需求拆分-软件工程

需求拆分

当我们获得需求的时候，需要对需求进行拆分。
那么，怎么评价拆分的好不好？ 完备不完备？
不同的功能抽象将导致不同的结果！但应该是等价的

需求大的拆分

比如北大软件工程课程，第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， 属性