Chapter - 12 - Fit, Criteria and Rationale

Fit, Criteria and Rationale

Formality Guide

A pleasing aspect (amongst many) of Kent Beck’s extreme Programming technique is its insistence on writing test cases before writing the code. The test case defines the yardstick that the implemented code must match. The fit criterion is the same thing: It is a yardstick for the requirement. By adding a fit criterion to the requirement, you are writing its test case.

Rabbits use a blog or wiki to discover the non-functional requirements. For each of the non-functional requirements yielded by the blog, we now suggest deriving the appropriate fit criterion, confirming it with the stakeholder, and writing the test case using that fit criterion. Horse projects need to have a precise and easily shareable understanding of the meaning of requirements. It has been our experience that when the project has multiple stakeholders—which is the norm for horse projects— different stakeholders assign different meanings to requirements. Adding a rationale and a fit criterion to each requirement means it is virtually impossible for misunderstandings to occur. We recommend that horse projects include both in their requirements. Elephant projects must use rationales and fit criteria. These projects are forced to produce a written specification to be handed on to some other party, either another part of the organization or an outsource. Having a specification containing only unambiguous, testable requirements is crucial to elephant projects if the other party is to understand and then deliver the correct product.

Why Does Fit Need a Criterion?

When you have a requirement for the product to perform some function or to have some property, the testing activity must demonstrate that the product does, indeed, perform that function or possess the desired property. To carry out such tests, the requirement must have a benchmark such that the testers can compare the delivered product with the original requirement. The benchmark is the fit criterion—a quantification of the requirement that demonstrates the standard the product must reach.

The Rationale for the Rationale

The rationale is the reason, or justification, for a requirement. We have found that attaching a rationale to the requirement makes it far easier to understand the real need. Quite often, stakeholders may tell you their perceived solution to the problem, rather than their real need. Alternatively, they may state a requirement that is so vague as to be (for the moment) unusable. In the example given previously, the client asked for a “user-friendly” product, but you could make sense of it when you learned that the rationale was that the project needed the users to readily adopt the product.

Scale of Measurement

Any requirement can be measured: All you must do is find a suitable scale with which to measure it. The scale of measurement is the unit you use to test the conformance of the product to its requirement. For example, if the requirement is for a certain speed of operation, then obviously the scale is time—microseconds, minutes, months—to complete a given action or set of tasks. For a usability requirement, you can measure the time needed to learn a product, or the time taken before achieving a level of competence, or perhaps even the error rate of the work done using the product. Scales of measurement exist for all sorts of qualities. Color can be measured by specifying its component colors as a percentage of cyan, magenta, yellow, and black. Loudness and softness of sound are measured in terms of decibels. An amount of light is measured in units of lumens. Typefaces can be measured by face names and point sizes. In fact, there is a scale of measurement for almost everything.

Product Failure

The fit criterion might be determined by asking your stakeholder, “What would you consider a failure to meet this requirement?” Suppose you have this requirement: Description: The product must produce the road de-icing schedule within an acceptable time. Clearly, the scale of measurement here is time. Your client can tell you how much time he thinks would constitute a failure. For example, the client would consider the product unacceptable if the engineer must wait for more than 15 seconds for the schedule to become available. This means you have the following fit criterion, with suitable business tolerances applied: Fit Criterion: The road de-icing schedule shall be available to the engineer within 15 seconds from when he makes his request for 90 percent of the times that it is produced. It shall never take longer than 20 seconds.

Standards

Sometimes numbers are not appropriate, or you can create a better fit criterion by citing a standard. For example, the requirement mentioned earlier that the product is “not offensive to any group” could be handled by citing your organization’s standards of conduct. Alternatively, your communications department might have standards for what is and what is not allowed to be said or displayed for public consumption. By citing that the product must comply with that standard, you are in effect setting the benchmark for lack of offensiveness.

Defining the Data

