需求拆分
当我们获得需求的时候,需要对需求进行拆分。
那么,怎么评价拆分的好不好? 完备不完备?
不同的功能抽象将导致不同的结果!但应该是等价的
需求大的拆分
比如北大软件工程课程,第10.4讲了一个图书馆的案例。需要建设的图书馆系统,有以下功能
- 书 读入系统,
- 书,销毁
- 借书
- 还书
- 管理员对书的查询
老师首先对功能进行抽象。
可以抽象成1个类,也可以抽象成2大类,也可以抽象成3大类。
课上将其抽象成两个“大块”
- 借还书的事务处理
- 咨询事务
我觉得这个抽象过程是非常重要的,是将纯粹的需求,进行一部抽象化。
这个案例中,分两大块的角度是,从图书的管理角度(借还书),从图书的查询角度(查询)
抽象 -> 顶层数据流, 数据源,数据潭
顶层数据流:
- 借还书等事务处理
- 咨询事务要求
- 相关数据流
数据源和数据潭: - 图书管理员
- 读者
- 时钟 (对于借书超时计数)
评论: 顶层数据流是从抽象进一步得到的,是数据最外层的交互行为
图像进一步分析数据流
建立系统的顶层数据流图
自顶向下,逐层分解 0层数据流
将顶层的数据流中的某个复杂部分,进一步进行分解
其中:保持输入与输出的一致;
引入三个文件,对顶层的DFD进行细化(存在数据库设计的问题)
不要过于复杂,过于细小, 7+2
1 层的数据流
一般建议最多3层
建立系统的数据字典
查询要求=[读者情况| 图书情况| 图书痛惜表]
读者情况= +++
。。
图书管理要求 = 【入库单 | 借书单| 还书单】
查询结果=读者情况 | 图书情况
数据存储条目:
借书文件={借书单}
目录文件={}
需求分析的输出
XXX系统需求规规格说明书
结构化方法
2, 概述
- 功能概述
- 约束
3, 数据流图与数据字典以及加工说明 - 3.1 数据流图
- 3.1.1 数据流图1
- 3.1.2 数据流图2
- 3.2 数据字典
4, 接口
4.1 用户接口
4.2 硬件接口
5, 灵活性
6, 属性