|
|
|
在需求分析阶段，主要考查需求分析的目的和任务、数据流图、结构化分析方法、需求分析的成果及软件规格说明书（软件需求说明书）等。
|
|
|
|
|
|
需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其他系统元素的接口细节，定义软件的其他有效性需求，细化软件要处理的数据域。用一句话概括就是：需求分析主要确定开发软件的功能、性能、数据和界面等要求。需求分析的实现步骤通常包括3个部分，分别是获取当前系统的物理模型，抽象出当前系统的逻辑模型，以及建立目标系统的逻辑模型。
|
|
|
|
|
|
具体来说，需求分析阶段的工作可以分成以下4个方面。
|
|
|
|
（1）问题识别。用于发现需求，描述需求，主要包括功能需求、性能需求、环境需求、可靠性需求、安全保密需求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求，并预先估计以后系统可能达到的目标。
|
|
|
|
（2）分析与综合。也就是对问题进行分析，然后在此基础上整合出解决方案。这个步骤经常是反复进行的，常用的方法有面向数据流的结构化分析方法，面向数据结构的Jackson方法，面向对象的分析方法，以及用于建立动态模型的状态迁移图和Petri网。
|
|
|
|
（3）编制需求分析的文档。也就是对已经确定的需求进行文档化描述，该文档通常称为软件需求说明书（需求规格说明书）。
|
|
|
|
（4）需求分析与评审。它是需求分析工作的最后一步，主要是对功能的正确性、完整性和清晰性，以及其他需求给予评价。
|
|
|
|
|
|
|
|
|
|
|
|
（3）必须划分描述信息、功能和行为的模型，从而可以以层次的方式揭示细节。
|
|
|
|
|
|
（5）必须按自顶向下、逐层分解的方式对问题进行分解和不断细化。
|
|
|
|
|
|
通过应用这些原则，系统分析员可以系统地处理某些问题，包括检查信息域以使得功能可以被更完整地理解，使用模型以使得可以以简捷的方式交流功能和行为的特征，应用划分以减少问题的复杂性等。在这些处理过程中，软件的要素和视图实现由处理需求带来的逻辑约束与由其他系统元素带来的物理约束是必需的。
|
|
|
|
|
|
什么是软件的需求呢？软件需求就是系统必须完成的事，以及必须具备的品质。具体来说，软件需求包括功能需求、非功能需求和设计约束三个方面的内容。
|
|
|
|
（1）功能需求。是指系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作。
|
|
|
|
（2）非功能需求。是指产品必须具备的属性或品质，如可靠性、性能、响应时间、容错性及扩展性，等等。
|
|
|
|
（3）设计约束。也称为限制条件、补充规约，这通常是对解决方案的一些约束说明，例如必须采用国有自主知识版权的数据库系统，必须运行在UNIX操作系统之下等。
|
|
|
|
除了这三种需求之外，还有业务需求、用户需求和系统需求这三个处于不同层面下的概念，充分理解这些需求才能够更加清晰地理清需求的脉络。
|
|
|
|
（1）业务需求。是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求。
|
|
|
|
（2）用户需求。是指描述用户使用产品必须要完成什么任务、怎么完成的需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，然后建立的从用户角度的需求。
|
|
|
|
（3）系统需求。是从系统的角度来说明软件的需求，它包括了用特性说明的功能需求，质量属性及其他非功能需求，还有设计约束。
|
|
|
|
我们经常围绕着“功能需求”来展开工作，而功能需求大部分都是从“系统需求”的角度来分析与理解的，也就是用“开发人员”的视角来理解需求。但要想真正地得到完整的需求，仅戴上“开发人员”的眼镜是不够的，还需要“领域专家”的眼镜，从更高的角度来理解需求，这就是“业务需求”。同时还应该更好地深入用户，了解他们的使用场景，了解他们的所思所想，这就是“用户需求”。这是一个理解层次的问题，并不仅仅是简单的概念。
|
|
|
|
|
|
需求工程就是包括创建和维护系统需求文档所必需的一切活动的过程，也就是指需求开发和需求管理两大工作。
|
|
|
|
（1）需求开发。包括需求捕获、需求分析、编写规格说明书和需求验证4个阶段。在需求开发阶段需要确定产品所期望的用户类型、获取每种用户类型的需求、了解实际的用户任务和目标，以及这些任务所支持的业务需求。同时还包括分析源于用户的信息、对需求进行优先级分类、将所收集的需求编写成为软件规格说明书和需求分析模型，以及对需求进行评审等工作。
|
|
|
|
（2）需求管理。通常包括定义需求基线、处理需求变更及需求跟踪等方面的工作。
|
|
|
|
这两个方面是相辅相成的，需求开发是主线，是目标；需求管理是支持，是保障。换句话来说，需求开发是努力更清晰、更明确地掌握客户对系统的需求；而需求管理则是对需求的变化进行管理的过程。
|
|
|
|
|
|
（1）在开始建立分析模型前先理解问题。人们通常总存在急于求成的倾向，甚至在问题被很好地理解前就已开始建模，这经常会导致产生一个解决错误的问题。
|
|
|
|
（2）开发原型，使得用户能够了解将如何发生人机交互。因为人们对软件质量的感觉经常基于对界面“友好性”的感觉，所以强力推荐使用原型方法（以及相应产生的迭代）。
|
|
|
|
（3）记录每个需求的起源及原因，这是建立回溯到客户的可追踪性的第一步。
|
|
|
|
（4）使用多个需求视图。建立数据、功能和行为模型，为软件工程师提供三种不同的视图，这将减少忽视某些东西的可能性，并增加识别不一致性的可能性。
|
|
|
|
（5）给需求赋予优先级。过短的时限可能使每个软件需求得以实现的可能性减小，如果采用增量模型，则必须标识那些将在第一个增量中要交付的需求。
|
|
|
|
（6）努力删除含糊性。因为大多数需求以自然语言描述，存在含糊性的可能，正式的技术复审是发现并删除含糊性的一种方法。
|
|
|
|
|
|
需求分析的方法种类繁多，不过如果按照分解的方式不同，可以很容易地划分出几种大类型。下面从分析方法发展的历史开始，对其建立一个概要性的认识。
|
|
|
|
（1）结构化分析方法。最初的分析方法都不成体系，而且通常都只包括一些笼统的告诫，在20世纪70年代，分析技术发展的分水岭终于出现了。这时人们开始尝试使用标准化的方法，开发和推出各种名为“结构化分析”的方法论，而Tom DeMacro则是这个领域最有代表性和权威性的专家。
|
|
|
|
（2）软系统方法。这是一个过渡性的方法论，并未真正流行过，它的出现只是证明了结构化分析方法的一些不足。因为结构化分析方法采用的相对形式化的模型不仅与社会观格格不入，而且在解决“不确定性”时显得十分无力。最有代表性的软系统方法是Checkland方法。
|
|
|
|
（3）面向对象分析方法（Object Oriented Analysis，OOA）。在20世纪90年代，结构化方法在面对多变的商业世界时显得更加苍白无力，这就催生了OOA的迅速发展。
|
|
|
|
（4）面向问题域的分析（Problem Domain Oriented Analysis，PDOA）。现在又发现面向对象分析方法也存在着很多的不足，从而应运而生了一些新的方法论，PDOA就是其中的一种。不过它现在还在研究阶段，并未广泛应用。
|
|
|
|
|
|
数据流图（Data Flow Diagram，DFD）是结构化分析中的重要方法和工具，是表达系统内数据的流动并通过数据流描述系统功能的一种方法。数据流图还可被认为是一个系统模型，在信息系统开发中，一般将它作为需求说明书的组成部分。
|
|
|
|
数据流图从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况来说明系统所完成的功能。具体来说，数据流图的主要作用如下：
|
|
|
|
（1）数据流图是理解和表达用户需求的工具，是系统分析的手段。由于数据流图简明易懂，理解它不需要任何计算机专业知识，因此通过它同客户交流很方便。
|
|
|
|
（2）数据流图概括地描述了系统的内部逻辑过程，是系统分析结果的表达工具，因而也是系统设计的重要参考资料，是系统设计的起点。
|
|
|
|
（3）数据流图作为一个存档的文字材料，是进一步修改和充实开发计划的依据。
|
|
|
|
在数据流图中，通常会出现4种基本符号，分别是数据流、加工、数据存储和外部实体（数据源及数据终点）。数据流是具有名字和流向的数据，在数据流图中用标有名字的箭头表示。加工是对数据流的变换，一般用圆圈表示。数据存储是可访问的存储信息，一般用直线段表示。外部实体是位于被建模的系统之外的信息生产者或消费者，是不能由计算机处理的成分，它们分别表明数据处理过程的数据来源及数据去向，用标有名字的方框表示。下图是一个典型的数据流图示例。
|
|
|
|
|
|
|
|
为了表达数据处理过程中的数据加工情况，用一个数据流图是不够的。稍微复杂的实际问题，在数据流图中常常出现十几个甚至几十个加工。这样的数据流图看起来很不清楚。层次结构的数据流图能很好地解决这一问题。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达整个系统。对任何一层数据流图来说，称它的上层图为父图，在它下一层的图则称为子图。
|
|
|
|
概括地说，画数据流图的基本步骤就是“自顶向下，逐层分解”。检查和修改的原则如下。
|
|
|
|
（1）数据流图中的所有图形符号只限于前述4种基本图形元素。
|
|
|
|
（2）顶层数据流图必须包括前述4种基本元素，缺一不可。
|
|
|
|
（3）顶层数据流图中的数据流必须封闭在外部实体之间。
|
|
|
|
（4）每个加工至少有一个输入数据流和一个输出数据流。
|
|
|
|
（5）在数据流图中，需按层给加工框编号。编号表明了该加工处在哪一层，以及上下层的父图与子图的对应关系。
|
|
|
|
（6）规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。
|
|
|
|
（7）可以在数据流图中加入物质流，帮助用户理解数据流图。
|
|
|
|
|
|
|
|
|
|
数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。数据流图和数据字典共同构成系统的逻辑模型。没有数据流图，数据字典难以发挥作用；没有数据字典，数据流图就不严格。只有把数据流图和对数据流图中每个元素的精确定义放在一起才能共同构成系统的规格说明。
|
|
|
|
数据字典的设计包括数据流设计、数据元素字典设计、数据处理字典设计、数据结构字典设计和数据存储设计。这些设计涵盖了数据的采集和范围的确定等信息。在数据字典的每一个词条中应包含以下信息。
|
|
|
|
（1）名称：数据对象或控制项、数据存储或外部实体的名字。
|
|
|
|
|
|
（3）分类：是数据对象？加工？数据流？数据文件？外部实体？还是控制项（事件／状态）？
|
|
|
|
|
|
（5）何处使用：使用该词条（数据或控制项）的加工。
|
|
|
|
对加工的描述是数据字典的组成内容之一，常用的加工描述方法有结构化语言、判定树及判定表。
|
|
|
|
（1）结构化语言。介于自然语言和形式语言之间的一种半形式语言，在自然语言基础之上加了一些限度，使用有限的词汇和有限的语句来描述加工逻辑。结构化语言是受结构化程序设计思想启发而扩展出来的。结构化程序设计只允三种基本结构。结构化语言也只允许三种基本语句，即简单的祈使语句、判断语句和循环语句。与程序设计语言的差别在于结构化语言没有严格的语法规定，与自然语言的不同在于它只有极其有限的词汇和语句。结构化语言使用三类词汇：祈使语句中的动词、数据字典中定义的名词及某些逻辑表达式中的保留字。
|
|
|
|
（2）判定树。若一个动作的执行不只依赖一个条件，而与多条件有关，那么这项策略的表达就比较复杂。如果用结构化语言的判断语句，就有多重嵌套，层次一多，可读性就会下降。用判定树来表示可以更直观一些。
|
|
|
|
（3）判定表。一些条件较多、在每个条件下取值也较多的判定问题，可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系，判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑，是在某种条件取值组合情况下可能的结果，它不能表达加工的顺序，也不能表达循环结构，因此判定表不能成为一种通用的设计工具。
|
|
|