For example, within the Ice Breaker project requirements often refer to Road Section. If you look in the data dictionary, you will find this definition: Road Section = Road Section Identifier + Road Section Coordinates You can then expect to find a definition of each of the attributes—for example: Road Section Identifier = *Unique identifier for 500 meters of road. The maximum number of road sections per road is 10,000.* Another strategy for defining the data is to define each term as part of the fit criterion of each individual requirement. However, as you will usually reference the same term in more than one requirement, it makes sense to maintain a central dictionary that can act as a cross-reference between requirements. Your growing understanding of the data means that you can progressively build a business data/information model that specifies the essential stored data for the requirements you are specifying.

Graphic Fit Criteria

When writing fit criteria, the aim is to be as implementation neutral as possible, thereby giving the designers and developers the maximum amount of freedom in choosing how to meet each requirement. The problem is that natural language is inherently procedural (you are forced to write words in a serial order) and sometimes that order is interpreted incorrectly as part of the requirement. You might consider the following approaches.

Decision Tables

Suppose that your fit criterion defines the rate of discount that a customer should have depending on how long he has been a customer, what his cumulative spending is, and whether he is a member of the customer loyalty program.

Maintainability Requirements

Maintainability requirements specify expectations about the maintenance of the product. Usually the fit criteria for these requirements quantify the amount of time allowed to make certain changes. This is not to say that all maintenance changes can be anticipated, but where changes are expected, then it is possible to quantify the time allowed to adopt those changes. Fit Criterion: All functionality must be migrated to the new website with no more than 10 minutes of unavailability of the site.

Security Requirements

Security is too important to be left to the whims or the goodwill of the developers. Your organization probably has some security standards in place, either specific to the industry or specific to your type of product. It is important to know which standard applies and to include it in your fit criterion. Taking this step has an added benefit: CYA. If a breach occurs in the future, at least you can say your product complied with the standard.

Cultural Requirements

Cultural requirements, by their nature, are subjective and slightly more difficult to quantify. The fit criterion is usually based on who will certify the product’s acceptability. For example: Fit Criterion: The Shatnez Laboratory of Brooklyn shall certify that the product complies with the shatnez rules. Fit Criterion: The communications department shall give the opinion that the product displays no words or symbols that could be construed as religious or political.

Chapter - 10 Functional Requirements

CHAPTER - 10

(Functional Requirements)

Created by:- Ramandeep Kaur

  

Functional Requirements


Functional requirements describe what the product has to do to support and enable the owner’s work. They should be, as far as possible, independent of the technology used by the eventual product. The Functional Requirements Specification is designed to be read by a general audience. Readers should understand the system, but no particular technical knowledge should be required to understand the document.

Uncovering the Functional Requirements 

The scenario is a convenient way to work with stakeholders to determine the necessary functionality for a product use case. Each of the scenario’s steps is decomposed into its functional requirements. The collection of functional requirements reveals what the product has to do to fulfill the product use case. 

This use case diagram shows the product generating the road de-icing schedule. This PUC is triggered by the Truck Depot Supervisor; the Thermal Mapping Database is a cooperative adjacent system providing information to the product use case upon request. The objective is to write enough functional requirements for your developers to build exactly the product your client is expecting and your actor needs to do the work.

Data, Your Secret Weapon

A class diagram showing the stored data that the business needs to predict the formation of ice on roads. A truck is dispatched to treat a road when the readings from the weather station and the forecast indicate the road section is about to freeze. There is a dependency between a product’s stored data and its functionality: You cannot have stored data unless there is some functionality to store and retrieve it, and functions can exist only if they process data.

Technological Requirements 

Technological requirements arise purely because of the chosen technology. This need is a technological requirement; that is, it arises purely because of the chosen technology. If the designer had selected a different technology to handle this part of the work—say, a direct fiber-optic link—the result would be different technological requirements. 

Grouping Requirements

A hierarchy of requirements. The work context is the highest-level statement of requirements; it is decomposed into the next level, the business events. The level below the business events comprises the product use cases, each of which is decomposed into a number of product use case steps. The lowest level includes the atomic requirements, each of which can be traced back to the hierarchy. Activity diagrams and user stories are also used to group atomic requirements. Features are a grouping often used by stakeholders from marketing or product version planning.

Chapter- 11 Non-functional requirements

Non-Functional Requirements

 Non-functional requirements
