软件需求调研“五步法” 收藏
摘要
客户需求，是软件生产加工的“原材料”，是团队展开工作的“依据”，是项目管理的“基石”，需求调研是获取这此基础信息的启始阶段，良好开始是成功的一半。在需求调研分析阶段，项目经理和需求分析人员无法推动需求调研，客户参与积极性不高，获取客户需求信息不完整，且没有得到客户的认可。将决定能否奠定项目成功的保障，决定软件项目实施的成败。本文介绍“B项目”需求调研不深入所造成项目经理的无奈，分析其中问题原因，归纳总结需求调研的“五步两点法”。
关键字
调研提纲，调研计划，调研文档，仿真界面
案例背景
“B项目”2007年7月份启动，发2008年3月底验收，项目实施时间仅1年时间，项目经理程正义全权负责需求调研。由于项目合同要求时间短，且与其它项目相似，在需求调研过程中，采用系统迁移方式，需求调研也是边挖掘边完善，直至于2008年3客月份，系统验收。
在验收过程中，发现经过迁移的系统架构无法满足南京卫系统架构的要求，客户的需求并不像从其它项目迁过的一样及其发展，系统验收前一个月，系统修改的工作量非常大，以至于无法验收。项目二期工作已经开始招标，作为一期的合作方，很想继续与客户合作下去，但苦于当前无法顺利验收。
在一次项目例会上，面对这样的商机及目前的情况，项目经理反思为什么出现这样的局面，究其原因需求调研不深入。
案例分析
通过以上案例，我们不难看出，使项目经理面临这样困境原因有许多方面，其中需求调研不够深入。
? 项目经理没有获得有效的需求调研，需求调研未达到预期的效果。
? 在需求收集整理过程中，有的部门提不出需求，有的部门提出需求已经严重超出范围；各个部门业务有重叠部分，有的业务有所冲突。
? 前段时间刚刚签字确认下来的需求，刚刚开始进行设计，客户接到上级的通知，政策发生了一些变化，要进行需求调整。
? 在为期半年的需求调研中，需求经过多次评审，多次变更，需求原型不知道改过多少次，但还是没有确定下来，项目进度严重延误，但他也感到很庆幸，因为还没有设计开发，变更只限于需求文档、系统原型。
在需求调研过程中，要搞清楚以下几个方面的内容：
（1）、认识用户的特点
? 用户提不出需求，没有进行专业咨询，缺乏整体规划。开发商对行业认识有限，需求难以确认，致使项目延期。
? 用户随意提需求，用户需求无人把关，没有信息监理。用户对项目实施周期认识不足，给予的实施周期过短，需求非常苛刻。
（2）、认识角色的特点
用户通常涉及到三种角色：决策人员、业务经办人员和信息中心人员，而各种角色具有个性特征：
? 决策人员。通常是管理层的领导，有决策权，偶尔出席需求调研会议，较少时间审阅需求文档。
? 业务经办人员。通常是各处室、科室的工作人员，参与具体需求调研，熟悉业务需求，但是很多业务不能拍板。
? 信息中心人员。通常是信息中心技术人员，负责系统实施工作，掌握一定的技术技能，不一定十分了解需求，无法推动需求调研进度，且在三种角色中处于最弱势地位。
综合这三种角色的特征，往往是：决策人员没时间审阅文档，不便于拍板；业务熟悉文档，但没有权限签字；信息中心人员既无权决策、又不熟悉业务，然而负责系统实施。因此，项目需求难以确认。
（3）、需求调研的特点
在需求调研过程中，我们碰到客户需求内容具有以下特点：
? 大量政策文件，大量表格、且内容分散。如在本项目案例中，客户提供书面资料有26份，且全是一本本厚厚的书，要深入熟悉这方面的需求，需要花大量的时间。
? 政策多变。今天一个会议精神，明天一个通知，后天一个新条例，政策经常发生变化，同时也引发需求变更。有时候，一个系统建设还没完成，政策可能全部发生改变，需求完全与原来的不一样，需求变更超过80%。
? 信息建设落后。在本项目案例中，客户是政府机关，有许多的C/S模式的系统在使用，这些系统相对比较落后，但功能稳定。在信息化过程中，用户习惯于将操作模式带到B/S模式下，用户根据其中知道的功能，随意增加内容。
（4）、需求交流
从需求沟通交流的角度出发，主要具有以下特点：
? 不同业务处室、或同一业务处室不同业务人员对同一个业务需求的理解不一致，交流时往往会浪费大量时间在用户自己内部争执上，甚至用户内部互相推诿，客户内部对业务需求的理解无法达成共识，开发商面临业务需求多头解释。
? 需求交流的形式基本停留在会议交流上，而且往往事先缺乏足够的准备，会议主题不明确，往往是就事论事，会议效率不高。
? 调研会议、交流计划常常因用户无法参加会议而变更，需求调研计划执行困难。
综合以上各方面的特征，客户需求具有一定的特征，但每个项目的客户需求都自有自身的特点，做好需求调研，本文概括为“五步两点”法：
第1步、理顺组织架构及沟通流程
(1)、良好的项目组织结构，是软件项目成果的保障之一，软件项目管理，要建立合理的组织结构，包括三方的组织架构：
? 开发方。根据项目目标，组建项目实施团队，明确、落实各个岗位角色职责，不能忽略QA、CM、测试人员，及兼多个项目设计开发人员的工作职责。
? 客户方。明确客户项目组织结构，参与到本项目中各个人员的工作职责，及工作配合内容。
? 第三方。根据情况，项目组可以有第三方组织介入，如：信息监理公司、客户咨询公司、软件测试等，为实现项目目标共同协作。
在本项目案例中，双方不仅设置各自的项目组架构，同时邀请第三方信息监理公司，以在双方之间进行沟通协调，在验收测试中，邀请第三方评测中心，对系统进行验收测试，以确保产品质量。
合理的项目组织结构，在关注是否有必要建议邀请第三方的同时，更加要考虑客户是否建设项目组织结构，开发方项目组织的内在结构。
（2）、明确的沟通协调流程
项目需求是双方共同理解的过程，共同理解其实也是不断沟通交流的过程，政府项目需求采集中的信息量大、原始资料多、内容多变等需求特点，要能够准确的理解这些需求，在不断提高自身素质、业务水平的前提下，更要明确沟通协调流程，以提高沟通的效率。
确定沟通协调平台。客户例会，或三方客户例会，是沟通协调的重要平台，在例会上，集中解决项目中存在的问题。对于客户例会，根据项目大小及多方协商，确定沟通的频率。关于例会的时间、地点、频率等，根据双方的协定而确定。
（2）、确定沟通交流方向。如果沟通方向不对等，项目需求发现漫延、拓展，将会引起需求范围扩大，增加项目成本，从而影响项目进度，因此要确定沟通交流方向。主要是：确定横向交流方向、确定纵向交流方向。
? 双方领导层的沟通交流。
? 项目经理与客户方信息技术负责人、业务负责人的沟通交流。
? 需求人员与客户业务人员的沟通交流。
在本项目案例中，沟通交流方向比例明确，在横向方面，主要有三个沟通协调方向，领导层、管理层、执行层；在纵向方面，也有三个沟通协调方向，开发方项目组、客户技术组、客户业务组。如图所示：“B项目沟通协调流程图”
第2步、确定需求调研计划
需求调研计划，是展开需求调研工作的开始，指导整个需求过程，在制定需求调研计划中，要全面考虑，尽量周全，能够想到的尽量在计划在内，但同时要注意如下几点：
? 确定被调研的部门、角色，具体业务人员。信息化建设是为人服务的、为管理服务的，因此，需求调研从被调研的部门角色开始，在客户方确定项目组组织架构、确定沟通协调之时、需求调研之前，要明确被调研所涉及的部门、角色。在需求调研计划中，确定参与需求调人员的姓名、联系方式等一些详细信息。
? 确定需求调研方式。需求调研方式多种多样，主要包括两种情况：
n （1）、客户描述客户要求、展示现有的手工操作、系统操作方式，主动向开发方提供信息，开发方组织需求调研，采用一对一沟通、会议、问卷等方法，使用文档、或原型来协助理解需求。
n （2）、系统改造，对相关的系统进行整理，然后向客户展示，然后组织需求调研。无论使用哪种方式，在需求调研之前，要确定下来。
? 确定调研的步骤和工作输入、输出。在本案例中，调研活动包括两个方面：
n 从文档方面有：1.讨论交流，2.业务培训，3.文档编制，4.文档提交，5.反馈修改，6文档确认；
n 从系统原型方面：1.页面设计，2.用户试用，3.反馈修改，4.界面确认；两个步骤同步进行，相辅相成。
第3步、良好调研过程文档
在需求调研过程中，涉及到许多的中间过程的文档，这些文档是形成用户需求的基础，过程文档主要包括两大类文档：
需求管理类文档：
? 需求调研计划。
? 需求调研提纲
? 需求变更申请（确认）单
? 需求跟踪表
? 需求确认书
需求调研类文档：
? 用户提交的原始需求
? 需求调研报告
? 用户交流备忘录
? 需求调研会议纪要
良好的过程文档记录，主要包括以下几大特点：
（1）、书面描述客户的需求，无论是客户口述，还是客户的想法，先以用书面的形式将录下来，这些书面的形式就是一份良好的过程文档。
（2）、不要遗漏客户的需求，作为客户需求的凭证，由于需求较多，不容易管理，有了过程文档进行记录，不容易遗漏某个想法、或某次需求。
（3）、分阶段的、逐步确认需求，每次需求都有一份过程文档进行记录，但每次都要进行一次需求确认，在一边收集、一边整理的过程中，同时也一边让客户确认。
第4步、漂亮的用户分析报告
也就是将历次的需求调研结果，经协过需求分析的而形成的结果，是客户需求的正确描述的文档，是与客户达成需求共识内容的体现，也是开发商需求调研成果的表现。“漂亮”的需求文档，主要包括以下内容：
? 正式的文档封面
? 工整规范的目录结构
? 专业的需求表述方式（SRS或者USE CASE）
? 章节内容清晰明了，行文规范
? 完整的内容（不要忘记非功能性需求）
? 有必要编制一个需求文档的说明
? 一个“漂亮”的需求文档模板，可以指导需求调研过程活动
第5步、直观的系统仿真界面
系统仿真界面，也称为系统原型，主要是描述用户的操作场景，一方面作为双方共同理解客户需求的依据，另一方面，也可以作为系统开发的原型基础，主要具有以下特点：
? 不是一些静态页面的组合，而是动态的、可操作的，直观地给客户展示操作页面。制作相对简单，修改比例方便，即需求反复变更，在开发之前，返工的工作量也会很小。
? 界面设计的前奏。作为界面设计的基础，在客户需求确定之后，就在此基础上进行设计开发，通常地说，也是一个增量式的系统原型。
? 仿真界面的签字确认，是需求确认的重要部分。在客户确认需求时，仿真界面也要得到客户的认可。
系统仿真界面，与实际系统的主要区别是：后台部分没有代码，界面基本相同，如图所示，“XX系统”的仿真界面。
小结
? 做好客户需求需要考虑的因素很多，也不可能三言两语能够说清，任何一个细节处理不当，都有可能带来风险，本文的主要是结合项目实例，将自己的体会与大家分享。
摘要
客户需求，是软件生产加工的“原材料”，是团队展开工作的“依据”，是项目管理的“基石”，需求调研是获取这此基础信息的启始阶段，良好开始是成功的一半。在需求调研分析阶段，项目经理和需求分析人员无法推动需求调研，客户参与积极性不高，获取客户需求信息不完整，且没有得到客户的认可。将决定能否奠定项目成功的保障，决定软件项目实施的成败。本文介绍“B项目”需求调研不深入所造成项目经理的无奈，分析其中问题原因，归纳总结需求调研的“五步两点法”。
关键字
调研提纲，调研计划，调研文档，仿真界面
案例背景
“B项目”2007年7月份启动，发2008年3月底验收，项目实施时间仅1年时间，项目经理程正义全权负责需求调研。由于项目合同要求时间短，且与其它项目相似，在需求调研过程中，采用系统迁移方式，需求调研也是边挖掘边完善，直至于2008年3客月份，系统验收。
在验收过程中，发现经过迁移的系统架构无法满足南京卫系统架构的要求，客户的需求并不像从其它项目迁过的一样及其发展，系统验收前一个月，系统修改的工作量非常大，以至于无法验收。项目二期工作已经开始招标，作为一期的合作方，很想继续与客户合作下去，但苦于当前无法顺利验收。
在一次项目例会上，面对这样的商机及目前的情况，项目经理反思为什么出现这样的局面，究其原因需求调研不深入。
案例分析
通过以上案例，我们不难看出，使项目经理面临这样困境原因有许多方面，其中需求调研不够深入。
? 项目经理没有获得有效的需求调研，需求调研未达到预期的效果。
? 在需求收集整理过程中，有的部门提不出需求，有的部门提出需求已经严重超出范围；各个部门业务有重叠部分，有的业务有所冲突。
? 前段时间刚刚签字确认下来的需求，刚刚开始进行设计，客户接到上级的通知，政策发生了一些变化，要进行需求调整。
? 在为期半年的需求调研中，需求经过多次评审，多次变更，需求原型不知道改过多少次，但还是没有确定下来，项目进度严重延误，但他也感到很庆幸，因为还没有设计开发，变更只限于需求文档、系统原型。
在需求调研过程中，要搞清楚以下几个方面的内容：
（1）、认识用户的特点
? 用户提不出需求，没有进行专业咨询，缺乏整体规划。开发商对行业认识有限，需求难以确认，致使项目延期。
? 用户随意提需求，用户需求无人把关，没有信息监理。用户对项目实施周期认识不足，给予的实施周期过短，需求非常苛刻。
（2）、认识角色的特点
用户通常涉及到三种角色：决策人员、业务经办人员和信息中心人员，而各种角色具有个性特征：
? 决策人员。通常是管理层的领导，有决策权，偶尔出席需求调研会议，较少时间审阅需求文档。
? 业务经办人员。通常是各处室、科室的工作人员，参与具体需求调研，熟悉业务需求，但是很多业务不能拍板。
? 信息中心人员。通常是信息中心技术人员，负责系统实施工作，掌握一定的技术技能，不一定十分了解需求，无法推动需求调研进度，且在三种角色中处于最弱势地位。
综合这三种角色的特征，往往是：决策人员没时间审阅文档，不便于拍板；业务熟悉文档，但没有权限签字；信息中心人员既无权决策、又不熟悉业务，然而负责系统实施。因此，项目需求难以确认。
（3）、需求调研的特点
在需求调研过程中，我们碰到客户需求内容具有以下特点：
? 大量政策文件，大量表格、且内容分散。如在本项目案例中，客户提供书面资料有26份，且全是一本本厚厚的书，要深入熟悉这方面的需求，需要花大量的时间。
? 政策多变。今天一个会议精神，明天一个通知，后天一个新条例，政策经常发生变化，同时也引发需求变更。有时候，一个系统建设还没完成，政策可能全部发生改变，需求完全与原来的不一样，需求变更超过80%。
? 信息建设落后。在本项目案例中，客户是政府机关，有许多的C/S模式的系统在使用，这些系统相对比较落后，但功能稳定。在信息化过程中，用户习惯于将操作模式带到B/S模式下，用户根据其中知道的功能，随意增加内容。
（4）、需求交流
从需求沟通交流的角度出发，主要具有以下特点：
? 不同业务处室、或同一业务处室不同业务人员对同一个业务需求的理解不一致，交流时往往会浪费大量时间在用户自己内部争执上，甚至用户内部互相推诿，客户内部对业务需求的理解无法达成共识，开发商面临业务需求多头解释。
? 需求交流的形式基本停留在会议交流上，而且往往事先缺乏足够的准备，会议主题不明确，往往是就事论事，会议效率不高。
? 调研会议、交流计划常常因用户无法参加会议而变更，需求调研计划执行困难。
综合以上各方面的特征，客户需求具有一定的特征，但每个项目的客户需求都自有自身的特点，做好需求调研，本文概括为“五步两点”法：
第1步、理顺组织架构及沟通流程
(1)、良好的项目组织结构，是软件项目成果的保障之一，软件项目管理，要建立合理的组织结构，包括三方的组织架构：
? 开发方。根据项目目标，组建项目实施团队，明确、落实各个岗位角色职责，不能忽略QA、CM、测试人员，及兼多个项目设计开发人员的工作职责。
? 客户方。明确客户项目组织结构，参与到本项目中各个人员的工作职责，及工作配合内容。
? 第三方。根据情况，项目组可以有第三方组织介入，如：信息监理公司、客户咨询公司、软件测试等，为实现项目目标共同协作。
在本项目案例中，双方不仅设置各自的项目组架构，同时邀请第三方信息监理公司，以在双方之间进行沟通协调，在验收测试中，邀请第三方评测中心，对系统进行验收测试，以确保产品质量。
合理的项目组织结构，在关注是否有必要建议邀请第三方的同时，更加要考虑客户是否建设项目组织结构，开发方项目组织的内在结构。
（2）、明确的沟通协调流程
项目需求是双方共同理解的过程，共同理解其实也是不断沟通交流的过程，政府项目需求采集中的信息量大、原始资料多、内容多变等需求特点，要能够准确的理解这些需求，在不断提高自身素质、业务水平的前提下，更要明确沟通协调流程，以提高沟通的效率。
确定沟通协调平台。客户例会，或三方客户例会，是沟通协调的重要平台，在例会上，集中解决项目中存在的问题。对于客户例会，根据项目大小及多方协商，确定沟通的频率。关于例会的时间、地点、频率等，根据双方的协定而确定。
（2）、确定沟通交流方向。如果沟通方向不对等，项目需求发现漫延、拓展，将会引起需求范围扩大，增加项目成本，从而影响项目进度，因此要确定沟通交流方向。主要是：确定横向交流方向、确定纵向交流方向。
? 双方领导层的沟通交流。
? 项目经理与客户方信息技术负责人、业务负责人的沟通交流。
? 需求人员与客户业务人员的沟通交流。
在本项目案例中，沟通交流方向比例明确，在横向方面，主要有三个沟通协调方向，领导层、管理层、执行层；在纵向方面，也有三个沟通协调方向，开发方项目组、客户技术组、客户业务组。如图所示：“B项目沟通协调流程图”
第2步、确定需求调研计划
需求调研计划，是展开需求调研工作的开始，指导整个需求过程，在制定需求调研计划中，要全面考虑，尽量周全，能够想到的尽量在计划在内，但同时要注意如下几点：
? 确定被调研的部门、角色，具体业务人员。信息化建设是为人服务的、为管理服务的，因此，需求调研从被调研的部门角色开始，在客户方确定项目组组织架构、确定沟通协调之时、需求调研之前，要明确被调研所涉及的部门、角色。在需求调研计划中，确定参与需求调人员的姓名、联系方式等一些详细信息。
? 确定需求调研方式。需求调研方式多种多样，主要包括两种情况：
n （1）、客户描述客户要求、展示现有的手工操作、系统操作方式，主动向开发方提供信息，开发方组织需求调研，采用一对一沟通、会议、问卷等方法，使用文档、或原型来协助理解需求。
n （2）、系统改造，对相关的系统进行整理，然后向客户展示，然后组织需求调研。无论使用哪种方式，在需求调研之前，要确定下来。
? 确定调研的步骤和工作输入、输出。在本案例中，调研活动包括两个方面：
n 从文档方面有：1.讨论交流，2.业务培训，3.文档编制，4.文档提交，5.反馈修改，6文档确认；
n 从系统原型方面：1.页面设计，2.用户试用，3.反馈修改，4.界面确认；两个步骤同步进行，相辅相成。
第3步、良好调研过程文档
在需求调研过程中，涉及到许多的中间过程的文档，这些文档是形成用户需求的基础，过程文档主要包括两大类文档：
需求管理类文档：
? 需求调研计划。
? 需求调研提纲
? 需求变更申请（确认）单
? 需求跟踪表
? 需求确认书
需求调研类文档：
? 用户提交的原始需求
? 需求调研报告
? 用户交流备忘录
? 需求调研会议纪要
良好的过程文档记录，主要包括以下几大特点：
（1）、书面描述客户的需求，无论是客户口述，还是客户的想法，先以用书面的形式将录下来，这些书面的形式就是一份良好的过程文档。
（2）、不要遗漏客户的需求，作为客户需求的凭证，由于需求较多，不容易管理，有了过程文档进行记录，不容易遗漏某个想法、或某次需求。
（3）、分阶段的、逐步确认需求，每次需求都有一份过程文档进行记录，但每次都要进行一次需求确认，在一边收集、一边整理的过程中，同时也一边让客户确认。
第4步、漂亮的用户分析报告
也就是将历次的需求调研结果，经协过需求分析的而形成的结果，是客户需求的正确描述的文档，是与客户达成需求共识内容的体现，也是开发商需求调研成果的表现。“漂亮”的需求文档，主要包括以下内容：
? 正式的文档封面
? 工整规范的目录结构
? 专业的需求表述方式（SRS或者USE CASE）
? 章节内容清晰明了，行文规范
? 完整的内容（不要忘记非功能性需求）
? 有必要编制一个需求文档的说明
? 一个“漂亮”的需求文档模板，可以指导需求调研过程活动
第5步、直观的系统仿真界面
系统仿真界面，也称为系统原型，主要是描述用户的操作场景，一方面作为双方共同理解客户需求的依据，另一方面，也可以作为系统开发的原型基础，主要具有以下特点：
? 不是一些静态页面的组合，而是动态的、可操作的，直观地给客户展示操作页面。制作相对简单，修改比例方便，即需求反复变更，在开发之前，返工的工作量也会很小。
? 界面设计的前奏。作为界面设计的基础，在客户需求确定之后，就在此基础上进行设计开发，通常地说，也是一个增量式的系统原型。
? 仿真界面的签字确认，是需求确认的重要部分。在客户确认需求时，仿真界面也要得到客户的认可。
系统仿真界面，与实际系统的主要区别是：后台部分没有代码，界面基本相同，如图所示，“XX系统”的仿真界面。
小结
? 做好客户需求需要考虑的因素很多，也不可能三言两语能够说清，任何一个细节处理不当，都有可能带来风险，本文的主要是结合项目实例，将自己的体会与大家分享。
