The Requirements Flow-Down skill provides systematic capabilities for capturing, decomposing, and tracing requirements throughout the mechanical design process, ensuring design intent is properly communicated and verified.
Capabilities
Stakeholder requirements elicitation
Functional requirements decomposition
Performance requirements specification
Design constraint identification
Requirements traceability matrix
Verification method assignment
Requirements change management
Code and standard flow-down
Usage Guidelines
Requirements Hierarchy
Requirements Levels
Level 1: Stakeholder Requirements
- What the customer/user needs
- High-level, solution-independent
- Source: Customer specifications, standards
Level 2: System Requirements
- What the system must do
- Allocated from stakeholder requirements
- Source: System engineering
Level 3: Subsystem Requirements
- What each subsystem must do
- Allocated from system requirements
- Source: Architecture trade studies
Level 4: Component Requirements
- What each component must do
- Allocated from subsystem requirements
- Source: Detailed design
Requirement Types
Type
Description
Example
Functional
What the system does
"Shall lift 500 kg"
Performance
How well it performs
"Lifting time < 30 sec"
Interface
Connections to other systems
"Shall mate with Type A connector"
Environmental
Operating conditions
"Shall operate at -40 to +85 C"
Physical
Size, weight, shape
"Shall weigh < 25 kg"
Reliability
Failure characteristics
"MTBF > 10,000 hours"
Maintainability
Service characteristics
"Shall be serviceable in field"
Safety
Hazard prevention
"Shall prevent pinch points"
Requirements Development
Requirements Attributes
Each requirement should have:
- Unique identifier (REQ-XXX-XXXX)
- Requirement text (shall statement)
- Rationale (why needed)
- Source (parent requirement or stakeholder)
- Priority (must have, should have, nice to have)
- Verification method (analysis, test, inspection, demo)
- Owner (responsible engineer)
- Status (draft, approved, verified)
Well-Written Requirements
Good requirement characteristics (SMART):
- Specific: Unambiguous and clear
- Measurable: Quantifiable acceptance criteria
- Achievable: Technically feasible
- Relevant: Traces to stakeholder need
- Traceable: Links up and down hierarchy
Bad: "The system shall be easy to use"
Good: "The system shall be operable by one person
without tools within 5 minutes of training"
Requirements Decomposition
Decomposition Process
Parse Parent Requirement
Identify measurable parameters
Identify applicable conditions
Identify affected components
Allocate to Children
Assign parameters to subsystems
Maintain budget (sum of allocations)
Document allocation rationale
Derive Supporting Requirements
Interface requirements
Enabling requirements
Constraint requirements
Budget Allocation Example
Parent: "System shall weigh < 100 kg"
Children:
- Structure: < 40 kg (40%)
- Mechanism: < 25 kg (25%)
- Electronics: < 15 kg (15%)
- Cabling: < 10 kg (10%)
- Margin: 10 kg (10%)
Traceability Matrix
Matrix Structure
Requirements Verification Matrix (RVM):
| Req ID | Requirement Text | Source | Verification Method | Evidence |
|--------|------------------|--------|---------------------|----------|
| REQ-001 | Shall lift 500 kg | SRS-001 | Test | Test Report TR-001 |
| REQ-002 | Shall operate at -40C | SRS-002 | Test | Test Report TR-002 |
| REQ-003 | Shall weigh < 25 kg | SRS-003 | Inspection | FAI-001 |
Verification Methods
Method
Application
Evidence
Analysis
Calculations, simulations
Analysis report
Test
Physical testing
Test report
Inspection
Visual/dimensional check
Inspection report
Demonstration
Functional demo
Demo record
Code and Standard Flow-Down
Standards Application
Mechanical standards flow-down:
1. Identify applicable standards (contract, regulatory)
2. Extract applicable requirements from standards
3. Create derived requirements with standard reference
4. Track compliance through verification
{"requirements_set":[{"id":"string","text":"string","type":"functional|performance|interface|environmental|physical","source":"string","parent":"string","verification_method":"analysis|test|inspection|demonstration","owner":"string","priority":"must|should|nice","status":"draft|approved|verified"}],"traceability_matrix":{"upward":"matrix of parent links","downward":"matrix of child links","verification":"matrix of evidence links"},"budgets":{"mass":"object of allocations","power":"object of allocations","cost":"object of allocations"},"open_items":"array of TBD/TBR items"}
Best Practices
Write requirements in shall statements
Each requirement should be verifiable
Maintain clear parent-child traceability
Review requirements with stakeholders
Control changes through formal process
Update verification evidence as completed
Integration Points
Connects with Trade Study for requirement derivation
Feeds into Design Review for verification
Supports Test Planning for verification activities
Integrates with Change Management for requirement changes
