级系统分析员或一个项目负责人来领导的。在信息服务部门中，这两种人是固定

分工做这项工作的。目前越来越多的公司采取这样一种政策，即由用户担任项目

组组长。这种将主要责任下放给最终用户的做法将进一步鼓励用户参与系统设计

在这种政策上取得成功经验的那些公司已经指派了一些具有杰出管理经验和具

有某些计算机和信息处理知识的用户人员担任项目组组长。在任何情况下，组长

必须对该组的工作有一个总的安排。如果要求一个用户代表既作为可行性研究组

或项目组的组长而同时又要求他继续履行业务领域的职责，那么该项目是肯定

要失败的。有好些公司已经采用了一种政策，即自动地指派受系统影响最大的业

务领域的经理作为可行性研究组和项目组的领导以后该经理将从原来的工作职

责中解脱出来，而用他

(她)的全部时间管理可行性研究(或项目)组。这种人事安

排已经成为当今的主流，其困难是用户经理需要离开原来主管的业务部门少则

两个月多则三年后才能回他原来的工作岗位上。

    (4)标列约束条件

    在系统开发的过程一开始，可行性研究组与信息服务人员和用户经理密切合

作标列出设备、成本、进度、规程、软件以及操作上的约束条件。它们可能限制建议

的系统的定义和设计。

    (5)整理现有系统的资料

    整理现有系统资料的主要理由是：如果可行性研究组不充分了解现有系统，

那么他们就不可能有效地完成所建议的系统的初始设计。已经建立起来的多数人

工系统并没有经过真正的设计。在这些系统中，必须从手稿整理出资料。如果一

个建议的系统是改进一个现有的计算机信息系统，那么可行性研究组只需要保

证现有资料的完整性和保持最新版本就行了。

现有系统所形成的任何资料将给设计阶段提供有价值的输入

(如果批准开发

该系统

)。即便建议的系统遭到拒绝，也能对现有系统提供基本的资料，并且可

①

②

能透彻地理解理有系统。现有系统的资料由四部分组成： 系统报告和资料；

③

④

系统数据文件； 系统数据元以及 说明现有系统的数据、信息和工作流程的图

表。前三部分

(报告、文件和数据元)可分类如下：

① 当前使用的，而且在建议的系统中以目前的形式保留下来；

    ② 当前使用的，但是修改后才在建议的系统中使用；

3