3 需求工程优秀实践

3.1需求开发过程框架

需求工程包括获取、分析、规范说明和验证。但不能只是简单以一种一次性线性顺序来实施这些实践。实际上，这些活动是相互交织、渐进的和迭代式的，如下图所示。

“逐步完善细节”是实施中的一个关键术语，指的是从一些原始的需求想法向更精确的理解和表述演进。
如果你是一名业务分析师，你会向客户提问，听他们的回答，观察他们的行为（获取）。你会处理这些信息并加以理解，还会将它们归入不同的类别，并且将客户的实际需要与可能的软件需求联系起来（分析）。在分析过程中，你可能会意识到自己需要澄清一些需求，所以需要回过头做更多获取活动。然后重新组织用户输入，整理需求，写下需求说明或图表（规范说明）。在记录需求的时候，也许需要回过头再做一些分析以填补认知上的缺口。接下来，还要征求干系人的意见，以便确认你所捕获的内容是准确和完整的，并修正可能的错误（验证）。要对需求中最重要的、需要最先开发的部分做所有上述工作。验证步骤让你重写部分不清晰的需求，回顾某些分析活动，甚至回过头再增加一些需求获取活动。然后，就可以继续项目中余下的部分，把所有这些再重复一次。这个迭代的过程贯穿整个需求工程始终，在敏捷项目中甚至是贯穿整个项目周期。
由于软件开发项目以及公司文化千差万别，所以需求开发工程并没有一个单一的、公式化的套路。下图显示的是一个需求开发工程的流程框架，经过适当调整，可以应用于很多项目。业务需要或是市场机遇是下图所示流程的源头。

这些步骤通常可以大致按照序号逐步实施，但这个流程并不是严格按照顺序进行的。前七个步骤通常在项目前期实行（虽然团队需要周期性地回顾这些活动）。剩下的步骤在每次发布或开发迭代中通常都要做。这些活动很多都可以迭代实施，并且可以交替进行。例如，可以小步实施步骤8，9，10，在每次迭代后进行一次评审（步骤12）。
需求工程的第5个子原则是需求管理。需求管理所包含的实践能够帮助处理手头上已有的需求。这些实践包括版本管理以及建立基线、变更控制、跟踪需求状态以及跟踪对其它系统元素的依赖。需求管理贯穿项目的始终，不过总的工作量并不是很大。
下图3-3展示的是一些常见的软件开发生命周期模型如何将需求工作量分配到各个产品开发阶段。在不同的生命周期模型中，规模相似的项目需花费的需求工作量可能差别不大。但是需求工作量的时间分布可能很不相同。在纯瀑布模型中，都只规划一次发布，所以大多数需求开发工作都安排在项目开始的一段时间里（图3-3中的实践）。相当多的项目仍然在使用这种方式，有些也比较合适。不过，即使在项目初期就规划传统的“需求阶段”，然后再进入设计阶段，也需要在整个项目过程中再加入一些额外的需求处理工作。
如果项目采用迭代式开发过程，例如Rational统一过程，就需要在整个开发过程中的每个迭代都做需求方面的工作，但第一个迭代做得多一些（图3-3中的虚线）。这种方式也适用于计划分多个阶段发布的项目，这种项目每次发布最终产品功能的一个重要子集。
敏捷以及其他增量式开发项目的目标是每隔几周就发布一些功能。他们的需求开发任务更频繁，但每次工作量很小，如图3-3中的虚线所示。这种项目首先用简单用户故事的形式描述用户希望通过系统完成哪些任务。如果采用此方式，必须对故事有很深的理解才能估算它们的开发工作量并对其进行优先级排序。通过对这些用户需求排序，能判断出在具体开发增量（所谓的迭代或者冲刺）中要分配哪些需求。我们可以在每个开发周期中再对这些分配好的需求进行更细致的探究。这些排好的需求可以在每个开发周期中用及时生产（Just-in-time）的方式深入研究。

无论项目采用何种生命周期模型，都应该做到心中有数，在每个发布或迭代中，表3-2中哪些活动能够增加价值并降低风险。不管是哪部分需求，只要完成上面的17步，就可以开工构建这部分的系统。针对余下部分的用户需求，重复第8步至第17步，为接下来的发布或增量打下来的发布或增量打下坚实的基础。

