requirements-flowdown

name	requirements-flowdown
description	Skill for systematic requirements capture, decomposition, and traceability
allowed-tools	["Read","Write","Glob","Grep","Bash"]
metadata	{"specialization":"mechanical-engineering","domain":"science","category":"design-development","priority":"medium","phase":7,"tools-libraries":["IBM DOORS","Jama Connect","Polarion"]}
graph	{"domains":["domain:mechanical-engineering"],"skillAreas":["skill-area:physics-simulation","skill-area:mathematical-reasoning","skill-area:motion-planning"],"roles":["role:systems-integration-engineer","role:research-engineer"]}

Requirements Flow-Down Skill

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

1. Parse Parent Requirement

   • Identify measurable parameters
   • Identify applicable conditions
   • Identify affected components

2. Allocate to Children

   • Assign parameters to subsystems
   • Maintain budget (sum of allocations)
   • Document allocation rationale

3. 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" 
  
   
     
     
     
  
   

Best Practices

1. Write requirements in shall statements
2. Each requirement should be verifiable
3. Maintain clear parent-child traceability
4. Review requirements with stakeholders
5. Control changes through formal process
6. 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