软件工程（四）软件需求工程

结构化分析的分析模型

事件

事件和dfd图的关系

事件列表中的每一个事件都可以画出一个DFD 图 (需要额外添加数据存储元素

事件列表可以作为画数据流图的一个基础和检验列表

事件对应 DFD 模型的中间层

事件可以继续分解绘制其具体的处理过程(向下)

系统中事件较多时，应进行分组 (向上抽象)

事件和用例之间的关系

数据流图

画数据流图的注意事项

1.  先画草图，然后与用户交流，确定正式图，并适当进行布局调整，使DFD清晰、易读。

2. 关于层次的划分，一般与管理的层次一致，但可根据系统处理的需要进行调整（进一步细分或不分），原则上不超过7层（以4层左右为宜）

3. 检查数据流程图的正确性  

（1）数据守恒，或称为输入输出数据匹配。  

（2）在一套数据流程图中的任何一个数据存储，必定有流入的数据流和流出的数据流。

（3）父图中某一处理框的输入、输出数据流必须出现在相应的子图中，否则就会出现父图与子图的不平衡。  

（4）任何一个数据流至少有一端是处理框。

4.提高数据流程图的易理解性

（1）简化处理间的联系

（2）均匀分解

（3）适当命名

5. 数据流图的优化

常常要作重新分解。重新分解可以按下述方法进行：

（1）把需要重新分解的某张图的所有子图拼成一张。

（2）把图分成几部分，使各部分之间的联系最少。

（3）重新建立父图

（4）重新画子图

（5）为所有处理重新命名、编号

数据流图的常见错误

1. 语法错误（可采用软件工具辅助绘图消除）

2. 逻辑错误

3. 词不达意，二义性

快速原型化方法

定义

是一种有效驾驭风险的技术。

通过原型可以增进软件者和用户对系统服务需求的理解，使比较含糊的具有不确定性的软件需求（主要是功能）明确化。

可以容易地确定系统的性能，确认各项主要系统服务的可应用性，确认系统设计的可行性，确认系统作为产品的结果。

有的原型可以直接成为产品，有的略加修改就可成为最终系统的一个组成部分。

使用

支持需求工程的两项活动及用途

需求获取 需求有效性验证 用户培训 系统测试

主要分类

进化式原型开发

先给出一个系统的最初实现，让用户去使用和评价，不断进行细化和改善，经过多次这样的反复过程后形成最终的完善的系统。

抛弃式原型开发

原型的根本作用是弄清楚需求和为风险评估提供补充信息。通过评估后，原型被抛弃，重新规划和实施系统的开发

需求规格说明

原则

1.功能与实现分离，描述要“做什么”而不是“怎样实现”。

2.要求使用面向处理的规格说明语言，从而得到“做什么”的规格说明。

3.如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。

4.规格说明必须包括系统运行的环境。

5.系统规格说明必须是一个认识的模型，而不是设计或实现的模型。

6.规格说明必须是可操作的。

7.规格说明必须容许不完备性并允许扩充。

8.规格说明必须局部化和松散的耦合。当信息被修改时，只要修改某个单个的段落，能够很容易地加入和删去一些段落。