[导读] 项目开发,一般都是按照需求驱动开发整个开发过程的。需求是开发的源头,即便是自己DIY一个小东西,心中所想也是一种需求,所以一个项目是否成功,需求分析做的是否到位也是至关重要的。七夕情人节刚过完了,想来有的盆友或许深思倦怠,今天来分享一篇轻松的文章吧。
客户想要一款集美丽、智慧于一身的机器人,理想很丰满,可是现实很骨感。项目中不同的角色对这个需求理解各不相同,而表现传递的信息又有可能会大打折扣,所以最后交付造出来的产品与客户想要的相去甚远。
那么问题出在哪里呢?我以为需求失真是罪魁祸首!
客户自己对需求理解失真
设计人员对需求理解失真
需求文档对需求描述失真
开发人员对需求设计失真
.......
那么对于需求的定义在项目的成功执行,就显得尤为重要了。再看一个关于小龙女形象的经典段子:
这不是终极版本,来看下颠覆三观的终极失控版本:
注:图片来源于网络,纯属调侃搞笑,不带任何歧视,侵删
所以对一个成功的项目而已,需求的作用就显得尤为重要了。
需求的SMART原则,SMART依次英文含义为聪明的,SMART对于需求而言,有哪些度量维度呢?
S:Specific 明确的 M:Measurable 可度量的 A:Achievable 可实现的 R:Realizable 可实现的 T:Traceable and Testable 可追溯及可测的
明确原则主要涵盖这样一些要点:
可度量,我的理解是体现精确性:
凡是写入项目需求规格书中的条款理论上就是一份技术合同,需求方就是甲方,项目团队相当于乙方。所以界定需求是需要与甲方反复沟通,反复确认的,否则一旦写入规格书,临了发现臣妾做不到!最后又不免撕逼扯皮!
要实现需求规格书的可实现原则,并不是简单成员坐在一起,拍拍脑袋想想就定下来,这里对于一些具有挑战的技术难点、技术指标是需要做技术预研的,否则可实现就变成了觉得可实现,而非客观上真的可实现!对于是否可实现,可以提出这样些问题:
可追溯原则:
可测试原则:
无法追溯(无标号)
按下急停开关,系统须停机。(这里其实还不精确,应描述在多少时间内停机) 不可测
SR-1:系统须永不崩溃。 不精确
SR-2:系统应向用户提供快速反馈。(多快?) 无测量公差
SR-3:LED灯应闪烁间隔100毫秒(应定义正负偏差) 过于复杂
SR-4:按红色按钮将激活功能A,按蓝色按钮应使LED 1 闪烁而不是LED 2点亮,点亮LED 2通过黄色按钮实现。(应拆分) 描述实现
SR-5:按下按钮W将导致两个16位整数值相加,然后…
实际项目中,不同的公司实际落地都各有各的特点,这里大致列举一些常见做法:
项目开发,需求阶段是一个至关重要的阶段。如果在需求阶段不做足确认工作,需求分析描述做的很随意,开发过程及交付时不免掉进各种坑里。
本文辛苦原创,如喜欢请点赞/在看/分享支持,不胜感激!
—END—