Requirements Flow-Down Skill
SkillDev toolsSkill for systematic requirements capture, decomposition, and traceability
Instructions available. Your AI can read the instructions. Execution depends on the setup they require.
Account requirements not reviewed. Check the skill instructions before use; ahel provides instructions and does not run this skill.
Add ahel to your AI once: Claude, ChatGPT, Cursor, Claude Code or Codex. Then ask it to use this.
Then ask your AI: use the Requirements Flow-Down Skill skill
What this skill tells your AI
The instructions your AI receives, as published by a5c-ai/babysitter in library/specializations/domains/science/mechanical-engineering/skills/requirements-flowdown/SKILL.md and read by ahel’s review.
Purpose
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
Common Standard Sources
| Domain | Standards |
|---|---|
| Structural | ASME BPVC, AWS D1.1, AISC |
| Materials | ASTM, SAE AMS, MMPDS |
| Drawing | ASME Y14.5, ASME Y14.100 |
| Quality | ISO 9001, AS9100 |
| Safety | OSHA, ANSI, ISO 13849 |
| Environmental | MIL-STD-810, IEC 60068 |
Requirements Change Control
Change Process
1. Change request submitted
2. Impact assessment
- Technical impact
- Cost impact
- Schedule impact
- Downstream requirements
3. Review and approval
4. Implementation
5. Verification of change
6. Update traceability
Process Integration
- ME-001: Requirements Analysis and Flow-Down
Input Schema
{
"source_documents": {
"customer_spec": "string",
"applicable_standards": "array",
"interface_documents": "array"
},
"system_context": {
"system_name": "string",
"subsystems": "array",
"interfaces": "array"
},
"requirement_level": "stakeholder|system|subsystem|component"
}
Output Schema
{
"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
Signals
- GitHub stars
- 2k
- Forks
- 112
- Last commit
- Sep 2026
Advanced
- Item type
- skill
- Key
requirements-flowdown- Source
- github.com/a5c-ai/babysitter