[工学]3-需求分析.ppt

在分析表达数据流图时还应该在概念上特别注意几点： 数据流图只是表达系统中（信息）数据的流动，是一种软件系统信息处理的逻辑模型，在图中不包括任何实际的物理实体。 带箭头的线表示的是数据的流动，而不是实物流或者控制流。 在数据流图中没有算法描述中常出现的那种循环和分支，因为数据流图只是在描述要解决的问题本身“是什么”，而不用考虑“怎么做”。 改进和优化 优化后的学生教材管理逻辑模型 学生教材管理实际处理流程 学生教材管理逻辑模型 示例 一个飞机机票预订系统 旅行社把预订机票的旅客信息 (姓名、年龄、单位、身份证号码、旅行时间、目的地等)输入机票预订系统。 系统为旅客安排航班，打印出取票通知单(附有应交的账款)。 旅客在飞机起飞的前一天凭取票通知单交款取票，系统检验无误，输出机票给旅客。 画数据流图的步骤 (1)画系统的输入输出，即先画顶层数据流图。 顶层流图只包含一个加工 顶层图的作用在于表明被开发系统的范围以及它和周围环境的数据交换关系 画数据流图的步骤 (2)画系统内部，即画下层数据流图，直至底层数据流图。 不再分解的加工称为基本加工。 一般将层号从0开始编号，采用自顶向下，由外向内的原则。 画0层数据流图时，分解顶层流图的系统为若干子系统，决定每个子系统间的数据接口和活动关系。 细化数据流图 2 系统 检验 3 交款 出票 1 安排 航班 航班文件 取票通知单 取 票 通 知 单 机票 旅客信息 旅行社 旅客 通知单不合法 合法通知单 旅客机票文件 旅行社 旅行社 旅行社 旅行社 旅行社 父图与子图的平衡 习题 2-15 某银行的计算机储蓄系统功能是：将储户填写的存款单或取款单输入系统,如果是存款，系统记录存款人姓名、住址、存款类型、存款日期、利率等信息，并打印出存款单给储户；如果是取款，系统计算清单给储户。试用SA方法对上述系统功能进行分析，画出系统的分层DFD图。 3.4.1 结构化技术 实体关系模型(Entity-Relationship Modeling，ERM)是对产品进行规格说明的一种半形式化的面向数据的技术。 基数是关于一个对象可以与另一个对象的出现次数相关联的出现次数的规约。两个对象可以如下关联： 一对一(1：1) 一对多(1：n) 多对多(m：n) 形态 如果对关系的出现没有明显的需要或关系是可选的时，关系的形态是0 如果关系必须出现一次，则形态是1 实体关系模型 1. 实体：观念世界中描述客观事物的概念。 2. 属性：指实体具有的某种特性。(椭圆形，可缺省) 3. 联系：现实世界的事物总是存在着这样或那样的联系，这种联系必然要在信息世界中得到反映。 3.4.2 形式化技术 形式化方法提供了规约环境的基础，它使得所生成的分析模型比用传统的或面向对象的方法生成的模型更完整、一致和无二义性。 有限状态机(FSM) Petri网 Z形式化方法 需求规格说明书格式 一份完整规范的需求规格说明书应包含下面的一些内容： 引言：对系统进行一些概要的描述； 引用标准：给出本需求规格说明书的有关参考标准； 系统及任务描述：用以描述系统中各种实体及其相应的关系，通常可用实体关系图和层次方框图来描述。 需求规定：对系统的功能、性能、精度以及输入、输出等具体要求作出规定。 数据描述：描述逻辑数据模型，也就是各种数据关系和相应的处理，通常可以使用数据流图, 数据词典，加工说明来描述。 功能描述：用以描述要解决的各种问题。 性能描述：描述系统性能方面的内容。 质量保证：描述系统各部分要求达到的质量标准。 其他：描述其他的一些补充内容。 签字认证：用户和开发人员双方签字认证。 参考文档 软件工程课程实践文档 3.5 需求验证 为确保系统分析员和用户之间都能正确理解需求，通常要在下面几个方面验证： 需求是正确的吗？ 需求是一致的吗？ 需求是完全的吗？ 需求是实际可行的吗？系统真的能做顾客所请求做的事吗？ 每一条需求所描述的事物是顾客需要的吗？ 需求是可检验的吗？ 需求是可跟踪的吗？每一系统功能都能被跟踪到要求它的需求集合吗？容易找到处理一个系统特定方面的需求集合吗？ 3.5 需求验证 对目标系统的逻辑模型进行完善和补充。 最后按照约定的格式写出规范完整的需求说明书。 作为需求分析阶段最后一项工作，就是双方或者三方的复审后的签字，作为软件开发合同的组成内容，签字后，如果在后续的开发过程中要更改，双方要重新协商，达成协议后再更改。 习题 2-16 某企业销售管理系统的功能为： (1)接受顾客的订单，检验订单，若库存有货，进行供货处理，即修改库存，给仓库开备货单，并且将订单留底；若库存量不足，将缺货订单登入缺货记录。 (2)根据缺货记录进行缺货统计，将缺货通知单发给采购部门，以便采购。 (3)根据采购部门发