课件

8.7 撰写需求文档.pdf

软件需求规格说明

软件需求规格说明（Software Requirements Specification，SRS）。

撰写软件需求规格说明的目标是：

• 为了围绕应用领域与待开发的系统进行沟通，形成一个具有一定法律效力的合同文档；
• 并以供需双方就系统内容达成的共识，清楚的描述软件在什么情况下需要做什么，以及不能做什么；
• 通过定义以系统的输入、输出，以及从输入到输出之间的转换的方式，来描述系统的功能性的需求；
• 描述经过干系人磋商后达成共识的非功能性需求及其评估指标；
• 一般可以参考需求定义的模板，覆盖标准模板中定义的所有相关条目；
• 并将需求作为后续软件评估的依据，和需求变更的基准；

需求文档的组织形式

需求文档需要有一定的逻辑组织结构，目前 IEEE 提供的模板是被最广泛应用的文章组织形式之一

除此以外，典型的需求文档的组织形式还包括：

• 可以按照系统能够响应的各种外部环境的情况来组织。比如对于一个飞机着陆管理系统来说，按照飞机着陆时的环境条件如风速、燃料余量、跑道长度等来组织需求的撰写。
• 可以按照系统的功能特征来组织。比如对于一个电话系统来说，按提供给客户的功能特征来组织，如呼叫转移、来电屏蔽、电话会议等。
• 可以按照系统对于外部请求的响应方式来组织。比如对于一个工资管理系统，按请求响应的方式是工资条生成请求、成本计算、打印税单等等。
• 可以按照所管理的外部数据对象的类型来组织。比如对图书管理系统按所管理的书籍的类型，来组织需求的撰写。
• 可以按照用户的类型来组织。比如对一个项目管理系统，可以按照经理人、技术人员、管理人员来组织系统的需求。
• 可以按照软件的工作模式来组织。比如对一个文档编辑器，可以按照文档编辑时候的页面布局分为大纲模式、分页模式，普通文档编辑模式等等。
• 可以按照子系统划分来组织。比如对一个飞行器管理系统，我们可以分为命令控制子系统、数据处理子系统、通信子系统、设备管理子系统等。

所以需求文档的组织形式应该是按照待设计的系统它本身的需要，按照合理的有逻辑的方式来组织。

软件需求规格说明的风格

软件需求规格说明的风格主要包括：

• 描述性的自然语言文本
• 用例模型
• 从需求数据库中生成

描述性的自然语言文本最常见的是目前敏捷方法中以用户故事为主的简洁文本描述，是目前最流行的描述性手段之一。

软件需求规格说明也可以从用例模型产生。从用例到需求规格说明之间的转化，可以看成一个双向的可逆的过程，如果我们用用例来表示需求模型，反过来如果我们先建立了用例模型的话，就可以逆向生成需求的完整集合，当然也可以在工具的支特下完成。

在商业的需求数据库中，也有部分内置的功能，通过对需求的列表进行筛选，生成我们想要的需求规格说明的文档。尤其是产品线或者产品线家族的需求，根据这类需求规格说明数据库中的选项，我们可以生成特定产品的需求规格说明。

此外我们还可以混合多种模型，比如将特征模型和用例模型相结合，生成需求规格说明。

从需求数据库中生成、从混合模型中生成这两种方式，往往都是要通过内嵌模板加上工具来完成。

选择合适的需求规格说明方式

对不同规格的软件开发项目，需求规格说明的方式可以是不同的，考虑以下的两种具体项目场景：

• 小型项目：有一名程序员，经过两个月的开发。住住程序员直接可以和用户对话，写两页纸的备忘录供查就已经足以支特项目的开发任务
• 大型项目：有 50 名程序员，经过两年的开发。需要专门的团队进行需求建模与分析，撰写详尽的需求规格说明。

仔细分析两个项目的差别我门就会发现，撰写需求的目的、管理的视角和读者都是不同的。

