4.2.2　需求获取方式

为了提高合作和交流的效率，需要有较好的交流方式和手段给予支持。开发人员与用户的交流可采取座谈会、书面咨询和用例表示法等方法。

1.座谈会方式

通过会议获得用户需求信息是用户与开发人员交流的一种常见方式，召开范围较广或专题会议，通过紧凑而集中的讨论可以将用户与开发人员间的合作关系付诸实践。对会议的参加者在人数方面应有所限制，参加人员不宜过多，否则会拖延会议的速度，偏离会议的主题。会议主持人的作用也不容忽视，其对会议能否成功和会议的效率方面有很大的影响。在每次座谈会中，都必须记录所讨论的内容，并在会后加以整理，然后请参与讨论的用户给予评价和修改，及早并经常进行座谈讨论是成功收集用户需求信息的一个关键途径。值得注意的是，在座谈会上必然会涉及某些细节问题，特别是有些问题的回答须事先做准备，在召开座谈会之前，提前发给参加人员有关座谈会的议题和内容等材料将有助于提高座谈会的效率。

2.书面咨询的方式

书面咨询的方式是由软件开发人员将所关心的、有待澄清的问题以书面形式提交给用户，例如，可以提出如下问题请用户回答：

（1）你所在部门的业务流程是怎样的？

（2）你所在部门与其他部门的关系是怎样的？

（3）本部门应产生哪些表格？这些表格的输入/输出形式是怎样的？

（4）在业务中使用什么计算方法？

（5）当某问题发生时，应该如何解决？

（6）你现在的工作中存在什么问题？如何解决？

（7）除了正常的情况，还会发生什么异常情况？该如何应对？

通过询问有助于软件开发人员更好地理解用户当前的业务过程，了解应如何帮助用户或改进对用户所做的工作。

3.用例表示方法

用例表示法是了解用户的业务流程和澄清含糊细节的好方法，可通过用例图建立需求模型。首先，确定系统边界，找出参与者，确定用例，画出用例图，针对每一个用例写出用例规约，并完成补充规约。系统边界即是面对的问题领域，站在边界外的是参与者，边界内的是用例，明确系统边界很重要，它决定了用户对系统的视角和能够得出的结果。参与者是处于系统边界之外并与系统进行交互的人、设备或外部系统；用例用于描述软件系统与一个外部“执行者”的交互顺序，主要体现执行者完成一次任务的过程。一个用例可以包括与完成一项任务逻辑相关的许多任务和交互顺序，执行者可以是一个人、一个应用软件系统、一个硬件，或其他一些与系统交互以实现某些目标的实体等，用例规格的书写应包括：用例名称、执行者、用例描述、前置条件、后置条件、基本事件流、异常事件流、备注等。

该方法可利用图形或自然语言描述用户需要完成的所有任务，然后从中分析出用户的功能需求、性能需求及约束等。