Chapter 12 Fit Criteria and Rationale

Fit Criteria and Rationale, we show how measuring requirements makes them unambiguous, understandable, communicable, and testable.

Fit means a solution completely satisfies or matches the requirement. That is, the solution does exactly what the requirement says it must do or has the property the requirement says it must have—no more and no less. To test whether the solution fits the requirement, however, the
the requirement itself must be measurable.

Formality Guide

Rabbit projects
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 of these 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 outsourcer. 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.

Possibly the most challenging part of testing a requirement against an

agreed-upon measurement is defining the appropriate measurement for the

requirement. It is tricky, but certainly not impossible.

Let’s suppose that your stakeholder is inexperienced and asks for a product

that is “user-friendly.” What that phrase means to you is likely not the

same thing as what it means to the stakeholder. However, once you can

measure “user-friendliness”—that is, put numbers against it—then you and

the stakeholder can arrive at an identical understanding.

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.

Chapter 11- Non-functional Requirements

Non-functional Requirements

The non-functional requirements describe the qualities that your product must have. In another way, how well it does the things it does. Such requirements make the product attractive, usable, fast, reliable or safe. Non-functional requirements are used to specify response times, or accuracy limits on calculations. Non-functional requirements are given when the product needs to have a particular appearance or be used by people in particular circumstances.

Functional Versus Non-functional Requirements

Use Cases and Non-functional Requirements

Non-functional Requirements Types

10 Look and Feel:

 The spirit of the product’s appearance.

11 Usability and Humanity:

The product’s ease of use, and any special considerations needed for better user experience.

12 Performance:

How fast, how safe, how many, how available, and how accurate the functionality must be.

13 Operational:

The operating environment of the product, and any considerations that must be taken into account for this environment.

14 Maintainability and Support: 

Expected changes, and the time needed to make them; also the specification of the support to be given to the product.

15 Security: 

Access, confidentiality, recoverability, and auditability of the product.

16 Cultural and Political: 

Special requirements that come about because of the culture and customs of people who can come in contact with the product.

17 Legal: 

The laws and standards that apply to the product.

Chapter 10- Functional Requirements

Functional Requirements

The chapter looks at the requirements that a product must satisfy to be successful or meaningful. These requirements should be defined alone before describing any technology to implement those requirements. The requirements should contain all the details so that the developers can understand these properly.

Uncovering the Functional Requirements

The scenarios help a lot to describe the requirements. Scenarios are created by partitioning the work using the business events that affect it. For each business event, there is a business use case that responds to the business event, and a BUC scenario describes this functionality from the business point of view. From this BUC, product use cases are created. 

PUC enables the business stakeholders and developers to have an overview of the functionality. The steps should be recognizable by stakeholders.

Description and Rationale

For every described requirement, there should be a rationale included to show why the requirement exists. By including a rationale with the description, the requirement itself becomes more useful. By knowing why something is there, the developers and the testers know much more about the effort they should put on it. It also indicates to future maintainers why the requirement exists in the first place. The rationale also helps to overcome the possibility of inadvertently writing a solution instead of the real need.

Data, Your Secret Weapon

After doing the description and rationale, there comes the data dictionary. The flows should be defined by listing their attributes and then those attributes enable us to develop a business data model. This model acts as a definition of functional requirements.

Data Models

The class model shows the classes (or entities) as rectangles. A class is a logical collection of data attributes that is needed by the product to carry out its functionality. The lines between the classes indicate an association between two classes and the name on the line indicates the reason for the association. The asterisks and the 1s define the multiplicity of the association.
 Here is an example to explain the data model for the IceBreaker Project.

Exceptions and Alternatives

Exceptions are unwanted but unavoidable deviations for the normal case caused by errors of processing and incorrect actions. 

Alternatives are allowable variations from the normal case, which are provided at the commands of stakeholders. 

Chapter 7 - Understanding the Real Problem

In this chapter, you will discover the real problem in your company when you remove all available technology and devices. With this action, you can understand the essence of the task that you are working with.

Formality Guide.

If you are not building something that meets the company’s needs, you are just wasting money and time for nothing. It doesn’t matter if the project is a rabbit, horse or elephant, in this chapter we need to understand the essence of the problem to create the best solution.

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. In this chapter, we look above the line.

The Essence