• 撰写需求规格说明的目的：对小型项目来说，撰写需求规格说明的目的是为了提升程序员对问题领域的了解并反馈给用户。而对大型项目来说，撰写需求规格说明的目的是为了把所有相关的细节沟通给参与项目的所有研发人员，因此项目的详细程度决定了人们对问题理解的精确性和详细程度。
• 从管理的角度：小型项目的资源已经固定的，无论文档的如何撰写，资源都将是不会再改变的。而对大型项目来说，需要根据规格说明中的功能点工作量来分配人员和时间，对项目任务进行规划，因此文档变得非常的重要，是很多后续工作的参照衣据。
• 从读者的角度：小型项目的参与人员较少，因比它的读者仅仅是撰写备忘录的作者自身以及需要和他确认的客户，而客户在这里只需要了解工作的要点就可了，两者遇到问题的时候可以随时沟通。而对大型项目来说，团队人数较多，后续的测试人员、相关的管理人员都需要随时参考需求规格说明，对项目的进度进行控制、对项目的质量进行把握。因此需求规格说明也许成了整个团队唯一的共同沟通媒介，我们需要采用更审慎的方法来撰写和管理需求规格说明。

生成不同风格SRS的方法总览

需求规格说明的撰写者可以是项目的招标方，也可以是项目的投标方，或者部分系统研发人员，当然也可以出多方共同商讨完成。不同类型的需求规格说明适合不同类型的项目，如下表所示：

用户手册

Fred Brooks 在《人月神话》中描述了将用户手册作为需求规格说明书的做法，据说在苹果第一台电脑的编码工作开始之前用户手册就写好了。

这些早期成功的故事说明，用户手册作为需求规格说明是一种性价比较高的一箭双雕的做法，通过撰写用户手册，我们同时获得了需求规格说明和用户手册，而且用户手册作为需求规格说明对于和用户交互比较强的系统来说非常有效的，这样的系统往往是由人机交互来驱动。

好的用户手册也描述了所有相关用例的场景。但是用户手册作为需求规格说明也存在一定的局限性，如缺少非功能性需求，以及不和用户交互的功能性需求（如函数计算、过滤器、翻译工具等）。

用户手册大纲

常见的用户手册大纲是：

• 介绍
  • 产品总览及基本原理
  • 术语和基本特征
  • 展示格式与报表格式的总结
  • 本介绍手册的大纲
• 开始
  • 开始使用系统
  • 样例运行
  • 帮助菜单
• 操作模式
  • 命令行、对话框、报告逐一举例
• 高级特性
• 系统命令语法和系统选项

需求规格说明的用户

需求规格说明的用户包括客户和终端用户、系统分析师、开发人员、测试人员、项目管理人员等等。

高质量需求规格说明

需求规格说明要覆盖软件产品的功能、外部接口、性能、质量属性、设计约束，而不应该包括项目的开发计划、产品的质量保证计划和具体的设计方案。

一个高质量的需求规格说明是所有需求的集合，它描述产品要提供的所有的功能，是软件系统解决方案的商业合同的基础，是测试计划的参考依据，它需要定义产品需求的度量标准，是后续产品需求跟踪的先决条件，它会影响产品的开发项目计划，但是在需求规格说明中不可以包括项目的开发计划、产品的质量保证计划和具体的设计方案。

需求规格说明的质量要从一下方面进行评价：

• 正确性：即是经过验证的，真正表达了干系人的需求，同时也没有引入不必要的噪声需求；
• 无歧义：指对每一个需求项都只有一种合理的解释，不会导致误解；
• 完整性：指涵盖了所有必要的功能，也给出了系统不应具有的行为。在概念上具备完整性，覆盖了所有可能的输入情况；在结构上也具备完整性，没有尚未添加的部分；
• 可测试性：即每一条需求都是可以证明的，有一个测试其满足程度的过程；
• 可修改性：指需求的来源清楚，每条需求都有其唯一的索引号，以备未来的引用；
• 可跟踪性：从结构和相互引用的逻辑上都具有清晰的条例，确保需求项的修改不会面临太大的困难；
• 易理解性：可被非专业人士阅读、理解；
• 一致性：需求在说法上不会存在自相矛盾的情况，术语的使用和引用也是一致的、连贯的；
• 有序性：需求之间按重要程度或稳定性，排优先级顺序，
• 以及项目或产品特定的其他特征

建立高质量的需求规格说明是未来项目成功的必要保证之一，但建立完美的需求规格说明也是不必要、不现实的，如下图所示：

图中可看到，这些评价指标之间是存在着一定的制约和平衡关系。