3.2优秀实践：需求获取活动

需求的三个级别：业务、用户以及功能。它们来自不同的源头以及项目的不同阶段，有不同的受众和目的，记录方式各异。还需要获取非功能需求，例如不同维度的质量期望值。以下这些实践能够帮助各式各样的需求信息。

• 定义产品愿景和项目范围
  愿景和范围文档包含产品的业务需求。愿景描述可以使所有干系人对产品的产出有一致的理解。范围界定了发布或者迭代中哪些功能（或不应该）出现。愿景与范围提供了一种参考，方便对大家所提议的需求进行评估。愿景在整个项目过程中相对稳定的，每个计划的发布或迭代都有自己的范围。
• 识别用户类型及其特征
  为了避免遗漏任何用户团体的需要，我们要为产品识别出不同的用户组。在使用频率、所用特性、权限级别以及经验方面，这些组别可能不同。记下他们的工作任务、态度、位置或者个性，这些都可能影响产品设计。建立用户角色——也就是一种虚拟任务——来代表特定用户类型。
• 为每类用户选出用户代表
  为每类用户找出一个能精确传达用户心声的个人——产品用户代表。他提出用户组的需求，并代表用户组做决策。在内部信息系统的开发中，这是最容易做到的，因为你的用户就是你的同事。对于商业产品的开发，则要按照你与大客户的现有关系或者是beta测试网站来锁定合适的产品用户代表。
• 安排由典型用户组成的焦点小组
  将以前产品或类似产品的用户代表组成小组。收集他们期望有的产品功能及质量。焦点小组对商业产品尤其重要，因为你可能要面对数量巨大且形形色色的客户。与产品用户代表不同，焦点小组通常没有决策权。
• 与用户代表协同发现用户需求
  要与用户代表共同探讨他们需要用软件完成什么任务以及他们希望获得哪些价值。用户需求的表达方式包括用例、用户故事或场景。讨论内容还包括用户与能使其完成各项任务的系统之间的互动关系。
• 识别系统事件和反应
  列出系统可能经历的外部事件及其对每个事件可能做出的反应。外部事件可以分为三类。信号事件是指控制信号或从外部硬件设备收到数据。时间或者时间相关事件会触发一个相应，例如系统每天晚上导出外部数据。业务事件在业务应用中触发用例。
• 举办获取访谈
  访谈可以是一对一的，也可以是和一小组干系人。这是一个获取需求的高效方式，可以避免占用干系人过多时间。因为你只跟每个人讨论他们很重要的需求。面谈十分有用，它可以分别启发出每个人的需求并且为讨论会做准备。在讨论会上大家在一起解决冲突。
• 举办并引导需求获取讨论会
  通过需求获取研讨会，分析师和客户能够精诚合作，高效地探索用户需求和起草需求文档。这样的讨论会有时称作“联合应用设计”（JAD）会议。
• 观察用户如何工作
  观察用户如何完成其任务目标，能够了解到一个新应用在这些用户中的潜在用途。简易的流程图可以描述出每个步骤以及所涉及的决策，并且展示不同用户组是如何交互的。如果能将业务流程图记录成文档，你就能识别出解决方案是否能够支持此流程的需求。
• 分发调查问卷
  调查问卷这种方式就是调查大量用户群并判断他们有哪些需要。如果用户群体比较大，就适合使用调查问卷，特别是用户群比较分散时，效果更好。如果问题设计得好，调查问卷可以帮助你快速获得关于需求的分析结果。这样一来，获取需求的其他工作量就可以按照调查问卷结果来确定。
• 分析文档
  现有的文档可以揭示系统目前如何运行或者人们期望它如何运行。文档中的书面信息涉及现有系统、业务流程、需求规格说明、对竞争对手的研究以及产品上架发行时的用户手册。检查并分析这些文档可以帮你发现什么功能需要保留，什么功能没有被用到，人们现在如何完成他们的工作，竞争对手提供什么功能，软件供应商如何描述产品功能。
• 检查现有系统在需求方面的问题报告
  从用户那里获取问题报告和改进请求为我们提供了丰富的候选项，我们可以将这些新增需求或改进纳入下一发布或新产品之中。客户支持或售后服务可以为未来开发工作提供很多有价值的需求。