Ans: Non-functional requirements define system attributes such as security, reliability, performance, maintainability,  scalability, and usability. They serve as constraints or restrictions on the design of the system across the different backlogs. They ensure the usability and effectiveness of the entire system. Failing to meet any one of them can result in systems that fail to satisfy internal business, user, or market needs, or that do not fulfill mandatory requirements imposed by regulatory or standards agencies. Proper definition and implementation of NFRs is critical. Over-specify them, and the solution may be too costly to be viable, under- specific or underachieve them, and the system will be inadequate for its intended use. An adaptive and incremental approach to exploring, defining, and implementing NFRs vital skill for Agile teams.


 Difference between functional and non-functional 
requirements
Ans: Functional Requirements: Functional requirements specifies a function that a system or system component must be able to perform. It can be documented in various ways. The most common ones are written descriptions in documents, and use cases. Use cases can be textual enumeration lists as well as diagrams, describing user actions. Each use case illustrates behavioural scenarios through one or more functional requirements. Often, though, an analyst will begin by eliciting a set of use cases, from which the analyst can derive the functional requirements that  must be implemented to allow a user to perform each use case. 
Non-functional requirements: Non-functional requirements are any other requirement than functional requirements. This are the requirements that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. Non-functional requirements are in the form of system shall be, an overall property of the system as a whole or of a particular aspect and not a specific function. The system's overall properties commonly mark the difference between whether the development project has succeeded or failed.


Use Case model
Ans: A use-case model is a model of the system's intended functions and its surroundings, and serves as a contract between the customer and the developers. Use cases serves as a unifying thread throughout system development. The same use-case model is the result of the requirements discipline, and is used as input to Analyses & Design and Test disciplines.
There are many ways to model a systems, each of which may serve a different purpose. However, the most important purpose of a use-case model is to communicate the system's behaviour to the customer or end user. Consequently, the model must be easy to understand.

Examples of Non-Functional requirements
Ans: Users must change the initially assigned login password immediately after the first successful login. Moreover, the initial should never be reused. Employees never allowed to update their salary information. Such attempt should be reported to the security administrator. Every unsuccessful attempt by a user to access an item of data shall be recorded on an audit trail. A website should be capable enough to handle 20 million users with affecting its performance. The software should be portable. So moving from one OS to other OS does not create any problem. Privacy of information, the export of restricted technologies, intellectual property rights, etc. should be audited.

Advantages and Disadvantages of Non-functional requirements.

Ans: Advantages:

• The nonfunctional requirements ensure the software system follow legal and compliance rules.
• They ensure the reliability, availability, and performance of the software system
• They ensure good user experience and ease of operating the software.
• They help in formulating security policy of the software system.

Disadvantages:

• None functional requirement may affect the various high-level software subsystem
• They require special consideration during the software architecture/high-level design phase which increases costs.
• Their implementation does not usually map to the specific software sub-system,
• It is tough to modify non-functional once you pass the architecture phase.

Chapter - 8 Starting the Solution

We cannot make this book an exhaustive treatise on the design of software and organizational systems. Each organization has its own unique implementation environment, which means that the designers will come up with a unique design. Nevertheless, we can identify the variables that you need to consider to make the design decisions in your environment.

Iterative Development 

Iterative development techniques don’t always appear to do much in the way of upfront design, relying instead on frequent releases of software to gauge the design’s suitability. Although this approach can certainly work, it can be time-consuming if the initial releases are not very close to what is actually needed, or if the problem is so poorly understood or defined by the stakeholders that any solution is bound to be wide of the mark. In any event, it is usually more efficient to begin the discovery of need with abstract models and conversations, instead of concrete implementations.

Determine the Extent of the Product 

The task of business analysis is to determine what the work should be in the future and how the product can best contribute to that work. As noted earlier in this text, business use cases are responses to requests from the outside world for the work’s service. The optimal response is to provide the most valuable service (from the outsider’s point of view) at the lowest cost in terms of time, materials, or effort (from your organization’s point of view), and in the most pleasing and encouraging manner (from the end user’s point of view). Thus the product you craft should be a contributor to the optimal business use case—one that makes the product cheaper and faster and more convenient and all of the other things your project is to deliver.

