0°

共读《掌握需求过程》Part4 需求验证


2016-11-21《掌握需求过程》

Part4 需求验证(第十二章~第十五章)

共读《掌握需求过程》Part4 需求验证


第十二章 验收标准和理由


我们这里所说的验收意味着:解决方案完全满足或符合需求。也就是说,解决方案准确的实现了需求所要求做的事情,或具备需求所要求的属性,不多也不少。
需求本身必须是可测量的,需求的测量指标就是验收标准。
它炼化了需求的行为执行方式以及一些其他的品质。
想准确的了解需求,必须以某种方式对描述进行量化。
一旦测量需求,也就是用数字来表述,误解的可能性就很小了。

1验收需要标准的原因


如果产品有一项需求,要执行某个功能或具备某种属性,那么测试活动必须展示产品确实执行了该项功能,或具备了该项期望的属性。
为了进行这样的测试需求,必须有一个测试基准,这样测试者才能比较提交的产品和最初的需求。
测试基准就是验收标准,基于需求的量化,它说明了产品必须到达的标准。

2需求理由的理由


理由就是需求的原因或存在的道理。

为需求加上理由,可以更容易理解真正的需求。
利益相关者常常会告诉你一个解决方案,而不是他们真实的需求。
或者他们会告诉你一向很模糊的需求,以致暂时没有什么用处。理由不仅是帮助你发现验收标准的指导,也帮助你发现是否有好几项不同的需求,伪装成了一项需求。
而且,理由也为如何实现需求的决定提供了基础。

在产品使用和运维人员方面,理由将起到重要的作用。
假定你需要对产品进行变更,由于不理解理由而导致的问题,也是软件维护成本非常高的一部分原因。
测试者需要做出最佳决定,就需要理解需求的理由。
理由是业务和提交的产品之间认识的纽带。
你必须问为什么,不断的问为什么,知道理解了需求的真正理由。

3测量的尺度


所有需求都可以测量,你要做的就是找到合适的尺度来测量它。
测量的尺度是用于测试产品符合程度的单位。
比如对于一个易用性需求,可以测量学习产品所需的时间,或达到供热能力水平的时间,或者可能是使用该产品完成工作的差错率。
各种品质都有测量尺度,你可以测量很多东西。

4非功能需求的验收标准


非功能需求是产品必须具备的品质,诸如应用性、观感、执行特点等,因此验收标准是对这些品质进行量化。不要为了需求可测量而放慢需求发现的过程。
要了解利益相关者的意图以及理由,然后分析你的理解,编写对验收标准的最佳阐释,与利益相关者讨论并改进它们。
你们必须都同意你建议的验收标准,准确地测量了这项需求。

5功能需求的验收标准


功能需求是产品必须做的某件事情,即产品必须完成的动作。
验收标准指明了如何得知产品已经成功地完成了该动作。
对功能需求来说,不存在测量的尺度。
因为动作要么完成,要么没完成。
完成就是权威满意,因为产品正确地执行了该动作。
这里的权威要么是数据源,要么是发起该行动的相邻系统。
功能需求的一般原则是:验收标准确保功能正确的执行。

6 验收标准的形式


编写验收标准,最常见的方式是采用自然语言的文字和数字。
如果你采用这种方式,就要确保验收标准中使用的所有数据,在规格说明书中都有定义,并在需求中一致的使用。
最好的方式是创建数据字典,定义工作范围内的术语。当然你也可以使用其他图式验收标准。比如,决策表、过程模型状态、模型、决策树、动态模型和其他技术。
只要能够以二义性最小的方式表达所需的测量指标,具体方式无所谓。

7 解决方案限制条件的验收标准


