第三讲需求分析与建模

第三讲需求分析与建模第一页，共八十页，编辑于2023年，星期一内容需求分析概述结构化需求分析方法面向对象需求分析方法第二页，共八十页，编辑于2023年，星期一分类筛选合并排序需求分析的过程第三页，共八十页，编辑于2023年，星期一需求分析成功的条件乙方正确的

方法论甲方明确的

建设目标第四页，共八十页，编辑于2023年，星期一需求分析分析什么？业务流程优化关键问题结构化分析法面向对象分析法怎么分析？第五页，共八十页，编辑于2023年，星期一系统建模系统模型描述了系统的某个特殊方面，在需求文档中对自然语言描述的系统需求加入补充信息。系统模型的界定需求规格说明中应该包含的高层次的模型表示系统运行环境的模型说明系统如何分解为子系统的体系结构模型系统建模需要注意的事项第六页，共八十页，编辑于2023年，星期一需求分析前的工作需求（系统）分析与建模理解真实世界中的问题和用户的需要并提出满足这些需要的解决方案的过程。分析前的准备确认系统的参与者确认系统的运行环境确认系统的约束第七页，共八十页，编辑于2023年，星期一内容需求分析概述结构化需求分析方法面向对象需求分析方法第八页，共八十页，编辑于2023年，星期一需求分析与建模—结构化方法结构化方法是一种系统分析和设计的方法，包括定义、开发和确认系统模型过程中用到的表示法、指南和规则。功能需求分析与建模方法功能需求说明数据的用途，以及如何记录、计算、转换、修改及传输数据等。数据需求分析与建模方法数据需求指定系统的存储数据第九页，共八十页，编辑于2023年，星期一

结构化开发方法（StructuredDevelopingMethod）是现有的软件开发方法中最成熟、应用最广泛的方法，主要特点是快速、自然和方便。结构化开发方法由结构化分析方法（SA法）、结构化设计方法（SD法）及结构化程序设计方法（SP法）构成的。结构化分析方法是面向数据流的需求分析方法，是20世纪70年代末由Yourdon,Constaintine及DeMarco等人提出和发展，并得到广泛的应用。它适合于分析大型的数据处理系统，特别是企事业管理系统。

SA法也是一种建模的活动，主要是根据软件内部的数据传递、变换关系，自顶向下逐层分解，描绘出满足功能要求的软件模型。结构化分析方法第十页，共八十页，编辑于2023年，星期一

分解：对于一个复杂的系统，为了将复杂性降低到可以掌握的程度，可以把大问题分解成若干小问题，然后分别解决（如右图）。

结构化分析方法的基本思想是“分解”和“抽象”。抽象：分解可以分层进行，即先考虑问题最本质的属性，暂把细节略去,以后再逐层添加细节，直至涉及到最详细的内容，这种用最本质的属性表示一个系统的方法就是“抽象”。1.11.21.3x2132.12.22.31.11.3SA法的基本思想第十一页，共八十页，编辑于2023年，星期一需求分析的方法绘制系统关联图创建用户接口原型分析需求可行性确定需求的优先级别为需求建立模型（模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图）创建数据字典使用质量功能调配第十二页，共八十页，编辑于2023年，星期一需求分析方法（细节）采用SRS模板指明需求的来源为每项需求注上标号记录业务规范创建需求跟踪能力矩阵审查需求文档以需求为依据编写测试用例编写用户手册确定合格的标准。

