软件工程之需求管理(1)

软件工程之需求过程（好软件系列一）

---- 此文献给指望成长为软件大团队的项目经理

曾经在面试项目经理和需求人员的时候，我通常会问几个问题，请问如何作一个好需求？好需求的标准是什么？如何判断别人作需求的水平是好仍是坏？有不少回答，可是最多见的是，需求作完后，经过客户的满意度来判断。我说若是是客户满意度来回答，岂非非得等到需求过程结束后，才能获悉？都需求结束了，判断出来了又有什么用？换句话来讲，是否项目经理须要跟着需求人员作需求，才能知道需求作的好仍是很差？那既然项目经理都跟着作了，那还要需求人员干什么？是否只要一个会帮着打打字的小姑娘就能够了？

颇有意思的逻辑，貌似从这个逻辑中，咱们能够推出目前项目经理作需求更好。貌似市场上也有不少公司招聘项目经理要求会作需求。可是真是这样的吗？若是项目经理作需求，那需求人员作什么！这是糟糕的角色定位，具体分析能够参考我写的“漫谈中国软件” 。那反过来推理，项目经理不作需求，项目经理就不该该陪着需求人员去作需求，那么项目经理如何才能判断出需求人员作的需求究竟是一个好的需求仍是坏的需求？这就是我开篇提的面试问题了。这些问题不是说需求具体应该怎么作，分几步，每步怎么弄？而是在讨论作好需求的标准是什么？或者说怎么判断出需求的质量。这其实属于软件工程范畴，由于它自己没有具体细化到需求细节，更可能是以面来看整个需求过程的工艺如何。

平时在家有时会作饭，切菜工序是少不了的。太太打马虎说不喜欢，就只能我来作了。每次在切菜的时候，就想着快点。但由于菜是有各类形状，千差万别的，但老是快不起来。要不就是怕切到手指，要不就切的厚薄不匀，切切停停的。有一次看一个酒店师傅切菜，听他切菜的声音节奏感很强，就想这个师傅在切菜这个领域里颇有造诣,不是很是人。果真师傅是专业切菜工，干了不少年切菜的活。看他切出的效果和声音效果一致,很享受。

这就是工艺，切菜的工艺。咱们判断切菜的工艺水平，很简单，听，看就够了。能够想象的是，这工艺水平的菜，比较容易在锅里均衡受热，一块儿熟，口感各方面也会更好点。固然实际出菜的时候，客户的吃的口感，满意度才是最终的定论。咱们是否能够借鉴一下，理解软件工程中需求过程的工艺水平呢？

参考CMMI中需求过程的说法，一个优秀的需求标准以下：

 此处较为学术化，我用另外一个通俗维度结合个人经验来重点分享叙述。判断一个好的需求，能够从几方面入手。

一，关注需求的规划           

每个系统都是要去解决相应某领域的问题。曾见过一个MIS管理系统A，里面把全部杂七杂八的功能都作 在一个系统里，这些功能都很简单。可是当某个系统B专业解决了一块问题的时候，就把A系统的某些功能覆盖掉了。这个时候A系统很尴尬，由于他不只存在推广 浪费，功能白作的问题，还存在后续定位发展问题，系统的将来可能被替换掉。

还见过一个系统，项目一期和二期在规划上没有很好的衔接，出现二期作需求的时候，对一期项目的设计产生较大冲击，甚至严重到将一期大部分功能推到重来。这些也是没有规划的缘由。

因此好的需求，必定有一条主线去贯穿整个系统,必定是在某个领域无可替代，有发展动力和生命力的。这也是CMMI中提到的完整性体现。

二，关注需求用户场景和需求变动列表分析

在CMMI中有用户需求和系统需求，用户需求表述的用户用本身的语言来描述当前对系统的一些指望。其实通俗点说用户需求最重要表达的是系统解决的用户场景问题。用例的表述需求方式的兴起也是基于场景来设计的。

曾讨论需求变动的源头分析，大多数需求变动基本是当时场景描述缺失。

好比：用户订餐，从功能上来讲只是须要提交一个订单而已。可是从场景分析来看，用户订餐，会先去找餐厅，会先找常吃的菜，会分请情侣，商务宴请，请家人，请朋友各类场景，最后才是提交一个订单而已。咱们会发现可能作一个订单提交功能，不必定是最重要的，可能客户重点是想解决一个请人吃饭的问题。若是这个时候把提交订单功能作的出神入化岂非本末倒置？

因此判断一个需求作的好很差，其实很简单，就是抽其中一段需求内容分析其所适用的场景和目标。若是能表述很清晰，就说明需求质量很高。这也是CMMI中正确性，可行性的的体现。

三，关注需求产出物齐全

所谓“燕过留痕，人过留迹”，优秀需求人员才能作出好的需求，而作事的方式必定会有个完整的套路，就象武功高手练的“降龙十八掌”，“六脉神剑”同样也是有套路的。因此判断需求作的好很差，在一些方面也能体现出来。结合经验，总结以下：

关注目标和进度：

需求范围SOW敲定 --- 判断与客户的沟通和需求范围的控制力

需求计划 --- 判断需求过程推动顺利的标准

需求工做量投入量估算 --- 判断需求过程的控制力

 

关注深度：

需求会议纪要 --- 判断需求过程交流达成共识产物

需求问题列表 --- 判断需求过程当中双方交流的深度和水平

功能性和非功能性的需求覆盖 --- 判断需求过程当中需求完整性

 

关注外部关联：

需求评审(关联设计，测试，UI)问题列表 --- 判断需求复杂度和知识传递的效果（可选）

需求跟踪矩阵--- 需求知识传递的保障（可选）

关注结果：

需求文档确认和高仿真原型的确认结果 --- 最终判断需求过程的结果

 

基本在需求产出物齐全这块包括了CMMI中优秀的需求剩下的其它特性体现。

 

因此一个好的需求工艺，也是靠“听”和“看”就能够了，不须要直接参与。而项目经理须要的是在这个过程当中练习“听”和“看”的本领。须要关注当需求工艺某方面出现问题的时候，知道怎么解决它。例如：咱们发现SOW范围没敲定下来，就开始推动需求讨论了，那么项目经理要能判断出什么问题,以及怎么解决它。或者需求知识传递效果不太好，怎么解决，等等之类。

 

总之，对于需求过程的把控是项目经理的职责，而对于需求的实施不须要项目经理。项目经理须要花更多时间在软件工程的总体把控和客户关系的梳理上。只有这样，才能发挥团队最大做用，作出一个好需求，作出一个好软件。