requirements-engineering

需求工程（Requirements Engineering）用于把用户需求与业务目标转化为精确、可测试的需求。它连接需求发现与设计：把发现阶段得到的“用户需要什么”，转化为架构阶段所需的“系统必须做什么”。资料指出，需求质量差是项目失败的首要原因，问题往往不在于需求缺失，而在于需求含糊、相互矛盾或不完整。

用途与起点该技能可能从多种上游形态启动：一是需求发现证据集，如市场研究、用户画像与可行性发现；二是经过路由的入口栈交接，如问题框架与设计方向；三是记录约束、开放问题与预期下一步的需求简报。资料强调，不要强行让所有路径都经过同一套上游产物，而应从实际存在的、已批准的上游方向出发，并忠实保留其约束。

输入

design-direction：当问题框架已比较选项并选定路径时的首选方向性输入，是应转化为需求的发布或迭代方向的最强信号。
problem-frame：澄清问题陈述、非目标、假设、开放问题与语言边界上下文，需求应保留而非悄悄解决这些内容。
intake-brief：补充路由与范围上下文，用于保留工作类型、紧迫性、方法选择、交接风险与上游语言边界。
market-research-report：当工作仍锚定在发现证据时的市场背景、竞品差距或机会框架。
user-persona-set：需求应回溯到的用户目标、痛点与行为模式。
feasibility-report：可行/不可行与风险上下文，尤其当可行性、运营约束或时间线限制影响哪些内容能成为需求时使用。最低期望是：要么有已批准的设计方向，要么有经过评审的发现证据集，使问题与目标用户足够清晰，无需猜测即可撰写需求。若两者都不存在，应停止并回到上游，而不是从模糊意图中编造需求。当上游产物声明了 source_language、artifact_record_language 与 user_presentation_locale 时，应原样向前复制这些字段，而不是隐式重新决定。

流程第 1 步：收集功能需求。针对每个用户画像与旅程，识别系统必须做什么，包括用户动作（登录、创建、搜索、购买、导出）、系统响应（校验、计算、通知、持久化）与业务规则（定价逻辑、访问控制、工作流转换）。使用一致格式：“当[条件]时，系统应[动作]，以便[收益]。” 第 2 步：识别非功能需求。仅在源材料支持某个界限，或明确标注为仍需负责人确认的假设时，才量化质量属性，例如性能（响应时间 < 200ms p95、支持 1000 并发用户）、安全（OWASP Top 10 合规、SOC2 Type II、静态数据加密）、可扩展性（无需架构变更即可应对 10 倍增长）、可用性（99.9% 正常运行时间，即每年 8.7 小时停机）、无障碍（WCAG 2.1 AA 合规）。当来源只给出方向而无数字时：仅当界限有明确来源时才转化为有界需求，否则记录为需要评审的开放问题或假设；不要为了让文档看起来完整而编造精确目标。第 3 步：优先级排序。使用 MoSCoW（Must/Should/Could/Won't）或 RICE（Reach x Impact x Confidence / Effort）：P0（Must）没有产品就不可用；P1（Should）重要但存在变通方案；P2（Could）锦上添花，时间允许则纳入；P3（Won't）明确不在本次迭代范围内。第 4 步：校验并解决冲突。与利益相关者评审完整性，检查需求之间是否矛盾，与架构师核实技术可行性，确保可追溯性（每条需求关联到某个用户需求），标记任何精度由假设驱动而非来源驱动的需求或非功能需求，保留来自 problem-frame、design-direction 或 intake-brief 的上游非目标与开放问题，而不是悄悄将其压缩为解决方案承诺。第 5 步：带可追溯性地记录。每条需求应包含：ID、描述、优先级、来源（哪个用户需求）、验收标准引用与状态。若某个指标、SLA 或保留期限未直接得到源材料支持，只能作为明确标注的假设，或带指定负责人的开放问题纳入。

输出

requirements-doc：由该技能产出。

质量门

所有 P0/P1 需求均已记录，并有清晰验收标准；
非功能需求在有证据处量化，否则转化为明确的开放问题或假设；
需求之间无未解决的矛盾；
利益相关者已评审并签字确认；
需求可追溯到用户需求。

反模式

把解决方案伪装成需求：“使用 Redis 做缓存”是解决方案而非需求，需求应是“缓存频繁访问的数据以实现 < 50ms 读取延迟”。
含糊需求：“系统应该快”不可测试，应量化一切。
编造精度：在没有来源或已批准假设的情况下，把“必须保持响应”变成“p99 < 800ms”会制造虚假确定性，未知界限应标记为开放问题。
委员会式需求：过多利益相关者而无单一负责人会导致膨胀，应由一人负责需求文档。
通过“再加一个”造成范围蔓延：每条新需求都有成本，应针对待办列表评估，而不是直接添加。

技能介绍