Innovation 

This is the time for you to be innovative. If no innovation occurs, then the new product will be much the same as whatever it replaces. It is, of course, important not to disrupt the essential requirements, but there are a number of things that you can do to make a more innovative and acceptable end product.

Innovation, as we use the term here, means thinking differently about the problem to find a new and better way to do the work, or in some cases to find better work to do. Instead of rushing ahead with the first-to-mind solution or the obvious solution, we urge you to spend just a little time with fellow business analysts and other stakeholders to come up with something better, something that will be longer lasting and more appealing, something innovative.


------------------------------------------------------------
Cooperative adjacent systems are usually computer systems acting as if they are part of the work.

-------------------------------------------------------------

Sketching the Interface

Sketching has certain advantages. It is quick, which is definitely a benefit. Moreover, if the sketch is rudimentary enough, it will dissuade users from trying their hand at screen design. They are not qualified to do so, and it is far too early in the development process to be going into detailed design. 

There is no point in having a carefully crafted screen layout when you’re still unsure of all the functionality (and non-functionality) that could influence the interface. Anything you can do to dissuade business users from designing screens is very much to your advantage. Similarly, when you use rough sketches, no one has too much ego invested. Subsequent tasks in crafting a solution could well mean significant changes to your sketches. No one seems to mind if a sketch is changed, but most people mind if their carefully crafted design is changed.

Product Use Case Scenarios 

The business analyst uses product use case (PUC) scenarios to communicate the intention of the automated product to the stakeholders. Naturally, the PUC scenario is not the only document available to you at this time. Even so, because it shows the functionality of the product, it is an easy document with which to convey your intentions to the stakeholders. We suggest that you present the PUC scenario to the stakeholders at some suitable meeting. Do not simply e-mail it to them—you need their feedback.

To begin, first identify the business events. Pick one of them and trawl to discover the functionality that responds to that event (the business use case). As a way of showing your understanding, write a business use case scenario for this event. When your stakeholders are happy with the scenario, determine how much of that BUC can be implemented as the product. Whatever that turns out to be becomes the product use case.

Cost, Benefit, and Risks 

Naturally enough, choosing a solution is not just a matter of drawing a few lines on process models and hoping for the best. You have the responsibility to come up with the optimally valuable product—that is, optimally valuable to its owner. This implies that the cost of your solution must be in proportion to the benefit it brings to the owner. There is little point spending $10 to develop the product if the benefit it brings is worth only $1—unless, of course, the $1 saving is part of a repetitive process and is applied thousands of times.

Putting It All Together 

There is no formulaic method for arriving at the optimal solution; you have lots of factors to juggle, and the best design is simply the best compromise among all of them.

Chapter 6 - Scenarios

Chapter 6 - Scenarios

Author - Zac Dewit

Scenarios

• A scenario is an outline of a series of steps. This term is used to describe the parts of a section of work. Chapter 4 taught us how to split the work into parts. The scenario takes those parts and defines its functionality. 
• These scenarios are especially used to create business use cases (BUC) with the help of the stakeholders. 
• A scenario is simple and is easy to understand for all stakeholders. However, not all stakeholders need to see or hear about it. It can be specifically made for groups or can be made for all the people involved.
• Once these scenarios have been made and shown, it should help the stakeholders reach an agreement on the work that needs to be done. Then you make more scenarios to describe how each person will interact with this new system
• Each part of the scenario should be a part of the functions in a BUC. There should be 3 to 10 steps. This way there is still a clear path, but it is not overly complicated.

The Essence of the Business

• If we think back to the brown cow model, the scenarios belong to the "how now" quadrant. To move to the "what" side of things, we need to consider the essence of the problem and in turn the essence of the business. 
• To do this we need to eliminate any technology-based bias that we have while asking one simple question. What does this business do? By breaking it down to the simple form here we can refocus on what really needs to be done to make the business better.  

Alternatives 

• Alternatives are choices that you have created for the user. These choices are put here on purpose. They are a desire of the business. These choices are usually available to make the user's life easier or more straightforward.
• An example of this is when you buy textbooks and choose if you want digital or actual copies. 
• These are positives and appeal to our desire to have options in life. 

