Step 3 “Check Completeness” is to check that a complete set of requirements have been developed and documented that defines all system functions that are needed to satisfy the stakeholder needs with their associated performance, environmental, and other non-functional requirements.
Visit: Requirements Evaluation
Requirements designers should go back to Stakeholders with the draft requirements document and have them review it. They should ask if this is what they had in mind, or if they think any changes are in order. It’s much easier to make changes now, while your project is still words on paper, than after development has begun. Take their comments and make changes; you may need to revisit the Step 2 “Write & Document Requirements” but it will be easier this time. Repeat the process until there is complete agreement among all stakeholders. It’s recommended that the Program Manager (PM) get each stakeholder to actually sign off on the requirements document before proceeding to Step 4 “Analyze, Refine & Decompose Requirements”.
A good tool to uses to check for completeness is Requirements Tracing. This tools allows requirements designers, PM, stakeholder and engineers the ability to verify that a requirement meets level objectives and to get rid of a requirement that doesn’t. Tracing is conducted throughout a systems life cycle and confirmed at each technical review for all new and old requirements. The purpose is to assure that the requirements continue to meet the needs and expectations of its stakeholders.
Step 3 Checklist Items:
Below is an excerpt from the Requirements Checklist that can be used in this step.
- Were the requirements documented in the appropriate document?
- Was a requirements walkthrough held to validate the requirements?
- Was a verification case for each requirement developed? [test, demonstration, analysis, inspection]
- Was each user need fully addressed by one or more system requirement(s)?
- Is the requirement set complete? Have the following types of requirements been defined?
- Enabling [training, operations & maintenance support, development, testing, production, deployment, disposal]
- Non-functional [reliability, availability, safety, and security].
- Were attributes [quality factors] assigned to each requirement [Priority, risk, cost, owner, date, and verification method]? Verification methods could include demonstration, analysis, test, and inspection.
- Have all stakeholders signed off on the requirements document?
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