电子政务平台需求开发 建设方案

2010-08-12 作者：张以海 来源：张以海的blog

一、项目概述
某某区电子政务平台将是某某区区域性政府的综合电子政务应用平台，平台将为区各级机关用户提供统一的用户认证、应用导航、门户服务，统一的集中式用户数据管理和应用逻辑管理，属于较复杂的大型综合信息系统。在区域性电子政务建设中，由于建设周期较紧张，建设者的期望较迫切，对需求开发和管理的要求较高，则平台总体的架构设计和需求调研、需求开发工作非常重要，决定着平台建设最后效果的贴合性、实用性。
本文档将从某某区电子政务平台建设的实际特征和实际需要出发，结合公司在IT行业从业经验以及在区域性电子政务需求开发中的经验，并结合CMM/CMMI 软件能力成熟度模型，对某某区电子政务平台的需求开发和需求管理过程进行给出一定建议。

二、需求总体范围
对需求范围的梳理决定了需求调研的目标准确性。本期电子政务建设的需求范围包括如下等部分的内容。
其中区统一办公平台将是其和核心的业务支撑系统，也是本期电子政务建设需求开发的重点内容。

三、需求工程简介
按CMM/CMMI软件能力成熟度的定义，需求是开发方和客户方就系统未来所达到的功能和质量所达成的一致约定和协议。而在电子政务建设中，不充分的、不完全的、错误的和模糊的系统需求是主要的和将要发生的系统问题的来源。需求工程（System Requirement Engineer Management）是对系统需求进行开发、定义、控制、跟踪和管理，以便更好开发和管理系统需求的综合工程过程。
需求工程是由需求开发、需求管理两部分组成。整体需求工程过程在项目启动后开始，进行需求获取、分析、规划化定义和需求验证，并进行组织内外的需求评审，以确定需求基线，并在需求发生变更时，重新进行需求的获取、分析、定义和验证评审，并对需求变更影响项进行相关识别、风险应对、修改和跟踪。并对需求状态和变化过程进行统计分析和测量汇报。需求工程由以下规程组成，如下图所示意。

1） 需求开发规程：分为需求获取、需求分析、规格化定义和需求验证等操作过程。
2） 需求评审规程：对完成的系统需求进行组织内外评审的过程；
3） 需求变更管理规程：需求基线产生后对需求进行变更管理的过程；
4） 需求跟踪管理规程：对需求进行状态跟踪和过程跟踪的管理过程；
5） 需求的测量和分析：对需求状态和需求变化过程进行测量和分析评估的管理过程；

四、需求分类方法推荐
1. 功能匹配性分类方法
合理的需求分类方法便于分类别、分层次确认需求内容、需求级别。功能性需求分类方法按照需求对于目标组织业务匹配程度和对于目标系统的功能匹配程度进行分类，从探索层次和分类方法上可以分为如下四类。
1) 业务和用户需求( Business Requirement)：指客户方的整体组织特征和整体性业务规则，以及单个操作用户（群）的操作规则和操作过程。反映了组织机构或客户对系统、产品高层次的目标要求。
2) 功能操作需求：由于业务需求的需要在系统功能上必须予以拓展或补充实现的需要，功能需求描述了系统所展示的可观察的行为，并且大多数是处于“执行者――系统”响应顺序的环境中。功能需求定义了系统应该必须额外做什么。这里包含了系统的功能操作实现、数据约束实现、外部接口实现等。比如因为需要验证用户身份，所以需要采用用户名密码机制。
3) 质量属性需求：对系统如何能很好地执行某些行为或让用户采取某一措施的陈述就是质量属性，这是一种非功能需求。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；包括系统的性能要求等。比如：快捷、简易、直觉性、用户友好性、外部接口清晰性、健壮性、可靠性、安全性和高效性。
4) 非技术需求：以上三类都可以称为技术需求，相对而言非技术需求是指系统基于当前项目环境所需尊照的一些约束和限制，包括交付日期、成本约束、特殊约定等、开发人员在软件产品设计和构造上的限制等。
2. 需求适用性分类方法
需求适用性分类方法是指从业主方需求的通用型和组织适用层次的角度对需求进行分类和路径探索。
1）基础服务需求：是指基于全局电子政务建设所需要的各种基础应用需求和服务需求，包括区域性电子政务建设的基础中间件平台和服务平台。
2）通用信息化需求：指能够满足全区性通用信息化需要的系统需求，这类需求具备较强的通用性、全局类似性。
3）专用信息化需求：是指相对通用信息化需求而言，较为条线专用、各单位专用、小范围专用的系统需求。
4）拓展性信息化需求：相对前三项而言，基于系统不断发展和远期建设需要所需考虑的信息化应用需求。

