言之无物

我说的一切都是错的

项目“背锅侠”之需求分析

从业这么多年,大大小小的项目也做了不少,有多少是真正成功的?当然,如何定义“成功”各有各的标准,从交付的角度来看,项目都是成功的。因为不管过程如何曲折,时间、成本如何超支,最终无法验收、收不到钱的项目实在少之又少。但这样的标准,对项目过程的改进毫无借鉴作用。 Standish Group是一家专注于软件项目绩效的咨询机构,它定义了用于衡量项目“成功”的5个指标:OnTime, OnBudget, OnGoal, Value, Satisfaction。按照这样的定义,我恐怕找不出一个成功的项目了。事实上,全球真正成功的项目也就30%左右,一半多的项目都处在“挣扎”状态。详见下图:

《项目“背锅侠”之需求分析》

当谈论起项目失败的原因时,大部分人都会“归功”于需求。“客户自己都不知道要做什么”,“功能刚做完,需求又变了”,“客户怎么不上天啊”,这些话我们都耳熟能详了。的确,需求是整个项目的基石,需求的质量直接影响着整个项目的进展。 1994年Standish Group发布了软件项目的CHOAS报告,在影响项目成功的十大要素中,需求相关的要素占比37%左右,具体是:用户的参与清晰的需求描述现实的客户期望。有趣的是在2015年的报告中,需求相关的要素只剩下用户参与这一条,占比15%。这说明需求分析的专业性20年来有了很大的提高,用户也逐渐回归理性。 94版的报告同时列出了导致项目失败的10大因素,跟需求相关的占了51.6%,分别是:不完整的需求,缺乏用户参与,不切实际的用户期望,需求变更频繁,提供了不再需要的。虽然15版中没有这项分析,但在我看来,这些因素很多依然存在,而且占比还不小。

需求分析的实践性非常强,因为面对的是用户,世界上没有两个相同的用户,所以我一般不太相信方法论。最近看了徐峰写的《软件需求最佳实践》,整本书并没有空洞的介绍一堆方法论,而是总结了很多作者自身的经验,还是值得一看的。这里我就借他山之石,摘录些个人觉比较好的观点。

需求可分为业务需求、用户需求、软件需求三个层次。

《项目“背锅侠”之需求分析》
业务需求反映的是系统的高层次目标要求,通常由企业高层管理人员提出,通常体现在两个方面:

  • 问题:解决企业运作过程中遇到的问题
  • 机会:抓住外部环境变化所带来的机会,以便为企业带来新的发展。

用户需求是指用户使用软件需要完成什么样的任务,怎么完成的。通常是在业务需求定义的基础上进行用户访谈、调查,对用户使用的场景进行整理,从而建立用户角度的需求。用户需求是需求捕获的产物,有以下几个特点:

  • 零散:用户从不同角度、不同层面、不同粒度提出的需求,很多时候是一句话需求
  • 存在矛盾:从不同角度去看业务,会有不同的需求,用户之间会存在不同的意见。

软件需求:正因为用户需求具有零散、存在矛盾的特点,需要分析人员进行分析、提炼、整理,从而生成指导开发的、更精确的软件需求。所以说,软件需求是需求分析与建模的产物。

软件需求可以分成功能需求、非功能需求、和设计约束三种类型

  • 功能需求:对功能需求而言,最关键的地方是如何对其进行组织,传统方法大多按照程序的结构(系统-子系统-模块-子模块)来梳理,这样会割裂用户的使用场景。 现代需求理论强调分析人员从用户角度,将系统理解成一个黑盒子,从横向的使用角度来整理需求,建议使用RUP的用例方法。
  • 非功能性需求:最典型有两个问题:一是信息传递的无效性,二是忽略了非功能性需求的局部性。
    • 信息传递的无效性:诸如“高可用性”,“安全性”等需求,一定要有具体的指标来说明,否则这个信息是无效的。
    • 局部性: “系统响应时间小于5秒”这样的话语要明确前提条件,系统在繁忙时段或某些复杂的查询,响应时间很有可能超过5秒。
  • 设计约束:这块内容前期很容易被忽视,而且产生的后果往往比较严重。 之前给客户做过一个小功能,因为比较简单,也没太多重视,功能需求了解完后,直接就让开发做了。做完才发现客户需要支持IE8浏览器,而目前的框架并不支持。所以,只能重新选择框架再做一遍。 设计约束主要包括非技术因素决定的技术选型,比如我之前做的外包项目,用户指定要XX用框架,那就没有别的选择了。还有就是刚讲的预期的软硬件环境。想当然的认为用户都用chrome导致了返工。

 

今天就敲这么多了,下次再补充优秀需求的标准。

点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注