软件需求--第9章编写需求文档.pdfVIP

下载 第9章 编写需求文档 需求开发的最终成果是：客户和开发小组对将要开发的产品达成一致协议。这一协议综 合了业务需求、用户需求和软件功能需求。就像我们早先所看到的，项目视图和范围文档包 含了业务需求，而使用实例文档则包含了用户需求。你必须编写从使用实例派生出的功能需 求文档，还要编写产品的非功能需求文档，包括质量属性和外部接口需求。只有以结构化和 可读性方式编写这些文档，并由项目的风险承担者评审通过后，各方面人员才能确信他们所 赞同的需求是可靠的。 你可以用三种方法编写软件需求规格说明： • 用好的结构化和自然语言编写文本型文档。 • 建立图形化模型，这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、 逻辑流或对象类和它们的关系。 • 编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。 由于形式化规格说明具有很强的严密性和精确度，因此，所使用的形式化语言只有极少 数软件开发人员才熟悉，更不用说客户了。虽然结构化的自然语言具有许多缺点，但在大多 数软件工程中，它仍是编写需求文档最现实的方法。包含了功能和非功能需求的基于文本的 软件需求规格说明已经为大多数项目所接受。图形化分析模型通过提供另一种需求视图，增 强了软件需求规格说明。 本章介绍软件需求规格说明的目的和结构，包括一个建议性的文档模板。同时还提供编 写功能需求规格说明的原则并附带讲述几个不完善的需求陈述以及改进建议的例子。在第 1 0 章将介绍利用图形化技术表示需求。本书并不深入介绍形式化需求方法；若要深入讨论形式 化需求方法，可参考Alan Davis 编著的《软件需求：对象、功能和说明》（1 9 9 3）。 9.1 软件需求规格说明 软件需求规格说明，也称为功能规格说明、需求协议以及系统规格说明。它精确地阐述 一个软件系统必须提供的功能和性能以及它所要考虑的限制条件。软件需求规格说明不仅是 系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。它应该尽可能 完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，软件需求规 格说明不应该包括设计、构造、测试或工程管理的细节。许多读者使用软件需求规格说明来 达到不同的目的： • 客户和营销部门依赖它来了解他们所能提供的产品。 • 项目经理根据包含在软件需求规格说明中描述的产品来制定规划并预测进度安排、工作 量和资源。 • 软件开发小组依赖它来理解他们将要开发的产品。 • 测试小组使用软件需求规格说明中对产品行为的描述制定测试计划、测试用例和试过 程。 第9章 编写需求文档 73 下载 • 软件维护和支持人员根据 S R S 了解产品的某部分是做什么的。 • 产品发布组在S R S和用户界面设计的基础上编写客户文档，如用户手册和帮助屏幕等。 • 培训人员根据S R S和用户文档编写培训材料。 软件需求规格说明作为产品需求的最终成果必须具有综合性：必须包括所有的需求。开 发者和客户不能作任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明， 那么它将不能作为协议的一部分并且不能在产品中出现。 毫无疑问，你必须在开始设计和构造之前编写出整个产品的软件需求规格说明。你可以 反复地或以渐增方式编写需求规格说明，这取决于以下几个因素：是否可以一开始就确定所 有的需求，编写软件需求规格说明的人是否将参与开发系统，计划发行的版本数量等等。然 而，每个项目针对要实现的每个需求集合必须有一个基准协议，基准（ b a s e l i n e ）是指正在开 发的软件需求规格说明向已通过评审的软件需求规格说明的过渡过程。必须通过项目中所定 义的变更控制过程来更改基准软件需求规格说明。 所有的参与者必须根据已通过评审的需求来安排工作以避免不必要的返工和误解。我见 过有一个项目突然接到测试人员发出的错误灾难的报告。结果是他们测试的是老版本的软件 需求规格说明，而他们觉得错误的地方正是产品所独有的特性。他们的测试工作