• 重用现有需求
  如果客户所要的功能跟现有系统中已经提供的功能类似，就要看需求（以及客户）是否能够变通，允许重用或者改写已有组件。例如符合组织业务规则的安全需求或者符合政府法规的可访问性需求，就经常可以重用。另一些可以重用的东西包括词汇表、数据规模和定义、干系人信息、用户类型描述以及用户角色。

3.3优秀实践：需求分析

需求分析包括需求的精炼，使所有干系人都能够理解并检查出错误、遗漏以及其他缺陷。分析还包括将概要需求分解成更细、粒度层次更合适的需求，建立原型，评估可行性以及协商优先级。其目标使产出符合质量和精确性要求的需求，这样，项目经理就可以提供合理的项目计划，技术人员也可以进行下一步的设计、构建以及测试。
将某些需求用多种方式表达出来具有非凡的意义。例如，同时使用文字和图形，或者同时使用需求描述以及测试。这些不同的视角所展现出来的见解和问题是单一视角无法提供的。多视角同样可以使所有干系人达成共识（共享愿景），知道产品交付之后能拥有什么东西。

• 为应用环境建模
  系统环境关系图是一种简单的分析模型，展示的是新系统如何适应其环境。它定义了开发中的系统与外部实体（例如用户、硬件设置或其他系统）之间的界限以及接口。生态环境图展示了解决方案中的各个系统如何相互作用及其相互关系的本质。
• 创建用户界面以及技术原型
  当开发人员或用户对需求不太确定时，需要创建一个原型：一个部分的、可能的或者初步实现的模型，目的是使概念及各种可能性更真实一些。原型可以让开发人员以及用户对所解决的问题达成共识并有助于验证需求。
• 分析需求可实现性
  业务分析师应当与开发人员协同工作，评估在成本可接受范围内每个需求实现的可能性及其在设定环境下的效果。这样可以让干系人了解实现每个需求可能存在的风险，包括不同需求之间的冲突或相互依赖、对外部因素的依赖以及技术上的障碍。我们可以对技术上不可行或实现成本过于高昂的需求进行精简，不过仍然可以实现项目的业务目标。
• 需求按优先级排序
  需求按优先级排序可以保证团队首先实现价值最高或者最具有时效性的功能。用分析的方法判断实现产品特性、用例、用户故事或功能需求的优先级，根据优先级，决定每个特性或者设定的需求应当归入哪些发布或者增量之中，在整个项目过程中，根据新需求的出现、客户的需要、市场情况以及业务目标的演进，不断调整优先级。
• 建立数据字典
  把与系统相关的、对数据内容和结构的定义存储在数据字典之中。这样能够保证项目中的每个人都使用一致的数据定义。随着需求的开发，数据字典应收录问题领域内的数据内容，以促进客户与开发团队之间的交流。
• 为需求建模
  图表是一种分析模型，与文本方式的功能需求列表不同，它可以将需求可视化。模型可以揭示出错误的、不一致的、缺失的或是冗余的需求。这样的模型包括数据流图、实体关系图、状态转移表、状态表、会话图和决策树等。
• 分析系统与外部世界之间的关联
  所有的软件系统都通过外部接口与外部世界联通。信息系统有用户界面，并常常与其他软件系统交换数据。嵌入式系统中软件与硬件组件之间会相互关联。与网络相关的应用会有通信接口。对上述内容进行分析可以确保应用顺利融入环境。
• 将需求分配给子系统
  一个包含多个子系统的复杂产品，我们必须将其需求分派到各个软件、硬件以及人工子系统和组件。

3.4优秀实践：需求规范说明

需求规范说明的精髓就在于用一致的、可存取、可评审的方式记录不同类型的需求，且目标读者都理解这些规则。可以在一个愿景和范围文档中记录业务需求。用户需求通常表现为用例或用户故事的形式。
详细的软件功能和非功能需求都被记录在软件需求规范说明或者其他替代品之中，例如需求管理工具中。

• 使用需求文档模板
  模板所提供的标准结构可以用来记录与需求相关的各类信息。即使不用传统的文档形式存储需求，模板也能提醒你还有各类的需求信息有待发掘和记录。
