REQUIREMENT QUALITY FACTORS
Requirement quality affects work performed in subsequent phases of the system life cycle. Requirements of poor quality:
- increase cost and schedule: effort is spent during design and implementation trying to figure out what the requirements are
- decrease product quality: poor requirements cause the wrong product to be delivered or descoping to meet schedule or cost constraints
- increase maintenance effort: lack of traceability increases the effort to identify where changes are required, especially as knowledgeable personnel leave
- create disputes with the customer/client: ambiguity causes differences in expectations and contractual issues
- are a major cause of project failure: all of the above
There never seems to be enough time to do it right, but time is found to do it over—if funding is available!
Information is associated with the requirement. This information is necessary for managing the project as well as the requirements. For example, associating priority and WBS with requirements facilitates planning and scheduling, associating change history with the requirement faciliates change control, while other associated information is necessary to produce traceability and other requirements management reports.
Completeness means there is enough information to proceed to the next stage or phase of work without risking a serious amount of rework. An example of incomplete requirements:The system shall validate charges over $100.Ensuring completeness is hard work, although models can help.
The system shall accept charges under $100.
What about charges of $100? Correcting the first requirement to state: "The system shall validate charges of $100 or more" is one way to address the situation.
Consistent terminology.Lack of conflict among requirements.
- A glossary helps achieve consistent terminology. Even commonly understood terms can create headaches later if they are undefined because they can change meaning over time.
- Acronyms common to the users' business can be used in requirements. Define them in the glossary for newcomers to the project.
Use the RM tool to search on key words and phrases to locate consistency problems. Key word and phrase searches may not locate conceptual conflicts. Diagrams can be also be used to locate some inconsistencies.
- Conflicting subjects: a requirement for blue backgrounds and one for red.
- Conceptual conflict: a requirement for accessibility and one requiring red and green on the GUI.
The requirement is technically and operationally possible to do within existing constraints. The constraints are typically time and money. For example, we can send a person to Mars, but not within a year and under a thousand dollars. An example of a technically infeasible requirement is time travel.An infeasible requirement does not always cease to be a requirement. Thinking these requirements cease to be requirements is a contractor/project's perspective. It is true they are not requirements for the project. But, if the client is enlightened and will use the respository for product maintenance, the requirement may be retained for future implementation. Typically, however, the requirements repository (if there is one at all) is scrapped after completion of the contract because it was not specified as a deliverable.
The requirement does not rely on another requirement to be fully understood.Requirements that need proxies are not independent. Parent requirements rely on their children to be fully defined. In testing, a parent is not satisfied until all its children are met. Why retain them? These may be source requirements that must be retained. Also, using them to structure the proxies or children improves understandability. For example, "user friendly" can be used to assign, talk about, or locate the group of proxies defining "user friendly" for that particular project. See examples of proxies.