Requirements Flow-Down Skill

SkillDev tools

Skill for systematic requirements capture, decomposition, and traceability

Instructions available. Your AI can read the instructions. Execution depends on the setup they require.

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
TypeDescriptionExample
FunctionalWhat the system does"Shall lift 500 kg"
PerformanceHow well it performs"Lifting time < 30 sec"
InterfaceConnections to other systems"Shall mate with Type A connector"
EnvironmentalOperating conditions"Shall operate at -40 to +85 C"
PhysicalSize, weight, shape"Shall weigh < 25 kg"
ReliabilityFailure characteristics"MTBF > 10,000 hours"
MaintainabilityService characteristics"Shall be serviceable in field"
SafetyHazard 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
MethodApplicationEvidence
AnalysisCalculations, simulationsAnalysis report
TestPhysical testingTest report
InspectionVisual/dimensional checkInspection report
DemonstrationFunctional demoDemo 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
DomainStandards
StructuralASME BPVC, AWS D1.1, AISC
MaterialsASTM, SAE AMS, MMPDS
DrawingASME Y14.5, ASME Y14.100
QualityISO 9001, AS9100
SafetyOSHA, ANSI, ISO 13849
EnvironmentalMIL-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

  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

Signals

GitHub stars
2k
Forks
112
Last commit
Sep 2026
Advanced
Item type
skill
Key
requirements-flowdown
Source
github.com/a5c-ai/babysitter