共读《掌握需求过程》P4需求验证（12~15章）
共读.jpg
第十二章 验收标准和理由
我们这里所说的验收意味着：解决方案完全满足或符合需求。也就是说，解决方案准确的实现了需求所要求做的事情，或具备需求所要求的属性，不多也不少。
需求本身必须是可测量的，需求的测量指标就是验收标准。
它炼化了需求的行为执行方式以及一些其他的品质。
想准确的了解需求，必须以某种方式对描述进行量化。
一旦测量需求，也就是用数字来表述，误解的可能性就很小了。
1 验收需要标准的原因
如果产品有一项需求，要执行某个功能或具备某种属性，那么测试活动必须展示产品确实执行了该项功能，或具备了该项期望的属性。
为了进行这样的测试需求，必须有一个测试基准，这样测试者才能比较提交的产品和最初的需求。
测试基准就是验收标准，基于需求的量化，它说明了产品必须到达的标准。
2 需求理由的理由
理由就是需求的原因或存在的道理。
为需求加上理由，可以更容易理解真正的需求。
利益相关者常常会告诉你一个解决方案，而不是他们真实的需求。
或者他们会告诉你一向很模糊的需求，以致暂时没有什么用处。理由不仅是帮助你发现验收标准的指导，也帮助你发现是否有好几项不同的需求，伪装成了一项需求。
而且，理由也为如何实现需求的决定提供了基础。
在产品使用和运维人员方面，理由将起到重要的作用。
假定你需要对产品进行变更，由于不理解理由而导致的问题，也是软件维护成本非常高的一部分原因。
测试者需要做出最佳决定，就需要理解需求的理由。
理由是业务和提交的产品之间认识的纽带。
你必须问为什么，不断的问为什么，知道理解了需求的真正理由。
3 测量的尺度
所有需求都可以测量，你要做的就是找到合适的尺度来测量它。
测量的尺度是用于测试产品符合程度的单位。
比如对于一个易用性需求，可以测量学习产品所需的时间，或达到供热能力水平的时间，或者可能是使用该产品完成工作的差错率。
各种品质都有测量尺度，你可以测量很多东西。
4 非功能需求的验收标准
非功能需求是产品必须具备的品质，诸如应用性、观感、执行特点等，因此验收标准是对这些品质进行量化。不要为了需求可测量而放慢需求发现的过程。
要了解利益相关者的意图以及理由，然后分析你的理解，编写对验收标准的最佳阐释，与利益相关者讨论并改进它们。
你们必须都同意你建议的验收标准，准确地测量了这项需求。
5 功能需求的验收标准
功能需求是产品必须做的某件事情，即产品必须完成的动作。
验收标准指明了如何得知产品已经成功地完成了该动作。
对功能需求来说，不存在测量的尺度。
因为动作要么完成，要么没完成。
完成就是权威满意，因为产品正确地执行了该动作。
这里的权威要么是数据源，要么是发起该行动的相邻系统。
功能需求的一般原则是：验收标准确保功能正确的执行。
6 验收标准的形式
编写验收标准，最常见的方式是采用自然语言的文字和数字。
如果你采用这种方式，就要确保验收标准中使用的所有数据，在规格说明书中都有定义，并在需求中一致的使用。
最好的方式是创建数据字典，定义工作范围内的术语。当然你也可以使用其他图式验收标准。比如，决策表、过程模型状态、模型、决策树、动态模型和其他技术。
只要能够以二义性最小的方式表达所需的测量指标，具体方式无所谓。
7 解决方案限制条件的验收标准
限制条件是一种特殊类型的需求，他们是全局需求，通常是管理层预先规定的。
但他们也需要正确制定，像其他类型的需求一样，所有其他限制条件，如实现环境，伙伴应用，商业上架销售软件，开源软件工作场地，环境时间预算，财务预算都应该有验收标准。本章小结
验收标准既不是测试，也不是对测试的设计，而是测试提交的产品时必须采用的测试基准。
它是构建测试用例的输入信息，测试者通过测试用例来确保产品的每项需求。
都符合它的验收标准，量化或测量需求，让你有更好的机会和利益相关者进行交流。
为需求加上验收标准，鼓励测试人员参与需求过程。
验收标准是真正的需求，验收标准是用精确方式来陈述的，可能使用数字或测量指标来表达它的含义。
验收标准也是多个利益相关者之间达成一致的手段，验收标准通常写在需求描述之后。
小婧的小结
需求的验收标准非常重要，特别是如果你是使用敏捷框架。
一个需求怎么才能算是完成，这个有很多判定的条件，其中验收标准是非常重要的一个。
通常我们的验收标准写的可能主要是针对功能性的，因为非功能性的需求不好提，不好验。
但是本章作者给我们举了很多生动的例子，证明非功能需求也是可以进行量化和测试的，这是很好的启发。但是值得注意的是这些指标数字要有理可据，而不是拍脑袋的。
另外针对需求的理由，确实也应该记录。
否则不说人员离职将这部分信息带走了，就个人而言过个一年半载的也不记得当时的理由，这是很正常的。
而记在哪里这件事情我觉得值得商榷。
因为作者是基于“白雪卡”等方式去管理需求的，所以可以在上面进行记录。
我们倒是可以考虑在story或者SRS中增加这么一个条目，专门用来记录这项需求的理由。
第十三章 质量关
需求来自于人，人们并非总能确定他们需要什么，并非总能解释他们想要什么，需求也并非总是编写的很小心完整无二义性。
需求工作的要点是，你必须确保交给开发者的东西是准确的、完整的、成熟的、真正的需求，任何不足都有违需求工作的初衷。
开发者可以构建任何东西，但他们必须首先知道他们必须构建什么。
质量关守关人确认每项需求，然后将它们加入需求规格说明书中。
共读《掌握需求过程》P4需求验证（12~15章）
当规范的潜在需求到达质量关，是它应该足够完整、以便进行测试，决定是否纳入规格说明书。
被拒绝的需求，退回个体后退回给提出者，要求澄清修改或取消。
1 需求质量
需求规格说明，是指一项或多项需求的集合。
它可以是你选择的任何方式，包括存在在你的头脑中。
如果规格说明是错的，产品也会错。
质量关测试就是要尽可能的保全保需求的正确性
需求错误代价巨大，如果允许错误，经过需求过程进入后续的开发工作，代价会越来越大。
及早的发现错误修正的成本就越来越低。
2 使用质量关
质量关防止不受欢迎的，不想要的需求进入需求规格。
需求通过质量关并进入需求规格说明，必须经过一系列测试，这些测试确保需求是完整的、准确的，不会因为不合适将来的设计和实现而引起麻烦。
共读《掌握需求过程》P4需求验证（12~15章）
3 超出范围
项目中有一个很常见的问题，就是超出范围的需求。
我们讨论了如何建立上下文范围，来确定工作的范围。
而上下文范围的另外一种用法，就是作为需求是否超出范围的仲裁者。
上下文模型中的数据流入或者离开工作领域。
他们决定了功能，也就是说如果你决定要自动化，某些功能就必须编写需求。
虽然上下文模型很清楚的说明了范围，但你也必须考虑需求的相关性。
要测试需求的相关性，就要比较他的意图和项目的目标。
测试相当简单，这项需求对项目的目标作出贡献吗？
这项需求对项目对产品满足项目目标有直接或间接的帮助吗？
需求可能逐渐的对产品作出贡献，有时候产品的需求需要做一些事情与目标没有直接的关系，但是如果没有这些需求产品将不能实现他们的目标。
质量关守关人可以放行这样的需求，他们对项目的目标作出了贡献。
许多非功能性需求也可以看作对象，目标有间接贡献。
无关的需求可能意味着利益相关者对项目的目标有误解，或者意味着新的业务领域正在打开。
4 测试完整性
完整性测试指出，每项需求都应具备的相关属性。
如果缺少某些属性原因要么很明显，要么需要解释。
对需求的每个属性进行测试，站在每个利益相关者的角度问一下，是否有可能误解。4 测试验收标准
质量关守关人的任务就是要确保验收标准是合理的需求测量指标。
即可以对照需求来测试产品。
第一个要问的问题就是：需求是否有一个正确定义的验收标准？
如果没有对它的理解就可能不充分。
对验收标准的下一个问题是：是否能作为设计验收测试的输入信息？
你也应该考虑是否存在经济有效的方法来测试。
实现这项需求的解决方案，验收标准也必须符合现实项目的目标。
验收标准可能是采用事先定义的标准，安全需求也可能会采用标准作为验收标准。
质量关守关人应该检查标准是否适用于这项需求，验收标准采用数字还是用标准，这取决于需求的类型。
不论哪种情况，缺乏合适的验收标准，就足以拒绝这项需求。
依据使用术语，要让指定的需求只能用一种方式理解，除了验收标准之外，你还需要在规格说明书中定义术语及其含义，保持一致的第二件事是检查每项需求使用的数据方式都符合定义，关于不一致性最后的一点，应该对他有心理准备，你应该利用质量观来消除它
5 现实条件下是否可行
可行的需求是指这样一些需求：我们能以经济有效的方式为他们开发解决方案，并在实施之后能够成功运营。
你是否具备这项需求的技术能力？
你是否有时间和财力来实现这项需求？
是否所有利益相关者都接受该需求？
是否存在其他限制条件要求不可行？
是否存在一些伙伴应用或预期的工作环境与该需求冲突？
是否存在一些解决方案限制条件，使得需求难以实现或不可能实现？
6 需求还是解决方案
很不幸，对需求的描述常常以解决方案形式给出。
这导致把重点放在一种可能的解决方案上。
这种方案不一定最合适，通常隐藏的真正的需求。
方法：
- 检查该需求，它是否包含技术元素，它的编写方式是否描述了某种过程？
- 想想潜在的解决方案。
- 如果以一种抽象的方式来编写需求，其他解决方案都是可能的。
- 检查需求的基础内容，你必须拒绝所有不是需求的解决方案，除非解决方案实际上是限制条件。
7 需求价值
需求所附的顾客满意度/不满意度评分，说明了顾客对该项需求价值的认识。8 镀金需求
"镀金"这个术语来自镀金浴室龙头.
软件业用这个术语来指代那些不必要的特征或需求：他它们对产品成本的贡献多于对产品功能的贡献，它存在也许是因为有了就很不错，但如果产品不实现该功能，没有人会介意。
对镀金的第一项检查就是：如果没有该需求，会有影响吗？
如果没有人能真正地提出该需求的正当理由，那么可以认为它是镀金需求。
第二项检查也许更可靠：查看需求所附的满意度/不满意度评分。不满意度，评分很低，说明该需求可能是镀金的。
8 需求蔓延
需求蔓延是指在大家认为需求已经完成后，新需求又进入了需求规格说明书。
很自然，需求过程永远不会结束。
但总存在一个项目阶段，在这个阶段打算要开始构建产品的工作。
在这个阶段之后，发生的需求被视为需求蔓延。
质量关在控制蔓延方面是有作用的。
你可以利用上下文模型中的数据浏览，决定需求是否超出范围。
同时你也应该确保每项需求都包含有效的顾客满意度/不满意度评分。
这些评分告诉你，顾客认为该需求具有的价值。
如果评分高，那么蔓延的需求也许可以容忍。
如果需求蔓延到项目范围之外或许产品的目标无关，你就应该认真考虑一下，范围是否正确。
产品的目标正确吗？
符合实际吗？
你需要仔细找出需求蔓延的根源。
也许范围在一开始就说错了，也许范围应该变更。
需求蔓延的名声不好，主要是因为他打乱了开发进度，增加了因此而导致提交产品的成本。
首先大多数需求蔓延都是因为一开始没有正确的设计需求。
如果用户和客户没有机会完整地参与需求过程，那么毫无疑问需求将是不完整的，几乎可以肯定当提交日期临近时需求会蔓延，用户开始要求那些他们知道需要的功能。
还有一种蔓延产生的原因是最初的预算太低，不符合实际情况。
9 实现质量关
第一项决定是谁来实现质量关。
建议从两个人开始实现你的质量关，可能是需求分析师和一名测试人员。
这个质量关是对需求的快速简单的测试，而不是涉及半数团队成员的辛苦过程。
比如需求分析师通过电子邮件将所有需求发送给质量关守关人，守关人将其中一些加入的校规和说明书中。
第二种方式是使用自动化的工具。有助于减少质量关过程中人的干涉，某些需求收集工具可以完成初步的机械性的检查，把所有的属性都存在使用了正确的术语，提供了正确的标识符等。
伙伴相互检查对方的输出，在过程的早期发现错误。
第二个阶段是同级复查，由团队中的其他人员正式复查每项需求。
第三个阶段是团队复查，包括顾客和用户。
第四个阶段是管理者复查，主要关注质量关成功和失败的总结。
小婧的小结：
目前我们的需求的解决方案确认方式是通过同级复查，然后再进行SRS编写和提交需求评审/对接。
其实，针对目前业务尚不是很复杂，BA不是很多的情况下是可行的。
但是如果随着团队的扩大，和产品复杂度的增加，确实需要对需求这部分的质量关进行把关。
另外，本章说的其实是需求的质量关而不是解决方案的质量关。
在这个方面，感觉周围人都做的很少。
第十四章 需求与迭代开发
我们的行业中有一项重要的进步，即开发者和业务人员共同承诺，尽一切努力，尽可能的交付有价值的适当的能工作的产品。
让我们看看这个承诺中“快”的部分，许多组织机构不是等待需求的所有细节都得到定义，而是更喜欢迭代完成这项业务活动。
这样增量式交付发行版本直到解决方案被判定完成，这种迭代的方式意味着业务环境的开发环境中的关注点、想法和变化更加同步。目的是开发者更了解今天的业务问题，工作的产品更适合今天的业务环境。
1 迭代的需求过程
共读《掌握需求过程》P4需求验证（12~15章）
2 如何编写好用户故事
要发现用户故事，问这个问题：产品可以为用户做些什么来满足这个业务用例背后的业务意图？要编写真正的好故事，你不能只是被动地聆听业务利益相关者，写下他们认为最想要的东西。
你必须运用业务分析师的许多手艺，包括：创新、思考问题本质、业务事件的真正起源、在横线上思考。
3 迭代需求的角色
你需要一名主题事务专家。
他是业务和工作问题的知识来源，提出业务要求也回答问题，告诉你变更做出业务方面的选择。
业务分析师是业务知识的有用来源。
业务分析师既不属于业务，也不属于开发团队。业务分析师中立的渠道，他所受的训练是观察和发现业务需求，并将这些需求告诉开发者。
技术知识体现为开发者和系统架构师测试员，外部供应商的角色的某种组合。
第十五章 复用需求
每个人都想写出别人能复用的组件，没人想复用别人的组件。
但是你如果要为新产品制定需求，那么开始时问一下：这些需求或相似的需求是否已经写过？
总有可能节省一些工作量。
1 什么是复用需求？
成功的复用始于一种组织文化。
这种文化有意识地鼓励复用，而不是重新发明。
共读《掌握需求过程》P4需求验证（12~15章）
在召开项目启动会议时，就触发关于复用的问题。
- 项目的目标：组织机构中是否存在其他项目与本项目一致，或实际上包含相同的领域？
- 客户顾客和其他利益相关者：可以复用一份利益相关者名单，利益相关者图个利益相关者分析表格吗？产品的用户，其他产品是否涉及相同的用户，从而具有类似的易用性需求？
- 强制的限制条件：限制条件是否已在其他项目中指定？是否有组织机构的限制条件也适用于你的项目？
- 命名标准核定义：你几乎可以肯定利用原有词汇表的一些部分
- 相关事实与假定：注意最近一些项目的相关事实，对其他项目的假定也适用于本项目吗？
- 工作的范围：你的项目很有可能成为组织机构正在开发的其他项目的相邻系统，要利用其他工作上下文模型已经建立好的接口，考虑你的工作范围是否其他项目已经定了类似的业务时间
- 业务模型：业务数据模型和数据字典，是否有重叠或相关的项目，其业务数据模型可以作为你的起点。别太急着说现在的项目与之前的任何项目都不同。
是的，主题是不同。
但如果你不去看那些名字，有多少底层的功能实际上是一样的呢？
启动会上的利益相关者是很好的可复用组件的来源。
2 可复用需求的来源
非正式的有关经验的需求复用，当我们向同事询问问题时，我们希望从他人的经验中学习，这样不必从头开始努力。一旦你知道了工作的上下文范围，就可以寻找针对全部或部分。
这一上下文的需求规格说明，将它们作为潜在的客户有需求的来源。来源可以是任意一种同事的经验，也有的需求规格说明，模型当然还有书籍。
3 模式
模式是一种指南。
如果你试图重复某项工作或近似地重复某项工作，它可以给出一种可遵循的形式。
但是从需求的角度来看，什么是模式呢？
是因为这个从某种逻辑功能组的一组需求模式，改进了需求规格说明书的精确性和完整性。
注意模版的角色。
它是一个指南，而不是一种严格的指令或实现。
它可以复用，因为不需要重做实验或发明，它是一组知识或经验可以进行调整和直接使用。
4 领域分析
可以把领域分析看作是非项目系统分析，目的是为了了解有关的业务策略数据和功能，而不是构建什么东西。
在该领域所获得的知识将用于该领域内所有构件产品的项目，最好是得到复用。
领域知识被发现被记录并记录下来后，就可以被任何构建该领域产品的人使用。
领域知识适用于该领域的所有产品，要点不是重新发现已经存在的知识，而是使用真实的模型。
领域分析是一项长期过任务，战略分析上投资就像其他投资一样，投资将得到回报。
小婧的小结：
领域建模和领域分析非常重要。
这些年我越发的体会到业务对于BA的重要性了。
你也许有很多需求调研、分析、开发的工具和技能，但是如果不了解业务就永远无法深入核心。
与客户在沟通上也会有很多二义性产生。
就最近，我们听客户说“配建”，我们以为是“配件”。
这只是一个很简单的例子，我们需要不断的学习才能得到长远的进步。
小婧是一名行走在产品路上的资深业务分析师（BA），如果想与我同行，就请关注我吧！
