03需求工程的推荐方法教案

《软件需求（第2版）》，教案

3 需求工程的推荐方法 (1)

3.1 知识技能 (2)

3.2 需求获取 (3)

3.3 需求分析 (5)

3.4 规格说明 (6)

3.5 需求验证 (7)

3.6 需求管理 (8)

3.7 项目管理 (9)

3.8 开始新实践 (10)

3.9 需求开发过程 (11)

3需求工程的推荐方法

十多年前，我曾是一个软件开发方法集的爱好者。软件开发方法集（methodology）指包装好的整套模型和技术方法，用于为项目提供整体解决方案。但现在我更愿意寻找和应用行业的最佳方法（best practice）。最佳方法的做法是：在你的软件工具包中储存各种技术方法，用于解决不同的问题，而不是试图设计或购买整体解决方案。即便采用商业开发方法集，也可以对其进行改造，使它最大程度地满足你的需求。还可以从工具包中选出其他有效方法补充该方法集。

最佳方法是一个有争议的说法：谁能决定什么是“最佳”，他有什么依据？一种决定方法是召集一群行业专家或研究员来分析来自不同组织的项目。这些专家在其中寻找一些方法，它们的有效性能是和成功的项目联系在一起，而失败的项目则往往没有很好地实施这些方法，或者根本就没有实施。通过这些手段，专家们就那些一直产生良好结果的活动达成了一致。这些活动就被称为最佳方法。对于专业软件人员来说，这些活动代表了十分高效的方法，能够提高特定类型或特定条件下项目的成功几率。

表3-1列出了近50种方法，分别属于7个类型，它们可以帮助大部分项目开发团队更好地完成他们的需求工作。有几项方法属于多种类型，但是表3-1中每个方法只出现一次。这些方法并不能适用于所有情况，因此要运用合适的判断标准常识和经验而不是照本宣科地应用它们。注意并非所有这些方法都己经被认定为行业最佳方法，这就是为什么我将这一章的标题定为“需求正程的推荐方法”，而不是“最佳方法”的原因。我怀疑是否所有这些方法都曾为了这个目的而被系统地评估过。尽管如此，很多业内人士已经发现这些技术是有效的（Sommervillc和Sawyer 1997；Hofmann和Lehner 2001）。本章中将简单介绍每一个方法，并给出了可以获得关于该技术的更多内容的章节或其他来源。本章的最后一节介绍了一个适合绝大部分软件项目的需求开发过程（一系列活动）。

表3-1需求工程推荐方法

3.1 知识技能

软件开发人员大都未曾接受过需求工程的正规培训。然而，许多开发人员在他们职业生涯的某些时刻都会担任需求分析员的角色，与用户打交道，获取、分析需求，并将它们编写成文档。期望所有开发人员天生就都胜任需求工程中需要进行大量沟通的工作是不合理的。培训可以提高分析员的熟练程度，使他们工作起来更得心应手，却无法弥补人际关系能力的不足或兴趣的缺乏。

由于需求过程是必不可少的，因此项目的所有涉众都应该理解需求工程的概念和方法。将各方涉众召集起来利用一天的时间进行软件需求培训，这是打造团队的一种有效方法。各方可以更好地理解合作伙伴所面临的挑战，明白为了整个团队的成功参与者们需要对方做些什么。同样，开发者也应该了解产品应用领域中的基本概念和术语。关于这些主题可以在以下章节中找到更详细的内容：

·第4章

●第10章

培训需求分析员

所有将要成为分析员的团队成员都应该接受需求工程方面的基本培训。需求分析专家需要几天时间来进行这样的培训。熟练的需求分析员应具备以下特点：耐心，思维条理性强，有良好的交际和沟通能力，理解产品应用领域，并且掌握丰富的需求工程技术。

对用户代表和管理者进行软件需求培训

参与软件开发的用户应该接受一到两天的需求工程方面的培训。开发经理和客户经趸也会发现这些内容很有用。培训可使用他们明白重视需求的意义；需求工作包括哪些活动，要提交什么样的结果；忽略需求过程会导致什么风险。一些参加过我的需求研讨课程的用户说他们从此更加体谅软件开发人员。

对开发人员进行应用领域的相关培训

