软件工程--需求分析与规格说明

软件工程--需求分析与规格说明也称为需求确定或分析阶段

 

 

通过分析，理解用户的各种问题，通过规格说明把问题表达出来；

 

基本概念

 

 

开发过程通常分为两大阶段：

 

1， 正确地确定问题：软件做什么？

 

2， 为问题寻找合适的解答：软件怎么做？

 

 

需求分析和规格说明阶段的目的：澄清用户的各种需求

 

 

这个阶段的基本任务：用户和软件人员双方一起来充分理解用户的要求，并把双方共同的理解明确地表达成一份书面文档—需求说明书；

 

 

用户需求：软件系统必须满足的所有性质和限制：功能要求（数据要求和加工要求），性能要求，可靠性要求，安全保密要求，以及开发费用，开发周期，可使用的资源等方面的限制；

 

 

需求说明书的作用：作为软件人员和用户之间的合同；

 

                              反映出问题的结构，作为软件人员设计和编写的基础；

 

                              作为验收的依据，作为选取测试用例和进行验证的依据；

 

需求说明书应该完整，一致，精确，无二义；

 

 

分析员是中间人物：一方面要熟悉计算机技术，另一方面要了解用户业务领域的相关知识；分析员作为用户的顾问和翻译；但只是做翻译和顾问，不能代替用户对系统提出要求；

 

 

结构化分析方法

 

SA:Structured Analysis

 

该方法用于需求分析阶段，在设计阶段可以衔接SD,即结构化设计方法；

 

 

软件工程技术中，控制复杂性的两个基本手段是：分解和抽象；

 

 

SA使用自顶向下逐层分解的方法；使用这个方法，系统规模增大的时候，分析工作的复杂程度不会随之增大，而只是多分解几层而已；所以SA方法有效地控制了系统的复杂性；

 

 

SA使用介于形式语言和自然语言之间的描述方式：

 

 

需求分析说明书的组成：

 

1，一套分层的数据流图：描述系统的组成部分和个部分之间的联系；

 

2，一本数据词典：描述系统中的每一个数据流的成分；

 

3，一组小说明：描述系统中的每一个加工的具体动作；

 

4， 补充材料：

 

 

SA分析的步骤：

 

1， 理解当前的现实环境，获得当前人工系统的具体模型；

 

2， 从当前系统的具体模型抽象出当前系统的逻辑模型；

 

3， 分析目标系统与当前系统逻辑上的差别，建立目标系统的逻辑模型；

 

4， 为目标系统的逻辑模型作补充；

 

//  我们发现，我们从现实系统分析得到的模型并不是我们所要开发的系统的模型，这两个完全是来自不同的方向；所以需求分析不光要分析和总结目标系统，而且要考察现实模型，给出他们之间的差别；但是目标系统一定是依靠现实模型建立起来的；

 

 

数据流图

 

数据流图描述了一个组织有哪几个组成部分，也描述了来往于各部分之间的数据流；

 

 

例如一个选课系统的数据流图描述如下：

 

 

数据流是由一组固定成分的数据组成的，比如 报名数据 的组成：姓名，单位，。。。。。；

 

 

数据流的可能流向：

 

 

数据流用箭头表示，加工动作用圆圈表示，文件用横线表示；

 

 

注意：数据流图中描述的是数据流而不是控制流；比如箭头上的标示不应该是：取下一张卡片，或者存储到文件等动作词语；同样也不可以是每月第一天或者当老板高兴的时候等这样的加工条件；

 

 

每个加工还有一个编号，来说明这个加工在数据流图的层次分解中的位置；

 

 

文件是暂时存储的数据；

 

 

加工与文件之间数据流的方向暗示了数据流的动作是写还是读或者是读写；

 

 

总结：数据流图从数据和数据经受的加工两个补充的方面来表达一个数据处理系统；

 

 

数据流图只是描述了系统的分解，但没有表达每个数据和加工的具体含义，这些信息要放在数据词典和小说明中；

 

 

画数据流图的方法：由外向里

 

       先画输入数据流和输出数据流，也就是确定系统的范围或者说边界；

 

       然后考虑系统的内部，然后用递归的思想来继续画；

 

       在数据流的组成或值变化的地方画上一个加工来实现这有一变化；

 

      

 

      

 

分层数据流图：一个庞大的数据流图应该由一套分层的小数据流图组成，这就是SA的方法；

 

 

       逐层分解的方式有控制地逐步增加细节，实现从抽象到具体的逐步过渡；

 

 

一套分层的数据流图的组成：

 

       顶层图：系统的边界；

 

       底层图：由一些不必再分解的加工组成，称为基本加工；

 

       中间层数据流图：描述了某个加工的分解，而她的组成部分又要进一步被分解；

 

