需求工程中六个最重要的最佳实践 - modernanalyst

需求工程中六个最重要的最佳实践 - modernanalyst
我和Joy Beatty合著的《软件需求》一书的第三版，大约有24.5万字，将近640页，字体相当小。也许这看起来有点矫枉过正，但公平地说，需求领域是庞大而复杂的。

像Suzanne和James Robertson的《软件需求》、《掌握需求过程》以及IIBA的《商业分析知识体系》这样的书，描述了几十种有价值的需求征询、分析、规范、验证和管理的技术。当你在适当的情况下深思熟虑地应用它们时，它们都是有用的。但是，如果你没有时间去阅读这些大部头，你可能会喜欢这个TL;DR版本的六个最重要的需求实践，每个项目团队都应该执行。

实践1：定义业务目标
组织开展一个项目是为了解决一个问题，利用一个商业机会，或者创造一个新的市场。定义项目的商业目标可以向所有参与者和其他利益相关者传达他们为什么要在这个项目上工作。组织可以希望通过新产品实现财务和非财务的商业目标。尝试量化业务目标，并使其可衡量，如以下陈述。

• 在Y个月内获得X%的市场份额。
• 在Z个月内达到X单位的销售量或Y美元的收入。
• 每年节省X美元，目前花在一个高维护的遗留系统上。

使用业务目标可以使团队的所有工作和关键决策保持一致。如果没有明确的业务目标，你就不能制定一个明确的产品愿景声明，也不能确定整个项目或任何开发增量的范围。除非团队知道这些变化是如何与业务目标相匹配的，否则他们无法对范围变化或建议的功能做出正确的决定。保持重点范围有助于团队避免范围蠕变，同时还能适应不断变化的商业现实。除非有人事先定义了可衡量的业务目标和成功标准，否则你怎么能知道这个项目是否成功呢？

做法二：了解用户需要用产品做什么
我强烈主张采取以使用为中心的方法进行需求开发和方案设计，而不是以功能或产品为中心的方法。了解用户需要执行的任务和他们想要实现的目标，可以让业务分析员（BA）得出开发人员必须实现的功能。当你专注于探索功能而不是用户目标时，很容易忽视一些必要的功能。也很容易包括那些看起来很酷但却不能帮助用户完成工作的功能。用例是保持这种以使用为中心的思维方式的有效技术。

寻求了解用户需要用产品做什么，意味着其他几个重要的BA活动，包括这些。

• 识别广泛的项目利益相关者
• 确定具有不同需求的用户类别的特征
• 识别个人作为每个用户类别的客户的声音（产品倡导者）。
• 选择适当的需求征询技术来与用户接触
• 建立决策过程，以解决不同用户类别之间的冲突和优先权。
• 建立和评估原型或早期版本，以激发用户反馈。

做法三：确定需求的优先次序
我怀疑任何项目都曾实现过所要求的每一点功能。即使你能实现所有的功能，你也不可能一下子就做到。你的目标是以最低的成本和最短的时间向你的客户提供最大的商业价值。实现这个目标要求你对需求进行优先排序，以便团队能够以最合适的顺序进行工作。

优先级包括考虑每个建议的需求对实现项目的商业目标有多大贡献。对需求进行优先排序，可以让团队决定在积压的工作项目中，由于时间和资源的限制，哪些要推迟或省略。有许多需求优先排序的技术，包括这些。

• 成对比较和等级排序
• MoSCoW
• 100美元测试

其中一些方法比其他方法要花费更多的精力，但这些方法也帮助项目经理或产品所有者做出更精细的选择。选择任何一种技术，让正确的利益相关者在整个项目中做出良好的商业决策，以避免在游戏后期出现疯狂的 "快速去界定阶段"。

做法四：探索非功能需求
人们在讨论需求时自然会关注产品的功能，但这些只是解决方案的一部分。非功能需求对用户的满意度和使用的适宜性有很大的贡献。当谈到非功能需求时，人们最常想到的是质量属性，有时称为"-效用"。这些产品特性包括可用性、可维护性、安全性、可靠性和其他许多特性。为了帮助设计者设计出最合适的解决方案，BAs需要讨论非功能需求作为需求征询的一部分。

开发人员不直接实现有关安全、可靠性、可移植性、安全性或其他特性的要求。相反，这些属性作为许多功能需求的起源，并驱动设计决策。表1指出了不同类型的质量属性可能会产生的技术信息类别。

做法#5：审查需求
你怎么知道你的需求是否准确？你怎么知道它们是否足够清楚，以便所有的团队成员知道该怎么做，其他的利益相关者知道对解决方案的期望是什么？无论你选择如何表示需求知识，它有时是模糊的，不完整的，或根本不正确的。

最有力的质量实践之一是对需求的同行评审。召集一些同事来审查文本需求和图表。不同的项目参与者--BAs、设计师、开发人员、测试人员、用户--会在这些审查中发现不同类型的问题。需求审查带来了一些特殊的挑战。与其简单地邀请人们查看需求，不如提供一些培训，使审查者知道如何有效地参与，并能尽可能多地发现问题。

一个相关的需求验证实践是根据需求来写概念测试。测试需求是你可以在每个开发周期的早期做的事情，在它们被投进代码之前就能发现许多错误。需求和测试是对同一知识的互补性看法。需求描述了产品在特定条件下的行为；测试描述了如何判断它是否表现出正确的行为。

实践#6：计划需求的变化
无论你对问题的理解有多深，你对需求的准备有多仔细，它们都不会是完美的、完整的或静态的。在我们工作的过程中，我们周围的世界在变化。新的用户和新的想法出现。业务规则浮出水面并不断演变。项目的发展不可避免地超出了他们最初设想的范围。每个团队都必须预测需求的变化，并建立处理这些变化的机制，而不使团队的承诺脱轨。

当你知道项目的结果是不完整的，而且可能会有很大的变化时，渐进的、敏捷的方法是应对它的好方法。你计划在一系列的小块中建立需求--和解决方案，期待方向的改变，并接受你最后会有什么以及什么时候会有的不确定性。

当可能的变化程度不那么极端时，计划通过在开发计划中建立应急缓冲，以适应一些增长（以及风险、不精确的估计和意外事件）。建立一个需求变更流程，这样正确的人就可以得到正确的信息，从而做出正确的商业决策，决定哪些建议的变更可以在最小的干扰下增加价值。但是，不要把对变化的期望作为吝啬需求思考的理由。过多的需求变化往往表明目标不明确，或者激发的方法不有效。

忽视这些做法会给你带来危险
当然，除了这六种方法，还有许多其他有价值的需求活动。然而，这些实践大大增加了你构建解决方案的机会，使之能有效地实现所需的商业结果。应用它们并不能保证任何BA、产品所有者或产品经理的成功。但是，忽视它们可能会确保失败。