为了帮助开发人员对应用领域有一个基本的理解，可以安排一个研讨课程，内容是客户的业务活动、术语和产品的目标。这样可以减少开发过程中的混淆、误解、和返工。还可以在项目开发过程中为每位开发人员配备一位“用户伙伴”，负责向他解释行话和业务概念。用户代言人可以担当这个角色。

创建项目术语表

定义应用领域专业名称的术语表可以碱少误解。术语表中包括同义词、有多种含义的术语、以及既有特定领域的含义又有日常含义的术语。既可以是名词又可以是动词的单词，如“process”和“order”，尤其容易产生混淆。

3.2 需求获取

第1章讨论了3个不同层次的需求：业务需求、用户需求和功能需求。这些需求在项目不同阶段的来源不同，有着不同的受众和目的，需要用不同的方式写入文档。项目范围内的业务需求不能排斥任何必要的用户需求，而且每项功能需求都应该可以追溯到对应的用户需求。您还需要收集非功能需求，如对质量和性能的要求。在以下章节中介绍了有关这些主题的内容：

·第3章

·第5章

●第6章

●第7章

●第8章

●第22章

定义需求开发过程

将你的组织如何获取和分析需求、编写规格说明和验证需求的步骤编写成文档。提供如何完成主要步骤的指导可以帮助分析员做好工作，还能够使规划项目的需卒尹发任务、进度和所需的资源变得更为容易。

编写前景和范围文档

前景和范园（vision and scope）文档包含了产品的业务需求。前景说明使所有涉众可以对产品的目标达成共识。范围则定义了需求是否属于某个特定版本的界线。前景和范围一起

为如何评估提出的需求提供了参考。项目前景应该在不同版本之间保持相对稳定，但是每个版本需要有自己的项目范围声明。

确定用户群和他们的特点

将产品的用户分成组，以避免出现某一用户群的需求被忽略的情况。不同的用户在很多方面存在着差异，例如：使用产品的频率、所使用的产品功能、他们的优先级以及熟练程度。详细描述出他们的工作内容、意见、工作地点及其个性特点将有助于实现更好的产品设计。

为每类用户选择代言人

为每类用户选择至少一位能够准确反映其需求的代言人。用户代言人提供某一类用户的需求，并代表他们作出决策。开发内部信息系统时这很容易做到，因为用户就是同事。而开发商业产品时，则要与主要的客户或测试者建立起良好的合作关系，从而确定合适的用户代言人。用户代言人必须一直参与项目的开发而且有权在用户需求方面作出决策。

建立典型用户的中心小组

把产品早期版本或同类产品的用户代表召集起来，收集他们对正在开发的产品的功能和质量特性的意见。这样的中心小组对于商业开发尤为有用，因为你可能拥有一个庞大且多样的客户群。中心小组与用户代言人不同，他们通常没有决策权。

与用户代表沟通以确定用例

与用户代表沟通、了解他们需要使用软件来完成的任务——用例。讨论用户与可以完成这些任务的系统之间的交互方式。在编写用例的文档时应采用标准模板，并根据这些用例推导出功能需求。一种经常用于政府项目的方法是定义一个业务概念（ConOps）文档，它从用户的观点出发描述了新系统的特性（IEEE 1998a）。

确定系统事件和响应

列出系统可能发生的外部事件以及对每个事件所期待的响应♂事件包括从外部硬件设备所接收的信号或数据，以及可以触发响应的临时事件，例如你的系统在每晚同一时刻生成的外部数据输入事件。业务事件可触发业务应用中的用例。

召开专门的需求获取讨论会

专门的需求获取讨论会可以方便分析员和客户进行合作。它是研究用户需求、编写需求文档的一种十分有效的途径（GottesdiCner 2002）。这种会议的典型例子包括联合需求计划（Join七Requircments P1anning，简称JRP）会议和联合应用程序开发（Joint App1icationDcvclopmcnt，简称JAD）会议。

观察用户工作的过程

观察用户执行业务任务的过程，能够确定用户对新的应用程序可能有哪些应用。可以画一张简单的工作流程图（最好用数据流图解）来描绘用户什么时候拥有什么数据，以及怎样使用这些数据。编制业务过程流程文档将有助于您确定支持该业务过程的系统需求。您甚至可能性发现客户并非真的需要一个全新的软件系统就能达到他们的业务目标。

