zoukankan      html  css  js  c++  java
  • 项目需求分析定义的灵魂拷问

    关注、星标嵌入式客栈,精彩及时送达

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

    从搞笑开始

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

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

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

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

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

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

    • .......

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

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

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

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

    需求的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

    往期精彩推荐,点击即可阅读

    ▲Linux内核中I2C总线及设备长啥样? 

    ▲学Linux驱动:应先了解总线驱动模型

    ▲看思维导图:一文带你学Verilog HDL语言

  • 相关阅读:
    Sql日期时间格式转换
    c#被指定为此窗体的 MdiParent 的窗体不是 MdiContainer?
    kmeans聚类分析
    C# VS2005打开没问题,但是运行解决方案时就整个自动关闭了
    PowerDesigner教程系列(一)概念数据模型
    PowerDesigner概念设计模型(CDM)中的3种实体关系
    spss clementine Twostep Cluster(两步聚类 二阶聚类)
    PowerDesigner教程系列(三)概念数据模型
    Kmeans聚类算法
    c# 中窗体居中代码怎么写?
  • 原文地址:https://www.cnblogs.com/embInn/p/14038109.html
Copyright © 2011-2022 走看看