本文翻译整理自《软件需求》（豆瓣评分8.8分）一书作者Karl Wiegers的一篇文章，作者在文中简明扼要地列举了影响项目成功的6个最重要的需求实践，基本上是将原书600多页的思想内容作了浓缩再浓缩，可以说把需求的要害关系剖析的非常清晰透彻，足见作者在该领域研究之深，感兴趣的同学不妨一读，看一下是否可以帮助到你？
序言
作者有时会使事情变得毫无必要的冗长和复杂，有些读者可能因此会觉得我会感到内疚。我与Joy Beatty合著的《软件需求》一书的第三版大约仅25万字，有640页之多，而且字体又相当小，看起来这有些过分了，但公平的说，需求领域本身又大又复杂。
Suzanne 和 James Robertson 的Software Requirements（软件需求）、Mastering the Requirements Process（掌握需求过程）以及 IIBA 的Business Analysis Body of Knowledge（业务分析知识体系）等书籍描述了数十种有价值的需求获取、分析、规范、验证和管理技术。当在适当的情况下深思熟虑地应用它们时，它们都是有用的。但是，如果您没有足够时间涉猎这些“鸿篇巨著”，则很可能会比较喜欢这篇“短小精悍”之作－－每个项目团队都应该执行的六个最重要的需求实践。
实践1：定义业务目标组织开展项目以解决问题、利用商机或开拓新的市场。明确定义项目的业务目标可以向所有参与者和其他利益相关者传达他们从事该项目的原因。该组织可能希望通过开发新产品来实现财务或非财务业务目标。要尝试将业务目标量化，并使其可衡量，比如使用如下陈述：
- 在Y个月内占领X%的市场份额
- 在Z个月内达到X单位的销售量或Y元的收入
- 节省每年花在对遗留系统维护上的X元
利用业务目标可以让团队的所有工作和关键决策保持一致。如果没有明确的业务目标，就无法制定出清晰的产品愿景，无法确定整个项目或每个开发增量的范围。除非团队知道这些变更如何与业务目标相匹配，否则他们就无法对范围更改或提议的功能特性做出正确的决策。保持对范围的关注，有助于团队在避免范围蔓延的同时能够适应业务的变化。
另外，除非有人预先定义了可衡量的业务目标和完成标准，否则怎么才能知道项目是否成功了呢？
译评：
组织利用项目发展事业，项目需要明确业务目标，业务目标凝聚参与者和干系人，业务目标让工作内容和关键决策协同一致，业务目标让产品愿景清晰，业务目标让范围变更有章可循，业务目标让团队适应业务变化，可衡量的业务目标和完成标准让项目成功与否的判断成为可能。
我强烈主张在需求开发和解决方案设计中采用以使用为中心的方法，而不是以功能或产品为中心的方法。了解用户需要执行的任务和他们想要实现的目标可以让业务分析师 (BA) 推导出开发人员必须实现的功能。当您专注于探索功能而不是用户目标时，很容易忽略一些必要的功能。包含看起来很酷但无助于用户完成工作的功能也很容易。而用例是维持这种以使用为中心的思维方式的有效技术。
寻求了解用户需要对产品做什么意味着其他一些重要的 BA 活动，包括：
- 最大可能识别项目利益干系人
- 识别在需求上有较大差异的不同用户类别
- 确定每个用户群的个人代表
- 选择适当的需求获取技术与用户互动
- 建立决策流程以解决用户类别之间的冲突和优先级
- 构建和评估原型或早期版本以激发用户反馈
译评：
需求探索应以使用而非功能为中心，用户目标和任务本身可以推导出功能。
以功能为中心可能会忽略必要的功能，或者做出好看而不实用的功能。
用例方法是以使用为中心的有效技术。
业务分析活动主要包括：① 识别所有利益干系人；② 从需求诉求角度识别不同的用户群；③ 找出每个用户群的个人代表；④ 以适当的形式与用户互动，来获取需求；⑤ 建立解决需求冲突和排定优先级的决策机制；⑥ 利用原型尽早获得用户反馈
我怀疑没有项目实现过需求描述的每一个功能。即使可以全部实现，也不能一次都完成。我们的目标通常是以最低的成本和最短的时间为客户提供最大的商业价值。而实现这一目标就要求考虑需求的优先级，以便团队能够以最合适的顺序处理它们。
考虑优先级，意味着要考虑需求的每个提议对实现项目业务目标的贡献程度。由于时间和资源的限制，对需求进行优先级排序可以让团队决定推迟或省略哪些待办事项。
有许多可用的需求优先级技术，包括：
- 进出（In or Out）
- 成对比较和排序（Pairwise comparison and rank ordering）
- 三级量表（Three-level scale）
- 莫斯科（MoSCoW）
- 相对权重（Relative weighting）
- 100 美元的测试（$100 test）
其中一些方法比其他方法需要更多的努力，但这些方法也有助于项目经理或产品负责人做出更细粒度的选择。选择任何能让正确的利益相关者在整个项目中做出良好业务决策的技术，以避免在游戏后期出现疯狂的“快速描述阶段”。
译评：
软件项目的目标通常是以最低成本和最短时间为客户提供最大的商业价值，基于这一目标就涉及到需求的优先级排序，即主要考虑需求的每个提议对实现项目目标的贡献程度，以便团队以最合适的顺序处理它们，包括推迟或省略。
MoSCoW排序法是将目标分类为：“必须具有(Must have)”、“应该具有(Should have)”、“可以具有(Could have)”和“想具有(Would like to have)”的。有些专家建议“W”代表“不会有(Won’t have)”。
人们在谈论需求时，会自然地关注产品的功能，但它只是整个解决方案的一部分。实际上，非功能性需求对用户满意度和使用适用性有着很大的贡献。当谈到非功能性需求时，人们最常想到的就是质量属性，有时也称为“-ilities”。这些产品特性包括可用性、可维护性、安全性、可靠性和防护性等等。为了帮助设计人员设计出最合适的解决方案，BA 需要将非功能性需求作为需求获取的一部分进行讨论。
开发人员不直接实现有关安全性、可靠性、可移植性、防护性或其他特性的要求。相反，这些属性是许多功能需求的来源并推动着设计决策。
下表指出了不同类型的质量属性可能产生的技术信息类别。在左栏中列出了几个质量属性，在右栏中，指示该属性是否可能导致功能需求、系统架构选择、设计约束、设计指南或实施约束。
|
质量属性 |
可能的技术信息类别 |
|
可安装性、完整性、互操作性、可靠性、健壮性、安全性、防护性、易用性、可验证性 |
功能需求 |
|
易用性、有效性、可修改性、性能、可靠性、可扩展性 |
系统架构 |
|
互操作性、安全性、易用性 |
设计约束 |
|
有效性、可修改性、可移植性、可靠性、可重用性、可扩展性、可验证性、易用性 |
设计原则 |
|
可移植性 |
实施约束 |
另一个挑战是不可能一次优化所有所需的质量因素。设计人员必须在各种属性之间做出权衡决定。因此，团队需要确定哪些对客户成功最重要并对其进行优化。仔细指定质量属性可以让您构建让用户满意的产品，而不仅仅是做它应该做的事情。
译评：
非功能性需求是解决方案重要的组成，对易用性和用户满意度有较大的贡献。
非功能性需求可能会衍生出功能性需求、系统架构、设计约束、设计原则和实施约束等技术信息。
非功能性需求的各种属性之间相互影响，设计人员必须进行权衡，优先实现那些对客户成功最重要的属性，从而构建让用户满意的产品。
你怎么知道你的要求是否准确？您如何判断它们是否足够清晰，以便所有团队成员都知道如何处理他们，而其他利益相关者也知道解决方案中的预期内容？无论您选择如何表示需求知识，它有时都是模棱两可的、不完整的或根本不正确的。
可用的最强大的质量实践之一是需求的同行评审。召集一些同事审查文本要求和图表。不同的项目参与者——BA、设计师、开发人员、测试人员、用户——在这些审查中会发现不同类型的问题。需求审查提出了一些特殊的挑战。与其简单地邀请人们查看需求，还不如提供一些培训，让审阅者知道如何有效参与并尽可能多地发现问题。
一个相关的需求验证实践是基于需求编写概念性测试。测试需求是您可以在每个开发周期的早期执行的操作，以便在将许多错误转换为代码之前揭示它们。需求和测试是相同知识的互补视图。需求描述了产品在特定条件下应该如何表现；测试描述了如何判断它是否表现出正确的行为。
译评：
需求需要准确和清晰地传达给团队成员和利益相关人，而需求表述总是存在模棱两可、不完整或错误的可能。因此，需要通过类似同行评审这样的方法来审查需求，确保需求的质量。
需求审查需要通过培训等方式，让审阅者知道如何有效参与，并尽可能地发现问题，避免评审流于形式。
通过在项目早期进行对需求的概念性测试，可以更早地发现方案中的错误。
无论您对问题的理解程度如何，以及您准备需求的程度如何，它们都不会是完美的、完整的或静态的。当我们工作时，我们周围的世界会发生变化，新用户和新想法出现，业务规则浮出水面并不断发展，项目不可避免地会超出其最初设想的范围。每个团队都必须预测需求变化并建立处理它们的机制，而不会破坏团队的承诺。
当您知道项目结果未完全定义并且可能会发生很大变化时，增量、敏捷的方法是应对它的好方法。您计划以一系列小块构建需求和解决方案，期望方向会发生变化，并接受您最终将拥有什么以及何时拥有它的不确定性。
当可能的变化程度不那么极端时，计划通过在开发计划中建立应急缓冲来适应一些增长（以及风险、不精确的估计和意外事件）。建立一个需求变更流程，以便正确的人员能够获得正确的信息，从而做出正确的业务决策，确定要合并哪些提议的变更以在最小的干扰下增加价值。但是，不要将期望的变化作为忽略需求思考的理由，过多的需求流失通常表明目标不明确或启发方法无效。
译评：
需求的变化几乎是必然的，项目不可避免地会超出其最初设想的范围。所以，团队必须预测需求变化，并建立相关处理机制，以避免违反承诺。
需求越是不明确的时候，越可以通过增量、敏捷等方法应对，通过小步前进来应对和接受需求在内容和时间上的不确定性。
而当预期的变化程度没那么强烈时，可以在项目计划中增加缓冲来适应诸如风险、工作量估算误差和意外事件等。
当然，一个需求变更的流程也是必不可少，它可以让正确的人在正确的时候获得正确的信息，从而做出正确的决策。变更合并的主要考量就是在最小的干扰下增加更多的价值。
还要注意不要因为需求可能要变化而在需求探索时忽略必要的思考，太多后期加入的需求可能意味着业务目标不明确或需求启发的方法存在问题。
当然，除了这六项之外，还有很多其他有价值的需求活动。但是，这些实践大大增加了您构建解决方案的机会，该解决方案能够有效地实现预期的业务成果。应用它们并不能保证任何 BA、产品所有者或产品经理都能成功，但忽视它们可能会导致失败。
