所属章节：

第11章. 软件需求工程

        第2节. 需求获取

需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。需求获取是一件看上去很简单、做起来却很难的事情。需求获取是否科学、准备是否充分，对获取出来的结果影响很大，这是因为大部分用户无法完整地描述需求，而且也不可能看到系统的全貌。因此，需求获取只有通过系统分析师与用户的有效合作才能成功。系统分析师必须建立一个对问题进行彻底探讨的环境，而这些问题与将要开发的系统有关。让用户明确了解，对于某些功能的讨论并不意味着将在系统中实现它。

作为一名系统分析师，掌握各种不同的需求获取技术，并且熟练地在实践中运用它，是十分必要的。本节就一些最常用的需求获取技术进行展开讨论。

11.2.6 需求记录技术

在需求获取的过程中，将会产生大量的信息，系统分析师要将这些信息有条理地记录下来，就需要借助一些工具。在信息系统开发实践中，有时候进行需求获取的人员和进行需求分析的人员不是同一个人或团队，有时候在同一个项目中有多个系统分析师参加需求获取，因此，需要统一需求记录工具，以便让所有人的获取结果是同一口径的。

常用的需求记录工具有任务卡片、场景说明、用户故事和Volere白卡等。

1. 任务卡片

在各种需求记录工具中，任务卡片是一种比较简单的工具，它特别适合对业务活动级的信息收集与整理。常用的任务卡片如图11-2所示：

在图11-2中，各个项目的内容及解释如表11-3所示：

增强版任务卡片在基本任务卡片的基础上，增加了问题点描述和解决方案提示。其中，方案示例是针对问题点，系统需要实现什么样的功能，以便验证这些解决方案是否能够解决用户提出的问题。

2. 场景说明

有时候，系统分析师可能很难总结出子任务和任务变体，因为这需要对任务执行过程进行抽象。此时，系统分析师可以使用场景说明来对用户的描述进行整理，抽象出子任务。简单地理解，场景说明就是用户对其工作场景和过程的详细描述，这些描述将在编写测试用例和用户培训手册中再次用到。

3. 用户故事

用户故事描述了对用户有价值的功能，可包括三个方面内容，分别是：书面描述（用于计划和备忘）、交谈（细化故事）和测试用例（验证故事实现）。用户故事描述的传统形式是手工书写的用户故事卡。系统分析师辅助用户编写，告诉用户所编写的故事是进一步讨论的引子，而不是详细的需求规范。在任何项目中，需要用户团队根据故事的重要性来安排开发工作，回答所有开发问题，编写所有的故事。在编写故事之前应该建立用户角色模型，必须包含对项目成功至关重要的角色，尽量保证所有用户对系统完全满意。

用户故事具有6个基本属性：独立性、可协商性、对用户有价值、可预测性、短小精悍和可测试性。

（1）独立性

尽可能避免故事之间存在依赖关系，因为依赖关系会产生优先级和规划问题。

（2）可协商性

故事是可协商的，不是必须实现的书面合同或者需求。

（3）对用户有价值

确保每个故事对用户有价值的最好方式是让用户编写故事。

（4）可预测性

系统分析师应该能够预测（至少大致猜测）故事的规模，以及实现所需要的工作量。

（5）短小精悍

故事规模对实现有影响，何种故事规模最合适，取决于开发团队的规模和能力，以及技术实现等方面。

（6）可测试性

所编写的故事必须是可测试的。

4. Volere白卡

Volere白卡是一种类似于任务卡片的需求记录工具，其格式如图11-4所示：

用户故事和Volere白卡定位的是最小的需求项，因此在实际应用中会导致量比较大，一般在敏捷方法中使用。

系统分析师在选择需求记录工具时，既可以借鉴现有的模板，也可以根据自己的需要进行扩展或重新定义。另外，选择记录工具时要考虑项目团队所使用的开发方法、用户的实际情况、系统分析师的技能等因素。

至此，“11.2.6 需求记录技术”的全部内容就讲解完了。“11.2 需求获取”的全部内容也都讲解完了。