可行性研究与需求

1、可行性研究与需求分析 XXX软件生命周期软件过程软件过程：为了获得高质量软件为了获得高质量软件产品所需要完成的一系列任务的框架，产品所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。它规定了完成各项任务的工作步骤。按照在软件生命周期全过程中应完成按照在软件生命周期全过程中应完成的任务的性质，在概念上可以把软件的任务的性质，在概念上可以把软件生命周期划分成八个阶段：生命周期划分成八个阶段： p 问题定义p 可行性研究可行性研究p 需求分析需求分析p 概要设计p 详细设计p 编码和单元测试p 综合测试p 维护目录1234可行性研究步骤可行性研究的文档可行性分类理论基础软件的可行性研究

2、理论基础理论基础1p 当接受一个软件开发任务时，就表明进入软件生命周期的第一个阶段，即当接受一个软件开发任务时，就表明进入软件生命周期的第一个阶段，即首先进入首先进入可行性的研究可行性的研究。通过可行性研究可以确定问题有无可行性的解。通过可行性研究可以确定问题有无可行性的解决办法，从而避免人力、物力和财力上的浪费。通常来说，可行性研究所决办法，从而避免人力、物力和财力上的浪费。通常来说，可行性研究所需的成本占预期工程总成本的需的成本占预期工程总成本的5%10%。p 通过对被开发系统的可行性研究，能够实现用最小的代价在尽可能短的时通过对被开发系统的可行性研究，能够实现用最小的代价在尽可能短的时间

3、内确定问题是否可以解决。间内确定问题是否可以解决。也就是说可行性研究的目的不是解决问题，也就是说可行性研究的目的不是解决问题，而是确定问题是否能获得解，研究在当前而是确定问题是否能获得解，研究在当前的具体条件下，开发新系统是否的具体条件下，开发新系统是否具备必要的资源和其它条件。具备必要的资源和其它条件。可行性研究是要进一次压缩简化了的系统分可行性研究是要进一次压缩简化了的系统分析和设计的过程，也就是说在较高层次上以较抽象的方式进行设计的过程。析和设计的过程，也就是说在较高层次上以较抽象的方式进行设计的过程。可行性分类2p 经济可行性p 技术可行性p 运行可行性p 法律可行性p 开发方案可行性

4、在明确了问题定义之后，分析员应该给出系统的逻辑模型，然后从系统逻辑模型出发，寻找可供选择的解法。u1.经济可行性研究主要进行成本效益分析，包括估计项目的开发成本，估算开发成本是否高于项目预期的全部利润。分析系统开发对其他产品或利润所带来的影响。2可行性分类u2.技术可行性是最难决断和最关键的问题。根据客户提出的系统功能、性能及实现系统的各项约束条件，从技术的角度研究系统实现的可行性。技术可行性研究是系统开发过程中难度最大的、最重要的工作。由于系统分析和定义过程与系统技术可行性评估过程同时进行，这时系统目标、功能和性能的不确定性会给技术可行性论证带来许多困难。技术可行性研究包括：u 风险分析：在

5、给出的限制范围内，能否设计出系统，并实现必要的功能和性能。u 资源分析：研究开发系统的人员是否存在问题？可用于建立系统的其他资源，如硬件、软件等是否具备？u 技术分析：相关技术的发展是否支持这个系统。u3.运行可行性能为新系统规定的运行方式是否可行。如果新系统是建立在原来已担负其他任务的计算机系统上的，就不能要求它在实时在线状态下运行，以免与原有的任务相矛盾。u4.法律可行性是指研究在系统开发过程中可能涉及的各种合同、侵权、责任以及各种与法律相抵触的问题。u5.开发方案可行性：提出系统实现的各种方案并进行评价之后，从中选择最优秀的一种方案。 可行性研究的结果是可行性研究报告，它可以作为系统规格

