察用语言规定的任何系统的功能和行为。（2）基于脚本的设计。脚本是用户界面的原型。一个脚本用来模拟在系统运行期间用户经历的事件。它提供了输入———处理———输出的屏幕格式和有关对话的模型。因此，软件开发者能够给用户显示系统的逼真的视图，使用户得以判断是否符合他的意图。（3）自动程序设计在程序自动生成环境的支持下，利用计算机实现软件的开发。它可以自动地或半自动地把用户的非过程式问题规格说明转换为某种高级语言程序。（4）专用语言。专用语言是应用领域的模型化语言。在原型开发中使用专用语言，可方便用户和软件开发者对系统特性进行交流。（5）可复用的软件。利用可复用的模块，通过适当的组合，构造的原型系统。为了快速地构造原型，这些模块首先必须有简单而清晰的界面；其次它们应当尽量不依赖其它的模块或数据结构；最后，它们应具有一些通用的功能。（6）简化假设。 简化假设使设计者迅速得到一个简化的系统。尽管这些假设可能实际上并不能成立，但它们可以使开发者的注意力集中在一些主要的方面。在修改一个文件时，可以假设这个文件确实存在。 在存取文件时，待存取的记录总是存在。一旦计划中的系统满足用户所有的要求，就可以撤消这些假设，并追加一些细节。
（四）原型分析优点
原型分析优点有：（1）增进软件开发者和用户对需求的理解，使比较含糊的具有不确定性的软件需求（主要功能性的需求）明确化。（2）软件原型化方法提供了一种有力的学习手段。（3）使用原型化方法，可以容易地确定系统的性能，确认系统主要服务的可应用性，确认系统设计的可行性，确认系统最终作为产品。（4）软件原型的最终版本，有的可以原封不动地称为产品，有的略加修改就可以成为最终系统的一个组成部分，这样有利于建成最终系统。
四、需求变更
在开发项目过程中，用户随时会提出一些新的需求，要求开发人员解决，这些需求的提出，有时在开发阶段中有时在开发阶段后。这种在需求分析的两个相邻子阶段中，或者在迭代周期的需求分析中，后一段或周期的需求分析结果与前一次不一致， 我们把这种不一致称为需求变更。产生需求变更的原因主要有以下几个方面：（1）在需求分析阶段，开发人员与用户的沟通不够。在需求分析阶段，开发方与用户没有很好的交流，开发方就根据用户提供的大概信息，自己推导出用户的需求。通过这种需求分析得出的需求往往会和用户的实际需求相差甚远，导致用户提出更改需求。（2）项目的实施周期过长。随着时间的推移，用户对整个系统的了解也越来越深入。他们会对模块的界面、功能和性能方面提出更高更多的要求。（3）技术更新过快。由于技术的快速更新， 企业可能引进一些新的设备， 而这些设备可能就会与我们的目标系统有直接的关系， 由于这一变化可能发生在解决用户原先问题之前或者之中， 那么开发人员不得不加入这一新的需求。
为了尽可能地避免发生需求变更，以及保证需求分析的高稳定性，可以采用以下方法：（1）对开发人员进行专业培训。因为，开发人员对所开发系统的领域不一定了解，为了开发人员能更好理解用户的需求，在做需求分析的初始阶段对开发人员进行该领域相关知识的培训。（2）开发方与用户进行协作和交流。在用户提出需求变更时开发人员应该认真听取用户的要求并加以整理和分析。分析需求变更的原因并提出可行的替代方案；同时向用户说明这些需求变更会对整个项目的开发带来的不良后果。（3）合同约束。由于需求变更可能会对整个项(下接第85页)(上接第77页)目产生影响，所以，开发方和用户在签定项目合同时，可以对需求变更增加一些相关的合同条款。（4）建立需求文档并进行版本控制。需求分