2）由于用户不关心或不理解原型的概念和实现，而且存在较大期望，使得与实际系统差别较大的原型增加了需求分析人员与用户的交流难度；无论是水平原型，还是垂直原型都不能反映实际系统的全貌；

　　3）软件需求主要包括：功能需求、界面需求、性能需求、环境需求、可靠性需求、安全保密需求、资源使用需求、软件成本消耗与开发进度需求和目标需求[3]。原型法中的原型难以表达软件的后七项需求；

　　4）原型法强调用户和开发人员不断对原型进行不断修改和补充，直到用户感到满意为止。在时间紧和任务重的大型MIS项目中，这种情况实际难以保证，特别是在用户单位和开发单位距离较远时。

　　本文结合管理信息系统项目实施的实践，提出一种新的需求分析方法-简化原型法。这种方法根据数据库应用的特点，将需求分析分为两个阶段，并简化了作为需求分析工具的系统原型。

　　1、简化原型法需求分析的第一个阶段

　　管理信息系统属于数据库应用。数据库应用需求分析应该围绕数据，而不是功能展开，因此应该首先解决"有什么"，然后再明确"做什么"[4]。第一个阶段就是要解决"有什么"，即由项目经理与用户进行协商，确定系统的技术协议，因此可以称为技术协议阶段。技术协议需要开发方的项目经理与用户单位的技术主管签字并盖章，并以合同附件的形式存在。技术协议的主要内容有：系统的边界、系统处理的业务、与其它系统的接口、工程的进度控制、培训安排和技术服务承诺。

　　1.1系统的边界

　　系统的边界规定系统覆盖的作业范围，主要有地理边界（规定系统运行的部门、分支单位等）、操作员范围（规定操作系统的所有操作员身份、分布和大致权限）和业务范围（规定系统处理的业务，对于不处理的边沿业务特别明确指出）。

　　1.2系统处理的业务

　　系统处理的业务涵盖系统处理的所有业务，包括各种业务的描述、数据来源、实现要求。但是业务规定不要求过细，可以对应实际系统中的一个模块。如：电力MIS中输电设施管理子系统中的线路设备管理，不详细描述线路设备管理中的所有功能。

　　1.3与其它系统的接口

　　与其它系统的接口明确规定接口的系统、功能和实施单位。在接口的实施单位中明确是由开发方完成，还是由开发方协助第三方完成。

　　1.4工程的进度控制

　　工程的进度控制规定工程的开始、结束日期和具体工程项目的名称、完成时间、地点、完成标志及责任分工。具体项目一般包括：采购设备到达现场、采购设备安装调试、完成网络布线、开发准备阶段、业务需求调查、系统分析和设计、软件编制、现场调试、数据准备及录入、功能确认、试运行和系统验收。责任分工规定双方对于具体项目的工作内容和配合方式。在配合方式中规定人员组织方式、人员素质要求、提供的设备和场所。完成标志规定具体项目完成提供的文件名称和要求，如：网络布线验收报告和硬件设备验收报告等。

　　1.5培训安排

　　训包括操作员和系统维护人员的培训。培训安排包括每种培训的人员数量、培训内容、培训时间、地点、组织方式和教材，并规定教员和学员的素质要求，及培训后学员达到的水平。

　　2、简化原型法需求分析的第二个阶段

　　如果说第一个阶段解决"有什么"的问题，那么第二个阶段解决"做什么"的问题。主要工作有需求调查准备、到用户单位进行需求调查分析和进行需求评审。

　　2.1需求调查准备

　　需求调查准备工作，在系统的技术协议签订后，严格依照技术协议进行，主要有向用户单位发放业务调查表、建立需求分析文档原型和建立系统简化原型。业务调查表在系统的技术协议签订后，立即通过传真发送到用户单位，要求用户单位在需求调查人员到达现场之前完成。业务调查表内容包括：具体业务的名称、上级业务、下级业务、发生条件、处理的数据和详细流程（处理岗位、处理方式和审核细节等）。需求分析文档原型是根据技术协议编写的需求分析说明书原型，它的格式与标准的需求分析说明书相同。其中的状态迁移图和各种表证单书等不明确的内容，采用相似系统的或由系统分析人员根据技术协议和以往经验设计。

