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