by Anupama A. Weerabahu

Good Requirements: What and Why?

The quality of a product is heavily dependent on the quality of the input or the raw material. This is applicable to software as well and in general, good requirements are a mandate necessity for good product design or software, which eventually satisfies the end customer. Thus, the requirement engineer or the business system analyst has a well-understood job responsibility of developing ‘good’ requirements. In today’s article, we will focus on identifying the qualities or the characteristics of good requirements and why it is important.

What are good requirements?

In order to reduce the risk of surprises at the time of delivery, the requirements engineer needs to work hard to develop a set of good requirements. The goodness of the requirements can be determined with the characteristics of individual requirements and as an entire set.

What makes a requirement good?

There are some characteristics identified which makes up a good individual requirements, such as necessity, feasibility, completeness, and verifiability etc. These are discussed below in detail.

    1) Necessity

A necessary requirement is one that must be present to meet the system objectives and is absolutely critical for the operation of the system. If it is removed or deleted, a deficiency will exist, which cannot be fulfilled by other capabilities of the product or process.

    2) Concise

The requirement statement includes only one requirement stating what must be done and only what must be done, stated simply and clearly. It will be easy for the reader to read and understand.

                                                    

    3) Implementation Free

The requirement states what is required, not how the requirement should be met. A requirement statement should not reflect a design or implementation nor should it describe an operation. However, the treatment of interface requirements is generally an exception.

    4) Feasible

The stated requirement can be achieved by one or more developed system concepts at a definable cost.  A feasible/viable requirement can be met using the existing technology, can be achieved within the budget, can be met within the schedule, is something that the organization has the necessary skills to utilize, will be used by the end users, and must be helpful to build the system.

    5) Complete

A complete requirement contains all the information that is needed to define the system function and leaves no one guessing. Thus the stated requirement is complete and does not need further amplification and it will provide sufficient capability. Needs to include the measurement units where applicable.

    6) Unambiguous

A requirement is unambiguous if it has the same interpretation for the customers, the requirement determiners, and the requirement recipients – thus each requirement must have one and only one interpretation. Language used in the statement must not leave a doubt in the reader's mind as to the intended descriptive or numeric value and the process needs to be clearly explained.

    7) Verifiable

The stated requirement is not vague or general but is quantified in a manner that can be verified and a verifiable requirement makes it possible to evaluate whether the system met the requirement and verifiable by means that will not contaminate the product or compromise the data integrity. The verifiable requirements are statues in such a way that it can be checked by one of these 4 alternative methods: inspection, analysis, demonstration or test.

What makes a set of requirement good?

Besides improving the requirements individually, we should also view them as a whole, in its entirety. The following characteristics are important to manage the entire set of requirements.

    1)    Consistency

Consistent requirements do not conflict with other software requirements or with higher level (system or business) requirements. Requirements are not duplicated. The same term is used for the same item in all requirements.

    2)    Maintainability

Requirements evolve with time. During the use of the Requirements Definition Process, they change as we learn more about the customer’s expectations. After delivery, they change because customer may have to respond quickly to changing business needs or develop new opportunities. The requirements and all associated information should be filed and managed by the established Provisioning change control procedures. Create an audit trail of changes as well as identification of current and superseded portions.

    3)   Traceability

Traceability is the cross-referencing of requirements. It greatly facilitates management and incorporating the voice of the customer in the design. During the Requirements Definition Process, there are two important questions that can be answered with a set of traceable requirements:

· What is the source of this requirement?

· What requirements are impacted or defined by this source?

When a requirement changes, the answers to these questions are essential for assessing the impact of the change.

Guidelines for Writing Quality Requirements

The given below are few guidelines that Karl E. Wiegers has presented in his article Writing Quality Requirements, that I funs very useful when writing the reqruirements: 

• Keep sentences and paragraphs short. Use the active voice. Use proper grammar, spelling, and punctuation. Use terms consistently and define them in a glossary or data dictionary.
• To see if a requirement statement is sufficiently well defined, read it from the developer’s perspective. Mentally add the phrase, "call me when you’re done" to the end of the requirement and see if that makes you nervous. In other words, would you need additional clarification from the SRS author to understand the requirement well enough to design and implement it? If so, that requirement should be elaborated before proceeding with construction.
• Requirement authors often struggle to find the right level of granularity. Avoid long narrative paragraphs that contain multiple requirements. A helpful granularity guideline is to write individually testable requirements. If you can think of a small number of related tests to verify correct implementation of a requirement, it is probably written at the right level of detail. If you envision many different kinds of tests, perhaps several requirements have been lumped together and should be separated.
• Watch out for multiple requirements that have been aggregated into a single statement. Conjunctions like "and" and "or" in a requirement suggest that several requirements have been combined. Never use "and/or" in a requirement statement.
• Write requirements at a consistent level of detail throughout the document. I have seen requirements specifications that varied widely in their scope. For example, "A valid color code shall be R for red" and "A valid color code shall be G for green" might be split out as separate requirements, while "The product shall respond to editing directives entered by voice" describes an entire subsystem, not a single functional requirement.
• Avoid stating requirements redundantly in the SRS. While including the same requirement in multiple places may make the document easier to read, it also makes maintenance of the document more difficult. The multiple instances of the requirement all have to be updated at the same time, lest an inconsistency creep in.

High quality requirements are mandatory for a good software, because they provide a better foundation for product development and testing, which yields the ultimate end user satisfaction. Thus we as business analysts or requirement engineers, need to view and review the written requirements formally as well as informally, early and often, to make sure that the written are of good quality.

Reference Materials:

1.  Writing Quality Requirements, by Karl E. Wiegers. http://www.processimpact.com/articles/qualreqs.html

2.   Characteristics of Good Requirements, Pradip Kar and Michelle Bailey.  Retreived from http://www.afis.fr/nav/gt/ie/doc/Articles/CHARACTE.HTM

3. 8 Characteristics of good user requirements. Retrieved from http://www.slideshare.net/guest24d72f/8-characteristics-of-good-user-requirements-presentation