五、需求开发方法推荐
1. 5W1H需求探索体系
5W1H方法获取和分析：Why，What，Who，When， Where，How
a) WHY：为什么用户要引入系统，引入新的信息系统对用户有什么帮助，在总体工作效能上如何实现一个最终的结果？在系统的定位和建立上，建立一个明确的最终目标，以及对系统能够产生的价值愿景的分析和描述。
b) WHAT：这个系统要做什么？实现什么？把系统划分成各功能模块，逐步弄清模块流程需求、功能需求、结构需求。
c) WHO、WHEN、WHERE：细分系统的用户需求，分析什么人，在什么时间，什么阶段可以或必须操作这个功能，结合前面的WHAT分解，理清系统的流程阶段划分，记录并分析系统功能实现的细节，可以产生系统需求的用例图。
d) HOW：考虑怎样实现系统了，包括系统的概要架构和界面设想，分析系统的需求，考虑下阶段的设计、实现工作。
2. 用例驱动和场景分析
用例（Use Case）是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果，也是系统的一组使用场景，每个场景描述了一个业务执行时间的序列和规则。单个用例一般由涉众、前置条件、基本路径、扩展路径、后置条件等组成，下图为一个系统用例的示例。
<为word图片，后续上传，备索 >
3. 需求开发的十种常用方法
1) 需求调查：采用需求调查表进行需求收集和调查；
2) 需求访谈：进行面对面的需求访谈、记录、整理并确认；
3) 资料收集和文档考古：收集业主方的有关资料进行分析提炼；
4) 需求研讨：召开需求研讨会有目的的对需求进行研讨；
5) 需求头脑风暴：发散式的对需求进行遐想和探索；
6) 需求原型：依据需求原型进行需求沟通和探索，是电子政务行业常用的需求开发方法；
7) 实地学习：实地深入业主方业务现场进行观摩学习，以提炼需求；
8) 实务跟踪/实地工作：更加深入的跟踪现场多个实物，甚至深入业主方现场进行实地、实务长时间、多案例的实地工作；
9) 案例讲述和故事板：通过对案例或故事的讲解和分析获取需求；
10) 场景模拟/角色扮演：通过模拟一个场景或者由不同人员扮演不同的角色进行需求模拟和角色分析，来获取需求。
以上常见的十种需求开发方法，建议在某某区电子政务工程中根据各业务系统的实际特征分别采用，也可以联合使用。

六、本项目需求工程建议原则
由于本期某某区电子政务综合应用平台是一个大型的综合信息化工程，建议本期某某区电子政务平台遵循以下的需求工程原则。
1. 重视需求、机制保障
要对本期电子政务系统的需求进行很好的开发和管理，首先要重视需求，这里包括从上到下重视，包括领导层的重视和业主方需求负责人员的重视。
然后就需要为求工程配备相应的机制和人员保障，为每个要业务系统配备专门的2名以上业务需求负责人，为每个要实施的机关单位配备2名以上的单位需求负责人，专人专用，保障业主方需求开发团队的形成和稳定。
遵循信息化行业的二八原则，80%的需求来自于20％的关键用户群，在本期电子政务建设过程，需要很好的识别这20％的关键用户群，并保障这些关键用户能保障充分的资源和时间投入。
2. 分为概要需求和详细需求两阶段
建议把整体某某区电子政务平台的需求开发分为两个阶段：
1） 概要需求阶段：这个阶段的目的主要是确定整体应用的需求范围，以及每个需求的概要轮廓，大概需要半个月的时间。
2） 详细需求阶段：围绕该要需求阶段确定的需求范围和需求轮廓，分别对各业务需求大类进行详细调研和需求开发，以分别得出各业务应用的详细需求，大概需要1.5个月的时间。
3. 业务需求先行
电子政务的成功在于三分电子、七分政务，需求的完整、正确程度很大程度上取决与业主方基础工作的成效情况。建议在进行详细需求开发前，业主方各涉及业务条线、各业务单位进行详细的业务需求疏理和准备，当然这些准备需要在承建方的大力支持下进行。以帮助各业务单位疏理自己单位的业务范围、信息化范围、业务数据、业务规则和实际需要，并形成纸张化文档作为业务需求的基础。
4. 以原型法为需求开发主要方法
原型法是一种快速、形象、准确的需求开发方法，便于某某区电子政务平台发挥后发优势，并站在前人智慧的肩膀上前进。所以本期某某区电子政务建设的需求开发建议以原型法为主要的需求开发方法。可以根据区内各业务系统的不同需要酬情采用如下几种需求原型方法。
1) 产品原型法：以承建方成熟的现有产品为原型，进行需求的对照分析、对照研讨、差异性分析、取舍点分析、优化点分析。
2) 案例原型法：以承建方以前的案例或者业主方以前的应用案例为原型，进行需求的对照分析、差异性分析、取舍点分析、优化点分析。
3) 抛弃原型法：由承建方快速开发一个将被抛弃的系统作为需求原型进行需求研讨和需求开发。
4) 增量原型法：由承建方先行构建某业务系统的一部分功能作为需求沟通原型，以便对该系统的整体需求进行完整开发。
5) 界面原型法：由承建方提供示意性的系统界面原型和关联关系，对系统需求进行探索和开发。
5. 多种需求开发方法联合使用
建议在本期某某区电子政务建设中采用多种需求开发方法联合使用，做一定的需求调查、需求访谈，结合一定的资料收集分析工作，再参照需求原型，对需求进行研讨、发散式探讨，再结合一定的实地学习、业务跟踪，进行场景分析、案例对照、业务模拟，以完成完整的需求从脉络到概要、从概要到细节，从无形到有形的规格化需求开发和管理过程。
6. 由点到面、试点先行
由于某某区电子政务应用是一个区域性群体单位、群体业务的联合电子政务影音案例，建议本期电子政务建设遵循有点到面、试点先行的原则，建议先条线信息化需求迫切、业务应用较娴熟的业务类型和业务单位进行需求开发，如区府办的公文应用，再取得阶段性进展后再行推广开来。
7. 对需求进行分类和优先级排序
遵循信息化行业的二八原则，系统80％的应用效果来自于其20％的系统需求，所以需要依据需求的客户期望值、实现成本比、紧迫性分析，对每个需求确定四级级别：必须、重要、一般、不重要。并对需求结合上面章节中的需求分类方法进行需求分类。
8. 明确需求的稳定性和风险应对
软件系统80％的问题来自于需求的不确定性和不稳定性，需要对每个需求进行稳定性分析，对需求的稳定性分为四级级别：固定、稳定、不稳定、不确定，对于后两级别需要指定相应的需求不稳定性风险应对计划。
在电子政务行业，需求的稳定性又取决与该业务的覆盖程度（通用程度）、主办单位的行政权限和协调力度、该业务的内部成熟性、该业务的外部稳定性、该业务的信息化迫切程度、该业务对应技术的稳定性等因素。
9. 明确需求的规格和属性信息
需求的属性信息包括需求的编号、业主单位、业务类型、发现日期、业主方负责人、记录人、需求的状态（提出、规格化、已评审、已确定等）、关联需求、需求的输入、输出、处理逻辑、前置状态、后置状态、变更历史等信息，明确需求完整的属性信息有利于准备标识需求的相关信息，并对需求进行规格化疏理，追溯需求变化。并使系统建设遵循统一的需求描述方法和规格结构。
10. 重视需求确认和评审工作
需求的确认和评审是保障需求是否能真正符合实际需要和用户需要的最后环节，建议明确需求的评审和签字制度。
11. 重视需求的管理和跟踪工作
建立需求跟踪矩阵，管理确定的需求，跟踪需求的状态变化，确认需求最终被开发和实现并运行。
12. 重视需求的变更审批和跟踪工作
需求的变更如果管理不善将是电子政务系统建设的恶梦，加强对需求的变更管理和变更审批是为了保障需求的严肃性、需求变更的充分跟踪，并保护业主方的需求变更效果和开发方的需求变更行为，保护双方的合作关系，保障需求的完整性、稳定性，保障系统的最终应用效果。

