用途：依据 ISO/IEC/IEEE 29148:2018 把现实需求转化为明确、可验证、可追溯的需求，衔接获取方与供应方，捕获利益相关者需求并形成约束设计与测试的正式陈述，保持基线受控。
主要能力：将需求结构化为利益相关者需求（StRS）；用 [Condition] [Subject] shall [Action] [Constraint] 构造规范语句；编写 BRS、StRS、SyRS、SRS 及 OpsCon、ConOps；按九项单项特性评估单条需求；评估需求集的完整性、一致性、可行性、无歧义性、可验证性与可确认性；检测并改写“user-friendly”“etc.”“and/or”“all”等语言反模式；分配验证方法（检查、分析、演示、测试）及明确通过/失败标准；构建双向追溯矩阵（RTM）；记录变更控制（CCB 流程）并计算波动性、追溯覆盖率、缺陷密度、验证就绪度等指标；按项目规模裁剪规格大纲，含敏捷格式。
使用方式：输入 mode（create、evaluate、document，缺省时按请求推断）、source_material、可选 target_specification 与 project_context。create 模式按层级分类并生成规范语句、探测边界情况、组织需求章节、附加元数据并向上追溯；evaluate 模式逐条检查九项特性、标记反模式并给出改写、评估需求集、确认验证方法与追溯、输出 PASS/FAIL/CONDITIONAL 判定；document 模式生成或更新 RTM、记录基线状态与 CCB 变更、计算指标并记录裁剪决策。输出为 Markdown，含工件、元数据表、评估判定与开放问题。需求 ID 形如 REQ-<SPEC>-<NNN>，删除后不复用。
适用场景：需求获取与编写、规格评审与审计、追溯与基线管理、变更控制与需求度量。
限制：不设计架构或向组件分配需求；不编写测试用例（仅定义验证标准）；不批准基线（由人或 CCB 负责）；信息缺失时不编造需求，而是列出开放问题。禁止以用户为主语，一条需求一个陈述，避免模糊量词，遵守抽象层级，基线仅经变更控制修改，裁剪需说明理由。