3.2 与用户沟通获取需求的方法
3.2.1 访谈是最早开始使用的获取用户需求的技术，也是迄今为止仍然广泛使用的需求分析技术。
访谈有两种基本形式,分别是正式和非正式、正式访谈时,系统分析员将提出一些事先准备好的具体问题,例如,询问客户公司销售的商品种类、雇佣的销售人员数目以及信息反时间应该多快等,在非正式访该中,分析员将提出一些用户可以自由答的开放性间题,以鼓励被访问人员说出自己的想法,例如,询间用户对目前正在使用的系统有哪些不满意的地方。
当需要调查大量人员的意见时,向被调查人分发调查表是一个十分有效的做法,经过仔细考虑写出的书面回答可能比被访者对问题的口头回答更准确,分析员仔细阅读收回的调查表,然后再有针对性地访问一些用户,以便向他们询问在分析调查表时发现的新问题。 在访问用户的过程中使用情景分析技术往往非常有数。所谓情景分析就是对用户将来使用目标系统解决某个具体问题的方法和结果进行分折,例如,假设目标系统是一个制定减肥计划的软件,当给出某个肥症患者的年龄、性别、身高、体重,腰围及其他数据时,就出现了一个可能的情景描述。系统分析员根据自己对目标系统应具备的功能的理解,给出适用于该患者的菜单。客户公司的饮食专家可能指出,那些菜单对于有特殊饮食需求的患者(例如,糖尿病人、素食者)是不合适的。这就使分析员认识到,目标系统在制定菜单之前还应该先询间患者的特殊饮食需求。系统分析员利用情景分析技术,往在能够获知用户的具体需求。
情景分析技术的用处主要体现在下述两个方面：
(1) 它能在某种程度上演示目标系统的行为,从而便于用户理解,面且还可能进一步揭示出一些分析员目前不知道的需求。
(2) 由于情景分析较易为用户所理解,使用这种技术能保证用户在需求分析过程中始终扮演一个积极主动的角色,需求分析的目标是获知用户的真实需求,而这一信息的唯一来源是用户,因此,让用户起积极主动的作用对需求分析工作获得成功是至关重要的。
3.2.2 面向数据流自顶向下求精
系统本质上是信息处理系统,而任何信息处理系的基本动能都是把输入数据转变成需要的输出信息,数据决定了需要的处理和算法,看来数据显然是需求分析的出发点。在可行性研究阶段许多实际的数据元素被忽略了,当时分析员还不需要考虑这些细节，现在是定义这些数据元素的时候了。
结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法,通过可行性研究已经得出了目标系统的高层数据流图,需求分析的目标之一就是把数据流和数据定义到元素级,为了达到这个目标,通常从数据流图的输出端看手分析,这是因为系统的基本功能是是产生这些输出，输出数据决定了系统必须具有的最基本的组成元素。
输出数据是由哪些元素组成的呢?通过调查访问不难搞清这个问题,那么,每个输出数据元素又是从哪里来的呢?既然它们是系统的输出,显然它们或者是从外面输人到系使中来的,或者是通过计算由系统中产生出来的。沿数据流图从输出端往输入端回溯,应该能够确定每个数据元素的来源,与此同时也就初步定义了有关的算法。但是,可行性研究阶段产生的是高层数据流图,许多具体的细节没有包括在里面,因此沿数据流图时常常遇到下述问题：为了得到某个数据元素需要用到数据流图中目前还没有的数据元素,或者得出这个数据元素需要用的算法尚不完全清楚,为了解决这些同题,往往需要向用户和其他有关人员请教,他们的回答使分析员对目标系统的认识更深入更具体了,系统中更多的数据元素被划分出来了,更多的算法被清楚了.通常把分析过程中得到的有关数元素的信息记录在数据字典中,把对算法的简明描述记录在IPO图中,通过分析而补充的数据流、数据存储和处理,应该加到数据流图的适当位置上。
必须请用户对上述分析过程中得出的结果仔细地复查,数据流图是帮助复查的极好工具从输入端开始,分析员借助数据流图、数据字典和IPO图向用户解释输入数据是怎样一步一步地转变成输出数据的。这些解释集中反映了通过前面的分析工作分析员所获得的对目标系统认识。这些认识正确吗?有没有遗漏?用户应该注意倾听分析员的报告,并及时正和补充分析员的认识。复查过程验证了已知的元素,补充了未知的元素,填补了文档中的空自。
反复进行上述分析过程,分析员越来越深入地定义了系统中的数据和系统应该完成的功能,为了追更详细的数据流,分析员应该把数据流图扩展到更低的层次。通过功能分解以完成数据流图的细化。
对数据流图细化之后得到一组新的数据流图,不同的系统元素之间的关系变得更清楚了。对这组新的数据流图的分析追踪可能产生新的问题,这些问题的答案可能又在数据字典中增加一些新条目,并且可能导致新的或精化的算法描述,随着分析过程的进展,经过提问和解答的反复循环,分析员越来越深入具体地定义了目标系统,最终得到对系统数据和功能要求的满意解,图3.1粗略地概括了上述分析过程。
1.<———————需要分解——————————3.
1.分析追踪数据流图 ——>2.用户复查——>3.细化数据流图——>不需分解
1.<——有补充修正——— 2.——无补充修正——>3.
3.2.3 简易的应用规格说明技术
使用传统的访谈或面向数据流自顶向下求精方法定义需求时,用户处于被动地位面且往往有意无意地与开发者区分“彼此”。由于不能像同一个团队的人那样齐心协力地识别和精化需求，这两种方法有时并不理想（经常发生误解，还可能遗漏重要的信息）
为了解决上述问题,人们研究出一种面向团队的需求收集法,称为简易的应用规格说明技术,这种方法提用户与开发者密切合作,共同标识问题,提出解决方案要素,商讨不同方案并指定基本需求,今天,简易的应用规格说明技术已经成为信息统领域使用的主流技术。
使用简易的应用现格说明技本分析需求的典型过程下：
首先进行初步的访谈,通过用户对基本问题的回答,初步确定待解决的问题的范围和解决方案,然后开发者和用户分别写出“产品需求”。选定会议的时间和地点,并选举一个负责主持会议的协调人,邀请开发者和用户双方组织的代表出席会议,并在开会前预先把写好的产品需求分发给每位与会者，要求每位与会者在开会的前几天认真审查产品需求,并且列出作为系统环境组成部分的对象、系统将产生的对象以及系统为了完成自己的功能将使用的对象,此外,还要求每位与会者列出操作这些对象或与这些对象交互的服务(即处理或功能),最后还应列出的约束条件(例如,成本、规模、完成日期)和性能标准(例如,速度,容量),并不望每位与会者列出的内容都是毫无遗漏的,但是,看望簧准确地表达出每个人对目标系的认识。
会议开始后,过论的第一个何题是,是否需要这个新产品,一旦大家都同意确实需要这个新产品,每位与会者就应该把他们在会前准备好的列表展示出来供大家讨论。可以把这些列表抄写在大纸钉在墙上,或者写在白板上挂在墙上。理想的情况是,表中每一项都能单独移动,这样就能方便地删除或增添表项,或组合不同的列表。在这个阶段,严格禁止批评与争论。
在展示了每个人针对某个议题的列表之后,大家共同创建一张组合列表。在组合列表中消去了冗余项,加入了在展示过程中产生的新想法,但是并不删除任何实质性内容。在针对每个议题的组合列表都建立起来之后,由协调人主持讨论这些列表。组合列表将缩短,加长或重新措辞,以便更准确地描述将被开发的产品。讨论的目标是,针对每个议题(对象、服务、约束和性能)都创建出一张意见一致的列表。
一旦得出了意见一致的列表,就把与会者分成更小的小组,每个小组的工作目标是为每张列表中的项目制定小型规格说明。小型规格说明是对列表中包含的单词或短语的准确说明。
然后,每个小组都向全体与会者展示他们制定的小型规格说明,供大家讨论。通过讨论可能会增加或删除一些内容，也可能进一步做些精化工作。
在完成了小型规格说明之后,每个与会者都制定出产品的一整套确认标准,并把自己制定的标准提交会议讨论。以创建出意见一致的确认标准,最后，由一名或多名与会者根据会议成果起草完整的软件需求规格说明书。
简易的应用规格说明技术并不是解决需求分析阶段遇到的所有问题的“万能灵药”，但是，这种面向团队的需求收集方法确实有多突出优点,开发者与用户不分彼此,密切合作;即时讨论并求精；有能导出规格说明的具体步骤。
3.2.4 快速建立软件原型
正如第1章已经讲过的,快速建立软件原型是最准确、最有数,最强大的需求分析技术。快速原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。构建原型的要点是,它应该实现用户看得见的功能(例如,屏幕显示或打印报表),省略目标系绕的“隐含”功能(例如,修改文件）
快速原型应该具备的第一个特性是“快速”。快速原型的目的是尽快向用户提供可在计算机上运行的目标系统的模型,以便使用户和开发者在目标系统应该“做什么”这个问题上尽可能快地达成共识,因此,原型的某些缺陷是可以忽略的,只要这些缺陷不严重地损害原型的功能,不会使用户对产品的行为产生误解,就不必管它们。
快速原型应该具备的第二个特性是“容易修改”。如果原型的第一版不是用户所需要的,就必须根据用户的意见迅速地修改它,构建出原型的第二版,以更好地满足用户需求在实际开发软件产品时,原型的“修改一试用一反馈”过程可能重复多遍,如果修改耗时过多,势必延误软件开发时间。为了快速地构建和修改原型,通常使用下述3种方法和工具
(1)第四代技术
第四代技术包括众多数据库查询和报表语言、程序和应用系统生成器以及其他非常高级的非过程语言。第四代技术使得软件工程师能够快速地生成可执行的代码,因此,它们是较理想的快速原型工具
(2)可重用的软件构件
另外一种快速构建原型的方法,是使用一已有的软件构件（也称为组件）来装配（而不是从头构造）原型。软件构件可以是数据结构(或数据库),或软件体系结构构件（即程序），或过程构件（即模块）。必须把软件构件设计成能在不知其内部工作细节的条件下重用。
应该注意,现有的软件可以被用作“新的或改进的”产品的原型。
(3)形式化规格说明和原型环境
在过去的20多年中,人们已经研究出许多形式化格说明语言和工具(符号语言概念),用于替代自然语言规格说明技术。今天,形式化语言的倡导者正在开发交互式环境以便可以调用自动工具把基于形式语言的规格说明翻译成可执行的程序代码,用户能够使用可执行的原型代码去进一步精化形式化的规格说明。
3.3 分析建模与规格说明
3.3.1 分析建概
为了更好地理解复杂事物,人们常富采用建立事物模型的方法,所谓模型,就是为了理解事物面对事物作出的一种抽象,是对事物的一种无歧义的书面描述,通常,概型由一组图形符号和组织这些符号的规则组成。
结构化分析实质上是一种创建模型的活动,为了开发出复杂的软件系统,系统分析员应该从不同角度抽象出目标系统的特性,使用精确的表示方法造系统的模型,验证模型是否满足用户对目标系统的需求,并在设计过程中逐渐把和实现有关的细节加进模型中,直至最终用程序实现模型。
根据本章开头讲述的结构化分析准则,需求分析过程应该建立3种模型,它们分别是数据模型、功能概型和行为模型。
实体一联系图,描绘数据对象及数据对象之的关系,是用于建立数据模型的图形
数据流图,描绘当数据在软件系统中移动时被变换的逻辑过程,指明系统具有的变换数据的功能,因此,数据流图是建立功能模型的基础。
状态转换图(简称为状态图),指明了作为外部事件结果的系统行为，为此,状态转换图描绘了系统的各种行为概式(称为“状态”)和在不同状态间转换的方式。状态转换图是行为建模的基础
3.3.2 软件件需求规说明
通过需求分析除了建分析模型之外,还应该写出件需求规格说明书,它是需求分析阶段得出的最主要的文档。
常用自然语言完整、准确,具体地描述系统的数据要求、功能需求,性能需求、可靠性和可用性要求,出错处理需求,接口需求、约束,逆向需求以及将来可能提出的要求。自然语言的规格说明具有容易书写,容易理解的优点,为大多数人所欢迎和采用。
与了消除用自然语言书写的软件需求规格说明书中可能存在的不一致、歧义、含糊不完整及抽象层次混乱等间题,也有些人主张用形式化方法描述用户对软件系统的需求，即形式化说明技术，待续。
