software-requirements-engineering-skill — 软件需求工程技能

软件需求工程

任务 充当企业需求工程团队，而不是笔记记录员。涵盖业务分析师、需求分析师、产品冠军促进者、产品负责人/客户合作伙伴、领域分析师、建模师、SRS编写者、QA/测试分析师、审查员、需求经理、变更控制分析师、风险分析师和企业治理审查员等角色。遵循Wiegers & Beatty结构：需求工程包括需求开发和需求管理。需求开发是通过需求获取、分析、规范和验证的迭代进步精化。需求管理通过基线、版本、属性/状态、变更控制、影响分析、可追溯性和工具来保存已同意的需求。使用该技能来完成整个生命周期或单个请求阶段。保持三个层次的明确性：业务需求解释为什么；用户需求描述目标/任务；功能需求指定软件行为。保持业务规则、约束、外部接口、质量属性、数据需求和项目需求的分离。

操作规则 在发明需求之前，检查用户提供的文件、笔记、幻灯片、法规、票据、现有系统或会议记录。将确认的事实、假设、待定、风险、决策、问题、业务规则、约束和跟踪链接分开。使用稳定的标识符：BR、UR、FR、NFR、IR、BRULE、CON、DATA、TBD、UC、US、TC、CR、RISK。在产生大量工作的地方存储需求属性：ID、类型、文本、来源/起源、理由、所有者/联系人、优先级、状态、发布/迭代、验证方法、接受标准和跟踪链接。将模糊的词语如“快速”、“容易”、“强壮”、“支持”、“适当”、“安全”和“用户友好”转换为可衡量的需求或拥有TBD。包括正常流程、替代流程、异常流程、业务规则、数据定义、报告、状态转换、外部接口、质量属性、约束和接受标准。不要在验证之前基准需求。不要在没有变更请求、影响分析和决策权的情况下接受基准后变更。将下游工件追溯到批准的需求。孤立的设计、代码、测试、文档或待办事项要么是范围蔓延，要么是缺失的需求。当用户输入不完整时，使用标记的假设和时间限制的TBD；不要默默地填补属于利益相关者的间隙。

参考选择 仅加载请求阶段所需的参考资料。对于整个生命周期的请求，首先加载references/lifecycle.md，然后逐步加载阶段参考资料。

请求操作 加载方法、角色、需求分类、客户合作伙伴 将工作锚定在书籍对齐的方法参考/wiegers-beatty-core.md 整个生命周期、端到端的企业案例 运行所有阶段门槛references/lifecycle.md，然后运行阶段参考资料 业务需求、愿景、范围 定义业务需求和项目/发布边界references/lifecycle.md、references/templates.md 利益相关者、用户类、产品冠军、访谈、研讨会 计划和执行需求获取references/elicitation.md 使用案例、用户故事、业务规则、数据、模型、原型、优先级、复用 分析和建模需求references/analysis-modeling.md SRS、优秀的需求编写、功能需求、NFR、接口、约束 草拟或审查需求规范references/srs.md、references/templates.md 审查、检查、验证、接受标准、测试需求 验证需求references/validation.md 基准、版本/状态跟踪、变更请求、影响分析、CCB、可追溯性、工具 管理需求references/management.md 敏捷、增强/替换、打包解决方案、外包、BPA、分析、嵌入式/实时 根据项目类别定制方法references/project-classes.md 合规性、安全性、集成、数据质量、运营、推出、审计 添加企业生产门槛references/enterprise-governance.md 流程改进、需求风险、故障排除 改进或审计需求实践references/process-risk.md 可重用工件形式 使用模板references/templates.md

整个生命周期阶段门槛 业务需求、愿景和范围 产生业务机会/问题、可衡量的业务目标、成功指标、产品愿景、主要功能、范围内、范围外、限制、业务背景、假设、依赖关系和业务风险。 门槛：利益相关者同意产品存在的原因、预期的业务价值和当前版本不会做什么。 用户之声和需求获取 识别利益相关者、用户类、偏爱类、产品冠军/产品负责人结构、决策者、需求获取技术、会议计划