• 明确需求来源
  为了让所有干系人了解每个需求存在的合理性，就需要对其进行追根溯源。它可能来自用例或其他一些用户的输入（一个概要的系统需求）或是业务规则。通过记录需求所影响到的干系人，你可以知道在有变更请求时应该该联系谁。需求来源可以用一个可跟踪的链接标示或者定义一个需求属性来做跟踪。
• 每个需求一个唯一标识
  可以制定一个规则，用于给每个需求打上独立的标签。这个规则必须足够健壮，能够经得起时间的考验，允许对需求增加、删除和变更。标识需求使需求具有可跟踪性，并能记录变更。
• 记录业务规则
  业务规则包括公司政策、政府法规、标准和算法。要将业务规则从项目需求中独立出来记录，因为其生存周期通常比具体项目更长。也就是说，将业务规则视为企业级资产，而不是项目级资产。有些规则会引申出功能需求，反过来又会强化这些规则，所以定义这些需求及其对应的规则之间的链接关系。
• 记录非功能需求
  可能出现这样一种情况：解决方案虽然完全按照人们当初的设想工作，但无法满足用户的质量期望。为了避免这种情况，思维必须跳出功能的局限，这样才能理解对成功至关重要的质量特性。这些特性包括性能、可靠性、易用性、可修改性等。客户提供这些质量属性的相对优先级使开发人员做出正确的设计决策。同样，要记录外部接口需求、设计和实现上的约束、国际化方面的考虑及其他的非功能需求。

3.5优秀实践：需求验证

验证能够保证需求的正确性、展示期望的质量特性并满足用户需要。
有些需求读起来似乎没什么问题，但当开发人员着手工作时又会遇到模棱两可或遗漏的地方。要想需求成为设计、最终的系统测试及用户验收测试的可靠基础，就必须修正这些问题。

• 需求评审
  需求的同行审查，特别是称为“审查”的严格评审，是一种高回报的质量保证实践。
  组织一个小的评审团，让他们从不同视角（分析师、客户、开发人员、测试人员）仔细审查需求文档、分析模型以及相关的缺陷信息。需求开发初期的非正式评审也很有价值。训练团队成员高效地评审需求并在组织中采用评审流程是非常重要的。
• 测试需求
  测试为需求提供了另一个视角。写测试也就是要你考虑如何证明系统是否正确实现预期功能。我们从用户需求中设计测试，就是想记录特定情况下产品的预期行为。和客户一起审查测试，确保它们反映了用户的真实期望。将测试与功能需求对应起来，确保没有需求被遗漏，并且每个需求都有对应的测试。测试还可以用于验证分析模型与原型的正确性。在敏捷项目中，我们通常用验收测试来代替具体的功能需求。
• 定义验收标准
  让用户自己说出如何判断解决方案是否满足自己的需要以及是否可用。验收标准包含一系列活动，例如：根据用户需求，软件通过一系列验收测试；软件能展示出它具备满足特定非功能需求的能力；对尚未修复的缺陷合为问题进行跟踪记录；发布前准备好基础设施与培训等。
• 模拟需求
  项目团队可以使用一些商业工具来模拟计划中的系统，代替或补充书面的需求规范说明书。模拟器是 原型系统的升级，它可以让业务分析师和用户迅速搭建一个可运行的系统模型。用户可以与模型系统交互来验证需求并做出设计决策，使需求在还没有进行代码实现之前就被赋予生命力。虽然模拟器并不能替代严谨的需求获取和分析活动，但它的确提供一个强大的补充。

3.6优秀实践：需求管理

一旦有最初始的需求，就必须做好准备应对变更，因为在整个开发阶段，客户、管理层、市场、开发团队或者其他人都会不可避免地提出这方面的要求。有效的变更管理包括提出变更、评估潜在成本及其对项目影响以及确保恰当的干系人可以判断要采纳哪些变更，并做出明智的业务决策。
拥有良好的配置管理实践是进行有效管理的一个前提条件。可以使用代码版本管理工具来管理需求文件。最好将需求放在需求管理工具中，里面提供的很多功能可以帮助你完成这些实践。

• 建立一个需求变更控制流程
  变更流程应当定义如何提出、分析和解决需求变更。所有提议的变更都通过这个流程来管理。缺陷跟踪工具可以支持这种变更控制流程。组建一个项目干系人小组来担任变更控制委员会，负责评估大家提出需求变更，决定采纳哪些，并为它们设置实施优先级或者目标发布。
