第六章_需求分析文档编制.pptVIP

第六章 需求分析文档编制 测试与SRS 某项目突然接到测试人员发出的错误灾难的报告。结果是他们测试的是老版本的软件需求规格说明，而他们觉得错误的地方正是产品所独有的特性。他们的测试工作是徒劳的，因为他们一直在老版本的软件需求规格说明中寻找错误的系统行为。 功能标识符举例 第六章 需求分析文档编制 选择合适的SRS模板 不同的软件项目，使用的模板不一，但前后项目使用同一模板有利于书面的沟通和知识的传承。 另一常用的SRS模板 第六章 需求分析文档编制 “分析程序应该能生成HTML标记出错的报告，这样就可以使HTML的初学者使用它来迅速排错。” “迅速”这个词具有模糊性。缺乏对出错报告内容的定义,表明该需求是不完整的。不知是如何验证这个需求的。找一些HTML的初学者，看他们利用这个报告是否可以迅速排错？ 还有一点不清楚的是： HTML初学者使用的是分析程序还是出错报告。并且何时生成这样的报告？ 使用另一种方式表述这个需求： a. 在HTML分析程序完全分析完一个文件后，该分析程序必须生成一个出错报告，这个报告中包含了在分析文件过程中所发现错误的HTML所在的行号以及文本内容，还包含了对每个错误的描述。 b. 如果在分析过程中未发现任何错误，就不必生成出错报告。 需求分析文档改进示例（三） “产品不应该提供将带来灾难性后果的查询和替换选择。” “灾难性后果”的含义是中心词。在编辑文档时，毫无目的地作出全局性变化而用户又不能检测出错误或没有任何办法来纠正它，此时就可能带来灾难性后果。 要合理地使用反面需求，因为这些需求描述了系统所不能做的事情。潜在的关注焦点在于当发生意外损坏时，能保护文件的内容。真正的需求是针对多级撤销能力、全局变化或其它可导致数据丢失行为确定的。 第六章 需求分析文档编制 * 6.1 软件需求规格说明 6.2 软件需求规格说明模板 本章结构 6.3 编写原则与改进示例 6.4 需求文档示例 本章目标： 了解软件需求的几种表达形式 掌握软件需求规格说明的编写方法 需求开发的最终成果是，在客户和开发小组对所要开发的产品达成共识后，所编写的具体文档。这一文档综合了业务需求、用户需求和软件功能需求。 只有以结构化和可读性方式编写这些文档，并由项目的风险承担者评审通过后，各方面人员才能确信他们所赞同的需求是可靠的。 SRS----需求开发的成果 采用以下几种方式来表示软件需求： 文档 用结构合理的自然语言来精心编写需求文档。 图形化模型 这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或者对象类及其关系。 形式化规格说明 使用数学上精确的形式逻辑语言来定义需求。 最常用和最普遍的方式是什么？ 几种表示需求结果的方式 必须使用软件需求规格说明的涉众有以下几类： 客户、市场部和销售人员 了解他们期望得到的产品。 项目经理 估计项目的进度、工作量和所需资源。 开发团队 了解需要开发什么样的产品。 测试小组 开发测试计划、测试用例和测试过程。实例 软件维护和支持人员 了解产品每一部分的功能是什么。 软件需求规格说明的涉众 文档编写人员根据软件需求规格说明和用户界面设计来编写用户手册和帮助屏幕。 培训人员根据软件需求规格说明和用户文档来编写培训材料。 公司律师要确保该需求遵守相应的法律法规。 分包商根据软件需求规格说明来进行工作。 软件需求规格说明的涉众 如何使涉众各方都能够理解SRS,增强其可读性？ 对节、小节和单个需求的标记格式必须一致。 灵活地使用各种可视强调标志(例如，黑体、下划线、斜体和不同字体)。 创建目录表，也许还需要创建索引，这有助于读者找到他们所需要的信息。(Word中文档结构图的使用) 增强SRS可读性 对所有图和表进行编号，并且给出标题，根据编号来引用这些图和表。 使用字处理程序的交叉引用功能来引用文档中的其他位置，而不是通过页码或节号进行引用。 使用超链接使读者可以跳到软件需求规格说明或其他文档的相关部分。 使用合适的模板来组织所有的必要信息。 6.1.1 需求的标识 好的SRS特性：完整性、一致性、可修改性和可跟踪性。 为了满足可跟踪性和可修改性的质量标准，必须对每个功能性需求进行惟一而永久的标识，可以在变更请求、修改的历史记录中引用特定的需求。 几种不同的需求标识方法 1. 序列号 2. 层次型编号 3. 层次型文本标签 赋予每个需求一个惟一的序列号，如UR-2,SRS13 序列号的前缀代表了需求类型 序列号不能重用 不能提供相关需求在逻辑上或层次上的区别 需求的标识不能提供任何有关每个需求内容的信息 1. 序列号 如果功能需求出现在软件需求规格说明中第3.2部分，那么它们将具有诸如3.2.4.3这样的标识号