限制条件是一种特殊类型的需求,他们是全局需求,通常是管理层预先规定的。
但他们也需要正确制定,像其他类型的需求一样,所有其他限制条件,如实现环境,伙伴应用,商业上架销售软件,开源软件工作场地,环境时间预算,财务预算都应该有验收标准。本章小结
验收标准既不是测试,也不是对测试的设计,而是测试提交的产品时必须采用的测试基准。
它是构建测试用例的输入信息,测试者通过测试用例来确保产品的每项需求。
都符合它的验收标准,量化或测量需求,让你有更好的机会和利益相关者进行交流。
为需求加上验收标准,鼓励测试人员参与需求过程。
验收标准是真正的需求,验收标准是用精确方式来陈述的,可能使用数字或测量指标来表达它的含义。
验收标准也是多个利益相关者之间达成一致的手段,验收标准通常写在需求描述之后。

小婧的小结


需求的验收标准非常重要,特别是如果你是使用敏捷框架。
一个需求怎么才能算是完成,这个有很多判定的条件,其中验收标准是非常重要的一个。
通常我们的验收标准写的可能主要是针对功能性的,因为非功能性的需求不好提,不好验。
但是本章作者给我们举了很多生动的例子,证明非功能需求也是可以进行量化和测试的,这是很好的启发。但是值得注意的是这些指标数字要有理可据,而不是拍脑袋的。
另外针对需求的理由,确实也应该记录。
否则不说人员离职将这部分信息带走了,就个人而言过个一年半载的也不记得当时的理由,这是很正常的。
而记在哪里这件事情我觉得值得商榷。
因为作者是基于“白雪卡”等方式去管理需求的,所以可以在上面进行记录。
我们倒是可以考虑在story或者SRS中增加这么一个条目,专门用来记录这项需求的理由。


第十三章 质量关


需求来自于人,人们并非总能确定他们需要什么,并非总能解释他们想要什么,需求也并非总是编写的很小心完整无二义性。
需求工作的要点是,你必须确保交给开发者的东西是准确的、完整的、成熟的、真正的需求,任何不足都有违需求工作的初衷。
开发者可以构建任何东西,但他们必须首先知道他们必须构建什么。
质量关守关人确认每项需求,然后将它们加入需求规格说明书中。

共读《掌握需求过程》Part4 需求验证


当规范的潜在需求到达质量关,是它应该足够完整、以便进行测试,决定是否纳入规格说明书。
被拒绝的需求,退回个体后退回给提出者,要求澄清修改或取消。

1
 需求质量


需求规格说明,是指一项或多项需求的集合。
它可以是你选择的任何方式,包括存在在你的头脑中。
如果规格说明是错的,产品也会错。
质量关测试就是要尽可能的保全保需求的正确性
需求错误代价巨大,如果允许错误,经过需求过程进入后续的开发工作,代价会越来越大。
及早的发现错误修正的成本就越来越低。

2
 使用质量关


质量关防止不受欢迎的,不想要的需求进入需求规格。
需求通过质量关并进入需求规格说明,必须经过一系列测试,这些测试确保需求是完整的、准确的,不会因为不合适将来的设计和实现而引起麻烦。

共读《掌握需求过程》Part4 需求验证


3
 超出范围


项目中有一个很常见的问题,就是超出范围的需求。
我们讨论了如何建立上下文范围,来确定工作的范围。
而上下文范围的另外一种用法,就是作为需求是否超出范围的仲裁者。
上下文模型中的数据流入或者离开工作领域。
他们决定了功能,也就是说如果你决定要自动化,某些功能就必须编写需求。
虽然上下文模型很清楚的说明了范围,但你也必须考虑需求的相关性。
要测试需求的相关性,就要比较他的意图和项目的目标。
测试相当简单,这项需求对项目的目标作出贡献吗?
这项需求对项目对产品满足项目目标有直接或间接的帮助吗?
需求可能逐渐的对产品作出贡献,有时候产品的需求需要做一些事情与目标没有直接的关系,但是如果没有这些需求产品将不能实现他们的目标。
质量关守关人可以放行这样的需求,他们对项目的目标作出了贡献。
许多非功能性需求也可以看作对象,目标有间接贡献。
无关的需求可能意味着利益相关者对项目的目标有误解,或者意味着新的业务领域正在打开。