检查当前系统的问题报告来进一步完善需求

客户的问题报告及补充需求提供了很多建议，抬出在新产品或新版本中应添加哪些功

能。负责提供支持及帮助的人能够为将来开发工作中的需求提供很有价值的信息。

跨项目重用需求

如果客户要求的功能与已有产品的某项功能很相似，则可以查看需求（和客户！）是否具有足够的灵活性允许重用一些已有的组件。多个项目可以重用那些符合一个组织的业务规则的需求。这类需求包括用于控制对应用程序的访问的安全需求，符合政府法规（如残疾人法）的需求等。

3.3 需求分析

需求分析包括对需求进行推敲和润色以保证所有的涉众人都能够理解需求，以及仔细检查找其中的错误、疏漏和萁他缺陷。分析包括将高层的需求分解成具体细节、创建开发原型，以及评估可行性和协商需求优先级。其目的是开发高质量、内容详细的需求，让管理者能够对项目做出实际的评估，使技术人员能够继续进行设计、开发和测试。

用多种方式来表达某些需求通常是很有帮助的——例如，同时使用文本和图形形式。这些不同的方法可以揭示出许多单独一种方法所不能发现的问题。多种方法将有助于所有涉众就产品发布后他们将得到什么达成共识（一个共享的视图）。关于需求分析方法的更多讨论可以在以下章节中找到：

●第5章

·第10章

●第11章

●第13章

●第14章

·第17章

绘制关联图

关联图是显示新系统如何适应它的环境的一个简单的分析模型。它定义了正在开发的系统和系统的外部实体（如用户，硬件设备和其他信息系统）之间的界线和接口。

创建用户界面和技术原型

当开发人员或用户对需求不能确定时，可构建一个开发原型———个不完全的、可能的、初步的实现，以便使概念和可能性变得更为直观明了。让用户评估原型能够帮助项目涉众对要解决的问题形成更一致和正确的理解。

分析需求的可行性

在允许的成本和性能要求下，分析在指定的运行环境下实现每项需求的可行性。明确与每项需求实现相关的风险，包括与其他需求之间的冲突、对外界因素的依赖以及技术上的障碍。

确定需求优先级

可采用分析方法确定产品功能、用例或单项需求的相对实现优先级。以优先级为基础，确定各项功能或各组需求应包括在哪个版本中。接受需求变更后，应将每一项变更加入到将来的某一版本中，并在该版本的计划中作出相应的变化。在项目的整个开发过程中，应定期评估和调整优先级，以适应客户需求、市场条件和业务目标的变化，

为需求建模

较之SRS中的细节或原型提供的用户界面视图，图形分析模型对需求的描述更为抽象。模型能够揭示不正确的、不一致的、遗漏的或冗余的需求。这类模型包括数据流图、实体关系图、状态转换图或状态图、对话图、类图、序列图、交互作用图、决策表和决策树等。

创建数据字典

数据字典中包括系统用到的所有数据项和结构的定义。数据字典可使参与项目开发的每个人都使用统一的数据定义。在需求阶段，数据字典应该定义问题领域中的数据项以方便客户和开发团队之间的交流。

将需求分解到子系统

必须将包括多个子系统的复杂产品的需求分配到各个软件、硬件以及人员子系统和部件中去（NclsCn 1990）。这种分配工作通常由系统工程师或架构设计师来完成。

应用质量功能调配

质量功能调配（QFD）是一种高级系统技术，它将产品功能、属性与客户的重要性联系起来（ZultnCr L993；Pardcc 1996）。该技术提供了一种分析方法以明确哪些功能最能满足客户的需要。QFD将需求分为3类：期望需求——客户或许并未提及，但若缺少却会让他们感到不满意的需求；普通需求：额外需求——实现了会给客户带来较高利益，未实现也不会受到责罚。

3.4 规格说明

不管你如何获得需求，都应该将它们编成一致的、可访问、可检查的文档。可以用项目前景和范园文档记录业务需求。用户需求通常使用用例或事件响应表来表达。SRS中包含详细的软件的功能需求和非功能需求。编写需求说明的方法在以下几章中讨论！

●第9章

●第10章

·第12章

采用SRS模板

