The Atomic Requirement

Now let us look at how an individual, complete, formalized requirement is constructed.

As we treat each of the items that make up the requirement, consider how you discover it and how well it applies to your organization. For this activity, we assume you are using the Volere Shell, or that you are using some mechanism to ensure that you capture the relevant parts of each requirement.

Start by identifying the requirement. Each requirement has three pieces of identification: its number, its type, and the event(s) and/or use case(s) that spawned the requirement.

Requirement Number

Each requirement must be uniquely identified. The reason is straightforward: Requirements must be traceable throughout the development of the product, so it is convenient and logical to give each requirement a unique number. We use "number" meaning any unique identifier, although it can be any kind of identifier you wish. To keep this assignment from becoming an onerous clerical task, we suggest you use a simple sequential number. It is not important how you uniquely identify the requirement as long as you identify it.

Requirement Type

The type comes from the Volere Requirements Specification Template. The template includes 27 sections, each of which contains a different type of requirement. We use the template section number as the type: The purpose of the product is requirement type 1, constraints are type 4, functional requirements are type 9, look and feel are type 10, usability requirements are type 11, and so on.

Attaching the type to the requirement is useful in several ways:

• You can sort the requirements by type. By comparing all requirements of one type, you can more readily discover requirements that conflict with one another.

• It is easier to write an appropriate fit criterion when the type of requirement is established.

• When you group all of the known requirements of one type, it becomes readily apparent if some of them are missing or duplicated.

• The ability to group requirements by type also helps with stakeholder involvement. For example, you can easily identify all of the security requirements and make them available for review by a security expert.

Event/Use Case Number

The context of the work is broken into smaller pieces using the business events as the partitioning tool. The work makes a response to each business event; this response constitutes a business use case. You decide which part of the business use case is to be handled by the product; we call this part a product use case. When you identify each product use case, you also identify the user or users who will interact with that part of the product; we call them actors.

Give each business event a number for convenient referencing. Similarly, each product use case is numbered. For traceability and change-control purposes, it is useful to keep track of all requirements generated by a business event. Each of your product use cases corresponds to a business event, so it is possible to use the same number to indicate the business event and the product use case. If, however, you choose to cluster your requirements into sub-use cases, then you need a separate numbering system. Whatever your preference, you must tag each requirement so that you can identify which parts of the business it relates to (business events) and which parts of the product it relates to (product use cases). Figure 10.4 illustrates how requirements are identified.

Figure 10.4.

The requirement number, requirement type, business event number, and product use case number.

Being able to collect together all the requirements for a product use case helps you find missing requirements and confirm the functionality with its users.

Description

The description is the intent of the requirement. It is an English (or whatever natural language you use) statement in the stakeholder's words as to what the stakeholder thinks he needs. Do not be too concerned about whether the description contains ambiguities (but neither should you be sloppy with your language), as the fit criterion eliminates any failings in the language. The objective when you first write the description is to capture the stakeholder's wishes. So for the moment just be as clear as you (and your user) can.

Rationale

The rationale is the reason behind the requirement's existence. It explains why the requirement is important and how it contributes to the product's purpose. Adding a rationale to a requirement helps you to clarify and understand it, and by so doing, you come to understand the requirement.

Originator

The originator is the person who raised the requirement in the first instance, or the person to whom it can be attributed. You should attach the originator's name to your requirements so you have a referral point if questions about the requirement arise or if the Quality Gateway rejects the requirement. The person who raises the requirement must have the knowledge and authority appropriate for the type of requirement.

Fit Criterion

A fit criterion is a quantified goal the solution has to meetin other words, it is an acceptance criterion. While the description of the requirement is written in the language of the users, the fit criterion is written in a precise, quantified manner so that solutions can be tested against the requirement.

The fit criteria set the standard to which the builder constructs the product. While they do not say how the implementation will be tested, they do provide the benchmark to test against to determine whether the implementation meets the requirements.

Chapter 9 covers fit criteria.

Fit criteria are so important that we have devoted an entire chapter to them. visit Chapter 9 for more details.

Customer Satisfaction and Customer Dissatisfaction

