软件需求分析复习整理

[toc]

第0章 引言

项目失败或严重超支的8个最重要原因中有5个都与需求相关：

1. 需求不完整
2. 缺乏用户的参与
3. 用户期望不实际
4. 需求和需求规格说明的变更
5. 提供许多不必要的功能。

“软件需求分析”：

就是对需要解决的问题进行详细分析

弄清楚需要解决的问题，开发人员才能顺利开发出用户真正需要的软件。

如果一味追求进度，而忽略软件需求分析，很可能南辕北敏，开发变得毫无意义。

“软件需求分析”：是连接开发人员和用户之间的重要纽带。只有真正理解用户的需求，才能设计出用户所需要的软件。

“软件需求分析”：

就是分析软件用户的需求是什么。

如果投入大量的人力、物力、财力、时间，开发出的软件却没人要，那所有的投入都是徒劳。

如果费了很大的精力，开发一个软件系统，最后却不满足用户的要求，从而要重新开发过，这种返工是让人痛心疾首的。

总之，软件需求问题不仅关系到软件项目开发的成功，也关系到软件产业的发展，更关系到各行各业信息化目标的实现。

解决软件需求问题已成为软件领域刻不容缓的任务。

第1章 软件需求概述

软件需求的好坏直接关系到软件的成功与否。

客户提出的需求是软件系统的源头，它定义了软件系统的意图和目的。

如果需求遗漏或完成得不好，不管系统多么完美，系统也是失败的。

为了得到有效的需求，需要采用有效的方法与用户广泛地交流。

定义：

① 用户解决问题或达到目标所需的条件或权能。

② 系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能。

③ 一种反映上面两种所描述的条件或权能的文档说明。

基本原则：

1）并没有一个清晰、毫无歧义性的“需求”术语存在，真正的“需求”实际上在人们的脑海中。

2）定义问题，而不是解决方案。

3）定义系统，而不是项目。需求定义了系统需要做什么：它们是一组目标。

4）区分正式和非正式部分。

5）避免重置。

6）保持每个需求定义的大小在合适的范围内是良好的做法。

软件需求的层次：

1. 业务需求（Business Requirement ）
2. 用户需求（User Requirement）
3. 软件需求（Software Requirement）

业务需求：

是从业务角度描述的，是指导软件开发的高层需求。

业务需求的目标体现在两个方面：

1）问题：解决企业运行过程中遇到的问题。

2）机会：抓住外部环境变化所带来的机会，以便为企业带来新的发展。

业务需求：是从各个不同的人那里收集来的，它们包括主办者、客户、支付或采购软件产品者、开发公司的高级管理人员等。

业务需求：阐明产品的高层次概念和产品的主要业务内容。

业务需求：说明客户、公司和想从该系统获利的风险承担者或从系统中取得结果的用户所要求的目标。

业务需求：为后继工作建立了一个指导性的框架。

用户需求：

是指描述的是用户使用软件需要完成什么任务。

用户需求：是在业务需求基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立用户角度的需求。

用户需求具有两个方面的特点：

1）零散：用户会给出不同角度、不同层面、不同粒度的用户需求。

2）存在矛盾：由于用户的层次不同，导致需求的片面性，甚至在不同用户之间会有不同的观点。

软件需求：

是需求分析与建模的产物。

软件需求：必须根据用户需求来考虑，并要与业务需求所设定的目标相一致。

用户需求：具有零散、存在矛盾的特点。

—— 因此，需求分析人员还需要对其进行分析、提炼、整理，从而生成指导开发的、更精确的软件需求。

软件需求可以分为：

• 功能需求（Functional Requirement）
• 非功能需求（Non-Functional Requirement）
• 设计约束

功能需求：

是一个系统必须提供的活动和服务描述。

功能需求：定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务需求。

开发人员根据功能需求来设计软件以实现必需的功能。

功能需求：描述软件系统所应具有的外部行为，它在开发、测试、质量保证、项目管理以及相关项目功能中都将起到重要的作用。

非功能需求：

描述了系统展现给用户的行为和执行的操作等。

非功能需求：包括外部界面的具体细节、性能要求及质量属性。

非功能需求：是产品必须具备的品质，它们可以让产品更具有吸引力、易于使用、快速、可靠或者安全。

非功能需求：通常并不改变产品的功能。

一般来说，不管增加多少的质量属性，功能需求都会保持不变，功能需求和非功能需求是相辅相成密不可分的。

非功能需求：经常被忽略，因为它们不易被发现，发现后不易表达、实现以及测试。

在系统实现过程中，有时候满足非功能需求往往比满足功能需求更为重要。

设计约束：

是指对开发人员在软件产品设计和构造上的限制，产品必须遵从的标准、规范和合约。

设计约束：包括：非技术因素的技术选型、预期的软硬件环境和预期的使用环境三大类型。

技术开发团队在决定架构、选择技术时，会受到企业实际的软硬件环境的影响，如果忽略了这个方面的因素会给项目带来一些不必要的麻烦。因此，在需求人员整理需求时，应该将这些预期的软硬件环境描述出来。

实现有效的需求工程过程可以让组织受益匪浅。减少开发后期以及整个维护过程中不必要的返工，并可带来极大的回报。

高质量软件需求的可以带来好处：

• 减少需求的缺陷
• 减少开发过程中的返工
• 减少不必要的特性
• 降低改进成本
• 加快开发进度
• 提高沟通效率
• 控制需求范围的改变
• 项目更有序
• 对系统测试的评估更准确
• 10）提高客户和开发人员的满意度

需求陈述的特点：

1. 完整性

   • 每一项需求都必须完整地描述即将交付使用的功能。
   • 它必须包含开发人员设计和实现这项功能需要的所有信息

2. 正确性

   • 每一项需求都必须准确地描述将要开发的功能。
   • 如果一项软件需求与其相对应的系统需求发生冲突就是不正确的。
   • 只有用户代表才能决定用户需求的正确性。

3. 可行性

   • 需求必须能够在系统及其运行环境的已知能力和约束条件内实现，因此，由开发人员来进行可行性检查，判断技术上能够实现哪些需求，或者什么功能需要额外的成本才能实现。

4. 必要性

   • 每一项需求记录的功能都必须是用户的真正需要，或者是为符合外部系统需求或某一标准而必须具备的功能。

   • 每项需求都必须来源于有权定义需求的一方。对每项需求都必须追溯至特定的客户需求的来源。

5. 有优先次序

   • 为每一项功能需求、特性或用例指定一个实现优先级，以表明它在产品的某一版本中的重要程度。
   • 如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度。

6. 无歧义

   • 一项需求对所有读者应该只有一种一致的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户的语言表达出来。
   • 避免二义性的有效方法包括对需求文档的正规审查、编写测试用例、开发原型以及设计特定的方案脚本。

7. 可验证性

   • 检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等方法来确定产品是否确实按需求实现了。
   • 如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。
   • 一份前后矛盾，不可行或有二义性的需求也是不可验证的。

需求规格说明的特点：

1）完整性

不能遗漏任何需求或必要的信息。

需求遗漏问题很难被发现，因为它们并没有列出来，着重于用户任务而不是系统功能会有助于避免遗漏需求。

2）一致性

需求的一致性是指需求不会与同一类型的其他需求或更高层次的业务、系统或用户需求发生冲突。

必须在开发前解决需求不一致的问题。只有经过调查才能知道需求正确与否。

3）可修改性

必须能够对SRS作必要的修订，并可以为每项需求维护修改的历史记录。

这要求对每项需求进行唯一标识，与其他需求分开表述，从而能够明确地提及它。

每项需求只能在SRS中出现一次。

如果有重复的需求，很容易因为只修改其中一项而产生不一致。

4）可跟踪性

需求如果是可跟踪的，就能找到它的来源、它对应的设计单元、实现它的源代码以及用于验证其是否被正确实现的测试用例。

可跟踪的需求都有一个固定的标识符对其唯一标识。

需求与其他软件项目过程的关系

软件需求阶段在系统开发的整个生命周期中处于最基础、最重要的位置。

只有在需求分析工作做得比较扎实到位，文档经过开发方与用户方的充分参与、查验、修改、完善，才能为设计实施迈出坚实的一步。

软件需求活动用于软件项目的初始阶段，它的结果接着用于开发的下一个阶段，即设计阶段。

随着更强调迭代的方法学的出现，需求活动的使用被扩展到每一个开发迭代过程中，而且需求分析和设计的界限也变得模糊。

软件需求阶段是以真实世界建模为对象，并找出系统要处理什么的过程。

此阶段需要把一组复杂的需求分解为基本元素和关系，之后的解决方案建立在这些元素和关系的基础之上。

此阶段的结果是生成软件需求规格说明。

根据项目的大小不同，需求规格说明的详细程度各异，但是即使是最小的项目，也应该有某种成文的需求规格说明供开发团队使用。

需求过程中最为困难工作是编写详细技术需求，这包括所有面向用户、面向机器和其他软件系统的接口等。

这个过程一旦做错，将最终给系统带来极大损害，并且以后再对它进行修改也极为困难。

需求与各过程间的关系

（1）需求与制订项目计划关系

需求是制订项目计划的基础，开发资源和进度安排的预估都要建立在对最终产品的真正理解之上。

项目计划所指出的所有希望特性不可能在允许的资源和时间内完成，因此，需要缩小项目范围或采用版本计划对功能特性进行选择。

（2）需求与项目跟踪和控制关系

在项目实施过程中，要监控每项需求的状态，以便项目管理者能发现设计和验证是否达到预期的要求。

如果没有达到，管理者通常请求变更控制过程来进行范围的缩减。

（3）需求与变更控制关系

在需求编写成文档并制订基线以后，所有后续的变更都应通过确定的变更控制过程来进行。

（4）需求与系统测试关系

用户需求和功能需求是系统测试的重要参考。

如果未清楚说明产品在多种多样条件下的期望行为，系统测试者将很难确定正确的测试内容。

系统测试是一种方法，可以验证计划中所列的功能是否按预期要求实现了。

测试也验证了用户任务是否能正确执行。

5）需求与用户编制文档关系

软件需求是编写文档的重要参考，低质量和拖延的需求会给编写用户文档带来极大的困难，需求文档是所有设计、实现工作的基础。

（6）需求与构造过程关系

构成软件项目的主要产品是交付可执行软件，而不是需求说明文档。

要根据功能需求来确定设计模块，而模块又要作为编写代码的依据。

采用设计评审的方法来确保设计正确地反映了所有的需求。而代码的单元测试能确定是否满足了设计规格说明和相关的需求。

本章小结

（1）软件需求的定义：给出了几种主要的软件需求定义和软件需求定义的一些基本原则。

（2）需求的层次：需求包括三个不同的层次，它们是：业务需求、用户需求和软件需求

（3）软件需求的分类：软件需求可以分为：功能需求、非功能需求和设计约束三种类型。

（4）高质量软件需求的好处及好的软件需求具有的特点。

（5）需求与其他软件项目过程的关系。

第2章 用户眼中的软件需求

软件需求来源于用户，用户是能够直接或间接从软件产品中获益的个人或组织。

软件用户可能提出需求、出钱、选择、说明、使用或者接收软件产品的输出。

用户”是一种泛称，它可细分为：

• “客户”（customer） 掏钱买软件产品的用户称为客户；
• “最终用户”（the end user）真正操作软件产品的用户叫最终用户。
• “间接用户”（或称为关系人）。既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品有很大的影响。
  • 例如：财务软件，开发商在把“财务软件”卖给客户之前，必须得到国家财政部的批准。否则，即使该软件的功能是完美的，但却被政府认为是非法的。所以，国家财政部就是所有财务软件的间接用户。
  • 又例如：市面上流通的信息安全软件、杀病毒软件必须得到国家公安部的批准，否则不能销售

优秀的软件产品建立在优秀的需求基础上，而高质量的需求来源于用户与开发者之间的有效沟通与合作。

协同合作要想取得成果，需要所有人员都清楚自己的需要，理解并尊重其他合作者的需求。

通常用户与开发者要建立合作伙伴关系。

十项软件客户权利清单

1. 要求需求分析员使用客户的语言进行交流
2. 要求需求分析员了解客户的业务和目标
3. 要求需求分析员用适合的形式记录需求
4. 要求需求分析员解释需求过程生成的所有工作结果
5. 要求需求分析员和开发人员尊重客户，并以合作和专业的态度与客户进行互动。
6. 要求需求分析员和开发人员为需求和产品实现提供思路和备用方案
7. 要求开发人员实现能让产品使用起来更容易、更有趣的特性
8. 调整需求，便于重用已有的软件组件
9. 在提出需求变更时，获得对变更的成本、影响及二者权衡关系的真实评估
10. 获得满足功能和质量要求的系统，这些要求必须事先告知开发人员并征得其同意

十项客户的需求义务清单

1. 为需求分析员和开发人员讲解业务并定义业务术语
2. 提供需求，阐明需求，通过与开发人员的交互将需求充实完善
3. 对系统需求的描述必须详细、准确
4. 需要时，及时对需求做出决定
5. 尊重开发人员对需求成本和可行性的评估
6. 与开发人员协作，为功能需求、系统特性和用例设置优先级
7. 审阅需求文档，评估原型
8. 发现需要变更需求时，及时与开发人员沟通
9. 按照开发组织的变更控制过程提出需求变更
10. 尊重需求分析员在需求工程中使用的过程

对需求达成一致

对在建产品的需求达成一致或是在某部分达成一致是客户和开发人员关系的核心。

涉及的多个角色应形成如下共识：

• 客户承认需求描述了他们的需要。
• 开发人员承认理解需求，并且认为它们是可实现的。
• 测试人员承认需求是可验证的。
• 管理层承认需求可以达成他们的业务目标。

第3章 需求工程

需求工程分为：需求开发和需求管理两部分。

需求分析是需求开发的其中一个环节，确立了需求工程与软件工程是同等重要的观念。

需求工程：是确保软件需求质量的。

软件工程：是确保软件开发质量的。

一个软件项目要想成功，必须握有需求工程和软件工程这两把利剑在手。

需求工程：是随着计算机的发展而发展的。

在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，软件需求很少受到重视。

随着软件系统规模的扩大，软件需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。

人们逐渐认识到软件需求活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。

需求工程：是用已证实有效的技术和方法进行需求分析、确定客户需求、帮助分析人员理解问题，并定义目标系统的所有外部特征的一门学科。

需求工程：通过合适工具和记号，描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。

需求工程：可分为：系统需求工程和软件需求工程。

系统需求工程，将软件需求开发和系统需求开发结合起来，在系统工程的开始阶段起到重要的作用。

软件需求工程，是一门分析并记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发，把这些系统需求转换成软件的需求描述和性能参数。

需求工程定义：

