如何进行IT项目的需求调研？[读后有得所以转之]
注：本文为我当年的工作手记节选——
一、如何理解客户业务和客户需求？
原则1：由粗到细，从宏观到微观。
必须先从宏观上了解客户业务的全貌，再逐步深入细节。因为对于客户的业务而言，我们是外行，如果从业务细节着手，很容易迷失方向，失去对业务核心的把握。同时要认识到，对于一个外行而言，我们对细节的深入也必定是有限的，不要指望自己能够无穷的彻底的了解每一个细枝末节。一是不可能有无限的时间给你了解，二是没有这个必要。因为未来的系统也不可能完全包办所有业务的细节，还有很多事情是要靠客户企业中这些具有专业技能的人来做的。
原则2：从不同层次的客户代表那里收集不同层次的需求
对于企业高层决策者，他会给你描述一个系统的大的功能蓝图，如使企业具有整体报价能力，能更好的服务于高端客户，能支持企业的重大业务决策等；对于企业各级管理者，他会给你讲述他这一层的管理需求，如能更好的进行部门员工的业绩考核、生成月度报表，更好的进行业务结算等；对于各级业务操作人员，他可能给你谈及很多业务细节和操作细节……
在由上到下的逐级访谈中，对未来系统的描述就从一个大黑箱变成多个小黑箱，再变成透明、明确、详细的系统定义的过程。
客户业务调研和需求分析注定是一个不断细化的过程，不要指望一次访谈/调研就能穷尽，也不要指望一次开发过程就能得到完全满足客户梦中期待的那套系统来。因为事实上很多需求是隐性的，连用户都不清楚自己的需求。只有经过多次循环细化才可能把更多隐性的不断挖掘、暴露出来。
二、如何具体开展需求调研工作？
在RUP中定义需求工作流程的工作目的如下：
1. 客户和其他涉众*在系统的工作内容方面达成并保持一致；
2. 使系统开发人员能够更清楚地了解系统需求；
3. 定义系统边界（限定）；
4. 为计划迭代的技术内容提供基础；
5. 为估算开发系统所需成本和时间提供基础；
6. 定义系统的用户界面，重点是用户的需要和目标。
[涉众]：英文stakeholder在RUP中的翻译，在项目管理专著中往往译为“干系人”，指所有与项目成败有直接间接利益关系的个人或团体。在软件项目中，往往包括企业的投资者、各级管理者、系统使用者、公司客户，甚至包括企业的合作伙伴和竞争对手。
首先要做好业务调研。要尽早把已经收集到的业务资料熟悉起来，并在理解的基础上提炼出问题列表，制成调查问卷。业务调研的要求是一定要沉下去，深入细致的了解客户的业务流程，而不是急着赶工完成自己的需求工件设计和业务模型的建立。在了解各项业务流程的同时，与客户一同深入分析业务的实现逻辑，并记录下有关的实现案例信息，收集好、整理好、分析好有关的参考材料。
要把迭代的思想贯穿于从业务调研、需求分析，乃至项目实施的始终。所谓迭代，就是我们老老实实承认我们没有能力一次就把事情做到尽善尽美。所以我们就先把一大部分有把握的地方做好，再在前面成功的基础上不断做好剩余的部分，最终就能无限接近于成功。设计编码过程是如此，业务调研和需求分析也是如此。
企业系统的设计开发与软件产品的设计开发有一个最大的不同，就是企业的需求肯定会变化，过去在变、调研的时候会变，系统实施后还会变。而我们要做的就是去适应这种变化。事实上，也正是因为我们采用的是面向对象的方法，才可能做到这一点。因为面向对象的方法认为：对象的基本属性是客观的和不会频繁变化的，而对象间的关系则是可能不断变化的。所以我们在业务调研和需求分析中也要认识到这一点，把不变的沉淀下来，把可变的灵活性和变化的自主性留给客户。
各位都是做技术的，在业务调研和需求分析中难免会不由自主的考虑一些技术实现的问题。值得强调的是：需求与技术无关。在业务调研的时候要忠实的进行记录，不要因为你个人对实现的疑虑而对用户需求进行（过早的）修改和裁减。
要善于争取客户方各级人员（均是项目干系人，RUP中称为涉众）的支持。只有得到未来系统用户的充分参与，项目才有可能最终取得成功。一套缺乏用户参与的系统，即使最后做出来也是注定没有人去用的。
一是要利用客户企业的组织关系，争取到上层的支持，由上到下进行调研配合；二是要会在调研过程中为目标用户树立有针对性的愿景，让他认同愿景的同时主动、积极的支持你的调研过程。
……
（以下内容从略）
--------------------------------------------------------
在工作过程中也碰到系统调研时不知从何入手的时候，读有所得，于是转到这里，以便以后自己忘了， :) 。
原文Url
http://www.tianyaclub.com/new/Publicforum/Content.asp?idWriter=0&Key=0&strItem=itinfo&idArticle=15482&flag=1
一、如何理解客户业务和客户需求？
原则1：由粗到细，从宏观到微观。
必须先从宏观上了解客户业务的全貌，再逐步深入细节。因为对于客户的业务而言，我们是外行，如果从业务细节着手，很容易迷失方向，失去对业务核心的把握。同时要认识到，对于一个外行而言，我们对细节的深入也必定是有限的，不要指望自己能够无穷的彻底的了解每一个细枝末节。一是不可能有无限的时间给你了解，二是没有这个必要。因为未来的系统也不可能完全包办所有业务的细节，还有很多事情是要靠客户企业中这些具有专业技能的人来做的。
原则2：从不同层次的客户代表那里收集不同层次的需求
对于企业高层决策者，他会给你描述一个系统的大的功能蓝图，如使企业具有整体报价能力，能更好的服务于高端客户，能支持企业的重大业务决策等；对于企业各级管理者，他会给你讲述他这一层的管理需求，如能更好的进行部门员工的业绩考核、生成月度报表，更好的进行业务结算等；对于各级业务操作人员，他可能给你谈及很多业务细节和操作细节……
在由上到下的逐级访谈中，对未来系统的描述就从一个大黑箱变成多个小黑箱，再变成透明、明确、详细的系统定义的过程。
客户业务调研和需求分析注定是一个不断细化的过程，不要指望一次访谈/调研就能穷尽，也不要指望一次开发过程就能得到完全满足客户梦中期待的那套系统来。因为事实上很多需求是隐性的，连用户都不清楚自己的需求。只有经过多次循环细化才可能把更多隐性的不断挖掘、暴露出来。
二、如何具体开展需求调研工作？
在RUP中定义需求工作流程的工作目的如下：
1. 客户和其他涉众*在系统的工作内容方面达成并保持一致；
2. 使系统开发人员能够更清楚地了解系统需求；
3. 定义系统边界（限定）；
4. 为计划迭代的技术内容提供基础；
5. 为估算开发系统所需成本和时间提供基础；
6. 定义系统的用户界面，重点是用户的需要和目标。
[涉众]：英文stakeholder在RUP中的翻译，在项目管理专著中往往译为“干系人”，指所有与项目成败有直接间接利益关系的个人或团体。在软件项目中，往往包括企业的投资者、各级管理者、系统使用者、公司客户，甚至包括企业的合作伙伴和竞争对手。
首先要做好业务调研。要尽早把已经收集到的业务资料熟悉起来，并在理解的基础上提炼出问题列表，制成调查问卷。业务调研的要求是一定要沉下去，深入细致的了解客户的业务流程，而不是急着赶工完成自己的需求工件设计和业务模型的建立。在了解各项业务流程的同时，与客户一同深入分析业务的实现逻辑，并记录下有关的实现案例信息，收集好、整理好、分析好有关的参考材料。
要把迭代的思想贯穿于从业务调研、需求分析，乃至项目实施的始终。所谓迭代，就是我们老老实实承认我们没有能力一次就把事情做到尽善尽美。所以我们就先把一大部分有把握的地方做好，再在前面成功的基础上不断做好剩余的部分，最终就能无限接近于成功。设计编码过程是如此，业务调研和需求分析也是如此。
企业系统的设计开发与软件产品的设计开发有一个最大的不同，就是企业的需求肯定会变化，过去在变、调研的时候会变，系统实施后还会变。而我们要做的就是去适应这种变化。事实上，也正是因为我们采用的是面向对象的方法，才可能做到这一点。因为面向对象的方法认为：对象的基本属性是客观的和不会频繁变化的，而对象间的关系则是可能不断变化的。所以我们在业务调研和需求分析中也要认识到这一点，把不变的沉淀下来，把可变的灵活性和变化的自主性留给客户。
各位都是做技术的，在业务调研和需求分析中难免会不由自主的考虑一些技术实现的问题。值得强调的是：需求与技术无关。在业务调研的时候要忠实的进行记录，不要因为你个人对实现的疑虑而对用户需求进行（过早的）修改和裁减。
要善于争取客户方各级人员（均是项目干系人，RUP中称为涉众）的支持。只有得到未来系统用户的充分参与，项目才有可能最终取得成功。一套缺乏用户参与的系统，即使最后做出来也是注定没有人去用的。
一是要利用客户企业的组织关系，争取到上层的支持，由上到下进行调研配合；二是要会在调研过程中为目标用户树立有针对性的愿景，让他认同愿景的同时主动、积极的支持你的调研过程。
……
（以下内容从略）
--------------------------------------------------------
在工作过程中也碰到系统调研时不知从何入手的时候，读有所得，于是转到这里，以便以后自己忘了， :) 。
原文Url
http://www.tianyaclub.com/new/Publicforum/Content.asp?idWriter=0&Key=0&strItem=itinfo&idArticle=15482&flag=1