第十三页，共八十页，编辑于2023年，星期一分析1:定义系统的边界评估原始需求，定义将要开发的计算机系统的边界。确定哪些是系统需求哪些是和系统相关的操作过程的需求哪些在系统范围之外的需求原则第十四页，共八十页，编辑于2023年，星期一分析2:系统环境建模环境模型是系统将要使用的语境模型，应该是最先开发的系统模型之一。效益：记录必须说明接口的外部系统模型包括：和正在说明的系统直接交互的其他系统其他有可能和本系统共存并发生交互的系统系统所在的业务过程（定义涉及的行为、它们的输入和输出、负责这些过程的人以及支持这些过程的软件）第十五页，共八十页，编辑于2023年，星期一系统环境建模-上下文图作用：上下文图能很好地概括产品的必要接口，初步确新产品包含了哪些内容，产品之外又包含哪些内容。即说明产品及其环境的图示说明产品的范围优点：上下文图为开发人员概括了所有的接口，在开发中或开发后，方便地验证是否已处理了所有接口用户能不费力地理解上下文图，并发现遗漏的接口。第十六页，共八十页，编辑于2023年，星期一系统环境建模案例邮件传阅系统环境建模企业OA办公系统图书管理系统操作管理员一般工作人员第十七页，共八十页，编辑于2023年，星期一分析3:系统体系结构建模效益体系结构模型有助于划分系统需求体系结构模型说明了系统功能的概况体系结构模型有助于需求工程师找出那些涉及多个子系统的需求体系结构模型描述方式-方框图第十八页，共八十页，编辑于2023年，星期一系统体系结构“标准”模式客户机-服务器通用服务器提供共享的系统功能分层系统系统功能通过调用更低层次所提供的功能来实现基于库的系统子系统通过一个共享库进行通信管道系统系统中的每个部件都进行一定的计算，并将结果传给其他部件以进行进一步的操作第十九页，共八十页，编辑于2023年，星期一体系结构建模举例第二十页，共八十页，编辑于2023年，星期一分析4:开发互补的系统建模互补的系统模型可以解释系统规格说明的不同方面。系统模型用来表达系统规格说明的行为视图或者结构视图。系统模型的例子数据处理模型组合模型分类模型刺激-响应模型过程模型第二十一页，共八十页，编辑于2023年，星期一分析5:事件列表与功能列表事件就是要求系统执行某项功能的请求业务事件与产品事件对复杂的业务任务采用任务说明、用例说明或数据流图等方法进行解释。对复杂的功能采用数据流图、算法描述、活动图、数学说明等进行解释第二十二页，共八十页，编辑于2023年，星期一事件列表与功能列表(续)事件及功能列表的优点主要作为核对清单，以说明应开发什么。而其中对这些功能的详细说明构成了功能需求的主要部分开发人员可以方便的检查产品是否实现每一个功能用户能够在某种程度上确认业务事件和任务列表通过一致性检查确定列表是否完备第二十三页，共八十页，编辑于2023年，星期一功能需求举例-活动图第二十四页，共八十页，编辑于2023年，星期一分析6:数据需求数据模型数据流图（状态图、活动图）数据字典虚拟窗口（原型界面）第二十五页，共八十页，编辑于2023年，星期一数据需求—数据模型数据模型说明了系统所要存储的数据以及数据之间的关系提供了对数据的高级“体系结构”视图，也可以描述信息的细节。模型：E-R模型、概念模型数据模型的优缺点第二十六页，共八十页，编辑于2023年，星期一数据需求—数据模型第二十七页，共八十页，编辑于2023年，星期一数据流图数据流图（DataFlowDiagram，DFD）是描述系统中数据流程的图形工具，它标识了一个系统的逻辑输入和逻辑输出，以及把逻辑输入转换为逻辑输出所需的加工处理。数据存储数据源点或终点加工加工名数据流数据流名文件名实体名箭头圆或椭圆单或双杠矩形框还有一些辅助的图例:一、数据流图的图符四种基本图形符号：TAB*CTAB*CTAB+CTAB+CTABC+TABC+*

与

+或互斥+第二十八页，共八十页，编辑于2023年，星期一顾客出版社验证订单汇总订单订单图书目录文件顾客档案待处理订单文件正确订单一批订单出版社档案文件出版社订单订货存根文件举例：图书预订系统画图步骤：

1、确定外部实体（顾客、出版社）及输入、输出数据流（订单、出版社订单）。

2、确定分解顶层的加工（验证订单、汇总订单）。

3、确定使用的文件（图书目录文件、顾客档案等5个文件）。

4、用数据流将各部分连接起来，形成数据封闭。加工和文件还有其他一些图例：加工加工名编号加工名编号文件名文件名文件注意：标注各加工框及数据流名称。第二十九页，共八十页，编辑于2023年，星期一经过初步的需求分析，得到系统功能要求：1、监视病员的病症（血压、体温、脉搏等）。2、定时更新病历。3、病员出现异常情况时报警。4、随机地产生某一病员的病情报告。实例：医院病房监护系统产生病情报告监视病情更新病历第三十页，共八十页，编辑于2023年，星期一监护系统分层DFD图病员护士护士病员监护系统病员日志病症信号要求报告病症报告报警顶层医院病房监护系统分层DFD图顶层确定了系统的范围，其外部实体为病员和护士。护士病员护士医院病房监护系统顶层第三十一页，共八十页，编辑于2023年，星期一

