《软件需求工程（第2版）》一3.4 实地收集需求信息

3.4 实地收集需求信息

在确定了需求的来源和调查对象后，下一步就是实地收集需求信息。实地收集需求信息阶段的任务就是到现场实地调查和与用户交流，收集和理解用户需求信息。在收集需求信息的过程中，可能会遇到一些困难和问题，如怎样进行收集等，这些都是此阶段应该考虑的事情。

3.4.1 实地收集需求信息面临的困难

实地收集需求信息并不是件容易的工作，软件开发人员需要与用户进行充分的交流，听取用户对软件系统的看法和意见。但在与用户交流的过程中并非是十分顺利的，特别是需要用户花费时间来讲解他们的业务流程和工作内容。因此，开发人员往往会遇到如下一些困难：
1）能提出软件需求的用户可能觉得没有充分的时间与开发人员进行交流和讨论，例如，由于用户出差或开会等，会给交流带来一些影响。
2）有时用户希望通过简单的方法和说明，或者通过简单回答开发人员的询问后，软件开发人员就能清楚地理解他们的需求，而不需要花费太多的时间进行讨论等。
3）用户和开发人员只考虑自己的利益，特别是有些用户认为损害了自己的利益，例如，计算机改变了过去传统的工作方式，可能有些不适应。有些用户由于缺乏使用计算机的经验，导致产生畏难情绪。此外，有些用户认为开发软件系统是单位领导层决定的，与自己的关系不大，因而对待需求信息的收集工作采取消极的态度。
4）用户本身不能提出明确的需求，因为用户不一定对人工系统中所涉及的问题有明确的概念和要求，亦即用户对所面临问题的认识是比较笼统的、抽象的、零碎的和随机偶然的。这些认识和想法未经整理便交给开发人员，使得开发人员无法理解和分析。
5）开发人员缺乏用户的业务知识，而用户也缺乏计算机方面的知识（如不知道什么是数据库，什么是OS等），双方在交流中产生许多困难，从而导致收集工作难以进行。

3.4.2 实地调查的步骤

要想获得充分的用户需求信息，就必须实地进行调查并与用户交流，因此，有步骤地进行实地调查也是相当重要的。实地调查通常分为三个步骤。
1）向掌握“全局”的负责人调查。掌握“全局”的负责人包括组织机构的负责人和高层管理人员。这些人比较了解系统的概貌、发展规划和策略等。向他们调查有利于对系统的宏观分析，明确系统的作用范围。他们可以说是目标需求的主要来源。
2） 向部门负责人调查。部门负责人不但熟悉本部门的各项业务和业务流程，也熟悉部门之间的相互关系。这种调查主要了解各部门的业务流程及主要功能需求和非功能需求，以及与其他部门间的接口信息等。
3）向业务人员调查。业务人员熟悉自身工作的处理细节，如具体数据或表格的作用、来源和去向、类型、精度、处理要求和输入/输出的格式等。此调查可获得系统需完成的一些具体功能和性能等方面的需求信息。
上述调查步骤中，步骤2）和步骤3）是一个反复的过程，每次调查之前要制定调查提纲，每次调查要作记录，并交由用户审查核实，以保证需求信息的可靠和准确。

3.4.3 实地收集需求信息的方式

如前所述，获取需求的工作只能通过用户和开发人员间有效的合作和交流才能成功。为了提高合作和交流的效率，需要有较好的交流方式和手段。开发人员与用户的交流可采取如下几种方式。
（1）座谈会的方式
通过会议获得用户需求信息是用户与开发人员交流的一种很好的方式，也是相当常见的方式。召开范围较广的或专题的会议，通过紧凑而集中的讨论可以将用户与开发人员间的合作关系付诸实践。当然，对会议的参加者在人数方面应有所限制，参加人员不宜过多，否则会拖长会议的时间和偏离会议的主题。另外，会议主持人的作用也不容忽视，其对会议能否成功和会议的效率方面有着很大的影响。在每次座谈会中，都必须记录所讨论的内容，并在会后加以整理，然后请参与讨论的用户给予评价和修改。及早并经常进行座谈讨论是成功收集用户需求信息的一个关键途径。不过，值得注意的是，在座谈会上必然会涉及某些细节问题，特别是有些问题的回答需事先做准备。因此，在召开座谈会之前，提前发给参加人员有关座谈会的议题和内容等材料将有助于提高座谈会的效率。
（2）书面咨询的方式
书面咨询的方式是由软件开发人员将所关心的和有待澄清的问题以书面形式提交给用户。通过询问将有助于软件开发人员能更好地理解用户当前的业务过程，并且了解计算机应如何帮助或改进用户的工作。例如，可以提出如下问题请用户回答：
a你所在部门的业务流程是怎样的？
b你所在部门与其他部门的关系是怎样的？
c本部门应产生哪些表格以及这些表格的输入/输出形式是怎样的？
d在业务中使用什么计算方法？
软件开发人员通过理解和分析用户的回答来收集他们的真正需求。除上述提问外，软件开发人员还可在书面咨询中设置一些如何解决问题的提问，例如：
a当某问题发生时，应该如何解决？
b你现在的工作中存在什么问题？如何解决？
c除了正常的情况，还会发生什么异常情况？该如何应对？
（3）利用用例表示方法

 用例是了解用户的业务流程和澄清含糊细节的好方法。用例用于描述软件系统与一个外部“执行者”的交互顺序，主要体现执行者完成一次任务的过程。一个用例可以包括与完成一项任务逻辑相关的许多任务和交互顺序。执行者可以是一个人、一个应用软件系统或一个硬件，或其他一些与系统交互以实现某些目标的实体等。该方法可利用图形或自然语言描述用户需要完成的所有任务，然后从中分析出用户的功能需求等。从理论上来讲，如果能收集到用户业务的全部用例，则这些用例中将必然包含所有合理的用户需求功能。有关如何使用该方法，以及该方法的一些具体细节将在后面给予说明。

