掌握需求过程

掌握需求过程

后篇

---

第十章 功能需求

功能需求是产品为了支持工作而必须做的事情，它们的表述应该尽可能独立于实现需求的技术。作为业务分析师不要尝试打造技术方案，而是要指定技术解决方案必须做的事，如何实现结果是设计师的事情。场景中包含3-10个步骤给出合理的细节程度，又不会让非技术的利益相关者感觉太复杂。控制需求描述的细节程度或粒度，在需求描述中添加理由，在许多情况下，这是需求的关键部分。不论需求最终如何实现，写下描述和理由显然会引导发现真正的需求。
在编写需求时，不只要注意一词多义，如果产品的上下文不清楚，也会引起二义性。需求的层次结构，工作上下文范围是最高层次的需求说明，它分解为下一个层次即业务事件，业务事件下一层由产品用例组成，每个产品用例又被分解为一些产品用例步骤，最底层的需求包括原子需求，每项原子需求都可以追踪到高层的用例步骤。有场景、用户故事（作为[角色]，我想要[功能]，这样就能[使用该功能的理由]）、业务过程模型等多种方法来描述产品的功能。
功能需求描述了产品的处理动作，即为了支持业务而必须做的事，功能需求是产品功能描述，它应该是完整的，并尽量避免二义性。

---

第十一章 非功能需求

非功能需求描述产品将失去做到什么程度。把功能需求看成是使产品工作的需求，把非功能需求看成是为工作增加某些特征的需求。非功能需求描述了特征或功能完成的方式。非功能需求类型包括感官、易用性和人性化、执行、操作、可维护行性和支持、安全、文化和政策、法律等。

• 感官：产品的外观精神实质
• 易用性和人性化：产品的易用程度以及更好的用户体验所需的特殊可用性考虑
• 执行：功能的实现必须多快、多可靠、能完成多少处理量、可用性、精确性
• 操作：产品的操作环境，以及对该操作环境必须考虑的问题
• 可维护性和支持：预期的改变以及完成改变允许的时间，也包括对产品的支持的规定
• 安全：产品的安全性、私密性、完整性、可恢复性和可审计性。
• 文化和策略：由产品的操作所涉及的文化和习惯所带来的特殊需求
• 法律：哪些法律和标准适用于该产品

需求类型有助于发现需求的工具，可以将需求类型看作一份检查清单，将来会为每项需求加上验收标准，并使它可测试。我们可以通过用博客记录需求、用例、模板、原型、客户等来发现非功能需求。非功能需求也许看起来有些模糊，需要在写验收标准时，写下测量指标，量化每项需求的含义。

---

第十二章 验收标准和理由

验收意味着解决方案准确地实现了需求所要求做的事情，或具备需求所要求的属性。需求本身必须是可测量的，需求的测量指标就是验收标准，它量化了需求的行为、执行方式以及一些其他品质。
验收标准既不是测试，也不是对测试的设计，而是测试提交的产品时必须采用的测试基准。它是构建测试用例的输入信息，测试者通过测试用例来确保产品的每项需求都符合它的验收标准。验收标准是产品要执行的、无二义性的测试基准。通过检查需求描述和理由，确定哪种量化方式最能体现用户需求的意图，从而导出验收标准。

---

第十三章 质量关

质量关是检查每项需求并确保它合适的活动，对需求活动提供清晰、完整和无二义性的描述，说明要构建什么，所有的需求都必须经过质量关的确认。当规范的潜在需求到达质量关时，它应该足够完整，以便能进行测试，决定是否纳入规格说明书。被拒绝的需求退回给提出者，要求澄清、修改或取消。质量关防止不受欢迎、不想要的需求进入规格说明。
拒绝的需求：

• 超出范围：建立上下文模型来定义范围
• 不完整
• 不可追踪
• 不一致
• 无关
• 不正确
• 有二义
• 不可行
• 属于解决方案
• 镀金

质量关守关人的任务就是确保验收标准是合理的需求测量指标，即可以对照需求来测试产品。验收标准使用数据来表达需求，但数字本身必须不是主观确定的，要基于事实依据。验收标准可以采用事先定义的标准。安全需求可能也会采用标准作为验收标准，要么是特定行业的安全标准，要么是组织结构自己的安全标准。验收标准采用数字还是引用标准，取决于需求的类型，执行需求和可用性需求通常采用数字，而观感、安全和文化等需求大多采用标准。高价值的需求要沟通和谈判，低价值的需求要放弃。在“伙伴结对”中，需求分析师相互测试得到的需求。如果两个分析师懂得客观地对待彼此的工作，这种策略最有效。质量关对潜在的需求进行测试，评估标准如下：

• 完整性
• 可追踪行
• 一致性
• 相关性
• 正确性
• 二义性
• 可行性
• 是解决方案
• 镀金
• 蔓延

通过防止不正确的需求进入规格说明书，质量关降低了开发成本。因为尽早消除错误是开发产品最快、最省钱的方式。

---

第十四章 需求与迭代开发