Davis的定义：“直到(但不包括）把软件分解为实际架构组建之前的所有活动”，即软件设计之前的一切活动。

Brays的定义：认为需求工程是“对问题域及需求做调查研究和描述，设计满足系统的特性，并用文档给予说明。这个定义明确指出了需求工程的任务就是获取、分析和表达软件的需求”

HerbKrasner（赫克拉斯纳）定义了五阶段生命周期：

1. 需求定义和分析
2. 需求决策
3. 形成需求规格
4. 需求实现与验证
5. 需求演进管理

需求工程：主要是抽取需求、模拟和分析需求、传递需求、认可需求和进化需求。

需求工程的定义：主要是抽取需求、模拟和分析需求、传递需求、认可需求和进化需求。每个活动都有它基本的动机、任务和结果，也有各自的困难所在。

需求工程的组成：需求开发和需求管理两部分。

Ø需求开发包括：需求获取、需求分析、形成需求规格、需求确认。

Ø需求管理包括：需求变更控制、版本控制、需求跟踪、需求状态跟踪。

初始循环

脉络循环

细节循环

第四章 需求获取

需求获取阶段的任务：就是获取用户的需求信息。

需求获取：是软件需求的早期活动，也是十分重要的一步。

由于需求获取是软件开发中最困难、最关键、最易出错和最需要交流的活动，故其只能通过用户与需求分析员之间进行高度的合作和交流才能成功。

需求获取阶段的活动可分为：

1. 确定需求开发计划
2. 确定项目的目标和范围
3. 确定调研对象
4. 需求信息收集

需求开发计划的任务：是确定需求开发的实施步骤，给出收集需求活动的具体安排和进度。

软件需求：是分析、理解和描述用户的需求，着重于软件系统“做什么”，而不是如何实现软件系统。

为了保证软件需求有充分的时间和经费，在安排软件需求的实施步骤、收集需求活动的进度时，只能考虑与需求开发相关的工作。

否则，将会导致软件需求花费的时间过长、成本过高，不利于有效地进行软件需求的活动。

在安排进度时，应考虑困难性和灵活性。

例如：在收集用户需求的活动中，由于用户可能出差或开会，不一定能保证在规定的时间内进行交流，因此，需要与用户预约时间，及时调整时间和计划。

此外，书写和整理需求规格说明也是需花费时间的，故在安排进度和时间时应予以考虑。

项目目标和范围的基本任务是：

—— 根据项目目标把项目相关人员定位到一个共同的和明确的方向上，并决定软件系统的范围。

项目的目标主要包括：

—— 项目开发的目的和意义，以及软件系统应实现的业务需求。

项目的范围：

—— 是指软件系统具体应包括和不应包括的部分，以及软件系统所涉及的各个方面。

如：计算机硬件和其他软件系统等，即软件系统在一个完善的环境中最终具有的功能。

项目的业务需求代表了需求层次中最高层的需求，为软件系统定义了作用的范围。

需求信息的类型

1. 业务需求
   1. 描述用户或开发机构，通过产品可获得的利益和利润。
   2. 以及与产品相关的发展规划等方面的信息。
2. 用例说明
3. 业务规则。有关业务过程的操作原则。
4. 功能需求。定义了系统应该做什么，它们是软件需求规格说明的一部分。
5. 性能需求
6. 外部接口需求
7. 约束
   1. 约束：是指一些合理限制设计者和程序员选择的条件。
   2. 约束：必须写入软件需求规格说明。
   3. 施加不必要的约束，将妨碍提出一个好的解决方案，将会降低利用现有商业化软件集成解决方案的能力，
   4. 一定的约束有助于提高产品质量。
8. 数据定义
   1. 当客户描述一个数据项，或一个复杂的业务数据结构的格式、允许值或默认值时，就是在进行数据定义。
   2. 把这些集中在一个数据词典中，作为项目参与者在整个项目的开发和维护中的主要参考文档。
9. 解决方案
   1. 如果一个客户描述了用户与系统交互的特定方法，使系统产生一系列活动，这时，就是在听取建议性的解决方案，而不是需求。

需求收集中应注意的问题

1. 应能适当地调整收集范围
   • 在收集需求的开始，需求分析员并不知道用户需求量的大小，可以根据系统的范围适当扩大收集范围。
   • 收集的范围不能过于扩大，因为范围扩大，收集的需求有些可能不是真正的需求，将导致分析员要花费大量的精力和时间，来理解和分析这些需求。
   • 收集的范围也不能太小，否则有些重要需求会被遗漏或排除在外。
2. 弄清楚用户所做的假设和冲突。
   • 尽量把用户所做的假设解释清楚，特别是发生冲突的部分。这就需要根据用户的信息去理解。
   • 以明确用户没有表达清楚的需求。
3. 理解用户的思维过程、专业知识和术语。
   • 尽量理解用户的思维过程，特别是尽量熟悉和掌握用户具有的一些专业知识和术语。
4. 避免受不熟悉细节的影响。
5. 避免讨论一些具体的解决方案。
6. 需求收集工作的结束。
   • 如何决定收集工作的结束，并没有一个简单和严格的标准，需根据实际情况进行判断。
   • eg
     • 用户不可能再提供更多新的需求信息。
     • 用户重复提出以前已提出的需求信息。
     • 与用户的讨论开始进入设计方面的工作。
     • 需求分析员本身已提不出更多的问题。
     • 安排收集工作的结束时间已到。
7. 非功能需求的确定
   • 非功能需求：是衡量软件能否良好运行的定性指标。
   • 非功能需求：也是非常重要的。
   • 可靠性、可扩展性、安全性、互操作性、易使用性、可维护性、用户界面友好等。
   • 必须根据用户对系统的期望来确定非功能需求。
8. 收集非功能需求的一些方法：
   1. 将不同用户类代表，提出的可能很重要的非功能需求进行综合，并根据其中的每个需求设计出许多方法，然后，根据用户的回答，使这些需求更明确。
   2. 需求分析员与用户一起对每一个非功能需求，制定可测试和可验证的具体标准。如果这些需求缺乏评价标准，就无法说明开发出的软件系统是否已满足这些需求。
   3. 设计与非功能需求相冲突的假设示例，利用反例来提示用户。

需求获取方法

1. 面向目标的方法
   • 目标是用户所期望达到的目的。
   • 层次性是目标的一个重要特征。
   • 从高层来说，目标是抽象的问题描述。
   • 从底层来说，则是具体的实现方式，即技术需求描述。
   • 这有利于需求的逐步精化，通过需求对高层目标的可追溯性，建立起软件需求与业务目标的关系。
   • 因此，面向目标方法不仅被用来进行需求获取、分析，还被应用于需求协商等领域。
2. 面向目标的方法的优点有：
   1. 容易理解和交流，可以保证需求的完整性、避免无关的需求。
   2. 目标本身所具有的层次关系，使得需求文档更加结构化，增强了可读性。
   3. 有助于将软件需求与业务环境联系起来，有助于解决多视点之间的冲突。
   4. 由于目标方法可以将稳定的需求和经常变化需求区分开，有利于需求的管理。
3. 基于场景的方法
   • 基于场景的方法：是通过应用环境的某一特定情景的描述，来阐述用户的需求。
   • 由于这一方法非常便于涉众之间的交流，并且提供了一种将需求与实际经验相结合的机制，因此，对于需求的获取和确认有很大的帮助。
   • 基于场景的方法：目前应用最广泛的一种就是基于用例的方法。
     • 用例是从用户的观点、以交互的方式，对于系统的行为特征进行的描述，而场景一般认为是用例的一个实例。
4. 面向视点的方法
   • 视点是对于涉众局部观察角度的一种抽象。
   • 在多视点需求工程中，需求分析人员从一组涉众处获取各局部需求，并将其进行整合。
   • 多视点需求工程方法认为，需求之间的冲突往往是由于涉众视点不同所导致的。
   • 因此，完整、一致地发现和集成视点，是获得高质量需求的关键。
   • 多视点方法适应于涉众视角的局部性和分布性特征，反映各种涉众的需求。
5. 基于知识的方法
   • 软件开发是一个知识密集型的活动，知识在其中起到关键的作用。
   • 基于知识的方法的出发点，是希望利用历史项目中，积累的经验或领域分析的结果，来帮助人们理解和获取需求。
   • 事实上，大多数的需求获取方法，都或多或少地用到这一类方法。
6. 面向方面的方法
   • 面向方面的软件开发：是使横切关注点更好地分离的一种技术。
   • 在面向方面的编程中，对于“横切”给出这样的定义：如果被构建的两个属性，必须以不同的方式构造，但它们之间又需要被协同，那么它们彼此横切。
   • 把问题分解为更小的部分，称为关注点分离。
   • 通过对关注点的分离，有助于从不同角度对软件系统进行理解、维护和扩展。
   • 面向方面的方法：在近年来被提出，并受到了研究者的重视。
   • 通常将功能需求作为一组基础，而将非功能需求作为方面级的需求。
   • 面向方面的方法：从编程方法发展而来，它的基本思想和多视角的方法有相似之处，目前，较为成功的应用主要集中在需求的实现。
   • 由于需求之间的关系往往错综复杂，因此，对横切需求的识别仍然是一个难题。

Summary

需求获取阶段的任务：

—— 就是获取用户的需求信息。通过用户与需求分析员之间进行高度的合作和交流才能成功。

需求开发计划：

—— 需求开发计划的任务：是确定需求开发的实施步骤，给出收集需求活动的具体安排和进度。

项目的目标和范围

—— 项目的目标主要包括： 项目开发的目的和意义，以及软件系统应实现的业务需求。

—— 项目的范围： 是指软件系统具体应包括和不应包括的部分，以及软件系统所涉及的各个方面。

需求调研对象：主要是：用户

根据用户的某些方面将用户分类：

根据用户所在的部门和职责分类。

—— 如：计划部门、销售部门、财务部门等。

根据用户使用系统的频繁度和优先级等分类。

根据用户掌握的计算机知识和使用计算机的熟练程度分类。

根据直接使用和非直接使用软件系统的情况分类。

确定需求来源

典型的软件需求来源有以下几方面：

1）直接和间接使用软件系统的用户。

2）系统需求规格说明。

3）市场调研和用户问卷调查。

4）已开发出的和待开发的同类软件系统的描述和文档。

5）人工系统中存在的问题报告。

6）观察正在工作的用户。

7）用户工作内容的分析。

需求调研的三个步骤：

1）向掌握“全局”的负责人调研

2）向部门负责人调研

3）向业务人员调研

明确需求信息的决策者

决策者能根据具体情况，对存在问题需求信息做出决定。

决策者并不是固定不变的，而是根据实际中可能发生的具体问题来确定。

需求信息收集面临的困难

需求信息收集并不是件容易的工作，需求分析员要与用户进行充分的交流，听取用户对软件系统的看法和意见。

但在与用户交流的过程中并非是十分顺利的，特别是需要用户花费时间来讲解他们的业务流程和工作内容。

需求信息收集的方式。

1）座谈会的方式

2）书面咨询的方式

3）利用用例表示方法

需求信息的类型有9种。

1.业务需求

2.用例说明

3.业务规则

4.功能需求

5.性能需求

6.外部接口需求

7.约束

8.数据定义

9.解决方案

需求收集中应注意的一些问题：

1）应能适当地调整收集范围。

2）尽量把用户所做的假设解释清楚，特别是发生冲突的部分。这就需要根据用户的信息去理解，以明确用户没有表达清楚的需求。

3）尽量理解用户的思维过程，特别是尽量熟悉和掌握用户具有的一些专业知识和术语。

4）在收集需求信息时，应尽量避免受不熟悉细节的影响。

5）应尽量避免讨论一些具体的解决方案，因为需求阶段的工作，是要弄清楚软件系统做什么，而不是怎么做。

6）需求收集工作的结束。

非功能需求：

非功能需求：是衡量软件能否良好运行的定性指标。

如：可靠性、可扩展性、安全性、互操作性、易使用性、可维护性、用户界面友好等。

收集非功能需求使用的3种方法：

将重要非功能需求进行综合，并根据其中的每个需求设计出许多方法，根据用户的回答，使这些需求更明确。

方法2：需求分析员与用户一起对每一个非功能需求，制定可测试和可验证的具体标准。

方法3：设计与非功能需求相冲突的假设示例，利用反例来提示用户。

需求获取方法：有5种

1. 面向目标的方法
2. 基于场景的方法
3. 面向视点的方法
4. 基于知识的方法
5. 面向方面的方法

第5章 需求分析

需求分析的任务

通过需求获取阶段的工作，软件开发人员从用户处收集到大量的需求信息。

这些需求信息并不完全都是真正的需求。

需求分析的基本任务：就是分析和综合已收集到的需求信息。

分析：在于透过现象看本质，找出这些需求信息间的内在联系和可能的矛盾。

综合：就是去掉那些非本质的信息，找出解决矛盾的方法，并建立系统的逻辑模型。

具体地说，需求分析的基本任务：就是提炼、分析和仔细审查已收集到的需求信息，找出真正的和具体的需求，以确保所有项目相关人员都明白其含义。

在分析过程中，通过建立软件系统的逻辑模型，发现或找出需求信息中存在的冲突、遗漏、错误或含糊问题等。

需求分析阶段工作结果：是获得高质量的具体软件需求。

需求分析的具体工作包括：

• 建立系统关联图；
• 分析需求的可行性；
• 构建用户分析原型；
• 确定需求的优先级；
• 需求建模；
• 建立数据词典。
• 对于较为简单的系统，确定需求优先级等工作可以考虑不施行。

系统关联图的建立

在需求获取阶段，首先确定收集需求信息的范围，提高需求获取效率，把项目相关人员定位到一个共同的、明确的方向上。

建立系统关联图：主要是根据需求获取阶段确定的系统范围，用图形表示系统与外部实体间的关联。

关联图：就是用于描述系统与外部实体间的界限和接口的模型，而且明确通过接口的信息流和物质流

关联图的建立：

• 把整个要开发的系统表示为一个椭圆，椭圆内标识系统的名字。
• 用箭头表示系统与外部实体间的关系和信息流向。
• 用矩形框表示系统外部实体。

关联图：不明确描述系统的内部过程和数据。

EG

某培训中心的主要工作是为本行业在职人员提供课程培训服务。有兴趣的本行业职工可以通过电子邮件、信函等报名、选修或注销课程，或询问课程计划等。培训中心收取一定的培训费用，学费可以用现金或支票形式支付。

该系统应具有记录和分类由电子邮件或信函表达的信息，处理报名、询问、注销和付款，以及输出回答信息的功能。

该系统外的实体主要是学员和系统的操作员等。

系统的关联图，如图所示。

建立关联图的目的：是项目相关人员一开始不必去考虑太多的细节，而是把注意力集中在软件系统的接口方面。

• 即系统的输入/输出上，从而确定系统的界限，并为分折用户需求提供很好的依据，特别是在功能需求方面。

关联图：以图形方式表示系统的范围，使得项目相关人员更易于理解和审查。

如果某些需求不可实施，例如：开发环境的支持，或技术实现有困难，或处理效率较低等，都应尽早与用户讨论和协商。

分析需求可行性的基本任务：是在允许的成本和性能要求以及系统的范围内，分析每项需求得以实施的可能性。

分析需求可行性的目的：在于明确与每项需求相关联的风险，包括：一些与其它方面的冲突、对外部环境的依赖和某些技术的障碍等。

分析需求可行性：是一项困难的工作，不存在对所有类型的需求都适用的分析方法。

分析需求可行性：需要与有经验的开发人员共同分析。

对于要开发的软件系统，由于涉及不可知因素，进行需求可行性分析，有助于避免后期开发过程中的一些问题。

与高风险相关的需求，最有可能导致软件开发工作的失败。

考虑的风险类型

1. 性能风险：实现这项需求，可能导致整个系统性能的下降。
2. 安全风险：实现这项需求，可能导致无法满足整个系统的安全需求。
3. 过程风险：实现这项需求，可能导致需要对常规的开发过程做修改。
4. 实现技术风险：实现这项需求，可能需要使用不熟悉的实现技术。
5. 数据库风险：实现这项需求，可能导致系统不支持的非标准数据。
6. 日程风险：实现这项需求，可能遇到技术困难，并危及系统原定的开发日程。
7. 外部接口风险：实现这项需求，可能涉及外部接口。
8. 稳定风险：这项需求可能是易变的，将导致开发过程的重大变动。

在实际工作中，通常使用定性的方法。

如：分类为：

• “高”
• “中”
• “低”

建立用户分析原型

在需求建模前，需要澄清一些不能确定的或含糊的需求，尽早使这些需求能完整和清楚地表达出来。

创建用户分析原型的基本任务：是对于软件开发人员或用户不能明确化的需求，通过建立相应的用户分析原型，然后，评估该原型，使得项目相关人员能更好理解所要解决的问题。

用户分析原型：是指一个可能的局部实现，而不是整个系统，这样可使许多概念和可能发生的事更为直观明了。

需求优先级分析

划分需求优先级可以帮助项目相关人员判断系统的核心需求，并有助于项目相关人员集中于重点问题的交流和协商，特别是涉及需求风险分析的时候。

需求优先级之间的关联，可以帮助软件开发人员决定软件体系结构，还可以帮助解决可能发生的设计冲突。

软件开发人员可以根据需求优先级，权衡合理的项目范围和进度安排、预算、人力资源以及质量目标的要求。

实现权衡的方法是，当接受一个新的高优先级的需求或者项目发生环境变化时，删除低优先级的需求，或者将其推迟到下一版本去实现。

在需求获取的理想情况下，开发人员应在客户表达需求时，由用户决定需求的重要性，标上需求的优先级。

如果单独让用户来决定需求的优先级是很难做到的，在众多具有不同期望的用户之间，达到一致意见就更难了。

优先级的分配，应当由软件开发人员和项目相关人员共同完成，最好是在做了一些初始的分析工作后，再进行需求优先级的分配。

在很多情况下，对同一需求，不同的项目相关人员会分配不同的优先级。

这可能反映了实际的需要，也可能只是简单地反映了不同项目相关人员各自的理解。

因此，必须消除这些差异，并在分配的每一类优先级的含义上达成一致意见。

需求建模

需求建模：就是导出目标系统的逻辑模型或需求模型，以明确目标系统“做什么”的问题。

目标系统：是指待开发的软件系统。

在已知需求的可行性以及各个需求明确以后，为了更好地理解需求，特别是复杂系统的需求，软件开发人员应从不同的角度，抽象出目标系统的特性，

使用精确的方法构造系统的模型，验证模型是否满足用户的需求，并在设计过程中，逐渐把与实现相关的细节加进模型，直至最终用程序实现模型。

模型，就是为了理解事物而对事物作出的一种抽象，是对事物的一种无歧义的书面描述。

模型：可由文本、图形符号或数学符号以及组织这些符号的规则组成。

需求建模，就是把由文本表示的需求和由图形或数学符号表示的需求结合起来，绘制出对目标系统的完整性描述，以检测软件需求的一致性、完整性和错误等。

利用图形表示需求，有助于增强项目相关人员对需求的理解，对于某些类型的信息。

图形表示方式可以使项目相关人员之间减轻语言和词汇方面的负担。

建立需求模型的目的：是为了增强对用自然语言描述的需求规格说明的理解，而不是替换它。

在需求建模中，使用什么方法取决于建模的目的、时间和应用领域等。

常见的需求分析方法有

1. 结构化分析方法（Structured Analysis, SA）
2. 面向对象方法
3. 面向问题域的分析方法
4. 面向特征的需求分析方法
5. 基于本体的需求分析方法
6. 面向多视点的需求分析方法

数据词典

定义：

目标系统中使用的所有数据元素和结构的含义、类型、数量值、精度及允许取值范围的共享数据仓库。

作用：

是确保软件开发人员使用统一的数据定义，可提高需求分析、设计、实现和维护过程中的可跟踪性。

为避免冗余和不一致性，每个项目建立一个独立的数据词典，而不是在每个需求出现的地方定义每个数据项。

数据词典：把不同的需求文档和需求模型紧密地结合到一起。

数据词典中的每个数据项对应一项记录，并根据实际情况使用简单的符合予以定义

Summary:

1）需求分析的任务：

就是分析和综合已收集到的需求信息。

分析：在于透过现象看本质，找出这些需求信息间的内在联系和可能的矛盾。

综合：就是去掉那些非本质的信息，找出解决矛盾的方法，并建立系统的逻辑模型。

（2）关联图：

就是用于描述系统与外部实体间的界限和接口的模型，而且明确通过接口的信息流和物质流。

（1）分析需求可行性的基本任务：

是在允许的成本和性能要求以及系统的范围内，分析每项需求得以实施的可能性。

（2）这项工作的目的：

在于明确与每项需求相关联的风险，包括：一些与其它方面的冲突、对外部环境的依赖和某些技术的障碍等。

（3）在需求分析中应考虑的风险类型：

性能风险、安全风险、过程风险、实现技术风险、

数据库风险、日程风险、外部接口风险、稳定风险

（1）用户分析原型：

用户分析原型：是指一个可能的局部实现，而不是整个系统，这样可使许多概念和可能发生的事更为直观明了。

（2）划分需求优先级

可以帮助项目相关人员判断系统的核心需求，并有助于项目相关人员集中于重点问题的交流和协商。

（3）需求建模

就是导出目标系统的逻辑模型或需求模型，以明确目标系统“做什么”的问题。

（4）数据词典

是定义目标系统中使用的所有数据元素和结构的含义、类型、数量值、精度及允许取值范围的共享数据仓库。

第6章 需求建模方法与技术

需求建模：是根据待开发软件系统的需求，利用某种建模方法建立该系统的逻辑模型。

也称为：需求模型或分析模型。

帮助软件开发人员检测软件需求的一致性、完全性、二义性和错误等。

在软件的实际开发中，为了表达和描述软件需求，软件开发人员使用不同的建模方法，来建立软件需求模型。

这些建模方法的作用、范围和特点不同，因此，在使用中是有所区别的。

需求建模方法具备的共同特点：

1）提供描述手段

开发一个软件系统涉及许多人，开发人员之间如何有效地进行交流是项目成功的关键之一。

在开发过程中，每个开发人员都必须将工作的结果以一定的形式记录下来，采用什么样的描述形式，对人员间的交流和继续进行下一步工作是非常重要的。

需求建模方法应该规定描述模型的手段，这包括要记录什么内容以及用什么符号来表达等。

2）提供基本步骤

开发一个软件系统，特别是大型复杂系统，要考虑的问题很多，如果同时处理这些问题，就会束手无策或者造成混乱。

正确解决问题的方法是，将问题按先后次序进行分解，每一步集中精力解决某个问题，直至所有问题被解决为止。

因此，需求建模方法需要规定基本实施步骤，确定每一步的目的，要产生什么样的结果，每步中要注意哪些概念，以及完成该步的工作需要掌握哪些必要的信息等。

在需求建模方法中，主要使用的描述手段和技术是：自然语言、图形符号语言和形式语言等。

常见的软件需求模型包括:

数据流图（DFD）

实体关系图（ERD）

状态转换图（STD）

用例图

类图

活动图

时序图

事件-响应表

词语类型	示 例	分析模型的组件
名词	人员、组织机构、软件系统、数据元素、已经存在的对象	·外部实体、数据库或者数据流（数据流图，DFD） ·参与者（用例图） ·实体或者实体属性（实体-关系图，ERD） ·通道（时序图） ·带状态的对象（状态转换，STD）
动词	行为、用户或者系统所做的事情、能够发生的事件	·处理（数据流图，DFD） ·处理步骤（时序图） ·用例（用例图） ·关系（实体-关系图，ERD） ·转换（状态转换图，STD） ·活动（活动图） ·事件（事件-响应表）
条件	条件逻辑的陈述，如if/then	·判定条件（决策树、决策表或者活动图） ·分支（时序图或者活动图）

数据流图

（Data Flow Diagram ,简称：DFD）

数据流图：用于标识一个系统中的加工处理、系统所操作的数据集合或者物理介质以及在处理、存储和系统外部之间的数据流。

数据流图：指明系统中数据是如何流动和变换的，以及描述使数据流进行变换的功能。

数据流图：是用来描绘软件系统逻辑模型的图形工具，它描绘信息和数据从输入到输出过程中，所经历的一系列变换。

数据流图：一般在软件生命周期的早期阶段开始进行分析，在软件生命周期后续阶段不断改进、完善和细化。

数据流图：非常适用于事务处理系统和其他偏重功能性的应用系统。

数据流图的绘制

一般情况下，应该遵守“由外向里”的原则。

即先确定系统的边界或范围，再考虑系统的内部，先画数据处理的输入和输出，再画数据处理内部。

也就是：

先全局，后局部；

先整体，后细节；

先抽象，后具体。

在图书预订系统中，书店向顾客发放订单，顾客将所填订单交由系统处理，系统首先依据图书目录对订单进行检查，并对合格订单进行处理，处理过程中，根据顾客情况和订单数目，将订单分为：优先订单与正常订单两种，随时处理优先订单，定期处理正常订单。最后，系统根据所处理的订单，进行汇总，并按出版社要求发给出版社。

第1步，画出顶层数据流图。

第2步，逐层分解加工，绘制1层数据流图。

第3步，绘制2层数据流图。

实体-关系图

（Entity Relation Diagram，简称为：E-R图）

实体-关系图的组成元素

实体-关系图：主要包含：实体、关系和属性，它创建了软件的数据模型。

实体：是现实世界中客观存在的，而且，可以相互区别的事物或活动的抽象。如：人、汽车、商品、职工等；

属性：是描述实体或关系中的一种特征。

一个实体或关系通常具有多个特征，需要多个相应属性来描述。如：学生的属性，包括：学号、姓名、性别、年龄等。

绘制实体-关系图：

用矩形表示实体，在框内写上实体名；

用椭圆形表示实体的属性，并用无向边把实体和属性连接起来；

用菱形表示实体间的关系，在菱形框内写上关系名，用无向边分别把菱形框与有关实体连接起来，在无向边旁注明关系的类型。

实体-关系图（Entity Relation Diagram，简称为：E-R图）

“学生实体和班级实体”的实体-关系图。

状态转换图

（Status Transfer Diagram，简称为：STD）

状态转换图：是用于指明系统在外部事件作用下，将会如何动作，表明了系统的各种状态，以及各种状态间的转换。

状态转换图：还指明了作为特定事件的结果，系统将做哪些动作。

状态转换图的组成元素

状态转换图：由状态、事件和转换组成。

• 状态：是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。
  • 状态主要有：初态（即：开始状态），终态（即：最终状态）和中间状态。
    • 初态：用实心圆表示。
    • 终态：用一对同心圆（内圆为实心圆）表示。
    • 中间状态：用圆角矩形表示，可以用两条水平横线，把它分成上、中、下3个部分。上面部分为状态的名称，这部分是必须有的；中间部分为状态变量的名字和值，这部分是可选的；下面部分是活动表，这部分也是可选的。
• 事件：是在某个特定时刻发生的事情，它是对引起系统做动作或从一个状态转换到另一个状态的外界事件的抽象。
  • 事件：就是引起系统做动作或转换状态的控制信息。
    • 是用箭头上的标记表示，它是引起转换的消息。
• 转换：表示状态从一种状态变为另一种状态
  • 用两个状态之间带箭头的连线来表示，箭头指明了转换方向。

例题：“复印机控制软件”的状态转换图。状态：闲置状态、复印状态、缺纸状态、卡纸状态。事件：复印命令、完成复印命令、发现没纸、装满纸、发生卡纸故障、故障排除。

用例图

用例图：是用来描述系统外部执行者与其交互用例之间的关系。

用例是系统开发者和用户反复讨论的结果，描述了开发者和用户对需求规格说明所达成的共识。

用例描述了对目标系统的功能需求，并把系统看作黑盒子，从外部行为者的角度来理解系统。

用例驱动了需求分析之后各阶段的开发工作，从而影响到开发过程的各个阶段。

用例图是进行需求分析和建立系统功能模型的强有力工具。

用例图的主要元素是：系统、用例、行为者以及用例之间的关系。

例如，自动售货机系统的用例图。

自动售货机系统的用例图。

类图

类是：对一组对象的描述，这些对象具有相似的属性、操作、关系和行为。

类图：描述类及类与类之间的静态关系。

类图：不仅定义软件系统中的类，描述类与类之间的关系，它还表示类的内部结构（即：类的属性和操作）。

一个类可以出现在多个类图中，一个系统可以由多个类图来描述。

类图的表示符号

类图的符号是一个长方形，用两条横线把长方形分为上、中、下三个区域。这三个区域分别放类的名字、属性和操作。

classDiagram
    class 动物
    动物 : String 标签
    动物 : 吃()

classDiagram
  class 银行账户
  银行账户 : +String 户主
  银行账户 : +BigDecimal 余额
  银行账户 : +存(数量)
  银行账户 : +取(数量)

活动图

活动图，用来描述用例中交错的各种流或者执行某个动作的执行者角色或者业务处理中的流程。

活动图：主要描述动作及动作的结果对象状态改变。

无须指明任何事件，只要源状态中的动作被执行了，活动图中的状态（称为动作状态）就自动开始转换。

活动图：描述交互的方式，它描述采取何种动作，动作的结果是什么（即：动作状态改变），何时发生，以及在何处发生。

时序图

时序图：描述对象之间的动态交互关系，着重表现对象之间消息传递的时间顺序。

时序图有2个坐标轴：纵坐标表示时间、横坐标表示不同的对象。

注意：时序图通常有多个对象，体现对象间的时间顺序。

时序图中的对象：用一个矩形框表示，框内标有对象名，从表示对象的矩形框，向下的垂直虚线是对象的“生命线”，用于表示在某段时间内该对象的存在。

对象间的通信通过对象生命线之间的水平消息线来表示，消息箭头的形状表明消息的类型（有：同步、异步或简单）。

当收到消息时，接收对象立即开始执行活动。

即对象被激活

激活用对象生命线上的细长矩形框表示。

消息：通常用消息名和参数表来标识。

消息可以带有条件表达式，用于表示分支或决定是否发送消息。

如果用条件表达式表示分支，则会有若干个互斥的箭头，也就是说，在某一时刻仅可发送分支中的一个消息。

浏览时序图的方法是：

从上到下（即：按时间顺序）查看对象间交换的消息。

如图所示为时序图示例。

决策表

决策表：是分析和表达多逻辑条件下，执行不同操作情况的工具。

决策表：分为四个部分

左上部列出所有条件

左下部是所有可能做的动作

右上部是表示各种条件组合的一个矩阵

右下部是和每种条件组合相对应的动作。

决策表通常有四个部分组成：

① 条件桩（Condition Stub）：列出了问题的所有条件。通常认为列出的条件的次序无关紧要。

② 动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

③ 条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。

④ 动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

行李费算法的决策表。

条件项：国内乘客、头等舱、残疾乘客、行李重量

动作项：列出了不同行李重量可能采取的操作

右侧上部和下部：各种条件组合和每种条件组合相对应的动作。

决策表的建立步骤：

① 确定规则的个数，假如有n个条件，每个条件有两个取值（0，1）,故有2的n次方种规则。

② 列出所有的条件桩和动作桩。

③ 填入条件项。

④ 填入动作项。得到初始决策表。

⑤ 简化、合并相似规则（相同动作）。

决策表的优点：

1）能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用决策表能够设计出完整的测试用例集合。

2）在一些数据处理问题中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。决策表很适合于处理这类问题。

决策树

决策树的概念

决策树：适合描述问题处理中具有多个判断，而且每个决策与若干条件有关。

决策树：是决策表的变种，也能清晰地表示复杂的条件组合与应做的动作之间的对应关系。

决策树的形式简单到不需任何说明，一眼就可以看出其含义，因此，易于掌握和使用。

行李费算法的决策树

决策树的优点

优点：在控制层级的基础上，构造简单，表示方法直观，易于理解。

小结

描述的每一个需求建模方法都有其优点和不足。

没有哪一个图形化模型能够充分描述系统的每个方面。

这些模型提供的描述也有重叠，所以我们也没有必要为项目创建所有的视图。

比如，如果创建了实体关系图和数据字典，很可能就没有必要再创建类图。

Summary

需求建模方法具备的共同特点：

1）提供描述手段

2）提供基本步骤

常见的软件需求模型包括：

数据流图（DFD）

实体关系图（ERD）

状态转换图（STD）

用例图

类图

活动图

时序图

事件-响应表

数据流图：

数据流图：用于标识一个系统中的加工处理、系统所操作的数据集合或者物理介质以及在处理、存储和系统外部之间的数据流。

数据流图由四种基本符号组成：

“箭头”表示：数据流，

“圆角矩形”表示：数据处理或加工

“双线”表示：数据存储

“矩形框”表示：外部实体

实体-关系图：

实体-关系图，包含：实体、关系和属性。

实体：是现实世界中客观存在的，而且，可以相互区别的事物或活动的抽象。

属性：是描述实体或关系中的一种特征。一个实体或关系通常具有多个特征，需要多个相应属性来描述。

关系：现实世界中事物内部以及事物之间的联系，在软件系统中反映为实体内部的关系和实体之间的关系。

实体之间的关系有三类：一对一关系（1:1）、一对多关系（1:n）和 多对多关系（m:n）

用例图：是用来描述系统外部执行者与其交互用例之间的关系。

（2）类是：对一组对象的描述，这些对象具有相似的属性、操作、关系和行为。

（3）活动图，用来描述用例中交错的各种流或者执行某个动作的执行者角色或者业务处理中的流程。

（4）时序图：描述对象之间的动态交互关系，着重表现对象之间消息传递的时间顺序。

决策表：

决策表：是分析和表达多逻辑条件下执行不同操作的情况的工具。

决策表：分为四个部分，其左上部列出所有条件，左下部是所有可能做的动作，右上部是表示各种条件组合的一个矩阵，右下部是和每种条件组合相对应的动作。

决策树：

决策树：适合描述问题处理中具有多个判断，而且每个决策与若干条件有关。

决策树：是决策表的变种，也能清晰地表示复杂的条件组合与应做的动作之间的对应关系。

第7章 需求文档

需求文档在需求工程中的位置

软件文档：是软件产品的重要组成部分，对于开发人员、项目管理人员以及软件用户都是十分重要的辅助工具。

软件文档定义清晰、维护及时，能够帮助开发人员理解需求、顺畅沟通，帮助项目管理人员了解进度、加强管理，帮助软件用户更好地使用和维护软件。

常用的软件文档主要包括：可行性研究报告、项目开发计划、需求文档、概要设计文档、详细设计文档、测试文档、项目开发总结报告、用户手册和操作手册等。

需求文档：是其中最重要的软件文档之一。

需求文档：使得开发人员、项目管理人员和软件用户对软件的初始规定达成共识，并使之成为整个开发工作的基础。

需求工程是一个不断反复的需求定义、需求分析、文档记录、需求演进的过程，并最终在验证的基础上得到需求基线。

需求是软件产品的根源，需求工作的优劣对软件产品影响最大。

就像一条河流，如果源头被污染了，那么整条河流也就被污染了。

需求文档与需求工程中各阶段的关系

如图所示

• 需求获取：当我们和客户合作时，我们会问一些问题，取得他们所提供的信息。

• 需求分析：分析获取的信息以理解它们，并把它们分成不同的类别，同时把客户需求同可能的软件需求联系起来。

• 需求文档：即，软件需求规格说明。

• 需求验证：可以让客户代表评审软件需求规格说明，并纠正存在的错误。

• 这四个过程相互迭代，贯穿着需求开发整个阶段。

需求文档：

• 是在整个需求开发过程中逐步完成，并完善。

• 经过评审后的需求文档，是经过迭代式的需求开发工作后最终形成的成果。

• 是需求管理的主要对象，也是设计文档、开发文档、测试文档等编写的重要依据。

需求文档的作用有以下几方面：

1. 规范的文档可以拓展人脑的知识记忆能力。

   人脑的记忆力总是有限的，获取的信息会随着时间慢慢消退。

   大量临时记录的文档，如果不及时进行整理，在下次阅读时很难再回忆起当时要表达的知识，容易造成歧义。

   规范的文档可以解决这些问题。

2. 编制需求文档的过程，是需求分析员更理解问题的过程，使文档表达的知识更准确、更清晰。

3. 定义清晰、正确、规范的需求文档为开发人员、项目管理人员和软件用户提供相对稳定的可阅读资料。

4. 通过编制需求文档，可以尽早发现需求错误，提高项目开发效率。

   错误在整个项目开发过程中有放大效应，因此，编制需求文档的过程，也是进一步明确和完善系统需求的过程。

   通过减少需求错误从而尽可能地降低项目返工成本，保证项目按期完成。

5. 需求文档能够促进软件开发过程的规范化，也为开发团队建立了经验模型和可复用知识库。

   如果需求分析员在项目未完成时离开了开发团队，通过需求文档记录了他们的工作，智力资产不会被带走。

   如果有新员工加人项目开发团队，也可以通过阅读文档，尽快地融人团队中。

   如果要进行项目二次开发，或者有类似的项目，则通过文档获得可复用知识模型，可以加快项目开发进度。

6. 需求文档可以作为项目开发方和软件客户之间的有关软件系统的协议基准，可以使用它作为合同协议的重要组成部分。使开发方和软件客户对系统目标达成一致。

7. 需求文档可以作为软件成本估算和项目开发进度安排的重要依据，从而使整个项目开发计划的制订更为合理。

对待需求文档的两种不同观点：

一种观点，是过分强调文档，一味追求文档的厚度、完整性，甚至花很长时间去美化文档，不断更新一些不重要的文档细节，从而导致花费大量时间编制和维护文档，反而降低了软件开发效率。

另一种观点，则是完全不重视文档，认为文档的编写只是一个形式化的过程，为节约时间，根本不重视文档的书写风格和表达方式，在实际开发过程中也基本不使用文档，这种观点将导致文档的作用得不到体现，和没有使用文档的开发，效果相差无几。

科学的态度应该是：

• 充分重视文档的实效，而非形式，不要过于强调“文档量”。

• 而要注重文档内容和文档中文字、图表的表达，使文档能够准确、简洁、清晰的表达系统需求信息。

• 使文档能够被项目管理人员、开发人员和软件客户共同接受。

在编写需求文档时，应遵循如下的基本原则：

（1）在可能的情况下，需求文档应该由软件开发方和软件客户联合起草。

由于用户通常对软件设计和开发过程了解较少，

软件开发方通常对客户从事的领域了解较少，对于客户的问题和意图也不甚清楚。

（2）需求文档编写应适应文档的读者。

需求文档的读者主要是项目管理人员、开发人员和软件客户，其中开发人员主要包括系统设计人员、程序员、测试人员、文档编写人员。

只有充分了解读者对文档的需求，才能编写出一份好的技术性文档。

（3）需求文档的表达方式依赖于内容。

需求文档的表达方式可以划分为：自然语言、图形化模型和形式化规格描述3种。

在大多数情况下中，仍然采用自然语言表达为主，图形化模型表达为辅的文档表达方式，在少量对描述精确性要求很高的文档中，采用形式化描述方式。

（4）需求文档编写应有必要的重复，并不断完善。

为了保证读者能够正确理解文档内容，或提醒用户关注重点内容，在文档中应有必要的重复，但要注意不是简单的重复，而是不断的完善。

（5）需求文档编写应具有一定的灵活性。

主要表现如下。

1）文档的详细程度应具有一定的灵活性。

基于相同模版的需求文档，可能只有几页，也可能是上百页。

详细程度取决于任务的规模、复杂性和项目管理人员对软件开发过程及运行环境所需要的详细程度的判断。

2）文档可以扩展与合并，文档中所有的章节都可以进一步细分或缩并，以适应实际需要。

3）文档应能够对需求变更进行有效的管理和控制。

用户需求的变化、市场需求的变化、系统变化、工作环境的变化，以及由于对原有需求的误解或需求分析不充分而存在的需求Bug都有可能导致需求变更。

因此，文档应能够灵活地处理需求变更。

（6）采用原型法，渐进式开发需求文档。

人们总是希望一开始就能将整个软件系统的需求确定下来，但在实际项目中却很难达到这一目标。

为降低需求风险，提高软件开发效率，可以采用原型法，渐进式编写需求文档。

常用的编写需求文档的方法有：

自然语言

图形化模型

形式化规格描述

常用的编写需求文档的方法有：

1. 自然语言

   自然语言：是使用结构合理的自然语言来表述需求。

   自然语言：不管对于写的人还是看的人，都是一个很容易接受的方法，一直以来这都是描述需求的首选方法。

   自然语言优点：易于编写、易于阅读，不要求掌握特定的技能。

   自然语言缺点：不够严谨，歧义性强，表述力差，对于复杂问题的描述就更为明显，往往需要很大的篇幅来解释。

   因此，需要尽可能采用结构化文本来组织。

2. 图形化模型 —— “一图抵千言”

   图形化模型：在表述时能够给读者提供更强的视觉效果，同时能够使问题更加聚焦。

   图形化模型：在日常的交流中，经常会在纸上绘制一些非标的示意图，以更好地完成沟通。

   图形化模型优点：就是前面提到的可视性、聚焦性。

   图形化模型缺点：要求编写和阅读的人都能够正确地理解模型，而且并不是所有的信息都是可以用模型表示的。

   因此，对于一个软件需求文档而言，是不可能只有图形化模型、没有任何文字表述的。

3. 形式化方法描述

   形式化方法描述：比图形化模型更高一些。对于逻辑性很强、精度要求很高的场合，形式化方法描述就是一种不错的选择。

   形式化方法描述优点：是严谨、精确。

   形式化方法描述：缺点：是编写和阅读的人都会感到很困难，容易产生理解歧义。

4. 需求文档编写方法的选择：

   1）以自然语言为主，而以图形化模型为辅，需要的地方少量使用形式化方法描述。

   这是现在最常见的组合形式，对于绝大多数信息系统、软件产品而言都是十分适合的方法。

   2）以图形化模型为主，而以自然语言作为补充，需要的地方少量使用形式化方法描述。

   3）以形式化规格语言为主，而以图形化模型为辅，并以自然语言为补充。

   适用于质量要求很高的领域，例如：航天、军工中的一些重要软件系统。

软件需求规格说明，也称为：功能规格说明、需求协议及系统规格说明。

软件需求规格说明：精确地阐述一个软件系统必须提供的功能、性能及它所要求考虑的限制条件。

软件需求规格说明：不仅是系统测试和用户手册的编写基础，也是各子系统计划、设计、编码的基础。

软件需求规格说明：应尽可能完整地描述系统预期的外部行为和用户可视化行为。

编写需求规格说明步骤：

1）整理所有已经通过审核的各阶段工作文档，这些文档虽然是阶段性的，但一定是经过审核准确的，对于每一个审核的局部文档都要给出版本号。

2）制订一个结构完成的需求规格说明模板，并给需求规格说明模板一个版本号，同时要制订一个需求规格说明的编写规范。

3）按照需求规格说明模板和编写规范依据整理的各阶段文档成果进行编写，编写时一定要注意前后一致性原则。

4）软件需求规格说明书编写成员进行自检和互检，最终形成一个提交需求验证的软件需求规格说明文档。

常用的标识方法有以下几种：

1）序列号法

序列号法：是一种最简单的方法，就是给每个需求一个唯一的序列号，如UR-1 , SRS13 , FR-1等。

当一个新的需求进来时，再依序给它分配一个序列号，序列号的前缀代表需求类型，

由于序号不能重用，当有一个需求被纳人进来时，其原先占有的序列号并不能释放出来，容易造成序列号断号。

序列号法：不能提供任何相关需求在逻辑上或层次上的区别，而且标识中不含有与需求内容相关的信息。

2）层次化编码

层次化编码：是一种常用的方法。如：软件需求规格说明中的4.1，下一层标识号是4.1.1等。

层次化编码中的数字越多，则表示需求越详细，号数越多的说明它是最底层的需求。

层次化编码：简单且紧凑，利用文档工具可以实现层次号的自动变更，它很方便地显示了一个需求的层次构成。

层次化编码： 不含需求的内容信息，而且如果有其他地方引用，当变动时引用部分要做相应的修改。

3）层次化文本标签

层次化的文本标签是结构化的、具有语义上的含义。

层次化文本标签：不受增加和减少或移动的影响。

层次化文本标签：但要定义好层次化文本标签要比层次化数字标识难得多。

处理不完整性

在编写需求规格说明时，一定会遇到缺少特定的需求信息，或认为原有过程化需求文档有不正确的地方，则使用一种TBD ，即待确定的标记来标识这些不确定的需求。

并将TBD的地方记录在一个TBD问题列表中，该列表有TBD编号、问题内容、责任人、解决时间、解决状态，这个表将有助于跟踪这个文档的编写。

TBD问题列表将作为需求规格说明文档的附录。

要把最终的软件需求规格说明移交给软件开发组时，必须解决所有的TBD问题。

软件需求规格说明模板

1.引言

引言：提供了一个概述，帮助于读者理解软件需求规格说明的组织方式和使用方式。

引言：主要包括：目标、文档约定、读者对象和阅读建议、项目范围及参考文献。

1.1 目标

在文档中说明软件或应用程序的需求，包括：修订或者发行版本号。

如果该软件需求规格说明只与整个系统的一部分有关系，那么，就只需确定这一部分或子系统。

1.2 文档约定

描述编写文档时所采用的所有标准或印刷上的约定。

包括：文本样式、强调形式或具有特殊意义的表示符号。

1.3 读者对象和阅读建议

列举软件需求规格说明面向的不同读者对象。

描述软件需求规格说明中其余部分的内容及其组织结构。

就每一类读者最合适以什么顺序来阅读该文档提出建议。

1.4 项目范围

提供对指定的软件及其作用的简短描述。

把软件与用户或公司目标相关联，把软件与业务目标和策略相关联。

如果可以得到单独的前景和范围文档，那么应该引用它，而不要直接将其内容复制到这里。

如果是说明改进产品的增量发布的软件需求规格说明，那么应该包括它自己的范围声明，作为长期战略的产品前景的一个子集。

1.5参考资料

列举编写软件需求规格说明时所参考的所有文档或其他资源。

如果可能的话，使用超文本链接。

2.总体描述

2.1 产品前景

描述产品的背景和起源。

说明该产品是否是产品系列中的下一个成员，是否是成熟系统的下一版本，是现有应用程序的升级产品还是是一个全新的产品。

2.2 产品特性

列出产品所具有的主要特性或者产品可实现的重要功能。

在此只需要提供一个总体概括即可。

2.3 用户类及其特征

确定我们能预料到的有可能使用该产品的各种用户类。

描述他们的相关特征。

2.4 运行环境

描述软件的运行环境，包括：硬件平台、操作系统和版本，以及用户、服务器和数据库的地理位置

2.5 设计和实现上的约束

描述限制开发人员进行有效选择的所有因素，以及每一种约束的基本原理。

2.6 用户文档

列出将要交付的用户文档组件以及可执行软件，可以包括用户手册、联机帮助和教程。

确定所有要求的文档交付格式、标准或工具。

2.7 假设和依赖

假设是这样一种声明，在缺少证据或不确定的情况下先相信它是真的。

如果假设不正确、不一致或被更改，那么就可能会产生问题。

有些假设将会转化为项目风险。

3.系统特性

模板是根据系统特性来组织的，它只是安排功能性需求的一种可能的方式。

其他可以选择的方式还包括按照用例、操作模式、刺激、响应、对象类或功能层次结构等。

正确的选择并不是惟一的，但我们应该选择一种使读者易于理解产品预期功能的组织方法

3.1 系统特性X

仅用简短的词语说明特性的名称，例如“3.1 拼写检查”。

对每一个系统特性都要重复 3.x.1一3.x.3 这几个部分。

3.x.1 描述优先级

提供对该特性的简短描述，并指出该特性的优先级是高、中或低

3.x.2 激励/响应序列

列出输入激励序列（如：用户操作、来自外部设备的信号或其他触发器）和系统响应序列，系统响应序列定义这一特性的行为。

这些激励与用例最初的对话步骤或者与外部系统事件相对应。

3.x.3 功能性需求

逐项列出与该特性相关的详细功能性需求。

这些是必须提交给用户的软件功能，使用户可以执行该特性的服务或者完成一个用例。

描述产品如何响应可预知的出错条件以及如何响应非法输入或操作。

唯一地标识每个功能性需求。

4.外部接口需求

这部分所提供信息是为了保证系统与用户、与外部硬件或软件元素之间的正常通信。

如果一个复杂系统有多个组成部分，则应创建一个独立的接口规范说明或者系统架构规范说明。

主要包括：用户界面、硬件接口、软件接口和通信接口。

4.1 用户界面

描述系统所需的每个用户界面的逻辑特征或屏幕模型，以便与需求的另一个视图进行交流。

而不能将用户界面的设计细节写入软件需求规格说明中。

4.2 硬件接口

描述系统中软件和硬件组件之间每一接口的特征。

这种描述可能包括支持的设备类型、软件和硬件之间的数据和控制交互以及所用的通信协议等。

4.3 软件接口

描述该产品与其他软件组件之间的连接，这些组件包括数据库、操作系统、工具、库和集成的商业组件等。

声明在软件组件之间交换消息、数据和控制项的目的。

描述外部软件组件所需的服务，以及组件间通信的本质。

确定将在软件组件之间共享的数据。

4.4 通信接口

描述产品将使用的所有通信功能的需求，包括电子邮件、Web浏览器、网络通信协议和电子表格等。

定义所有相关的消息格式。

规定通信安全或加密问题、数据传输速率和同步通信机制等。

5.其他非功能性需求

5.1 性能需求

声明各种系统操作特定的性能需求，并解释其原理以指导开发人员做出合理的设计选择。

5.2 防护性需求

这部分声明与产品使用过程中可能发生的损失、破坏或危害相关的需求。

定义必须采取的安全保护措施或动作，还有那些必须避免的可能危险的动作。

明确产品必须遵循的安全标准、策略或规则。

5.3 安全性需求

指定与安全性、完整性或保密性问题相关的所有需求，这些问题影响对产品的访问、使用以及产品所创建或使用的数据的保护。

确定产品必须遵守的所有安全或保密策略或规则。

5.4 软件质量属性

声明对用户或开发人员至关重要的其他产品质量特征。

这些特征必须是明确的、定量的和可验证的。

应该指明各种属性的相对优先级。

6.其他需求

定义在此软件需求规格说明中其他部分未出现的所有其他需求。

例如：国际化需求及法律上的需求。

如果不需要添加任何其他需求，就省略这一部分。

7.附录

附录A：术语表

定义读者需要了解的所有专门术语，以便他们能够正确地理解软件需求规格说明。

附录B：分析模型

这一部分是可选的，包括或指向相关的分析模型。

例如：数据流图、类图、状态转换图、实体-关系图等。

附录C：待确定问题的清单

这一部分列出了有待于解决的需求问题。

这一部分并不是软件需求规格说明所必需的。

Summary

需求文档：是其中最重要的软件文档之一。

需求开发，包括：

需求获取

需求分析

需求文档

需求确认

需求文档的7个作用：

（1）规范的文档可以拓展人脑的知识记忆能力。

（2）编制需求文档的过程，是需求分析员更理解问题的过程，使文档表达的知识更准确、更清晰。

（3）定义清晰、正确、规范的需求文档为开发人员、项目管理人员和软件用户提供相对稳定的可阅读资料。

（4）通过编制需求文档，可以尽早发现需求错误，提高项目开发效率。

（5）需求文档能够促进软件开发过程的规范化，也为开发团队建立了经验模型和可复用知识库。

（6）需求文档可以作为项目开发方和软件客户之间的有关软件系统的协议基准，可以使用它作为合同协议的重要组成部分。使开发方和软件客户对系统目标达成一致。

（7）需求文档可以作为软件成本估算和项目开发进度安排的重要依据，从而使整个项目开发计划的制订更为合理。

编写需求文档的6个原则：

（1）在可能的情况下，需求文档应该由软件开发方和软件客户联合起草。

（2）需求文档编写应适应文档的读者。

（3）需求文档的表达方式依赖于内容。

（4）需求文档编写应有必要的重复，并不断完善。

（5）需求文档编写应具有一定的灵活性。

（6）采用原型法，渐进式开发需求文档。

需求文档的编写方法：

自然语言

图形化模型

形式化规格描述

需求文档编写方法的选择：

1）以自然语言为主，而以图形化模型为辅，需要的地方少量使用形式化方法描述。

2）以图形化模型为主，而以自然语言作为补充，需要的地方少量使用形式化方法描述。

3）以形式化规格语言为主，而以图形化模型为辅，并以自然语言为补充。

编写需求规格说明步骤：

（1）整理所有已经通过审核的各阶段工作文档。

（2）制订一个结构完成的需求规格说明模板，并给需求规格说明模板一个版本号。

（3）按照需求规格说明模板和编写规范依据整理的各阶段文档成果进行编写。

（4）软件需求规格说明书编写成员进行自检和互检。

常用的标识方法：

（1）序列号法

（2）层次化编码

（3）层次化文本标签

处理不完整性方法：

（1）使用：TBD ，即待确定的标记来标识这些不确定的需求。

（2）将有TBD的地方记录在一个TBD问题列表中。

（3） TBD问题列表将作为需求规格说明文档的附录。

（4）要把最终的软件需求规格说明移交给软件开发组时，必须解决所有的TBD问题。

软件需求规格说明模板：

当前常用的模板是IEEE标准830-1998的模板。

模板中的主要内容：

1. 引言

2. 总体描述

3. 系统特性

4. 外部接口需求

5. 其他非功能性需求

6. 其他需求

7. 附录

第8章 软件质量属性

质量属性的概念：

系统的功能：是系统能够为用户提供帮助的第一要素。

成功的软件系统除了满足功能需求之外，还需要满足更多的要求。

系统的性能需求，包括：系统的易用性、运行速度、出错频率，以及处理异常情况的能力等。

这些特性合起来被称为：软件质量属性或质量因素

它是系统非功能需求的一部分。

质量属性：也应该和功能需求一样得到足够的重视。

在决定系统的成功或失败的因素中，有时满足非功能属性往往比满足功能需求更为重要。

质量属性：对设计的影响很大。

质量属性：在软件设计中，对任何指定的功能都会有多种可选的方案，不同的方案选择产生不同的设计结果。

不同的方案之间却有着很大的区别，差异之处即在于拥有不同的质量属性。

不同的质量属性之间互有折中，很难会出现某一个设计方案的质量属性完全优于其他方案的情况。

因此，软件设计必须根据需求的质量属性在多种方案中，选择一个最优的方案。

如果不存在事先定义好的质量属性，设计方案的选择将完全没有依据，结果就很有可能导致软件不被用户接受。

在设计开始之初，就确定质量属性非常重要，而且对越复杂的系统越为重要。

质量属性：分类两类：

（1）根据质量属性能否在运行时进行识别。

（2）根据对用户和技术人员的重要性，分为：

对用户很重要的可见的质量属性

对技术人员有意义的质量属性

后者通过使系统易于更改、纠正和验证，并易于移植到新的平台上，间接地促进用户需要的满足。

理想情况下，每一个系统总是展示所有这些属性可能的最大值。

系统总是可用的，决不会崩溃，可以立即得出始终正确的运行结果，系统也总是直观且易于使用。

必须了解哪些属性对项目的成功至关重要。

根据这些基本属性来定义用户和开发人员的目标，从而使系统的设计人员能够做出合适的选择

对用户重要的属性：

可用性（Availability）

可用性：用于衡量预定的可用时间，在这期间系统是真正可用并且是完全可操作的。

可用性：等于系统的平均无故障时间（简称：MTTF）除以平均无故障时间与故障发生后所用的故障修复时间（简称：MTTR）之和。

即：可用性 = MTTF/（MTTF+MTTR）

可用性，包括：可靠性、可维护性和完整性。

有效性（Efficiency）

有效性：用来衡量系统在利用处理器的处理能力、磁盘空间、内存或通信带宽等方面的表现如何。

有效性与性能相关，性能是另一类非功能性需求。

如果系统消耗了太多可用的资源，那么用户遇到的将是性能的下降，这是缺乏有效性的一个表现。

灵活性（Flexibility）

灵活性，也称为：可扩充性、可扩展性。

灵活性：用来测量向系统中添加新功能的容易程度。

如果开发人员预料到要对系统进行扩展，那么他们可以选择使软件灵活性最高的设计方案。

灵活性：对以增量或迭代方式开发的系统是必不可少的，这些系统是通过一系列连续的发布版本或演化式原型而开发的。

完整性（Integrity）

完整性：主要处理防止非法访问系统功能、防止数据丢失、保护软件免受病毒入侵以及保护输入到系统的数据的保密性和安全性等问题。

完整性需求不能容忍任何错误，陈述完整性需求时应使用含义明确的术语。

如：用户身份验证、用户特权级别、访问限制或者需要保护的精确数据。

互操作性（Interoperability）

互操作性：表明了系统与其他系统交换数据和服务的难易程度。

为了评估互操作性，必须了解清楚用户使用其他哪些应用程序与本系统协同工作，还要了解清楚用户期望交换什么数据。

可靠性（Reliability）

可靠性：是软件无故障执行指定时间的概率。

健壮性有时可看成是可靠性的一部分。

衡量软件可靠性的方法，包括：正确执行操作所占的百分比和系统发生故障之前正常运行的平均时间长度。

具有高可靠性要求的系统，也应该设计得具有很高的可测试性，就可以轻松地发现损害系统可靠性的缺陷。

健壮性（Robustness）

健壮性：指的是当系统遇到非法的输入数据、相连接的软件组件或硬件组件的缺陷，以及预料不到的操作情况时，能继续正确运行功能的可能性。

健壮的软件：可以从发生问题的环境中自然地恢复过来，并且可以容忍用户所犯的错误。

当获取健壮性需求时，向用户询问系统可能遇到的错误条件，并且要了解用户期望系统如何响应。

易用性（Usability）

易用性：陈述了许多因素，用户经常将这些因素描述为“用户友好性"。

分析人员和开发人员不应该讨论友好的软件，而应该讨论将软件的使用设计得有效而不让人感到困惑。

易用性：包括：对于新用户或不常使用系统的用户在学习使用系统时的简易程度。

对开发人员重要的属性

可维护性

可维护性：表明了纠正缺陷或修改软件的简单程度，它取决于理解软件、更改软件和测试软件的简单程度。

可维护性：与灵活性和可测试性密切相关。

对那些将要频繁修订的系统和要快速生成的系统来说，可维护性的要求很高。

可以根据修复一个问题所花的平均时间和修复正确的百分比来衡量可维护性。

可移植性

可移植性：用来度量把一个软件从一种运行环境移植到另一种运行环境所需的工作量。

可移植性：对项目的成功来说，要么是无关紧要，要么是至关重要。

可移植性：目标应该确定系统中必须移植到其他环境的那一部分，并描述这些目标环境。

开发人员就能选择设计和编码方法以适当提高系统的可移植性。

可重用性

可重用性：是软件开发的一个长远目标。

可重用性：表明把一个软件组件用于其他应用程序所涉及的相关工作量。

比起创建一个打算只在一个应用程序中使用的组件，开发可重用软件的费用会大得多。

可重用软件必须模块化，文档齐全，不依赖于特定的应用程序和运行环境，并且具有通用性。

可测试性

可测试性：也称为：可验证性。

可测试性：指的是测试软件组件或集成系统以查找缺陷的简单程度。

如果系统中包含复杂的算法和逻辑，或包含复杂的功能性相互关系，那么对于可测试性的设计就很重要。

如果经常更改系统，那么可测试性也是很重要的，因为需要经常对系统进行回归测试，来判断更改是否破坏了任何原有的功能性。

属性的折中方案

用户和开发人员必须确定，与其他属性相比哪些属性更为重要。

当制定决策时，必须始终遵照优先级顺序。

如图所示，描述了质量属性之间一些典型的相互关系。

当然我们也可能会遇到一些与此不一致的例外

单元格中的加号：表明单元格所在行的属性对其所在列的属性具有正面的影响。

• 例如，增强软件组件可移植性的设计方法也可以使软件变得更加灵活，更易于与其他软件组件相连接，更易于重用，并且更易于测试。

单元格中的减号：表明单元格所在行的属性对其所在列的属性具有负面的影响。

单元格为空则表明单元格所在行的属性对其所在列的属性几乎没有什么影响。

有效性对其他许多属性具有消极影响。

类似地，一些对易用性进行优化的系统，或具有灵活性、可重用性以及与其他软件组件或硬件组件进行互操作的系统，则要付出性能的代价。

如图所示中的矩阵并不是对称的，因为增加属性A对属性B所产生的影响与增加属性B对属性A所产生的影响并不一定是相同的。

• 例如，图中表明设计系统时增加有效性并不一定对完整性产生任何影响。

增加完整性却可能会损害有效性，因为系统必须通过更多层次的用户身份验证、加密、病毒扫描和数据检查技术。

为达到系统特性的最佳平衡，必须在需求获取阶段识别、指定相关的质量属性，并且为之确定优先级。

为项目定义重要的质量属性时，利用图可以防止发生与目标冲突的行为。

性能需求

性能需求：定义了系统必须多好和多快地完成专门的功能。

性能需求：包括：速度（例如，数据库响应时间）、吞吐量（例如，每秒钟处理的事务）、处理能力（例如，并发使用负载）和定时（例如，严格的实时要求）。

苛刻的性能需求，会对设计软件策略和选择硬件造成严重的影响，因此，定义的性能需求目标要适合于运行环境。

性能需求范例：

范例1：温度控制循环必须在80毫秒内完全执行。这里，“80毫秒”就是性能需求。

范例2：解释器每分钟应该至少解析5000条没有错误的语句。这里，“5000条”就是性能需求。

范例3：在通过50KBps的调制解调器与Internet相连的情况下，下载一个Web页面需要15秒或更短。这里，“15秒或更短”就是性能需求。

范例4：ATM自动拒员机系统对提款请求的身份认证不能超过10秒。这里，“10秒”就是性能需求。

Summary

质量属性：

用于衡量系统性能的特性包括：系统的易用性、运行速度、出错频率，以及处理异常情况的能力等。

这些特性合起来被称为：软件质量属性或质量因素。

对用户重要的属性有：

可用性、有效性、灵活性、完整性、互操作性、可靠性、健壮性、易用性。

对开发人员重要的属性有：

可维护性、可移植性、可重用性、可测试性。

属性的折中方案

为达到系统特性的最佳平衡，必须在需求获取阶段识别、指定相关的质量属性，并且为之确定优先级。

性能需求

性能需求，定义了系统必须多好和多快地完成专门的功能。

性能需求，包括：速度（例如，数据库响应时间）、吞吐量（例如，每秒钟处理的事务）、处理能力（例如，并发使用负载）和定时（例如，严格的实时要求）。

第9章 通过原型来减少风险

为什么要建立原型？

因为预想一个未来的软件系统，并表达出系统需求是比较困难的，而通过制作软件原型，可以使需求更加真实，使用例更加生动，并且，可以减小在需求理解上的差异。

原型：可以把新系统的一个模型或一个部分摆在用户的面前，可以激活他们的思维，并促进需求对话。

对原型的早期反馈有助于涉众对理解系统需求达成共识，从而减小客户不满意的风险。

由于需求中仍然还会有对用户、对开发人员或者对这二者都不明确或不清晰的部分。

如果不解决这些问题，那么用户对系统的想像与开发人员对系统的理解会存在期望差距。

原型有多种含义，并且参与原型制作活动的人可以有完全不同的期望。

如：一个飞机原型实际上可能是真实飞机的雏形。

一个软件原型：仅仅是真实系统的一部分或一个模型，它可能根本不能完成任何有用的功能。

软件原型，可能是：

工作模型或静态设计

很详细的屏幕草图或简单草图

真实功能的可视化显示或一部分

使用原型有3个主要目的：

（1）明确并完善需求。

原型：作为一种需求工具。

原型：是对部分系统的初步实现，因为我们尚没有很好地了解该系统。

用户对原型的评估，可以指出需求中存在的问题。

这样可以在开发真正的系统之前，以低成本来解决这些问题。

（2）研究设计选择方案。

原型作为一种设计工具，涉众可以用它研究不同的用户交互技术，优化系统的易用性，并评估可能的技术方案。

原型能够通过有效的设计来演示需求的可行性。

（3）发展为最终系统。

原型作为一种构造工具，是系统一个最初子集的完整功能实现，通过一系列小规模的开发周期，我们可以完成整个系统的开发。

建立原型的主要原因：

是为了解决在系统开发早期阶段不能确定的一些问题。

利用这些不确定性，可以判断系统中哪些部分需要建立原型，以及希望从用户对原型的评估中获得什么信息。

原型：是发现并解决需求中的二义性和不完整性的很好的方法。

用户、管理人员和其他非技术人员发现：

当系统处于编写需求规格说明和设计阶段时，原型可以使他们更具体地思考问题

原型，尤其是直观的原型，比开发人员有时所使用的技术术语更易于理解。

根据使用原型的目的不同，原型分为：

1. 水平原型和垂直原型
2. 抛弃式原型和演化式原型
3. 书面原型和电子原型

水平原型

当人们谈到“软件原型”时，所想到的通常是一个可能的用户界面的水平原型。

• 水平原型，也叫做：行为原型或演示性模型。

• 水平原型：主要描绘了用户界面的一部分。

  • 因为水平原型并不能深入到体系结构的所有层次，或者深入到系统的细节。

• 通过水平原型，可以研究预期系统的一些特定行为，并达到完善需求的目的。

• 水平原型：有助于用户判断基于该原型的系统是否能完成任务。

• 水平原型：显示用户界面的屏幕外观，并允许这些屏幕之间进行某些导航，但只包含很少或根本就不包含真正的功能实现。

• 水平原型：能够演示用户以后可用的功能选项、用户界面的外观和感觉（如：颜色、布局、图形和控件），以及信息体系结构（如：导航结构）等。

• 虽然原型看起来似乎可以执行一些有意义的工作，但其实不然。

• 水平原型：常常只是使用户判断是否有遗漏、错误或不必要的功能。

• 有些原型，代表了开发人员对可能如何实现一个特定用例的一种观念。

• 用户对原型的评估，可以指出用例的其他实现方式、遗漏的交互步骤，或者其他异常情况。

• 当处理水平原型时，用户应该把注意力集中在概括性需求和工作流问题上，而不要被屏幕元素的精确外观所分心。

• 在此阶段，不要担心屏幕元素的精确位置、字体、颜色、图形或控件。

• 弄清了需求，并确定了界面的总体框架之后，再来研究用户界面的细节。

垂直原型

• 垂直原型：也称为：结构化原型、概念的证明

• 垂直原型：在整个技术服务层上实现应用程序用户界面的一部分功能。

• 垂直原型的运作与所期望的真实系统的运作类似，因为它触及到了系统实现的所有层次。

• 如果不能确定所提议的架构方法是否可行和合理，或者如果我们想要优化算法、评估所提议的数据库架构或测试关键的定时需求。就可以开发一个垂直模型。

• 垂直原型：为使其结果有意义，通常在与系统类似的运行环境中，用生产工具来创建垂直原型。

• 垂直原型：常用于研究关键界面和定时需求，也常用在设计阶段以减小风险。

抛弃式原型和演化式原型

（1）抛弃式原型

在构造一个原型之前，需要做出一个明确的和经过分析的决策。

也就是在评估之后是将原型抛弃掉，还是将原型作为最终交付系统的一部分。

如果打算在原型达到预期目的以后将它抛弃掉，那么，就应该尽量花最小的代价，并尽可能快地创建该原型。

在此原型上付出的努力越多，项目的参与者就越不愿意将它抛弃掉。

要注意的是：

如果认为该原型有其优点，应该留着以备将来重用，那么也不一定非要将它抛弃掉。

不能将“抛弃式原型”整合到最终交付的系统中。

可能更愿意将它称为“非发布型原型”。

抛弃式原型：重点强调在健壮性、可靠性、性能和长期维护性等方面的快速实现和修改。

不允许将抛弃式原型中质量低的代码移植到最终系统中，否则，用户和维护人员将在系统生命周期中遭遇种种麻烦

当团队面临需求中的不确定性、二义性、不完整性或含糊性时。

最恰当的方法是建立一个抛弃式原型。

这样可以减少在继续开发时存在的风险。

抛弃式原型：可帮助用户和开发人员直观地了解需求可能如何实现，并发现需求中存在的漏洞。

抛弃式原型：可以使用户判断出这些需求是否可以使必要的业务过程运作起来。

不要过于详细地构建抛弃式原型，只要能够满足原型制作的目标就够了。

如图所示，描述了借助于抛弃式原型，从用例到详细的用户界面设计的一系列开发活动。

演化式原型

当随着时间的推移，需求越来越明确时，演化式原型为增量地构建系统奠定了坚实的结构基础。

演化式原型：是螺旋式软件开发生命周期模型和某些面向对象软件开发过程的一个组成部分。

与抛弃式原型快速、粗略的特点相比，演化式原型必须具有健壮性，代码质量从一开始就要达到系统的要求。

要完成相同的功能，构建演化式原型要比构建抛弃式原型所花的时间更多。

演化式原型：必须设计得易于进行扩展和频繁改进，开发人员必须重视软件体系结构和成熟的设计原则。

要得到高质量的演化式原型，并没有捷径可走。

应该将演化式原型的第1次增量作为一个试验性版本，用来实现需求中已经正确理解和稳定的部分。

根据用户验收测试和初次使用时发现的问题，在下一次迭代中对其进行修改，最终得到完整的系统，可以很快地将能够使用的功能交付给用户。

如果已经预料到系统以后还要进行扩展。

那么，就选择演化式原型。

如图所示，给出了综合使用各种原型的几种方法。

如表所示，概括地总结了抛弃式、演化式、水平和垂直原型的一些典型应用。

书面原型和电子原型

（1）书面原型

书面原型：有时也称为“低保真原型"

书面原型：是一种成本低、速度快，且不涉及高深技术的方法。

书面原型：可以把一个系统的某部分，是如何实现的呈现在用户面前。

通过书面原型可以判断用户和开发人员对需求的理解是否一致。

书面原型：可以在代码编制之前，对可能的解决方案进行试验性和低风险的尝试。

书面原型：所涉及的工具仅仅是纸张、索引卡、粘贴便签和干净的塑料板等。

设计人员对屏幕布局进行构思，而不必关心布局中控件的精确位置和它们的外观。

当用户遍历一个评估场景时，一个人就可以充当计算机的角色。

用户说出他想在特定的屏幕上做什么来启动动作，模仿计算机的人就会把相应的纸张和索引卡拿给用户看，这些纸张和索引卡表示了用户采取这一动作时的外观显示。

用户就可以判断这是否确实是所期望的响应，并且还可以判断所显示的条目内容是否正确。

如果有错误，只需要用一张新纸或索引卡，重画一张就可以了。

书面原型：可以方便地实现快速迭代，而迭代对需求开发的成功与否起着至关重要的作用。

书面原型：也有助于开发团队管理客户的需求。

（2）电子原型

电子原型：就是一个基于计算机的可运行的原型。

构建一个抛弃式电子原型，可以使用以下工具：

1. 编程语言，例如：Visual Basic，IBM VisualAge Smalltalk和Delphi。

2. 脚本语言，例如Perk Python和Rexx（雷克斯）。

3. 商业原型制作工具箱、屏幕绘图器和图形用户界面生成器。

4. 绘图工具，例如Visio和PowerPoint

运用合适的工具，可以轻松地实现并修改用户界面组件，而不管隐藏在界面背后的代码效率高低。

如果创建一个演化式原型，那么必须从一开始就使用系统开发工具。

Summary

建立原型的3个目的：

（1）明确并完善需求

（2）研究设计选择方案

（3）发展为最终系统

根据使用原型的目的不同，原型分为：

水平原型和垂直原型

抛弃式原型和演化式原型

书面原型和电子原型

水平原型：主要描绘了用户界面的一部分。

因为水平原型并不能深入到体系结构的所有层次，或者深入到系统的细节。

垂直原型：也称为：结构化原型、概念的证明

在整个技术服务层上实现应用程序用户界面的一部分功能。

建立水平原型目的：

研究预期系统的一些特定行。

显示用户界面的屏幕外观、屏幕之间的导航。

建立垂直原型目的：

确定所提议的架构方法是否可行和合理。

优化算法、评估所提议的数据库架构或测试关键的需求。

（1）抛弃式原型：

是在原型达到预期目的后，就将原型抛弃掉。

当团队面临需求中的不确定性、二义性、不完整性或含糊性时，最恰当的方法是建立一个抛弃式原型。

（2）演化式原型：

是增量地构建系统，是被开发系统的一个组成部分。

必须具有健壮性，代码质量从一开始就要达到系统的要求。

必须易于进行扩展和频繁改进。

开发人员必须重视软件体系结构和成熟的设计原则。

（1）书面原型

书面原型：有时也称为“低保真原型"

书面原型：是一种成本低、速度快，且不涉及高深技术的方法。

书面原型：所涉及的工具仅仅是纸张、索引卡、粘贴便签和干净的塑料板等。

（2）电子原型

电子原型：就是一个基于计算机的可运行的原型。

（1）原型评估：

可以从原型所针对的用例或功能中推导出评估脚本。

务必要通过合适的人从恰当的角度来评估原型。

要同时包括有经验的和经验不足的用户类代表。

（2）创建原型所带来的风险：

风险1：是项目相关人员看到一个正在运行的原型，从而得出系统几乎已经完成的结论。

风险2：是用户重点关注的是系统“如何做”的问题，他们关注用户界面的外观如何，以及如何操作这些界面。

风险3：是用户将根据原型的性能来推断最终系统的期望性能。

（3）建立有效原型应遵循的原则：

1. 应该在项目计划中包括创建原型的任务。安排好开发、评估和更改原型的时间进度和所需的资源。

2. 创建原型之前，先要陈述每个原型的用途。

3. 要计划开发多个原型，因为很少能一次便成功。

4. 创建抛弃式原型时要用最少的投资开发出用于回答问题和解决需求不确定性的原型。

5. 抛弃式原型中不应包括输入数据有效性检查、防御式编码技术、用于错误处理的代码或代码注释。

6. 对于已经理解的需求不要建立原型，除非是要研究设计选择方案。

7. 在原型显示和报告中使用看似真实的数据。

第10章 确定需求的优先级别

为什么要设定需求优先级？

对于每一个受资源限制的软件项目，都必须对要求的功能定义相对优先级。

设定优先级：有助于项目经理解决冲突、安排阶段性交付，并且做出必要的取舍。

当用户的期望很高，而且开发时间又很紧迫时，就必须确保在系统的尽早版本中，提供最重要的功能。

设定优先级：就是一种行之有效的方法，可以处理在资源有限的情况下，应该优先满足哪些需求。

为每一种功能建立相对优先级后，就可以规划软件的开发过程，以最低的成本提供最佳的系统。

项目经理必须根据时间进度、项目预算、人力资源以及质量目标等约束条件，权衡考虑，制定出合理的项目范围。

达到此目的的一种方法是：

当接受一个更重要的新需求或者项目的其他条件发生变化时，删除优先级低的需求。

或者把它们推迟到下一版本中实现。

如果用户并没有将他们的需求按重要性和紧迫性区分开，那么项目经理就必须自己做出决策。

很可能用户并不赞成项目经理所设定的优先级，这不足为奇。

用户必须指明哪些需求必须在最初版本中得到实现，哪些需求可以延期实现。

当有多个可用方案都可以实现一个成功的系统时，应尽早在项目中设定优先级，并且要定期查看它们。

如果用户并没有将他们的需求按重要性和紧迫性区分开，那么项目经理就必须自己做出决策。

很可能用户并不赞成项目经理所设定的优先级，这不足为奇。

用户必须指明哪些需求必须在最初版本中得到实现，哪些需求可以延期实现。

当有多个可用方案都可以实现一个成功的系统时，应尽早在项目中设定优先级，并且要定期查看它们。

2）优先级规则

用户对设定优先级的第1个反应是：

“所有功能我都需要，无论采用什么方式，只要实现它就行”

如果用户知道优先级低的需求可能不会实现，那么就很难说服用户讨论需求优先级。

有些开发人员更喜欢避开设定优先级，因为他们认为：

他们可以全部完成系统功能。

事实上，即便是一个中等规模的软件项目，也有好几十个用户需求和好几百个功能需求，多到难以通过分析进行统一归类。

项目中总有一些系统功能比其他的功能更为必要。

在项目接近尾声时，当开发人员抛弃掉一些不必要的功能，以保证按期交付一些重要功能的时候，这一特性体现得尤为明显。

如果在项目的早期阶段设定优先级，并随着用户偏好、市场状况和业务事件的变更而重新评估它们。

那么，项目团队就可以“好钢用在刀刃上”，合理地将时间花在价值最高的功能中。

如果某一功能己经实现得差不多了，才得出该功能并不需要的结论。

则会造成时间上的巨大浪费，同时，也会让人感到很沮丧。

如果让用户自己设定优先级。

那么，他们将把85%的需求设定为高优先级，10%的需求设定为中等优先级，5%的需求设定为低优先级。

这并没有给项目经理很多灵活性。

如果确实是几乎所有的需求都具有最高的优先级。

那么，项目就面临着不能完全获得成功的风险，因此，应该制定出相应的计划。

可以通过废除不必要的需求，并且简化那些过于复杂的需求，来对需求做出调整。

为了帮助用户代表确认哪些需求属于低优先级的需求，分析人员可以向他们询问如下几个问题：

1. 是否有其他方法可以满足这一需求?

2. 如果忽略或推迟实现这一需求，其后果是什么?

3. 如果不立即实现这一需求，那么对项目业务目标会有什么影响?

4. 如果将这一需求推迟到下一版本中实现，用户为什么会不满意?

在一个小型项目中，项目相关人员可以非正式地就需求的优先级达成共识。

对于大型项目或有争议的项目，则需要采用一种更加结构化的方法，这样在处理过程中，可以消除一些感情因素、政策因素以及推测。

人们提出许多分析上的和数学上的技术，用于辅助需求优先级的确定。

这些方法包括：建立每个需求的相对价值和相对成本。

优先级最高的需求是那些以最低的成本生产出最高的系统价值的需求。

确定需求优先级的一些技术：

入选与落选

两两比较并排序

三层分级法

MoSCoW（莫斯科欧）排序法

在MoSCoW（莫斯科欧）优先级排序法中，四个大写字母代表在一个需求集合中四类可能的优先级类别，具体如下：

M字母，指的是：Must（必做）：需求必须满足，只有这样，解决方案才会被认为是成功的。

S字母，指的是：Should（应做）：需求很重要，并且如果可能，应当包含到解决方案中，但对于成功不是强制性的。

C字母，指的是：Could（可做）：想要但是可以推迟或者清除，只有当时间和资源都允许的时候才实现。

W字母，指的是：Won’t（不做）：表示这次不实现，但可能包含到未来的版本中。

对于如何通过比较其他需求来评级给定需求的优先级，MoSCoW（莫斯科欧）排序法并没有给出相关的依据。

MoSCoW（莫斯科欧）排序法：不关注时间，特别是需求被评定为“Won’t”时，极可能意味着“不在下个版本中做”，也可能意味着“永远不做”

设定优先级的一种方法是：

质量功能部署（简称：QFD）

质量功能部署：是将用户价值和所提议的系统功能相联系的一种综合方法。

在质量功能部署方法中，用户价值取决于两个方面：

一方面，如果实现了特定的系统特性，将为用户提供收益；

另一方面，如果不能实现系统特性，用户收益就要受到损害。

这个设定优先级的方法可适用于除了最高优先级之外的所有需求。

根据价值、成本和风险来设定优先级方法：

借鉴了质量功能部署的概念，对用户价值加以考虑。

即，考虑如果获得某个特定系统特性，会为用户提供什么收益，也考虑到如果没有那个特性，会带来什么损失。

在设定优先级的过程中典型的参与者有：

项目经理、用户代表和开发人员代表。

项目经理：负责整个过程，解决冲突，并且在必要的时候协调其他参与者的意见。

用户代表：可以提供受益和损失的程度。

开发人员代表：可以提供成本和风险程度。

根据价值、成本和风险来设定优先级，必须遵循如下8个步骤：

• 步骤1：在表格中列出要设定优先级的所有特性、用例或功能需求。

所有条目都必须在同一抽象级别上，不要把功能需求与系统特性混合在一起。

如果某些特性有逻辑上有联系，在分析中只要列出驱动较全面的项。如果有更多的项，那么就把相关的特性归成一类，并建立一个可管理的初始化列表。

如果需要的话，可以在更详细的级别上进行第二轮分析。

• 步骤2：让用户代表来估计每一个特性提供给用户或业务的相关收益，并用1-9划分等级，1代表对任何人都没用的特性，9代表具有最大价值的特性。

这些收益等级表明这些特性与系统业务需求的一致性。

• 步骤3：估计出如果没有把某一特性包括到系统中，将会给用户或业务上带来的相对损失。

仍然使用1-9划分等级，这里1代表即使不包括这一特性也无人会介意，9代表如果不包括这一特性将带来严重损失。

对于具有低收益低损失的需求只会增加费用，而不会增加价值；

步骤4：将表格中的“相对收益”和“相对损失”相加，并考虑权值，计算出每个特性的总价值。

即：总价值 = 相对收益收益权值 + 相对损失损失权值

并计算出每个特性价值占总价值的百分比。

即：“价值%”一栏。

步骤5：让开发人员估计实现每个特性的相对成本，并计算出每个特性价值占总相对成本的百分比。

使用1-9来划分等级，1代表快速而容易，9代表费时又昂贵。

根据特性的复杂度、所需要的用户界面的实际情况、重用当前代码的潜在能力、所需的测试量和文档等等，开发人员可以估算出相对成本。

步骤6：让开发人员估计出与每个特性相关的技术风险或其他风险的相对程度，并计算出每个特性所产生的风险百分比。

技术风险：是指第1次尝试实现某个特性时，不能成功的概率。

使用1-9来划分等级，1表示可以轻松地实现编程，9表示需要重点关注其可行性、缺乏具有专门知识的人员，或者使用不成熟或不熟悉的工具和技术。

如果根本无需在分析中考虑风险，就把风险的权值设为0。

步骤7：把所有的估算值都填入表格之后，就可以利用优先级公式，计算出每一特性的优先级值。

步骤8：按计算出的优先级的降序排列表中的特性。处于列表最顶端的特性是价值、成本和风险之间的最佳平衡，因此，具有最高的优先级。

Summary

设定需求优先级原因：

设定优先级有助于项目经理解决冲突、安排阶段性交付，并且做出必要的取舍。

为每一种功能建立相对优先级后，就可以规划软件的开发过程，以最低的成本提供最佳的系统。

分析人员可以向用户询问的几个问题：

1. 是否有其他方法可以满足这一需求?

2. 如果忽略或推迟实现这一需求，其后果是什么?

3. 如果不立即实现这一需求，那么对项目业务目标会有什么影响?

4. 如果将这一需求推迟到下一版本中实现，用户为什么会不满意?

确定需求优先级的技术，包括：

入选与落选

两两比较并排序

三层分级法

MoSCoW（莫斯科欧）排序法

设定优先级的质量功能部署方法：

质量功能部署（简称：QFD）

质量功能部署：是将用户价值和所提议的系统功能相联系的一种综合方法。

根据价值、成本和风险来设定优先级，有8个步骤。

以“化学品跟踪系统”的特性为例，介绍了根据价值、成本和风险来设定优先级的过程。

注意：

计算出来的优先级序列，只能作为一种指导策略的参考。

客户和开发者代表应该讨论，从而达成共识，并根据使用情况来校正。

可以适当调整每一因素的权值，直到所计算出的优先级序列与后来对测试集中需求的重要性评估相吻合为止。

在把需求优先级的设定，应以客观和分析为基础

第11章 需求确认

• 需求确认：是指开发方和用户方共同对软件需求规格说明进行评审，双方对需求达成共识后作出承诺。

• 是需求开发的最后一个环节。可以通过内部评审、同行评审以及用户评审的方式来完成。

• 项目组内部评审或同行评审：主要是根据公司规范和评审人员本身的经验对需求分析中不明确、不合理、不符合逻辑、不符合规范的地方予以指正。

• 用户评审：主要是对描述的软件实现是否真正符合他们的需求，能否帮助他们解决问题等方面做出评定。

• 需求确认的目的：是要检验需求是否能够反映用户的意愿。是尽可能地发现需求里的错误，减少因后期修改需求错误所带来的损失。

需求确认的提出：

避免信息衰减的关键手段

1. 文档

   如果信息在传递的过程中仅靠口头传递，就难免发生遗忘、加工等情况。

   因此，必须在这个过程中有效地利用文档，将达成共识的信息文档化。

   但这种方法只是用来辅助沟通的，而不是代替沟通。

2. 评审

    评审：在很多人的脑海中就是得出一个通过与否的结论，这也是导致需求评审工作流于形式的罪魁祸首之一。
    
    评审：是通过再次的审读，尽早地暴露出错误。
    
    最简单、有效的评审：是在用户代表阐述了需求之后，需求分析员用自己的语言再复述一遍，以确保沟通没有失真。
    
    评审的首要任务：是确认需求是否充分，并正确的反映了用户的需求。
   

需求确认：

首先需要用户来验证结构和文档化后的需求是否和他们的想法一致，是否把用户的真实意图描述清楚了，以保证需求本身的正确性。

对于后续设计开发阶段的人员也需要对需求进行评审，以保证需求的可实现性，确认需求描述是否清楚，是否是可以实现的，对于业务对象，流程和规则是否存在不可实现的模糊描述词语。

对于测试人员，则主要是确认需求是否是可测试的，是否在需求描述中存在不确定和不可测试的词语。

不仅仅是需求阶段对需求文档的评审，还需要关注设计，开发等各阶段对需求的实现情况的验证。指在需求规格说明完成之后，对需求规格说明文档进行的验证活动。是对需求的复查和审核，目的是发现需求中存在的错误，以便及时更正，避免在后期实施中修改造成大量的损失。

好的需求将会带来好的系统质量和用户满意度，降低系统后期维护和用户支持的费用。

需求确认的任务：

需求确认的活动确保以下几个方面的内容：

1. 软件需求规格说明是否正确描述了目标系统的行为和特征；

2. 从系统需求、业务规则或其他来源中得到软件需求；

3. 需求是完整的和高质量的；

4. 所有人对需求的看法是一致的；

5. 需求为进一步的软件开发和测试提供了足够的基础。

需求确认的任务：就是要求各方人员从不同的技术角度对需求规格说明文档做出综合性评价。

需求确认的内容：

一般来说，从下述4个方面进行需求验证：

1）一致性：所有需求必须是一致的，任何一条需求不能和其他需求相矛盾。

2）完整性：需求必须是完整的，软件需求规格说明应包括用户需要的每一个功能和性能。

3）现实性：指定的需求在现有的硬件技术或软件技术的基础上应该是基本上可行的。

4）有效性：必须证明需求是正确有效的，确实能解决用户需求间的矛盾。

一般可根据软件系统的特点和用户的要求增加一些检验内容。

如：软件的可信特性，即安全性、可靠性、正确性以及系统的灵活性等。

验证需求规格说明的方法，除形式化方法外，大部分只能通过人工进行检测。

此外，部分项目相关人员也不愿意在需求确认方面花费时间。

形式化的验证方法主要使用数学方法：

即，将软件系统抽象为用数学符号表示的形式系统。

然后，通过推理和证明的方式来验证软件系统中的一些性质，如：完整性、一致性、可信特性等。

这种方法的好处：是严格和自动化。

这种方法的不足：是对数学基础的要求太高，难度较大。

通过人工进行检测的方式有很多，例如：需求评审。

这种方式就是让与项目相关的所有人员参加，并根据验证的内容人工评审软件需求规格说明文档。

另外，还可结合现有的一些软件技术，如：设计测试用例的方法等，对软件需求进行多方面的、有效的检验和测试

需求评审方法

需求评审：是由需求评审员对软件需求规格说明进行检查，以发现其所存在的问题。

通过对需求规格说明的评审，可以发现其中的不确定和二义性的要求等。

需求评审，可划分为：非正式评审和正式评审

非正式评审：由开发人员描述系统并征求意见。

包括：把工作系统分发给许多其他有关人员，粗略地看一看或走过场地检查。

非正式评审的好处：是能培养其他人对系统的认识，并可获得一些非结构化的反馈信息。

非正式评审的不足：是不够系统化和不彻底，或者在实施过程中不具有一致性，并且非正式评审不需要记录，完全可以根据个人爱好进行。

非正式评审方法包括：

——同级桌面检查：就是请一位同事检查系统

——轮查：就是同时请若干同事分别检查可交付的系统

——走查：作者向评审员描述系统，请求做出评论。

正式评审：由不同背景的审查人员组成小组，阅读需求规格说明文档，把其中的问题记录下来，再转送给软件开发人员。

正式评审：有专门的审查人员，正规的审查过程和步骤，审查人员有严格的分工和职责。

需求评审的组成人员

在需求正式评审过程中，应由具有不同背景的人组成一个小组，对需求规格说明文档进行评审。

审查人员由4个方面的人组成：

1）从事软件系统需求开发的相关人员。

这类人员主要是指编写需求规格说明的系统分析员及相应参与人员等。

2）具有需求分析经验和知识的人员，以及领域专家等。

这些人可以审查需求规格说明文档是否符合标准，是否存在错误等。

3）客户或用户代表。

这些人可以保证需求规格说明能正确地、完整地描述他们的需求。

4）软件开发人员，

如：设计人员、测试人员、项目经理等。这些人可以发现需求规格说明中存在的不可实现的、含糊或二义性等。

审查人员的主要角色：

作者：编写正在被审查的需求规格说明文档的人，通常为系统分析员。

他们听取其他审查员的评论，并回答其他审查员提出的问题，但不参与讨论。

调解员：审查的调解与主持人，通常为项目总负责人。

调解员与作者一起制定审查计划，协调审查期间的各种活动，以及推进审查工作的进行。

读者：主要由审查员扮演，审查需求规格说明文档，并提出问题，以及自己的看法和理解。

记录员：以标准的形式记录在审查中提出的问题和缺陷。

记录员必须仔细地整理自己所写的材料，以确保记录的正确性。

需求评审的过程

规范的评审过程包括：规划、总体会议、会前准备、评审会议、返工、跟踪6个阶段。

1）规划

由作者和调解员对审查进行规划。

如：决定谁参加审查，审查之前应准备什么材料，审查会议的日程安排等。

2）总体会议

总体会议：可以为审查员提供了解会议的信息。

包括：要审查的材料背景，作者所做的假设和作者的特定审查目标。

如果所有的审查员对要审查的项目都很熟悉，那就可以省略本次会议。

3）准备

准备工作：做的好不好直接关系到评审会议的质量。

应为每位评审者提前提供相关资料，提供时间做相关阅读、查找错误。

评审者可将阅读时发现的文字、版面类的错误直接发给作者，无需在评审会议上讨论，以便节省会议时间，提高会议质量。

4）评审会议

在进行审查的过程中，审查员审查软件需求规格说明中的每一个需求。

当审查员提出可能的错误或其他问题时，记录员就记录这些内容，它们可以成为需求规格说明的作者的参考依据。

会议的目的是尽可能多地发现需求规格说明中的重大缺陷。

开审查会的时间不宜过长，如果需要更多的时间，就另外再安排一次会议。

5）返工

当发现需求规格说明中出现问题时，作者必须在审查会之后安排一段时间用于修改文档。

如果把不正确的需求拖延到以后修改，将十分费时。

马上修改可以解决二义性和消除模糊性，并为成功开发项目打下坚实的基础。

6）跟踪

当发现同一类错误多次出现在需求规格说明书中不同地方时，就会发现评审中提出的问题没有得到有效的解决。

因此，应对提出的问题是否解决进行跟踪、督促，避免同类问题再出现。

需求评审面临的困难

当需求规格说明编写完成后，开发人员希望能尽快地开发软件系统。

认为需求评审工作是重要的。

但最重要的是后面的开发工作，从而导致需求评审成为“走过场”。

在需求评审工作中，一些常见的问题说明如下：

1）大型的需求文档

对于一个大的复杂软件系统，其需求规格说明往往有几百页，要审查这样的需求规格说明工作量是非常大的。

既使一个中型的需求规格说明，审查人员可能会认真地检查开始的部分，有耐心的人可能会审查到中间的部分，但无人可以坚持检查到最后。

这就导致忽略审查过程，而直接进入软件的开发工作。

对于上述问题的解决方案是：

可在强调评审工作重要性的基础上，采用多人分段审查的方式，让一些审查员，从文档的不同位置开始检查，以确保认真地检查其中的每一页，或者采取分组方式，不同组分别审查材料的不同部分。

2）庞大的审查小组

一个项目可能涉及许多的相关人员，如：用户、部门经理、销售部门等，他们都与需求相关。

这些人都可以成为需求评审员。

然而，评审小组过于庞大，将导致难于安排会议，并且在审查会议上经常引发题外话，在许多问题上也难于达成一致意见。

这种情况经常导致花了大量的时间而无较好的结果等。

对于上述这些困难，往往要根据实际情况给予解决。

例如，可在强调评审工作重要性的基础上，采取解释与说明的方式，采用多人分段审查的方式，以及采取分组方式等。

测试需求

测试需求概述

测试需求，是验证需求是否是正确的、完整的、无二义性的。

测试人员要能够分辨出来问题点，并跟用户进行核对，确定用户的真实需求。

测试需求的输入主要包括：

需求规格说明、用户用例、界面设计、项目会议或与用户沟通时有关需求信息的会议记录、其他技术文档等；

测试需求的输出主要包括：

问题点及修改建议，以及测试分析结果。

在部分需求稳定时，就可以开始设计测试用例，及早发现问题并以较少的费用解决这些问题。

测试需求：是对测试目标的概括，根据测试需求，了解测试时所应测试的功能点。

测试需求：主要是整理测试焦点。

包括：一些界面、输入域、业务流程、数据等。

并明确测试焦点的优先级，为测试用例的设计提供测试所需的功能点信息。

测试需求：是告诉要测什么，而测试用例是告诉怎么测。

好的测试需求：能发现需求中显性和隐性的测试焦点，从而能更好地指导测试用例的设计。

在开发过程的早期阶段，可以从用例中获得概念上的功能测试用例。

即，可验证需求规格说明和分析模型，并做出评价。

为什么要进行测试需求？

1）把不直观的需求转变为直观的需求。

使得测试范围可以度量；

使得独立的功能点其对应的所有的处理分支可以度量；

使得该系统需要测试的业务场景可以度量；

2）把不明确的需求转变为明确的需求，明确其功能点对应的输出、处理和输出；

3）把不能度量的需求转变为可度量的需求。

包括：度量测试范围，度量处理分支，度量业务场景。

需求测试的范围主要有：

1）需求的背景，目标，影响范围；

2）系统的输入输出，类型，精度，允许的出错次数，输出的格式，数据的来源以及正确性；

3）响应时间，提示的方式，异常处理方式，性能指标；

4）主要流程描述，操作流程和步骤说明，分析是否合理化；

5）需求的上下文是否一致，有没有与其他需求发生冲突；

6）需求逻辑是否足够清晰，每个条款是否都包含描述问题及解决问题；

7）需求是否都是可测试的；

8）寻找隐含的需求，和相互依赖的需求。

4）推荐的需求文档格式的内容

主要有：

1）业务名称解释；

2）需求背景及目标介绍；

3）用户操作场景说明；

4）功能总览：

如：逐项叙述对系统所提出的功能要求，说明输入什么量、经怎么样的处理、得到什么输出；

5）系统交互图；

6）界面原型；

7）业务规则说明；

8）业务正常流程：如：功能模块流程，主要操作流程；

9）业务异常流处理：如：异常场景，错误提示；异常流转。

4）推荐的需求文档格式的内容

这里要注意：

需求测试：不等同于集成测试或者系统测试。

软件测试，都是软件已经编写完成的条件下，判断软件是否会出错。

而需求测试，只是验证需求是否真正是用户的要求。

Summary

需求确认：是软件工程中一项重要的活动。

需求确认：是需求工程中发生的对需求规格说明文档进行的验证与确认活动。

需求确认：不仅要发现问题，而且要监督、跟踪问题的解决。

验证和确认的过程：贯穿于项目开发的每个阶段。

尽早的了解系统需求，可很大程度上节约后期修改的成本。

需求确认，主要包括：需求的评审和作出承诺。

需求确认的目的：

是要检验需求是否能够反映用户的意愿。

是尽可能地发现需求里的错误，减少因后期修改需求错误所带来的损失。

需求确认，主要包括：需求的评审和作出承诺。

需求确认的目的：

是要检验需求是否能够反映用户的意愿。

是尽可能地发现需求里的错误，减少因后期修改需求错误所带来的损失。

（1）需求确认的任务：

是对需求规格说明文档做出综合性评价。

需要确认的内容主要是验证需求的：

一致性、完整性、现实性、有效性4个方面。

（2）需求确认的内容：

一致性

完整性

现实性

有效性

（1）需求评审方法：

需求评审：就是由需求评审员对软件需求规格说明进行检查，以发现其所存在的问题。

需求评审可划分为：非正式评审和正式评审

（2）需求评审的组成人员：

1）从事软件系统需求开发的相关人员。

2）具有需求分析经验和知识的人员，以及领域专家等。

3）客户或用户代表。

4）软件开发人员。

3）需求评审的过程：

规范的评审过程包括：规划、总体会议、会前准备、评审会议、返工、跟踪6个阶段。

（4）需求评审面临的困难：

1）大型的需求文档

对于一个大的复杂软件系统，其需求规格说明往往有几百页，要审查这样的需求规格说明工作量是非常大的。

2）庞大的审查小组

一个项目可能涉及许多的相关人员，如：用户、部门经理、销售部门等，他们都与需求相关。

测试需求的解释：

测试需求，是验证需求是否是正确的、完整的、无二义性的。

为什么要进行测试需求？

1）把不直观的需求转变为直观的需求。

2）把不明确的需求转变为明确的需求，明确其功能点对应的输出、处理和输出；

3）把不能度量的需求转变为可度量的需求。

需求测试的内容：

1）需求的背景，目标，影响范围；

2）系统的输入输出，类型，精度，允许的出错次数，输出的格式，数据的来源以及正确性；

3）响应时间，提示的方式，异常处理方式，性能指标；

4）主要流程描述，操作流程和步骤说明，分析是否合理化；

5）需求的上下文是否一致，有没有与其他需求发生冲突；

6）需求逻辑是否足够清晰，每个条款是否都包含描述问题及解决问题；

7）需求是否都是可测试的；

8）寻找隐含的需求，和相互依赖的需求。

推荐的需求文档格式的内容：

1）业务名称解释；

2）需求背景及目标介绍；

3）用户操作场景说明；

4）功能总览；

5）系统交互图；

6）界面原型；

7）业务规则说明；

8）业务正常流程：如：功能模块流程，主要操作流程；

9）业务异常流处理：如：异常场景，错误提示；异常流转。

第12章 需求管理实践

（1）需求管理内容
软件需求工程，分为：需求开发和需求管理。
需求开发活动：
包括：获取需求、分析需求、描述需求和确认需求。
需求开发的交付物：
包括：业务需求、用户需求、功能需求、非功能需求、数据字典和各种分析模型等。
在这些交付物经过评审，且核准之后，这些条目的任何已定义子集都可以组成需求基线。[toc]

第0章 引言

项目失败或严重超支的8个最重要原因中有5个都与需求相关：

1. 需求不完整
2. 缺乏用户的参与
3. 用户期望不实际
4. 需求和需求规格说明的变更
5. 提供许多不必要的功能。

“软件需求分析”：

就是对需要解决的问题进行详细分析

弄清楚需要解决的问题，开发人员才能顺利开发出用户真正需要的软件。

如果一味追求进度，而忽略软件需求分析，很可能南辕北敏，开发变得毫无意义。

“软件需求分析”：是连接开发人员和用户之间的重要纽带。只有真正理解用户的需求，才能设计出用户所需要的软件。

“软件需求分析”：

就是分析软件用户的需求是什么。

如果投入大量的人力、物力、财力、时间，开发出的软件却没人要，那所有的投入都是徒劳。

如果费了很大的精力，开发一个软件系统，最后却不满足用户的要求，从而要重新开发过，这种返工是让人痛心疾首的。

总之，软件需求问题不仅关系到软件项目开发的成功，也关系到软件产业的发展，更关系到各行各业信息化目标的实现。

解决软件需求问题已成为软件领域刻不容缓的任务。

第1章 软件需求概述

软件需求的好坏直接关系到软件的成功与否。

客户提出的需求是软件系统的源头，它定义了软件系统的意图和目的。

如果需求遗漏或完成得不好，不管系统多么完美，系统也是失败的。

为了得到有效的需求，需要采用有效的方法与用户广泛地交流。

定义：

① 用户解决问题或达到目标所需的条件或权能。

② 系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能。

③ 一种反映上面两种所描述的条件或权能的文档说明。

基本原则：

1）并没有一个清晰、毫无歧义性的“需求”术语存在，真正的“需求”实际上在人们的脑海中。

2）定义问题，而不是解决方案。

3）定义系统，而不是项目。需求定义了系统需要做什么：它们是一组目标。

4）区分正式和非正式部分。

5）避免重置。

6）保持每个需求定义的大小在合适的范围内是良好的做法。

软件需求的层次：

1. 业务需求（Business Requirement ）
2. 用户需求（User Requirement）
3. 软件需求（Software Requirement）

业务需求：

是从业务角度描述的，是指导软件开发的高层需求。

业务需求的目标体现在两个方面：

1）问题：解决企业运行过程中遇到的问题。

2）机会：抓住外部环境变化所带来的机会，以便为企业带来新的发展。

业务需求：是从各个不同的人那里收集来的，它们包括主办者、客户、支付或采购软件产品者、开发公司的高级管理人员等。

业务需求：阐明产品的高层次概念和产品的主要业务内容。

业务需求：说明客户、公司和想从该系统获利的风险承担者或从系统中取得结果的用户所要求的目标。

业务需求：为后继工作建立了一个指导性的框架。

用户需求：

是指描述的是用户使用软件需要完成什么任务。

用户需求：是在业务需求基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立用户角度的需求。

用户需求具有两个方面的特点：

1）零散：用户会给出不同角度、不同层面、不同粒度的用户需求。

2）存在矛盾：由于用户的层次不同，导致需求的片面性，甚至在不同用户之间会有不同的观点。

软件需求：

是需求分析与建模的产物。

软件需求：必须根据用户需求来考虑，并要与业务需求所设定的目标相一致。

用户需求：具有零散、存在矛盾的特点。

—— 因此，需求分析人员还需要对其进行分析、提炼、整理，从而生成指导开发的、更精确的软件需求。

软件需求可以分为：

• 功能需求（Functional Requirement）
• 非功能需求（Non-Functional Requirement）
• 设计约束

功能需求：

是一个系统必须提供的活动和服务描述。

功能需求：定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务需求。

开发人员根据功能需求来设计软件以实现必需的功能。

功能需求：描述软件系统所应具有的外部行为，它在开发、测试、质量保证、项目管理以及相关项目功能中都将起到重要的作用。

非功能需求：

描述了系统展现给用户的行为和执行的操作等。

非功能需求：包括外部界面的具体细节、性能要求及质量属性。

非功能需求：是产品必须具备的品质，它们可以让产品更具有吸引力、易于使用、快速、可靠或者安全。

非功能需求：通常并不改变产品的功能。

一般来说，不管增加多少的质量属性，功能需求都会保持不变，功能需求和非功能需求是相辅相成密不可分的。

非功能需求：经常被忽略，因为它们不易被发现，发现后不易表达、实现以及测试。

在系统实现过程中，有时候满足非功能需求往往比满足功能需求更为重要。

设计约束：

是指对开发人员在软件产品设计和构造上的限制，产品必须遵从的标准、规范和合约。

设计约束：包括：非技术因素的技术选型、预期的软硬件环境和预期的使用环境三大类型。

技术开发团队在决定架构、选择技术时，会受到企业实际的软硬件环境的影响，如果忽略了这个方面的因素会给项目带来一些不必要的麻烦。因此，在需求人员整理需求时，应该将这些预期的软硬件环境描述出来。

实现有效的需求工程过程可以让组织受益匪浅。减少开发后期以及整个维护过程中不必要的返工，并可带来极大的回报。

高质量软件需求的可以带来好处：

• 减少需求的缺陷
• 减少开发过程中的返工
• 减少不必要的特性
• 降低改进成本
• 加快开发进度
• 提高沟通效率
• 控制需求范围的改变
• 项目更有序
• 对系统测试的评估更准确
• 10）提高客户和开发人员的满意度

需求陈述的特点：

1. 完整性

   • 每一项需求都必须完整地描述即将交付使用的功能。
   • 它必须包含开发人员设计和实现这项功能需要的所有信息

2. 正确性

   • 每一项需求都必须准确地描述将要开发的功能。
   • 如果一项软件需求与其相对应的系统需求发生冲突就是不正确的。
   • 只有用户代表才能决定用户需求的正确性。

3. 可行性

   • 需求必须能够在系统及其运行环境的已知能力和约束条件内实现，因此，由开发人员来进行可行性检查，判断技术上能够实现哪些需求，或者什么功能需要额外的成本才能实现。

4. 必要性

   • 每一项需求记录的功能都必须是用户的真正需要，或者是为符合外部系统需求或某一标准而必须具备的功能。

   • 每项需求都必须来源于有权定义需求的一方。对每项需求都必须追溯至特定的客户需求的来源。

5. 有优先次序

   • 为每一项功能需求、特性或用例指定一个实现优先级，以表明它在产品的某一版本中的重要程度。
   • 如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度。

6. 无歧义

   • 一项需求对所有读者应该只有一种一致的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户的语言表达出来。
   • 避免二义性的有效方法包括对需求文档的正规审查、编写测试用例、开发原型以及设计特定的方案脚本。

7. 可验证性

   • 检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等方法来确定产品是否确实按需求实现了。
   • 如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。
   • 一份前后矛盾，不可行或有二义性的需求也是不可验证的。

需求规格说明的特点：

1）完整性

不能遗漏任何需求或必要的信息。

需求遗漏问题很难被发现，因为它们并没有列出来，着重于用户任务而不是系统功能会有助于避免遗漏需求。

2）一致性

需求的一致性是指需求不会与同一类型的其他需求或更高层次的业务、系统或用户需求发生冲突。

必须在开发前解决需求不一致的问题。只有经过调查才能知道需求正确与否。

3）可修改性

必须能够对SRS作必要的修订，并可以为每项需求维护修改的历史记录。

这要求对每项需求进行唯一标识，与其他需求分开表述，从而能够明确地提及它。

每项需求只能在SRS中出现一次。

如果有重复的需求，很容易因为只修改其中一项而产生不一致。

4）可跟踪性

需求如果是可跟踪的，就能找到它的来源、它对应的设计单元、实现它的源代码以及用于验证其是否被正确实现的测试用例。

可跟踪的需求都有一个固定的标识符对其唯一标识。

需求与其他软件项目过程的关系

软件需求阶段在系统开发的整个生命周期中处于最基础、最重要的位置。

只有在需求分析工作做得比较扎实到位，文档经过开发方与用户方的充分参与、查验、修改、完善，才能为设计实施迈出坚实的一步。

软件需求活动用于软件项目的初始阶段，它的结果接着用于开发的下一个阶段，即设计阶段。

随着更强调迭代的方法学的出现，需求活动的使用被扩展到每一个开发迭代过程中，而且需求分析和设计的界限也变得模糊。

软件需求阶段是以真实世界建模为对象，并找出系统要处理什么的过程。

此阶段需要把一组复杂的需求分解为基本元素和关系，之后的解决方案建立在这些元素和关系的基础之上。

此阶段的结果是生成软件需求规格说明。

根据项目的大小不同，需求规格说明的详细程度各异，但是即使是最小的项目，也应该有某种成文的需求规格说明供开发团队使用。

需求过程中最为困难工作是编写详细技术需求，这包括所有面向用户、面向机器和其他软件系统的接口等。

这个过程一旦做错，将最终给系统带来极大损害，并且以后再对它进行修改也极为困难。

需求与各过程间的关系

（1）需求与制订项目计划关系

需求是制订项目计划的基础，开发资源和进度安排的预估都要建立在对最终产品的真正理解之上。

项目计划所指出的所有希望特性不可能在允许的资源和时间内完成，因此，需要缩小项目范围或采用版本计划对功能特性进行选择。

（2）需求与项目跟踪和控制关系

在项目实施过程中，要监控每项需求的状态，以便项目管理者能发现设计和验证是否达到预期的要求。

如果没有达到，管理者通常请求变更控制过程来进行范围的缩减。

（3）需求与变更控制关系

在需求编写成文档并制订基线以后，所有后续的变更都应通过确定的变更控制过程来进行。

（4）需求与系统测试关系

用户需求和功能需求是系统测试的重要参考。

如果未清楚说明产品在多种多样条件下的期望行为，系统测试者将很难确定正确的测试内容。

系统测试是一种方法，可以验证计划中所列的功能是否按预期要求实现了。

测试也验证了用户任务是否能正确执行。

5）需求与用户编制文档关系

软件需求是编写文档的重要参考，低质量和拖延的需求会给编写用户文档带来极大的困难，需求文档是所有设计、实现工作的基础。

（6）需求与构造过程关系

构成软件项目的主要产品是交付可执行软件，而不是需求说明文档。

要根据功能需求来确定设计模块，而模块又要作为编写代码的依据。

采用设计评审的方法来确保设计正确地反映了所有的需求。而代码的单元测试能确定是否满足了设计规格说明和相关的需求。

本章小结

（1）软件需求的定义：给出了几种主要的软件需求定义和软件需求定义的一些基本原则。

（2）需求的层次：需求包括三个不同的层次，它们是：业务需求、用户需求和软件需求

（3）软件需求的分类：软件需求可以分为：功能需求、非功能需求和设计约束三种类型。

（4）高质量软件需求的好处及好的软件需求具有的特点。

（5）需求与其他软件项目过程的关系。

第2章 用户眼中的软件需求

软件需求来源于用户，用户是能够直接或间接从软件产品中获益的个人或组织。

软件用户可能提出需求、出钱、选择、说明、使用或者接收软件产品的输出。

用户”是一种泛称，它可细分为：

• “客户”（customer） 掏钱买软件产品的用户称为客户；
• “最终用户”（the end user）真正操作软件产品的用户叫最终用户。
• “间接用户”（或称为关系人）。既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品有很大的影响。
  • 例如：财务软件，开发商在把“财务软件”卖给客户之前，必须得到国家财政部的批准。否则，即使该软件的功能是完美的，但却被政府认为是非法的。所以，国家财政部就是所有财务软件的间接用户。
  • 又例如：市面上流通的信息安全软件、杀病毒软件必须得到国家公安部的批准，否则不能销售

优秀的软件产品建立在优秀的需求基础上，而高质量的需求来源于用户与开发者之间的有效沟通与合作。

协同合作要想取得成果，需要所有人员都清楚自己的需要，理解并尊重其他合作者的需求。

通常用户与开发者要建立合作伙伴关系。

十项软件客户权利清单

1. 要求需求分析员使用客户的语言进行交流
2. 要求需求分析员了解客户的业务和目标
3. 要求需求分析员用适合的形式记录需求
4. 要求需求分析员解释需求过程生成的所有工作结果
5. 要求需求分析员和开发人员尊重客户，并以合作和专业的态度与客户进行互动。
6. 要求需求分析员和开发人员为需求和产品实现提供思路和备用方案
7. 要求开发人员实现能让产品使用起来更容易、更有趣的特性
8. 调整需求，便于重用已有的软件组件
9. 在提出需求变更时，获得对变更的成本、影响及二者权衡关系的真实评估
10. 获得满足功能和质量要求的系统，这些要求必须事先告知开发人员并征得其同意

十项客户的需求义务清单

1. 为需求分析员和开发人员讲解业务并定义业务术语
2. 提供需求，阐明需求，通过与开发人员的交互将需求充实完善
3. 对系统需求的描述必须详细、准确
4. 需要时，及时对需求做出决定
5. 尊重开发人员对需求成本和可行性的评估
6. 与开发人员协作，为功能需求、系统特性和用例设置优先级
7. 审阅需求文档，评估原型
8. 发现需要变更需求时，及时与开发人员沟通
9. 按照开发组织的变更控制过程提出需求变更
10. 尊重需求分析员在需求工程中使用的过程

对需求达成一致

对在建产品的需求达成一致或是在某部分达成一致是客户和开发人员关系的核心。

涉及的多个角色应形成如下共识：

• 客户承认需求描述了他们的需要。
• 开发人员承认理解需求，并且认为它们是可实现的。
• 测试人员承认需求是可验证的。
• 管理层承认需求可以达成他们的业务目标。

第3章 需求工程

需求工程分为：需求开发和需求管理两部分。

需求分析是需求开发的其中一个环节，确立了需求工程与软件工程是同等重要的观念。

需求工程：是确保软件需求质量的。

软件工程：是确保软件开发质量的。

一个软件项目要想成功，必须握有需求工程和软件工程这两把利剑在手。

需求工程：是随着计算机的发展而发展的。

在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，软件需求很少受到重视。

随着软件系统规模的扩大，软件需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。

人们逐渐认识到软件需求活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。

需求工程：是用已证实有效的技术和方法进行需求分析、确定客户需求、帮助分析人员理解问题，并定义目标系统的所有外部特征的一门学科。

需求工程：通过合适工具和记号，描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。

需求工程：可分为：系统需求工程和软件需求工程。

系统需求工程，将软件需求开发和系统需求开发结合起来，在系统工程的开始阶段起到重要的作用。

软件需求工程，是一门分析并记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发，把这些系统需求转换成软件的需求描述和性能参数。

需求工程定义：

Davis的定义：“直到(但不包括）把软件分解为实际架构组建之前的所有活动”，即软件设计之前的一切活动。

Brays的定义：认为需求工程是“对问题域及需求做调查研究和描述，设计满足系统的特性，并用文档给予说明。这个定义明确指出了需求工程的任务就是获取、分析和表达软件的需求”

HerbKrasner（赫克拉斯纳）定义了五阶段生命周期：

1. 需求定义和分析
2. 需求决策
3. 形成需求规格
4. 需求实现与验证
5. 需求演进管理

需求工程：主要是抽取需求、模拟和分析需求、传递需求、认可需求和进化需求。

需求工程的定义：主要是抽取需求、模拟和分析需求、传递需求、认可需求和进化需求。每个活动都有它基本的动机、任务和结果，也有各自的困难所在。

需求工程的组成：需求开发和需求管理两部分。

Ø需求开发包括：需求获取、需求分析、形成需求规格、需求确认。

Ø需求管理包括：需求变更控制、版本控制、需求跟踪、需求状态跟踪。

初始循环

脉络循环

细节循环

第四章 需求获取

需求获取阶段的任务：就是获取用户的需求信息。

需求获取：是软件需求的早期活动，也是十分重要的一步。

由于需求获取是软件开发中最困难、最关键、最易出错和最需要交流的活动，故其只能通过用户与需求分析员之间进行高度的合作和交流才能成功。

需求获取阶段的活动可分为：

1. 确定需求开发计划
2. 确定项目的目标和范围
3. 确定调研对象
4. 需求信息收集

需求开发计划的任务：是确定需求开发的实施步骤，给出收集需求活动的具体安排和进度。

软件需求：是分析、理解和描述用户的需求，着重于软件系统“做什么”，而不是如何实现软件系统。

为了保证软件需求有充分的时间和经费，在安排软件需求的实施步骤、收集需求活动的进度时，只能考虑与需求开发相关的工作。

否则，将会导致软件需求花费的时间过长、成本过高，不利于有效地进行软件需求的活动。

在安排进度时，应考虑困难性和灵活性。

例如：在收集用户需求的活动中，由于用户可能出差或开会，不一定能保证在规定的时间内进行交流，因此，需要与用户预约时间，及时调整时间和计划。

此外，书写和整理需求规格说明也是需花费时间的，故在安排进度和时间时应予以考虑。

项目目标和范围的基本任务是：

—— 根据项目目标把项目相关人员定位到一个共同的和明确的方向上，并决定软件系统的范围。

项目的目标主要包括：

—— 项目开发的目的和意义，以及软件系统应实现的业务需求。

项目的范围：

—— 是指软件系统具体应包括和不应包括的部分，以及软件系统所涉及的各个方面。

如：计算机硬件和其他软件系统等，即软件系统在一个完善的环境中最终具有的功能。

项目的业务需求代表了需求层次中最高层的需求，为软件系统定义了作用的范围。

需求信息的类型

1. 业务需求
   1. 描述用户或开发机构，通过产品可获得的利益和利润。
   2. 以及与产品相关的发展规划等方面的信息。
2. 用例说明
3. 业务规则。有关业务过程的操作原则。
4. 功能需求。定义了系统应该做什么，它们是软件需求规格说明的一部分。
5. 性能需求
6. 外部接口需求
7. 约束
   1. 约束：是指一些合理限制设计者和程序员选择的条件。
   2. 约束：必须写入软件需求规格说明。
   3. 施加不必要的约束，将妨碍提出一个好的解决方案，将会降低利用现有商业化软件集成解决方案的能力，
   4. 一定的约束有助于提高产品质量。
8. 数据定义
   1. 当客户描述一个数据项，或一个复杂的业务数据结构的格式、允许值或默认值时，就是在进行数据定义。
   2. 把这些集中在一个数据词典中，作为项目参与者在整个项目的开发和维护中的主要参考文档。
9. 解决方案
   1. 如果一个客户描述了用户与系统交互的特定方法，使系统产生一系列活动，这时，就是在听取建议性的解决方案，而不是需求。

需求收集中应注意的问题

1. 应能适当地调整收集范围
   • 在收集需求的开始，需求分析员并不知道用户需求量的大小，可以根据系统的范围适当扩大收集范围。
   • 收集的范围不能过于扩大，因为范围扩大，收集的需求有些可能不是真正的需求，将导致分析员要花费大量的精力和时间，来理解和分析这些需求。
   • 收集的范围也不能太小，否则有些重要需求会被遗漏或排除在外。
2. 弄清楚用户所做的假设和冲突。
   • 尽量把用户所做的假设解释清楚，特别是发生冲突的部分。这就需要根据用户的信息去理解。
   • 以明确用户没有表达清楚的需求。
3. 理解用户的思维过程、专业知识和术语。
   • 尽量理解用户的思维过程，特别是尽量熟悉和掌握用户具有的一些专业知识和术语。
4. 避免受不熟悉细节的影响。
5. 避免讨论一些具体的解决方案。
6. 需求收集工作的结束。
   • 如何决定收集工作的结束，并没有一个简单和严格的标准，需根据实际情况进行判断。
   • eg
     • 用户不可能再提供更多新的需求信息。
     • 用户重复提出以前已提出的需求信息。
     • 与用户的讨论开始进入设计方面的工作。
     • 需求分析员本身已提不出更多的问题。
     • 安排收集工作的结束时间已到。
7. 非功能需求的确定
   • 非功能需求：是衡量软件能否良好运行的定性指标。
   • 非功能需求：也是非常重要的。
   • 可靠性、可扩展性、安全性、互操作性、易使用性、可维护性、用户界面友好等。
   • 必须根据用户对系统的期望来确定非功能需求。
8. 收集非功能需求的一些方法：
   1. 将不同用户类代表，提出的可能很重要的非功能需求进行综合，并根据其中的每个需求设计出许多方法，然后，根据用户的回答，使这些需求更明确。
   2. 需求分析员与用户一起对每一个非功能需求，制定可测试和可验证的具体标准。如果这些需求缺乏评价标准，就无法说明开发出的软件系统是否已满足这些需求。
   3. 设计与非功能需求相冲突的假设示例，利用反例来提示用户。

需求获取方法

1. 面向目标的方法
   • 目标是用户所期望达到的目的。
   • 层次性是目标的一个重要特征。
   • 从高层来说，目标是抽象的问题描述。
   • 从底层来说，则是具体的实现方式，即技术需求描述。
   • 这有利于需求的逐步精化，通过需求对高层目标的可追溯性，建立起软件需求与业务目标的关系。
   • 因此，面向目标方法不仅被用来进行需求获取、分析，还被应用于需求协商等领域。
2. 面向目标的方法的优点有：
   1. 容易理解和交流，可以保证需求的完整性、避免无关的需求。
   2. 目标本身所具有的层次关系，使得需求文档更加结构化，增强了可读性。
   3. 有助于将软件需求与业务环境联系起来，有助于解决多视点之间的冲突。
   4. 由于目标方法可以将稳定的需求和经常变化需求区分开，有利于需求的管理。
3. 基于场景的方法
   • 基于场景的方法：是通过应用环境的某一特定情景的描述，来阐述用户的需求。
   • 由于这一方法非常便于涉众之间的交流，并且提供了一种将需求与实际经验相结合的机制，因此，对于需求的获取和确认有很大的帮助。
   • 基于场景的方法：目前应用最广泛的一种就是基于用例的方法。
     • 用例是从用户的观点、以交互的方式，对于系统的行为特征进行的描述，而场景一般认为是用例的一个实例。
4. 面向视点的方法
   • 视点是对于涉众局部观察角度的一种抽象。
   • 在多视点需求工程中，需求分析人员从一组涉众处获取各局部需求，并将其进行整合。
   • 多视点需求工程方法认为，需求之间的冲突往往是由于涉众视点不同所导致的。
   • 因此，完整、一致地发现和集成视点，是获得高质量需求的关键。
   • 多视点方法适应于涉众视角的局部性和分布性特征，反映各种涉众的需求。
5. 基于知识的方法
   • 软件开发是一个知识密集型的活动，知识在其中起到关键的作用。
   • 基于知识的方法的出发点，是希望利用历史项目中，积累的经验或领域分析的结果，来帮助人们理解和获取需求。
   • 事实上，大多数的需求获取方法，都或多或少地用到这一类方法。
6. 面向方面的方法
   • 面向方面的软件开发：是使横切关注点更好地分离的一种技术。
   • 在面向方面的编程中，对于“横切”给出这样的定义：如果被构建的两个属性，必须以不同的方式构造，但它们之间又需要被协同，那么它们彼此横切。
   • 把问题分解为更小的部分，称为关注点分离。
   • 通过对关注点的分离，有助于从不同角度对软件系统进行理解、维护和扩展。
   • 面向方面的方法：在近年来被提出，并受到了研究者的重视。
   • 通常将功能需求作为一组基础，而将非功能需求作为方面级的需求。
   • 面向方面的方法：从编程方法发展而来，它的基本思想和多视角的方法有相似之处，目前，较为成功的应用主要集中在需求的实现。
   • 由于需求之间的关系往往错综复杂，因此，对横切需求的识别仍然是一个难题。

Summary

需求获取阶段的任务：

—— 就是获取用户的需求信息。通过用户与需求分析员之间进行高度的合作和交流才能成功。

需求开发计划：

—— 需求开发计划的任务：是确定需求开发的实施步骤，给出收集需求活动的具体安排和进度。

项目的目标和范围

—— 项目的目标主要包括： 项目开发的目的和意义，以及软件系统应实现的业务需求。

—— 项目的范围： 是指软件系统具体应包括和不应包括的部分，以及软件系统所涉及的各个方面。

需求调研对象：主要是：用户

根据用户的某些方面将用户分类：

根据用户所在的部门和职责分类。

—— 如：计划部门、销售部门、财务部门等。

根据用户使用系统的频繁度和优先级等分类。

根据用户掌握的计算机知识和使用计算机的熟练程度分类。

根据直接使用和非直接使用软件系统的情况分类。

确定需求来源

典型的软件需求来源有以下几方面：

1）直接和间接使用软件系统的用户。

2）系统需求规格说明。

3）市场调研和用户问卷调查。

4）已开发出的和待开发的同类软件系统的描述和文档。

5）人工系统中存在的问题报告。

6）观察正在工作的用户。

7）用户工作内容的分析。

需求调研的三个步骤：

1）向掌握“全局”的负责人调研

2）向部门负责人调研

3）向业务人员调研

明确需求信息的决策者

决策者能根据具体情况，对存在问题需求信息做出决定。

决策者并不是固定不变的，而是根据实际中可能发生的具体问题来确定。

需求信息收集面临的困难

需求信息收集并不是件容易的工作，需求分析员要与用户进行充分的交流，听取用户对软件系统的看法和意见。

但在与用户交流的过程中并非是十分顺利的，特别是需要用户花费时间来讲解他们的业务流程和工作内容。

需求信息收集的方式。

1）座谈会的方式

2）书面咨询的方式

3）利用用例表示方法

需求信息的类型有9种。

1.业务需求

2.用例说明

3.业务规则

4.功能需求

5.性能需求

6.外部接口需求

7.约束

8.数据定义

9.解决方案

需求收集中应注意的一些问题：

1）应能适当地调整收集范围。

2）尽量把用户所做的假设解释清楚，特别是发生冲突的部分。这就需要根据用户的信息去理解，以明确用户没有表达清楚的需求。

3）尽量理解用户的思维过程，特别是尽量熟悉和掌握用户具有的一些专业知识和术语。

4）在收集需求信息时，应尽量避免受不熟悉细节的影响。

5）应尽量避免讨论一些具体的解决方案，因为需求阶段的工作，是要弄清楚软件系统做什么，而不是怎么做。

6）需求收集工作的结束。

非功能需求：

非功能需求：是衡量软件能否良好运行的定性指标。

如：可靠性、可扩展性、安全性、互操作性、易使用性、可维护性、用户界面友好等。

收集非功能需求使用的3种方法：

将重要非功能需求进行综合，并根据其中的每个需求设计出许多方法，根据用户的回答，使这些需求更明确。

方法2：需求分析员与用户一起对每一个非功能需求，制定可测试和可验证的具体标准。

方法3：设计与非功能需求相冲突的假设示例，利用反例来提示用户。

需求获取方法：有5种

1. 面向目标的方法
2. 基于场景的方法
3. 面向视点的方法
4. 基于知识的方法
5. 面向方面的方法

第5章 需求分析

需求分析的任务

通过需求获取阶段的工作，软件开发人员从用户处收集到大量的需求信息。

这些需求信息并不完全都是真正的需求。

需求分析的基本任务：就是分析和综合已收集到的需求信息。

分析：在于透过现象看本质，找出这些需求信息间的内在联系和可能的矛盾。

综合：就是去掉那些非本质的信息，找出解决矛盾的方法，并建立系统的逻辑模型。

具体地说，需求分析的基本任务：就是提炼、分析和仔细审查已收集到的需求信息，找出真正的和具体的需求，以确保所有项目相关人员都明白其含义。

在分析过程中，通过建立软件系统的逻辑模型，发现或找出需求信息中存在的冲突、遗漏、错误或含糊问题等。

需求分析阶段工作结果：是获得高质量的具体软件需求。

需求分析的具体工作包括：

• 建立系统关联图；
• 分析需求的可行性；
• 构建用户分析原型；
• 确定需求的优先级；
• 需求建模；
• 建立数据词典。
• 对于较为简单的系统，确定需求优先级等工作可以考虑不施行。

系统关联图的建立

在需求获取阶段，首先确定收集需求信息的范围，提高需求获取效率，把项目相关人员定位到一个共同的、明确的方向上。

建立系统关联图：主要是根据需求获取阶段确定的系统范围，用图形表示系统与外部实体间的关联。

关联图：就是用于描述系统与外部实体间的界限和接口的模型，而且明确通过接口的信息流和物质流

关联图的建立：

• 把整个要开发的系统表示为一个椭圆，椭圆内标识系统的名字。
• 用箭头表示系统与外部实体间的关系和信息流向。
• 用矩形框表示系统外部实体。

关联图：不明确描述系统的内部过程和数据。

EG

某培训中心的主要工作是为本行业在职人员提供课程培训服务。有兴趣的本行业职工可以通过电子邮件、信函等报名、选修或注销课程，或询问课程计划等。培训中心收取一定的培训费用，学费可以用现金或支票形式支付。

该系统应具有记录和分类由电子邮件或信函表达的信息，处理报名、询问、注销和付款，以及输出回答信息的功能。

该系统外的实体主要是学员和系统的操作员等。

系统的关联图，如图所示。

建立关联图的目的：是项目相关人员一开始不必去考虑太多的细节，而是把注意力集中在软件系统的接口方面。

• 即系统的输入/输出上，从而确定系统的界限，并为分折用户需求提供很好的依据，特别是在功能需求方面。

关联图：以图形方式表示系统的范围，使得项目相关人员更易于理解和审查。

如果某些需求不可实施，例如：开发环境的支持，或技术实现有困难，或处理效率较低等，都应尽早与用户讨论和协商。

分析需求可行性的基本任务：是在允许的成本和性能要求以及系统的范围内，分析每项需求得以实施的可能性。

分析需求可行性的目的：在于明确与每项需求相关联的风险，包括：一些与其它方面的冲突、对外部环境的依赖和某些技术的障碍等。

分析需求可行性：是一项困难的工作，不存在对所有类型的需求都适用的分析方法。

分析需求可行性：需要与有经验的开发人员共同分析。

对于要开发的软件系统，由于涉及不可知因素，进行需求可行性分析，有助于避免后期开发过程中的一些问题。

与高风险相关的需求，最有可能导致软件开发工作的失败。

考虑的风险类型

1. 性能风险：实现这项需求，可能导致整个系统性能的下降。
2. 安全风险：实现这项需求，可能导致无法满足整个系统的安全需求。
3. 过程风险：实现这项需求，可能导致需要对常规的开发过程做修改。
4. 实现技术风险：实现这项需求，可能需要使用不熟悉的实现技术。
5. 数据库风险：实现这项需求，可能导致系统不支持的非标准数据。
6. 日程风险：实现这项需求，可能遇到技术困难，并危及系统原定的开发日程。
7. 外部接口风险：实现这项需求，可能涉及外部接口。
8. 稳定风险：这项需求可能是易变的，将导致开发过程的重大变动。

在实际工作中，通常使用定性的方法。

如：分类为：

• “高”
• “中”
• “低”

建立用户分析原型

在需求建模前，需要澄清一些不能确定的或含糊的需求，尽早使这些需求能完整和清楚地表达出来。

创建用户分析原型的基本任务：是对于软件开发人员或用户不能明确化的需求，通过建立相应的用户分析原型，然后，评估该原型，使得项目相关人员能更好理解所要解决的问题。

用户分析原型：是指一个可能的局部实现，而不是整个系统，这样可使许多概念和可能发生的事更为直观明了。

需求优先级分析

划分需求优先级可以帮助项目相关人员判断系统的核心需求，并有助于项目相关人员集中于重点问题的交流和协商，特别是涉及需求风险分析的时候。

需求优先级之间的关联，可以帮助软件开发人员决定软件体系结构，还可以帮助解决可能发生的设计冲突。

软件开发人员可以根据需求优先级，权衡合理的项目范围和进度安排、预算、人力资源以及质量目标的要求。

实现权衡的方法是，当接受一个新的高优先级的需求或者项目发生环境变化时，删除低优先级的需求，或者将其推迟到下一版本去实现。

在需求获取的理想情况下，开发人员应在客户表达需求时，由用户决定需求的重要性，标上需求的优先级。

如果单独让用户来决定需求的优先级是很难做到的，在众多具有不同期望的用户之间，达到一致意见就更难了。

优先级的分配，应当由软件开发人员和项目相关人员共同完成，最好是在做了一些初始的分析工作后，再进行需求优先级的分配。

在很多情况下，对同一需求，不同的项目相关人员会分配不同的优先级。

这可能反映了实际的需要，也可能只是简单地反映了不同项目相关人员各自的理解。

因此，必须消除这些差异，并在分配的每一类优先级的含义上达成一致意见。

需求建模

需求建模：就是导出目标系统的逻辑模型或需求模型，以明确目标系统“做什么”的问题。

目标系统：是指待开发的软件系统。

在已知需求的可行性以及各个需求明确以后，为了更好地理解需求，特别是复杂系统的需求，软件开发人员应从不同的角度，抽象出目标系统的特性，

使用精确的方法构造系统的模型，验证模型是否满足用户的需求，并在设计过程中，逐渐把与实现相关的细节加进模型，直至最终用程序实现模型。

模型，就是为了理解事物而对事物作出的一种抽象，是对事物的一种无歧义的书面描述。

模型：可由文本、图形符号或数学符号以及组织这些符号的规则组成。

需求建模，就是把由文本表示的需求和由图形或数学符号表示的需求结合起来，绘制出对目标系统的完整性描述，以检测软件需求的一致性、完整性和错误等。

利用图形表示需求，有助于增强项目相关人员对需求的理解，对于某些类型的信息。

图形表示方式可以使项目相关人员之间减轻语言和词汇方面的负担。

建立需求模型的目的：是为了增强对用自然语言描述的需求规格说明的理解，而不是替换它。

在需求建模中，使用什么方法取决于建模的目的、时间和应用领域等。

常见的需求分析方法有

1. 结构化分析方法（Structured Analysis, SA）
2. 面向对象方法
3. 面向问题域的分析方法
4. 面向特征的需求分析方法
5. 基于本体的需求分析方法
6. 面向多视点的需求分析方法

数据词典

定义：

目标系统中使用的所有数据元素和结构的含义、类型、数量值、精度及允许取值范围的共享数据仓库。

作用：

是确保软件开发人员使用统一的数据定义，可提高需求分析、设计、实现和维护过程中的可跟踪性。

为避免冗余和不一致性，每个项目建立一个独立的数据词典，而不是在每个需求出现的地方定义每个数据项。

数据词典：把不同的需求文档和需求模型紧密地结合到一起。

数据词典中的每个数据项对应一项记录，并根据实际情况使用简单的符合予以定义

Summary:

1）需求分析的任务：

就是分析和综合已收集到的需求信息。

分析：在于透过现象看本质，找出这些需求信息间的内在联系和可能的矛盾。

综合：就是去掉那些非本质的信息，找出解决矛盾的方法，并建立系统的逻辑模型。

（2）关联图：

就是用于描述系统与外部实体间的界限和接口的模型，而且明确通过接口的信息流和物质流。

（1）分析需求可行性的基本任务：

是在允许的成本和性能要求以及系统的范围内，分析每项需求得以实施的可能性。

（2）这项工作的目的：

在于明确与每项需求相关联的风险，包括：一些与其它方面的冲突、对外部环境的依赖和某些技术的障碍等。

（3）在需求分析中应考虑的风险类型：

性能风险、安全风险、过程风险、实现技术风险、

数据库风险、日程风险、外部接口风险、稳定风险

（1）用户分析原型：

用户分析原型：是指一个可能的局部实现，而不是整个系统，这样可使许多概念和可能发生的事更为直观明了。

（2）划分需求优先级

可以帮助项目相关人员判断系统的核心需求，并有助于项目相关人员集中于重点问题的交流和协商。

（3）需求建模

就是导出目标系统的逻辑模型或需求模型，以明确目标系统“做什么”的问题。

（4）数据词典

是定义目标系统中使用的所有数据元素和结构的含义、类型、数量值、精度及允许取值范围的共享数据仓库。

第6章 需求建模方法与技术

需求建模：是根据待开发软件系统的需求，利用某种建模方法建立该系统的逻辑模型。

也称为：需求模型或分析模型。

帮助软件开发人员检测软件需求的一致性、完全性、二义性和错误等。

在软件的实际开发中，为了表达和描述软件需求，软件开发人员使用不同的建模方法，来建立软件需求模型。

这些建模方法的作用、范围和特点不同，因此，在使用中是有所区别的。

需求建模方法具备的共同特点：

1）提供描述手段

开发一个软件系统涉及许多人，开发人员之间如何有效地进行交流是项目成功的关键之一。

在开发过程中，每个开发人员都必须将工作的结果以一定的形式记录下来，采用什么样的描述形式，对人员间的交流和继续进行下一步工作是非常重要的。

需求建模方法应该规定描述模型的手段，这包括要记录什么内容以及用什么符号来表达等。

2）提供基本步骤

开发一个软件系统，特别是大型复杂系统，要考虑的问题很多，如果同时处理这些问题，就会束手无策或者造成混乱。

正确解决问题的方法是，将问题按先后次序进行分解，每一步集中精力解决某个问题，直至所有问题被解决为止。

因此，需求建模方法需要规定基本实施步骤，确定每一步的目的，要产生什么样的结果，每步中要注意哪些概念，以及完成该步的工作需要掌握哪些必要的信息等。

在需求建模方法中，主要使用的描述手段和技术是：自然语言、图形符号语言和形式语言等。

常见的软件需求模型包括:

数据流图（DFD）

实体关系图（ERD）

状态转换图（STD）

用例图

类图

活动图

时序图

事件-响应表

词语类型	示 例	分析模型的组件
名词	人员、组织机构、软件系统、数据元素、已经存在的对象	·外部实体、数据库或者数据流（数据流图，DFD） ·参与者（用例图） ·实体或者实体属性（实体-关系图，ERD） ·通道（时序图） ·带状态的对象（状态转换，STD）
动词	行为、用户或者系统所做的事情、能够发生的事件	·处理（数据流图，DFD） ·处理步骤（时序图） ·用例（用例图） ·关系（实体-关系图，ERD） ·转换（状态转换图，STD） ·活动（活动图） ·事件（事件-响应表）
条件	条件逻辑的陈述，如if/then	·判定条件（决策树、决策表或者活动图） ·分支（时序图或者活动图）

数据流图

（Data Flow Diagram ,简称：DFD）

数据流图：用于标识一个系统中的加工处理、系统所操作的数据集合或者物理介质以及在处理、存储和系统外部之间的数据流。

数据流图：指明系统中数据是如何流动和变换的，以及描述使数据流进行变换的功能。

数据流图：是用来描绘软件系统逻辑模型的图形工具，它描绘信息和数据从输入到输出过程中，所经历的一系列变换。

数据流图：一般在软件生命周期的早期阶段开始进行分析，在软件生命周期后续阶段不断改进、完善和细化。

数据流图：非常适用于事务处理系统和其他偏重功能性的应用系统。

数据流图的绘制

一般情况下，应该遵守“由外向里”的原则。

即先确定系统的边界或范围，再考虑系统的内部，先画数据处理的输入和输出，再画数据处理内部。

也就是：

先全局，后局部；

先整体，后细节；

先抽象，后具体。

在图书预订系统中，书店向顾客发放订单，顾客将所填订单交由系统处理，系统首先依据图书目录对订单进行检查，并对合格订单进行处理，处理过程中，根据顾客情况和订单数目，将订单分为：优先订单与正常订单两种，随时处理优先订单，定期处理正常订单。最后，系统根据所处理的订单，进行汇总，并按出版社要求发给出版社。

第1步，画出顶层数据流图。

第2步，逐层分解加工，绘制1层数据流图。

第3步，绘制2层数据流图。

实体-关系图

（Entity Relation Diagram，简称为：E-R图）

实体-关系图的组成元素

实体-关系图：主要包含：实体、关系和属性，它创建了软件的数据模型。

实体：是现实世界中客观存在的，而且，可以相互区别的事物或活动的抽象。如：人、汽车、商品、职工等；

属性：是描述实体或关系中的一种特征。

一个实体或关系通常具有多个特征，需要多个相应属性来描述。如：学生的属性，包括：学号、姓名、性别、年龄等。

绘制实体-关系图：

用矩形表示实体，在框内写上实体名；

用椭圆形表示实体的属性，并用无向边把实体和属性连接起来；

用菱形表示实体间的关系，在菱形框内写上关系名，用无向边分别把菱形框与有关实体连接起来，在无向边旁注明关系的类型。

实体-关系图（Entity Relation Diagram，简称为：E-R图）

“学生实体和班级实体”的实体-关系图。

状态转换图

（Status Transfer Diagram，简称为：STD）

状态转换图：是用于指明系统在外部事件作用下，将会如何动作，表明了系统的各种状态，以及各种状态间的转换。

状态转换图：还指明了作为特定事件的结果，系统将做哪些动作。

状态转换图的组成元素

状态转换图：由状态、事件和转换组成。

• 状态：是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。
  • 状态主要有：初态（即：开始状态），终态（即：最终状态）和中间状态。
    • 初态：用实心圆表示。
    • 终态：用一对同心圆（内圆为实心圆）表示。
    • 中间状态：用圆角矩形表示，可以用两条水平横线，把它分成上、中、下3个部分。上面部分为状态的名称，这部分是必须有的；中间部分为状态变量的名字和值，这部分是可选的；下面部分是活动表，这部分也是可选的。
• 事件：是在某个特定时刻发生的事情，它是对引起系统做动作或从一个状态转换到另一个状态的外界事件的抽象。
  • 事件：就是引起系统做动作或转换状态的控制信息。
    • 是用箭头上的标记表示，它是引起转换的消息。
• 转换：表示状态从一种状态变为另一种状态
  • 用两个状态之间带箭头的连线来表示，箭头指明了转换方向。

例题：“复印机控制软件”的状态转换图。状态：闲置状态、复印状态、缺纸状态、卡纸状态。事件：复印命令、完成复印命令、发现没纸、装满纸、发生卡纸故障、故障排除。

用例图

用例图：是用来描述系统外部执行者与其交互用例之间的关系。

用例是系统开发者和用户反复讨论的结果，描述了开发者和用户对需求规格说明所达成的共识。

用例描述了对目标系统的功能需求，并把系统看作黑盒子，从外部行为者的角度来理解系统。

用例驱动了需求分析之后各阶段的开发工作，从而影响到开发过程的各个阶段。

用例图是进行需求分析和建立系统功能模型的强有力工具。

用例图的主要元素是：系统、用例、行为者以及用例之间的关系。

例如，自动售货机系统的用例图。

自动售货机系统的用例图。

类图

类是：对一组对象的描述，这些对象具有相似的属性、操作、关系和行为。

类图：描述类及类与类之间的静态关系。

类图：不仅定义软件系统中的类，描述类与类之间的关系，它还表示类的内部结构（即：类的属性和操作）。

一个类可以出现在多个类图中，一个系统可以由多个类图来描述。

类图的表示符号

类图的符号是一个长方形，用两条横线把长方形分为上、中、下三个区域。这三个区域分别放类的名字、属性和操作。

classDiagram
    class 动物
    动物 : String 标签
    动物 : 吃()

classDiagram
  class 银行账户
  银行账户 : +String 户主
  银行账户 : +BigDecimal 余额
  银行账户 : +存(数量)
  银行账户 : +取(数量)

活动图

活动图，用来描述用例中交错的各种流或者执行某个动作的执行者角色或者业务处理中的流程。

活动图：主要描述动作及动作的结果对象状态改变。

无须指明任何事件，只要源状态中的动作被执行了，活动图中的状态（称为动作状态）就自动开始转换。

活动图：描述交互的方式，它描述采取何种动作，动作的结果是什么（即：动作状态改变），何时发生，以及在何处发生。

时序图

时序图：描述对象之间的动态交互关系，着重表现对象之间消息传递的时间顺序。

时序图有2个坐标轴：纵坐标表示时间、横坐标表示不同的对象。

注意：时序图通常有多个对象，体现对象间的时间顺序。

时序图中的对象：用一个矩形框表示，框内标有对象名，从表示对象的矩形框，向下的垂直虚线是对象的“生命线”，用于表示在某段时间内该对象的存在。

对象间的通信通过对象生命线之间的水平消息线来表示，消息箭头的形状表明消息的类型（有：同步、异步或简单）。

当收到消息时，接收对象立即开始执行活动。

即对象被激活

激活用对象生命线上的细长矩形框表示。

消息：通常用消息名和参数表来标识。

消息可以带有条件表达式，用于表示分支或决定是否发送消息。

如果用条件表达式表示分支，则会有若干个互斥的箭头，也就是说，在某一时刻仅可发送分支中的一个消息。

浏览时序图的方法是：

从上到下（即：按时间顺序）查看对象间交换的消息。

如图所示为时序图示例。

决策表

决策表：是分析和表达多逻辑条件下，执行不同操作情况的工具。

决策表：分为四个部分

左上部列出所有条件

左下部是所有可能做的动作

右上部是表示各种条件组合的一个矩阵

右下部是和每种条件组合相对应的动作。

决策表通常有四个部分组成：

① 条件桩（Condition Stub）：列出了问题的所有条件。通常认为列出的条件的次序无关紧要。

② 动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

③ 条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。

④ 动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

行李费算法的决策表。

条件项：国内乘客、头等舱、残疾乘客、行李重量

动作项：列出了不同行李重量可能采取的操作

右侧上部和下部：各种条件组合和每种条件组合相对应的动作。

决策表的建立步骤：

① 确定规则的个数，假如有n个条件，每个条件有两个取值（0，1）,故有2的n次方种规则。

② 列出所有的条件桩和动作桩。

③ 填入条件项。

④ 填入动作项。得到初始决策表。

⑤ 简化、合并相似规则（相同动作）。

决策表的优点：

1）能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用决策表能够设计出完整的测试用例集合。

2）在一些数据处理问题中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。决策表很适合于处理这类问题。

决策树

决策树的概念

决策树：适合描述问题处理中具有多个判断，而且每个决策与若干条件有关。

决策树：是决策表的变种，也能清晰地表示复杂的条件组合与应做的动作之间的对应关系。

决策树的形式简单到不需任何说明，一眼就可以看出其含义，因此，易于掌握和使用。

行李费算法的决策树

决策树的优点

优点：在控制层级的基础上，构造简单，表示方法直观，易于理解。

小结

描述的每一个需求建模方法都有其优点和不足。

没有哪一个图形化模型能够充分描述系统的每个方面。

这些模型提供的描述也有重叠，所以我们也没有必要为项目创建所有的视图。

比如，如果创建了实体关系图和数据字典，很可能就没有必要再创建类图。

Summary

需求建模方法具备的共同特点：

1）提供描述手段

2）提供基本步骤

常见的软件需求模型包括：

数据流图（DFD）

实体关系图（ERD）

状态转换图（STD）

用例图

类图

活动图

时序图

事件-响应表

数据流图：

数据流图：用于标识一个系统中的加工处理、系统所操作的数据集合或者物理介质以及在处理、存储和系统外部之间的数据流。

数据流图由四种基本符号组成：

“箭头”表示：数据流，

“圆角矩形”表示：数据处理或加工

“双线”表示：数据存储

“矩形框”表示：外部实体

实体-关系图：

实体-关系图，包含：实体、关系和属性。

实体：是现实世界中客观存在的，而且，可以相互区别的事物或活动的抽象。

属性：是描述实体或关系中的一种特征。一个实体或关系通常具有多个特征，需要多个相应属性来描述。

关系：现实世界中事物内部以及事物之间的联系，在软件系统中反映为实体内部的关系和实体之间的关系。

实体之间的关系有三类：一对一关系（1:1）、一对多关系（1:n）和 多对多关系（m:n）

用例图：是用来描述系统外部执行者与其交互用例之间的关系。

（2）类是：对一组对象的描述，这些对象具有相似的属性、操作、关系和行为。

（3）活动图，用来描述用例中交错的各种流或者执行某个动作的执行者角色或者业务处理中的流程。

（4）时序图：描述对象之间的动态交互关系，着重表现对象之间消息传递的时间顺序。

决策表：

决策表：是分析和表达多逻辑条件下执行不同操作的情况的工具。

决策表：分为四个部分，其左上部列出所有条件，左下部是所有可能做的动作，右上部是表示各种条件组合的一个矩阵，右下部是和每种条件组合相对应的动作。

决策树：

决策树：适合描述问题处理中具有多个判断，而且每个决策与若干条件有关。

决策树：是决策表的变种，也能清晰地表示复杂的条件组合与应做的动作之间的对应关系。

第7章 需求文档

需求文档在需求工程中的位置

软件文档：是软件产品的重要组成部分，对于开发人员、项目管理人员以及软件用户都是十分重要的辅助工具。

软件文档定义清晰、维护及时，能够帮助开发人员理解需求、顺畅沟通，帮助项目管理人员了解进度、加强管理，帮助软件用户更好地使用和维护软件。

常用的软件文档主要包括：可行性研究报告、项目开发计划、需求文档、概要设计文档、详细设计文档、测试文档、项目开发总结报告、用户手册和操作手册等。

需求文档：是其中最重要的软件文档之一。

需求文档：使得开发人员、项目管理人员和软件用户对软件的初始规定达成共识，并使之成为整个开发工作的基础。

需求工程是一个不断反复的需求定义、需求分析、文档记录、需求演进的过程，并最终在验证的基础上得到需求基线。

需求是软件产品的根源，需求工作的优劣对软件产品影响最大。

就像一条河流，如果源头被污染了，那么整条河流也就被污染了。

需求文档与需求工程中各阶段的关系

如图所示

• 需求获取：当我们和客户合作时，我们会问一些问题，取得他们所提供的信息。

• 需求分析：分析获取的信息以理解它们，并把它们分成不同的类别，同时把客户需求同可能的软件需求联系起来。

• 需求文档：即，软件需求规格说明。

• 需求验证：可以让客户代表评审软件需求规格说明，并纠正存在的错误。

• 这四个过程相互迭代，贯穿着需求开发整个阶段。

需求文档：

• 是在整个需求开发过程中逐步完成，并完善。

• 经过评审后的需求文档，是经过迭代式的需求开发工作后最终形成的成果。

• 是需求管理的主要对象，也是设计文档、开发文档、测试文档等编写的重要依据。

需求文档的作用有以下几方面：

1. 规范的文档可以拓展人脑的知识记忆能力。

   人脑的记忆力总是有限的，获取的信息会随着时间慢慢消退。

   大量临时记录的文档，如果不及时进行整理，在下次阅读时很难再回忆起当时要表达的知识，容易造成歧义。

   规范的文档可以解决这些问题。

2. 编制需求文档的过程，是需求分析员更理解问题的过程，使文档表达的知识更准确、更清晰。

3. 定义清晰、正确、规范的需求文档为开发人员、项目管理人员和软件用户提供相对稳定的可阅读资料。

4. 通过编制需求文档，可以尽早发现需求错误，提高项目开发效率。

   错误在整个项目开发过程中有放大效应，因此，编制需求文档的过程，也是进一步明确和完善系统需求的过程。

   通过减少需求错误从而尽可能地降低项目返工成本，保证项目按期完成。

5. 需求文档能够促进软件开发过程的规范化，也为开发团队建立了经验模型和可复用知识库。

   如果需求分析员在项目未完成时离开了开发团队，通过需求文档记录了他们的工作，智力资产不会被带走。

   如果有新员工加人项目开发团队，也可以通过阅读文档，尽快地融人团队中。

   如果要进行项目二次开发，或者有类似的项目，则通过文档获得可复用知识模型，可以加快项目开发进度。

6. 需求文档可以作为项目开发方和软件客户之间的有关软件系统的协议基准，可以使用它作为合同协议的重要组成部分。使开发方和软件客户对系统目标达成一致。

7. 需求文档可以作为软件成本估算和项目开发进度安排的重要依据，从而使整个项目开发计划的制订更为合理。

对待需求文档的两种不同观点：

一种观点，是过分强调文档，一味追求文档的厚度、完整性，甚至花很长时间去美化文档，不断更新一些不重要的文档细节，从而导致花费大量时间编制和维护文档，反而降低了软件开发效率。

另一种观点，则是完全不重视文档，认为文档的编写只是一个形式化的过程，为节约时间，根本不重视文档的书写风格和表达方式，在实际开发过程中也基本不使用文档，这种观点将导致文档的作用得不到体现，和没有使用文档的开发，效果相差无几。

科学的态度应该是：

• 充分重视文档的实效，而非形式，不要过于强调“文档量”。

• 而要注重文档内容和文档中文字、图表的表达，使文档能够准确、简洁、清晰的表达系统需求信息。

• 使文档能够被项目管理人员、开发人员和软件客户共同接受。

在编写需求文档时，应遵循如下的基本原则：

（1）在可能的情况下，需求文档应该由软件开发方和软件客户联合起草。

由于用户通常对软件设计和开发过程了解较少，

软件开发方通常对客户从事的领域了解较少，对于客户的问题和意图也不甚清楚。

（2）需求文档编写应适应文档的读者。

需求文档的读者主要是项目管理人员、开发人员和软件客户，其中开发人员主要包括系统设计人员、程序员、测试人员、文档编写人员。

只有充分了解读者对文档的需求，才能编写出一份好的技术性文档。

（3）需求文档的表达方式依赖于内容。

需求文档的表达方式可以划分为：自然语言、图形化模型和形式化规格描述3种。

在大多数情况下中，仍然采用自然语言表达为主，图形化模型表达为辅的文档表达方式，在少量对描述精确性要求很高的文档中，采用形式化描述方式。

（4）需求文档编写应有必要的重复，并不断完善。

为了保证读者能够正确理解文档内容，或提醒用户关注重点内容，在文档中应有必要的重复，但要注意不是简单的重复，而是不断的完善。

（5）需求文档编写应具有一定的灵活性。

主要表现如下。

1）文档的详细程度应具有一定的灵活性。

基于相同模版的需求文档，可能只有几页，也可能是上百页。

详细程度取决于任务的规模、复杂性和项目管理人员对软件开发过程及运行环境所需要的详细程度的判断。

2）文档可以扩展与合并，文档中所有的章节都可以进一步细分或缩并，以适应实际需要。

3）文档应能够对需求变更进行有效的管理和控制。

用户需求的变化、市场需求的变化、系统变化、工作环境的变化，以及由于对原有需求的误解或需求分析不充分而存在的需求Bug都有可能导致需求变更。

因此，文档应能够灵活地处理需求变更。

（6）采用原型法，渐进式开发需求文档。

人们总是希望一开始就能将整个软件系统的需求确定下来，但在实际项目中却很难达到这一目标。

为降低需求风险，提高软件开发效率，可以采用原型法，渐进式编写需求文档。

常用的编写需求文档的方法有：

自然语言

图形化模型

形式化规格描述

常用的编写需求文档的方法有：

1. 自然语言

   自然语言：是使用结构合理的自然语言来表述需求。

   自然语言：不管对于写的人还是看的人，都是一个很容易接受的方法，一直以来这都是描述需求的首选方法。

   自然语言优点：易于编写、易于阅读，不要求掌握特定的技能。

   自然语言缺点：不够严谨，歧义性强，表述力差，对于复杂问题的描述就更为明显，往往需要很大的篇幅来解释。

   因此，需要尽可能采用结构化文本来组织。

2. 图形化模型 —— “一图抵千言”

   图形化模型：在表述时能够给读者提供更强的视觉效果，同时能够使问题更加聚焦。

   图形化模型：在日常的交流中，经常会在纸上绘制一些非标的示意图，以更好地完成沟通。

   图形化模型优点：就是前面提到的可视性、聚焦性。

   图形化模型缺点：要求编写和阅读的人都能够正确地理解模型，而且并不是所有的信息都是可以用模型表示的。

   因此，对于一个软件需求文档而言，是不可能只有图形化模型、没有任何文字表述的。

3. 形式化方法描述

   形式化方法描述：比图形化模型更高一些。对于逻辑性很强、精度要求很高的场合，形式化方法描述就是一种不错的选择。

   形式化方法描述优点：是严谨、精确。

   形式化方法描述：缺点：是编写和阅读的人都会感到很困难，容易产生理解歧义。

4. 需求文档编写方法的选择：

   1）以自然语言为主，而以图形化模型为辅，需要的地方少量使用形式化方法描述。

   这是现在最常见的组合形式，对于绝大多数信息系统、软件产品而言都是十分适合的方法。

   2）以图形化模型为主，而以自然语言作为补充，需要的地方少量使用形式化方法描述。

   3）以形式化规格语言为主，而以图形化模型为辅，并以自然语言为补充。

   适用于质量要求很高的领域，例如：航天、军工中的一些重要软件系统。

软件需求规格说明，也称为：功能规格说明、需求协议及系统规格说明。

软件需求规格说明：精确地阐述一个软件系统必须提供的功能、性能及它所要求考虑的限制条件。

软件需求规格说明：不仅是系统测试和用户手册的编写基础，也是各子系统计划、设计、编码的基础。

软件需求规格说明：应尽可能完整地描述系统预期的外部行为和用户可视化行为。

编写需求规格说明步骤：

1）整理所有已经通过审核的各阶段工作文档，这些文档虽然是阶段性的，但一定是经过审核准确的，对于每一个审核的局部文档都要给出版本号。

2）制订一个结构完成的需求规格说明模板，并给需求规格说明模板一个版本号，同时要制订一个需求规格说明的编写规范。

3）按照需求规格说明模板和编写规范依据整理的各阶段文档成果进行编写，编写时一定要注意前后一致性原则。

4）软件需求规格说明书编写成员进行自检和互检，最终形成一个提交需求验证的软件需求规格说明文档。

常用的标识方法有以下几种：

1）序列号法

序列号法：是一种最简单的方法，就是给每个需求一个唯一的序列号，如UR-1 , SRS13 , FR-1等。

当一个新的需求进来时，再依序给它分配一个序列号，序列号的前缀代表需求类型，

由于序号不能重用，当有一个需求被纳人进来时，其原先占有的序列号并不能释放出来，容易造成序列号断号。

序列号法：不能提供任何相关需求在逻辑上或层次上的区别，而且标识中不含有与需求内容相关的信息。

2）层次化编码

层次化编码：是一种常用的方法。如：软件需求规格说明中的4.1，下一层标识号是4.1.1等。

层次化编码中的数字越多，则表示需求越详细，号数越多的说明它是最底层的需求。

层次化编码：简单且紧凑，利用文档工具可以实现层次号的自动变更，它很方便地显示了一个需求的层次构成。

层次化编码： 不含需求的内容信息，而且如果有其他地方引用，当变动时引用部分要做相应的修改。

3）层次化文本标签

层次化的文本标签是结构化的、具有语义上的含义。

层次化文本标签：不受增加和减少或移动的影响。

层次化文本标签：但要定义好层次化文本标签要比层次化数字标识难得多。

处理不完整性

在编写需求规格说明时，一定会遇到缺少特定的需求信息，或认为原有过程化需求文档有不正确的地方，则使用一种TBD ，即待确定的标记来标识这些不确定的需求。

并将TBD的地方记录在一个TBD问题列表中，该列表有TBD编号、问题内容、责任人、解决时间、解决状态，这个表将有助于跟踪这个文档的编写。

TBD问题列表将作为需求规格说明文档的附录。

要把最终的软件需求规格说明移交给软件开发组时，必须解决所有的TBD问题。

软件需求规格说明模板

1.引言

引言：提供了一个概述，帮助于读者理解软件需求规格说明的组织方式和使用方式。

引言：主要包括：目标、文档约定、读者对象和阅读建议、项目范围及参考文献。

1.1 目标

在文档中说明软件或应用程序的需求，包括：修订或者发行版本号。

如果该软件需求规格说明只与整个系统的一部分有关系，那么，就只需确定这一部分或子系统。

1.2 文档约定

描述编写文档时所采用的所有标准或印刷上的约定。

包括：文本样式、强调形式或具有特殊意义的表示符号。

1.3 读者对象和阅读建议

列举软件需求规格说明面向的不同读者对象。

描述软件需求规格说明中其余部分的内容及其组织结构。

就每一类读者最合适以什么顺序来阅读该文档提出建议。

1.4 项目范围

提供对指定的软件及其作用的简短描述。

把软件与用户或公司目标相关联，把软件与业务目标和策略相关联。

如果可以得到单独的前景和范围文档，那么应该引用它，而不要直接将其内容复制到这里。

如果是说明改进产品的增量发布的软件需求规格说明，那么应该包括它自己的范围声明，作为长期战略的产品前景的一个子集。

1.5参考资料

列举编写软件需求规格说明时所参考的所有文档或其他资源。

如果可能的话，使用超文本链接。

2.总体描述

2.1 产品前景

描述产品的背景和起源。

说明该产品是否是产品系列中的下一个成员，是否是成熟系统的下一版本，是现有应用程序的升级产品还是是一个全新的产品。

2.2 产品特性

列出产品所具有的主要特性或者产品可实现的重要功能。

在此只需要提供一个总体概括即可。

2.3 用户类及其特征

确定我们能预料到的有可能使用该产品的各种用户类。

描述他们的相关特征。

2.4 运行环境

描述软件的运行环境，包括：硬件平台、操作系统和版本，以及用户、服务器和数据库的地理位置

2.5 设计和实现上的约束

描述限制开发人员进行有效选择的所有因素，以及每一种约束的基本原理。

2.6 用户文档

列出将要交付的用户文档组件以及可执行软件，可以包括用户手册、联机帮助和教程。

确定所有要求的文档交付格式、标准或工具。

2.7 假设和依赖

假设是这样一种声明，在缺少证据或不确定的情况下先相信它是真的。

如果假设不正确、不一致或被更改，那么就可能会产生问题。

有些假设将会转化为项目风险。

3.系统特性

模板是根据系统特性来组织的，它只是安排功能性需求的一种可能的方式。

其他可以选择的方式还包括按照用例、操作模式、刺激、响应、对象类或功能层次结构等。

正确的选择并不是惟一的，但我们应该选择一种使读者易于理解产品预期功能的组织方法

3.1 系统特性X

仅用简短的词语说明特性的名称，例如“3.1 拼写检查”。

对每一个系统特性都要重复 3.x.1一3.x.3 这几个部分。

3.x.1 描述优先级

提供对该特性的简短描述，并指出该特性的优先级是高、中或低

3.x.2 激励/响应序列

列出输入激励序列（如：用户操作、来自外部设备的信号或其他触发器）和系统响应序列，系统响应序列定义这一特性的行为。

这些激励与用例最初的对话步骤或者与外部系统事件相对应。

3.x.3 功能性需求

逐项列出与该特性相关的详细功能性需求。

这些是必须提交给用户的软件功能，使用户可以执行该特性的服务或者完成一个用例。

描述产品如何响应可预知的出错条件以及如何响应非法输入或操作。

唯一地标识每个功能性需求。

4.外部接口需求

这部分所提供信息是为了保证系统与用户、与外部硬件或软件元素之间的正常通信。

如果一个复杂系统有多个组成部分，则应创建一个独立的接口规范说明或者系统架构规范说明。

主要包括：用户界面、硬件接口、软件接口和通信接口。

4.1 用户界面

描述系统所需的每个用户界面的逻辑特征或屏幕模型，以便与需求的另一个视图进行交流。

而不能将用户界面的设计细节写入软件需求规格说明中。

4.2 硬件接口

描述系统中软件和硬件组件之间每一接口的特征。

这种描述可能包括支持的设备类型、软件和硬件之间的数据和控制交互以及所用的通信协议等。

4.3 软件接口

描述该产品与其他软件组件之间的连接，这些组件包括数据库、操作系统、工具、库和集成的商业组件等。

声明在软件组件之间交换消息、数据和控制项的目的。

描述外部软件组件所需的服务，以及组件间通信的本质。

确定将在软件组件之间共享的数据。

4.4 通信接口

描述产品将使用的所有通信功能的需求，包括电子邮件、Web浏览器、网络通信协议和电子表格等。

定义所有相关的消息格式。

规定通信安全或加密问题、数据传输速率和同步通信机制等。

5.其他非功能性需求

5.1 性能需求

声明各种系统操作特定的性能需求，并解释其原理以指导开发人员做出合理的设计选择。

5.2 防护性需求

这部分声明与产品使用过程中可能发生的损失、破坏或危害相关的需求。

定义必须采取的安全保护措施或动作，还有那些必须避免的可能危险的动作。

明确产品必须遵循的安全标准、策略或规则。

5.3 安全性需求

指定与安全性、完整性或保密性问题相关的所有需求，这些问题影响对产品的访问、使用以及产品所创建或使用的数据的保护。

确定产品必须遵守的所有安全或保密策略或规则。

5.4 软件质量属性

声明对用户或开发人员至关重要的其他产品质量特征。

这些特征必须是明确的、定量的和可验证的。

应该指明各种属性的相对优先级。

6.其他需求

定义在此软件需求规格说明中其他部分未出现的所有其他需求。

例如：国际化需求及法律上的需求。

如果不需要添加任何其他需求，就省略这一部分。

7.附录

附录A：术语表

定义读者需要了解的所有专门术语，以便他们能够正确地理解软件需求规格说明。

附录B：分析模型

这一部分是可选的，包括或指向相关的分析模型。

例如：数据流图、类图、状态转换图、实体-关系图等。

附录C：待确定问题的清单

这一部分列出了有待于解决的需求问题。

这一部分并不是软件需求规格说明所必需的。

Summary

需求文档：是其中最重要的软件文档之一。

需求开发，包括：

需求获取

需求分析

需求文档

需求确认

需求文档的7个作用：

（1）规范的文档可以拓展人脑的知识记忆能力。

（2）编制需求文档的过程，是需求分析员更理解问题的过程，使文档表达的知识更准确、更清晰。

（3）定义清晰、正确、规范的需求文档为开发人员、项目管理人员和软件用户提供相对稳定的可阅读资料。

（4）通过编制需求文档，可以尽早发现需求错误，提高项目开发效率。

（5）需求文档能够促进软件开发过程的规范化，也为开发团队建立了经验模型和可复用知识库。

（6）需求文档可以作为项目开发方和软件客户之间的有关软件系统的协议基准，可以使用它作为合同协议的重要组成部分。使开发方和软件客户对系统目标达成一致。

（7）需求文档可以作为软件成本估算和项目开发进度安排的重要依据，从而使整个项目开发计划的制订更为合理。

编写需求文档的6个原则：

（1）在可能的情况下，需求文档应该由软件开发方和软件客户联合起草。

（2）需求文档编写应适应文档的读者。

（3）需求文档的表达方式依赖于内容。

（4）需求文档编写应有必要的重复，并不断完善。

（5）需求文档编写应具有一定的灵活性。

（6）采用原型法，渐进式开发需求文档。

需求文档的编写方法：

自然语言

图形化模型

形式化规格描述

需求文档编写方法的选择：

1）以自然语言为主，而以图形化模型为辅，需要的地方少量使用形式化方法描述。

2）以图形化模型为主，而以自然语言作为补充，需要的地方少量使用形式化方法描述。

3）以形式化规格语言为主，而以图形化模型为辅，并以自然语言为补充。

编写需求规格说明步骤：

（1）整理所有已经通过审核的各阶段工作文档。

（2）制订一个结构完成的需求规格说明模板，并给需求规格说明模板一个版本号。

（3）按照需求规格说明模板和编写规范依据整理的各阶段文档成果进行编写。

（4）软件需求规格说明书编写成员进行自检和互检。

常用的标识方法：

（1）序列号法

（2）层次化编码

（3）层次化文本标签

处理不完整性方法：

（1）使用：TBD ，即待确定的标记来标识这些不确定的需求。

（2）将有TBD的地方记录在一个TBD问题列表中。

（3） TBD问题列表将作为需求规格说明文档的附录。

（4）要把最终的软件需求规格说明移交给软件开发组时，必须解决所有的TBD问题。

软件需求规格说明模板：

当前常用的模板是IEEE标准830-1998的模板。

模板中的主要内容：

1. 引言

2. 总体描述

3. 系统特性

4. 外部接口需求

5. 其他非功能性需求

6. 其他需求

7. 附录

第8章 软件质量属性

质量属性的概念：

系统的功能：是系统能够为用户提供帮助的第一要素。

成功的软件系统除了满足功能需求之外，还需要满足更多的要求。

系统的性能需求，包括：系统的易用性、运行速度、出错频率，以及处理异常情况的能力等。

这些特性合起来被称为：软件质量属性或质量因素

它是系统非功能需求的一部分。

质量属性：也应该和功能需求一样得到足够的重视。

在决定系统的成功或失败的因素中，有时满足非功能属性往往比满足功能需求更为重要。

质量属性：对设计的影响很大。

质量属性：在软件设计中，对任何指定的功能都会有多种可选的方案，不同的方案选择产生不同的设计结果。

不同的方案之间却有着很大的区别，差异之处即在于拥有不同的质量属性。

不同的质量属性之间互有折中，很难会出现某一个设计方案的质量属性完全优于其他方案的情况。

因此，软件设计必须根据需求的质量属性在多种方案中，选择一个最优的方案。

如果不存在事先定义好的质量属性，设计方案的选择将完全没有依据，结果就很有可能导致软件不被用户接受。

在设计开始之初，就确定质量属性非常重要，而且对越复杂的系统越为重要。

质量属性：分类两类：

（1）根据质量属性能否在运行时进行识别。

（2）根据对用户和技术人员的重要性，分为：

对用户很重要的可见的质量属性

对技术人员有意义的质量属性

后者通过使系统易于更改、纠正和验证，并易于移植到新的平台上，间接地促进用户需要的满足。

理想情况下，每一个系统总是展示所有这些属性可能的最大值。

系统总是可用的，决不会崩溃，可以立即得出始终正确的运行结果，系统也总是直观且易于使用。

必须了解哪些属性对项目的成功至关重要。

根据这些基本属性来定义用户和开发人员的目标，从而使系统的设计人员能够做出合适的选择

对用户重要的属性：

可用性（Availability）

可用性：用于衡量预定的可用时间，在这期间系统是真正可用并且是完全可操作的。

可用性：等于系统的平均无故障时间（简称：MTTF）除以平均无故障时间与故障发生后所用的故障修复时间（简称：MTTR）之和。

即：可用性 = MTTF/（MTTF+MTTR）

可用性，包括：可靠性、可维护性和完整性。

有效性（Efficiency）

有效性：用来衡量系统在利用处理器的处理能力、磁盘空间、内存或通信带宽等方面的表现如何。

有效性与性能相关，性能是另一类非功能性需求。

如果系统消耗了太多可用的资源，那么用户遇到的将是性能的下降，这是缺乏有效性的一个表现。

灵活性（Flexibility）

灵活性，也称为：可扩充性、可扩展性。

灵活性：用来测量向系统中添加新功能的容易程度。

如果开发人员预料到要对系统进行扩展，那么他们可以选择使软件灵活性最高的设计方案。

灵活性：对以增量或迭代方式开发的系统是必不可少的，这些系统是通过一系列连续的发布版本或演化式原型而开发的。

完整性（Integrity）

完整性：主要处理防止非法访问系统功能、防止数据丢失、保护软件免受病毒入侵以及保护输入到系统的数据的保密性和安全性等问题。

完整性需求不能容忍任何错误，陈述完整性需求时应使用含义明确的术语。

如：用户身份验证、用户特权级别、访问限制或者需要保护的精确数据。

互操作性（Interoperability）

互操作性：表明了系统与其他系统交换数据和服务的难易程度。

为了评估互操作性，必须了解清楚用户使用其他哪些应用程序与本系统协同工作，还要了解清楚用户期望交换什么数据。

可靠性（Reliability）

可靠性：是软件无故障执行指定时间的概率。

健壮性有时可看成是可靠性的一部分。

衡量软件可靠性的方法，包括：正确执行操作所占的百分比和系统发生故障之前正常运行的平均时间长度。

具有高可靠性要求的系统，也应该设计得具有很高的可测试性，就可以轻松地发现损害系统可靠性的缺陷。

健壮性（Robustness）

健壮性：指的是当系统遇到非法的输入数据、相连接的软件组件或硬件组件的缺陷，以及预料不到的操作情况时，能继续正确运行功能的可能性。

健壮的软件：可以从发生问题的环境中自然地恢复过来，并且可以容忍用户所犯的错误。

当获取健壮性需求时，向用户询问系统可能遇到的错误条件，并且要了解用户期望系统如何响应。

易用性（Usability）

易用性：陈述了许多因素，用户经常将这些因素描述为“用户友好性"。

分析人员和开发人员不应该讨论友好的软件，而应该讨论将软件的使用设计得有效而不让人感到困惑。

易用性：包括：对于新用户或不常使用系统的用户在学习使用系统时的简易程度。

对开发人员重要的属性

可维护性

可维护性：表明了纠正缺陷或修改软件的简单程度，它取决于理解软件、更改软件和测试软件的简单程度。

可维护性：与灵活性和可测试性密切相关。

对那些将要频繁修订的系统和要快速生成的系统来说，可维护性的要求很高。

可以根据修复一个问题所花的平均时间和修复正确的百分比来衡量可维护性。

可移植性

可移植性：用来度量把一个软件从一种运行环境移植到另一种运行环境所需的工作量。

可移植性：对项目的成功来说，要么是无关紧要，要么是至关重要。

可移植性：目标应该确定系统中必须移植到其他环境的那一部分，并描述这些目标环境。

开发人员就能选择设计和编码方法以适当提高系统的可移植性。

可重用性

可重用性：是软件开发的一个长远目标。

可重用性：表明把一个软件组件用于其他应用程序所涉及的相关工作量。

比起创建一个打算只在一个应用程序中使用的组件，开发可重用软件的费用会大得多。

可重用软件必须模块化，文档齐全，不依赖于特定的应用程序和运行环境，并且具有通用性。

可测试性

可测试性：也称为：可验证性。

可测试性：指的是测试软件组件或集成系统以查找缺陷的简单程度。

如果系统中包含复杂的算法和逻辑，或包含复杂的功能性相互关系，那么对于可测试性的设计就很重要。

如果经常更改系统，那么可测试性也是很重要的，因为需要经常对系统进行回归测试，来判断更改是否破坏了任何原有的功能性。

属性的折中方案

用户和开发人员必须确定，与其他属性相比哪些属性更为重要。

当制定决策时，必须始终遵照优先级顺序。

如图所示，描述了质量属性之间一些典型的相互关系。

当然我们也可能会遇到一些与此不一致的例外

单元格中的加号：表明单元格所在行的属性对其所在列的属性具有正面的影响。

• 例如，增强软件组件可移植性的设计方法也可以使软件变得更加灵活，更易于与其他软件组件相连接，更易于重用，并且更易于测试。

单元格中的减号：表明单元格所在行的属性对其所在列的属性具有负面的影响。

单元格为空则表明单元格所在行的属性对其所在列的属性几乎没有什么影响。

有效性对其他许多属性具有消极影响。

类似地，一些对易用性进行优化的系统，或具有灵活性、可重用性以及与其他软件组件或硬件组件进行互操作的系统，则要付出性能的代价。

如图所示中的矩阵并不是对称的，因为增加属性A对属性B所产生的影响与增加属性B对属性A所产生的影响并不一定是相同的。

• 例如，图中表明设计系统时增加有效性并不一定对完整性产生任何影响。

增加完整性却可能会损害有效性，因为系统必须通过更多层次的用户身份验证、加密、病毒扫描和数据检查技术。

为达到系统特性的最佳平衡，必须在需求获取阶段识别、指定相关的质量属性，并且为之确定优先级。

为项目定义重要的质量属性时，利用图可以防止发生与目标冲突的行为。

性能需求

性能需求：定义了系统必须多好和多快地完成专门的功能。

性能需求：包括：速度（例如，数据库响应时间）、吞吐量（例如，每秒钟处理的事务）、处理能力（例如，并发使用负载）和定时（例如，严格的实时要求）。

苛刻的性能需求，会对设计软件策略和选择硬件造成严重的影响，因此，定义的性能需求目标要适合于运行环境。

性能需求范例：

范例1：温度控制循环必须在80毫秒内完全执行。这里，“80毫秒”就是性能需求。

范例2：解释器每分钟应该至少解析5000条没有错误的语句。这里，“5000条”就是性能需求。

范例3：在通过50KBps的调制解调器与Internet相连的情况下，下载一个Web页面需要15秒或更短。这里，“15秒或更短”就是性能需求。

范例4：ATM自动拒员机系统对提款请求的身份认证不能超过10秒。这里，“10秒”就是性能需求。

Summary

质量属性：

用于衡量系统性能的特性包括：系统的易用性、运行速度、出错频率，以及处理异常情况的能力等。

这些特性合起来被称为：软件质量属性或质量因素。

对用户重要的属性有：

可用性、有效性、灵活性、完整性、互操作性、可靠性、健壮性、易用性。

对开发人员重要的属性有：

可维护性、可移植性、可重用性、可测试性。

属性的折中方案

为达到系统特性的最佳平衡，必须在需求获取阶段识别、指定相关的质量属性，并且为之确定优先级。

性能需求

性能需求，定义了系统必须多好和多快地完成专门的功能。

性能需求，包括：速度（例如，数据库响应时间）、吞吐量（例如，每秒钟处理的事务）、处理能力（例如，并发使用负载）和定时（例如，严格的实时要求）。

第9章 通过原型来减少风险

为什么要建立原型？

因为预想一个未来的软件系统，并表达出系统需求是比较困难的，而通过制作软件原型，可以使需求更加真实，使用例更加生动，并且，可以减小在需求理解上的差异。

原型：可以把新系统的一个模型或一个部分摆在用户的面前，可以激活他们的思维，并促进需求对话。

对原型的早期反馈有助于涉众对理解系统需求达成共识，从而减小客户不满意的风险。

由于需求中仍然还会有对用户、对开发人员或者对这二者都不明确或不清晰的部分。

如果不解决这些问题，那么用户对系统的想像与开发人员对系统的理解会存在期望差距。

原型有多种含义，并且参与原型制作活动的人可以有完全不同的期望。

如：一个飞机原型实际上可能是真实飞机的雏形。

一个软件原型：仅仅是真实系统的一部分或一个模型，它可能根本不能完成任何有用的功能。

软件原型，可能是：

工作模型或静态设计

很详细的屏幕草图或简单草图

真实功能的可视化显示或一部分

使用原型有3个主要目的：

（1）明确并完善需求。

原型：作为一种需求工具。

原型：是对部分系统的初步实现，因为我们尚没有很好地了解该系统。

用户对原型的评估，可以指出需求中存在的问题。

这样可以在开发真正的系统之前，以低成本来解决这些问题。

（2）研究设计选择方案。

原型作为一种设计工具，涉众可以用它研究不同的用户交互技术，优化系统的易用性，并评估可能的技术方案。

原型能够通过有效的设计来演示需求的可行性。

（3）发展为最终系统。

原型作为一种构造工具，是系统一个最初子集的完整功能实现，通过一系列小规模的开发周期，我们可以完成整个系统的开发。

建立原型的主要原因：

是为了解决在系统开发早期阶段不能确定的一些问题。

利用这些不确定性，可以判断系统中哪些部分需要建立原型，以及希望从用户对原型的评估中获得什么信息。

原型：是发现并解决需求中的二义性和不完整性的很好的方法。

用户、管理人员和其他非技术人员发现：

当系统处于编写需求规格说明和设计阶段时，原型可以使他们更具体地思考问题

原型，尤其是直观的原型，比开发人员有时所使用的技术术语更易于理解。

根据使用原型的目的不同，原型分为：

1. 水平原型和垂直原型
2. 抛弃式原型和演化式原型
3. 书面原型和电子原型

水平原型

当人们谈到“软件原型”时，所想到的通常是一个可能的用户界面的水平原型。

• 水平原型，也叫做：行为原型或演示性模型。

• 水平原型：主要描绘了用户界面的一部分。

  • 因为水平原型并不能深入到体系结构的所有层次，或者深入到系统的细节。

• 通过水平原型，可以研究预期系统的一些特定行为，并达到完善需求的目的。

• 水平原型：有助于用户判断基于该原型的系统是否能完成任务。

• 水平原型：显示用户界面的屏幕外观，并允许这些屏幕之间进行某些导航，但只包含很少或根本就不包含真正的功能实现。

• 水平原型：能够演示用户以后可用的功能选项、用户界面的外观和感觉（如：颜色、布局、图形和控件），以及信息体系结构（如：导航结构）等。

• 虽然原型看起来似乎可以执行一些有意义的工作，但其实不然。

• 水平原型：常常只是使用户判断是否有遗漏、错误或不必要的功能。

• 有些原型，代表了开发人员对可能如何实现一个特定用例的一种观念。

• 用户对原型的评估，可以指出用例的其他实现方式、遗漏的交互步骤，或者其他异常情况。

• 当处理水平原型时，用户应该把注意力集中在概括性需求和工作流问题上，而不要被屏幕元素的精确外观所分心。

• 在此阶段，不要担心屏幕元素的精确位置、字体、颜色、图形或控件。

• 弄清了需求，并确定了界面的总体框架之后，再来研究用户界面的细节。

垂直原型

• 垂直原型：也称为：结构化原型、概念的证明

• 垂直原型：在整个技术服务层上实现应用程序用户界面的一部分功能。

• 垂直原型的运作与所期望的真实系统的运作类似，因为它触及到了系统实现的所有层次。

• 如果不能确定所提议的架构方法是否可行和合理，或者如果我们想要优化算法、评估所提议的数据库架构或测试关键的定时需求。就可以开发一个垂直模型。

• 垂直原型：为使其结果有意义，通常在与系统类似的运行环境中，用生产工具来创建垂直原型。

• 垂直原型：常用于研究关键界面和定时需求，也常用在设计阶段以减小风险。

抛弃式原型和演化式原型

（1）抛弃式原型

在构造一个原型之前，需要做出一个明确的和经过分析的决策。

也就是在评估之后是将原型抛弃掉，还是将原型作为最终交付系统的一部分。

如果打算在原型达到预期目的以后将它抛弃掉，那么，就应该尽量花最小的代价，并尽可能快地创建该原型。

在此原型上付出的努力越多，项目的参与者就越不愿意将它抛弃掉。

要注意的是：

如果认为该原型有其优点，应该留着以备将来重用，那么也不一定非要将它抛弃掉。

不能将“抛弃式原型”整合到最终交付的系统中。

可能更愿意将它称为“非发布型原型”。

抛弃式原型：重点强调在健壮性、可靠性、性能和长期维护性等方面的快速实现和修改。

不允许将抛弃式原型中质量低的代码移植到最终系统中，否则，用户和维护人员将在系统生命周期中遭遇种种麻烦

当团队面临需求中的不确定性、二义性、不完整性或含糊性时。

最恰当的方法是建立一个抛弃式原型。

这样可以减少在继续开发时存在的风险。

抛弃式原型：可帮助用户和开发人员直观地了解需求可能如何实现，并发现需求中存在的漏洞。

抛弃式原型：可以使用户判断出这些需求是否可以使必要的业务过程运作起来。

不要过于详细地构建抛弃式原型，只要能够满足原型制作的目标就够了。

如图所示，描述了借助于抛弃式原型，从用例到详细的用户界面设计的一系列开发活动。

演化式原型

当随着时间的推移，需求越来越明确时，演化式原型为增量地构建系统奠定了坚实的结构基础。

演化式原型：是螺旋式软件开发生命周期模型和某些面向对象软件开发过程的一个组成部分。

与抛弃式原型快速、粗略的特点相比，演化式原型必须具有健壮性，代码质量从一开始就要达到系统的要求。

要完成相同的功能，构建演化式原型要比构建抛弃式原型所花的时间更多。

演化式原型：必须设计得易于进行扩展和频繁改进，开发人员必须重视软件体系结构和成熟的设计原则。

要得到高质量的演化式原型，并没有捷径可走。

应该将演化式原型的第1次增量作为一个试验性版本，用来实现需求中已经正确理解和稳定的部分。

根据用户验收测试和初次使用时发现的问题，在下一次迭代中对其进行修改，最终得到完整的系统，可以很快地将能够使用的功能交付给用户。

如果已经预料到系统以后还要进行扩展。

那么，就选择演化式原型。

如图所示，给出了综合使用各种原型的几种方法。

如表所示，概括地总结了抛弃式、演化式、水平和垂直原型的一些典型应用。

书面原型和电子原型

（1）书面原型

书面原型：有时也称为“低保真原型"

书面原型：是一种成本低、速度快，且不涉及高深技术的方法。

书面原型：可以把一个系统的某部分，是如何实现的呈现在用户面前。

通过书面原型可以判断用户和开发人员对需求的理解是否一致。

书面原型：可以在代码编制之前，对可能的解决方案进行试验性和低风险的尝试。

书面原型：所涉及的工具仅仅是纸张、索引卡、粘贴便签和干净的塑料板等。

设计人员对屏幕布局进行构思，而不必关心布局中控件的精确位置和它们的外观。

当用户遍历一个评估场景时，一个人就可以充当计算机的角色。

用户说出他想在特定的屏幕上做什么来启动动作，模仿计算机的人就会把相应的纸张和索引卡拿给用户看，这些纸张和索引卡表示了用户采取这一动作时的外观显示。

用户就可以判断这是否确实是所期望的响应，并且还可以判断所显示的条目内容是否正确。

如果有错误，只需要用一张新纸或索引卡，重画一张就可以了。

书面原型：可以方便地实现快速迭代，而迭代对需求开发的成功与否起着至关重要的作用。

书面原型：也有助于开发团队管理客户的需求。

（2）电子原型

电子原型：就是一个基于计算机的可运行的原型。

构建一个抛弃式电子原型，可以使用以下工具：

1. 编程语言，例如：Visual Basic，IBM VisualAge Smalltalk和Delphi。

2. 脚本语言，例如Perk Python和Rexx（雷克斯）。

3. 商业原型制作工具箱、屏幕绘图器和图形用户界面生成器。

4. 绘图工具，例如Visio和PowerPoint

运用合适的工具，可以轻松地实现并修改用户界面组件，而不管隐藏在界面背后的代码效率高低。

如果创建一个演化式原型，那么必须从一开始就使用系统开发工具。

Summary

建立原型的3个目的：

（1）明确并完善需求

（2）研究设计选择方案

（3）发展为最终系统

根据使用原型的目的不同，原型分为：

水平原型和垂直原型

抛弃式原型和演化式原型

书面原型和电子原型

水平原型：主要描绘了用户界面的一部分。

因为水平原型并不能深入到体系结构的所有层次，或者深入到系统的细节。

垂直原型：也称为：结构化原型、概念的证明

在整个技术服务层上实现应用程序用户界面的一部分功能。

建立水平原型目的：

研究预期系统的一些特定行。

显示用户界面的屏幕外观、屏幕之间的导航。

建立垂直原型目的：

确定所提议的架构方法是否可行和合理。

优化算法、评估所提议的数据库架构或测试关键的需求。

（1）抛弃式原型：

是在原型达到预期目的后，就将原型抛弃掉。

当团队面临需求中的不确定性、二义性、不完整性或含糊性时，最恰当的方法是建立一个抛弃式原型。

（2）演化式原型：

是增量地构建系统，是被开发系统的一个组成部分。

必须具有健壮性，代码质量从一开始就要达到系统的要求。

必须易于进行扩展和频繁改进。

开发人员必须重视软件体系结构和成熟的设计原则。

（1）书面原型

书面原型：有时也称为“低保真原型"

书面原型：是一种成本低、速度快，且不涉及高深技术的方法。

书面原型：所涉及的工具仅仅是纸张、索引卡、粘贴便签和干净的塑料板等。

（2）电子原型

电子原型：就是一个基于计算机的可运行的原型。

（1）原型评估：

可以从原型所针对的用例或功能中推导出评估脚本。

务必要通过合适的人从恰当的角度来评估原型。

要同时包括有经验的和经验不足的用户类代表。

（2）创建原型所带来的风险：

风险1：是项目相关人员看到一个正在运行的原型，从而得出系统几乎已经完成的结论。

风险2：是用户重点关注的是系统“如何做”的问题，他们关注用户界面的外观如何，以及如何操作这些界面。

风险3：是用户将根据原型的性能来推断最终系统的期望性能。

（3）建立有效原型应遵循的原则：

1. 应该在项目计划中包括创建原型的任务。安排好开发、评估和更改原型的时间进度和所需的资源。

2. 创建原型之前，先要陈述每个原型的用途。

3. 要计划开发多个原型，因为很少能一次便成功。

4. 创建抛弃式原型时要用最少的投资开发出用于回答问题和解决需求不确定性的原型。

5. 抛弃式原型中不应包括输入数据有效性检查、防御式编码技术、用于错误处理的代码或代码注释。

6. 对于已经理解的需求不要建立原型，除非是要研究设计选择方案。

7. 在原型显示和报告中使用看似真实的数据。

第10章 确定需求的优先级别

为什么要设定需求优先级？

对于每一个受资源限制的软件项目，都必须对要求的功能定义相对优先级。

设定优先级：有助于项目经理解决冲突、安排阶段性交付，并且做出必要的取舍。

当用户的期望很高，而且开发时间又很紧迫时，就必须确保在系统的尽早版本中，提供最重要的功能。

设定优先级：就是一种行之有效的方法，可以处理在资源有限的情况下，应该优先满足哪些需求。

为每一种功能建立相对优先级后，就可以规划软件的开发过程，以最低的成本提供最佳的系统。

项目经理必须根据时间进度、项目预算、人力资源以及质量目标等约束条件，权衡考虑，制定出合理的项目范围。

达到此目的的一种方法是：

当接受一个更重要的新需求或者项目的其他条件发生变化时，删除优先级低的需求。

或者把它们推迟到下一版本中实现。

如果用户并没有将他们的需求按重要性和紧迫性区分开，那么项目经理就必须自己做出决策。

很可能用户并不赞成项目经理所设定的优先级，这不足为奇。

用户必须指明哪些需求必须在最初版本中得到实现，哪些需求可以延期实现。

当有多个可用方案都可以实现一个成功的系统时，应尽早在项目中设定优先级，并且要定期查看它们。

如果用户并没有将他们的需求按重要性和紧迫性区分开，那么项目经理就必须自己做出决策。

很可能用户并不赞成项目经理所设定的优先级，这不足为奇。

用户必须指明哪些需求必须在最初版本中得到实现，哪些需求可以延期实现。

当有多个可用方案都可以实现一个成功的系统时，应尽早在项目中设定优先级，并且要定期查看它们。

2）优先级规则

用户对设定优先级的第1个反应是：

“所有功能我都需要，无论采用什么方式，只要实现它就行”

如果用户知道优先级低的需求可能不会实现，那么就很难说服用户讨论需求优先级。

有些开发人员更喜欢避开设定优先级，因为他们认为：

他们可以全部完成系统功能。

事实上，即便是一个中等规模的软件项目，也有好几十个用户需求和好几百个功能需求，多到难以通过分析进行统一归类。

项目中总有一些系统功能比其他的功能更为必要。

在项目接近尾声时，当开发人员抛弃掉一些不必要的功能，以保证按期交付一些重要功能的时候，这一特性体现得尤为明显。

如果在项目的早期阶段设定优先级，并随着用户偏好、市场状况和业务事件的变更而重新评估它们。

那么，项目团队就可以“好钢用在刀刃上”，合理地将时间花在价值最高的功能中。

如果某一功能己经实现得差不多了，才得出该功能并不需要的结论。

则会造成时间上的巨大浪费，同时，也会让人感到很沮丧。

如果让用户自己设定优先级。

那么，他们将把85%的需求设定为高优先级，10%的需求设定为中等优先级，5%的需求设定为低优先级。

这并没有给项目经理很多灵活性。

如果确实是几乎所有的需求都具有最高的优先级。

那么，项目就面临着不能完全获得成功的风险，因此，应该制定出相应的计划。

可以通过废除不必要的需求，并且简化那些过于复杂的需求，来对需求做出调整。

为了帮助用户代表确认哪些需求属于低优先级的需求，分析人员可以向他们询问如下几个问题：

1. 是否有其他方法可以满足这一需求?

2. 如果忽略或推迟实现这一需求，其后果是什么?

3. 如果不立即实现这一需求，那么对项目业务目标会有什么影响?

4. 如果将这一需求推迟到下一版本中实现，用户为什么会不满意?

在一个小型项目中，项目相关人员可以非正式地就需求的优先级达成共识。

对于大型项目或有争议的项目，则需要采用一种更加结构化的方法，这样在处理过程中，可以消除一些感情因素、政策因素以及推测。

人们提出许多分析上的和数学上的技术，用于辅助需求优先级的确定。

这些方法包括：建立每个需求的相对价值和相对成本。

优先级最高的需求是那些以最低的成本生产出最高的系统价值的需求。

确定需求优先级的一些技术：

入选与落选

两两比较并排序

三层分级法

MoSCoW（莫斯科欧）排序法

在MoSCoW（莫斯科欧）优先级排序法中，四个大写字母代表在一个需求集合中四类可能的优先级类别，具体如下：

M字母，指的是：Must（必做）：需求必须满足，只有这样，解决方案才会被认为是成功的。

S字母，指的是：Should（应做）：需求很重要，并且如果可能，应当包含到解决方案中，但对于成功不是强制性的。

C字母，指的是：Could（可做）：想要但是可以推迟或者清除，只有当时间和资源都允许的时候才实现。

W字母，指的是：Won’t（不做）：表示这次不实现，但可能包含到未来的版本中。

对于如何通过比较其他需求来评级给定需求的优先级，MoSCoW（莫斯科欧）排序法并没有给出相关的依据。

MoSCoW（莫斯科欧）排序法：不关注时间，特别是需求被评定为“Won’t”时，极可能意味着“不在下个版本中做”，也可能意味着“永远不做”

设定优先级的一种方法是：

质量功能部署（简称：QFD）

质量功能部署：是将用户价值和所提议的系统功能相联系的一种综合方法。

在质量功能部署方法中，用户价值取决于两个方面：

一方面，如果实现了特定的系统特性，将为用户提供收益；

另一方面，如果不能实现系统特性，用户收益就要受到损害。

这个设定优先级的方法可适用于除了最高优先级之外的所有需求。

根据价值、成本和风险来设定优先级方法：

借鉴了质量功能部署的概念，对用户价值加以考虑。

即，考虑如果获得某个特定系统特性，会为用户提供什么收益，也考虑到如果没有那个特性，会带来什么损失。

在设定优先级的过程中典型的参与者有：

项目经理、用户代表和开发人员代表。

项目经理：负责整个过程，解决冲突，并且在必要的时候协调其他参与者的意见。

用户代表：可以提供受益和损失的程度。

开发人员代表：可以提供成本和风险程度。

根据价值、成本和风险来设定优先级，必须遵循如下8个步骤：

• 步骤1：在表格中列出要设定优先级的所有特性、用例或功能需求。

所有条目都必须在同一抽象级别上，不要把功能需求与系统特性混合在一起。

如果某些特性有逻辑上有联系，在分析中只要列出驱动较全面的项。如果有更多的项，那么就把相关的特性归成一类，并建立一个可管理的初始化列表。

如果需要的话，可以在更详细的级别上进行第二轮分析。

• 步骤2：让用户代表来估计每一个特性提供给用户或业务的相关收益，并用1-9划分等级，1代表对任何人都没用的特性，9代表具有最大价值的特性。

这些收益等级表明这些特性与系统业务需求的一致性。

• 步骤3：估计出如果没有把某一特性包括到系统中，将会给用户或业务上带来的相对损失。

仍然使用1-9划分等级，这里1代表即使不包括这一特性也无人会介意，9代表如果不包括这一特性将带来严重损失。

对于具有低收益低损失的需求只会增加费用，而不会增加价值；

步骤4：将表格中的“相对收益”和“相对损失”相加，并考虑权值，计算出每个特性的总价值。

即：总价值 = 相对收益收益权值 + 相对损失损失权值

并计算出每个特性价值占总价值的百分比。

即：“价值%”一栏。

步骤5：让开发人员估计实现每个特性的相对成本，并计算出每个特性价值占总相对成本的百分比。

使用1-9来划分等级，1代表快速而容易，9代表费时又昂贵。

根据特性的复杂度、所需要的用户界面的实际情况、重用当前代码的潜在能力、所需的测试量和文档等等，开发人员可以估算出相对成本。

步骤6：让开发人员估计出与每个特性相关的技术风险或其他风险的相对程度，并计算出每个特性所产生的风险百分比。

技术风险：是指第1次尝试实现某个特性时，不能成功的概率。

使用1-9来划分等级，1表示可以轻松地实现编程，9表示需要重点关注其可行性、缺乏具有专门知识的人员，或者使用不成熟或不熟悉的工具和技术。

如果根本无需在分析中考虑风险，就把风险的权值设为0。

步骤7：把所有的估算值都填入表格之后，就可以利用优先级公式，计算出每一特性的优先级值。

步骤8：按计算出的优先级的降序排列表中的特性。处于列表最顶端的特性是价值、成本和风险之间的最佳平衡，因此，具有最高的优先级。

Summary

设定需求优先级原因：

设定优先级有助于项目经理解决冲突、安排阶段性交付，并且做出必要的取舍。

为每一种功能建立相对优先级后，就可以规划软件的开发过程，以最低的成本提供最佳的系统。

分析人员可以向用户询问的几个问题：

1. 是否有其他方法可以满足这一需求?

2. 如果忽略或推迟实现这一需求，其后果是什么?

3. 如果不立即实现这一需求，那么对项目业务目标会有什么影响?

4. 如果将这一需求推迟到下一版本中实现，用户为什么会不满意?

确定需求优先级的技术，包括：

入选与落选

两两比较并排序

三层分级法

MoSCoW（莫斯科欧）排序法

设定优先级的质量功能部署方法：

质量功能部署（简称：QFD）

质量功能部署：是将用户价值和所提议的系统功能相联系的一种综合方法。

根据价值、成本和风险来设定优先级，有8个步骤。

以“化学品跟踪系统”的特性为例，介绍了根据价值、成本和风险来设定优先级的过程。

注意：

计算出来的优先级序列，只能作为一种指导策略的参考。

客户和开发者代表应该讨论，从而达成共识，并根据使用情况来校正。

可以适当调整每一因素的权值，直到所计算出的优先级序列与后来对测试集中需求的重要性评估相吻合为止。

在把需求优先级的设定，应以客观和分析为基础

第11章 需求确认

• 需求确认：是指开发方和用户方共同对软件需求规格说明进行评审，双方对需求达成共识后作出承诺。

• 是需求开发的最后一个环节。可以通过内部评审、同行评审以及用户评审的方式来完成。

• 项目组内部评审或同行评审：主要是根据公司规范和评审人员本身的经验对需求分析中不明确、不合理、不符合逻辑、不符合规范的地方予以指正。

• 用户评审：主要是对描述的软件实现是否真正符合他们的需求，能否帮助他们解决问题等方面做出评定。

• 需求确认的目的：是要检验需求是否能够反映用户的意愿。是尽可能地发现需求里的错误，减少因后期修改需求错误所带来的损失。

需求确认的提出：

避免信息衰减的关键手段

1. 文档

   如果信息在传递的过程中仅靠口头传递，就难免发生遗忘、加工等情况。

   因此，必须在这个过程中有效地利用文档，将达成共识的信息文档化。

   但这种方法只是用来辅助沟通的，而不是代替沟通。

2. 评审

    评审：在很多人的脑海中就是得出一个通过与否的结论，这也是导致需求评审工作流于形式的罪魁祸首之一。
    
    评审：是通过再次的审读，尽早地暴露出错误。
    
    最简单、有效的评审：是在用户代表阐述了需求之后，需求分析员用自己的语言再复述一遍，以确保沟通没有失真。
    
    评审的首要任务：是确认需求是否充分，并正确的反映了用户的需求。
   

需求确认：

首先需要用户来验证结构和文档化后的需求是否和他们的想法一致，是否把用户的真实意图描述清楚了，以保证需求本身的正确性。

对于后续设计开发阶段的人员也需要对需求进行评审，以保证需求的可实现性，确认需求描述是否清楚，是否是可以实现的，对于业务对象，流程和规则是否存在不可实现的模糊描述词语。

对于测试人员，则主要是确认需求是否是可测试的，是否在需求描述中存在不确定和不可测试的词语。

不仅仅是需求阶段对需求文档的评审，还需要关注设计，开发等各阶段对需求的实现情况的验证。指在需求规格说明完成之后，对需求规格说明文档进行的验证活动。是对需求的复查和审核，目的是发现需求中存在的错误，以便及时更正，避免在后期实施中修改造成大量的损失。

好的需求将会带来好的系统质量和用户满意度，降低系统后期维护和用户支持的费用。

需求确认的任务：

需求确认的活动确保以下几个方面的内容：

1. 软件需求规格说明是否正确描述了目标系统的行为和特征；

2. 从系统需求、业务规则或其他来源中得到软件需求；

3. 需求是完整的和高质量的；

4. 所有人对需求的看法是一致的；

5. 需求为进一步的软件开发和测试提供了足够的基础。

需求确认的任务：就是要求各方人员从不同的技术角度对需求规格说明文档做出综合性评价。

需求确认的内容：

一般来说，从下述4个方面进行需求验证：

1）一致性：所有需求必须是一致的，任何一条需求不能和其他需求相矛盾。

2）完整性：需求必须是完整的，软件需求规格说明应包括用户需要的每一个功能和性能。

3）现实性：指定的需求在现有的硬件技术或软件技术的基础上应该是基本上可行的。

4）有效性：必须证明需求是正确有效的，确实能解决用户需求间的矛盾。

一般可根据软件系统的特点和用户的要求增加一些检验内容。

如：软件的可信特性，即安全性、可靠性、正确性以及系统的灵活性等。

验证需求规格说明的方法，除形式化方法外，大部分只能通过人工进行检测。

此外，部分项目相关人员也不愿意在需求确认方面花费时间。

形式化的验证方法主要使用数学方法：

即，将软件系统抽象为用数学符号表示的形式系统。

然后，通过推理和证明的方式来验证软件系统中的一些性质，如：完整性、一致性、可信特性等。

这种方法的好处：是严格和自动化。

这种方法的不足：是对数学基础的要求太高，难度较大。

通过人工进行检测的方式有很多，例如：需求评审。

这种方式就是让与项目相关的所有人员参加，并根据验证的内容人工评审软件需求规格说明文档。

另外，还可结合现有的一些软件技术，如：设计测试用例的方法等，对软件需求进行多方面的、有效的检验和测试

需求评审方法

需求评审：是由需求评审员对软件需求规格说明进行检查，以发现其所存在的问题。

通过对需求规格说明的评审，可以发现其中的不确定和二义性的要求等。

需求评审，可划分为：非正式评审和正式评审

非正式评审：由开发人员描述系统并征求意见。

包括：把工作系统分发给许多其他有关人员，粗略地看一看或走过场地检查。

非正式评审的好处：是能培养其他人对系统的认识，并可获得一些非结构化的反馈信息。

非正式评审的不足：是不够系统化和不彻底，或者在实施过程中不具有一致性，并且非正式评审不需要记录，完全可以根据个人爱好进行。

非正式评审方法包括：

——同级桌面检查：就是请一位同事检查系统

——轮查：就是同时请若干同事分别检查可交付的系统

——走查：作者向评审员描述系统，请求做出评论。

正式评审：由不同背景的审查人员组成小组，阅读需求规格说明文档，把其中的问题记录下来，再转送给软件开发人员。

正式评审：有专门的审查人员，正规的审查过程和步骤，审查人员有严格的分工和职责。

需求评审的组成人员

在需求正式评审过程中，应由具有不同背景的人组成一个小组，对需求规格说明文档进行评审。

审查人员由4个方面的人组成：

1）从事软件系统需求开发的相关人员。

这类人员主要是指编写需求规格说明的系统分析员及相应参与人员等。

2）具有需求分析经验和知识的人员，以及领域专家等。

这些人可以审查需求规格说明文档是否符合标准，是否存在错误等。

3）客户或用户代表。

这些人可以保证需求规格说明能正确地、完整地描述他们的需求。

4）软件开发人员，

如：设计人员、测试人员、项目经理等。这些人可以发现需求规格说明中存在的不可实现的、含糊或二义性等。

审查人员的主要角色：

作者：编写正在被审查的需求规格说明文档的人，通常为系统分析员。

他们听取其他审查员的评论，并回答其他审查员提出的问题，但不参与讨论。

调解员：审查的调解与主持人，通常为项目总负责人。

调解员与作者一起制定审查计划，协调审查期间的各种活动，以及推进审查工作的进行。

读者：主要由审查员扮演，审查需求规格说明文档，并提出问题，以及自己的看法和理解。

记录员：以标准的形式记录在审查中提出的问题和缺陷。

记录员必须仔细地整理自己所写的材料，以确保记录的正确性。

需求评审的过程

规范的评审过程包括：规划、总体会议、会前准备、评审会议、返工、跟踪6个阶段。

1）规划

由作者和调解员对审查进行规划。

如：决定谁参加审查，审查之前应准备什么材料，审查会议的日程安排等。

2）总体会议

总体会议：可以为审查员提供了解会议的信息。

包括：要审查的材料背景，作者所做的假设和作者的特定审查目标。

如果所有的审查员对要审查的项目都很熟悉，那就可以省略本次会议。

3）准备

准备工作：做的好不好直接关系到评审会议的质量。

应为每位评审者提前提供相关资料，提供时间做相关阅读、查找错误。

评审者可将阅读时发现的文字、版面类的错误直接发给作者，无需在评审会议上讨论，以便节省会议时间，提高会议质量。

4）评审会议

在进行审查的过程中，审查员审查软件需求规格说明中的每一个需求。

当审查员提出可能的错误或其他问题时，记录员就记录这些内容，它们可以成为需求规格说明的作者的参考依据。

会议的目的是尽可能多地发现需求规格说明中的重大缺陷。

开审查会的时间不宜过长，如果需要更多的时间，就另外再安排一次会议。

5）返工

当发现需求规格说明中出现问题时，作者必须在审查会之后安排一段时间用于修改文档。

如果把不正确的需求拖延到以后修改，将十分费时。

马上修改可以解决二义性和消除模糊性，并为成功开发项目打下坚实的基础。

6）跟踪

当发现同一类错误多次出现在需求规格说明书中不同地方时，就会发现评审中提出的问题没有得到有效的解决。

因此，应对提出的问题是否解决进行跟踪、督促，避免同类问题再出现。

需求评审面临的困难

当需求规格说明编写完成后，开发人员希望能尽快地开发软件系统。

认为需求评审工作是重要的。

但最重要的是后面的开发工作，从而导致需求评审成为“走过场”。

在需求评审工作中，一些常见的问题说明如下：

1）大型的需求文档

对于一个大的复杂软件系统，其需求规格说明往往有几百页，要审查这样的需求规格说明工作量是非常大的。

既使一个中型的需求规格说明，审查人员可能会认真地检查开始的部分，有耐心的人可能会审查到中间的部分，但无人可以坚持检查到最后。

这就导致忽略审查过程，而直接进入软件的开发工作。

对于上述问题的解决方案是：

可在强调评审工作重要性的基础上，采用多人分段审查的方式，让一些审查员，从文档的不同位置开始检查，以确保认真地检查其中的每一页，或者采取分组方式，不同组分别审查材料的不同部分。

2）庞大的审查小组

一个项目可能涉及许多的相关人员，如：用户、部门经理、销售部门等，他们都与需求相关。

这些人都可以成为需求评审员。

然而，评审小组过于庞大，将导致难于安排会议，并且在审查会议上经常引发题外话，在许多问题上也难于达成一致意见。

这种情况经常导致花了大量的时间而无较好的结果等。

对于上述这些困难，往往要根据实际情况给予解决。

例如，可在强调评审工作重要性的基础上，采取解释与说明的方式，采用多人分段审查的方式，以及采取分组方式等。

测试需求

测试需求概述

测试需求，是验证需求是否是正确的、完整的、无二义性的。

测试人员要能够分辨出来问题点，并跟用户进行核对，确定用户的真实需求。

测试需求的输入主要包括：

需求规格说明、用户用例、界面设计、项目会议或与用户沟通时有关需求信息的会议记录、其他技术文档等；

测试需求的输出主要包括：

问题点及修改建议，以及测试分析结果。

在部分需求稳定时，就可以开始设计测试用例，及早发现问题并以较少的费用解决这些问题。

测试需求：是对测试目标的概括，根据测试需求，了解测试时所应测试的功能点。

测试需求：主要是整理测试焦点。

包括：一些界面、输入域、业务流程、数据等。

并明确测试焦点的优先级，为测试用例的设计提供测试所需的功能点信息。

测试需求：是告诉要测什么，而测试用例是告诉怎么测。

好的测试需求：能发现需求中显性和隐性的测试焦点，从而能更好地指导测试用例的设计。

在开发过程的早期阶段，可以从用例中获得概念上的功能测试用例。

即，可验证需求规格说明和分析模型，并做出评价。

为什么要进行测试需求？

1）把不直观的需求转变为直观的需求。

使得测试范围可以度量；

使得独立的功能点其对应的所有的处理分支可以度量；

使得该系统需要测试的业务场景可以度量；

2）把不明确的需求转变为明确的需求，明确其功能点对应的输出、处理和输出；

3）把不能度量的需求转变为可度量的需求。

包括：度量测试范围，度量处理分支，度量业务场景。

需求测试的范围主要有：

1）需求的背景，目标，影响范围；

2）系统的输入输出，类型，精度，允许的出错次数，输出的格式，数据的来源以及正确性；

3）响应时间，提示的方式，异常处理方式，性能指标；

4）主要流程描述，操作流程和步骤说明，分析是否合理化；

5）需求的上下文是否一致，有没有与其他需求发生冲突；

6）需求逻辑是否足够清晰，每个条款是否都包含描述问题及解决问题；

7）需求是否都是可测试的；

8）寻找隐含的需求，和相互依赖的需求。

4）推荐的需求文档格式的内容

主要有：

1）业务名称解释；

2）需求背景及目标介绍；

3）用户操作场景说明；

4）功能总览：

如：逐项叙述对系统所提出的功能要求，说明输入什么量、经怎么样的处理、得到什么输出；

5）系统交互图；

6）界面原型；

7）业务规则说明；

8）业务正常流程：如：功能模块流程，主要操作流程；

9）业务异常流处理：如：异常场景，错误提示；异常流转。

4）推荐的需求文档格式的内容

这里要注意：

需求测试：不等同于集成测试或者系统测试。

软件测试，都是软件已经编写完成的条件下，判断软件是否会出错。

而需求测试，只是验证需求是否真正是用户的要求。

Summary

需求确认：是软件工程中一项重要的活动。

需求确认：是需求工程中发生的对需求规格说明文档进行的验证与确认活动。

需求确认：不仅要发现问题，而且要监督、跟踪问题的解决。

验证和确认的过程：贯穿于项目开发的每个阶段。

尽早的了解系统需求，可很大程度上节约后期修改的成本。

需求确认，主要包括：需求的评审和作出承诺。

需求确认的目的：

是要检验需求是否能够反映用户的意愿。

是尽可能地发现需求里的错误，减少因后期修改需求错误所带来的损失。

需求确认，主要包括：需求的评审和作出承诺。

需求确认的目的：

是要检验需求是否能够反映用户的意愿。

是尽可能地发现需求里的错误，减少因后期修改需求错误所带来的损失。

（1）需求确认的任务：

是对需求规格说明文档做出综合性评价。

需要确认的内容主要是验证需求的：

一致性、完整性、现实性、有效性4个方面。

（2）需求确认的内容：

一致性

完整性

现实性

有效性

（1）需求评审方法：

需求评审：就是由需求评审员对软件需求规格说明进行检查，以发现其所存在的问题。

需求评审可划分为：非正式评审和正式评审

（2）需求评审的组成人员：

1）从事软件系统需求开发的相关人员。

2）具有需求分析经验和知识的人员，以及领域专家等。

3）客户或用户代表。

4）软件开发人员。

3）需求评审的过程：

规范的评审过程包括：规划、总体会议、会前准备、评审会议、返工、跟踪6个阶段。

（4）需求评审面临的困难：

1）大型的需求文档

对于一个大的复杂软件系统，其需求规格说明往往有几百页，要审查这样的需求规格说明工作量是非常大的。

2）庞大的审查小组

一个项目可能涉及许多的相关人员，如：用户、部门经理、销售部门等，他们都与需求相关。

测试需求的解释：

测试需求，是验证需求是否是正确的、完整的、无二义性的。

为什么要进行测试需求？

1）把不直观的需求转变为直观的需求。

2）把不明确的需求转变为明确的需求，明确其功能点对应的输出、处理和输出；

3）把不能度量的需求转变为可度量的需求。

需求测试的内容：

1）需求的背景，目标，影响范围；

2）系统的输入输出，类型，精度，允许的出错次数，输出的格式，数据的来源以及正确性；

3）响应时间，提示的方式，异常处理方式，性能指标；

4）主要流程描述，操作流程和步骤说明，分析是否合理化；

5）需求的上下文是否一致，有没有与其他需求发生冲突；

6）需求逻辑是否足够清晰，每个条款是否都包含描述问题及解决问题；

7）需求是否都是可测试的；

8）寻找隐含的需求，和相互依赖的需求。

推荐的需求文档格式的内容：

1）业务名称解释；

2）需求背景及目标介绍；

3）用户操作场景说明；

4）功能总览；

5）系统交互图；

6）界面原型；

7）业务规则说明；

8）业务正常流程：如：功能模块流程，主要操作流程；

9）业务异常流处理：如：异常场景，错误提示；异常流转。

第12章 需求管理实践

（1）需求管理内容
软件需求工程，分为：需求开发和需求管理。
需求开发活动：
包括：获取需求、分析需求、描述需求和确认需求。
需求开发的交付物：
包括：业务需求、用户需求、功能需求、非功能需求、数据字典和各种分析模型等。
在这些交付物经过评审，且核准之后，这些条目的任何已定义子集都可以组成需求基线。