3.4.4 需求信息的分类

对于一个复杂的软件系统，通过收集而得到的用户需求信息是相当庞大和复杂的，特别是这些需求信息中哪些是功能需求，哪些是性能需求等，必须通过大量的分析和整理工作才能弄清楚。开发人员不能指望用户提供一份简洁的、完整的和清晰的需求清单，而必须把收集到的全部需求信息分成不同的类型后，一方面为编制需求规格说明和其他文档等提供基本材料，另一方面也为删除一些不是真正需求的信息提供依据。
因此，给出需求信息的类型是一项重要的工作。通常，需求信息可大致分类如下［14］：
1）目标需求：描述用户或开发机构通过产品可获得的利益和利润，以及与产品相关的发展规划等方面的信息。例如“每年可获利润多少元”或“可节省多少成本”等。
2）用例说明：有关如何利用系统完成业务任务或如何实现用户目标的陈述可能就是用例，而特定的任务描述更需使用用例说明。与客户一起商讨，可把特定的任务概括成更广泛的使用实例，还可以通过让客户描述他们的业务工作流程活动来获取使用实例。
3）业务规则：当一个客户说一些活动只能在特定的条件下由一些特定的人来完成时，该用户可能在描述一个业务规则。例如，“某工厂所需的生产材料只能通过本工厂的采购部门采购”。业务规则是有关业务过程的操作原则。可以用一些软件功能需求来加强规则，正如上面所说的，这里的业务规则不是功能需求。
4）功能需求：客户所说的诸如“用户应该能<执行某些功能>”或者“系统应该<具备某些行为>”，是最可能的功能需求。功能需求描述了系统所展示的可观察的行为，大多数是处于执行者 系统响应顺序的环境中。功能需求定义了系统应该做什么，它们是软件需求规格说明的一部分。分析者应该明确，每个人应该理解系统为什么“必须”执行某一功能。所提出的功能需求有时反映了过时的或无效的业务过程，而这些过程不能加入到新系统中。
5）性能需求：对系统如何能很好地执行某些行为或让用户采取某一措施的陈述就是性能需求，这是一种非功能需求。听取那些描述合理特性的意见：快捷、简易、直觉性、用户友好、健壮性、可靠性、安全性和高效性等。这需要和用户一起商讨，并精确定义这些需求的真正含义。
6）外部接口需求：这类需求描述了系统与外部的联系。软件需求规格说明必须包括用户接口和通信机制、硬件和其他软件系统需求部分。客户描述外部接口需求包括如下习惯用语：
“从<某些设备>读取信号”
“给<一些其他系统>发送消息”
“以<某种格式>读取文件”
“能控制<一些硬件>”
7） 限制：限制是指一些合理限制设计者和程序员选择的条件。它们代表了另一种类型的非功能需求，必须把这些需求写入软件需求规格说明。尽量防止客户施加不必要的限制，因为这将妨碍提出一个好的解决方案。不必要的限制将会降低利用现有商业化软件集成解决方案的能力，一定的限制有助于提高产品质量。下面是客户描述限制的一些习惯用语：
“必须使用<一个特定的数据库产品或语言>”
“不能申请多于<一定数量的内存>”
“操作必须与<其他系统>相同”
“必须与<其他应用程序>一致”
8） 数据定义： 当客户描述一个数据项或一个复杂的业务数据结构的格式、允许值或默认值时，就是在进行数据定义。例如，“邮政编码由5个数字组成，后跟一个可选的短划线或一个可选的四位数字，默认为0000”就是一个数据定义。把这些集中在一个数据词典中，作为项目的参与者在整个项目的开发和维护中的主要参考文档。
9） 解决方案： 如果一个客户描述了用户与系统交互的特定方法，使系统产生一系列活动（例如用户从某菜单中选择一个所需要的项），这时，你就是在听取建议性的解决方案，而不是需求。所建议的解决方案使获取需求小组成员在潜在的真正需求上分散精力。在获取需求时，应该把重点放在需要做什么，而不是新系统应该如何设计和构造上。探讨客户为什么提出一个特定的实现方法，可以帮助你理解真正的需求和用户对如何构造系统的隐含期望。