requirements-flowdown

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

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

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

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

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