4
 测试完整性


完整性测试指出,每项需求都应具备的相关属性。
如果缺少某些属性原因要么很明显,要么需要解释。
对需求的每个属性进行测试,站在每个利益相关者的角度问一下,是否有可能误解。4 测试验收标准
质量关守关人的任务就是要确保验收标准是合理的需求测量指标。
即可以对照需求来测试产品。
第一个要问的问题就是:需求是否有一个正确定义的验收标准?
如果没有对它的理解就可能不充分。
对验收标准的下一个问题是:是否能作为设计验收测试的输入信息?
你也应该考虑是否存在经济有效的方法来测试。
实现这项需求的解决方案,验收标准也必须符合现实项目的目标。
验收标准可能是采用事先定义的标准,安全需求也可能会采用标准作为验收标准。
质量关守关人应该检查标准是否适用于这项需求,验收标准采用数字还是用标准,这取决于需求的类型。
不论哪种情况,缺乏合适的验收标准,就足以拒绝这项需求。

依据使用术语,要让指定的需求只能用一种方式理解,除了验收标准之外,你还需要在规格说明书中定义术语及其含义,保持一致的第二件事是检查每项需求使用的数据方式都符合定义,关于不一致性最后的一点,应该对他有心理准备,你应该利用质量观来消除它

5
 现实条件下是否可行


可行的需求是指这样一些需求:我们能以经济有效的方式为他们开发解决方案,并在实施之后能够成功运营。
你是否具备这项需求的技术能力?
你是否有时间和财力来实现这项需求?
是否所有利益相关者都接受该需求?
是否存在其他限制条件要求不可行?
是否存在一些伙伴应用或预期的工作环境与该需求冲突?
是否存在一些解决方案限制条件,使得需求难以实现或不可能实现?

6
需求还是解决方案


很不幸,对需求的描述常常以解决方案形式给出。
这导致把重点放在一种可能的解决方案上。
这种方案不一定最合适,通常隐藏的真正的需求。
方法:

  • 检查该需求,它是否包含技术元素,它的编写方式是否描述了某种过程?

  • 想想潜在的解决方案。

  • 如果以一种抽象的方式来编写需求,其他解决方案都是可能的。

  • 检查需求的基础内容,你必须拒绝所有不是需求的解决方案,除非解决方案实际上是限制条件。

7
 需求价值


需求所附的顾客满意度/不满意度评分,说明了顾客对该项需求价值的认识。8 镀金需求
“镀金”这个术语来自镀金浴室龙头.
软件业用这个术语来指代那些不必要的特征或需求:他它们对产品成本的贡献多于对产品功能的贡献,它存在也许是因为有了就很不错,但如果产品不实现该功能,没有人会介意。
对镀金的第一项检查就是:如果没有该需求,会有影响吗?
如果没有人能真正地提出该需求的正当理由,那么可以认为它是镀金需求。
第二项检查也许更可靠:查看需求所附的满意度/不满意度评分。不满意度,评分很低,说明该需求可能是镀金的。

8
 需求蔓延


需求蔓延是指在大家认为需求已经完成后,新需求又进入了需求规格说明书。
很自然,需求过程永远不会结束。
但总存在一个项目阶段,在这个阶段打算要开始构建产品的工作。
在这个阶段之后,发生的需求被视为需求蔓延。
质量关在控制蔓延方面是有作用的。
你可以利用上下文模型中的数据浏览,决定需求是否超出范围。
同时你也应该确保每项需求都包含有效的顾客满意度/不满意度评分。
这些评分告诉你,顾客认为该需求具有的价值。
如果评分高,那么蔓延的需求也许可以容忍。
如果需求蔓延到项目范围之外或许产品的目标无关,你就应该认真考虑一下,范围是否正确。
产品的目标正确吗?
符合实际吗?
你需要仔细找出需求蔓延的根源。
也许范围在一开始就说错了,也许范围应该变更。
需求蔓延的名声不好,主要是因为他打乱了开发进度,增加了因此而导致提交产品的成本。
首先大多数需求蔓延都是因为一开始没有正确的设计需求。
如果用户和客户没有机会完整地参与需求过程,那么毫无疑问需求将是不完整的,几乎可以肯定当提交日期临近时需求会蔓延,用户开始要求那些他们知道需要的功能。
还有一种蔓延产生的原因是最初的预算太低,不符合实际情况。