为组织定义一种标准模板用于编写软件需求规约。该模板为记录功能说明和其他与需求相关的信息提供了统一的结构。不必创建一种全新的模板，只需改造一个已有的模板让它可适合你的项目特点即可。许多组织都采用IEEE Standard 830－1998（IEEE 1988b）中规定的SRS模板作为基础；第10章中给出的模板就改造自该模板。如果你的组织开展了多个不同种类和规模的项目，例如大型的新项目和小规模的版本改进，应该为每个项目定义一个合适的模板。模板和过程的规模都应是可缩放的。

确定需求来源

为保证所有涉众都明自SRS中为何包括这些需求，以及便于进一步阍明需求，应追溯每项需求的来源。结果可能是某项用例或其他客户要求，也可能是更高层的系统需求、业务规则或其他外部来源。为每项需求记录受其影响最大的涉众，这样，当变更请求提上议程时，你就可以知道该和谁联系。可以通过使用跟踪链或者定义需求属性来确定需求来源。关于需

求属性的更多内容可参见第18章。

为需求分配惟一标号

可定义一种约定，用于为SRS中的每项需求提供一个惟一的识别标号。这种约定应该很健全，经得起随时间推移发生的对需求的增加、删除和修改。为需求标号使得需求可以被跟踪，其变更可以被记录。

记录业务规则

业务规则包括公司章程、政府法规和计算机算法。之所以应将业务规则从SRs中分离出来单独形成文档，是因为它们的存在通常超出了特定项目的范围。某些业务规则将引出实施它们的功能需求，因而需要在这些需求和对应的规则之间定义跟踪链。

定义质量属性

在功能需求之外还应考虑非功能的质量属性，运会使你的产品达到并超过客户的要求。这些属性包括性能、效率、可靠性、可用性等。应该将质量需求写入SRS文档。客户对这些质量属性的相对重要性的意见可以让开发者做出适当的设计决策。

3.5 需求验证

需求验证可确保需求声明是正确的、具备了所需的质量属性，而且能够满足客户的需要。SRS中有些需求读起来感觉很好，可是当开发人员在实际工作中使用它们时就会出现问题。根据需求编写测试用例时经常会发现需求中的歧义和含糊不清的地方。只有纠正这些问题，才能使需求成为设计和最终系统验收（通过系统测试或用户接受度测试）的可靠基础。第15章将对需求验证作进一步的讨论。

审查需求文档

对需求文档进行正式审查是保证软件质量的有效手段之一。应由代表不同群体（如分析员、客户、开发人员和测试人员）的审查员组成审查小组，对SRS、分析模型和相关信息进行仔细检查，找出其中的缺陷和漏洞。在需求开发的过程中进行初步的评审也是大有裨益的。虽然需求审查并不是最容易实现的新实践之一，但却是最有价值的，因此立刻开始进行需求审查吧。

测试需求

应根据用户需求摊导出功能测试用例，以便记录产品在特定条件下应有的行为。与客户一起对用例进行走查，以确保他们反映了所期望的系统行为。从测试用例追溯到功能需求，以确保没有忽略任何需求，而且每项需求都有其对应的测试用例。可用测试用例来验证分析模型和原型的正确性。

定义合格标准

让用户描述决定产品是否满足他们的需求并适合使用的标准。以使用情况为基础进行合格性测试（Hsia、Kung和Scll 1997）。

3.6 需求管理

一旦有了项目的初步需求，就必须处理好开发过程中不可避免的来自客户、管理层、营销部门、开发团队以及其他群体的变更请求。要进行有效的变更管理，必须建立一个过程，用于提请变更、评估变更的可能成本和对项目的影响。变更控制委员会（ChangeControl Board，简称CCB）由主要涉众组成，负责决定接受哪些需求变更。通过跟踪每项需求在开发和系统测试过程中的状态就能洞察整个项目的状态。

建立良好的配置管理方法是进行有效需求管理的前提。用来控制基本代码的控制工具也可以管理需求文档。需求管理所涉及的技术将在第18章～第21章中详细介绍。

定义需求变更控制过程

建立一个用于提议、分析和解决需求变更的过程。通过这个过程管理所有提议的变更。商业化的问题跟踪工具可支持变更控制过程。

成立变更控制委员会

可授权由涉众组成的小组作为变更控制委员会（CCB）来接收需求变更的请求，对它们进行评估，决定接受或拒绝，并设置实现的优先顺序或者在哪个版本中实现。

