如何执行需求管理？
执行需求管理是为了确保系统和系统要素需求与系统的其他表示、分析和工件保持一致。它包括提供对需求的理解、获得承诺、管理变更、维护需求之间的双向可追溯性以及与系统定义的其余部分，以及与项目资源和进度的一致性。
有许多工具可以为需求管理提供支持基础设施;最好的选择是与项目或企业的过程相匹配的。对于基线管理和控制，需求管理也与配置管理紧密相连。当需求被定义、记录和批准后，需要将它们置于基线管理和控制之下。基线允许项目分析和理解正在进行的建议变更的影响(技术、成本和进度)。
过程方法
方法的目的和原则
系统需求分析过程的目的是将期望的服务和属性的利益攸关方、面向用户的视图转换为满足用户操作需求的产品的技术视图。这个过程构建了一个系统的表示，它将满足利益攸关方的需求，并且只要约束允许，它并不意味着任何具体的实现。它产生了可测量的系统要求，从供应商的角度规定了为了满足利益相关方的要求，系统必须具备哪些性能和非性能特征。
过程的活动
在此过程中主要的活动和任务包括:
v 分析利益攸关方需求，检查预期服务和操作场景、条件、操作模式和约束的完整性。
v 定义系统需求及其基本原理。
v 使用建议的分类对系统需求进行分类(参见上面的例子)。
v 将派生的需求(来自架构和设计)合并到系统需求基线中。
v 建立与利益攸关方需求和需求的向上追溯性。
v 在系统层次结构中相邻层次的需求之间建立双向可追溯性。
v 验证每个系统需求的质量和完整性，以及系统需求集的一致性。
v 根据利益攸关方需求集验证每个系统需求的内容和相关性。
v 识别系统需求可能产生的潜在风险(或威胁和危害)。
v 集成、记录和管理系统需求和潜在的相关风险。
v 在需求得到批准后，建立控制基线以及其他系统定义要素，并结合已建立的配置管理实践。
v 检查系统要求的正确性
应该检查系统需求，以判断它们是否得到了恰当的表达。有许多特征,可用于检查系统需求,如标准的同行评审技术和比较每个需求设置的需求特点,表2和表3中列出的“表示和质量要求”部分(下图)。使用“方法和建模技术”一节中描述的需求捕获和基本原理捕获，可以进一步验证需求。
方法和建模技术
需求捕获和原型设计
需求捕获需要用户的参与，并且可以有效地获得利益攸关方的参与和参与。质量功能展开(QFD)和原型设计是可以应用的两种常见技术，并在本节中定义。此外，访谈、焦点小组和Delphi技术经常用于引出需求。
QFD是一种引出需求并将设计特性与用户需求进行比较的强大技术。QFD应用的输入是用户需求和操作概念，因此用户的参与至关重要。应该包括来自整个生命周期的用户，以确保考虑到用户需求的所有方面并确定优先级。
早期的原型设计可以帮助用户和开发人员交互式地识别功能和操作需求以及用户接口约束。这可以实现真实的用户交互、发现和反馈，以及一些敏感性分析。这提高了用户对需求的理解，并增加了满足他们实际需求的可能性。
捕获需求原理
将利益攸关方需求转换为系统需求的一种强大且经济有效的技术是获取每个需求的基本原理。需求基本原理仅仅是对需求存在的原因、任何假设、相关设计研究的结果或任何其他相关支持信息的陈述。这支持进一步的需求分析和分解。基本原理可以直接在需求数据库中捕获。
这种方法的一些好处包括:
减少所需经费总数- -这一过程有助于查明重复的项目。减少需求数量将减少项目成本和风险。
不良假设的早期暴露
删除设计实现——许多写得很差的利益攸关方需求都是伪装的设计需求，因为客户有意或无意地指定了一个候选实现。
改善与利益攸关方社团的沟通——通过捕获所有利益攸关方需求的基本原理，用户和设计人员之间的沟通得到了极大的改善。)。
建模技术
当需求必须详细或细化时，或者当它们处理利益攸关方需求定义和任务分析期间未考虑到的主题时，可以使用的建模技术包括:
状态图模型(ISO 2011，第8.4节)
场景建模(ISO 2011，第6.2.3.1节)
仿真，原型设计(ISO 2011，第6.3.3.2节)
质量功能展开(INCOSE 2011，第83页)
系统建模语言序列图、活动图、用例、状态机图、需求图(OMG 2010)
操作场景的功能流框图
- 用户评论