七、需求工程的建议主要过程
1. 确定需求范围和目标
确定需求范围，启动需求工程；
在组织内探讨需求和产品原型，会通组织内的专业人员、业务人员对产品原型进行探讨和学习；
2. 分析需求范围，准备调研素材
分析目标组织特征和业务特征、需求特征，准备需求调研策略，进行需求调研前沟通和规划;
如有必要需要制定需求调研计划和需求调研问题清单，如有必要准备需求调研表格和需要演示原型
3. 进行需求开发，获取需求和素材
适当时可召开需求启动会议，分发需求调研表格；
进行用户访谈、实地学习、需求研讨、原型研讨、实务跟踪，以识别、针对、确定需求；
并可以记录调研活动记录和收集材料记录，需求获取的相关方法参考以上章节论述。
4. 分析获取到的信息和资料
依据需求调研过程收集到的资料和记录，进行需求框架梳理、需求分解梳理、关键需求甄别；
并进行业务需求、用户需求到系统功能需求的转化定义，并确定系统非技术需求部分。
必要时可以绘制关联图、创建开发原型、分析可行性、进行需求编号、确定需求优先级、为需求建立模型、编写数据字典等。
5. 撰写需求规格说明书草案
根据需求分析和条理化结构，依据需求规格说明书模板，撰写需求规格说明书草案；
并提交需求分析报告草案给客户方代表、涉众用户和内部相关人员，并进行持续修改；
6. 进行需求验证
并进行需求的一定验证，包括用例分析，技术验证、需求模拟、实务跟踪对照等方法；
可选：适当时可以开发界面原型、系统原型或系统主体功能部分，提交客户方核心用户验证系统需求；
7. 必要时：进行补充开发
必要时补充调研系统需求，补充收集需求资料，以完善需求、澄清分歧，达到对需求的初步一致认定；
8. 形成需求规格说明书
根据前期反馈和补充需求调研结果，对需求分析报告初稿进行修改；以形成《需求规格说明书》；
对项目需要进行细化拆分形成《概要需求列表》，含系统的功能点细化；每个需求功能点的开发工作量<3个人天；
提交并召集业主方、供应商一起评审以上需求文档；
9. 需求跟踪和管理
采用需求跟踪矩阵，对需求状态进行跟踪，对需求整体规模进行跟踪；
10. 需求变更审批和跟踪
成立需求变更审批小组，对于影响较大的，超过一定工作量阀值的需求进行变更审批；
并跟踪需求变更同意或否决后的影响和应对措施进行跟踪。