项目需求分析定义的灵魂拷问

项目需求分析定义的灵魂拷问乡村艳色李大壮 [导读] 项目开发，一般都是按照需求驱动开发整个开发过程的。需求是开发的源头，即便是自己DIY一个小东西，心中所想也是一种需求，所以一个项目是否成功，需求分析做的是否到位也是至关重要的

[导读] 项目开发，一般都是按照需求驱动开发整个开发过程的。需求是开发的源头，即便是自己DIY一个小东西，心中所想也是一种需求，所以一个项目是否成功，需求分析做的是否到位也是至关重要的。七夕情人节刚过完了，想来有的盆友或许深思倦怠，今天来分享一篇轻松的文章吧。

从搞笑开始

客户想要一款集美丽、智慧于一身的机器人，理想很丰满，可是现实很骨感。项目中不同的角色对这个需求理解各不相同，而表现传递的信息又有可能会大打折扣，所以最后交付造出来的产品与客户想要的相去甚远。

那么问题出在哪里呢？我以为需求失真是罪魁祸首！

• 客户自己对需求理解失真

• 设计人员对需求理解失真

• 需求文档对需求描述失真

• 开发人员对需求设计失真

• .......

  那么对于需求的定义在项目的成功执行，就显得尤为重要了。再看一个关于小龙女形象的经典段子：

客户自己对需求理解失真

设计人员对需求理解失真

需求文档对需求描述失真

开发人员对需求设计失真

.......

那么对于需求的定义在项目的成功执行，就显得尤为重要了。再看一个关于小龙女形象的经典段子：

这不是终极版本，来看下颠覆三观的终极失控版本：

注：图片来源于网络，纯属调侃搞笑，不带任何歧视，侵删

所以对一个成功的项目而已，需求的作用就显得尤为重要了。

需求的SMART原则， SMART依次英文含义为聪明的，SMART对于需求而言，有哪些度量维度呢？

• S：Specific 明确的

• M：Measurable 可度量的

• A：Achievable 可实现的

• R：Relevant 相关的（范畴内）

• T：Traceable and Testable 可追溯及可测的

需求的SMART原则， SMART依次英文含义为聪明的，SMART对于需求而言，有哪些度量维度呢？

• S：Specific 明确的

• M：Measurable 可度量的

• A：Achievable 可实现的

• R：Relevant 相关的（范畴内）

• T：Traceable and Testable 可追溯及可测的

S：Specific 明确的

M：Measurable 可度量的

A：Achievable 可实现的

R：Relevant 相关的（范畴内）

T：Traceable and Testable 可追溯及可测的

明确原则主要涵盖这样一些要点：

• 需求描述的正确性？描述的需求本身必须是正确的界定某个功能，如果本身就是一个错误的描述，则设计实现就一定是错误的！需求描述的内容是否是需求方（可能是最终客户或者来源于市场产品管理人员）。这项需求真的是需求方所需吗？或者部分所需？或者完全错误？

• 需求描述的唯一性？好的做法是将需求拆分成一个个条目，每一个条目描述一项明确精准的需求，相互之间不存在包含关系。

• 需求条目是否在项目的范围内？有的需求可能天马行空，超出了项目预期的范围的事情时有发生。

• 需求描述时否明确了该项需求的前提条件或者约束？

需求描述的正确性？描述的需求本身必须是正确的界定某个功能，如果本身就是一个错误的描述，则设计实现就一定是错误的！需求描述的内容是否是需求方（可能是最终客户或者来源于市场产品管理人员）。这项需求真的是需求方所需吗？或者部分所需？或者完全错误？

需求描述的唯一性？好的做法是将需求拆分成一个个条目，每一个条目描述一项明确精准的需求，相互之间不存在包含关系。

需求条目是否在项目的范围内？有的需求可能天马行空，超出了项目预期的范围的事情时有发生。

需求描述时否明确了该项需求的前提条件或者约束？

可度量，我的理解是体现精确性：

• 需求描述的精确性？需求不要用模棱两可的描述，比如不可使用左右，上下，可能等，而尽量用精准的数字去描述。比如需要描述响应时间，推荐描述为响应时间须满足：

• 需求描述的客观性？需求描述应采用客观描述语言，忌讳采用具有主管色彩的词汇，比如需求一个产品经理要求设计的UI界面，美观大方，容易操作，这样的需求是非常不易度量的，相信很多盆友或许又遭遇过这样的需求，也一定是非常恼火的。这样的需求你让设计咋整？一千个读者眼中就有一千个哈姆莱特，这样的描述太过主观，最后一定是撕逼扯皮的结局。

需求描述的精确性？需求不要用模棱两可的描述，比如不可使用左右，上下，可能等，而尽量用精准的数字去描述。比如需要描述响应时间，推荐描述为响应时间须满足：