• 对需求变更进行影响分析
  影响分析是变更流程的重要元素，他可以帮助变更控制委员会做出可靠的业务决策。评估提出的每个需求变更并确定它们对项目可能造成的影响。使用需求跟踪矩阵来发现其他可能需要修改的需求、设计元素、源代码以及测试。明确实现变更所需的任务并估算完成它们所需的工作量。
• 建立基线并控制需求集合版本
  基线定义的是大家都认可的一组需求，通常是一个特定发布或迭代内的需求。当需求基线确定后，如果要做变更，就只能通过项目变更控制流程。我们要赋予需求规范说明书的每个版本一个独特的标识，避免将草稿与基线或者旧版本与当前版本搞混。
• 维护需求变更的历史记录
  每做一次需求变更，就要留下一个历史记录。有时需要回退到需求的某个早期版本或者希望了解需求是如何变更现在这个形式的。记录需求变更的日期、变更的内容、谁做出的变更以及原因。版本控制工具或者需求管理工具都可以完成类似的功能。
• 跟踪每个需求的状态
  为每个影响产品实现方式的独立需求都建立一个记录。保存每个需求的关键属性，包括状态（例如提出、批准、实施或验证）。这样可以检测在任何时间点处于每个状态的需求个数。随着需求在开发和系统测试中的进行，要对每个需求进行跟踪，从而深刻洞察整体项目状态。
• 跟踪需求问题
  当大家都在忙于一个复杂的项目时。非常容易忽略很多问题，例如需求需要澄清、缺陷需要弥补以及需求评审中发现的问题需要解决。问题跟踪工具可以帮助我们避免遗漏问题。我们要为每个问题指定专门的负责人，监控需求问题的状态，以此来判断需求的整体状态。
• 维护一个需求可跟踪矩阵
  把每个功能需求与设计、实现它的代码以及验证它的测试相互联系起来，这样做通常很有价值。这样的需求跟踪矩阵有助于确认所有的需求都已经实现并且通过了验证。当维护期内需要修改时它也有帮助。需求可跟踪矩阵还可以将功能需求从其引申而来的高级需求、相关需求联系起来。在开发过程中同步建立这个矩阵，而不要等待开发结束后再开始。
• 使用需求管理工具
  商业版的需求管理工具可以在数据库中帮助存储各种类型的需求。在此工具可以帮助实现以及自动化很多本节所提到的需求管理实践。

3.7优秀实践：知识

在特定的项目中，不同团队成员都承担过业务分析师的角色，但软件相关人员很少受到过正规的需求工程训练。业务分析师是专业且有竞争力的角色，有其自身的知识体系。

• 训练业务分析师
  除了拥有一个强大的技术工具箱外，有经验的分析师都很有耐心、有条理，拥有高效的人际沟通技巧，并且了解业务领域。
• 帮助干系人理解需求
  参与软件开发的用户应当接受一到两天需求方面的培训，理解术语、关键概念和实践及其对项目成功的重要性。
• 帮助开发人员理解应用领域
  为了让开发人员对应用领域有一个基本的认识，我们可以组织一个研讨会介绍客户的业务活动、术语以及待建产品的目标。这样有助于减少以后工作中的困惑、误解以及可能的返工。“客户工作中的一天”体验活动就是一种不错的“投资”，期间开发人员全天陪同用户并观察其工作方式。项目开发期间也配置一个用户伙伴，帮助开发人员解释行业术语及业务概念。产品用户代表可以充当这一角色。
• 制定一个需求工程流程
  将组织所遵循的获取、分析、规范、验证以及管理需求的流程记录成文档。为如何完成其中的关键步骤提供指引，使分析师一直得心应手。这样的流程也有助于计划每个项目的需求开发和管理任务、时间表以及所需的资源。项目经理应当将需求活动作为一个独立的任务加入项目计划中。
• 建立词汇表
  词汇表，是应用领域中专业术语的一种汇总，它有助于消除误解。词汇表包括同义词、首字母缩写或简称，有多种含义的词汇以及在应用领域与平常生活中意义不同的词汇。词汇表可以成为一种可重用的企业级财富。定义词汇表的工作可以分配给团队新成员，因为他们最容易对陌生的术语感到困惑。