　　系统的简化模型根据技术协议的要求，仿照相似系统设计。简化模型采用可视化的数据库编程语言设计，一般采用数据库应用开发人员熟悉的PowerBuilder(PB)或Delphi。简化模型的主要设计要求有：1）充分考虑系统的设计与实现，不得与实际系统脱节；2）尽量仿真实际系统的操作界面，与实际系统的操作过程完全相同；3）可以单机安装运行，不与实际数据库连接；4）演示数据的存储可以通过文本文件、单机的数据库或PB外部数据源的数据窗口；5）对于界面中容易误解或难以理解的操作，在功能帮助按钮中给出说明；6）界面中难以实现或工作量很大的功能，以标注方式详细说明；7）运行稳定，并比实际系统对硬件要求低。

　　2.2需求调查分析

　　需求调查分析在确认需求调查准备的三项工作完成后，由开发单位的系统分析人员到用户单位进行。系统分析人员与用户单位安排的业务主管共同讨论业务调查表和系统简化原型，并不断修改完善系统简化原型和文档原型，最终形成共识，并要求业务主管在需求分析说明书上签字。最终系统简化原型和源代码留在用户现场，便于系统的操作员进一步理解分析，直到最终掌握；而且有利于提出进一步的改进意见。改进意见可以随时通过邮件或传真直接发到开发单位，或由用户单位的系统维护人员修改简化原型后，随时发到开发单位，从而便于开发人员及时修改系统的设计和编码。

　　2.3进行需求评审

　　需求评审一般由用户单位组织，评审团成员由同行专家、系统分析、设计和测试人员组成。评审的依据不仅有需求分析说明书，还有系统简化原型；同时在评审过程中，系统简化原型不断进行优化。评审的目标是要求需求分析说明书具有正确性、可行性、必要性、具有优先级属性、可验证性和无二义性[5]。需求评审报告作为对需求分析的补充和修正，由双方负责人签字，以需求分析说明书附件的形式存在，同样指导下一步的系统设计工作。

　　3、几点说明

　　1）、此方法适合各种MIS工程的需求分析，特别适合致力于某一领域MIS开发的软件公司。采用此方法，开发同类项目越多，需求分析工作的效率越高。

　　2）、在需求分析过程中，由于需要设计系统简化原型和文档原型，并充分考虑到系统的设计与实现，因此与其它需求分析方法向比，提高了对需求分析人员的要求。在实际工作中，一般由资深的软件分析和设计人员进行。

　　3）、此方法不仅适合MIS软件工程，同样适合其它大型软件工程。

　　4）、由于需求分析工作本身的难度和重要性，此方法同样要求用户单位和需求分析人员对需求分析所有工作内容，引起足够重视；科学安排需求分析工作步骤，某些步骤可以同时进行；所有工作步骤不得应负或疏忽。

　　4、结束语：

　　目前简化原型法已经在多个电力MIS工程中应用，大大提高了需求分析的工作效率。实践证明，简化原型法具有以下特点：1）简化的系统原型开发工作量大大降低，修改和补充方便；2）简化原型大大缩短了需求分析人员与业务主管之间的距离，便于交流；并大大加强了需求分析人员与业务主管对系统的认识，有利于发现和解决问题；3）简化原型的设计提前考虑了系统的设计与实现，大大降低了软件工程的风险；4）简化原型增加了系统操作员对实际系统的认识，大大简化了工程实施后系统的操作培训；5）简化原型可以直接指导工程的设计和编码，便于系统开发的组织。这种方法也可以用于其它软件工程，对于其它需求分析方法的改革也具有指导意义。