分析需求变更的影响

对影响进行分析有助于CCB做出明智的业务决策。应该评估被提出的每项需求变更，从而确定它对项目的影响。可参照需求跟踪矩阵找出其他可能需要修改的需求、设计元素、源代码和测试用例。应确定实现变更需要完成的任务，并评估完成这些任务所需要的工作量。

建立基线和控制需求文档的版本

基线是由已经被提交到一个指定版本中的实现（implementation）的需求组成的。在需求被定为基线后，只能通过定义的变更控制过程来实现变更。应该给每个版本的需求规恪说明指定一个惟一的标识，以避免需求草案与基线之间以及新旧版本之间的混淆。一种更好的方法是使用合适的配置管理工具，将需求文档置于版本控制之下。

维护需求变更的历史记录

记录需求规格说明变更的日期、变更的内容、变更的实施者和原因。版本控制工具或商业需求管理工具可以自动完成这些任务。

跟踪每项需求的状态

建立一个数据库，为每一项功能需求倮存一条记录。保存每项需求的重要属性，包括需求的状态（例如已提议、已批准、已实现或已验证），这样在任何时候都能掌握每个状态类的需求数量。

衡量需求的稳定性

记录已设为基线的需求数，以及每周提议和批准的需求的变更（增加，修改，删除）数。过多的需求变更是一个“报警信号”，意味着问题并未真正弄清楚，项目范围没有明确定义，业务规则变化过快，需求获取过程中漏掉了很多需求，或政策变化太快。

使用需求管理工具

商业需求管理工具可用于在数据库中存储各种类型的需求。可以为每项需求定义属性，跟踪每项需求的状态，并在需求和其他软件开发产品间建立跟踪链。这项方法能够帮助你实现本节中介绍的其他需求管理任务的自动化。

创建需求跟踪矩阵

建立一个表，把每项功能需求和实现它的设计和代码部分、验证它的测试部分联系起来。需求跟踪矩阵还能把功能需求和产生它的高层需求以及其他相关的需求联系起来。应该在开发过程中就建立这个矩阵，而不要等到工程结束。

3.7 项目管理

软件项目管理方法和项目的需求过程密切相关。应根据需要实现的需求来规划项目资源、进度和承诺。需求变更会影响到这些项目计划，因此项目计划应该预先为需求变更和范围扩大作一些准备（WiegCrs 2o02d）。关于需求工程的项目管理方法，更多内容可参考以下章节：

·第17章

·第18章

·第23章

选择合适的软件开发生命周期

组织应该定义多种开发生命周期，以适应不同的项目类型和不同程度的需求不确定性（McConncl1 1996）°项目经理应该选择和采用最适合他的项目的开发周期。生命周期的定义中应包括需求工程的活动。如果在项目的早期几乎没有充分定义需求或范围，应计划以小规模增量方式开发产品，并且要在充分理解需求，具有强健、可修改的体系结构基础上进行开发。可能的话，可以实现一些特性集，这样你可以周期性发行产品的一部分，并可尽早将它交付给客户（Gilb 1998：Cockburn 2002）。

根据需求制订项目计划

当范园和详细的需求变得清楚时，应反复斟酌项日的计划和进度表。通过评估所需的投入，根据最初产品前景和项目范围开始开发功能需求。过早地以尚不明确的需求为基础进行开销和进度评估是非常不可靠的，但是当您对需求的理解加深时可以再来改进你的评估。

需求变更时重新讨论项目承诺

当你将新的需求合并到项目中时，应估计一下你是否仍然可以利用可用资源兑现当前的进度和质量承诺。如果不能，将项目的实际情况报告给管理层，协商制定新的、可行的承诺（Humphrey 199⒎Fishcr、Ury和Patton 1991；Widgcrs 2002b）。如杲没有协商成功，应及时与管理者和客户交流可能的结果，这样他们就不会被意想不到的项目结果搞得晕头转向了。

管理与需求相关的风险以及编写风险文档

确定与需求相关的风险并将它们编写成文档是项目风险管理活动的一部分。可组织自由讨论，找到方法来减轻或避免这些风险、实施减小风险的活动，以及跟踪它们的过程和效果。

跟踪需求工程的投入