监护系统分层DFD图计算超过极限值否病员数据超过极限值报警开解信号产生报警信息病员极限格式化病员数据体温血压、体温、脉搏生理信号极限值时间脉搏血压日期时钟格式化病员数据3.13.23.33.4第二层：加工“中央监视”分解医院病房监护系统分层DFD图第一层格式化病员数据生理信号极限值病员护士护士中央监视病员日志病症信号要求报告病症报告报警局部监视生成报告病员极限更新日志病员数据1324日志数据第一层分解为局部监视、生成报告、中央监视、更新日志4个加工。这层的分解是关键。以4个加工中最重要的加工“中央监视”为例，进行第二层分解。第三十二页，共八十页，编辑于2023年，星期一数据流图的用处系统分析员用这种工具可以自顶向下分析系统信息流程；可在图上划出需要计算机处理的部分和需要修改的部分；根据逻辑存储，进一步作数据分析，向数据库数据过渡；根据数据流向，定出存取方式；对应一个处理过程，用相应的语言，判定表等工具来表达处理方法。第三十三页，共八十页，编辑于2023年，星期一数据需求—数据字典数据字典是一个系统组织的、叙述性的数据说明效益保证名字使用的一致性，避免名字重复使用和误解。有助于提高系统需求、设计和实现维护过程中的可跟踪性。第三十四页，共八十页，编辑于2023年，星期一数据需求—数据字典（续）数据字典应具有的信息模型中的实体的名字名字的别名或其它变体命名的实体类型命名实体和为何将它引入系统模型的描述对于命名实体的约束指向相关实体的联接第三十五页，共八十页，编辑于2023年，星期一分层数据流图只是表达了系统的“分解”，为了完整地描述这个系统，还需借助“数据词典”(datadictionary)和“小说明”对图中的每个数据和加工给出解释。对数据流图中包含的所有元素的定义的集合构成了数据词典。它有四类条目：数据流、数据项、文件及基本加工。在定义数据流或文件时，使用表2-1给出的符号。将这些条目按照一定的规则组织起来，构成数据词典。数据词典（DD）表2-1X=1••8表示X可取1到8中的任意一个值连接符••X=“a”表示X是取值为字符a的数据元素基本数据元素“•••”X=(a)表示a可在X中出现，也可不出现可选(•••)X=2{a}6或x={a}表示重复2~5次a重复m{•••}n或{•••}X={a}表示X由0个或多个a组成重复{•••}X=[a|b]表示X由a或b组成或[•••|•••]X=a+b表示X由a和b组成与+被定义为=例及说明含义符号Nm62第三十六页，共八十页，编辑于2023年，星期一数据流条目给出了DFD图中数据流的定义，通常列出该数据流的各组成数据项。例如，数据流“乘客名单”由若干“乘客姓名”、“单位名”和“等级”组成，则词典中的“乘客名单”条目是：乘客名单＝{乘客姓名＋单位名＋等级}又如，报名单＝姓名＋单位名＋年龄＋性别＋课程名数据词典类型加工条目加工条目就是“加工小说明”。一般应单独列出。数据项条目给出某个数据单项的定义，通常是该数据项的值类型、允许值等。例如：账号=00000~99999；存款期=[1|3|5]（单位：年）文件条目给出某个文件的定义，文件的定义通常是列出文件记录的组成数据流。例如，某销售系统的订单文件：订单文件＝订单编号＋顾客名称＋产品名称＋订货数量＋交货日期第三十七页，共八十页，编辑于2023年，星期一加工逻辑说明对数据流图中每一个不能再分解的基本加工都必须有一个加工小说明给出这个加工的精确描述。小说明中应精确地描述加工的激发条件、加工逻辑、优先级、执行频率和出错处理等。加工逻辑是其中最基本的部分，是指用户对这个加工的逻辑要求。对基本加工说明有三种描述方式：结构化语言，判定表，判定树。

一、结构化语言结构化语言是介于自然语言和形式语言之间的一种半形式语言，它是自然语言的一个受限制的子集。一般分为两层结构：外层语法较具体，为控制结构（顺序、选择、循环）,内层较灵活，表达“做什么”。例如：外层可为以下结构：

1、顺序结构

2、选择结构

IF–THEN-ELSE;CASE-OF-ENDCASE；

3、循环结构

WHILE-DO;REPEAT-UNTIL第三十八页，共八十页，编辑于2023年，星期一例二“确定能否供货”的加工逻辑：根据库存记录

IF订单项目的数量<该项目库存量的临界值

THEN可供货处理

