[导读] 项目开发，通常都是按照需求驱动开发整个开发过程的。需求是开发的源头，即使是本身DIY一个小东西，心中所想也是一种需求，因此一个项目是否成功，需求分析作的是否到位也是相当重要的。七夕情人节刚过完了，想来有的盆友或许深思倦怠，今天来分享一篇轻松的文章吧。
node
从搞笑开始
客户想要一款集美丽、智慧于一身的机器人，理想很丰满，但是现实很骨感。项目中不一样的角色对这个需求理解各不相同，而表现传递的信息又有可能会大打折扣，因此最后交付造出来的产品与客户想要的相去甚远。
web
那么问题出在哪里呢？我觉得需求失真是罪魁祸首！微信
-
客户本身对需求理解失真网络
-
设计人员对需求理解失真架构
-
需求文档对需求描述失真app
-
开发人员对需求设计失真less
-
.......编辑器
那么对于需求的定义在项目的成功执行，就显得尤其重要了。再看一个关于小龙女形象的经典段子：svg
这不是终极版本，来看下颠覆三观的终极失控版本：测试
注：图片来源于网络，纯属调侃搞笑，不带任何歧视，侵删
因此对一个成功的项目而已，需求的做用就显得尤其重要了。
需求的SMART原则，SMART依次英文含义为聪明的，SMART对于需求而言，有哪些度量维度呢？
S：Specific 明确的 M：Measurable 可度量的 A：Achievable 可实现的 R：Realizable 可实现的 T：Traceable and Testable 可追溯及可测的
Specific明确原则
明确原则主要涵盖这样一些要点：
-
需求描述的正确性？描述的需求自己必须是正确的界定某个功能，若是自己就是一个错误的描述，则设计实现就必定是错误的！需求描述的内容是不是需求方（多是最终客户或者来源于市场产品管理人员）。这项需求真的是需求方所需吗？或者部分所需？或者彻底错误？ -
需求描述的惟一性？好的作法是将需求拆分红一个个条目，每个条目描述一项明确精准的需求，相互之间不存在包含关系。 -
需求条目是否在项目的范围内？有的需求可能天马行空，超出了项目预期的范围的事情时有发生。 -
需求描述时否明确了该项需求的前提条件或者约束？
Measurable可度量原则
可度量，个人理解是体现精确性：
-
需求描述的精确性？需求不要用模棱两可的描述，好比不可以使用左右，上下，可能等，而尽可能用精准的数字去描述。好比须要描述响应时间，推荐描述为响应时间须知足： -
需求描述的客观性？需求描述应采用客观描述语言，忌讳采用具备主管色彩的词汇，好比需求一个产品经理要求设计的UI界面，美观大方，容易操做，这样的需求是很是不易度量的，相信不少盆友或许又遭遇过这样的需求，也必定是很是恼火的。这样的需求你让设计咋整？一千个读者眼中就有一千个哈姆莱特，这样的描述太过主观，最后必定是撕逼扯皮的结局。
Achievable 可实现原则
凡是写入项目需求规格书中的条款理论上就是一份技术合同，需求方就是甲方，项目团队至关于乙方。因此界定需求是须要与甲方反复沟通，反复确认的，不然一旦写入规格书，临了发现臣妾作不到！最后又难免撕逼扯皮！
要实现需求规格书的可实现原则，并非简单成员坐在一块儿，拍拍脑壳想一想就定下来，这里对于一些具备挑战的技术难点、技术指标是须要作技术预研的，不然可实现就变成了以为可实现，而非客观上真的可实现！对因而否可实现，能够提出这样些问题：
-
项目团队是否具备这样的技术？ -
关键技术指标可否知足要求？ -
项目资源配置能知足要求？ -
可实现是原则不是描述如何实现！需求描述的就是功能性或非功能性的要求，而不要描述设计方案！ -
.......
双T可追溯可测原则
可追溯原则：
-
后向追溯：全部的需求条目，理论上应有甲方（需求方）的源头 -
后向追溯：全部的需求条目，都应有设计能对应保证，都应测试用例可验证。
可测试原则：
-
需求条目，须要应尽可能具备可测性 -
需求阶段，理论上测试人员就应该参与讨论，从测试的角度来进行核定。
不良需求描述栗子
没法追溯（无标号）
按下急停开关，系统须停机。（这里其实还不精确，应描述在多少时间内停机） 不可测
SR-1：系统须永不崩溃。 不精确
SR-2：系统应向用户提供快速反馈。（多快？） 无测量公差
SR-3：LED灯应闪烁间隔100毫秒（应定义正负误差） 过于复杂
SR-4：按红色按钮将激活功能A，按蓝色按钮应使LED 1 闪烁而不是LED 2点亮，点亮LED 2经过黄色按钮实现。（应拆分） 描述实现
SR-5：按下按钮W将致使两个16位整数值相加，而后…
需求描述方法
实际项目中，不一样的公司实际落地都各有各的特色，这里大体列举一些常见作法：
-
文档描述法：属于常规方法，不少公司采用这样方案描述项目需求。 -
UML 用例法：利用UML用例图描述需求，这种方法比较直观，好比下图
-
敏捷项目管理，采用用户故事描述（user story）
总结一下
项目开发，需求阶段是一个相当重要的阶段。若是在需求阶段不作足确认工做，需求分析描述作的很随意，开发过程及交付时难免掉进各类坑里。
本文辛苦原创，如喜欢请点赞/在看/分享支持，不胜感激！
—END—
本文分享自微信公众号 - 嵌入式客栈（embInn）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。