Characteristics of Excellent Requirements

Characteristics of Excellent Requirements

How can you distinguish good requirements specifications from those with problems? Several characteristics that individual requirement statements should exhibit, followed by desirable characteristics of the SRS as a whole, are discussed below (Davis 1993; IEEE 1998). A careful review of the SRS by project stakeholders representing different perspectives is the best way to determine whether each requirement has these desired attributes. If you keep these characteristics in mind as you write and review the requirements, you will produce better (although never perfect) requirements documents and you will build better products. 

Requirement Statement Characteristics

Complete

Each requirement must fully describe the functionality to be delivered. It contains all the information necessary for the developer to design and implement that functionality.

Correct

Each requirement must accurately describe the functionality to be built. The reference for correctness is the source of the requirement, such as a customer or a higher-level system requirements specification. A software requirement that conflicts with a corresponding system requirement isn't correct. Only user representatives can determine the correctness of user requirements, which is why it is essential to include users, or their surrogates, in requirements reviews. Requirements reviews that don't involve users can lead to reviewers saying, "That doesn't make sense. This is probably what they meant." This is also known as guessing.

Feasible

It must be possible to implement each requirement within the known capabilities and limitations of the system and its environment. To avoid infeasible requirements, have a member of the software engineering team work with marketing or the requirements analysts throughout the elicitation (requirements-gathering) process. This person can provide a reality check on what can and cannot be done technically, and what can be done only at excessive cost.

Necessary

Each requirement should document something that the customers really need or something that is required for conformance to an external system requirement or a standard. Another way to look at "necessary" is that each requirement comes from an origin you recognize as having the authority to specify requirements. Trace each requirement back to specific voice-of-the- customer input, such as a use case, or some other origin.

Prioritized

Assign an implementation priority to each requirement, feature, or use case to indicate how essential it is to a particular product release. If all the requirements are regarded as equally important, the project manager loses a degree of freedom for responding to new requirements added during development, budget cuts, schedule overruns, or the loss of project personnel.

Unambiguous

All readers of a requirement statement should arrive at a single, consistent interpretation of it. Because natural language is highly prone to ambiguity, write each requirement in simple, succinct, straightforward language of the user domain, not in computerese. Effective ways to reveal ambiguity include holding formal inspections of the requirements documents, writing test cases, developing prototypes, and devising specific usage scenarios.

Verifiable

Examine each requirement to see whether you can devise a small number of tests or use other verification approaches, such as inspection or demonstration, to determine whether the requirement was properly implemented in the product. If a requirement isn't verifiable, determining whether it was correctly implemented becomes a matter of opinion, not objective analysis. Requirements that are inconsistent, infeasible, or ambiguous are also unverifiable.

Requirements Specification Characteristics

Complete

No requirements or necessary information should be missing. Missing requirements are hard to spot, because they are invisible. Focusing on user tasks, rather than on system functions, can help you to prevent incompleteness. If you know you are lacking certain information, use TBD ("to be determined") as a standard flag to highlight these gaps. Resolve all TBDs from a given portion of the requirements before you proceed with construction.

Consistent

Consistent requirements don't conflict with other software requirements or with higher-level (system or business) requirements. Disagreements among requirements must be resolved before development can proceed. You might not know which single requirement (if any) is correct until you do some research.

Modifiable

You must be able to revise the SRS when necessary and maintain a history of changes made to each requirement. This requires that each requirement be uniquely labeled and expressed separately from other requirements so that it can be referred to unambiguously. Each requirement should appear only once in the SRS, as it is easy to generate inconsistencies by changing only one instance of a redundant requirement. A table of contents, an index, and a cross-reference listing will make the SRS easier to modify.

Traceable

You should be able to link each software requirement to its origin and to the design elements, source code, and test cases that implement and verify the correct implementation of the requirement. Traceable requirements are uniquely labeled and are written in a structured, fine-grained way, as opposed to large, narrative paragraphs. 

--
h.o.s.a.m.r.e.d
Be OpeN Mind