记录下你的团队在需求开发和管理活动上投入的工作量。使用这些数据来评定计划的需求活动是否如期完成，利用这些数据还可以为将来的项目更好地计划所需的资源。另外，监视需求工程活动对项目的影响，这将有助于评估对需求工程的投资的回报。

从其他项目的需求工程中积累经验

组建一个学术研究组织专门管理项目回顾（也称为项目的审阋）以收集有价值的信息。研究这些过去项目的有价值的需求和方法，可以帮助项目管理层和需求分析人员在以后的工作中更加充满信心，得心应手。

3.8 开始新实践

表3-2将本章中描述的需求工程方法，按照它们对大多数项目的相对影响以及实现的相对难度进行分组。虽然所有的方法都是有益的，但你最好从那些对项目的成功有很大影响并且相对容易实现的方法开始。

不要试图在下一个项目中使用所有这些方法，而是考虑将这些推荐方法作为您的需求工具包中新的成员。例如无论项目处于开发周期中的哪个阶段，都可以利用诸如处理变更管理等成功方法。当开始下一个项目或迭代时，收集方法是非常有用的。其他实践仍然可能不适

合你当前的项目、公司文化或资源可用性。第22章描述了评估你的当前需求工程方法的方法。它还将帮助你以本章描述的方法为基础设计流程图，以实现需求过程中某些需求改进。

3.9 需求开发过程

不要期望可以线性地、顺序地完成获取、分析、编写规格说明和验证这些需求开发活动。实际上，这些活动是交叉的、递增的和反复的，如图3-l所示。当分析员和客户交流时，分析员将请教问题，聆听客户所言，观察他们的行为（需求获取）。然后处理这些信息以便理解它，将其加以分类，并将客户的要求和可能的软件需求联系起来（需求分析）。然后分析员将客户的要求和得到的需求编制成书面的文档和图解（编写规格说明）。接着，向客户代表确认所编写的文档是否正确和完整，并纠正其中的错误（需求验证）。这个反复的过程贯穿于整个需求开发过程。

图3-1需求开发是一个迭代的过程

由于软件开发项目和公司文化的多样性，需求开发没有一种单一的、公式化的方法。图3-2给出了一个可用子（或经过适当调整后）很多项目的需求开发过程框架。图中显示了质量控制反馈循环，以及以用例为基础的增量实现。其中的步骤通常按数字顺序执行，但严格来说这个过程并不是完全按顺序执行的。前7个步骤主要在项目的前期执行一次（虽然团队需要定期地重访优先级）。其他步骤在每次版本增补或迭代时都要执行。

图3-2 推荐的需求开发过程

根据你和用户代表的接近程度，选择适当的需求获取方法（小组讨论，调查，交谈等），为获取需求可能需要的时间和资源作出计划。由于许多系统都采用增量开发模式，因此项目开发团队需要为用例或其他需求划分优先级（第7步）。设置用例优先级使你能够决定为每次增量安排实现哪些用例，这样就可以在适当的时候对所需的用例进行仔细研究。对子新系统或主要的改进，可以定义或改进体系结构（第14步），将功能需求分配到特定的子系统（第15步）。第12步和第17步是质量控制活动，它引领你重新回到一些前面的步骤以改正错误、改进分析模型、发现以前忽略的需求。第13步中建立的类型常常会导致对以前定义的需求的润色和修改。对需求的任一部分完成第17步时，就可以开始构建这部分了。对下一组用例（它们可能出现在下一个版本中）重复第8到17步。

下一步

●回到第1章的下一步中确定的与需求相关的问题。为你确认的每个问题在本章中找到可能有用的推荐方法。可参考附录C中的故障诊断指南。在你的组织中按影响程度将方法分成高、中、低三组。确定在你的组织或环境下实现每个方法的困难或障碍。了解谁能帮助你克服这些障碍？

●确定如何评估从那些你认为最有价值的方法中得到的好处。你会发现以店的策略中需求的缺点更少了，不必要的重复工作减少了，并且更能适应项目进度表。

·列出第一步中确定的所有需求推荐方法。对每一个方法，给出你的项目团队目前的能力水平：专家，熟练，新手或不熟悉。如果你的团队在任何方法中都没有到达精通级，则要求项目中的某些成员仔细地研究这个方法，并将他的学习心得和团队中的共他人分享。