6、说明书的一个附件。步骤步骤1当然，可行性研究最根本的任务是对以后的行动路线提出建议：如果问题没有可行的解，应该建议停止这项软件项目的开发；如果问题值得解，应该推荐一个较好的解决方案，并且为项目制定一个初步的计划。如何进行可行性研究，一般地说，可行性研究有如下步骤。3可行性研究步骤1.复查系统规模和目标u 通过仔细阅读和分析有关资料，访问有关人员，复查系统的目标和规模，改正模糊的叙述，对目标系统的约束给予清晰地描述。使分析员正在要解决的问题是用户所提出的问题。 步骤步骤22.研究目前正在使用的系统u 现有的系统是构造新系统的基础、是信息的重要来源，通过对现有系统的文档资料的阅读、分析和研究，再如

7、实地考虑该系统，总结出现有系统的优点和不足，进而得出新系统的雏形。这样调查研究，是了解一个陌生应用领域的最快方法，它既可以使新系统脱胎而生，但又不能全盘照抄。步骤步骤33可行性研究步骤3.提出新系统的高层逻辑模型u 优秀的设计通常总是从现有的实际物理系统出发，获得现有系统的高层逻辑模型。逻辑模型是数据流图来描述的，此时的数据流图不需要细化。然后，再来参考现有的逻辑模型。这样，经过上述几步的反复进行，最后根据开发系统的目标，得到新系统的说明和逻辑模型。逻辑模型确立之后，可以在此基础上建造开发系统的物理系统，通常物理系统模型是用系统流程图来表示的。 步骤步骤44.重新定义问题u 新系统的逻辑模型是

8、分析员对新系统的描述。为了使用户和分析员有同样的看法，分析员应该和用户一起再次复查问题定义，再次确定工程规模、目标和约束条件，并修改已发现的错误。u 可行性研究的前四个步骤构成一个循环：分析员定义问题，分析这个问题，导出一个试探性的解，再此基础上再次定义问题，再次分析，再次修改，继续这个过程，直到提出的逻辑模型完全符合系统目标为止。步骤步骤53可行性研究步骤5.提出和评价供选择的方案u 分析员从系统的逻辑模型出发，提出若干较高层次的、较抽象的物理解决供比较和选择。从技术、经济、操作等方面进行分析比较，并估算开发成本、运行费用和纯收入。在此基础上对每个可能的系统进行成本/效益分析。 步骤步骤66

9、.推荐一个方案并说明理由u在对上一步提出的各种方案分析比较的基础上，提出向用户推荐的方案，在推荐的方案中应清楚地表明：u （1）本项目的开发价值；u （2）推荐这个方案的理由；u （3）制定实现进度表，这个进度表不需要也不可能很详细，通常只需要估计生存周期每个阶段的工作量。步骤步骤73可行性研究步骤7.书写计划任务书u 把上述材料进行分析汇总，草拟一份描述计划任务的可行性论证报告。此报告应包括以下内容：（1）系统概述：对当前系统及其存在问题的简单描述；新系统的开发目的、目标、业务对象和范围；新系统和它的各个子系统功能与特性；新系统与当前系统的比较等。新系统可以用系统流程图来描述，并附上重要的数

10、据流图和数据字典以及加工说明作为补充。（2）可行性分析：这是报告的主体。论述新系统在经济上、技术上、运行上、法律上的可行性，以及对新系统的主客观条件的分析。（3）拟定开发计划：工程进度表，人员配备情况，资源配备情况，估计出每个阶段的成本、约束条件等。（4）结论意见：综合上述分析，说明新系统是否可行，结论可分为三类：可立即进行、推迟进行、不能和不值得进行。 步骤步骤88.提交审查u用户和使用部门的负责人仔细审查上述的文档，也可以召开论证会。论证会成员有用户、使用部门负责人及有关方面专家，对该方案进行论证，最后由论证会成员签署意见，指明该任务计划书是否通过。4可行性研究的文档u 1. 引言：说明编

11、写本文档的目的，项目的名称、背景，本文档用到的专门术语和参考资料。u 2. 可行性研究前提：说明开发项目的功能、性能和基本要求，达到的目标，各种限制条件，可行性研究方法和决定可行性的主要因素。u 3. 对现有系统的分析：说明现有系统的处理流程和数据流程，工作负荷，各项费用支出，所需各类专业技术人员和数量，所需各种设备，现有系统存在什么问题。u 4. 所建议系统的技术可行性分析：对所建议系统的简要说明，处理流程和数据流程，与现有系统比较的优越性，采用所建议系统对用户的影响，对各种设备、现有软件、开发环境和运行环境的影响，对经费支出的影响，对技术可行性的评价。可行性研究结束后要提交的文档是可行性研