Exceptions

• Exceptions are the unwanted deviations. They are unwanted because the owner would have preferred if they never existed. This includes things like when people forget their passwords or do not have proper documents.
• Do not look for exceptions until after you have found all your normal scenarios. It can be easy to spend forever thinking of exceptions that will likely never happen. It is important to save this step until nearer to the end. 
• The goal of these scenarios is to understand how to safely and respectfully handle these exceptions to your normal work.

What if? Scenarios

• Finally "what if?" scenarios are when you explore strange and outside the box ideas. You can ask questions like "What if we did this?" or "What if we rearranged this?". These questions can get stakeholders to reimagine how work can be done and even if you don't immediately find a solution to a problem, it can give a greater understanding of how the business works and how the parts of the work interact with one another. 
• Another aspect of this is to find what is currently a constraint in the business. What is it that is holding you back from achieving so much more? If you can find these and eliminate them, you can improve the business.

Chapter - 7 Understanding the Real Problem

This chapter is of particular importance to rabbits. 

As a rabbit project, you are likely to be using techniques such as story cards, Post-it notes, or sketches on a whiteboard. These artifacts display, more often than not, proposed solutions to unstated problems.The essence does not have to be written as the first draft of the story card (it helps if it is) but it must be revealed during the requirements conversation.

Horse projects’ aspirations to informality are helped if the business analysts and the stakeholders talk about only the essence of the work. Using this approach, they generate fewer models and possibly cut down on the amount of communication needed.

Elephant projects might involve outsourced development, in which case it is vital that they solve the right problem. If not, the delivered product has to be corrected and the outsource charges for the corrections.

The Brown Cow Model

Abstraction 

At this stage, it might be helpful to talk a little about abstraction. Abstraction and getting to the essence are pretty much the same thing, but possibly abstraction is the more natural way to think about this concept. The word has Latin roots—abs, which “means away from,” and trahere, which means “to draw.” Thus abstraction, as we use the term here, is drawing away or removing physical implementation so as to reduce it to its essential characteristics. In other words, an abstraction is the idea, not the implementation. 

Solving the Right Problem 

The way of thinking discussed here follows from understanding the abstracted essence. This section is relevant to all requirements analysts, regardless of the size or nature of the project. It is equally applicable to iterative and traditional development methods.

Moving into the Future 

So far in this book we have been looking at the current implementation of the business, and then deriving the essence of the business and arriving at the correct problem to solve. Of course, all this activity relates to the current business, its current technology, and its current essence. If you refer to the Brown Cow Model, you have achieved respectively the How-Now and the What-Now views of the work. 

-------------------------------------------------------------------------------

We suggest something along these lines for planning and running innovation workshops: 

1. Set the scope of the innovation. It should not be too narrow, as many innovations are originally thought of as outside the remit of the team. Invite all stakeholders who have an interest in this scope to participate in the workshop. 

2. Partition the scope using business events to allow the participants to concentrate on the end-to-end business processes, while keeping in mind that systemic thinking usually involves all of the business events. 

3. Plan the workshop. You will probably have to use several innovation techniques. Some of these are discussed in this book, and a number of excellent texts on creativty also available. You will have to facilitate the workshop and lead your stakeholder through the techniques. 

4. Record everything that happens in the workshop. Do not try and assess ideas during the workshop. Innovating and assessing are two separate activities and should not be tackled at the same time. 

5. After the workshop, feed the results back to participants. 

6. Incubate. Sometimes the really great idea does not happen for some time. People are quite capable of coming back days later with some profound improvement to one of the workshop innovations. These workshops are intended to be more structured than regular brainstorming sessions. The intention is to use a mixture of innovation techniques to generate a more interesting outcome. 

--------------------------------------------------------------------------------

Brainstorming Brainstorming 

It is one way of innovating. It is useful for generating lots of contributions regarding the scope of the problem,or what it could be. This strategy is not intended to promote unconstrained scope creep. Instead, the brainstorming session generates ideas that could lead to a better product without incurring additional expense.

Piggyback a new idea onto an old one. That is, build one idea on top of another. 

Write every idea down, without censoring. 

