1S Softwareoftware R Requirementsequirements E Engineeringngineering软件需求工程软件需求工程 郑州大学软件学院 软件工程专业必修课程授课对象:本科3年级授课教师:徐强22 Requirements Specification需求规格说明 33软件需求规格说明编写需求文档的原则需求示例改进前后质量属性软件需求规格说明模板本章内容44SRS Document软件需求规格说明55可以用三种方法编写软件需求规格说明：用好的结构化的自然语言编写文本型文档。建立图形化模型，这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系。编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。编写软件需求规格说明66虽然结构化的自然语言具有许多缺点，但在大多数软件工程中，它仍是编写需求文档最现实的方法。包含了功能和非功能需求的基于文本的软件需求规格说明已经为大多数项目所接受。图形化分析模型通过提供另一种需求视图，增强了软件需求规格说明。由于形式化规格说明具有很强的严密性和精确度，因此，所使用的形式化语言只有极少数软件开发人员才熟悉，更不用说客户了。编写软件需求规格说明77关于SRS软件需求规格说明，也称为功能规格说明、需求协议以及系统规格说明。它精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件。软件需求规格说明不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，软件需求规格说明不应该包括设计、构造、测试或工程管理的细节。88关于SRS软件需求规格说明作为产品需求的最终成果必须具有综合性：必须包括所有的需求。开发者和客户不能作任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明，那么它将不能作为协议的一部分并且不能在产品中出现。毫无疑问，必须在开始设计和构造之前编写出整个产品的软件需求规格说明。可以反复地或以渐增方式编写需求规格说明。99SRS的阅读者不同人员使用软件需求规格说明来达到不同的目的：客户和营销部门依赖它来了解他们所能提供的产品。项目经理根据包含在软件需求规格说明中描述的产品来制定规划并预测进度安排、工作量和资源。软件开发小组依赖它来理解他们将要开发的产品。测试小组使用软件需求规格说明中对产品行为的描述制定测试计划、测试用例和试过程。软件维护和支持人员根据SRS了解产品的某部分是做什么的。产品发布组在SRS和用户界面设计的基础上编写客户文档，如用户手册和帮助屏幕等。培训人员根据SRS和用户文档编写培训材料。1010SRS的可读性可读性的建议：对节、小节和单个需求的号码编排必须一致。右边部分留下文本注释区。允许不加限制地使用空格。正确使用各种可视化强调标志（例如，黑体、下划线、斜体和其它不同字体）。创建目录表和索引表有助于读者寻找所需的信息。对所有图和表指定号码和标识号，并且可按号码进行查阅。使用字处理程序中交叉引用的功能来查阅文档中其它项或位置，而不是通过页码或节号。1111标识需求为了满足软件需求规格说明的可跟踪性和可修改性的质量标准，必须唯一确定每个软件需求。这可以在变更请求、修改历史记录、交叉引用或需求的可跟踪矩阵中查阅特定的需求。由于要达到这一目的，用单一的项目列表是不够的，因此，描述几个不同的需求标识方法，并阐明它们的优点与缺点。可以根据情况选择最适合的方法。1212Identifying requirements 标识需求1) 序列号 最简单的方法是赋予每个需求一个唯一的序列号，例如UR-2或SRS13。当一个新的需求加入到商业需求管理工具的数据库之后，这些管理工具就会为其分配一个序列号（许多这样的工具也支持层次化编号）。序列号的前缀代表了需求类型，例如UR代表“用户需求”。由于序列号不能重用，所以把需求从数据库中删除时，并不释放其所占据的序列号，而新的需求只能得到下一个可用的序列号。这种简单的编号方法并不能提供任何相关需求在逻辑上或层次上的区别，而且需求的标识不能提供任何有关每个需求内容的信息。1313Identifying requirements 标识需求2) 层次化编码 这也许是最常用的方法。如果功能需求出现在软件需求规格说明中第3.2部分，那么它们将具有诸如3.2.4.3这样的标识号。标识号中的数字越多则表示该需求越详细，属于较低层次上的需求。这种方法简单且紧凑，（字处理程序可能可以自动编排序号）。然而，即使在一个中型的软件需求规格说明中，这些标识号也会扩展到许多位数字，并且这些标识也不提供任何有关每个需求目的的信息。如果要插入一个新的需求，那么该需求所在部分其后所有需求的序号将要增加。删除或移去一个需求，那么该需求所在部分其后所有需求的序号将要减少。这些变化将破坏系统其它地方需求的引用。1414Identifying requirements 标识需求2) 层次化编码 （contd.）对于这种简单的层次化编号的一种改进方法是对需求中主要的部分进行层次化编号，然后对于每个部分中的单一功能需求用一个简短文字代码加上一个序列号来识别。例如，软件需求规格说明可能包含“第3.2.5部分编辑功能”，那么这一部分需求的编号可以写成ED-1、ED-2等等。这种方法具有层次性和组织性，同时使标识号简短和具有一定意义并与位置无关等特点。如果要在ED-1和ED-2之间插入新的需求ED-9，则不必对该部分中余下的需求重新编号。1515Identifying requirements 标识需求 3) 层次化文本标签基于文本的层次化标签方案来标识单个需求（Gilb 1988）。考虑这样一个需求：“当用户请求打印超过10个副本时，系统必须让用户进行确认判断。”这一需求可能被标识为“打印.副本.确认”，这意味着这个需求是打印功能的一部分，并且与要打印的副本数量的设置问题有关。层次化文本标签是结构化的，具有语义上的含义，并且不受增加、删除或移动其它需求的影响。它们的主要缺点是文本标签比层次化数字标识码复杂。1616处理不完整性有时会缺少特定需求的某些信息。在解决这个不确定性之前，可能必须与客户商议、检查与另一个系统的接口或者定义另一个需求。使用“待确定”（to be determined, TBD）符号作为标准指示器来强调软件需求规格说明中这些需求的缺陷（gap）。通过这种方法，可以在软件需求规格说明中查找所要澄清需求的部分。记录谁将解决哪个问题、怎样解决及什么时候解决。把每个TBD编号并创建一个TBD列表，这有助于方便地跟踪每个项目。在继续进行构造需求集合之前，必须解决所有的TBD问题，因为任何遗留下来的不确定问题将会增加出错的风险和需求返工。当开发人员遇到一个TBD问题或其它模糊之处时，他可能不会返回到原始需求来解决问题。多半开发者对它进行猜测，但并不总是正确的。如果有TBD问题尚未解决，而又要继续进行开发工作，那么尽可能推迟实现这些需求，或者解决这些需求的开放式问题，把产品的这部分设计得易于更改。1717关于用户界面把用户界面的设计编入软件需求规格说明既有好处也有坏处。Disadvantage 消极方面，屏幕映像和用户界面机制是解决方案（设计）的描述，而不是需求。如果在完成了用户界面的设计之后才能确定软件需求规格说明，那么需求开发的过程将会花费很长的时间。这将会使那些只关心需求开发时间的经理、客户或开发人员失去耐心。用户界面的布局不能替代定义功能需求。不要指望开发人员可以从屏幕中推断出潜在的功能和数据关系。把用户界面的设计加入软件需求规格说明还意味着开发人员在更改一个用户界面的元素时必须相应更改需求的过程。1818关于用户界面Advantage 积极方面，探索潜在的用户界面有助于精化需求并使 用户系统 的交互对用户和开发人员更具有实在性。用户界面的演示也有助于项目计划的制定和预测。根据以往类似开发活动的经验，可以数清图形用户界面（GUI）的元素数目或者计算与每个屏幕有关的功能点数目，然后估计实现这些屏幕功能所需的工作量。1919权衡点一个合理的权衡点是：在软件需求规格说明中加入所选择的用户界面组件的概念映像草图，而在实现时并不一定要精确地遵循这些方法。通过使用另一种方式来表示需求，从而增强相互交流的能力，但并不增加对开发人员的限制，也不增加变更管理过程的负担。例如，一个复杂对话框的最初草案将描述支持需求部分的意图，但是一个有经验的设计者可以把它转化为一个带有标签组件的对话框或使用其它方法以提高其可用性。2020需求文档模板 每个软件开发组织都应该在它们的项目中采用一种标准的软件需求规格说明的模板。许多人使用来自IEEE标准830-1998的模板，“IEEE推荐的软件需求规格说明的方法” （IEEE 1998） 。GB8567-88模板GBT9385-2008计算机软件需求规格说明规范2121软件需求规格说明编写需求文档的原则需求示例改进前后质量属性软件需求规格说明模板本章内容2222Principle of SRS编写需求文档的原则2323需求文档的原则编写优秀的需求文档没有现成固定的方法，最好是根据经验进行。从过去所遇到的问题中可使你受益匪浅。在编写软件需求文档时，应牢记以下几点建议：1.保持语句和段落的简短。2.采用主动语态的表达方式。3.编写具有正确的语法、拼写和标点的完整句子。4.使用的术语与词汇表中所定义的应该一致。2424需求文档的原则5.需求陈述应该具有一致的样式，例如“系统必须”或者“用户必须”，并紧跟一个行为动作和可观察的结果。例如，“仓库管理子系统必须显示一张所请求的仓库中有存货的化学药品容器清单。”6.为了减少不确定性，必须避免模糊的、主观的术语，例如，用户友好、容易、简单、迅速、有效、支持、许多、最新技术、优越的、可接受的和健壮的。当用客说“用户友好”或者“快”或者“健壮”时，你应该明确它们的真正含义并且在需求中阐明用户的意图。7.避免使用比较性的词汇，例如：提高、最大化、最小化和最佳化。定量地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值。当客户说明系统应该“处理”、“支持”或“管理”某些事情时，你应该能理解客户的意图。含糊的语句表达将引起需求的不可验证。2525细节由于需求的编写是层次化的，因此，可以把顶层不明确的需求向低层详细分解，直到消除不明确性为止。编写详细的需求文档，所带来的益处是如果需求得到满足，那么客户的目的也就达到了，但是不要让过于详细的需求影响了设计。2626方针文档的编写人员必须以相同的详细程度编写每个需求文档。文档的编写人员不应该把多个需求集中在一个冗长的叙述段落中。在需求中诸如“和”，“或”之类的连词就表明了该部分集中了多个需求。务必记住，不要在需求说明中使用“和/或”，“等等”之类的连词。文档的编写人员在编写软件需求规格说明时不应该出现需求冗余。虽然在不同的地方出现相同的需求可能会使文档更易读，但这也造成了维护上的困难。需求的多个实例都需要同时更新，以免造成需求各实例之间的不一致。文档的编写人员应考虑用最有效的方法表达每个需求。2727软件需求规格说明编写需求文档的原则需求示例改进前后质量属性软件需求规格说明模板本章内容2828需求示例改进前后2929Example 1“产品必须在固定的时间间隔内提供状态消息，并且每次时间间隔不得小于60秒”。这个需求看起来是不完整的：什么是状态消息，并且在什么情况下向用户提供这些消息？显示时间多长？我们所说的是产品的哪一部分？时间间隔也会导致混淆。假定显示状态消息之间的时间间隔只要求不少于60秒，按这样推理，是否可以每隔一年显示一次状态信息？如果意图是消息之间的时间间隔不多于60秒，那么1毫秒会不会太短？消息显示的时间间隔怎样才能一致？“每次”这个词混淆了这一问题。由于这些问题的存在，导致了需求是不可验证的。3030Example 1（contd.）这里提出一个方法使我们能重写需求文档来表述这些缺点（从我们与客户一致的目标出发作出一些猜测）即：后台任务管理器（BTM）应该在用户界面的指定区域显示状态消息。a. 在后台任务进程启动之后，消息必须每隔60(10)秒更新一次，并且保持连续的可见性。b. 如果正在正常处理后台任务进程，那么后台任务管理器（BTM）必须显示后台任务进程已完成的百分比。c. 当完成后台任务时，后台任务管理器（BTM）必须显示一个“已完成”的消息。d. 如果后台任务中止执行，那么后台任务管理器（BTM）必须显示一个出错消息。3131Example 1（contd.）把原先的需求分割成多个需求，因为每个需求都需要独立的测试用例并且使各个需求都具有可跟踪性。如果把多个需求都集中在一个段落中，那么在构造软件和测试时就很容易忽略其中某个需求。注意，修改之后的需求并没有精确地说明是怎样显示状态信息的。这是一个设计问题，如果你在这个地方详述该问题，那么就会给开发人员带来设计上的一些限制。过早地限制设计上的可选方案将会给编程人员带来不利因素，并可导致产品设计的失败。3232Example 2“产品必须在显示和隐藏非打印字符之间进行瞬间切换”。在瞬间这一时间概念上，计算机不能完成任何工作，因此，这个需求是不可行的。该需求也是不完整的，因为它没有说清状态切换的原因。在特定的条件下，软件产品是否可以进行自动切换或者可否由用户采取某些措施来激发这样转变？还有，在文档中显示转变的范围是什么？是所选的文本、整个文档或其它内容？这个需求也存在一个不确定性问题。“非打印”字符是否指隐藏文本、属性标记或者其它的控制字符？由于存在这些问题，该需求是不可验证的。3333Example 2（contd.）用如下的语句描述这个需求可能会更好一些：“用户在编辑文档时，通过激活特定的触发机制，可以在显示和隐藏所有HTML标记之间进行切换”。现在，指代关系就清楚了，非打印字符指的是HTML标记。修改过的需求指明了是用户触发了显示状态的转换，但是它并没有对设计造成限制，因为它并没有精确定义所使用的机制。当设计人员选择好一种触发机制（例如热键、菜单命令或语音输入）时，你就可以编写详细的测试用例来验证这种转换操作是否正确。3434Example 3“分析程序应该能生成HTML标记出错的报告，这样就可以使HTML的初学者使用它来迅速排错。”“迅速”这个词具有模糊性。缺乏对出错报告内容的定义表明该需求是不完整的。是如何验证这个需求的？找一些HTML的初学者，看他们利用这个报告是否可以迅速排错？还有一点不清楚的是：HTML初学者使用的是分析程序还是出错报告。并且何时生成这样的报告？3535Example 3（contd.）让我们使用另一种方式表述这个需求：a. 在HTML分析程序完全分析完一个文件后，该分析程序必须生成一个出错报告，这个报告中包含了在分析文件过程中所发现错误的HTML所在的行号以及文本内容，还包含了对每个错误的描述。b. 如果在分析过程中未发现任何错误，就不必生成出错报告。现在我们知道了任何生成出错报告及其所包含的内容，但是我们已经把该需求提交给设计人员，让他们来决定报告的形式。我们还指明了一种例外情况：如果没有任何错误，就不生成出错报告。3636Example 4“如果可能的话，应当根据主货物编号列表在线确认所输入的货物编号。”“如果可能的话”这句话意味着什么？该需求是否在技术上可行？是否可以在线访问主货物编号列表？如果你不能确信是否可以递交一个请求，那么就使用“待确定” ( TBD )来表示未解决的问题。这个需求是不完整的，因为它并没有指明如果确认通过或失败，将会发生什么情况。应该尽量避免使用不精确的词汇，例如“应当”。客户可能需要这个功能或者不需要这个功能。一些需求规格说明利用关键字之间微妙的差别如“应当”，“必须”和“可能”来指明重要性。一些人更喜欢使用“必须”或“将要”来明确说明需求的目的并且明确指定其优先级。3737Example 4（contd.）改进后的该需求描述如下：“系统必须根据在线的主货物编号列表确认所输入的货物编号。如果在主列表中查不到该货物的编号，系统必须显示一个出错消息并且拒绝订货。”第二种相关需求可能记录了一种异常情况：当进行货物编号确认时，主货物编号列表不可访问。3838Example 5“产品不应该提供将带来灾难性后果的查询和替换选择。”“灾难性后果”的含义是解释的中心词。在编辑文档时，毫无目的地作出全局性变化而用户又不能检测出错误或没有任何办法来纠正它，此时就可能带来灾难性后果。也要合理地使用反面需求，因为这些需求描述了系统所不能做的事情。潜在的关注焦点在于当发生意外损坏时，能保护文件的内容。也许，真正的需求是针对多级撤销( undo )能力、全局变化或其它可导致数据丢失行为确定的。3939软件需求规格说明编写需求文档的原则需求示例改进前后质量属性软件需求规格说明模板本章内容4040Quality Attribute质量属性4141质量属性（非功能属性）用户对产品如何良好地运转抱有许多期望。这些特性包括：产品的易用程度如何，执行速度如何，可靠性如何，当发生异常情况时，系统如何处理。这些被称为软件质量属性(或质量因素)的特性是系统非功能（也叫非行为）部分的需求。Quality Attribute（质量属性）是很难定义的，并且他们经常造成开发者设计的产品和客户满意的产品之间的差异。“真正的现实系统中，在决定系统的成功或失败的因素中，真正的现实系统中，在决定系统的成功或失败的因素中，满足非功能需求往往比满足功能需求更为重要满足非功能需求往往比满足功能需求更为重要”。 -Robert Charette(1990) 4242质量属性虽然有许多产品特性可以称为质量属性(Quality Attribute)，但是在许多系统中需要认真考虑的仅是其中的一小部分。如果开发者知道哪些特性对项目的成功至关重要，那么他们就能选择软件工程方法来达到特定的质量目标。 （ Glass 1992; DeGrace and Stahl 1993）。根据不同的设计可以把质量属性分类。 （ Boehm 1976; DeGrace and Stahl 1993）。一种属性分类的方法是把在运行时可识别的特性与那些不可识别的特性区分开（ Bass, Clements and Kazman 1998）。另一种方法是把对用户很重要的可见特性与对开发者和维护者很重要的不可见特性区分开。那些对开发者具有重要意义的属性使产品易于更改、验证，并易于移植到新的平台上，从而可以间接地满足客户的需要。4343质量属性ISO/IEC 9126将软件的质量分为六个特征：4444软件质量属性4545定义质量属性必须根据用户对系统的期望来确定质量属性。定量地确定重要属性提供了对用户期望的清晰理解，这将有助于设计者提出最合理的解决方案。-Gilb 1988然而，大多数用户并不知道如何回答诸如“互操作性对你的重要性如何？”或者“软件应该具有怎样的可靠性？”等问题。在一个项目中，分析员想出了对于不同的用户类可能很重要的属性，并根据每一个属性设计出许多问题。他们利用这些问题询问每一个用户类的代表，可以把每个属性分成一级（不必多加考虑的属性）到五级（极其重要的属性）。这些问题的回答有助于分析员决定哪些质量特性用作设计标准是最重要的。4646定义质量属性然后，分析员与用户一起为每一属性确定特定的、可测量的和可验证的需求（Robertson 1997）。如果质量目标不可验证，那么就说不清是否达到这些目标。在合适的地方为每一个属性或目标指定级别或测量单位，以及最大和最小值。如果不能定量地确定某些对你的项目很重要的属性，那么至少应该确定其优先级。IEEE关于软件质量度量方法的标准提出了一个在综合质量度量基准体系下定义软件质量需求的方法（ IEEE 1992）4747定义质量属性另一个定义属性的方法是确定任何与质量期望相冲突的系统行为（ Voas 1999）。通过定义不悦人意行为一种反向需求可以设计出强制系统表现出那些行为的测试用例。如果不能强制系统，那么可能达到了属性目标。这种方法最适用于要求安全性能很高的应用程序，在这些应用程序中，系统的差错可能会导致生命危险。4848对用户重要的属性1)Availability 有效性 有效性指的是在预定的启动时间中，系统真正可用并且完全运行时间所占的百分比。更正式地说，有效性等于系统的平均故障时间（MTTF）除以平均故障时间与故障修复时间之和。有些任务比起其它任务具有更严格的时间要求，此时，当用户要执行一个任务但系统在那一时刻不可用时，用户会感到很沮丧。询问用户需要多高的有效性，并且是否在任何时间，对满足业务或安全目标有效性都是必须的。一个有效性需求可能这样说明：“工作日期间，在当地时间早上6点到午夜，系统的有效性至少达到99.5 %，在下午4点到6点，系统的有效性至少可达到99.95%。4949对用户重要的属性2) Efficiency 效率效率是用来衡量系统如何优化处理器、磁盘空间或通信带宽的（ Davis 1993）。如果系统用完了所有可用的资源，那么用户遇到的将是性能的下降，这是效率降低的一个表现。拙劣的系统性能可激怒等待数据库查询结果的用户，或者可能对系统安全性造成威胁，就像一个实时处理系统超负荷一样。为了在不可预料的条件下允许安全缓冲，可以这样定义：“在预计的高峰负载条件下， 10%处理器能力和15%系统可用内存必须留出备用。”在定义性能、能力和效率目标时，考虑硬件的最小配置是很重要的。5050对用户重要的属性3) Flexibility 灵活性就像我们所知道的可扩充性、增加性、可延伸性和可扩展性一样，灵活性表明了在产品中增加新功能时所需工作量的大小。如果开发者预料到系统的扩展性，那么他们可以选择合适的方法来最大限度地增大系统的灵活性。灵活性对于通过一系列连续的发行版本，并采用渐增型和重复型方式开发的产品是很重要的。example：“一个至少具有6个月产品支持经验的软件维护程序员可以在一个小时之内为系统添加一个新的可支持硬拷贝的输出设备。”5151对用户重要的属性4) Integrity 完整性完整性（或安全性）主要涉及：防止非法访问系统功能、防止数据丢失、防止病毒入侵并防止私人数据进入系统。完整性对于通过WWW执行的软件已成为一个重要的议题。电子商务系统的用户关心的是保护信用卡信息， Web的浏览者不愿意那些私人信息或他们所访问过的站点记录被非法使用。完整性的需求不能犯任何错误，即数据和访问必须通过特定的方法完全保护起来。用明确的术语陈述完整性的需求，如身份验证、用户特权级别、访问约束或者需要保护的精确数据。一个完整性的需求样本可以这样描述：“只有拥有查账员访问特权的用户才可以查看客户交易历史。”5252对用户重要的属性5) Interoperability 互操作性互操作性表明了产品与其它系统交换数据和服务的难易程度。为了评估互操作性是否达到要求的程度，必须知道用户使用其它哪一种应用程序与产品相连接，还要知道他们要交换什么数据。example：“化学制品跟踪系统应该能够从ChemiDraw和Chem-Struct工具中导入任何有效化学制品结构图。”5353对用户重要的属性6) Reliability 可靠性可靠性是软件无故障执行一段时间的概率（Musa, Iannino and Okumoto 1987）。健壮性和有效性有时可看成是可靠性的一部分。衡量软件可靠性的方法包括正确执行操作所占的比例，在发现新缺陷之前系统运行的时间长度和缺陷出现的密度。根据如果发生故障对系统有多大影响和对于最大的可靠性的费用是否合理，来定量地确定可靠性需求。如果软件满足了它的可靠性需求，那么即使该软件还存在缺陷，也可认为达到其可靠性目标。要求高可靠性的系统也是为高可测试性系统设计的。Example:“由于软件失效引起实验失败的概率应不超过5”。5454对用户重要的属性7) Robustness 健壮性健壮性指的是当系统或其组成部分遇到非法输入数据、相关软件或硬件组成部分的缺陷或异常的操作情况时，能继续正确运行功能的程度。健壮的软件可以从发生问题的环境中完好地恢复并且可容忍用户的错误。当从用户那里获取健壮性的目标时，询问系统可能遇到的错误条件并且要了解用户想让系统如何响应。“所有的规划参数都要指定一个缺省值，当输入数据丢失或无效时，就使用缺省值数据。”这个例子反映了对一个“用户”是另一个软件应用程序的产品，其健壮性设计的方法。5555对用户重要的属性8) Usability 可用性可用性也称为“易用性”和“人类工程”，它所描述的是许多组成“用户友好”的因素。可用性衡量准备输入、操作和理解产品输出所花费的努力。必须权衡易用性和学习如何操纵产品的简易性。对于可用性的讨论可以得出可测量的目标，例如:一个培训过的用户应该可以在平均3分钟或最多5分钟时间以内，完成从供应商目录表中请求一种化学制品的操作。可用性还包括对于新用户或不常使用产品的用户在学习使用产品时的简易程度。易学程度的目标可以经常定量地测量。例如，“一个新用户用不到3 0分钟时间适应环境后，就应该可以对一个化学制品提出请求”，或者“新的操作员在一天的培训学习之后，就应该可以正确执行他们所要求的任务的95%”。当定义可用性或可学性的需求时，应考虑到在判断产品是否达到需求而对产品进行测试的费用。5656对开发者重要的属性1)Maintainability 可维护性可维护性表明了在软件中纠正一个缺陷或做一次更改的简易程度。可维护性取决于理解软件、更改软件和测试软件的简易程度，可维护性与灵活性密切相关。高可维护性对于那些经历周期性更改的产品或快速开发的产品很重要。可以根据修复（fix）一个问题所花的平均时间和修复正确的百分比来衡量可维护性。Example:“函数调用不能超过两层深度“，并且“每一个软件模块中，注释与源代码语句的比例至少为12”。5757对开发者重要的属性2) Portability 可移植性可移植性是度量把一个软件从一种运行环境转移到另一种运行环境中所花费的工作量。软件可移植的设计方法与软件可重用的设计方法相似（ Glass 1992）。可移植性对于工程的成功是不重要的，对工程的结果也无关紧要。可以移植的目标必须陈述产品中可以移植到其它环境的那一部分，并确定相应的目标环境。于是，开发者就能选择设计和编码方法以适当提高产品的可移植性。5858对开发者重要的属性3) Reusability 可重用性从软件开发的长远目标上看，可重用性表明了一个软件组件除了在最初开发的系统中使用之外，还可以在其它应用程序中使用的程度。比起创建一个打算只在一个应用程序中使用的组件，开发可重用软件的费用会更大些。可重用软件必须标准化、资料齐全、不依赖于特定的应用程序和运行环境，并具有一般性（ DeGrace and Stahl 1993）。确定新系统中哪些元素需要用方便于代码重用的方法设计，或者规定作为项目副产品的可重用性组件库。5959对开发者重要的属性4) Testability 可测试性可测试性指的是测试软件组件或集成产品时查找缺陷的简易程度。如果产品中包含复杂的算法和逻辑，或如果具有复杂的功能性的相互关系，那么对于可测试性的设计就很重要。如果经常更改产品，那么可测试性也是很重要的，因为将经常对产品进行回归测试来判断更改是否破坏了现有的功能性。example：“一个模块的最大循环复杂度不能超过20”。循环复杂度度量一个模块源代码中逻辑分支数目（McCabe 1982）。在一个模块中加入过多的分支和循环将使该模块难于测试、理解和维护。如果一些模块的循环复杂度大于2 0，这并不会导致整个项目的失败，但指定这样的设计标准有助于开发者达到一个令人满意的质量目标。6060属性的取舍用户和开发者必须确定哪些属性比其它属性更为重要，并定出优先级。在他们作决策时，要始终遵照那些优先级。6161选择的质量属性之间的正负关系有效性效率灵活性完整性互操作性可维护性可移植性可靠性可重用性健壮性可测试性可用性6262平衡性一个单元格中的加号表明单元格所在行的属性增加了对其所在列的属性的积极影响。例如，增强软件可重用性的设计方法也可以使软件变得灵活、更易于与其它软件组件相连接、更易于维护、更易于移植并且更易于测试。一个单元格中的减号表明单元格所在行的属性增加了对其所在列的属性的不利影响。高效性对其它许多属性具有消极影响。如果你编写最紧凑，最快的代码，并使用一种特殊的预编译器和操作系统，那么这将不易移植到其它环境，而且还难于维护和改进软件。6363平衡性为了达到产品特性的最佳平衡，必须在需求获取阶段识别、确定相关的质量属性，并且为之确定优先级。当为项目定义重要的质量属性时，利用上图可以防止发生与目标冲突的行为。在软件中，其自身不能实现质量特性的合理平衡。在需求获取的过程中，加入对质量属性期望的讨论，并把所了解的写入软件需求规格说明中。这样，才有可能提供使所有项目风险承担者满意的产品。6464软件需求规格说明编写需求文档的原则需求示例改进前后质量属性软件需求规格说明模板本章内容软件需求规格说明模板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. 其它非功能需求 e.1 性能需求 e.2 安全设施需求 e.3 安全性需求 e.4 软件质量属性 e.5 业务规则 e.6 用户文档f. 其它需求附录A：词汇表附录B：分析模型附录C：待确定问题的列表从从IEEE 830IEEE 830标准改写并扩充的软件需求规格说明的模板标准改写并扩充的软件需求规格说明的模板 需求规格说明模板-引言 a. 引言引言提出了对软件需求规格说明的纵览，这有助于读者理解文档如何编写并且如何阅读和解释。a.1 目的对产品进行定义，在该文档中详尽说明了这个产品的软件需求，包括修正或发行版本号。如果这个软件需求规格说明只与整个系统的一部分有关系，那么只定义文档中说明的部分或子系统。a.2 文档约定描述编写文档时所采用的标准或排版约定，包括正文风格、提示区或重要符号。列如，说明了高层需求的优先级是否可以被其所有细化的需求继承，或者每个需求陈述是否都有其自身的优先级。 需求规格说明模板-引言 a.3 预期的读者和阅读建议列举了软件需求规格说明所针对的不同读者，列如开发人员、项目经理、营销人员、用户、测试人员或文档的编写人员。描述了文档中剩余部分的内容及其组织结构。提出了最适合于每一类型读者阅读文档的建议。a.4 产品的范围提供了对指定的软件及其目的的简短描述，包括利益和目标。把软件与企业目标或业务策略相联系。可以参考项目视图和范围文档而不是将其内容复制到这里。a.5 参考文献列举了编写软件需求规格说明时所参考的资料或其它资源。这可能包括用户界面风格指导、合同、标准、系统需求规格说明、使用实例文档，或相关产品的软件需求规格说明。在这里应该给出详细的信息，包括标题名称、作者、版本号、日期、出版单位或资料来源，以方便读者查阅这些文献。 需求规格说明模板-综合描述 b.综合描述这一部分概述了正在定义的产品以及它所运行的环境、使用产品的用户和已知的限制、假设和依赖。b.1 产品的前景描述了软件需求规格说明中所定义的产品的背景和起源。 b.2 产品的功能概述了产品所具有的主要功能。其详细内容将在d中描述，所以在此只需要概略地总结，例如用列表的方法给出。b.3 用户类和特征确定你觉得可能使用该产品的不同用户类并描述它们相关的特征。 需求规格说明模板-综合描述 b.4 运行环境描述了软件的运行环境，包括硬件平台、操作系统和版本，还有其它的软件组件或与其共存的应用程序。 b.5 设计和实现上的限制确定影响开发人员自由选择的问题，并说明这些问题为什么成为一种限制。 b.6 假设和依赖列举出在对软件需求规格说明中影响需求陈述的假设因素（与已知因素相对立）。 需求规格说明模板-外部接口需求 c.外部接口需求需要把对接口数据和控制组件的详细描述写入数据字典中。如果产品的不同部分有不同的外部接口，那么应把这些外部接口的详细需求并入到这一部分的实例中。c.1 用户界面陈述需要的用户界面的软件组件。描述每个用户界面的逻辑特征。 c.2 硬件接口描述系统中软件和硬件每一接口的特征。 c.3 软件接口描述该产品与其他外部组件（由名字和版本识别）的连接，包括数据库、操作系统、工具和集成的商业组件 等。c.4 通信接口描述与产品所使用的通信功能相关的，包括电子邮件、Web浏览器、网络通信标准或协议及电子表格等等。需求规格说明模板-系统特性 d.系统特性功能需求是根据系统特性即产品所提供的主要服务来组织的。可以通过使用实例、运行模式、用户类、对象类或功能等级来组织这部分内容。还可以使用这些元素的组合。总而言之，你必须选择一种使读者易于理解预期产品的组织方案。d.1 说明和优先级提出了对该系统特性的简短说明并指出该特性的优先级是高、中，还是低。或者你还可以包括对特定优先级部分的评价，例如利益、损失、费用和风险，其相对优先等级可以从1（低）到9（高）。d.2 激励/响应序列列出输入激励（用户动作、来自外部设备的信号或其它触发器）和定义这一特性行为的系统响应序列。 d.3 功能需求列出与该特性相关的详细功能。 需求规格说明模板-其它非功能需求 e.其它非功能需求这部分列举出了所有非功能需求，而不是外部接口需求和限制。e.1 性能需求阐述了不同的应用领域对产品性能的需求，并解释它们的原理以帮助开发人员作出合理的设计选择。 e.2 安全设施需求详尽陈述与产品使用过程中可能发生的损失、破坏或危害相关的需求。 e.3 安全性需求详尽陈述与系统安全性、完整性或与私人问题相关的需求，这些问题将会影响到产品的使用和产品所创建或使用的数据的保护。 需求规格说明模板-其它非功能需求e.4 软件质量标准属性详尽陈述与客户或开发人员至关重要的其产品质量特性。 e.5 业务规则列举出有关产品的所有操作规则，例如什么人在特定环境下可以进行何种操作。 e.6 用户文档列举出将与软件一同发行的用户文档部分，例如，用户手册、在线帮助和教程。明确所有已知的用户文档的交付格式和标准。需求规格说明模板-其它需求 f. .其它需求定义在软件需求规格说明的其它部分未出现的需求，例如国际化需求或法律上的需求。你还可以增加有关操作、管理和维护部分来完善产品安装、配置、启动和关闭、修复和容错，以及登录和监控操作等方面的需求。在模板中加入与你的项目相关的新部分。如果你不需要增加其它需求，就省略这一部分。 需求规格说明模板-附录 附录A: 词汇表定义所有必要的术语，以便读者可以正确地解释软件需求说明，包括词头和缩写。你可能希望为整个公司创建一张跨越多项项目的词汇表，并且只包括特定于单一项目的软件需求规格说明中的术语。附录B：分析模型这个可选部分包括或涉及到相关的分析模型的位置，例如数据流程图、类图、状态转换图或实体-关系图。 附录C: 待确定问题的列表编辑一张在软件需求规格说明中待确定问题的列表，其中每一表项都是编上号的，以便于跟踪调查。