12、究报告。一个可行性研究报告的主要内容如下：4可行性研究的文档u 5. 所建议系统的经济可行性分析：说明所建议系统的各种支出，各种效益，收益投资比，投资回收周期。u 6. 社会因素可行性分析：说明法律因素对合同责任、侵犯专利权和侵犯版权等问题的分析，说明用户使用可行性是否满足用户行政管理、工作制度和人员素质的要求。u 7. 其他可供选择方案：逐一说明其他可供选择的方案，并说明未被推荐的理由。u 8. 结论意见：说明项目是否能开发，还需什么条件才能开发，对项目目标有何变动等。可行性研究结束后要提交的文档是可行性研究报告。一个可行性研究报告的主要内容如下：目录12345分析建模与规格说明实体关系图数

13、据流图与用户通信技术理论基础6状态转换图7数据字典8结论与应用软件的需求分析理论基础理论基础1p 为了开发出真正满足用户需求的软件产品，首先必须知道用户的需求。为了开发出真正满足用户需求的软件产品，首先必须知道用户的需求。p 对软件需求的深入理解是软件开发工作获得成功的前提和关键，不论我们把设计和编码对软件需求的深入理解是软件开发工作获得成功的前提和关键，不论我们把设计和编码工作做得如何出色，不能真正满足用户需求的程序只会给用户带来失望，给开发者带来工作做得如何出色，不能真正满足用户需求的程序只会给用户带来失望，给开发者带来烦恼。烦恼。p需求分析需求分析是发现、求精、建模、规格说明和复审的过程

14、。是发现、求精、建模、规格说明和复审的过程。p 为了发现用户的真正需求，首先应该从宏观角度调查、分析用户所面临的问题。也就是为了发现用户的真正需求，首先应该从宏观角度调查、分析用户所面临的问题。也就是说，需求分析的第一步是尽可能准确地了解用户当前的情况和需要解决的问题。说，需求分析的第一步是尽可能准确地了解用户当前的情况和需要解决的问题。1理论基础理论基础u为了更好地理解问题，人们常常采用建立模型的方法。u所谓模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。u通常，模型由一组图形符号和组织这些符号的规则组成。u除了用分析模型表示软件需求之外，还要写出准确的软件需求

15、规格说明。u模型既是软件设计的基础，也是编写软件规格说明的基础。模型模型软件需求规格说明软件需求规格说明1理论基础理论基础在分析软件需求和编写软件规格说明的过程中，软件开发者和软件用户都起着关键的、必不可少的作用。用户与开发者之间需要通信、沟通的内容非常多，在双方交流信息的过程中很容易出现误解或遗漏，也可能存在二义性。与用户通信的技术与用户通信的技术2p软件需求分析总是从两方或多方之间的通信开始。p用户面临的问题需要用基于计算机的方案来解决；开发者应该对用户的需求作出反应，给用户提供帮助。p这样就产生了相互通信的需求。但是，正如前面已经讲过的，从开始通信到真正相互理解的道路通常是充满坎坷的。p

16、良好的通信技术有助于加快理解的过程。与用户通信的技术与用户通信的技术访谈访谈2p 在正式的访谈正式的访谈中，系统分析员将提出一些事先准备好的具体问题，例如，询问客户公司销售的商品种类、雇用的销售人员数目以及信息反馈时间应该多快等。p 在非正式的访谈非正式的访谈中，将提出一些可以自由回答的开放性问题，以鼓励被访问的人员表达自己的想法，例如，询问用户为什么对目前正在使用的系统感到不满意。访谈(或称为会谈)是最早开始运用的获取用户需求的技术，也是迄今为止仍然广泛使用的主要的需求分析技术。访谈有两种基本形式：正式的、非正式的与用户通信的技术与用户通信的技术应用规格说明技术应用规格说明技术2尽管存在许多

