23
24
软件工程基础教程
(1) 通过对现实环境的调查研究,获取当前系统的物理模型,如图 2.2 所示.
宿舍 管理员 住宿 单据 出纳 学费 单据 秘书 2 图 2.2 当前系统的物理模型
学 生
交费 申请
秘书 1
交费 清单
交费 发票 会计
领书 单据
书库 管理员
教材
学 生
(2) 分析需求,建立系统的分析模型(由当前系统的逻辑模型到目标系统的逻辑模型). ① 排除当前系统的物理模型中的非本质因素,提炼出当前系统的逻辑模型. 在图 2.2 中具体的办公人员是可能变动的,但他们需要处理的工作是不变的.这些工 作才是本质的内容.由此可以抽象出学生交费过程中当前系统的逻辑模型,如图 2.3 所示.
住宿 住宿 单据 开单据 学费 单据 注册 图 2.3 当前系统的逻辑模型
学 生
交费 申请
审查 有效性
交费 清单
开发票
交费 发票
领书 单据
教材 领书
学 生
② 分析当前系统与目标系统的差别,建立目标系统的逻辑模型. 目标系统与当前系统是有差别的,它的功能比当前系统更强,而不是完全模拟现行的 系统.在上述分析中,可以把第二步与第三步的工作合并,当学生提交申请后,根据学生 信息得出学生应交纳的学费及相关书费等费用情况,直接开出发票.抽象后的逻辑模型如 图 2.4 所示.
24
第2章
软件需求分析
25
住宿
交费 学 申请 生
审查并 开发票
交费 发票
住宿 单据 开单据 学费 单据 注册
领书 单据 领书
教材
学 生
图 2.4
目标系统的逻辑模型
(3) 整理综合需求,编写软件需求规格说明书.根据已经确定的目标系统的逻辑模型, 编写相关文档,描述对系统的综合需求及数据要求.具体编写过程在此不做赘述,相关内 容参见 2.7 节. (4) 验证需求,完善对目标系统的描述.为了对目标系统有个完整的描述,还需要对 已经得到的结果做补充:通过目标系统的人机界面,和用户一起确认目标系统功能;分析 哪些功能由计算机完成,哪些功能由人工完成.在本系统中,收款,发书,住宿认证和注 册等仍由人工完成. 验证需求说明,补充未考虑的细节, 如确定系统的响应时间, 增加出错处理等. 在本系统中,若某学生因故休学,在重新 注册时,就要考虑学生的实际情况,交费 情况与其他同级学生有不同.这样,就需 要在其办理休学手续时,用"休学通知" 把相应的情况通知系统,如图 2.5 所示. 2.1.2 软件需求分析的任务

上一页下一页