BELL MTS

Non Functional Requirements  The explanation of the Non Functional Requirements starts with a story in our book. A story that really happened: The client rejected the delivered help desk software. The functionality was correct-it supported the help desk’s activity, and did all that it was supposed to do, but the client didn’t want it. Why not? Because the users-the help desk operators-refused to use it, preferring to use the existing manual procedures. Why was the product so bad? Because the requirements team had paid almost no attention to the non-functional requirements.  We should explain that: The help desk staff already had nine other applications running on their desktops. The requirements team did not bother inquiring about the users’ look and feel requirements. As a consequence, the new software had a completely different interface style with a different set of icons and screen layouts. The help desk people had to use nine other applications and, quite rightfully, r...

Functional requirements are a part of requirements analysis (also known as requirements engineering), which is an interdisciplinary field of engineering that concerns the design and maintenance of complex systems. Functional requirements describe the desired end function of a system operating within normal parameters, so as to assure the design is adequate to make the desired product and the end product reaches its potential of the design in order to meet user expectations. The requirements in requirement engineering help direct the development of the engineered product. Typically, a functional requirement is a basic functionality or desired behavior documented clearly and quantitatively. Requirements engineering ideas may be applied to more or less complex items. For example, when outlining the functional requirements for a jar, a functional requirement would be that it holds a fluid and have a threaded top for a lid to seal the jam for better preservation. When a product fails func...

Scenarios. According to the book we have reached up-to a stage, after learning about BUCs (Business Use Cases), identifying the business events and respond to the events. We have reached at scenarios to model and record the BUCs. We use scenarios a number of times, and find them to be very useful, mostly because of their ready acceptance by nontechnical stakeholders. Formality Guide Scenarios are useful in many of the situations-anyone can understand them, and they fit into every development style.  Rabbit projects can use scenarios as a trawling technique. The requirements analysts and the appropriate stakeholders come together to build a scenario for the business use cases. Horse projects may consider scenarios as an alternative to writing atomic functional requirements. When they have been developed enough, they can serve to inform the developers of the functional needs of the product. Elephant projects make use of scenarios as a discovery tool. The meetings...

Starting the solution, in which we bring the essence of the business into the technological world of the implementation. This diagram shows how you can decide and how you are going to implement the essential business. So, we are moving from an abstract world to the physical world; from policy to technology; from problem to solution; from purpose to design. We have arrived at the point where we move away from the virtual, abstract, and perfect world that exists above the line, and bring the business requirements into the reality of the technological world that lies below the line. in every step of our life we need solutions for getting better outcome. So, to arrive at an elegant solution, you must consider, and probably design, the experience that results from your choice of automation boundary. In other words, you must deliver the required functionality so that it works in a way that readily fits into the users’ work customs, meets the operational needs of the organization, c...

Fit Criteria and Rationale Fit Criterion:  A Fit Criterion   quantifies or measures the requirement, which makes it testable. It specifies that how one will know and measure that whether the implementation meets the requirement or not.   It quantifies the behavior, the performance, or some other quality of the requirement. A fit criterion is important as once the requirement is measured, then there is little room for any misunderstanding or ambiguity because it makes it understandable and testable. Why is Fit Criterion needed? When the requirement for any product is supposed to perform any kind of functions or to possess some property, then the testing activity must be able to show what the product does. Then to perform such tests, the requirement must have a benchmark so that the testers can compare the delivered product with the requirement. The benchmark is the fit criterion, i.e. a quantification of the requirement which demonstrate the standard that the p...

Understanding the Real Problem This chapter talks about how to deliver the right products. It is really important to state the problem completely so that the appropriate solution can be created focusing on how to solve it. The right product is the one that meet the user's need and to get to the right problem, abstraction is used. Abstraction is focusing on ideas rather than solutions. It means thinking about the essence of subject by discarding the technological and physical components to uncover the real intent of the work. The Brown Cow Model: Thinking Above the line The Brown Cow Model provides four views of the work, each of which provides the business analyst with information that is useful at different stages of the investigation. Here, we would be talking about the "What" in the Brown Cow Model. Getting to the Essence of the Work Working above the horizontal line of Brown Cow Model, we capture the real essence of the business. It's not about issu...

Chapter 5 INVESTING THE WORK  In this chapter we have learned that how the business is working and to make sure that is that business working according to plan and requirements. chapter we are discussing how to investigate a piece of work prior to changing it. Normally your change would mean building a software product or some other device to do some or all of the work. we are using trawling to describe the activity of investigating the business. It is important to uncover the current business, including both its data and its processes, it is also important that you do not spend too much time doing so. Keep in mind that this is the beginning of the analysis process, and you would like to get through this step as rapidly as possible. The trawling activity is central to the requirements process. It uses the outputs of the project blast off activity as its starting point for investigating the work and accumulating knowledge about it. Over the next few chapters, we will de...

Business Use Cases Business Use Cases Business events are useful to partition the work, but it is the work’s response  to the event that now captures the interest of the requirements analyst.  For every business event, there is a preplanned response to it, known as a  business use case (BUC). The business use case is always a collection of identifiable  processes, data that is retrieved and/or stored, output generated, messages  sent, or some combination of these. Alternatively, we could simply say  that the business use case is a unit of functionality. This unit is the basis for  writing the functional and non-functional requirements. Understanding the Work: When we say “work,” we mean the system for doing business. This system includes the human tasks, the software systems, the machines, and the low-tech devices such as telephones, photocopiers, manual files, and notebooks. In fact, anything that is used to produce the owner’s goods, ...