6.2.1 概念内涵

需求不确定或定义错误是导致软件开发项目失败的重要原因之一。需求确认（Requirments Vlidation）的目标是确保软件要实现的需求与用户实际需求相一致，但这个过程十分复杂，很难一次性产生正确且完整的需求规格（Requirments Specification），为此有必要采用快速原型开发法开发系统原型，来给用户展示概念，尽早发现需求错误，找到可行解决方案，并发现缺失的重要需求。

系统原型或原型系统（System prototyping） 是指待开发或交付软件系统的一种初始形态，在此形态下，软件系统具有初始的交互界面或基本的功能模块，能够满足用户基本的人机交互和功能需求。在原型系统基础上，用户与系统开发人员间不断反复迭代，将软件系统的界面、功能及使用体验打磨臻于至善。原型系统的开发过程如图 6.2 示意：

图 6.2: 原型系统的开发流程

从上图可以看到，系统原型的开发客户分为四步骤：

1. 确定用户的基本需求

由用户提出对新系统的基本要求，如功能、界面的基本形式、所需要的数据、应用范围、运行环境等，开发者根据这些信息估算开发该系统所需的费用，并建立简明的系统模型。

2. 构造初始原型

系统开发人员在明确了对系统基本要求和功能的基础上，依据计算机模型，以尽可能快的速度和尽可能多的开发工具来建造一个结构仿真模型，即快速原型构架。之所以称为原型构架，是因为这样的模型是系统总体结构，子系统一上部分的高层模型。由于要求快速，这一步骤要尽可能使用一些软件工具和原型制造工具，以辅助进行系统开发。

3. 运行、评价、修改原型

快速原型框架建造成后，就要交给用户立即投入试运行，各类人员对其进行试用、检查分析效果。由于构造原型中强调的事快速，省略了许多细节，一定存在许多不合理的部分。所以，在试用中要充分进行开发人员和用户之间的沟通，尤其是要对用户提出的不满意的地方进行认真细致的反复修改、完善，直到用户满意为止。

4. 形成最终交付物

如果用户和开发者对原型比较满意，则将其作为正式原型。经过双方继续进行细致的工作，把开发原型过程中的许多细节问题逐个补充、完善、求精，最后形成一个适用的系统交付物。

原型系统开发过程中的注意要点如下：

并非所有的需求在系统开发以前都能准确地说明

要想详细而地定义任何事情都是有困难的。实际上，用户很善于叙述其目标、对象以及他们想要前进的大致方面，但对于他们要如何实现那些事情的细节却不甚清楚和难以确定。

需要有快速的系统建造工具

原型的修正和完善需要有快速的系统建造工具支持，只有快速系统生成工具，才能使应用系统得以快速模型化，而且能快速地进行修改。没有快速系统建造工具，原型不能得到快速修改完善，原型法就失去存在的基础。

项目参加者之间通常都存在通信上的障碍

对于开发人员通信上障碍的排除，不是试图将每一个项目参加者都培养成职业的系统定义人员，而是让每个人以一种易于接受的方式去理解规格说明。从常识上来理解，一个具体的工作原型，由于其直观性、报考性而能够担当和胜任这一任务。

需要实际的、可供用户参与的系统模型

文字和静态图形是一种比较好的通信工具，然而其的缺点是缺乏直观的、感性的特征，因而往往不易理解对象的全部含义。交互式原型系统能够提供生动活泼的规格说明，用户见到的是一个“活”的、运行着的系统。理解纸面上的系统和操作运行在机器上的系统，其差别是十分显著的。

需求一旦确定，就可以遵从严格的方法

原型法是确定需求策略，它快速地、选代地建立终系统工作模型，对问题定义采用启发的方式，由用户作出响应——实际上是一种报考定义技术。但同时，原型法的采纳并不排除和放弃严格方法的运用，一旦通过建立原型并在演示中得到明确的需求定义后，即可运用行之有效的结构化方法来完成系统的开发。

大量的反复是不可避免的、必要的，应该加以鼓励

应该鼓励用户改进他们的系统，改进建议的产生是来自经验的发展。

在“需求分析”、“原型设计”两个阶段中，开发者和用户一起为想象中的系统的某些主要部分定义需求和规格说明，并由开发者在规格说明级用原型描述语言构造一个系统原型。

而在演示原型期间，用户可以根据他所期望的系统行为来评价原型的实际行为。如果原型不能满意地运行，用户能立刻找出问题和不可接受的地方，并与开发者重新定义需求。该过程一直持续到用户认为该原型能成功地体现想象中的系统的主要部分功能为止。