1 访谈
      访谈是最早开始使用的获取用户需求的技术，也是迄今为止仍然广泛使用的需求分析技术。
      访谈有两种基本形式，分别是正式的和非正式的访谈。正式访谈时，系统分析员将提出一些事先准备好的具体问题，例如，询问客户公司销售的商品种类、雇用的销售人员数目以及信息反馈时间应该多快等。在非正式访谈中，分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法，例如，询问用户对目前正在使用的系统有哪些不满意的地方。
       当需要调查大量人员的意见时，向被调查人分发调查表是一个十分有效的做法。经过仔细考虑写出的书面回答可能比被访者对问题的口头回答更准确。分析员仔细阅读收回的调查表，然后再有针对性地访问一些用户，以便向他们询问在分析调查表时发现的新问题。
       在访问用户的过程中使用情景分析技术往往非常有效。所谓情景分析就是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。例如，假设目标系统是一个制定减肥计划的软件，当给出某个肥胖症患者的年龄、性别、身高、体重、腰围及其他数据时，就出现了一个可能的情景描述。系统分析员根据自己对目标系统应具备的功能的理解，给出适用于该患者的菜单。客户公司的饮食专家可能指出，那些菜单对于有特殊饮食需求的患者（例如，糖尿病人、素食者）是不合适的。这就使分析员认识到，目标系统在制定菜单之前还应该先询问患者的特殊饮食需求。系统分析员利用情景分析技术，往往能够获知用户的具体需求。

       情景分析技术的用处主要体现在下述两个方面。
       （1）它能在某种程度上演示目标系统的行为，从而便于用户理解，而且还可能进一步揭示出一些分析员目前还不知道的需求。
       （2）由于情景分析较易为用户所理解，使用这种技术能保证用户在需求分析过程中始终扮演一个积极主动的角色。需求分析的目标是获知用户的真实需求，而这一信息的唯一来源是用户，因此，让用户起积极主动的作用对需求分析工作获得成功是至关重要的。

2 面向数据流自顶向下求精
       软件系统本质上是信息处理系统，而任何信息处理系统的基本功能都是把输入数据转变成需要的输出信息。数据决定了需要的处理和算法，看来数据显然是需求分析的出发点。在可行性研究阶段许多实际的数据元素被忽略了，当时分析员还不需要考虑这些细节，现在是定义这些数据元素的时候了。
       结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。通过可行性研究已经得出了目标系统的高层数据流图，需求分析的目标之一就是把数据流和数据存储定义到元素级。为了达到这个目标，通常从数据流图的输出端着手分析，这是因为系统的基本功能是产生这些输出，输出数据决定了系统必须具有的最基本的组成元素。
       输出数据是由哪些元素组成的呢？通过调查访问不难搞清这个问题。那么，每个输出数据元素又是从哪里来的呢？既然它们是系统的输出，显然它们或者是从外面输入到系统中来的，或者是通过计算由系统中产生出来的。沿数据流图从输出端往输入端回溯，应该能够确定每个数据元素的来源，与此同时也就初步定义了有关的算法。但是，可行性研究阶段产生的是高层数据流图，许多具体的细节没有包括在里面，因此沿数据流图回溯时常常遇到下述问题：为了得到某个数据元素需要用到数据流图中目前还没有的数据元素，或者得出这个数据元素需要用的算法尚不完全清楚。为了解决这些问题，往往需要向用户和其他有关人员请教，他们的回答使分析员对目标系统的认识更深入更具体了，系统中更多的数据元素被划分出来了，更多的算法被搞清楚了。通常把分析过程中得到的有关数据元素的信息记录在数据字典中，把对算法的简明描述记录在IPO图中。通过分析而补充的数据流、数据存储和处理，应该添加到数据流图的适当位置上。

       必须请用户对上述分析过程中得出的结果仔细地复查,数据流图是帮助复查的极好工具。从输人端开始,分析员借助数据流图、数据字典和IP)图向用户解释输人数据是怎样一步一步地转变成输出数据的。这些解释集中反映了通过前面的分析工作分析员所获得的对目标系统的认识。这些认识正确吗?有没有遗漏?用户应该注意倾听分析员的报告,并及时纠正和补充分析员的认识。复查过程验证了已知的元素,补充了未知的元素,填补了文档中的空白。
       反复进行上述分析过程,分析员越来越深人地定义了系统中的数据和系统应该完成的功能。为了追踪更详细的数据流,分析员应该把数据流图扩展到更低的层次。通过功能分解可以完成数据流图的细化。
       对数据流图细化之后得到一组新的数据流图,不同的系统元素之间的关系变得更清楚了。对这组新数据流图的分析追踪可能产生新的问题,这些问题的答案可能又在数据字典中增加一些新条目,并且可能导致新的或精化的算法描述。随着分析过程的进展,经过提问和解答的反复循环,分析员越来越深人具体地定义了目标系统,最终得到对系统数据和功能要求的满意了解。图粗略地概括了上述分析过程。

3 简易的应用规格说明技术
       使用传统的访谈或面向数据流自顶向下求精方法定义需求时,用户处于被动地位而且往往有意无意地与开发者区分“彼此”。由于不能像同一个团队的人那样齐心协力地识

面向数据量自顶向下求精过程