一些开发技术如SCRUM、Crystal Clear、极限编程、看板等，这些技术的目的是迭代式地交付能工作的产品，迭代式地构建产品。分析业务需求是一项持续的活动，收集新的业务要求并对它们进行探讨、评估和排列优先级。大多数迭代过程通过用户故事来沟通，一组用户故事代表了下一个发行版需要的功能。用户故事是一种方式，它大致相当于产品用例（PUC）场景中的一个步骤，用户故事起源于极限编程，但现在已经被大多数迭代方法所接受。用户故事的常见形式是：最为[角色]，我想要[功能]，以便能实现[理由]。故事写下来，被加到开发列表中，为它们排列优先级，根据架构和开发的要求，当然还有业务的要求。这种优先级排列是连续的。
用户故事确定了产品要为用户做的事情，但它也必须关注业务用例所确定的业务问题，因此，BUC作为故事的起点，每个BUC通常导出一个或多个故事。BUC提供了业务指导，这样用户故事会支持业务，而不只是确定用户界面。好故事带来卓越的产品。
扩展用户故事设计一些领域专家的输入信息：业务、易用性、安全性、观感等非功能需求。业务是项目中最关键的部分，业务知识很重要。因为业务分析师既不属于业务，也不属于开发团队，所以业务分析师是业务知识的有用来源。技术知识体现为开发者、系统架构师、测试员、外部供应商等角色的某种组合。业务专家关注业务的运营以及他们的日常工作，技术专家投身于解决方案和追踪最新技术，他们的工作是完成项目和解决问题。
有了业务分析师和其他人给出的输入信息和解释，开发者写下最能满足业务要求的故事。开发者对开发列表中的用户故事排列优先级，针对选出的故事，扩展并决定产品下一个发行版要实现的原子需求。

---

第十五章 复用需求

在一个组织结构中，项目常常构建相同或类似的产品。需求复用指利用为其他项目写下的需求。有一下几种来源：规格说明书的复用库、相同领域的需求规格说明或来自其他人的经验。成功的复用始于一种组织文化，这种文化有意识地鼓励复用，而不是重新发明。启动会议的提交产物为确定可复用的知识提供了关注点，否则这些知识也许不能发现。如果每个人都按一致的方式来组织需求和使用术语，那么所有的需求就更容易被将来的项目路复用。
非正式的、有关经验的需求复用：当我们向同事问问题时，我们希望从他人的经验中学习，这样不必从头开始努力。一旦知道了工作的上下文范围，就可以寻找针对全部或部分这一上下文的需求规格说明，将它们作为潜在可复用需求的来源。采用训练有素的过程来编写需求规格说明书有一项好处：得到的需求更容易被将来的项目复用。

---

第十六章 沟通需求

编写需求不是一项单独的活动，而是在网罗和发现需求时完成的。将潜在需求变成书面需求，它必须包含清晰、完整、可测试的要求，说明必须构建什么。将半成形的相反变成准确的、可沟通的需求表述。项目通常组合使用电子表格、字处理程序、需求管理工具、建模工具以及老式卡片来管理知识模型中展现的信息。
原子需求的属性：

• 需求编号
• 需求类型
• 事件/用例编号
• 描述
• 理由
• 来源
• 验收标准
• 顾客满意度和不满意度
• 优先级
• 冲突
• 支持材料
• 历史

有许多不同的自动化需求工具，工具清单参见www.volere.co.uk/tool.html
编写需求规格说明不是一项随意的活动，业务事件、业务用例、产品用例、模板和需求框架使之成为一个有序的过程，而且它们也随着度量完成程度，更重要的是，指出哪些地方需要完善。需求知识管理是管理需求知识的文档系统的一种抽象视图，它为追踪一部分知识对其他知识的影响提供了基础。正确地编写需求是很重要的，一组好的需求能得到数倍的回报：构建工作更精确，维护成本更低，完成的产品更准确地反映了顾客的需要和想法。

---

第十七章 需求完整性

质量关已测试并接受了单项的需求，它们被允许进入规格说明，现在需要评估规格说明是否完整。这种复查可以迭代进行，最好每次针对一个产品用例的需求。复查的过程是迭代式的，寻找问题或遗漏、修正问题。有一种相当有效的规格说明复查方式，它是一个正式的过程，成为审查。审查过程开始时，由一名协调人确定要审查的材料和审查者，审查者收到被审查的文档的概要，用一天的时间来研究这些材料，审查会议利用以前发现的问题的检查清单来分析文档。如果发现新错误，就会更新清单。审查工具是非常有效的工具，确保了需求的正确性和完整性。为了进行复查，不必产生更多的文档，只要更好地利用已有的信息。复查过程如下：

• 定义上下文范围
• 识别业务事件和无事件
• 为业务用例建模
• 定义业务数据
• CRUD检查
• 保管人过程检查
• 重复知道完成

排列需求优先级，可以将需求分组，并将它们作为一个单元来排列优先级。影响优先级的因素：

• 实现的成本
• 对顾客或客户的价值
• 实现产品所需的价值
• 技术实现的容易程度
• 业务或组织结构实现的容易程度
• 对业务的好处
• 遵守法律的要求

常见的需求优先级登记是“高”、“中”、“低”等，优先级可以预防某些冲突的发生。冲突的产生可能是因为不同的利益相关者提出了不同的需求，或者利益相关者提出的需求与客户对需求的想法不一致。这对于大多数的需求收集工作来说都是正确的，它表明需要建立某种冲突解决机制。作为业务分析师，要将冲突的需求隔离出来，单独与每个利益相关者沟通接触。
规格说明书用到的所有术语，都必须在数字字典部分得到明确定义。如果每个词都有达成共识的定义，而且一致地使用术语，那么整个规格说明书的意思就是一致的和无二义性的。
风险评估不是正在的需求，而是项目问题。作为需求分析师，不必独自进行风险分析，如果组织机构足够大，员工中应该有人接受过风险评估方面的培训。业务分析师在风险评估中的角色，是考虑需求是否包含某种风险，可能影响项目的成功。
项目驱动
- 项目驱动
- 客户、顾客和其他利益相关者
- 产品用户

项目限制条件
- 强制的限制条件
- 相关事实和假定
功能需求
- 工作的范围
- 业务数据模型和数据字典
- 产品的范围
度量所需的工作量
复查是为了评估需求规格说明的正确性、完整性和质量。复查才有机会测量构建产品的好处、成本和风险，从而评估是否值得继续开发该产品。

掌握需求过程为分析方面提供了一个众人期盼的“前传”。