除了上面的评价标准以为，还应该注意保证需求规约是简洁的。怎样才算简洁呢？应该有如下特征：

• 只描述系统的一个独立特征
• 除了必需的信息外没有包含其他信息
• 用清晰、简单、容易理解的词表述
• 避免“应该”、“可以”、“可能”之类的不确定的用词

例如：说法一是“急救电话的响应应本着先到先响应的原则” ，说法二是“急救电话应按照其拨入的次序存入一个先入先出的等待队列当中，并且按照进入队列的次序逐一应答”，显然说法一比说法二是相对简洁的。

从需求数据库中生成需求规格说明

使用需求数据库的时候，创建任何类型的需求规格说明，都优先通过需求数据库来进行生成。所有的修改不要直接在规格说明上进行，而是首先修改数据库中的需求相关数据，然后从新生成需求规格说明。

需求规格说明的结构

基于子系统划分来组织需求规格说明就如图中的分层结构，我们将整体的系统需求描述按不同粒度、不同层次的子系统组织相关的内容，然后为每个子系统单独撰写相应的需求描述。这种分层结构可以包含要开发的软硬件的模块。

需求规格说明SRS模板

需求规格说明可以按照预先定义好的模板来组织章节的内容。模板的存在使撰写统一标淮的需求规格说明变得非常简单，也有利于质量保证人员QA定义需求规格说明的评估指标。模板即可以用于撰写业务需求，也可以撰写系统需求，当我们把模板嵌入到需求工程工具中时，就可以自动或者半自动的从需求数据库或用例模型生成需求规格说明。

IEEE-830 SRS模板大纲

图中右边黄色部分是文档的结构，IEEE建议的模板中，首先要介绍项目的基本范围和目标，给出术语的定义，然后从总体上描述系统的外部接口、相关的用户、软硬件平台以及操作和节点上的一些要求。之后对系统特殊的功能性、非功能性需求给出详细的描述。

IEEE模板中，第三部分是最关键的内容，细分内容如下图所示：

• 外部接口
  • 用户接口
  • 硬件接口
  • 软件接口
  • 通信接口
• 功能性需求：可通过系统的操作模式、用户分类、特征分类来定义
• 性能需求：定义可测量的性能指标
• 设计约束：从下面方面给出在系统设计个过程中需要注意的来自外部条件的约束条件
  • 标准依从性
  • 硬件限制
• 软件系统质量属性：质量相关的属性
  • 可靠性
  • 可用性
  • 安全性
  • 可维护性
  • 可移植性

SRS模板的优缺点

优点：

• 提高需求撰写的效率
• 在有模板的情况下，面对一个完整的大纲，不容易遗漏重要的信息

缺点：

• 并非适用于所有的系统
• 模板的章节设计都是类似的
• 如果仅仅为了满足标准的要求而填写模板的所有章节，在一些不相关的章节就会加入一些不是很有意义的内容
• 读者很唯将这些无意义的文字和真正的需求分开

总结

需求撰写主要出于以下的目标：

• 在干系人之间沟通需求
• 建立合同约定，为后续的验证提供基准，为后面的需求变更提供参考
• 需求的规约可以给技术和非技术的用户来使用，因此我们应该尽快的开始撰写需求，产生一个初始的版本来获取用户反馈
• 确定哪些属性可以用于进一步细化分类需求，将其定义到需求的列表当中
• 在遇到问题的时候直接询问用户往往比咨询场外的专家更为有用

在撰写需求的时候要遵循以下法则：

• 使用简单直接的语言让非技术人员能够读懂
• 撰写可测试的需求，为需求的验证提供帮助
• 使用定义好并已经达成共识的术语
• 一次只写一项需求，保持需求项之间的独立性

由于项目的需求有很大的不同，因此投放在需求撰写中的代价和时间应该是和需求可能造成的影响成正比的。

获取到原始需求之后，应该本着「随时准备迎接需求的变化」的这样一种态度，由于越多的干系人参与需求获取就获得越多的需求特征，但是我们不能通过减少干系人的方法来解决这个问题，因为干系人代表着一个独特的视角，而且干系人有改变他们想法的权利。我们不要总是追问“这是你最终的需求吗”，我们应该把变化看成是改进系统的机会，而不是威胁项目的一个危险。