项目管理——需求

需求在整个项目生命周期中占据很重要的部分。需求分析阶段的结束并不能代表需求工作的完全结束。但是确实需求工作中的核心。

一、立项阶段

必须完成：成体框架，功能模块

待定：功能模块下的具体操作尽量做多少是多少；界面风格，每个阶段的成品中不断与客户确认。

完成需求调查表，需求规划书，先内部审核研究可行性，最终确立需求调查表，需求规划书，可行性分析这些文档。即有项目原型。

再外部与客户审核，确立则可以签合同，项目正式立项。着手深入需求分析。

二、需求分析注意

1.根据不同的业务，涉及的相应部门，不同的途径去了解需求。

高层：着重宏观问题，如研发目标，宏观统计报表，决策支持能力等。不用过多涉及细枝末节。

中层（各项业务流程、功能模块的需求决策者）：着重软件带来的具体效益，如功能的定义，业务流转的衔接，查询报表的设计。不用过多涉及业务流程的细节。

基层（每一项业务流程的操作者）：需求调研的重点对象。寻找那些业务涉及面广，经验丰富，又有一定大局观的真正的基层人员。

2.项目目标必须明确

例如 我认为研究院那个项目，他就是为了有比现有系统更灵活的，尤其是在数据库的存储方式上，做到灵活获取动态季报。系统操作上追求录入方便，准确率高。

3.注意业务多元化，需求个性化的调研

即同一个业务功能，在不同的级别的角色下有不同的处理流程。解决方式无非两种，照旧设计，但是这会加大我们工作量。或者降低多元化需求，和高层以及相关部门专项商讨，标准化管理。

4.专业分析

签订合同前，我们应明确客户的希望达到的项目预期，而我们给出的应该是对预期做出的解决方案。

三、    需求

需求分析流程

需求分析就是一个不断迭代，反复的过程。不断地  需求捕获-->需求整理-->需求验证

需求捕获：

需求分析的问题源头是需求捕获不完整  

避免：（1）专业态度 ，筛选性的总结

    （2） 挖掘客户没有说的需求和客户没有想到的需求。

没有说的需求：客户的专业领域算是非常熟悉的，约定俗成的内容。导致客户忘记说了。这就需要去了解业务，每个业务执行的目的和作用是什么

没想到的需求：换位思考，提前发掘需求。或者说，客户没有参照物，原型。

需求整理：

宏观：UML用例模型： 功能角色分析  

即系统为用户提供了哪些功能，这些功能是为哪些用户服务的

微观：细化需求： 业务流程分析与业务领域分析 

1.业务流程分析：分析业务流程中哪些是需要信息化管理的，而哪些则不需要；流程差异化分析

2.业务领域分析 ：客户现有的业务知识，客户现有的业务流程是什么样的，都有些什么操作？客户在业务中都有些什么事物，什么专用名词，都是怎样定义的，相互之间的关系是什么？客户在每一项操作中的目的是什么，为什么要这样做，他们制作的手工报表都说明了什么问题？

为什么要有业务领域分析：客户存在的最大问题就是提不出正确的需求：

（1）由于对软件不了解，客户提不出需求，不知道软件最终会做成什么样子。

（2）能提出一些业务需求，但当软件做出来摆在自己面前时，需求就变了。

（3）能非常详细地提出业务需求，甚至有时候该怎么做的提出来了。

需求验证：对需求理解是否正确的信息反馈 

总结：需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。

参考： http://blog.csdn.net/zhangtao__a/article/details/8486322

扩展：ERP系统