别和精化需求,这两种方法的效果有时并不理想(经常发生误解,还可能遗漏重要的
信息)。
       为了解决上述问题,人们研究出一种面向团队的需求收集法,称为简易的应用规格说明技术。这种方法提倡用户与开发者密切合作,共同标识问题,提出解决方案要素,商讨不同方案并指定基本需求。今天,简易的应用规格说明技术已经成为信息系统领域使用的主流技术。
       使用简易的应用规格说明技术分析需求的典型过程如下:
       首先进行初步的访谈,通过用户对基本问题的回答,初步确定待解决的问题的范围和解决方案。然后开发者和用户分别写出“产品需求”。选定会议的时间和地点,并选举一个负责主持会议的协调人。邀请开发者和用户双方组织的代表出席会议,并在开会前预先把写好的产品需求分发给每位与会者。
       要求每位与会者在开会的前几天认真审查产品需求,并且列出作为系统环境组成部分的对象、系统将产生的对象以及系统为了完成自己的功能将使用的对象。此外,还要求每位与会者列出操作这些对象或与这些对象交互的服务(即处理或功能)。最后还应该列出约束条件(例如,成本、规模、完成日期)和性能标准(例如,速度、容量)。并不期望每位与会者列出的内容都是毫无遗漏的,但是,希望能准确地表达出每个人对目标系统的认识。
       会议开始后,讨论的第一个问题是,是否需要这个新产品,一旦大家都同意确实需要这个新产品,每位与会者就应该把他们在会前准备好的列表展示出来供大家讨论。可以把这些列表抄写在大纸上钉在墙上,或者写在白板上挂在墙上。理想的情况是,表中每一项都能单独移动,这样就能方便地删除或增添表项,或组合不同的列表。在这个阶段,严格禁止批评与争论。

       在展示了每个人针对某个议题的列表之后,大家共同创建一张组合列表。在组合列
表中消去了冗余项,加入了在展示过程中产生的新想法,但是并不删除任何实质性内容。
在针对每个议题的组合列表都建立起来之后,由协调人主持讨论这些列表。组合列表将被缩短、加长或重新措辞,以便更准确地描述将被开发的产品。讨论的目标是,针对每个议题(对象、服务、约束和性能)都创建出一张意见一致的列表。
       一旦得出了意见一致的列表,就把与会者分成更小的小组,每个小组的工作目标是为每张列表中的项目制定小型规格说明。小型规格说明是对列表中包含的单词或短语的准确说明。
       然后,每个小组都向全体与会者展示他们制定的小型规格说明,供大家讨论。通过讨论可能会增加或删除一些内容,也可能进一步做些精化工作。
       在完成了小型规格说明之后,每个与会者都制定出产品的一整套确认标准,并把自己制定的标准提交会议讨论,以创建出意见一致的确认标准。最后,由一名或多名与会者根据会议成果起草完整的软件需求规格说明书。
       简易的应用规格说明技术并不是解决需求分析阶段遇到的所有问题的“万能灵药”,但是,这种面向团队的需求收集方法确实有许多突出优点:开发者与用户不分彼此,齐心协力,密切合作;即时讨论并求精;有能导出规格说明的具体步骤。

3.2.4 快速建立软件原型
       正如第1章已经讲过的,快速建立软件原型是最准确、最有效、最强大的需求分析技术。快速原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。构建原型的要点是,它应该实现用户看得见的功能(例如,屏幕显示或打印报表),省略目标系统的“隐含”功能(例如,修改文件)。
       快速原型应该具备的第一个特性是“快速”。快速原型的目的是尽快向用户提供一个可在计算机上运行的目标系统的模型,以便使用户和开发者在目标系统应该“做什么”这个问题上尽可能快地达成共识。因此,原型的某些缺陷是可以忽略的,只要这些缺陷不严重地损害原型的功能,不会使用户对产品的行为产生误解,就不必管它们。
       快速原型应该具备的第二个特性是“容易修改”。如果原型的第一版不是用户所需要的,就必须根据用户的意见迅速地修改它,构建出原型的第二版,以更好地满足用户需求。在实际开发软件产品时,原型的“修改一试用一反馈”过程可能重复多遍,如果修改耗时过多、势必延误软件开发时间。
       为了快速地构建和修改原型,通常使用下述3种方法和工具。
       (1) 第四代技术
       第四代技术包括众多数据库查询和报表语言、程序和应用系统生成器以及其他非常高级的非过程语言。第四代技术使得软件工程师能够快速地生成可执行的代码,因此,它们是较理想的快速原型工具。
       (2) 可重用的软件构件
       另外一种快速构建原型的方法,是使用一组已有的软件构件(也称为组件)来装配(而
不是从头构造)原型。软件构件可以是数据结构(或数据库),或软件体系结构构件(即程
序),或过程构件(即模块)。必须把软件构件设计成能在不知其内部工作细节的条件下
重用。
       应该注意,现有的软件可以被用作“新的或改进的”产品的原型。
       (3) 形式化规格说明和原型环境
       在过去的20多年中,人们已经研究出许多形式化规格说明语言和工具, 用于替代自然语言规格说明技术。今天,形式化语言的倡导者正在开发交互式环境, 以便可以调用白动工具把基于形式语言的规格说明翻译成可执行的程序代码,用户能够使用可执行的原型代码去进一步精化形式化的规格说明。