ELSE此订单缺货，登录，待进货后再处理

ENDIF例一根据当前流动资金值确定贬值数。IFtheCurrent–Capital–Valueislessthen$1000ThenSetDepreciated–AmounttoCurrent–Capital–Value.SetCurrent–Capital–Valuetozero.OtherwiseSetDepreciated–Amountto10%ofCurrent–Capital–Value.ReduceCurrent–Capital-Valueby10%.

一、结构化语言结构化语言特点:简单，易学，少二义性。不好处理组合条件。结构化语言举例第三十九页，共八十页，编辑于2023年，星期一判定表是一种二维的表格，常用于较复杂的组合条件（与结构化语言比较），通常由四部分组成。判定表判定表的特点：可处理较复杂的组合条件，但不易理解.不易输入计算机。条件框—

条件定义。操作框—

操作的定义。条件条目—

各条件的取值及组合。操作条目—

在各条件取值组合下所执行的操作。条件框条件条目操作框操作条目例如:对商店每天的营业额所收税率营业额X（¥）1000≤X<50005000≤X<10000X≥10000税率5%8%10%第四十页，共八十页，编辑于2023年，星期一例：一图书销售系统，其中一加工为“优先处理”，条件是：顾客的营业额大于1000元，同时必须信誉好，或者虽然信誉不好，但是20年以上的老主顾。判定表应用举例分析：共有3个判定条件，有8种可能的组合情况（图a）。对图a进行化简后，得到图b。化简后

图b图aY-满足条件N-不满足条件X-选中判定的结论第四十一页，共八十页，编辑于2023年，星期一特点:描述一般组合条件较清晰，易理解。不易输入计算机。好的支付信誉

优惠处理坏的支付信誉营业额>1000元≤1000元正常处理

>20年优惠处理

<20年