17、不同的简易应用规格说明方法，但是它们遵循的基本准则是相基本准则是相同的。同的。p在中立地点举行由开发者和用户双方出席的会议。p制定准备会议和参加会议的规则。p提出一个议事日程，这个日程应该足够正式以便能够涵盖所有要点，同时这个日程又应该足够非正式，以便鼓励自由思维。p由一个“协调人”来主持会议，他既可以是用户也可以是开发者还可以是从外面请来的人。p使用一种“定义机制”(例如，工作表、图表等)。p目标是标识问题、提出解决方案要素、商讨不同的方法以及在有利于实现目标的氛围中指定初步的需求。这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案的要素，商讨不同的方法并指定基本的需求。今天，简易

18、的应用规格说明技术已经成为信息系统界使用的主流技术。与用户通信的技术与用户通信的技术软件原型软件原型2 快速原型应该具备的特性快速容易修改快速原型的目的是尽快向用户提供一个可在计算机上运行的目标系统的模型，以便使用户和开发者在目标系统应该“做什么”这个问题上尽可能快地达成共识。如果原型的第一版不是用户所需要的，就必须根据用户的意见迅速地修改它，构建出原型的第二版，以更好地满足用户的需求。p 构建原型的要点是，它应该实现用户看得见的功能(例如屏幕显示或打印报表)，省略目标系统的“隐含”功能(例如修改文件)。p 在实际开发软件产品时，“修改试用反馈”的过程可能重复多遍，如果修改耗时过多，势必延误软

19、件开发时间。3分析建模与规格说明分析建模与规格说明结构化分析结构化分析实质上是一种创建模型的活动。通过需求分析而建立的模型必须达到下述的三个基本目标。p描述用户的需求。p为软件设计工作奠定基础。p定义一组需求，一旦开发出软件产品之后，就可以用这组需求为标准来验收该产品。为了达到上述这些目标，在结构化分析过程中导出的分析模型的形式，如右图所示。图图1.1.分析模型的结构分析模型的结构分析建模与规格说明分析建模与规格说明3通过需求分析除了创建分析模型之外，还应该写出软件需求规格说明，它是分析阶段的最终成果。下面给出的简略大纲可以作为软件需求规格说明的框架。 A .功能分解 B .功能描述 1 .处

20、理说明 2 .限制 3 .性能需求 4 .设计约束 5 .支撑图 C .控制描述 1 .控制规格说明 2 .设计约束 .行为描述 A .系统状态 B .事件和动作.确认标准 A .性能范围 B .测试种类 C .预期的软件响应 D .特殊考虑.参考书目.附录 .引言 A .系统参考文献 B .整体描述 C .软件项目约束.信息描述 A .信息内容 B .信息流 1 .数据流 2 .控制流.功能描述 实体实体关系图关系图4数据模型包含三种相互关联的信息：p数据对象数据对象p描述数据对象的属性属性p数据对象彼此间相互连接的关系关系属性属性定义了数据对象的性质。应该根据对所要解决的问题的理解，来确定

21、特定数据对象的一组合适的属性。数据对象彼此之间相互连接的方式称为关系关系，也称为联系。(1)一对一联系(1 1)(2) 一对多联系(1 N)(3) 多对多联系(M N)联系也可能有属性。数据对象数据对象是对软件必须理解的复合信息的表示。所谓复合信息是指具有一系列不同性质或属性的事物，因此，仅有单个值的事物(例如宽度)不是数据对象。实体实体关系图关系图4命命1通常，使用实体关系图(Entity Relationship Diagram)来建立数据模型。通常把实体关系图简称为ER图，相应地，用ER图描绘的数据模型也可以称为ER模型。ER图基本成分：u 实体(即数据对象)：矩形框u 关系：连接相关实

22、体的菱形框表示关系u 属性：用椭圆形或圆角矩形表示实体(或关系)的属性u 并用无向边把实体(或关系)与其属性连接起来实体实体关系图关系图4某学校教学管理的ER图u教师u学生u课程 例题例题图图2.2.某校教学管理某校教学管理 ER ER 图图数据流图数据流图5命题命题3当信息在软件中移动时，它将被一系列“变换”所修改。数据流图(DFD)是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。数据流图有四种基本符号：u正方形(或立方体)表示数据的源点或终点；u圆角矩形(或圆形)代表变换数据的处理；u开口矩形(或两条平行横线)代表数据存储；u箭头表示数据流，即特定数据的流动方向。

