在进行需求调研的过程中，用户提出的很多需求都是在项目范围之外的，这该怎么办呢？这样做我们会亏死的啊，亲。
用户的需求不能漫无边际，所有的需求都应该在项目范围之内，搞软件的都知道这一点，但是，并非所有的用户都知道这一点。为了做好需求控制，需求分析者在进行需求调研与分析的过程中就要时时刻刻将这种观点向用户灌输，只要持之以恒坚持不懈，无论多么难缠的用户都会逐渐接受你的观点——谁都要混口饭吃嘛，这个道理容易理解。
接下来要做的是，让用户知道需求边界在什么地方。首先想到的自然是合同，行走商场当然以合同为准，合同要我们干什么我们就干什么，合同没有的我们就不干，这话说得是在理，不过在实际工作中往往是另外一个样子。先了解一下项目合同是怎么来的吧，一般来说，项目合同都是销售、售前在客户那边将胸脯拍得震天响，恨不得连制造航母、氢弹的活儿都答应了，然后才签下来的（不要责怪他们，不这样签不到单，你们都得喝西北风），在这种情况下很难在合同中对项目的范围进行非常明确的规定——销售没那么傻，自然知道根据自己拍胸脯的内容签合同一定是死路一条，只能将合同签得模模糊糊了。因此，让我们先打消通过合同来控制项目范围的想法，即使有些项目的合同签得比较规范，合同中将项目的范围基本确定了，也不可能详细到每个功能的每项需求、每个规则，如果有，这恐怕是个外包开发合同，不大可能是个做信息管理系统的合同。
为了让用户理解需求边界，首先要确定好项目目标，这个目标应该是在项目启动时双方经过讨论达成的共识，后面所有的工作都应该围绕这个目标开展——这件事主要是项目经理的职责，如果这事没做或没做好，项目经理难辞其咎。对于需求分析者来说，要对这个项目的目标了然于心，如果目标不清晰，就要想办法去了解，或者促成相关人员确定好目标。当然，也没有必要把确定目标这件事看得过于严肃刻板，未必就一定要通过规范文件来确定目标，也未必一定要通过非常正式的会议讨论确定目标，关键是大家在内心深处能否达成共识，只要能达到共识，在饭桌边、电梯中的讨论都有用，不能达成共识，写下来签字画押也意义不大（国情决定了，在称兄道弟的过程中达成的谅解比签字画押的文件要有用得多）。
有了清晰的目标后，只要用户的需求偏离了这个目标，就立即指出来这个需求超出了边界。原则是，宁可在这个阶段的目标实现了以后再设置新目标，也不要不停地修改一个目标，甚至根本不把目标当回事随意践踏。需要注意的是，如果用户的需求超出边界，需要尽早指出来，越早越好，最好在他刚提出来时就果断、坚决地一把拍死，这样用户就能够体会到你的边界之墙，如果拖拖拉拉，态度暧昧，今天说可以做明天说不可以做，就会让用户生疑，逐渐就会觉得你这个人拿三架四的，不是真心为他服务。这种想法一旦形成，你要想再扭转过来就难了，从此以后你在这里的工作会越来越难做，你想砍掉任何一项需求都将是个异常艰巨的任务，许多初学者就是这样把自己与项目一起带入深渊的。
来个简单的案例——
某公司需要开发一款OA系统，小王经过需求调研后，将用户的需求做了整理，总结后大概包括这些需求点：
1)发布通知公告、新闻。
2)内部信息发布，包括内部消息推送，内部邮件发送，内部论坛。
3)内部通讯，包括内部即时通讯，文件传输，群聊，发送短信。
4)采购申请审批流程。采购单审批通过后需要推送到现有的ERP系统采购模块。
5)物品领用申请审批流程。物品领用单审批通过后需要推送到ERP系统库存模块。
6)单据 销审批流程。 销单审批通过后需要推送到现有的财务系统。
7)请假审批流程。
8)用车申请流程。
9)会议室申请流程。
10)公文管理，包括收文、发文管理。
11)工作计划与工作日志。
12)管理客户信息，设置拜访计划，登记拜访记录，登记客户服务日志，录入客户投诉记录。
小王经过分析后，向用户指出：管理客户的需求，明显属于CRM系统的范畴，这是个OA项目，明显超出了项目范围；将信息向ERP、财务系统推送的需求，由于不在这一期的目标中，建议先不考虑，在下一期再考虑如何整合这些不同系统的信息。
*************************************
更多关于软件需求分析、产品设计的内容， 杨长春新书《实战需求分析》
微博：@无锡杨长春
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！