需求文档中容易出的错误

需求文档中容易出现的主要问题：

1、需求缺失

2. 需求不明确

 

本周开会的时候，PMs分享了三个案例，其中有两个谈到需求不明的情况。第三个项目是Agile实施项目，不存在需求不明的情况。其原因，我猜测由于甲方主导的Agile的项目，因此，需求方面主要掌握在甲方，甲方管理更好一些。

总的来说，需求不明几乎是所有项目的通病。下面的内容有点飘，叔思维一直是这样，将就了。

需求的不明晰，要区分是需求范围不清晰还是需求内容不清晰。因为这两者有本质的不同。

那么何为范围不清晰呢？我举一个典型的例子，有公司在承接一个政府项目的时候，其需求就是为XXXX，建设一个智能的城市。这里何为智能，为何城市，或者城市的构成是哪些？哪些需要智能？ 完全是模糊的，无法界定的。

另一个例子，某个汽车公司需要开发一套质量管理系统，那么，这里可能出现的需求不清晰就是需求内容的不清晰，而非需求范围的不清晰了。

那么，针对上面的两种不清晰，有哪些方式可以来解决呢？

第一种出现范围的不清晰的主要原因是，甲方无法提出可实现，或可执行的方案，或者说整个项目在业务层面，没有一个对应可运营的商务方案。再简单一点说，连客户自己都没有想清楚怎么做。因此，第一步要做的是：先立项进行业务需求的调研和业务方案（不是技术方案）的制定。（我觉得很多时候是创新，因为如果有现成的业务模型，抄也抄出来一个了。）从这一点来说，需求分析师需要跟业务架构师一起来完成业务的创新。 但在中国业务架构师还是属于一个比较新的行业，认可度还比较低。 很多公司不认同业务创新的价值，更多是以抄方案，胡乱编写一个业务来完事。

之前我遇见一位投资人，投资了互联网农业，在整个业务过程中，连盈利点都无法清晰描述出来，跟别说什么是成本结构，什么是利润流这些东西了。结果就是1000多W的投资，两年耗尽。

 

第二种情况是最普通，其实也是最好解决的问题，因为需求内容是可以在实施开发过程中进行细化的。

我的经验是：不要过于依赖SOW的东西，多数签署的都是需求范围，不要跟客户斤斤计较。在实施项目开始的时候，再做一轮需求调研，将需要实施或者开发的东西具体的约定下来。

以下是需求的检查单：

 

回到需求文档上来，

在需求文档的编写方面，主要有两种描述方式：自然语言和模型化描述。 两者各个优劣，通常的都是hybrid。以前我写需求文档的时候很不注意措辞和结构，总是觉得这东西不重要，看懂代码才是真。有一位师兄就讲过一个故事，当年他在一家公司里面做主程，来了几个小弟小妹跟着他，他就说请大家把需求文档去学习一遍，结果，只有一个小妹把需求文档给完整的给读了一遍，后来这师兄要离职，领导就问谁能接替他的工作，他就推荐这个小妹上去了。这，让人情何以堪。

总的来说，需求文档是实施，开发的一个基础中的基础，没有这个，其他所衍生的东西都不可能做好。好了，屁话一堆。

对自然描述的语言来说，可能有哪些问题值得注意呢？ （这里叔直接拷贝IREB书上的内容了。）

• 笼统的描述无法体现整个过程细节

 

• 没有限定，或模糊的名词定义

 

• 通用的量词造成无法界定的范围

 

• 不完整的条件约定

 

 

• 不完整的过程描述

 

当然，现在很多的企业都推崇的是Agile开发，因此正儿八经来写需求文档的人是少多了。 叔上半年是开发，下半年是顾问，一会是Agile实施，一会是Package solution。。总之，到哪个庙，唱哪段经。去年在某马汽车公司时候，跟德国的顾问一起工作，那是被震惊了一次，一个物流跟踪的项目，20多页的需求文档（没有啥口水话，几乎没有图形，只有表格），第一感觉非常详细。但也不是说没有问题，那就顾问把设计的活都给干了。呃，这个。。。。让架构师情何以堪？ 一般我们都是延迟设计，不要在需求文档里面去做方案设定。

 

模型化的需求文档格式以后再说了，就到这里。