6-需求获取 软件工程案例分析课件_精品.ppt

编写需求文档 需求文档要求 完整性 一致性 可修改性 可跟踪性 * 软件需求规格说明 软件需求规格说明的作用 客户和营销部门依赖它了解他们所能提供的产品 项目经理根据包含在软件需求规格说明中描述的产品来制定规划并预测进度安排、工作量和资源 软件开发小组依赖它来理解他们将要开发的产品 测试小组利用它来制定测试计划，测试案例 软件维护人员和支持人员依据它了解系统的功能 产品发布组根据它编写客户文档，包括用户手册和帮助 培训人员根据它编写培训教材 * 什么是好的需求规格说明书 正确 正确地反映用户真实意图。 开发者和用户自己都不明白用户究竟“想要什么”和“不要什么”。 双方确认需求规格说明书。 清楚 采用反问方式来判断需求文档是否清楚 文档结构、段落是否乱七八糟？上下文是否不连贯？ 文档语句是否含糊其词、罗里罗嗦？ 看了半天是否还不明白需求究竟是什么？ 无二义性 每个需求只有唯一含义。 措词准确，切勿模棱两可。 * 什么是好的需求规格说明书 一致 各个需求之间不会发生矛盾。 矛盾常常潜伏在需求文档的上下文中。 必要 各项需求对用户而言应当都是必要的。 “雪中送炭”，不能 “画蛇添足” “锦上添花”是好事，但不会多付钱。 集中精力先完成必要需求，条件允许再“锦上添花” “锦上添花”需求设置为较低优先级。 完备 没有遗漏必要需求。 不能关注特色，忽视必需功能。 * 什么是好的需求规格说明书 可实现 各项需求对开发方而言应当都是可实现的（Attainable）。 “可实现”：技术上可行，满足时间、费用、质量约束。 营销人员对用户提出的需求“来者不拒”。但是《产品需求规格说明书》相当于商业合同。 对于合同项目，如开发方不能确信某些需求是否可实现，则应事先与用户协商，达成一致处理意见。 可验证 各项需求对用户方而言应当都是可验证的（Verifiable）。 摩天大楼的一项需求是“抗十二级台风”.如何验证？ * 什么是好的需求规格说明书 确定优先级 原因是：项目存在“进度、费用、人力资源”限制。 “取舍”法：先做优先级高的需求，后做（甚至放弃）优先级低的需求，这样可以将风险降到最低。 阐述“做什么”而不是“怎么做” 重点是阐述“做什么”，而不是“怎么做”。“怎么做”是系统设计和实现阶段的事情。 开发人员身兼数职，可能把需求开发、系统设计、编程等工作从头做到尾。关键是不要将“怎么做”写到需求规格说明书里面，记录在其它文档里就行了。 * 软件需求规格说明 文档可读性 对节、小节和单个需求的号码编排必须一致 在右边部分留下文本注释区 允许不加限制地使用空格 正确使用各种可视化强调标志 创建目录表和索引表有助于读者寻找所需信息 对所有图和表制定号码和标识号 * 软件需求规格说明 需求的标识 序列号，如UR-2,SRS13 层次化编码，如3.2.4 层次化文本标签，“当用户请求打印超过10个副本时，系统必须让用户进行确认判断。” print.copies.confirm 不完整的需求 进行特殊的标识TBD(to be determined)，在继续进行构造需求集合之前，必须处理完所有TBD 用户界面与软件需求说明 用户界面是解决方案，而不是需求，但是可以更清楚的定义需求。 可以画一些草图 * 软件需求规格说明 a 引言 a.1目的 a.2文档约定 a.3预期的读者和阅读建议 a.4产品的范围 a.5参考文献 b.综合描述 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.1性能需求 e.2安全设施需求 e.3软件安全性需求 e.4软件质量属性 e.5业务规则 e.6用户文档 其它需求 附录A:词汇表 附录B:分析模型 附录C:待确定问题的类标 * 软件需求规格说明的注意事项 需求说明语句 保持语句和段落的简短 采用主动语态的表达方式 编写具有正确的语法和标点的完整句子 使用的术语应该和词汇表中定义的一致 需求陈述应该具有一致的式样 “系统必须……”，或者“用户必须……” 紧跟一个行为动作和可观察的结果 “仓库管理子系统必须现实一张在所请求的仓库中有存货的药品名单。” * 软件需求规格说明的注意事项 减少不确定性，避免采用模糊、主观术语 “用户友好、容易、简单、迅速、有效、支持、许多、必威体育精装版技术、优越的、可接受和健壮。” 避免使用比较性词汇 “提高，最大化，最小化和最佳化。” 定量说明所需提高的程度或说清一些参数可接