0°

BABOK Guide 3.0(7.2)Verify Requirements


BABOK Guide 3.0(7.2)Verify Requirements


Purpose


The purpose of Verify Requirements is to ensure that requirements and designs specifications and models meet quality standards and are usable for the purpose they serve.


有人觉得奇怪,需求为什么还要校验?

其实我们可能都默默的做了这个步骤,只是没有那么正式的执行。

我仔细读了一下这一章的内容,发现如果做好这一章的任务,可以避免以后各种自挖的或者被挖的坑。

Description


Verifying requirements ensures that the requirements and designs have been defined correctly.


在校验需求和设计的时候,我们需要保证需求和设计的载体,可能是需求规格,可能是原型,可能是模型,也可能是一堆的故事卡片,不管是什么,这么载体可以很好的编写并有助于相关干系人理解。


并且我们需要校验我们分析的需求和得出的设计可以符合用户的期望以及目标。


Inputs


• Requirements (specified and modelled)

上一个任务的输出将作为这个任务的输入。


Elements


Characteristics of Requirements and Designs Quality


我们校验需求或设计质量的要素,BABOK给出了以下几个。

但是我觉得,我们可以根据自己项目的特点和需求去选择校验的要素。

虽然这里列出的已经是最基本的要求了。


• Atomic原子性,不可分割


self-contained and capable of being understood independently of other requirements or designs.


需求需要足够小,相对独立。

也就是我们说的,尽量的高内聚、低耦合。


为什么有这项要求呢?

因为如果你的需求之间关系太过紧密,或者相互依赖比较多,未来在进行优先级评估、排布开发计划、验证解决方案、变更需求等等方面都会有比较大的阻碍和困扰。

而有的时候,的确需求之间的相互依赖关系非常强。


我的建议是,你可以退一步,思考一下你自己拆分需求的方式是不是有问题。


我打个比方,一个用户信息修改的功能。

你可以拆成:前台页面+后台校验保存。

但这种拆法很显然有相互的依赖关系。

你换一种拆法:登录信息的修改、个人资料的修改、关联账号的绑定修改。

这样相互的依赖关系会小很多。


• Complete完整性


enough to guide further work and at the appropriate level of detail for work to continue. The level of completeness required differs based on perspective or methodology, as well as the point in the life cycle where the requirement is being examined or represented.


对于完整性的校验,主要是看看这个需求是否完整详细到可以指导后续的工作。

但是,针对不同的研发流程和方法,对于详细程度的要求也是不一样的。


比如瀑布的话,肯定是需要非常详细到支撑详细设计的程度。

而针对敏捷的话,如果在初期阶段可以是比较粗颗粒的主线流程的故事。


• Consistent一致性


aligned with the identified needs of the stakeholders and not conflicting with other requirements.


需求和需求之间要一致,不能前言不搭后语或者前后矛盾。

这种情况多出现于很多case没有分析清楚,或者是协作沟通上的问题。


• Concise简洁


contains no extraneous and unnecessary content.


针对需要实现什么,约束限制是什么必须简单明了。

用最简单的句子和词语,会减少歧义。


• Feasible可行性


reasonable and possible within the agreed-upon risk, schedule, and budget, or considered feasible enough to investigate further through experiments or prototypes.


这就是为什么我们在校验需求的时候,一般会叫上相关的开发组长和项目经理,而不是一个人黑练的原因。

特别是一些技术可行性,时间和预算以及资源的可行性都是需要进行评估的。


• Unambiguous无歧义


the requirement must be clearly stated in such a way to make it clear whether a solution does or does not meet the associated need.


这点算是很基本的了,但是非常容易被忽略。


你去看看你写的文档里面,出现过多少这类词 “最好可以”,“可能需要”……那到底是可以还是不可以,需要还是不需要呢?

设计和开发测试人员怎么处理这个呢?


• Testable 可测试


able to verify that the requirement or design has been fulfilled. Acceptable levels of verifying fulfillment depend on the level of abstraction of the requirement or design.


需求的不可测试最长出现在非功能性需求中。


“页面打开速度要快,如果慢的话需要有进度条。”

什么是快?什么是慢?

“系统要有良好的可扩展性。”

什么是良好的可扩展性,怎么测量?


这类问题有很多,什么系统易用,页面友好等等。

这些其实属于废话……唉,你不说清楚,只能被理解为废话。


• Prioritized优先级


ranked, grouped, or negotiated in terms of importance and value against all other requirements.


优先级都是“高”,等于优先级都是“低”。


• Understandable可理解


represented using common terminology of the audience.


Verification Activities



在具体执行校验的过程中,可以根据一些标准进行衡量。

比如是否使用了适当的工具和方法,是否使用了公司规定的文档模板,是否针对每个模块都进行了要素分析,是否有相应的例子帮助理解,等等。


Checklists


当然,为了校验的顺利进行,你可以准备一个检查单。

检查单在质量控制中经常被用到。

思考一下对于你的组织、你的项目或产品来说,校验一个需求是否合格的标准有那些。

之前说到的内容可以给你作为参考。

检查单不仅保证了质量标准的一致性,也保证了随心所欲的校验会造成不必要的遗漏。


Guidelines and Tools


• Requirements Life Cycle Management Tools


Techniques


• Acceptance and Evaluation Criteria

• Item Tracking

• Metrics and Key Performance Indicators (KPIs)

• Reviews


Stakeholders


• All stakeholders


Outputs


• Requirements (verified)

a set of requirements or designs that is of sufficient quality to be used as a basis for further work.




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

BABOK Guide 3.0(7.2)Verify Requirements





「点点赞赏,手留余香」

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