Now it is time to move above the horizontal line that separates the “how” from the “what.” Here’s where you see the real business—that which we refer to as the essence of the business. Up here the air is rarified, and you do not need to deal with the mundane, real-world issues of people and technology; instead, you take an abstract view and discover what the business is really doing. Once you see that, you move to what you would like to be doing in the future. In the Brown Cow Model, these views are shown by the What-Now and the Future-What quadrants.

Swim Lanes Begone

A typical process mode showing swim lanes; the horizontal lines on the diagram divide the work by current departmental responsibility. The model of the business after removing the swim lanes. Note how the customer can abort the transaction if the inventory is not available. The Confirm Order process can now advise the customer of the delivery date.

Chapter 8 Starting the Solution

Starting the solution  

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 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. 

Unfortunately, many projects begin with a proposed solution—in our terms, this means starting in the fourth quadrant, the Future-How. By starting here, the development team must hammer and cajole the solution into some semblance of what is needed, and at the same time attempt to discover what is really needed. Many practitioners find that they are forced to start in the Future-How quadrant, move back to the Future-What view to find out what is really needed, and then proceed once more to the Future-How view of the solution.  

No matter how you are developing software, the important part of this process is the discovery, by both you and your stakeholders, of the real needs of the solution. 

Essential business  

The functional needs can be presented to you in the form of a business use case (BUC) scenario, a collection of atomic functional requirements, or properly crafted user stories. The level of detail that you address before thinking about the solution will vary depending on your project strategy and the way in which you are working with all the stakeholders. Chapter 9 is devoted to strategies for getting from needs to solutions. An understanding of the non-functional needs of the essential business is important to crafting a valuable solution. The non-functional requirements—such things as usability, look and feel, operational, environmental, security, and so on—must be considered when making choices about the solution. The non-functional needs are largely responsible for specifying the kind of user experience appropriate for the intended audience.  

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 

~Igor Ilin 

Chapter 6- Scenarios

SCENARIOS

A Scenario is an outline of a plotted sequence of steps where the plot is supposed to suggest that you smash the work into a sequence of steps or scenes and by way of explaining

these steps, you give an explanation for the work.

The scenario is a neutral medium that is simple and understandable to stakeholders. The scenario should only be presented to interesting stakeholders who have knowledge in that part. The first thing we need is, to create an agreement that what will be the output from the work or what the work must do. After achieving the agreement, we need to decide how much work must be done by product. Then, we need to produce scenarios by breaking down the functions of business use cases into small steps. Each step stands for meaningful activity. There should be about 3 to 10 steps ideally in order to keep scenarios simple.

Then we need to confirm this scenario with the interested stakeholders. All stakeholders can be invited to participate and revise this scenario until it represents a consensus view of what the work

should be.

THE ESSENCE OF THE BUSINESS

The scenarios belong to the first quadrant of the Brown-Cow model - The How-Now view. To look at other quadrants, we need to take into consideration the essence of the problems. For this, we need to go back over the scenarios and eliminate the technological bias by keeping in mind what does the business needs to do.

DIAGRAMMING THE SCENARIOS

The better approach is to draw a picture first to explain the functions of a business use case. There are many choices that can be used for scenarios. However, UML is a popular choice that stands for Unified Modeling Language. Sometimes BPMN can be used as well which is Business Process Modeling Notation. The figure depicts the airline check-in example as a UML activity diagram. 

ALTERNATIVES

Alternatives arise when you wish the user to have a choice of possible actions. These choices are intentional, as they are wanted and defined by the business. They usually exist to make the work of the business use case more attractive and convenient to the participants. When you buy books or

music online, for example, you can decide whether to place your selected goods in a shopping cart awaiting check-out, or have them sent directly to you when you click “buy.” These deliberate choices offered by the vendor are alternatives.

EXCEPTIONS

We must pause here to urge you to delay looking for exceptions until you are satisfied with the normal case scenario. It is far too easy for stakeholders to get carried away with exceptions, and your review session with them can be quickly derailed by needlessly chasing exceptions that are not guaranteed ever to happen. It is only when you have the normal case that you can methodically work through it by looking for the exceptions and deciding what you will do about them.

Chapter 5 Investigating the work

In this module, we come to an understanding of what the business is doing and start to think about what it might like to do.

TRAWLING THE BUSINESS