23、或或或5数据流图数据流图TCAB*数据A和数据B同时输入才能变换成CTCAB*数据A变换成B和CTCAB+数据A或B，或A和B同时输入变换成CTCAB+数据A变换成B或C，或B和CTCAB只有数据A或只有数据B（不能A，B同时）输入时变换成CTCAB数据A变换成B或C，但不能变换成B和C还有一些附加符号。例题例题假设一家工厂的采购部每天需要一张定货报表，报表按零件编号排序，表中列出所有需要再次定货的零件。5数据流图数据流图u 对于每个需要再次定货的零件应该列出下述数据；零件编号、零件名称、定货数量、目前价格、主要供应者和次要供应者。 u 零件入库或出库称为事务，通过放在仓库中的CRT终端把事务

24、报告给定货系统。当某种零件的库存数量少于库存量临界值时就应该再次定货。p 从问题描述中提取数据流图的四种成分p 接下来考虑处理p 最后，考虑数据流和数据存储 步骤步骤例题例题表1总结了上面分析的结果，其中加星号标记的是在问题描述中隐含的成分。5数据流图数据流图表1.组成数据流图的元素可以从描述问题的信息中提取源头源头/终点终点数据流数据流采购员定货报表仓库管理员零件编号数据存储数据存储零件名称定货信息(见定货报表)定货数量库存清单目前价格零件编号*主要供应者库存量次要供应者库存量临界值事务处理处理零件编号*产生报表事务类型处理事务数量*5数据流图数据流图u一旦把数据流图的四种成分都分离出来以后

25、，就可以着手画数据流图了。u任何系统的基本模型都由若干个数据源点/终点以及一个处理组成，这个处理就代表了系统对数据加工变换的基本功能。对于上述的定货系统可以画出如图3所示的基本系统模型。图图3.3.定货系统的基本系统模型定货系统的基本系统模型( (突出表明了数据的源点和终点突出表明了数据的源点和终点) )5数据流图数据流图u下一步应该把基本系统模型细化，描绘系统的主要功能。u在图4中给处理和数据存储都加了编号，这样做的目的是便于引用和追踪。 图图4.4.定货系统的定货系统的功能级数据流图功能级数据流图5数据流图数据流图u接下来应该对功能级数据流图中描绘的系统主要功能进一步细化。u在对数据流图分

26、层细化时必须保持信息连续性，也就是说，当把一个处理分解为一系列处理时，分解前和分解后的输入/输出数据流必须相同。图5.把处理事务的功能进一步分解后的数据流图数据流数据流u 名字应代表整个数据流(或数据存储)的内容，而不是仅仅反映它的某些成分。u 不要使用空洞的、缺乏具体含义的名字(如“数据”、“信息”、“输入”之类)。u 如果在为某个数据流(或数据存储)起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的，应该试试重新分解，看是否能克服这个困难。 处理处理5数据流图数据流图命名命名u 通常先为数据流命名，然后再为与之相关联的处理命名。这样命名比较容易，而且体现了人类习惯的“由表及里”的

27、思考过程。u 名字应该反映整个处理的功能，而不是它的一部分功能。u 名字最好由一个具体的及物动词，加上一个具体的宾语组成。应该尽量避免使用“加工”、“处理”等空洞笼统的动词作名字。数据流图中每个成分的命名是否恰当，直接影响数据流图的可理解性，因此，给这些成分起名字时应该仔细推敲。p通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能更恰当些。p如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的迹象，应考虑重新分解。6状态转换图状态转换图状态转换图(简称状态图)通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。状态状态是任何可以

28、被观察到的系统行为模式，一个状态代表系统的一种行为模式。p状态规定了系统对事件的响应方式。p系统对事件的响应，既可以是做一个（或一系列）动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。p在状态图中定义的状态主要有：初态（即初始状态）、终态（即最终状态）和中间状态。p在一张状态图中只能有一个初态，而终态则可以有0至多个。事件事件是在某个特定时刻发生的事情，它是对引起系统从一个状态转换到另一个状态的外界事件的抽象。简而言之，事件就是引起系统状态转换的控制信息。6状态转换图状态转换图初态初态/ /终态终态/ /中间状态中间状态在状态图中，初态用实心圆表示，终态有一对同心圆（内圆为实

