第四课 软件工程 第三部分.pptVIP

一.需求规格说明书(SRS) SRS的作用： 开发者与用户间事实上的技术合同书 开发者下一步设计和编码的基础 测试验收目标系统的依据 SRS大纲（模板） 引言 任务概述(项目概述) 数据描述(DFD、DD) 功能描述 接口 性能需求 属性 其它需求 需求文档的陈述与改进举例（1） 产品必须在固定的时间间隔内提供状态消息，并且每次时间间隔不得小于60秒。 需求文档的陈述与改进举例（2） 产品必须在显示和隐藏非打印字符之间进行瞬间切换。 软件需求评审 作为需求分析阶段工作的复查手段，在需求分析的最后一步，应该对功能的正确性、完整性和清晰性，以及其它需求给予评价. 需求验证特性 (1) 正确性 (2) 无二义性 (3) 完整性 (4) 可验证性 (5) 一致性 (6) 可理解性 (7) 可修改性 (8) 可跟踪性 (9) 设计无关性 (10)注释 软件需求评审 软件需求评审 软件需求分析文档 软件需求分析文档 后台任务管理器(BTM)应该在用户界面的指定区域显示状态消息。 a.在后台任务进程启动之后，消息必须每隔60(?10)秒更新一次，并且保持连续的可见性。 b.如果正在正常处理后台任务进程，那么后台任务管理器(BTM)必须显示后台任务进程已完成的百分比。 c.当完成后台任务时，后台任务管理器(BTM)必须显示一个“已完成”的消息。 d.如果后台任务中止执行，那么后台任务管理器(BTM)必须显示一个出错信息。 需求不完整， 导致需求不可验证 改 进 软件需求分析文档 用户在编辑文档时，通过激活特定的机制，可以在显示和隐藏所有HTML标记之间进行切换。 需求不可行、不完整、 不确定性，导致需求 不可验证 改 进 软件需求分析文档 软件需求分析的目标和任务 软件需求分析的过程 软件需求分析的原则 软件需求获取技术 结构化分析方法 原型化方法 软件需求分析的图形工具 软件需求文档 软件需求评审 评审应以专门指定的人员负责，并按规程严格进行。评审结束应有评审负责人的结论意见及签字。除分析员之外，用户／需求者，开发部门的管理者，软件设计、实现、测试的人员都应当参加评审工作。一般，评审的结果都包括了一些修改意见，待修改完成后再经评审通过，才可进入设计阶段。 软件需求评审 系统定义的目标是否与用户的要求一致； 系统需求分析阶段提供的文档资料是否齐全； 文档中的所有描述是否完整、清晰、准确反映用户要求; 与所有其它系统成分的重要接口是否都已经描述； 所有图表是否清楚，在不补充说明时能否理解； 主要功能是否已包括在规定的软件范围之内，是否都已充分说明； 软件的行为和它必须处理的信息、必须完成的功能是否一致； 设计的约束条件或限制条件是否符合实际； 是否考虑了开发的技术风险； 是否考虑过软件需求的其它方案； 被开发项目的数据流与数据结构是否足够，确定； 评审的主要内容包括： 是否考虑过将来可能会提出的软件需求； 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认； 有没有遗漏，重复或不一致的地方； 用户是否审查了初步的用户手册或原型； 软件开发计划中的估算是否受到了影响 评审的主要内容包括：