【IT168 技术文章】
花了一天的时间，整理了下需求工程方面的有关方法。并对这些方法的实现难易度以及效果进行了分类。供大家参考讨论
影响高 难度高
1. 定义需求开发过程
将你的组织如何获取和分析需求、编写规格说明和验证需求的步骤编写成文档。可以帮助分析员做好工作，还能够使规划项目的需求开发任务、进度和所需的资源变得更为容易。
2. 以需求为基础指定计划
当范围和详细的需求变得清楚时，应反复斟酌项目的计划和进度表。
3. 需求变更时重新讨论项目承诺
当将新的需求合并到项目中时，如果不能兑现当前的进度和质量承诺，应将项目的实际情况报告给管理层，协商制定新的、可行的承诺
难度高 影响中
1. 对用户和管理者进行需求培训
培训可使他们明白重视需求的意义；需求活动包括哪些活动，要提交什么样的结果；忽略需求过程会导致什么风险。
2. 为需求建立模型
模型能够揭示不正确的、不一致的、遗漏的或冗余的需求。这类模型包括数据流图、实体关系图、状态转换图或状态图、对话图、类图、序列图、交互作用图、决策表和决策树等。
3. 管理需求风险以及编写需求文档
可组织自由讨论，找到方法来减轻或避免这些风险。实施减少风险的活动，以及跟踪它们的进程和效果。
4. 使用需求管理工具
商业需求管理工具可用于在数据库中存储各种类型的需求。可以为每项需求定义属性，跟踪每项需求的状态，并在需求和其他软件开发产品间建立跟踪链。
5. 创建需求跟踪能力矩阵
建立一个表，把每项功能需求和实现它的设计和代码部分、验证它的测试部分联系起来。需求跟踪矩阵还能把功能需求和产生它的高层需求以及其他相关需求联系起来。
6. 召开需求获取讨论会
方便分析员和客户进行交流。是研究用户需求、编写需求文档的一种十分有效的途径、包括联合需求计划（Joint Requirements Planning，JRP）会议和联合应用程序开发（Joint Application Development，JAP）会议。
难度高 影响低
1. 重用需求
多个项目可以重用那些符合一个组织的业务规则的需求。
2. 应用质量功能调配
质量功能调配（QFD）将产品功能、属性与客户的重要性联系起来。该技术提供了一种分析方法以明确哪些功能最能满足客户的需要。QFD将需求分为3类：期望需求——客户或许并未提及，但若缺少却会让他们感到不满意的需求；普通需求；额外需求。
3. 衡量需求的稳定性
记录成为基线的需求数，以及每周提议和批准的需求的变更数。过多的需求变更，意味着问题并未真正弄清楚，项目范围没有明确定义，业务规则变化过快，需求获取过程漏掉了很多需求，或政策变化太快。
难度中 影响高
1. 确定用例
与用户代表沟通、了解他们需要使用软件来完成的任务——用例。讨论用户与系统之间的交互方式。在编写用例文档时采用标准模板，并根据这些用例推导出功能需求。
2. 指定质量属性
包括性能、效率、可靠性、可用性等。应该写入SRS文档。
3. 确定需求优先级
在项目的整个开发过程中，应定期评估和调整优先级。
4. 采用SRS模板
为组织定义一个标准模板用于编写软件需求规约。该模板为记录功能说明和其他与需求相关的信息提供了统一的结构。
5. 定义变更控制过程
建立一个用于提议、分析和解决需求变更的过程。通过这个过程管理所有提议的变更。
6. 建立CCB
变更控制委员会（Change Control Board CCB）
7. 审查需求文档
保证软件质量的有效手段之一。应由代表不同群体（如分析员、客户、开发人员和测试人员）的审查员组成审查小组，对SRS分析模型和相关信息进行检查，找出其中的缺陷和漏洞。
8. 将需求分解到子系统
9. 记录业务规则
包括公司章程、政府法规和计算机算法。
难度中 影响中
1. 培训需求分析员
所有将要成为需求分析员的团队成员都应该接受需求工程方面的基本培训。熟练的需求分析员应具备以下特点：
耐心，思维条理性强，有良好的交际和沟通能力，理解产品应用领域，并且掌握丰富的需求工程技术。
2. 为每类用户选择代言人
用户代言人提供某一类用户的需求，并代表他们作出决策。
3. 建立核心队伍
把产品早期版本或同类产品的用户代表召集起来，收集他们对正在开发的产品功能和质量特性的意见。
4. 创建原型（用户界面和技术原则）
使概念和可能性变得更为直观明了。
5. 定义合格标准
让用户决定产品是否满足他们的需求并适合使用的标准。以使用情况为基础进行合格性测试。
6. 进行变更影响分析
有助于CCB作出明确的业务决策。可参照需求跟踪矩阵找出其他可能需要修改的需求、设计元素、源代码和测试用例。应确定实现变更需要完成的任务，并评估完成这些任务所需的工作量。
7. 选择合适的开发周期