正常处理如上例判定树第四十二页，共八十页，编辑于2023年，星期一数据需求—虚拟窗口虚拟窗口是理想化的屏幕图像，形同真实的屏幕图像，但不具备功能或菜单。虚拟窗口的目的。虚拟窗口的优缺点。第四十三页，共八十页，编辑于2023年，星期一需求分级关注最重要的需求划分优先级可以帮助项目相关人员判断系统的核心需求需求优先级之间明显的关联可以帮助设计者决定系统体系结构，还可以帮助解决可能发生的设计冲突第四十四页，共八十页，编辑于2023年，星期一使用多维方法进行需求分级效益需求分级是发现需求之间的共性和例外关系的依据。有助于发现需求重叠和冲突。需求分级提高需求文档的跟踪能力需求分级可以帮助你找到遗漏的需求实施需求分级最简单的方法就是使用刻面方法。定义一系列的维度或者说是刻面，并用相应的关键词描述它们。第四十五页，共八十页，编辑于2023年，星期一评估需求风险对每一项需求或者一系列相关的需求进行风险分析，指出在实现需求过程中可能会发生的问题、这些问题发生的机率及其影响。第四十六页，共八十页，编辑于2023年，星期一内容需求分析概述结构化需求分析方法面向对象需求分析方法第四十七页，共八十页，编辑于2023年，星期一采用面向对象分析建模首先是描述需求;其次根据需求建立系统的静态模型,以构造系统的结构;第三步是描述系统的行为。其中在第一步与第二步中所建立的模型都是静态的,包括用例图、类图(包含包)、对象图、组件图和配置图等五个图形,是标准建模语言UML的静态建模机制。第四十八页，共八十页，编辑于2023年，星期一采用面向对象分析建模-续其中第三步中所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系。它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语言UML的动态建模机制。第四十九页，共八十页，编辑于2023年，星期一OO分析师与设计师的任务找出参与者和用例详述用例组织用例模型（注意：用例仅能获取功能需求）需求工程师任务找出功能性需求找出非功能性需求优先排序需求跟踪用例和需求第五十页，共八十页，编辑于2023年，星期一用例过程描述用例第五十一页，共八十页，编辑于2023年，星期一用例建模活动的输出用例建模活动的输出是用例模型该模型具有四个部分：参与者-人们所扮演的角色或者使用系统的事物；用例-参与者与系统交互的物件；关系-参与者和用例之间有意义的联系；系统边界-包围用例的方框，说明正在建模系统的边界第五十二页，共八十页，编辑于2023年，星期一关于”用例”的误解用例模型就是指”UML用例图”用例模型包括用例图和用例描述用例分析技术是一项分解技术.用例分析技术是一项合成技术第五十三页，共八十页，编辑于2023年，星期一用例是什么?用例实例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果特点用例实例也就是“使用场景”用例应该给参与者带来可见的价值用例是在系统中第五十四页，共八十页，编辑于2023年，星期一典型的用例建模活动找出系统边界识别参与者合并需求找出用例详述用例第五十五页，共八十页，编辑于2023年，星期一用例建模—找出系统边界系统边界是定义由谁或什么（即参与者）使用系统，系统能够为哪些参与者提供什么特定的利益（即用例）第五十六页，共八十页，编辑于2023年，星期一用例建模—参与者参与者是直接与系统交互的事物所扮演的角色。参与者角色人其它系统硬件系统时钟第五十七页，共八十页，编辑于2023年，星期一如何识别参与者谁或什么使用该系统？交互中，它们扮演什么角色？谁安装系统？谁启动和关闭系统？谁维护系统？与该系统交互的是其它什么系统？谁从该系统获取信息，谁提供信息给系统？有什么事情发生在固定时间？第五十八页，共八十页，编辑于2023年，星期一在识别参与者需要注意的！参与者对于系统而言总是外部的；参与者直接同系统交互；参与者表示人和事物同系统发生交互时所扮演的角色，而不是特定的人和特定的事物；一个人或事物在与系统发生交互时，同时或不同时扮演多种角色；每个参与者需要一个具有业务意义的简短名称；每个参与者必须有简短描述，它从业务角度描述参与者是什么。像类一样，参与者可以具有分栏，表示参与者属性和它可能接收的事件；第五十九页，共八十页，编辑于2023年，星期一用例建模—用例用例定义为“系统、子系统或类能够与外部参与者交互所执行的动作序列，包括各种序列以及出错序列的规格说明。用例是参与者想要系统做的事情。第六十页，共八十页，编辑于2023年，星期一识别用例特定参与者希望系统提供什么功能？系统存储和检索信息吗？如果有，哪个参与者触发这个行为？当系统改变状态时，通知参与者吗？存在影响系统的外部时间吗？是谁通知系统这些事件的？第六十一页，共八十页，编辑于2023年，星期一用例图邮件订阅系统PlaceOrderCancelOrderCheckOrderStatusSendCatalogShipProductCustomerDispatcherShippingCompany第六十二页，共八十页，编辑于2023年，星期一详述用例用例模型补充需求项目词汇表用例详述用例用例阐述员第六十三页，共八十页，编辑于2023年，星期一在编写事件流需要注意的！使用简单的语法：主语明确，语义易于理解;明确写出“谁控制球”从俯视的角度来编写显示过程向前推移显示参与者的意图而非动作包括“合理的活动集”（带数据的请求、系统确认、更改内部、返回结果）用“确认”而非“检查是否”可选择地提及时间限制第六十四页，共八十页，编辑于2023年，星期一用例技术的优点用例相对容易写用例是用用户的语言写的用例为行为或场景提供相关线索，用户和开发人员都能够理解用例的图形表示提高对复杂软件系统的可理解性用例描述的场景在确认阶段几乎可以直接用作测试脚本第六十五页，共八十页，编辑于2023年，星期一用例方法的适用场合适用场合系统是面向功能的，具有多种类型的用户和功能行为团队采用UML和面向对象（OO）方法实现系统不太适用场合系统用户很少或没有并且接口也很少系统中非功能性需求和设计约束占主导地位第六十六页，共八十页，编辑于2023年，星期一用例建模实战-调研后的功能特性FEAT01.新增学生信息FEAT02.修改已有的学生信息FEAT03.学生信息按统招生、工程硕士、学位进修分别建档FEAT04.录入新生信息时能够自动按规则生成学生号号FEAT05.统招生、工程硕士与学位进修生采用不同的书号规则FEAT06.录入新生信息时如果重名将自动提示FEAT07.按入学时间、所在学院、学生类别等关键字组合查询学生信息FEAT08.列出所有学生信息FEAT09.记录学生休学、退学、转学和留级情况FEAT10.学生状态能够自动反应在学生信息中FEAT11.按姓名、学号查询学生成绩情况、交费情况、奖惩情况FEAT12.列出所有的获得奖惩情况学生名单及所在学院FEAT13.按特定时间段统计学生学习成绩和学分FEAT14.所有查询、列表、统计功能应可以单独对统招生、工程硕士、学位进修类别进行；也可以按照学院进行第六十七页，共八十页，编辑于2023年，星期一学生老师用例建模实战-识别参与者第六十八页，共八十页，编辑于2023年，星期一特征用例用例FEAT01.新增学生信息UC01.新增学生信息FEAT03.学生信息按统招生、工程硕士、学位进修分别建档FEAT04.录入新生信息时能够自动按规则生成学生号号FEAT05.统招生、工程硕士与学位进修生采用不同的书号规则FEAT06.录入新生信息时如果重名将自动提示FEAT02.修改已有的学生信息UC02.修改学生信息FEAT07.按入学时间、所在学院、学生类别等关键字组合查询学生信息UC03.查询学生信息FEAT08.列出所有学生信息FEAT14.所有查询、列表、统计功能应可以单独对统招生、工程硕士、学位进修类别进行；也可以按照学院进行FEAT09.记录学生休学、退学、转学和留级情况UC04.改变学生状态FEAT10.学生状态能够自动反应在学生信息中FEAT11.按姓名、学号查询学生成绩情况、交费情况、奖惩情况UC05.查询学生状态信息FEAT12.列出所有的获得奖惩情况学生名单及所在学院FEAT14.所有查询、列表、统计功能应可以单独对统招生、工程硕士、学位进修类别进行；也可以按照学院进行FEAT13.按特定时间段统计学生学习成绩和学分UC056.统计学生成绩FEAT14.所有查询、列表、统计功能应可以单独对统招生、工程硕士、学位进修类别进行；也可以按照学院进行用例建模实战-合并需求获得用例第六十九页，共八十页，编辑于2023年，星期一用例建模实战-绘制用例图邮件订阅系统新增学生信息修改学生信息查询学生信息改变学生状态查询学生状态teacherstudent统计学生成绩第七十页，共八十页，编辑于2023年，星期一1）用例名称：应该与用例图相符，并写上其相应的编号；2）简要说明：该用例对参与者所传递的价值结果进行描述。3）前置条件：是执行用例之前必须存在的系统状态4）后置条件：用例执行完毕系统可能处于的一组状态。5）扩展点：如果包括扩展或包含用例，则写出扩展或包含用例名，并说明在什么情况下使用。如果有，则应该在编写事件流的同时进行编写。6）优先级:说明用户对该用例的期望值，可以为今后开发时制定先后顺序。用例建模实战-细化用例描述第七十一页，共八十页，编辑于2023年，星期一用例建模实战-用例粒度思辨“四轮马车”如何整理用例的层次第七十二页，共八十页，编辑于2023年，星期一把建立原型系统作为一种可能采取的策略的主要理由：由于人类认识能力的局限，不能预先指定所有要求。在用户和系统分析员之间存在固有的交流鸿沟。用户需要一个“活的”系统模型，以便获得实践经验。在开发过程中重复和反复是必要的和不可避免的。目前有快速建立原型系统的工具可供选用。由于成本的增加，过去很少采用样机策略。但是，由于正确地提出用户需求是软件开发工程成功的基础，近来主张采用样机策略的人也多起来。原型需求分析第七十三页，共八十页，编辑于2023年，星期一按照传统的瀑布模型进行软件开发，由于将软件开发这样一个充满回朔的过程硬性地割裂开，虽然强调各个阶段的复审，而用户所提出的需求往往是模糊的，因此很难得到一个完整精确的规格说明，直接影响到后期的开发，针对其主要缺点推出了原型化方法。2.3原型化方法什么是原型化方法（PrototypingMethod）

？原型是软件开发过程中，软件的一个早期可运行的版本，它反映了最终系统的部分重要特性。原型化方法的基本思想是花费少量代价建立一个可运行的系统，使用户及早获得学习的机会，原型化方法又称速成原型法（RapidPrototyping），强调的是软件开发人员与用户的不断交互，通过原型的演进不断适应用户任务改变的需求。将维护和修改阶段的工作尽早进行，使用户验收提前，从而使软件产品更加适用。第七十四页，共八十页，编辑于2023年，星期一由于软件项目的特点和运行原型的目的不同，原型有两种不同的类型。软件原型的分类

2、追加（addon）型也称为快速建立渐进原型RCP法（RapidCyclicPrototyping）法采用循环渐进的开发方式，对系统模型作连续精化，即先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，将系统需要具备的性质逐步添加上去，通过不断地扩充修改，逐步追加新的要求，直至所有性质全部满足，此时的原型模型也就是最终的产品。

1、废弃（throwaway）型也称为快速建立需求规格原型RSP法（RapidSpecific