【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. 选择合适的开发周期
难度中 影响低
1. 维护需求变更的历史记录
记录需求规格说明变更的日期、变更的内容、变更的实施者和原因。
2. 跟踪投入需求工程的工作量
使用这些数据来评定计划的需求活动是否如期完成，利用这些数据还可以为将来的项目更好的计划所需的资源。有助于评估对需求工程的投资和回报。
难度低 影响高
1. 在应用领域培养开发者
帮助开发人员对应用领域有一个基本的理解。这样可以减少开发过程中的混淆、误解和返工。
2. 定义项目前景和范围
前景（vision）说明使所有涉众可以对产品的目标达成共识。
范围（scope）则定义了需求是否属于某个特定版本的界线。
3. 用户群分类
将产品的用户分成组，已避免出现某一用户群的需求被忽略的情况。
4. 绘制关联图
关联图是显示新系统如何适应环境的一个简单的分析模型。定义了正在开发的系统和系统的外部实体（如用户、硬件设备和其他信息系统）之间的界线和接口。
5. 确定需求来源
为保证所有涉众都明白SRS中为何包括这些需求，以及便于进一步阐明需求。可以通过使用跟踪链或定义需求属性来确定需求来源。
6. 建立需求基线和控制版本
基线是已经被提交到一个指定版本中的实现（implementation）的需求组成的，在需求被定为基线后，只能通过定义的变更控制过程来实现变更。使用合适的配置管理工具，将需求文档置于版本控制之下。
难度低 影响中
1. 分析可行性
在允许的成本和性能的要求下，分析在指定的运行环境下实现每项需求的可行性，明确与每项需求实现相关的风险，包括与其他需求之间的冲突、对外界因素的依赖以及技术上的障碍。
2. 创建术语表
定义应用领域专业名称的术语表可以减少误解。
3. 编写数据字典
数据字典中包括系统用到的所有数据项和结构的定义。使参与项目开发的每个人都使用统一的数据定义。方便客户和开发团队之间的交流。
4. 观察用户执行工作的过程
能够确定用户对新的应用程序可能有哪些应用。可以通过一张简单的工作流程图（最好用数据流程图）来描绘用户什么时候拥有什么数据，以及怎样使用这些数据。
5. 确定系统事件和响应
列出系统可能发生的外部事件以及对每个事件所期待的响应。
6. 为每项需求注上唯一的标号
这种规约（标号）应该很健全，经得起随时间推移发生的对需求的增加、删除和修改。为需求标号使得需求可以被跟踪，其变更可以被记录。
7. 测试需求
根据用户需求推导出测试用例，以便记录产品在特定条件下应有的行为。与客户一起对用例进行走查，已确保它们反映了所期望的系统行为。每项需求都应有其对应的测试用例。
8. 跟踪需求状态
建立一个数据库，为每一项功能的需求保存一条记录。保存每项需求的重要属性，包括需求的状态。
9. 从其他项目的需求工程中积累经验
难度低 影响低
1. 检查问题报告
客户的问题包括及补充为需求提供了很多建议，提出在新产品或新版本中应添加哪些功能。
