第二章2系统—需求教材.ppt

软件需求规格说明的基本原则： 功能与实现分离，描述要“做什么”而不是“怎样实现”。 要求使用面向处理的规格说明语言，从而得到“做什么”的规格说明。 如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。 规格说明必须包括系统运行的环境。 （1）需求规格说明的原则 系统规格说明必须是一个认识的模型，而不是设计或实现的模型。 规格说明必须是可操作的。 规格说明必须容许不完备性并允许扩充。 规格说明必须局部化和松散的耦合。当信息被修改时，只要修改某个单个的段落，能够很容易地加入和删去一些段落。 （2）需求规格说明的内容 基于IEEE 830改写的规格说明模板内容： 引言 a.1 目的 a.2 文档约定 a.3 预期的读者和阅读建议 a.4 产品的范围 a.5 参考文献 综合描述 b.1 产品的前景 b.2 产品的功能 b.3 用户类和特征 b.4 运行环境 b.5 设计和实现的限制 b.6 假设和依赖 c. 外部接口 c.1 用户界面 c.2 硬件接口 c.3 软件接口 c.4 通信接口 d. 系统特性 d.1 说明和优先级 d.2 激励／响应序列 d.3 功能需求 e. 其他非功能需求 e.1 性能需求 e.2 基本设施需求 e.3 安全性需求 e.4 软件质量属性 e.5 业务规则 e.6 用户文档 f. 其他需求 附录A：词汇表 附录B: 软件需求分析模型 附录C: 待确定的问题 常用模板 案例 又称需求评审。需求评审的目的是确保需求编写正确。审查的内容包括： 系统定义的目标是否与用户的要求一致； 需求分析阶段提供的文档资料是否齐全； 文档中的所有描述是否完整、清晰、准确反映用户要求； 与所有其它系统成分的重要接口是否都已经描述； （3） 需求验证 主要功能是否已包括在规定的软件范围之内，是否都已充分说明； 软件的行为和它必须处理的信息、必须完成的功能是否一致； 设计的限制条件是否符合实际； 是否考虑了开发的技术风险； 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认； （3） 需求验证 6. 需求管理 需求管理就是管理需求变化的过程。 需求管理涉及需求变更如何被处理的策略、规程和过程。它规定了 应如何提交一个需求变更请求？ 如何分析需求变更对范围、进度和成本的影响？ 如何批准或驳回需求变更？ 如果批准了变更，变更如何实现？ 需求管理 建议变更 分析影响 做出决策 交流 合并 测量需求 的稳定性 变更控制 确定需求 文档版本 确定单个需求文档版本 版本控制 定义对其他 需求的连接链 定义对其他 系统元素的 连接链 需求跟踪 定义需求状态 跟踪需求的 每一个状态 需求状态跟踪 6. 需求管理 变更管理的方法和手段 （1）确定需求变更控制过程 （2）建立变更控制委员会 （3）进行需求变更影响分析 （4）跟踪所有受需求变更影响的工作产品 （5）建立需求基线和需求控制版本文档 （6）维护需求变更的历史记录 （7）跟踪每项需求的状态 （8）衡量需求稳定性 （9）使用需求管理工具 6. 需求管理 停车场收费的业务流程 一、入场： 1.有车辆进入； 2.判断是临时车辆还是固定车辆； 3.若是临时车辆，发进车单，写明车号、入场时间等，然后放行； 4.若是固定车辆，检查车证看是否过期，若正常，放行；若过期，提醒续费，本次按临时车辆处理。 二、出场： 1.有车辆出场； 2.判断是临时车辆还是固定车辆； 3.若是临时车辆，查看进车单，对照车号信息是否无误，计算停车费用，收费、开发票，然后放行； 4.若是包月车辆，检查车证，有效放行、无效续费处理。 智能停车场收费流程 一、入场： 1. 车辆进入，道闸放下； 2. 摄像系统和车辆识别系统启动，摄入车辆图像，经车辆识别系统分析后，获得牌照号、颜色、车型等信息； 3. 若是临时车辆，取卡，卡中写入车辆信息、入场时间等，道闸抬起放行； 4. 若是固定车辆，刷月卡，比对信息，若正常，记录通行时间，道闸放行；若问题卡（如过期），显示提示信息，按临时车辆办理取卡入场。 二、出场： 1.同入场1； 2.同入场2； 3.若是临时车辆，用户把卡交给管理员刷卡，比对信息无误，计费、显示（播报），收费、开发票，管理员控制道闸放行； 4.若是固定车辆，用户刷卡，比对信息，有效则放行，记录出场时间；无效则提示出错信息，由人工处理。 思考： 需求工程的几个阶段？ 需求获取的方法？ 需求规格说明书的主要内容？ 需求管理的内容和方法？ 练习： 掌握业务流程图和系统流程图的画法 * 软件开发项目的最终目标是要实现目标系统的物理模型，即确定待开发