9
 实现质量关

第一项决定是谁来实现质量关。
建议从两个人开始实现你的质量关,可能是需求分析师和一名测试人员。
这个质量关是对需求的快速简单的测试,而不是涉及半数团队成员的辛苦过程。
比如需求分析师通过电子邮件将所有需求发送给质量关守关人,守关人将其中一些加入的校规和说明书中。
第二种方式是使用自动化的工具。有助于减少质量关过程中人的干涉,某些需求收集工具可以完成初步的机械性的检查,把所有的属性都存在使用了正确的术语,提供了正确的标识符等。
伙伴相互检查对方的输出,在过程的早期发现错误。

第二个阶段是同级复查,由团队中的其他人员正式复查每项需求。

第三个阶段是团队复查,包括顾客和用户。

第四个阶段是管理者复查,主要关注质量关成功和失败的总结。

小婧的小结:


目前我们的需求的解决方案确认方式是通过同级复查,然后再进行SRS编写和提交需求评审/对接。
其实,针对目前业务尚不是很复杂,BA不是很多的情况下是可行的。
但是如果随着团队的扩大,和产品复杂度的增加,确实需要对需求这部分的质量关进行把关。
另外,本章说的其实是需求的质量关而不是解决方案的质量关。
在这个方面,感觉周围人都做的很少。


第十四章 需求与迭代开发


我们的行业中有一项重要的进步,即开发者和业务人员共同承诺,尽一切努力,尽可能的交付有价值的适当的能工作的产品。
让我们看看这个承诺中“快”的部分,许多组织机构不是等待需求的所有细节都得到定义,而是更喜欢迭代完成这项业务活动。
这样增量式交付发行版本直到解决方案被判定完成,这种迭代的方式意味着业务环境的开发环境中的关注点、想法和变化更加同步。目的是开发者更了解今天的业务问题,工作的产品更适合今天的业务环境。

1 迭代的需求过程


共读《掌握需求过程》Part4 需求验证


2 如何编写好用户故事


要发现用户故事,问这个问题:产品可以为用户做些什么来满足这个业务用例背后的业务意图?要编写真正的好故事,你不能只是被动地聆听业务利益相关者,写下他们认为最想要的东西。
你必须运用业务分析师的许多手艺,包括:创新、思考问题本质、业务事件的真正起源、在横线上思考。

3 迭代需求的角色


你需要一名主题事务专家。
他是业务和工作问题的知识来源,提出业务要求也回答问题,告诉你变更做出业务方面的选择。
业务分析师是业务知识的有用来源。
业务分析师既不属于业务,也不属于开发团队。业务分析师中立的渠道,他所受的训练是观察和发现业务需求,并将这些需求告诉开发者。
技术知识体现为开发者和系统架构师测试员,外部供应商的角色的某种组合。


第十五章 复用需求


每个人都想写出别人能复用的组件,没人想复用别人的组件。
但是你如果要为新产品制定需求,那么开始时问一下:这些需求或相似的需求是否已经写过?
总有可能节省一些工作量。

1 什么是复用需求?


成功的复用始于一种组织文化。
这种文化有意识地鼓励复用,而不是重新发明。

共读《掌握需求过程》Part4 需求验证



