需求流下技能

目的

需求流下技能为机械设计过程提供了系统化的能力，用于捕获、分解和追溯需求，确保设计意图得到正确传达和验证。

能力

利益相关者需求获取
功能需求分解
性能需求规范
设计约束识别
需求追溯矩阵
验证方法分配
需求变更管理
代码和标准流下

使用指南

需求层次结构

需求层级

层级1：利益相关者需求
- 客户/用户需要什么
- 高层次，独立于解决方案
- 来源：客户规范、标准

层级2：系统需求
- 系统必须做什么
- 从利益相关者需求分配而来
- 来源：系统工程

层级3：子系统需求
- 每个子系统必须做什么
- 从系统需求分配而来
- 来源：架构权衡研究

层级4：组件需求
- 每个组件必须做什么
- 从子系统需求分配而来
- 来源：详细设计

需求类型

类型	描述	示例
功能	系统做什么	“应能提升500公斤”
性能	执行效果如何	“提升时间 < 30秒”
接口	与其他系统的连接	“应与A型连接器对接”
环境	操作条件	“应在-40至+85°C下运行”
物理	尺寸、重量、形状	“重量应 < 25公斤”
可靠性	故障特性	“平均无故障时间 > 10,000小时”
可维护性	服务特性	“应能在现场进行维护”
安全	危险预防	“应防止夹点”

需求开发

需求属性

每个需求应具备：
- 唯一标识符（REQ-XXX-XXXX）
- 需求文本（应陈述）
- 理由（为何需要）
- 来源（父需求或利益相关者）
- 优先级（必须有、应该有、最好有）
- 验证方法（分析、测试、检查、演示）
- 负责人（责任工程师）
- 状态（草案、已批准、已验证）

良好编写的需求

良好需求特征（SMART）：
- 具体：明确且清晰
- 可衡量：可量化的验收标准
- 可实现：技术可行
- 相关：追溯至利益相关者需求
- 可追溯：上下层级链接

差："系统应易于使用"
好："系统应可由一人操作，无需工具，且在5分钟培训内完成"

需求分解

分解过程

解析父需求
- 识别可测量参数
- 识别适用条件
- 识别受影响组件
分配至子需求
- 将参数分配至子系统
- 保持预算（分配总和）
- 记录分配理由
推导支持需求
- 接口需求
- 使能需求
- 约束需求

预算分配示例

父需求："系统重量应 < 100公斤"

子需求：
- 结构：< 40公斤（40%）
- 机构：< 25公斤（25%）
- 电子：< 15公斤（15%）
- 线缆：< 10公斤（10%）
- 余量：10公斤（10%）

追溯矩阵

矩阵结构

需求验证矩阵（RVM）：

| 需求ID | 需求文本 | 来源 | 验证方法 | 证据 |
|--------|------------------|--------|---------------------|----------|
| REQ-001 | 应能提升500公斤 | SRS-001 | 测试 | 测试报告TR-001 |
| REQ-002 | 应在-40°C下运行 | SRS-002 | 测试 | 测试报告TR-002 |
| REQ-003 | 重量应 < 25公斤 | SRS-003 | 检查 | 首件检验FAI-001 |

验证方法

方法	应用	证据
分析	计算、仿真	分析报告
测试	物理测试	测试报告
检查	视觉/尺寸检查	检查报告
演示	功能演示	演示记录

代码和标准流下

标准应用

机械标准流下：
1. 识别适用标准（合同、法规）
2. 从标准中提取适用要求
3. 创建带标准参考的衍生需求
4. 通过验证跟踪合规性

常见标准来源

领域	标准
结构	ASME BPVC、AWS D1.1、AISC
材料	ASTM、SAE AMS、MMPDS
图纸	ASME Y14.5、ASME Y14.100
质量	ISO 9001、AS9100
安全	OSHA、ANSI、ISO 13849
环境	MIL-STD-810、IEC 60068

需求变更控制

变更流程

1. 提交变更请求
2. 影响评估
   - 技术影响
   - 成本影响
   - 进度影响
   - 下游需求
3. 评审与批准
4. 实施
5. 变更验证
6. 更新追溯性

流程集成

ME-001：需求分析与流下

输入模式

{
  "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"
}

输出模式

{
  "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": "父链接矩阵",
    "downward": "子链接矩阵",
    "verification": "证据链接矩阵"
  },
  "budgets": {
    "mass": "分配对象",
    "power": "分配对象",
    "cost": "分配对象"
  },
  "open_items": "待定/待决项数组"
}

最佳实践

使用应陈述编写需求
每个需求应可验证
保持清晰的父子追溯性
与利益相关者评审需求
通过正式流程控制变更
完成时更新验证证据

集成点

与权衡研究连接以推导需求
为验证提供设计评审输入
支持验证活动的测试规划
与变更管理集成以处理需求变更