SRE08需求规格说明教材.ppt

* Software Requirements Engineering软件需求工程 School of Software Zhengzhou University Instructor: Xu Ting ietxu@zzu.edu.cn * Software Requirements Engineering 需求规格说明 * 8 需求规格说明 8.1 需求规格说明 8.2 标识需求 8.3 TBD 8.4 关于用户界面 8.5 需求模板 8.6 需求规格说明的原则 8.7 需求示例改进前后 * * 8.1 需求规格说明 可以用三种方法编写软件需求规格说明： 用好的结构化和自然语言编写文本型文档。 建立图形化模型，这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系。 编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。 * * 8.1 需求规格说明 由于形式化规格说明具有很强的严密性和精确度，因此，所使用的形式化语言只有极少数软件开发人员才熟悉，更不用说客户了。 虽然结构化的自然语言具有许多缺点，但在大多数软件工程中，它仍是编写需求文档最现实的方法。包含了功能和非功能需求的基于文本的软件需求规格说明已经为大多数项目所接受。 图形化分析模型通过提供另一种需求视图，增强了软件需求规格说明。 * * 8.1 需求规格说明 软件需求规格说明，也称为功能规格说明、需求协议以及系统规格说明。它精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件。 软件需求规格说明不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。 除了设计和实现上的限制，软件需求规格说明不应该包括设计、构造、测试或工程管理的细节。 * * 8.1 需求规格说明 软件需求规格说明作为产品需求的最终成果必须具有综合性：必须包括所有的需求。开发者和客户不能作任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明，那么它将不能作为协议的一部分并且不能在产品中出现。 毫无疑问，必须在开始设计和构造之前编写出整个产品的软件需求规格说明。 可以反复地或以渐增方式编写需求规格说明。 * * 8.1 需求规格说明 不同人员使用软件需求规格说明来达到不同的目的： 客户和营销部门依赖它来了解他们所能提供的产品。 项目经理根据包含在软件需求规格说明中描述的产品来制定规划并预测进度安排、工作量和资源。 软件开发小组依赖它来理解他们将要开发的产品。 测试小组使用软件需求规格说明中对产品行为的描述制定测试计划、测试用例和试过程。 软件维护和支持人员根据SRS了解产品的某部分是做什么的。 产品发布组在SRS和用户界面设计的基础上编写客户文档，如用户手册和帮助屏幕等。 培训人员根据SRS和用户文档编写培训材料。 * * 8.1 需求规格说明 可读性的建议： 对节、小节和单个需求的号码编排必须一致。 右边部分留下文本注释区。 允许不加限制地使用空格。 正确使用各种可视化强调标志（例如，黑体、下划线、斜体和其它不同字体）。 创建目录表和索引表有助于读者寻找所需的信息。 对所有图和表指定号码和标识号，并且可按号码进行查阅。 使用字处理程序中交叉引用的功能来查阅文档中其它项或位置，而不是通过页码或节号。 * * 8.2 标识需求 为了满足软件需求规格说明的可跟踪性和可修改性的质量标准，必须唯一确定每个软件需求。这可以在变更请求、修改历史记录、交叉引用或需求的可跟踪矩阵中查阅特定的需求。由于要达到这一目的，用单一的项目列表是不够的，因此，描述几个不同的需求标识方法，并阐明它们的优点与缺点。可以根据情况选择最适合的方法。 * * Identifying requirements 标识需求1) 序列号 最简单的方法是赋予每个需求一个唯一的序列号，例如UR-2或SRS13。 当一个新的需求加入到商业需求管理工具的数据库之后，这些管理工具就会为其分配一个序列号（许多这样的工具也支持层次化编号）。 序列号的前缀代表了需求类型，例如UR代表“用户需求”。由于序列号不能重用，所以把需求从数据库中删除时，并不释放其所占据的序列号，而新的需求只能得到下一个可用的序列号。这种简单的编号方法并不能提供任何相关需求在逻辑上或层次上的区别，而且需求的标识不能提供任何有关每个需求内容的信息。 * * Identifying requirements 标识需求2) 层次化编码 这也许是最常用的方法。如果功能需求出现在软件需求规格说明中第3.2部分，那么它们将具有诸如3.2.4.3这样的标识号。标识号中的数字越多则表示该需求越详细，属于较低层次上的需求。 这种方法简