If you get stuck, seed the session with a word pulled randomly from a dictionary, and ask participants to make word associations that have some bearing on the product. 

Make the session fun. You cannot mandate creativity; you have to let it come naturally. 

You won’t see many ground-breaking ideas if the boss is present at the session and says something like, “I want to hear only ideas that are marketable.” 

Back to the Future 

Let’s return to what we are doing here. Your task is to change the current work into the future work, or as we have described it previously, to transform the How-Now into the Future-What. Looked at it another way, this effort involves changing business policy, and the new policy should be innovative. As we have said several times—and it is worth repeating—there is little value in simply re implementing some old piece of work. If your project is to provide something valuable to the organization, then it must provide an advance, some fresh thinking, to make the end product as useful as possible. 

Chapter 5 - Investigating the Work

Chapter 5 - Investigating the Work

Author: Zac Dewit

Trawling 

• Trawling is usually a term for fishing. It defines hanging out your net and continuing to drive the boat so that fish will be caught without much effort as they can be unaware they were caught. This also applies to requirements gathering. 
• A person that is good at trawling will know where to find the fish or information as it is usually in similar locations from one day to the next. Once you have found a spot that works, it can be smart to revisit it for future projects.
• It is also important to realize that you can't be too slow whilst doing this. You need to get through this stage so the project can truly begin. Do not worry as you can always come back if there is something you missed. 
• One last thing to realize is that all stakeholders are different and need to be addressed as such. You need to understand how the business works, how the project will help the business and what each stakeholder wants out of the project. 

Formality Guide

• For each of the project sizes, there are different guides to finding your requirements. 
• Rabbit - For these small projects (less than 6 months)  it is especially important to work as fast as you can. You are encouraged to go to the shop in small slices and to understand how it works and what needs to be fixed. Projects like this are usually iterative projects meaning they are repetitive and steps are usually repeated. Using a repeated process will also help you save on paperwork and other documentation. 
• Horse - Since a horse project (6 months to 2 years) has a high capacity of stakeholders, different techniques like apprenticing and interviewing are key. Use case workshops can also be a very helpful tool. These three tools can help with documentation which will help with the decisions later in the project. These projects can have a much larger scope and effect range. This means that the BA needs to have a greater knowledge of the company. 
• Elephant - Since these projects can take such a long time (over 2 years), it is important to keep up to date documentation. Other parts of elephant projects can include outsourcing. This also needs special documentation. 

Brown Cow Model

• One unique way of looking at the work and requirements is by using the brown cow model. This model splits everything into 4 sections. How now, What now, Future What, Future How.
• How now - This quadrant is the usual place to start. This shows how the work is being done currently. This view is the ground zero for where your new system or idea will come into play. It is important to realize that this new thing needs to be unique and different from the current way or else it is not worthwhile. There must be a change. 
• What now - This part is all about the essence of the work. This view is technologically neutral meaning it shows no direct link to the tech or humans within the company. It is a clean way of thinking about how the company operates.
• Future What - This is where you put your dreams. This being anything that you could want or need from your company. In this section you can put all the ambitions you have as an owner. 
• Future How - This last quadrant takes all the aspects of the previous and finds a technological way of solving and implementing that into the current system. 

Business Use Case Workshops

• A business use case or BUC is all about how business events trigger a response in the form of work. This work is then broken down and divided into manageable chunks.
• Now that the work is in chucks a helpful tool to analyze and make improvements is a BUC workshop. 
• In these workshops, the interested stakeholders discuss what work they are currently involved with and what they hope to do in the future. This is like the "how now" and " future what" sections of the brown cow model. 
• Then you can uses scenarios to help people understand what will help them achieve what they want. 

Interviewing Stakeholders

• Interviewing stakeholders is a basic way to understand what the company needs and what the solution to the problem could be. This is one of the simplest ways to understand the company and all the different aspects that can be changed.
• This, however, is not without its downsides as it requires the stakeholders to verbalize what they want. For some people that is easy but for many, it is difficult to explain what they do to someone who hasn't had their level of training. The BA also needs to ask specific and targeted questions so the interviewee can stay on track and give accurate replies.