29、心圆）表示。中间状态用圆角矩形表示，可以用两条水平横线把它分成上、中、下3个部分。u上面部分为状态的名称，这部分是必须有的；u中间部分为状态变量的名字和值，这部分是可选的；u下面部分是活动表，这部分也是可选的。状态转换状态转换状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。状态变迁通常是由事件触发的，在这种情况下应在表示状态转换的箭头线上标出触发转换的事件表达式；如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。6状态转换图状态转换图事件表达式语法事件表达式语法事件说明守卫条件/动作表达式u其中，事件说明的语法为：事件名（参数表）。u守卫条件是一个布尔

30、表达式。如果同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时，状态转换才发生。如果只有守卫条件没有事件说明，则只要守卫条件为真状态转换就发生。u动作表达式是一个过程表达式，当状态转换开始时执行该表达式。活动表的语法格式活动表的语法格式事件名（参数表）/动作表达式其中，“事件名”可以是任何事件的名称。在活动表中经常使用下述3种标准事件：entry，exit和do。entry事件指定进入该状态的动作，exit事件指定退出该状态的动作，而do事件则指定在该状态下的动作。需要时可以为事件指定参数表。活动表中的动作表达式描述应做的具体动作。6状态转换图状态转换图状态转换图(简称状态图)通

31、过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。图7为状态图中使用的主要符号。图图6.6.状态图中使用的主要符号状态图中使用的主要符号6状态转换图状态转换图图图7.7.电话系统的状态图电话系统的状态图7数据字典数据字典u数据字典是为了描述在结构化分析过程中定义的对象的内容，而使用的一种半形式化的工具。u 数据字典是所有与系统相关的数据元素的有组织的列表，并且包含了对这些数据元素的精确、严格的定义，从而使得用户和系统分析员双方对输入、输出、存储的成分甚至中间计算结果有共同的理解。u 简而言之，数据字典是描述数据的信息的集合，是对系统中使用的所有数据元素的定义的集合。通常包含下面信息。

32、p 名字数据、控制项、数据存储或外部实体的主要名称。p 别名第一项中对象的其他名字。p 使用地点与方式使用数据或控制项的处理的列表，以及使用这些对象的方式(例如作为处理的输入，从处理输出，作为数据存储，作为外部实体)。p 内容描述描述数据或控制项内容的符号。p 补充信息关于数据类型、预置值、限制等的其他信息。7数据字典数据字典u 意思是 等价于(或定义为)；u 意思是 和(即，连接两个分量)；u 意思是或(即，从方括弧内列出的若干个分量中选择一个)，通常用“”号分开供选择的分量；u 意思是重复(即，重复花括弧内的分量)；u （ ）意思是可选(即，圆括弧里的分量可有可无)。u 在开括弧的左边用上

33、角标和下角标分别表明重复的上限和下限；u 在开括弧左侧标明重复的下限，在闭括弧的右侧标明重复的上限。虽然可以使用自然语言描述由数据元素组成数据的关系，但是为了更加清晰简洁起见，建议采用下列符号：常常使用上限和下限进一步注释表示重复的花括弧。8结论与应用结论与应用u 为了详尽地了解并正确地理解用户的需求，必须使用适当的技术与用户通信和沟通。访谈访谈是历史悠久历史悠久的与用户通信的技术，至今仍被系统分析员广泛采用。u 为了促使用户与分析员密切合作共同分析需求，人们研究出一种面向团队面向团队的需求收集法，称为“简易的应用规格说明技术简易的应用规格说明技术”，现在，这种技术已经成为信息系统界使用的主流技术。u 实践表明，快速建立软件原型快速建立软件原型是最准确、最有效和最强大最准确、最有效和最强大的需求分析技术。快速原型应该具备的基本特性是“快速”和“容易修改”，因此，必须有适当的软件工具支持快速原型技术