3.8优秀实践：项目管理

软件项目管理方法与项目需求流程紧密相关。项目经理应当根据需求规划项目时间表、资源以及作出的承诺。另一种策略是将开发周期纳入“时间盒”，即团队估算出他们在固定迭代时间内能够完成的工作范围。敏捷开发项目采用的就是这种方式。范围可以在计划时间范围内协商。这样一来，范围蔓延就成了“范围选择”，产品负责人可以按照其意愿提出要求，但必须为这些要求排定优先级，当团队开发时间耗尽时则停止开发。然后团队再为余下的需求制定下一个发布计划。

• 选择一个合适的软件开发生命周期
  组织应当根据不同的项目类型一级需求的不确定程度指定多种相应的开发生命周期。每个项目经理都应选择并采纳最适合其项目生命周期。将需求活动纳入生命周期。如果可能，就增量细化和开发功能集，力求尽早向客户交付有用的软件。
• 规划需求活动
  每个项目团队都应该计划如何进行需求开发和管理实践活动。需求获取活动计划可以保证你用最合适的技巧在恰当的项目阶段找到合适的干系人并从他们那里获得信息。业务分析师要与项目经理协同工作，确保与需求工程相关的任务以及可交付物都会出现在项目管理计划中。
• 估算需求工作量
  干系人一般都需要知道项目中需求开发阶段需要多长时间以及花在需求开发和管理上的工作量占总工作量的比例。当然，这取决于很多因素。考虑一下那些指标性的因素，它们能给你一个参考，告诉你需要花更多还是更少的时间确保需求能够成为开发可依赖的基础。
• 基于需求确定项目计划
  随着项目范围和需求细节逐渐清晰，以迭代方式制定计划和时间表。首先估算完成初始产品愿景和范围内的用户需求所需的工作量。早期基于模糊需求的成本和时间估计很不可靠，但随着对需求理解的加深，可以逐步修正估算。敏捷项目中，迭代是固定时间长度的，做计划就意味着不断调整范围，这样才符合固定的时间和资源约束。
• 识别需求决策人
  软件开发需要做很多决策。我们要解决用户需求的输入冲突，选择商业组件包，评估变更请求，等等。因为需求问题需要做大量的决策，所以项目团队需要找出决策者并给他授权，最好是在首次做出重大决策之前就要做到这一点。
• 当需求变化时重新协商项目承诺
  项目团队承诺在预定时间及预算内交付特定的需求集合。随着在项目中加入新的需求，需要重新评估基于现有资源是否仍然能够完成原来的承诺。如果不能，将项目的实际情况告知管理层，并且商定一个现实且可行的承诺。还有一种情况是，在开始阶段，需求理解不那么清晰，估算也处于初始阶段，而随着演化，需求会逐渐明晰并经过验证，这时就需要重新协商承诺了。
• 分析、记录以及管理与需求相关的风险
  如果项目准备不充分，突发事件和情况就可能对其造成灾难性破坏。作为项目风险管理活动的一部分，要识别并记录与需求相关的风险。我们要想办法降低甚至消除这些风险，实施能够降低风险的活动，记录活动进展和功效。
• 跟踪在需求上花费的工作量
  为了能在未来项目中提高对需求所耗资源估算的准确性，要记录团队在需求开发以及管理所花的工作量。监控需求实践对项目产生的影响，从而判断在需求工程方面的投资有多少回报。
• 借鉴其他项目中关于需求的经验教训
  学习型组织会定期组织回顾会，收集以往项目或当前项目早期迭代中的经验教训。

3.9开始新的实践

下表表3-2按照需求工程对大多数项目的相对价值与实施难度，对本章所述的需求工程优秀实践进行了分组。这些分组不是绝对的，可能与你的经验有出入。虽然所有的实践都有好处，但你可以从相对容易但对项目成功关系重大的实践开始尝试。
不要试图在新项目中一个不落地使用所有这些技巧。相反，要将这些优秀实践当作需求工具箱中的新工具。有些实践（例如变更管理）无论项目处于什么开发阶段都可以立刻投入使用。需求获取实践在开始下一个项目或迭代的时候采用最有效。也有一些实践可能不适合你现在的项目、组织文化或者资源配置。