需求描述的客观性？需求描述应采用客观描述语言，忌讳采用具有主管色彩的词汇，比如需求一个产品经理要求设计的UI界面，美观大方，容易操作，这样的需求是非常不易度量的，相信很多盆友或许又遭遇过这样的需求，也一定是非常恼火的。这样的需求你让设计咋整？一千个读者眼中就有一千个哈姆莱特，这样的描述太过主观，最后一定是撕逼扯皮的结局。

凡是写入项目需求规格书中的条款理论上就是一份技术合同，需求方就是甲方，项目团队相当于乙方。所以界定需求是需要与甲方反复沟通，反复确认的，否则一旦写入规格书，临了发现臣妾做不到！最后又不免撕逼扯皮！

要实现需求规格书的可实现原则，并不是简单成员坐在一起，拍拍脑袋想想就定下来，这里对于一些具有挑战的技术难点、技术指标是需要做技术预研的，否则可实现就变成了觉得可实现，而非客观上真的可实现！对于是否可实现，可以提出这样些问题：

• 项目团队是否具有这样的技术？

• 关键技术指标能否满足要求？

• 项目资源配置能满足要求？

• 可实现是原则不是描述如何实现！需求描述的就是功能性或非功能性的要求，而不要描述设计方案！

• .......

项目团队是否具有这样的技术？

关键技术指标能否满足要求？

项目资源配置能满足要求？

可实现是原则不是描述如何实现！需求描述的就是功能性或非功能性的要求，而不要描述设计方案！

.......

可追溯原则：

• 后向追溯：所有的需求条目，理论上应有甲方（需求方）的源头

• 后向追溯：所有的需求条目，都应有设计能对应保证，都应测试用例可验证。

后向追溯：所有的需求条目，理论上应有甲方（需求方）的源头

后向追溯：所有的需求条目，都应有设计能对应保证，都应测试用例可验证。

可测试原则：

• 需求条目，需要应尽量具有可测性

• 需求阶段，理论上测试人员就应该参与讨论，从测试的角度来进行核定。

需求条目，需要应尽量具有可测性

需求阶段，理论上测试人员就应该参与讨论，从测试的角度来进行核定。

无法追溯（无标号）

• 按下急停开关，系统须停机。（这里其实还不精确，应描述在多少时间内停机）

不可测

• SR-1：系统须永不崩溃。

不精确

• SR-2：系统应向用户提供快速反馈。（多快？）

无测量公差

• SR-3：LED灯应闪烁间隔100毫秒（应定义正负偏差）

过于复杂

• SR-4：按红色按钮将激活功能A，按蓝色按钮应使LED 1 闪烁而不是LED 2点亮，点亮LED 2通过黄色按钮实现。（应拆分）

描述实现

• SR-5：按下按钮W将导致两个16位整数值相加，然后…

无法追溯（无标号）

• 按下急停开关，系统须停机。（这里其实还不精确，应描述在多少时间内停机）

按下急停开关，系统须停机。（这里其实还不精确，应描述在多少时间内停机）

不可测

• SR-1：系统须永不崩溃。

SR-1：系统须永不崩溃。

不精确

• SR-2：系统应向用户提供快速反馈。（多快？）

SR-2：系统应向用户提供快速反馈。（多快？）

无测量公差

• SR-3：LED灯应闪烁间隔100毫秒（应定义正负偏差）

SR-3：LED灯应闪烁间隔100毫秒（应定义正负偏差）

过于复杂

• SR-4：按红色按钮将激活功能A，按蓝色按钮应使LED 1 闪烁而不是LED 2点亮，点亮LED 2通过黄色按钮实现。（应拆分）

SR-4：按红色按钮将激活功能A，按蓝色按钮应使LED 1 闪烁而不是LED 2点亮，点亮LED 2通过黄色按钮实现。（应拆分）

描述实现

• SR-5：按下按钮W将导致两个16位整数值相加，然后…

SR-5：按下按钮W将导致两个16位整数值相加，然后…

实际项目中，不同的公司实际落地都各有各的特点，这里大致列举一些常见做法：

• 文档描述法：属于常规方法，很多公司采用这样方案描述项目需求。

• UML 用例法：利用UML用例图描述需求，这种方法比较直观，比如下图

• 敏捷项目管理，采用用户故事描述（user story）

文档描述法：属于常规方法，很多公司采用这样方案描述项目需求。

UML 用例法：利用UML用例图描述需求，这种方法比较直观，比如下图

敏捷项目管理，采用用户故事描述（user story）

项目开发，需求阶段是一个至关重要的阶段。如果在需求阶段不做足确认工作，需求分析描述做的很随意，开发过程及交付时不免掉进各种坑里。

来源：嵌入式客栈

作者：逸珺

声明：本文由作者，文章内容系作者个人观点，转载仅作为传达一种不同的观点，不代表对该观点的赞同或支持，如有异议，欢迎联系。