系统可以没有中间层，也可以有很多中间层；

 

 

所以现在我们对分层数据流图应该有个纠正认识：分层的数据流图的各个层的图并不是整个数据流图所描述的系统的一部分，而是整个系统的完整但是详细度不同的描述；

 

也就是说每层都完整地描述了整个系统，只是详细的程度是逐步增加的；

 

 

各层图之间的关系称为父图与子图；

 

 

分层数据流图只是表达了系统的分解，还需要用数据词典和小说明对图中的每个数据和加工的含义进行描述；

 

分层数据流图的绘制方法： 自顶向下，逐步求精；

 

事实上是：父图的分解其实就是对父图的一个加工分解成了子图中的数据流和加工而已；

 

注意的问题：

 

1， 子图应该与父图在编号上有所反映；

 

2， 父图和子图需要平衡，其实就是说子图要能够完全替换父图而不影响父图的相应加工的输入输出结构；有时候是否平衡还得借助数据词典来看，比如下图是可以是平衡的：

 

 

3，   局部文件，意思就是在父图中，只需要画出加工与加工之间的联系，不必画出各个加工内部的细节，这个细节就包括将来在子图中出现的局部文件；

 

4， 分解的程度：没有统一的标准；

 

数据流图的正确性检查和改进：

 

正确性检查：

 

1， 数据流的输入输出；

 

2， 文件的使用；如果文件只被写了没被读过，那肯定漏了某个数据流；

 

3， 父子图是否平衡；

 

提高易理解性：

 

1， 简化加工间的联系；

 

2， 注意分解的均匀；要么都比较细，要么都比较粗；

 

3， 适当地命名；

 

重新分解：当一个数据流图读起来非常不容易理解：

 

       把需要重新分解的某张图的所有子图连接成一张；

 

       把图分成几部分，使各部分之间的联系最少；

 

       重新建立父图；

 

       重新建立各张子图；

 

       为所有加工重新命名和编号；

 

数据词典

 

 

因为数据流图没有说明系统中各个成分是什么含义，所以系统说明书中的第二个组成部分是数据词典，用来对数据流图中的所有名字进行定义和解释；

 

 

词典中应该对以下项目进行描述：

 

1， 数据流

 

 

2， 对文件进行描述：

 

 

3， 数据项：

 

 

数据项是有值域的；

 

下面是几个词典的实例：

 

 

 

 

 

小说明:对每个基本加工的说明，应该精确地描述用户要求一个加工做什么，这包括加工的激发条件，加工逻辑，优先级，执行频率，出错处理等；

 

 

SA方法用结构化语言，判定表，判定树这三种半形式化工具对加工进行说明：

 

1， 结构化语言：外层语法用来描述控制结构，如顺序，选择，循环，这些控制结构将

 

加工中的各个操作连接起来；

 

内层语法：语态：只有祈使句一种，它能明确表达做什么；

 

                词汇：名词都是词典中定义过的或自定义的词；

 

                动词：避免使用handle,process等抽象不具体的词；

 

                没有形容词，副词等修饰语；

 

                可以用常用的运算符和比较符；

 

尽可能精确，尽可能简单；

 

完全可以用具有一定结构的汉语来描写加工逻辑；可以理解为伪代码；

 

2， 判定表：

 

类似下面的形式：如果 XXX 满足了什么条件，然后就执行YYY的动作；

 

                            如果XXX。。。。。；

 

                            。。。

 

 

              判定表清晰易懂，只适合描述条件，描述循环则比较困难；

 

3， 判定树：

 

 

小结：加工逻辑可以用语言，表格，图形等多种形式来描述，在使“小说明”尽可能精确易懂的前提下，分析员可根据每个加工的具体情况选用不同的描述手段；

 

 

 

 

SA具体分析的例子

 

 

 

 

 

 

 

SA方法的缺点：

 

1， 理解和表达用户的数据需求方面比较局限；

 

2， 理解和表达人机界面方面差；

 

3， 它强调分析数据流，而对时间，控制方面的描述不精确，所以不适合于实时系统；

 

4， 在澄清，确定用户需求方面能起的作用有限；

 

 

 

快速原形法

 

在很短的时间内建立起一个只包含基本数据库和一些基本功能的原形给用户使用，然后根据用户意见对原形进行修改，直到满意为止；

 

 

 

快速原形法适合给用户一个定心丸，让不知道系统复杂的用户在短期内看到整个系统的基本模型；

 

 

需求分析阶段还要做的其他工作：

 

       确定设计限制；

 

       确定验收准则；

 

编写 初步用户手册；

 

       复查需求说明书；