探索管理与信息化发展和谐之路

       项目经理组织举行用户需求的同行评审会议，同行评审会议由项目经理和系统分析员以及项目经理确定的相关涉众人员参加。如果该需求文档通过了评审，则由项目经理与客户代表共同对该需求文档进行最终确认，并由客户代表和项目经理签字认可。如果该需求文档未通过评审，则由需求开发人员继续调研，修改《用户需求说明书》并更新《用户需求列表》作为附件，直到其通过评审，再由项目经理与用户签字认可。签字认可的《用户需求说明书》即作为需求基线的组成部分，由配置管理人员迁入受控库的基线区建立需求基线，标明其版本，并对其进行严格的配置管理。

       在完成《软件需求规格说明书》后，同样要举行相应的需求同行评审会议，最终签字认可的《软件需求规格说明书》并《软件需求列表》也作为需求基线的组成部分，由配置管理人员迁入受控库的基线区建立需求基线，标明其版本，并对其进行严格的配置管理。

       需求跟踪：《用户需求说明书》和《软件需求规格说明书》一旦经过需求确认后，项目经理则开始按照《需求跟踪规程》，并根据《软件需求列表》中对应的业务功能点，对该软件需求中涉及到的每个业务功能进行跟踪，动态更新《需求跟踪报告》。 《需求跟踪报告》每周至少周期性的更新一次，当项目变更或者项目经理发现需求与项目实施过程存在不符合项时，也要及时更新《需求跟踪报告》。在项目进入每一个里程碑阶段（基线阶段，比如单元测试、系统测试、预结项等）时，也要更新《需求跟踪报告》。并相应的组织人员更改所有相关需求文档（包括《软件需求规格说明书》并《软件需求列表》以及其附件），以及相应的工作产品，如程序编码和测试用例等，使得每一个软件的需求均能够与后续工作成果保持一致。

       需求变更控制：需求变更按照严重程度，分为I、II、III级变更。I级变更为系统级变更：该系统、其子系统需求发生重大变更，用户开发思路和整体工作流程发生变化，对系统各模块接口关系，数据库结构要做重大调整，对开发进度造成严重影响，需要重新定义需求工作，大量开发代码需要重新编写。II级变更为模块级变更：系统的某个模块或流程单元发生变动，变更只影响该模块或者流程内部，对系统整体模块接口关系，数据库结构等未造成重大影响，仅影响工作量和开发进度。III级变更为功能性变更：变更仅仅是调整系统的小功能单元，变更不影响系统整体结构和模块结构，也不会对开发进度和造成影响。

       三种级别的需求的变更均可以由项目经理、系统分析员或者相关用户提出，需求变更提出后，交予项目经理确认，由项目经理初步确定变更级别。I、II级需求的变更，项目经理需首先向CCB提交《需求变更控制报告》在变更申请中，需要将变更原因及变更的影响范围进行详细描述。如果CCB同意了该变更申请，则由项目经理通知相关受影响组和个人，组织项目组成员进行需求变更工作，即重新进行需求开发、需求确认，更新《用户需求说明书》和《软件需求规格说明书》，项目经理并及时更新《需求跟踪报告》，要对应的填写配置管理人员亦建立新版本的需求基线。如果变更申请被拒绝，CCB则需求在变更申请中说明理由，项目则继续按原计划进行。配置管理人员根据配置项变更控制规程中基线变更的流程进行需求基线的变更控制。在《需求跟踪报告》中，要标明需求变更级别，如果I，II级变更，要填写该变更对应的《需求跟踪报告》的文档编号。III级需求变更，项目经理确认后可直接更新《需求跟踪报告》，并且更新《用户需求说明书》和《软件需求规格说明书》，变更后交由用户进行签字确认，不需交由CCB进行评审。当III级变更数量过于频繁时，应当引起项目经理注意，查找问题所在。

产品线支撑的原型法策略架起管理者和信息化实施团队之间有效沟通的桥梁

在“需求分析”、“原型设计”两个阶段中，开发者和用户一起为想象中的系统的某些主要部分定义需求和规格说明，并由开发者在规格说明级用原型描述语言构造一个系统原型，它代表了部分系统，包括那些为满足用户需求的必要属性。该原型可用来帮助分析和设计工作，而不是一个软件产