How to derive engineering requirement

Requirements Development Steps

Step 4 “Analyze, Refine & Decompose Requirements” examines each requirement to see if it meets the characteristics of a good requirement. Each requirement is then decomposed into a more refined set of requirements that are allocated to sub-systems and documented in the Weapons System Specification (WSS). Newly derived requirements are expected to emerge from this process, which continues until all requirements are defined and analyzed.

Requirements analysis, refinement, and decomposition is often a shared responsibility between the acquisition Program Management Office (PMO) and the development contractor.

1. Assess each top-level requirement for feasibility (see Feasibility Assessment) of implementation, consistency within program constraints, and its ability to be verified. If the requirement is impossible to implement within cost and schedule constraints, it must be identified as an issue and resolved by adjusting the budget, relaxing the schedule, and changing or eliminating the requirement.
2. Use functional or object-oriented analysis to define a functional architecture that can be used as a basis for allocating requirements.
3. Allocate all system, subsystem, and interface requirements to appropriate hardware and software configuration items. Ensure each requirement:
   • Is written as a single definitive statement.
   • Has a unique identification number for tracking purposes.
   • Can be traced to a higher level source requirement or analysis.
   • Has been allocated to a specific Computer Software Configuration Item (CSCI).
4. Ensure that each performance requirement has one or more corresponding verification requirements. Involve those who will perform testing activities to ensure that requirements are testable. The specification verification requirement should define a means of objective measurement.
5. Identify analyses, trade studies, prototyping, and demonstration efforts for risk reduction, considering the following:
   • Completeness: Are all higher-level requirements allocated?
   • Consistency: Is the content, format, and notation from requirement to requirement, and specification to specification similar?
   • Feasibility: Can the requirement be met?
   • Balance: What are the trade-offs between requirements?
   • Verifiability/testability: Can the requirement be objectively verified?
   • Human factors: Is the design consistent with sound human factors principles?
6. Complete the definition of derived software requirements and examine them for consistency with system requirements, feasibility, and the effects of various implementation strategies. Monitor derived requirements size volatility since derived requirements are often a significant source of software size growth.
7. Apply early aggressive activities to verify that software intended for reuse fits the following criteria:
   • The advertised performance of the software to be reused satisfies performance requirements.
   • The software to be reused exists and is available.
   • The actual performance of the software to be reused satisfies performance requirements and does not have inherent shortfalls that will lead to additional growth.
   • There is a plan to address future upgrades/support of the reused software.
8. Ensure developers flow top-level requirements down to lower-level specifications and to lower-tier suppliers, including software configuration item specifications.
9. Verify CSCI-to-CSCI and CSCI-to-Hardware Configuration Item (HWCI) interface requirements identification and definition.
10. Verify that an adequate and compatible set of tools are in place to capture multi-level requirements (systems down through software) and design evolution.
11. Use operational scenarios to the extent possible to demonstrate, or bring to life, what the requirements are trying to capture. (Operational scenarios portray the product, end-user, and other entities in the intended environment, and are a useful tool for discovering and refining requirements.)

Requirements Development Steps

• Overview: Requirements Development Process Overview
• Step 1: Gather & Develop Requirements
• Step 2: Write & Document Requirements
• Step 3: Check Completeness
• Step 4: Analyze, Refine & Decompose Requirements
• Step 5: Verify & Validate Requirements
• Step 6: Manage Requirements

AcqNotes Tutorials

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