The satisfaction ranking is a measure of how happy the client will be if you successfully deliver an implementation of the requirement. The scale ranges from 1 to 5, where 1 means that the client is unconcerned about the outcome and 5 means that the client will be extremely happy if you successfully deliver a product that meets the requirement.

The dissatisfaction rating is also on a scale of 1 to 5. This time the rating measures the amount of unhappiness the client will feel if you do not successfully deliver this requirement. A 1 means that the client will be unconcerned if the product appears without this requirement; a 5 means that your client will be extremely angry if you do not successfully deliver this requirement.

For example, this is a fairly normal and unremarkable requirement:

The product shall record changes to the road network.

Naturally, your client expects the product to be able to record the road network so that it can tell the engineers which roads must be treated. The client is unlikely to get excited over this requirement, so the satisfaction rating may be anything from 3 to 5. However, if the product cannot record changes to roads, you would expect the client to be rather angry, and thus would give a dissatisfaction rating of 5. The high dissatisfaction score gives significance to this requirement.

Now consider this requirement:

The product shall issue an alert if a weather station fails to transmit readings.

This feature of the product would be both useful and nice to have. Your client may give it a satisfaction rating of 5. However, the requirement is not crucial to the correct operation of the product: The engineers would eventually notice if readings failed to turn up from one of the weather stations. In this case the client may well rate the dissatisfaction as 2 or 3. In other words, if the product never does this, the engineers will not be too unhappy.

The satisfaction/dissatisfaction ratings are used to place a value on each of the requirements. The effect of asking your client to rate the satisfaction and the dissatisfaction is to make him consider the requirement more seriously. It also gives him an opportunity to let you know how he feels about each of the requirements. Later, you can weigh these ratings against the cost of each requirement.

The ratings are set either by your client or by a panel made up of the significant stakeholders. If the product is intended for sale to external customers, then these ratings should be assigned by a panel representing the potential customers.

An example of a complex case we have come across is one where mobile telephones were being developed for sale in different countries. The marketing people had identified that their customers' priorities differed from country to country. Thus the value ratings had to be separately assessed for each target country.

Priority

The priority of a requirement is the decision on the importance of the requirement's implementation relative to the whole project. The customer value ratings help to identify how the stakeholders feel about the requirements. The priority rating governs which requirements will receive priority when it comes to inclusion in the next release of the product. Priority is often the result of a decision reached by a group of stakeholders and sometimes reflects a compromise.

You can apply the idea of customer value and priority at the product use case level. As soon as you have identified your product use cases, ask your stakeholders to give a customer satisfaction rating and a customer dissatisfaction rating to each use case. If you know enough about the constraints, then you might also be able to do a rough prioritization for each use case by asking whether it should appear in the first or subsequent releases of the product.

For more on prioritization techniques, refer to Chapter 14, Reviewing the Specification.

Conflicts

Conflicts between requirements mean there is some contradiction between them, or one requirement makes another requirement less feasible. For example, a requirement for the product may be to calculate the shortest route to the destination. Another requirement might say the product is to calculate the quickest route to the destination. A conflict between these two requirements would arise if they were both considered to be the preferred route, and if traffic or other conditions meant that the shortest route was not always the quickest route.

Similarly, you may discover a conflict between two or more requirements when you design the product and begin to look at solutions. Perhaps the solution to one requirement means the solution to the other requirement is impossible, or at least severely restricted.

Conflicting requirements are a normal part of development. Don't be too concerned if conflicts between requirements appear. As long as you are able to capture the fact that the conflict exists, then you can work toward solving it.

Supporting Materials

Do not attempt to put everything in the specification. There will always be other material that is important to the requirements, and it may be simply cross-referenced by this item.

Supporting Materials: Thornes, J. E. Cost-Effective Snow and Ice Control for the Nineties. Third International Symposium on Snow and Ice Control Technology, Minneapolis, Minnesota, Vol. 1, Paper 24, 1992.

We suggest you restrict entries under this heading to those references that have a direct bearing on the requirement.

History

This section is the place to record the date the requirement was first raised, dates of changes, dates of deletions, date of passing through the Quality Gateway, and so on. Add the names of people responsible for these actions if you think it will help later.