在召开项目启动会议时,就触发关于复用的问题。

  • 项目的目标:组织机构中是否存在其他项目与本项目一致,或实际上包含相同的领域?

  • 客户顾客和其他利益相关者:可以复用一份利益相关者名单,利益相关者图个利益相关者分析表格吗?产品的用户,其他产品是否涉及相同的用户,从而具有类似的易用性需求?

  • 强制的限制条件:限制条件是否已在其他项目中指定?是否有组织机构的限制条件也适用于你的项目?

  • 命名标准核定义:你几乎可以肯定利用原有词汇表的一些部分

  • 相关事实与假定:注意最近一些项目的相关事实,对其他项目的假定也适用于本项目吗?

  • 工作的范围:你的项目很有可能成为组织机构正在开发的其他项目的相邻系统,要利用其他工作上下文模型已经建立好的接口,考虑你的工作范围是否其他项目已经定了类似的业务时间

  • 业务模型:业务数据模型和数据字典,是否有重叠或相关的项目,其业务数据模型可以作为你的起点。别太急着说现在的项目与之前的任何项目都不同。
    是的,主题是不同。
    但如果你不去看那些名字,有多少底层的功能实际上是一样的呢?
    启动会上的利益相关者是很好的可复用组件的来源。

2可复用需求的来源


非正式的有关经验的需求复用,当我们向同事询问问题时,我们希望从他人的经验中学习,这样不必从头开始努力。一旦你知道了工作的上下文范围,就可以寻找针对全部或部分。
这一上下文的需求规格说明,将它们作为潜在的客户有需求的来源。来源可以是任意一种同事的经验,也有的需求规格说明,模型当然还有书籍。

3模式


模式是一种指南。
如果你试图重复某项工作或近似地重复某项工作,它可以给出一种可遵循的形式。
但是从需求的角度来看,什么是模式呢?
是因为这个从某种逻辑功能组的一组需求模式,改进了需求规格说明书的精确性和完整性。
注意模版的角色。
它是一个指南,而不是一种严格的指令或实现。
它可以复用,因为不需要重做实验或发明,它是一组知识或经验可以进行调整和直接使用。

4 领域分析


可以把领域分析看作是非项目系统分析,目的是为了了解有关的业务策略数据和功能,而不是构建什么东西。
在该领域所获得的知识将用于该领域内所有构件产品的项目,最好是得到复用。
领域知识被发现被记录并记录下来后,就可以被任何构建该领域产品的人使用。
领域知识适用于该领域的所有产品,要点不是重新发现已经存在的知识,而是使用真实的模型。
领域分析是一项长期过任务,战略分析上投资就像其他投资一样,投资将得到回报。

小婧的小结:


领域建模和领域分析非常重要。
这些年我越发的体会到业务对于BA的重要性了。
你也许有很多需求调研、分析、开发的工具和技能,但是如果不了解业务就永远无法深入核心。
与客户在沟通上也会有很多二义性产生。
就最近,我们听客户说“配建”,我们以为是“配件”。
这只是一个很简单的例子,我们需要不断的学习才能得到长远的进步。



写在最后:

我们来贴一下阅读计划哦。
计划从2016年11月1日开始,总共花费21天完成。
假设:每天花半个小时阅读,阅读速度约为15页/30分钟。
将本书划分为5个部分,具体计划为:
Part1
阅读内容:前言(1~2章)
时间:11-01~11-02,2天

Part2
阅读内容:问题及业务分析(3~7章)
时间:11-03~11-09,7天
Part3
阅读内容:解决方案及需求分析(8~11章)
时间:11-10~11-14,5天

Part4
阅读内容:需求验证(12~15章)
时间:11-15~11-18,4天

Part5
阅读内容:沟通与管理(16~17章)
时间:11-19~11-21,3天




小婧是一名行走在产品路上的资深业务分析师(BA),如果想与我同行,就请关注我吧!

共读《掌握需求过程》Part4 需求验证






「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论