We use the term trawling to describe the activity of investigating the business.
This term evokes the nature of what we are doing here: fishing. Not idly
dangling a line while hoping a fish might come by, but rather methodically running a net through the business to catch every possible requirement.

With a little experience and good techniques, the skipper of a

trawler knows where to fish so that he gets the fish he wants, and avoids the

ones that he doesn’t. The objective in this chapter is to show you some trawling

techniques, and give you guidelines on how to get the best from them.This chapter explores the techniques for discovering the business processes and the people involved in those processes. Inevitably, you will need a variety of techniques to achieve this feat, and you will find that not all

techniques are equally acceptable to your stakeholders. For this reason, it

will be necessary to vary your approach to best suit the stakeholders who are

providing the requirements.

TWARL FOR KNOWLEDGE

We build products to help us do work. For our purposes, it doesn’t matter

whether the work is processing insurance claims, analyzing blood samples,

designing automotive parts, predicting when ice will form on roads, keeping

track of a “things to do” list, controlling a telephone network, downloading music or movies, monitoring a household, manipulating photographs, or

one of many other human activities. In all instances, the product that you

are being asked to build must improve this work.

THE BUSINESS ANALYST

The business analyst is also known as a systems analyst, a requirements engineer,

and probably several other titles. We use “business analyst” because it

is the most commonly used name. Whatever name you use, this person is

an investigator and a translator: He has to inspect the work, interview the

business stakeholders, understand what they are saying, and then translate

that knowledge into a form that can be communicated to and understood by

the developers. Tasks of the business analyst are as follow:

Observe and learn the work, and understand it from the point of view of the

owner. As you work with your users, you study their work and question

them about what they are doing, and why they are doing it.

● Interpret the work. A user’s description of some work is not always factual

despite the user being the expert on that part of the work. The analyst

must filter the description to strip away the current technology, thereby

revealing the underlying essence of the work, not its incarnation.

● Record the results in the form of stakeholder-understandable analysis models.

The analyst must ensure that he and the stakeholders have the

same, and agreed, understanding of the work. We suggest using models

as a common language for communicating your knowledge to the

stakeholders.

THE BROWN COW MODEL

Chapter 4 Business use Cases

Business Use Cases 

A business use-case model is a model that describes the processes of a business and their interactions with external parties like customers and partners. 

 The blastoff process, which we described in the previous chapter, establishes
the scope of the work—the business area to be studied. This scope—ideally
shown graphically as a context diagram—defines a business area, part of which
is to be automated by your intended product. In reality, this work scope is
probably too large to be studied as a single unit. Just as you cut your food into
small bites before attempting to eat it, so it is necessary to partition the work
into manageable pieces before studying it to find the product’s requirements.
In this chapter we provide heuristics for finding the most appropriate use
cases. In later chapters you will see how this process allows you to arrive at
the most relevant and useful product to build. 

Understanding the work: 

The product you intend to build must improve its owner’s work; it will be
installed in the owner’s area of business and will do part of (sometimes all of) the work.

It does not matter which kind of work it is—commercial, scientific, embedded real-time,

manual, or automated—you always have to under-stand it before you can decide which kind of

product will best help with it. 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 note-books—in fact, anything that is used to produce the owner’s goods, services, or information. Until you understand this work and its desired outcomes, you cannot know which product will be optimally valuable to the owner.

Formality Guide: 

Rabbit projects should pay particular attention to this chapter. When run-
ning an iterative project, it is important to have a rock-solid grasp of the

business problem to be solved. We strongly suggest that rabbits make use of

business use cases to explore their problem domain before starting to formu-
late a solution. This approach does not add to the documentation load, and

it lessens the time spent delivering inappropriate solutions.

Horse projects should consider partitioning the work area using business
use cases as we describe them in this chapter. We have found that the BUC
scenarios are a useful working tool for discussing the current and future
work with your stakeholders. There is also the possibility of using BUC (and
later product use case [PUC]) scenarios as the documentation to pass along
to the developers, which allows you to avoid writing many of the detailed
requirements. We shall discuss this aspect in later chapters.

Elephant projects should definitely use business events. Given that ele-
phant projects have a large number of stakeholders, clear communication is

both important and difficult. We have found that BUC scenarios are an ideal
mechanism for discussing the work in geographically distributed teams.
Later, the BUC scenarios and their PUC derivatives are maintained as part
of the formal documentation. The BUC scenario is also useful for discussing
high-level issues with outsourcers.