4、项目启动与需求分析：项目章程、干系人识别、需求收集方法、需求规格说明书（SRS）编写
嵌入式项目与纯软件项目最大的差异在于：需求不仅来自业务逻辑，还受限于硬件资源、实时性约束、功耗预算、通信接口和物理环境。项目启动阶段若未建立清晰的章程、未识别关键干系人、未采用结构化的需求收集方法，后续的系统架构设计将如同在流沙上盖楼。本章围绕项目启动的四大核心活动——项目章程制定、干系人识别、需求收集方法、SRS编写——展开，帮助项目经理和系统架构师在第一时间建立项目的“宪法”与“边界”。
4.1 项目章程：项目的“宪法”与授权依据
核心原理：项目章程（Project Charter）是正式授权项目启动的文件，它明确了项目存在的理由、高层级范围、关键里程碑、总体预算和项目经理的权限。在嵌入式项目中，章程尤其需要明确硬件平台选型约束、目标量产时间（TTM）、成本上限（BOM Cost Target）以及合规认证要求（如CE、FCC、IEC 60730）。章程不是需求文档，它不描述具体功能，而是定义“为什么做”和“边界在哪里”。
判断方法：一份合格的嵌入式项目章程应包含以下要素：
| 章程要素 | 嵌入式项目中的具体体现 | 常见缺失风险 |
|---|---|---|
| 项目背景与商业论证 | 市场对低功耗、高算力边缘设备的需求；竞品分析结论 | 缺乏商业驱动，后期需求蔓延无依据 |
| 目标与成功标准 | “6个月内完成量产，BOM成本≤$45，通过IEC 60730 B类认证” | 目标模糊，验收时争议不断 |
| 高层级范围 | “开发一款基于Cortex-M7的工业数据采集器，支持4-20mA输入和Modbus TCP” | 范围边界不清，后期不断加功能 |
| 关键里程碑 | EVT→DVT→PVT→MP 各阶段时间点 | 里程碑缺失，进度失控 |
| 预算与资源 | 人力投入（嵌入式软件3人、硬件2人、测试1人）、NRE费用 | 资源不足，项目延期 |
| 项目经理权限 | 有权调配资源、批准需求变更、向高层汇报 | 权限不足，决策链过长 |
4.2 干系人识别：从“隐形人”到“关键决策者”
核心原理：干系人（Stakeholder）是能影响项目决策、活动或结果的个人、群体或组织。嵌入式项目的干系人远比纯软件项目复杂：除了产品经理、软件工程师、测试工程师外，还包括硬件工程师、FPGA工程师、结构工程师、认证工程师、供应链采购、生产制造（SMT工厂）、现场应用工程师（FAE）、最终用户、甚至法律合规部门。遗漏任何一方，都可能在项目后期引发严重返工。
操作流程：干系人识别应遵循“四步法”：
- 头脑风暴列出候选清单：从项目生命周期出发，覆盖设计、开发、测试、认证、生产、维护各阶段。
- 分类与优先级排序：使用权力/利益矩阵（Power/Interest Grid），将干系人分为高权力高利益（重点管理）、高权力低利益（保持满意）、低权力高利益（随时告知）、低权力低利益（监督）四类。
- 分析期望与影响：明确每位干系人对项目的期望、潜在影响力和参与程度。
- 制定沟通策略：针对不同类别干系人，确定沟通频率、方式和内容深度。
4.3 需求收集方法：从“用户说”到“可验证的规格”
核心原理：需求收集是将干系人的期望转化为可设计、可测试、可验证的系统行为的过程。嵌入式项目的需求来源多样：客户规格书（SOW）、市场调研、竞品拆解分析、行业标准（如ISO 26262、IEC 61508）、硬件能力约束、软件可维护性要求等。需求收集不是一次性的访谈，而是持续迭代的过程。
常用方法对比：
| 方法 | 适用场景 | 优点 | 局限 |
|---|---|---|---|
| 一对一访谈 | 关键客户、领域专家 | 深度挖掘隐性需求 | 耗时，样本量小 |
| 问卷调查 | 大量用户、市场调研 | 覆盖面广，量化分析 | 无法追问，回复率低 |
| 现场观察/用户日志 | 工业设备、医疗仪器操作流程 | 发现真实使用场景 | 观察者效应，成本高 |
| 原型法（快速原型） | 人机交互界面、复杂逻辑验证 | 直观，早期验证可行性 | 原型可能被误解为最终产品 |
| 标杆对照 | 竞品分析、行业最佳实践 | 明确差距，设定目标 | 过度关注竞品，忽略创新 |
| 头脑风暴/工作坊 | 跨职能团队需求挖掘 | 激发创意，达成共识 | 需要强引导者，易偏离主题 |
4.4 需求规格说明书（SRS）编写：从“想法”到“基线”
核心原理：SRS是项目需求的正式载体，它描述了系统应提供的功能、性能、接口、质量属性和约束条件。SRS的质量直接决定了系统架构设计的正确性和测试验收的客观性。一份优秀的SRS应具备：正确性、无歧义、完整性、可验证性、一致性、可追踪性。
SRS标准结构（参考IEEE 830 / ISO/IEC/IEEE 29148）：
- 引言：目的、范围、定义、参考文献
- 总体描述：产品视角、用户特征、运行环境、约束与假设
- 具体需求：
- 功能需求（FR）：系统行为、输入/输出、处理逻辑
- 外部接口需求（IR）：用户接口、硬件接口、软件接口、通信接口
- 性能需求（PR）：响应时间、吞吐量、精度、功耗
- 质量属性（QR）：可靠性、可用性、可维护性、安全性
- 约束（CR）：法规、标准、硬件平台、成本
- 验证与验收：每个需求对应的测试方法或验收标准
- 附录：需求追溯矩阵（RTM）
编写操作流程：
- Step 1：将收集到的原始需求逐条编号（如FR-001、PR-002），确保每条需求独立、原子化。
- Step 2：使用“用户故事+验收标准”或“传统需求陈述”两种格式之一，但必须保证可测试性。例如：“系统应能在1秒内响应按键操作”优于“系统应快速响应”。
- Step 3：组织内部评审（硬件、软件、测试、产品四方参与），重点检查需求冲突和遗漏。
- Step 4：建立需求基线（Baseline），纳入配置管理。后续任何变更必须走正式变更控制流程（CCB）。
背景：某公司计划开发一款便携式工业数据采集器，用于现场设备振动信号采集。
关键约束：MCU选用STM32H743（Cortex-M7, 480MHz），ADC采样率最高1MSPS，BOM成本≤$50，工作温度-20℃~+70℃。
初始需求（来自客户）：“能采集振动信号，并保存数据。”
分析过程：该需求过于模糊。通过访谈和现场观察，细化出：
- FR-001：系统应支持4通道同步采样，每通道采样率可配置（1kSPS~500kSPS）。
- FR-002：系统应支持IEPE传感器供电（4mA恒流源，24V偏置电压）。
- PR-001：在500kSPS采样率下，连续采集时间≥30分钟，数据存储于MicroSD卡。
- QR-001：系统在-20℃环境下，采样精度误差≤±1%。
- IR-001：系统应提供USB 2.0接口用于数据导出，同时支持UART调试接口。
结果：SRS基线化后，硬件设计、驱动开发、测试用例设计均基于此版本展开，避免了后期需求变更导致的返工。
复盘经验：需求细化必须结合硬件数据手册进行可行性验证；SRS评审必须邀请硬件工程师参与。
4.5 常见误区与总结复盘
| 误区 | 后果 | 纠正措施 |
|---|---|---|
| 章程流于形式，未获得高层真正授权 | 资源协调困难，项目经理无实权 | 章程必须由发起人（Sponsor）正式签发，并在启动会上宣布 |
| 干系人识别只做一次，后期不更新 | 新加入的干系人（如认证机构）需求未被满足 | 每阶段初重新审视干系人清单 |
| 需求收集依赖单一来源（如只听客户） | 忽略内部制造、测试、维护需求 | 采用多源收集，交叉验证 |
| SRS中需求不可测试 | 验收时争议，测试用例无法设计 | 每条需求必须包含“如何验证” |
| 需求变更未走流程 | 范围蔓延，进度失控 | 建立CCB（变更控制委员会），严格执行变更评估 |