One of the key assurance activities for any project is expert evaluation and assessment of the requirements. The requirements need to be evaluated by multiple people with varying expertise, in order to identify incorrect, ambiguous, and incomplete requirements. A System Requirements Review (SRR) is one way to accomplish this evaluation.
A fundamental question for requirements evaluation is: How well do the requirements accomplish the system and sub-system objectives? This question provides a framework within which to consider the specific requirements. While it is very easy to take a focused approach to low-level requirements, such as for complex electronics, it is in the best interest of the project to always keep a systems-level viewpoint. When the whole system is considered, in relation to the specific low-level requirements, inconsistencies and missing requirements can be identified.
The main goals of requirements evaluation are: [1]
- Ensure that all appropriate higher-level requirements are included in the requirements specification.
- Identify any inconsistencies or conflicts within the requirements, or with other requirements documents.
- Ensure that the quality of the document (e.g. readable, unambiguous) is adequate for its usage.
- Ensure decomposition of the higher-level requirements into system-level requirements and specifications. Using Requirement Tracing makes this step easier.
Inconsistencies and Conflicts [1]
With any complex system, it is difficult to ensure that there are no inconsistencies or conflicts within the large set of requirements for the system. When higher-level requirements are decomposed to lower-level, sub-system requirements, it is possible for the information to be lost or changed. This is especially true if the sub-system requirements are written by the engineers responsible for those sub-systems. Even in the best-managed requirements development, however, mistakes do happen.
Conflicting requirements are those that state essentially the same requirement (or refer to the same item), but have different values or constraints. For example, a requirement for the electronic circuit board that will include a complex electronic device may state that the device will have 24 pins, while the requirements for that device may specify 28 pins. Another example is the data rate at which a sensor must be read. The complex electronics may have a requirement for 1 hertz, while the software that processes the data states that the sensor will be read at 10 hertz.
Inconsistencies are basically subtle conflicts. These are the cases where the requirements are specifying a behavior, interface, or timing for the complex electronic device that cannot meet all or part of another requirement. Finding inconsistencies often requires looking at multiple parts of the system, especially when they have to work together to implement a higher-level requirement.
What to Look for During the Evaluation
Use the Requirements Checklist, which contains specific items to look for in requirements, as an evaluation guide. Modify the checklist to make it specific to your project.
Checklist Items:
Below is an excerpt from the Requirements Checklist that can be used in this step.
- Were all stakeholder requirements documented?
- Was each requirement checked to see that it met all of the following?
- Necessary [trace to a user need]
- Concise [minimal]
- Feasible [attainable]
- Testable [measurable]
- Technology Independent [avoid “HOW to” statements unless they are real constraints on the design of the system]
- Unambiguous [Clear]
- Complete [function fully defined]
AcqLinks and References:
- Defense Acquisition Guidebook (DAG) – Chapter 4
- Requirements Development Checklist
- DAU Systems Engineering Fundamentals Guide
- Space and Missile Systems Center (SMC) Systems Engineering Primer & Handbook
- NASA Systems Engineering Handbook (large 9M file)
- EIA-632 “Processes for Engineering a System” – 7 Jan 99
- White Paper: Writing a Requirements Document “For Multimedia and Software Projects” by Rachel S. Smith
- White Paper: Requirements Development, Verification, and Validation Famous Failures by Bahill & Henderson
Updated: 7/30/2021
Rank: G1
