软件工程导论第3章需求分析课件

第3章 需求分析3.1需求分析的任务 需求分析的任务就是准确地回答“系统必须做什么?”这个问题，是通过系统分析员与用户一起商定，清晰、准确、具体地描述软件产品必须具有的功能、性能、运行规格等要求。软件需求分析阶段的目的是澄清用户的要求，并把双方共同的理解明确地表达成一份书面文档——软件需求规格说明书。第3章 需求分析3.1需求分析的任务1用户与分析员的责任用户与分析员的责任2第3章 需求分析需求分析的具体任务包括：1.功能需求这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能。2.性能需求性能需求指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。第3章 需求分析需求分析的具体任务包括：33.可靠性和可用性需求可靠性需求定量地指定系统的可靠性。可用性与可靠性密切相关，它量化了用户可以使用系统的程度。4.出错处理需求这类需求说明系统对环境错误应该怎样响应。例如，如果它接收到从另一个系统发来的违反协议格式的消息，应该做什么?注意，上述这类错误并不是由该应用系统本身造成的。3.可靠性和可用性需求4在某些情况下，“出错处理”指的是当应用系统发现它自己犯下一个错误时所采取的行动。但是，应该有选择地提出这类出错处理需求。我们的目的是开发出正确的系统，而不是用无休止的出错处理代码掩盖自己的错误。总之，对应用系统本身错误的检测应该仅限于系统的关键部分，而且应该尽可能少。5.接口需求接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。在某些情况下，“出错处理”指的是当应用系统发现它自己犯下一个56.约束设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。在需求分析阶段提出这类需求，并不是要取代设计(或实现)过程，只是说明用户或环境强加给项目的限制条件。常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。7.逆向需求逆向需求说明软件系统不应该做什么。理论上有无限多个逆向需求，我们应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。6.约束68.将来可能提出的要求应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。8.将来可能提出的要求7需求分类一、综合需求3.1.3软件需求分析的任务环境需求功能需求性能需求需求分类一、综合需求3.1.3软件需求分析的任务环境需求功8软件工程导论第3章需求分析9(1)功能需求

系统做什么？系统何时做什么？系统何时及如何修改或升级？(1)功能需求系统做什么？10(2)性能需求软件开发的技术性指标例如：存储容量限制执行速度、相应时间吞吐量(2)性能需求软件开发的技术性指标11(3)环境需求硬件设备：机型、外设、接口、地点、分布、温度、湿度、磁场干扰等软件：操作系统网络数据库(3)环境需求硬件设备：机型、外设、接口、12(4)界面需求有来自其它系统的输入吗？到自其它系统的输出吗？对数据格式有规定吗？对数据存储介质有规定吗？(4)界面需求有来自其它系统的输入吗？13(5)用户或人的因素

用户类型？各种用户熟练程度？需受何种训练？用户理解、使用系统的难度？用户错误操作系统的可能性？(5)用户或人的因素用户类型？14(6)数据需求输入、输出数据的格式？接收、发送数据的频率？数据的准确性和精度？数据流量？数据需保持的时间？(6)数据需求输入、输出数据的格式？15(7)资源需求

软件运行时所需的数据、软件。内存空间等资源。软件开发、维护所需的人力、支撑软件、开发设备等。(7)资源需求软件运行时所需的数据、软件。内存空间等资16(8)安全保密要求需对访问系统或系统信息加以控制吗？如何隔离用户之间的数据？用户程序如何与其它程序和操作系统隔离？系统备份要求？(8)安全保密要求需对访问系统或系统信息加以控制吗？17二、逻辑模型结构化分析——数据流图（DFD）面向对象分析——类图和用例图二、逻辑模型结构化分析——数据流图（DFD）面向对象分析——18三、需求评审对需求文档进行正式审查以需求为依据编写测试用例编写用户手册在需求开发早期即可起草一份用户手册确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的

三、需求评审对需求文档进行正式审查19四、编写文档1.编写“需求说明书”；2.编写初步的用户使用手册；3.编写确认测试计划；4.修改完善项目开发计划。四、编写文档1.编写“需求说明书”；20第3章 需求分析3.2需求分析的过程 需求分析阶段可分为四个过程：调查研究、分析与综合、书写需求分析的文档和评审。（1）调查研究 系统分析员协同程序员向用户做需求调查，阅软件计划中的可行性报告和项目开发计划报告，访问系统现场，并由此确定当前系统必须做什么，并获得当前系统的具体模型，用数据流图或IPO图表示出来。

第3章 需求分析3.2需求分析的过程21软件工程导论第3章需求分析22软件工程导论第3章需求分析23第3章 需求分析（2）分析与综合 分析员需从数据流和数据结构出发，逐步细化所有的软件功能，找出系统中各元素之间的联系、接口特征和设计上的限制，分析它们能否满足功能要求，是否合理。依据功能需求、性能需求、运行环境需求等，剔除其中不合理的部分，增加其需要的部分。最终综合成系统的解决方案后，给出目标系统的详细逻辑模型。第3章 需求分析（2）分析与综合24软件工程导论第3章需求分析25软件工程导论第3章需求分析26(3)编制需求分析阶段的文档软件需求说明书数据要求说明书初步的用户手册修改、完善与确定软件开发实施计划(3)编制需求分析阶段的文档27(4)需求分析评审系统定义的目标是否与用户的要求一致;系统需求分析阶段提供的文档资料是否齐全;文档中的所有描述是否完整、清晰、准确反映用户要求;与所有其它系统成分的重要接口是否都已经描述;(4)需求分析评审系统定义的目标是否与用户的要求一致;28被开发项目的数据流与数据结构是否足够，确定;所有图表是否清楚，在不补充说明时能否理解;主要功能是否已包括在规定的软件范围之内，是否都已充分说明;设计的约束条件或限制条件是否符合实际;开发的技术风险是什么;被开发项目的数据流与数据结构是否足够，确定;29是否考虑过软件需求的其它方案;是否考虑过将来可能会提出的软件需求;是否详细制定了检验标准，它们能否对系统定义是否成功进行确认;是否考虑过软件需求的其它方案;30软件工程导论第3章需求分析313.3与用户沟通获取需求的方法

访谈是最早开始使用的获取用户需求的技术，也是迄今为止仍然广泛使用的需求分析技术。访谈有两种基本形式，分别是正式的和非正式的访谈。正式访谈时，系统分析员将提出一些事先准备好的具体问题。在非正式访谈中，分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法。3.3.1访谈3.3与用户沟通获取需求的方法

访谈是最早开始使用的获取32会谈法（1）识别信息源（2）计划会谈内容（3）进行访问（4）概括获取内容优点：面对面，灵活，适应性强；探讨较深入缺点：费时；获取信息难以评价；访问者带有偏见；被访者刻意隐瞒会谈法（1）识别信息源优点：面对面，灵活，适应性强；33发调查表法发调查表法34软件工程导论第3章需求分析35所有问题应局限于一个主题应考虑回答者的背景：如受教育程度、行话等应易于打分所提供答案应具有排他性所提问题用词应准确优点：经济、易于管理；可以快速将结果制表并分析缺点：只能采集一些特殊的、数量有限的信息；不具备灵活性；不能对问题的回答做进一步的探索和研究设计调查表应注意：优点：经济、易于管理；设计调查表应注意：36观察法

观看与系统有关的实际处理过程进行信息采集工作取样

采集有关现行系统运行情况的信息，如错误率和错误分布情况

观察法37软件系统本质上是信息处理系统，而任何信息处理系统的基本功能都是把输入数据转变成需要的输出信息。数据决定了需要的处理和算法，数据显然是需求分析的出发点。在可行性研究阶段许多实际的数据元素被忽略了，需求分析的目标之一就是把数据流和数据存储定义到元素级。3.3.2面向数据流自顶向下求精软件系统本质上是信息处理系统，而任何信息处理系统的基本功能都38面向数据流自顶向下求精过程软件工程导论第3章需求分析39使用传统的访谈或面向数据流自顶向下求精方法定义需求时，用户处于被动地位而且往往有意无意地与开发者区分“彼此”。由于不能像同一个团队的人那样齐心协力地识别和精化需求，这两种方法的效果有时并不理想。为了解决上述问题，人们研究出一种面向团队的需求收集法，称为简易的应用规格说明技术。这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。3.3.3简易的应用规格说明技术使用传统的访谈或面向数据流自顶向下求精方法定义需求时，用户处40快速建立软件原型是最准确、最有效、最强大的需求分析技术。快速原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。构建原型的要点是，它应该实现用户看得见的功能(例如，屏幕显示或打印报表)，省略目标系统的“隐含”功能(例如，修改文件)。3.3.4快速建立软件原型快速建立软件原型是最准确、最有效、最强大的需求分析技术。快速41用户不清楚软件将会以什么形式实现业务，而对现有业务是非常清楚的。通过原型法，用户能直观的看到将来用软件是怎样实现业务，是否符合用户的期望值。

原型主要描述2个问题：用户不清楚软件将会以什么形式实现业务，而对现有业务是非常清楚421

界面处理流程和后台业务处理流程是否正确。

界面处理流程：界面是指用户面对的界面。用户只有看到具体的软件界面，才会形成感性的知识，才能对开发的系统提出具体要求，和进一步的改进需求。才能理解我们推荐的解决方案。另一方面，这也是检验PM对用户需求的理解是否正确，能否做出符合要求的产品。-

后台处理流程：建模！解释后台处理的逻辑。模型是用户方面的技术人员。好的模型对于系统的扩展和改变至关重要。

1

界面处理流程和后台业务处理流程是否正确。432

原型法处理界面设计问题

在不少项目中，一旦用户对界面挑剔起来将会花费大量时间。因此，在原型阶段，就应包括界面设计的原则。从界面风格，易用性，友好化，用户习惯等多方面达成一定规定，会对程序员在界面设计上节省大量时间。

2

原型法处理界面设计问题

441、原型可以用于吸引需求，也有风险a、开发周期的控制更难。b、用户的需求扩大。（个人意见）

2、原型可以做技术评估（大规模开发和实现之前，考核方案是否合适，规格说明是否可靠；找出软件方案中比较难的技术问题进行解决，解决不了换方案，工作量太大换方案，影响系统性能换方案....）

3、原型不能用作进度估计（至少一般情况如此）

4、做原型参与竞标，争夺项目（展示形原型）

1、原型可以用于吸引需求，也有风险45例如：大多数的动态网站，都是在客户初步的需求基础上，先制作一个大体上能表现功能的静态网站出来，然后客户根据这个静态网站提出进一步的详细需求，开发便按照这个详细需求来进行。

例如：大多数的动态网站，都是在客户初步的需求基础上，先制作一46为了快速地构建和修改原型，通常使用下述3种方法和工具：(1)第四代技术第四代技术包括众多数据库查询和报表语言、程序和应用系统生成器以及其他非常高级的非过程语言。第四代技术使得软件工程师能够快速地生成可执行的代码，它们是较理想的快速原型工具。为了快速地构建和修改原型，通常使用下述3种方法和工具：47第一代编程语言机器语言特征：面向机器。第二代编程语言汇编语言特征：用针对指令的符号代替二进制代码。第三代编程语言C、C++、pascal、特征：有类型的、过程式语言；标准化的和独立于硬件的；在这些语言中的操作必须用详细的、一步接一步的算法方式指定；做很少的隐含处理；是通用的

第一代编程语言机器语言48第四代编程语言4GL特征：通常有自由形式的变量使用；通常不需要类型定义并允许动态类型的变量；不强调模块化、基于过程的编码式样；包含一些预定义的过程来进行各种高层操作，这些高层操作涉及大量隐含的处理。

第四代语言(4GL)应当尽可能的提供你需要的简单语句，而不是如何处理它的详细过程。第四代编程语言4GL第四代语言(4GL)应当尽可能的提供49第三代程序fori=1to10

printinexti语句多数被限制在算术操作上，带有有限的字符串功能。

使用shell你可以在几分钟或几小时中把应用程序组装起来，而不是使用3GL要求的几周或几个月。在4GL中你应当可以用一或两行来写多数应用程序。使用

shell

你可以有如下表示:$cutsomecolumns<file|grep'string'|sort|lpr

这个简短的程序得到一个文件中的一些列，连接管道通过grep来得到带有特定字符串的行、排序它们并把它们发送到行打印机。在COBOL、PL/I、C和多数商业4GL中相同的报告将使用数十到数百行。

第三代程序fori=1to10语句多数被限制在算术操作50(2)可重用的软件构件另外一种快速构建原型的方法，是使用一组已有的软件构件(也称为组件)来装配(而不是从头构造)原型。软件构件可以是数据结构(或数据库)，或软件体系结构构件(即程序)，或过程构件(即模块)。(3)形式化规格说明和原型环境(2)可重用的软件构件(3)形式化规格说明和原型环境513.4分析建模与规格说明3.4.1分析建模为了更好地理解复杂事物，人们常常采用建立事物模型的方法。所谓模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通常，模型由一组图形符号和组织这些符号的规则组成。3.4分析建模与规格说明3.4.1分析建模为了更好地52模型的作用建模的原因：在建模过程中了解系统通过抽象降低复杂性有助于回忆所有的细节有助于开发小组间的交流有助于与用户的交流为系统的维护提供文档

模型的作用建模的原因：53模型的类型数学模型描述模型图形模型模型的类型数学模型54需求分析的步骤当前系统目标系统物理模型逻辑模型逻辑模型物理模型模型化抽象化具体化实例化怎么做做什么当前系统目标系统需求定义需求分析的步骤当前目标物理逻辑逻辑物理模型化抽象化具体化实例55现行系统目标系统描述新系统是如何实施的（包括技术）。描述新系统的主要业务功能和用户新的需求，无论系统应如何实施。描述重要的业务功能，无论系统是如何实施的。逻辑模型物理模型(本质模型、概念模型)(实施模型、技术模型)描述现实系统是如何在物理上实现的。现目描述新系统是如何实施的（包括技术）。描述新系统的主要业务56需求分析过程示意学生（1）通过对现实环境的调查，获得当前系统的物理模型

学生购书申请购书单发票领书单书107张教务科206王会计室206李出纳员303赵教材科学生购买教材的物理模型需求分析过程示意学（1）通过对现实环境的调查，获得当前系统的57需求分析过程示意(2)去掉具体模型中的非本质因素，抽象出当前系统的逻辑模型

学生购买教材的逻辑模型学生学生购书申请购书单发票领书单书审查有效性开发票开领书单发书需求分析过程示意(2)去掉具体模型中的非本质因素，抽象出当58需求分析过程示意(3)分析当前系统与目标系统的差别，建立目标系统的逻辑模型

计算机售书系统的逻辑模型学生学生购书单发票领书单审查并开发票开领书单无效书单需求分析过程示意(3)分析当前系统与目标系统的差别，建立目59分析阶段中常用的模型（逻辑模型）数据流图（DFD）实体―联系图（ERD）类图实例图时序图状态图协作图事件列表数据流定义数据元素定义……分析阶段中常用的模型（逻辑模型）数据流图（DFD）60通过需求分析除了创建分析模型之外，还应该写出软件需求规格说明书，它是需求分析阶段得出的最主要的文档。自然语言形式化方法3.4.2软件需求规格说明通过需求分析除了创建分析模型之外，还应该写出软件需求规格说明61需求分析示例—教材购销管理系统（1）问题描述：学校教材科根据业务的需要，建立一个学校教材购销管理系统，提高教材采购、销售和信息管理的效率。学生张秘书购书申请王会计李出纳赵保管学生购书证明购书申请购书申请书学生审查有效性购书单开发票开领书单发书学生有效购书单发票领书单书学生审查并开发票购书单开领书单发书学生发票领书单书2）去掉具体模型中的非本质因素，抽象出当前系统的逻辑模型1）通过对现实环境的调查研究，获得当前系统的具体模型3）分析当前系统与目标系统的差别，建立目标系统的逻辑模型。需求分析示例—教材购销管理系统（1）问题描述：学校教材科根62需求分析示例—教材购销管理系统（2）学生审查并开发票购书单开领书单学生发票领书单无效书单4）对目标系统进行补充和完善，并写出完整的需求说明。学生1审查并开发票购书单2开领书单学生发票领书单无效书单各班学生用书表教材存量表5）对需求说明进行复审，直到确认文档齐全，并且符合用户的全部需求为止需求分析示例—教材购销管理系统（2）学生审查并开发票购书单开63需求分析示例—教材购销管理系统（3）学生教材购销管理系统书库保管员1.教材购销管理系统的顶层DFD学生书库保管员2.第二层DFD图—教材购销系统购书单领书单缺书单进书通知购书单领书单1销售2采购进书通知F2:缺书登记表F1:教材存量表缺书单进书通知需求分析示例—教材购销管理系统（3）学生教材购销管理系统书64需求分析示例—教材购销管理系统（4）1.1审查有效性1.2开发票有效购书单1.3领书并开领书单发票1.4登记缺书1.5补售教材F2:缺书登记表学生学生无效书单领书单领书单F3:各班学生用书表F4:售书登记表补售书单暂缺书单采购3.第三层DFD图—销售子系统F1:教材存量表需求分析示例—教材购销管理系统（4）1.1审查有效65需求分析示例—教材购销管理系统（5）2.3修改教材库存和待购量2.1按书号汇总缺书F2:缺书登记表销售子系统书库保管员F1:教材存量表进书通知3.第三层DFD图—采购子系统2.2按出版社统计缺书F5:待购教材表F6:教材一览表进书通知需求分析示例—教材购销管理系统（5）2.366需求分析示例—教材购销管理系统（6）数据字典（DataDirectory-DD)领书单=学院+专业+班级+学号+姓名+{书号+[书名]+数量}+日期有效购书单=领书单发票=学号+姓名+{书号+[书名]+单价+数量+总价}+书费合计教材存量表={书号+单价+数量}暂缺书单=学号+姓名+{书号+数量}补售书单=学号+姓名+{书号+数量}需求分析示例—教材购销管理系统（6）数据字典（DataDi673.4实体-联系图在数据词典中，强调对数据存储结构的逻辑设计，并用数据结构表达数据项之间的逻辑关系。但任何一个软件系统都可能有成千上万个数据项，仅仅描述这些数据项是不够的，更重要的是如何把它们以最优的方式组织起来，以满足系统对数据的要求。3.4实体-联系图在数据词典中，强调对数据存储结构的逻辑68为了把用户的数据要求清楚、准确地描述出来，系统分析员通常建立一个概念性的数据模型(也称为信息模型)。它描述了从用户角度看到的数据，它反映了用户的现实环境，而且与在软件系统中的实现方法无关。数据模型中包含3种相互关联的信息：数据对象、数据对象的属性及数据对象彼此间相互连接的关系。为了把用户的数据要求清楚、准确地描述出来，系统分析员通常建立69数据对象是对软件必须理解的复合信息的抽象。所谓复合信息是指具有一系列不同性质或属性的事物，仅有单个值的事物(例如，宽度)不是数据对象。数据对象可以是外部实体(例如，产生或使用信息的任何事物)、事物(例如，报表)、行为(例如，打电话)、事件(例如，响警报)、角色(例如，教师、学生)、单位(例如，会计科)、地点(例如，仓库)或结构(例如，文件)等。总之，可以由一组属性来定义的实体都可以被认为是数据对象。3.5.1数据对象数据对象是对软件必须理解的复合信息的抽象。所谓复合信息是指具70属性定义了数据对象的性质。必须把一个或多个属性定义为“标识符”，也就是说，当我们希望找到数据对象的一个实例时，用标识符属性作为“关键字”(通常简称为“键”)。应该根据对所要解决的问题的理解，来确定特定数据对象的一组合适的属性。3.5.2属性属性定义了数据对象的性质。必须把一个或多个属性定义为“标识符71数据对象彼此之间相互连接的方式称为联系，也称为关系。联系可分为以下3种类型：(1)一对一联系(1∶1)例如，一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是一对一的。(2)一对多联系(1∶N)例如，某校教师与课程之间存在一对多的联系“教”，即每位教师可以教多门课程，但是每门课程只能由一位教师来教(见图3.2)。3.5.3联系数据对象彼此之间相互连接的方式称为联系，也称为关系。联系可分72(3)多对多联系(M∶N)例如，学生与课程间的联系是多对多的，即一个学生可以学多门课程，而每门课程可以有多个学生来学。联系也可能有属性。例如，学生“学”某门课程所取得的成绩，既不是学生的属性也不是课程的属性。由于“成绩”既依赖于某名特定的学生又依赖于某门特定的课程，所以它是学生与课程之间的联系“学”的属性(3)多对多联系(M∶N)73某校教学管理E-R图软件工程导论第3章需求分析743.5.4实体-联系图的符号ER模型实体联系属性学生教师课程教学111NMN姓名学号3.5.4实体-联系图的符号ER模型学生教75软件系统经常使用各种长期保存的信息，这些信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。3.6数据规范化软件系统经常使用各种长期保存的信息，这些信息通常以一定方式组761NF定义：如果关系模式的所有属性都是不可再分的数据项,则称该关系属于第一范式,记作R1NF。

规范化的表课程名称讲课时数实验时数微机原理化

学65154010例：非规范化的表课程名称学时数讲课

实验微机原理化

学651540101NF规范化的表课程名称讲课时数实验时数微机原理6577

例：设车间考核职工完成生产定额关系WW（日期,工号,姓名,工种,超额,定额,车间,车间主任）

F(日期、工号

超额,工号

姓名,工号

车间,

工号

工种,工种

定额,车间

车间主任,

工号

车间主任）日期

工号

姓名

工种

定额

超额

车间

车间主任90.590.590.590.590.690.690.690.6101102103104101102103104丁一王二张三李四丁一王二张三李四车工车工钳工铣工车工车工钳工铣工808075708080757022%17%14%20%19%25%16%26%工具金工工具金工工具金工工具金工李明赵杰李明赵杰李明赵杰李明赵杰例：设车间考核职工完成生产定额关系W日期工号78上述关系属于第一范式，但存在以下问题：1、数据冗余大2、修改麻烦3、插入异常4、删除异常原因在于模式中存在着各种数据依赖关系.例：日期、工号

超额

日期、工号

姓名

日期、工号

工种

日期、工号

车间

日期、

工号

车间

车间

车间主任

日期、

工号

车间主任

}

完全依赖

部分依赖

传递依赖上述关系属于第一范式，但存在以下问题：原因在于模式中存在着各792NF定义：若关系R1NF，且它的每一非主属性都完全依赖于关键字,则称R属于第二范式。记为

R2NF。

例：对刚才的关系W进行分解，消除部分依赖于KEY的属性部分,使之满足2NF。即：WWSG+WPY且

WSG2NF、WPY2NF

F={工号

姓名

工号

工种

工号

车间

工号

定额

工号

主任

工种

定额

车间

主任}

工号

姓名

工种

定额

车间

主任101102103104丁一王二张三李四车工车工钳工铣工80807570工具金工工具金工李明赵杰李明赵杰WSG2NF2NF例：对刚才的关系W进行分解，消除部分依赖于KEY的80日期

工号

超额90.590.590.590.590.690.690.690.610110210310410110210310422%17%14%20%19%25%16%26%F={日期、工号

超额}分解后虽消除了部分依赖关系，并没有消除传递依赖关系。所以仍然存在修改麻烦、插入、删除异常的现象。如：

工号

车间主任

工号

定额

是传递依赖

且

工种、车间主任有重复。WPY2NF日期工号超额90.510122%F=813NF定义：若R2NF,且它的每一非主属性都不传递依赖于R的关键字。则称R属于第三范式。记为

R3NF。

继续分解：将WSGWG+WS+WR工种

定额车工钳工铣工807570WG3NFW=WPY+WG+WS+WR车间

主任工具金工李明赵杰WS

3NF工号

姓名

工种

车间101102103104丁一王二张三李四车工车工钳工铣工工具金工工具金工WR3NF3NF继续分解：将WSGWG+WS+WR工82关系规范化问题小结：1、确定所有的候选关键字;2、选定主关键字;3、确定关系的各个属性中,哪些是主属性,哪些是非主属性;4、找出属性间的依赖关系（函数依赖）;5、根据应用特点,确定规范化到第几范式;6、分解关系,分解必须是无损的,不得丢失信息;7、分解后的关系,力求相互独立,即对一个关系内容的修改不要影响到分解出来的其他关系。

关系规范化问题小结：4、找出属性间的依赖关系（函数依赖）;83规范化过程使每个属性不可再分消除非主属性对关键字部分依赖消除非主属性对关键字传递依赖消除主属性对关键字部分与传递依赖非规范关系1NF2NF3NF使每个决定子都是候选关键子BCNFBCNF3NF2NF1NF规范化过程使每个属性不可再分消除非主属性对关键字部分依赖消除84状态转换图(简称为状态图)通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外，状态图还指明了作为特定事件的结果系统将做哪些动作(例如，处理数据)。3.7状态转换图状态转换图(简称为状态图)通过描绘系统的状态及引起系统状态转85状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。系统对事件的响应，既可以是做一个(或一系列)动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。在状态图中定义的状态主要有：初态(即初始状态)、终态(即最终状态)和中间状态。在一张状态图中只能有一个初态，而终态则可以有0至多个。3.7.1状态状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种86事件是在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。例如，内部时钟表明某个规定的时间段已经过去，用户移动或点击鼠标等都是事件。简而言之，事件就是引起系统做动作或(和)转换状态的控制信息。3.7.2事件事件是在某个特定时刻发生的事情，它是对引起系统做动作或(和)87在状态图中，初态用实心圆表示，终态用一对同心圆(内圆为实心圆)表示。中间状态用圆角矩形表示，可以用两条水平横线把它分成上、中、下3个部分。上面部分为状态的名称，这部分是必须有的；中间部分为状态变量的名字和值，这部分是可选的；下面部分是活动表，这部分也是可选的。3.7.3符号在状态图中，初态用实心圆表示，终态用一对同心圆(内圆为实心圆88状态图中使用的主要符号软件工程导论第3章需求分析89其中，“事件名”可以是任何事件的名称。在活动表中经常使用下述3种标准事件：entry，exit和do。entry事件指定进入该状态的动作，exit事件指定退出该状态的动作，而do事件则指定在该状态下的动作。需要时可以为事件指定参数表。动作表达式描述应做的具体动作。状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。状态变迁通常是由事件触发的，在这种情况下应在表示状态转换的箭头线上标出触发转换的事件表达式；如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。活动表的语法格式如下：事件名(参数表)/动作表达式其中，“事件名”可以是任何事件的名称。在活动表中经常使用下述90事件表达式的语法如下：事件说明［守卫条件］／动作表达式其中，事件说明的语法为：事件名(参数表)。守卫条件是一个布尔表达式。如果同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时，状态转换才发生。如果只有守卫条件没有事件说明，则只要守卫条件为真状态转换就发生。动作表达式是一个过程表达式，当状态转换开始时执行该表达式。事件表达式的语法如下：91

状态图

状态1Do:活动1状态2.…...事件1[条件1]/动作1结束事件初始事件空闲可视菜单左边按钮按下/显示弹出菜单左边按钮弹起/擦除弹出菜单光标移动/高亮菜单项弹出菜单动作状态图状态1Do:活动1状态2.…..92ATM机状态图3.6.4例子

ATM机状态图3.6.4例子

93层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构。树形结构的顶层是一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素(不能再分割的元素)。例如，描绘一家计算机公司全部产品的数据结构可以用图3.5中的层次方框图表示。3.8其他图形工具

3.8.1层次方框图层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构94层次方框图的一个例子软件工程导论第3章需求分析95法国计算机科学家Warnier提出了表示信息层次结构的另外一种图形工具。和层次方框图类似，Warnier图也用树形结构描绘信息，但是这种图形工具比层次方框图提供了更丰富的描绘手段。用Warnier图可以表明信息的逻辑组织，也就是说，它可以指出一类信息或一个信息元素是重复出现的，也可以表示特定信息在某一类信息中是有条件地出现的。因为重复和条件约束是说明软件处理过程的基础，所以很容易把Warnier图转变成软件设计的工具。3.8.2Warnier图法国计算机科学家Warnier提出了表示信息层次结构的另外一96Warnier图的一个例子软件工程导论第3章需求分析97考虑一个典型的报纸自动组版系统。报纸作为其中重要的信息对象，具有以下内容：1．首版

1）标题新闻

2）国内新闻

3）本地新闻2．商业金融版

1）股市行情

2）商业新闻

3）广告3．文化体育版

1）文化、体育新闻

2）散文

3）新书评论考虑一个典型的报纸自动组版系统。报纸作为其中重要的信息对象，98该信息结构用Warnier图表示如下：标题新闻国内新闻本地新闻股市行情(0,1)商业新闻广告(1,5)文化、体育新闻散文

新书评论文化体育版首版商业金融版报纸3.8其他图形工具该信息结构用Warnier图表示如下：标题新闻股市行情(0,99花括号内的信息条目构成顺序关系；花括号从左至右排列表示树型层次结构；符号“⊕”表示不可兼具的选择关系；圆括号内的数字表示重复次数：（1,n）表示重复结构，（1）或不标次数表示顺序结构，（0,1）表示选择结构。花括号内的信息条目构成顺序关系；100IPO图是输入、处理、输出图的简称，它是美国IBM公司发展完善起来的一种图形工具，能够方便地描绘输入数据、对数据的处理和输出数据之间的关系。3.8.3IPO图IPO图是输入、处理、输出图的简称，它是美国IBM公司发展完101IPO图的一个例子图软件工程导论第3章需求分析102改进的IPO图的形式软件工程导论第3章需求分析1033.8其他图形工具3.8其他图形工具1043.8其他图形工具3.8其他图形工具105需求分析阶段的工作结果是开发软件系统的重要基础，大量统计数字表明，软件系统中15%的错误起源于错误的需求。为了提高软件质量，确保软件开发成功，降低软件开发成本，一旦对目标系统提出一组要求之后，必须严格验证这些需求的正确性。一般说来，应该从下述4个方面进行验证：3.9验证软件需求

3.9.1从哪些方面验证软件需求的正确性

需求分析阶段的工作结果是开发软件系统的重要基础，大量统计数字106(1)一致性所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。(2)完整性需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。(3)现实性指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。对硬件技术的进步可以做些预测，对软件技术的进步则很难做出预测，只能从现有技术水平出发判断需求的现实性。(4)有效性必须证明需求是正确有效的，确实能解决用户面对的问题。(1)一致性所有需求必须是一致的，任何一条需求不能和其他需1071.验证需求的一致性当需求分析的结果是用自然语言书写的时候，除了靠人工技术审查验证软件系统规格说明书的正确性之外，目前还没有其他更好的“测试”方法。但是，这种非形式化的规格说明书是难于验证的，特别在目标系统规模庞大、规格说明书篇幅很长的时候，人工审查的效果是没有保证的，冗余、遗漏和不一致等问题可能没被发现而继续保留下来，以致软件开发工作不能在正确的基础上顺利进行。3.9.2验证软件需求的方法1.验证需求的一致性3.9.2验证软件需求的方法108为了克服上述困难，人们提出了形式化的描述软件需求的方法。当软件需求规格说明书是用形式化的需求陈述语言书写的时候，可以用软件工具验证需求的一致性，从而能有效地保证软件需求的一致性。2.验证需求的现实性为了验证需求的现实性，分析员应该参照以往开发类似系统的经验，分析用现有的软、硬件技术实现目标系统的可能性。必要的时候应该采用仿真或性能模拟技术，辅助分析软件需求规格说明书的现实性。为了克服上述困难，人们提出了形式化的描述软件需求的方法。当软1093.验证需求的完整性和有效性只有目标系统的用户才真正知道软件需求规格说明书是否完整、准确地描述了他们的需求。因此，检验需求的完整性，特别是证明系统确实满足用户的实际需要(即，需求的有效性)，只有在用户的密切合作下才能完成。然而许多用户并不能清楚地认识到他们的需要(特别在要开发的系统是全新的，以前没有使用类似系统的经验时，情况更是如此)，不能有效地比较陈述需求的语句和实际需要的功能。只有当他们有某种工作着的软件系统可以实际使用和评价时，才能完整确切地提出他们的需要。3.验证需求的完整性和有效性110例：“产品应在不少于每60秒的正常周期内提供状态信息”

这个需求是不完整的：状态信息是什么，如何显示给用户。这个需求有几处含糊。我们在谈论产品的哪部分？状态信息间隔真的假定为不少于60秒？，甚者每10年显示一条新的状态信息也可以？也许它的意图是消息间隔不应超过60秒，那么1毫秒是不是太短？“每”这个词导致了不确定性。问题的后果，就是需求的不可证实。

例：“产品应在不少于每60秒的正常周期内提供状态信息”

111弥补缺陷，重写需求的一种方法：

1、状态信息

1.1后台任务管理器因该以误差上下不超过10秒的

60秒间隔，在用户界面的指定位置显示状态信息

1.2如果后台进程处理正常，那么应该显示任务已完成的百分数/比

1.3任务完成时，应显示相关的信息

1.4后台任务出错应该显示错误信息

弥补缺陷，重写需求的一种方法：112理想的做法是先根据需求分析的结果开发出一个软件系统，请用户试用一段时间以便能认识到他们的实际需要是什么，在此基础上再写出正式的“正确的”规格说明书。但是，这种做法将使软件成本增加一倍，因此实际上几乎不可能采用这种方法。使用原型系统是一个比较现实的替代方法，开发原型系统所需要的成本和时间可以大大少于开发实际系统所需要的。用户通过试用原型系统，也能获得许多宝贵的经验，从而可以提出更符合实际的要求。理想的做法是先根据需求分析的结果开发出一个软件系统，请用户试113

使用原型系统的目的，通常是显示目标系统的主要功能而不是性能。为了达到这个目的快速建立原型系统，并且可以适当降低对接口、可靠性和程序质量的要求，此外还可以省掉许多文档资料方面的工作，从而可以大大降低原型系统的开发成本。使用原型系统的目的，通常是显示目标系统的主要114为了更有效地保证软件需求的正确性，特别是为了保证需求的一致性，需要有适当的软件工具支持需求分析工作。这类软件工具应该满足下列要求：(1)必须有形式化的语法(或表)，因此可以用计算机自动处理使用这种语法说明的内容；(2)使用这个软件工具能够导出详细的文档；(3)必须提供分析(测试)规格说明书的不一致性和冗余性的手段，并且应该能够产生一组报告指明对完整性分析的结果；3.9.3用于需求分析的软件工具为了更有效地保证软件需求的正确性，特别是为了保证需求的一致性115(4)使用这个软件工具之后，应该能够改进通信状况。作为需求工程方法学的一部分，在1977年设计完成了RSL(需求陈述语言)。RSL中的语句是计算机可以处理的，处理以后把从这些语句中得到的信息集中存放在一个称为ASSM（抽象系统语义模型）的数据库中。有一组软件工具处理ASSM数据库中的信息以产生出用PASCAL语言书写的模拟程序，从而可以检验需求的一致性、完整性和现实性。(4)使用这个软件工具之后，应该能够改进通信状况。1161977年美国密执安大学开发了PSL/PSA(问题陈述语言/问题陈述分析程序)系统。这个系统是CADSAT（计算机辅助设计和规格说明分析工具）的一部分，它的基本结构类似于RSL。其中PSL是用来描述系统的形式语言，PSA是处理PSL描述的分析程序。用PSL描述的系统属性放在一个数据库中。一旦建立起数据库之后即可增加信息、删除信息或修改信息，并且保持信息的一致性。PSA对数据库进行处理以产生各种报告，测试不一致性或遗漏，并且生成文档资料。1977年美国密执安大学开发了PSL/PSA(问题陈述语言/117PSL/PSA系统的功能主要有下述4种：(1)描述任何应用领域的信息系统；(2)创建一个数据库保存对该信息系统的描述符；(3)对描述符施加增加、删除和更改等操作；(4)产生格式化的文档和关于规格说明书的各种分析报告。PSL/PSA系统用描述符从系统信息流、系统结构、数据结构、数据导出、系统规模、系统动态、系统性质和项目管理等8个方面描述信息系统。PSL/PSA系统的功能主要有下述4种：118一旦用PSL对系统做了完整描述，就可以调用PSA产生一组分析报告，其中包括所有修改规格说明数据库的记录，用各种形式描述数据库信息的参照报告(包括图形形式的描述)，关于项目管理信息的总结报告，以及评价数据库特性的分析报告。借助PSL/PSA系统可以边对目标系统进行自顶向下的逐层分解，边将需求分析过程中遇到的数据流、文件、处理等对象用PSL描述出来并输入到PSL/PSA系统中。PSA将对输入信息作一致性和完整性检查，并且保存这些描述信息。一旦用PSL对系统做了完整描述，就可以调用PSA产生一组分析119PSL/PSA系统的主要优点是它改进了文档质量，能保证文档具有完整性、一致性和无二义性，从而可以减少管理和维护的费用。数据存放在数据库中，便于增加、删除和更改，这也是它的一个优点。PSL/PSA系统的主要优点是它改进了文档质量，能保证文档具120结论

a)需求分析是整个项目管理中需要重点控制的几个关键节点之一，首先思想上一定要重视。

b)需求分析报告的编写者要参与到需求的搜集工作中，准确领会客户的意图，并转化成软件能够实现的功能。对于说不清楚需求的客户，要善于问关键问题，引导客户提出自己的需求。可以采取的措施是事先编制一个问卷调查之类的文档，详细列举需要客户回答的问题，以便防止遗漏。

c)需求报告的编写者要能够对客户需求进行深入分析，区别出哪些需求存在日后变更的可能，哪些需求属于相对固定的，哪些需求能够实现，哪些需求需要变通才能实现，以便于指导后面的功能设计。

d)需求分析报告对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。可以通过评审，用大家的力量来避免这种情况发生结论121

e)需求报告的每个关乎功能的描述都要让客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。

f)需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题

g)帮助客户去理解提交给他的需求分析报告而不是只等签字，对于有能够用好几种方式实现的功能，尽量做到能让客户去比较和选择。不要让客户对报告中的部分产生歧义。只有客户对报告的完全的理解，才能在日后客户提出的修改被认为是需求变更的时候能够得到客户的理解

h)最后，需求分析报告一定要双方共同签字确认e)需求报告的每个关乎功能的描述都要让客户明白和理解，122第3章 需求分析3.1需求分析的任务 需求分析的任务就是准确地回答“系统必须做什么?”这个问题，是通过系统分析员与用户一起商定，清晰、准确、具体地描述软件产品必须具有的功能、性能、运行规格等要求。软件需求分析阶段的目的是澄清用户的要求，并把双方共同的理解明确地表达成一份书面文档——软件需求规格说明书。第3章 需求分析3.1需求分析的任务123用户与分析员的责任用户与分析员的责任124第3章 需求分析需求分析的具体任务包括：1.功能需求这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能。2.性能需求性能需求指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。第3章 需求分析需求分析的具体任务包括：1253.可靠性和可用性需求可靠性需求定量地指定系统的可靠性。可用性与可靠性密切相关，它量化了用户可以使用系统的程度。4.出错处理需求这类需求说明系统对环境错误应该怎样响应。例如，如果它接收到从另一个系统发来的违反协议格式的消息，应该做什么?注意，上述这类错误并不是由该应用系统本身造成的。3.可靠性和可用性需求126在某些情况下，“出错处理”指的是当应用系统发现它自己犯下一个错误时所采取的行动。但是，应该有选择地提出这类出错处理需求。我们的目的是开发出正确的系统，而不是用无休止的出错处理代码掩盖自己的错误。总之，对应用系统本身错误的检测应该仅限于系统的关键部分，而且应该尽可能少。5.接口需求接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。在某些情况下，“出错处理”指的是当应用系统发现它自己犯下一个1276.约束设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。在需求分析阶段提出这类需求，并不是要取代设计(或实现)过程，只是说明用户或环境强加给项目的限制条件。常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。7.逆向需求逆向需求说明软件系统不应该做什么。理论上有无限多个逆向需求，我们应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。6.约束1288.将来可能提出的要求应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。8.将来可能提出的要求129需求分类一、综合需求3.1.3软件需求分析的任务环境需求功能需求性能需求需求分类一、综合需求3.1.3软件需求分析的任务环境需求功130软件工程导论第3章需求分析131(1)功能需求

系统做什么？系统何时做什么？系统何时及如何修改或升级？(1)功能需求系统做什么？132(2)性能需求软件开发的技术性指标例如：存储容量限制执行速度、相应时间吞吐量(2)性能需求软件开发的技术性指标133(3)环境需求硬件设备：机型、外设、接口、地点、分布、温度、湿度、磁场干扰等软件：操作系统网络数据库(3)环境需求硬件设备：机型、外设、接口、134(4)界面需求有来自其它系统的输入吗？到自其它系统的输出吗？对数据格式有规定吗？对数据存储介质有规定吗？(4)界面需求有来自其它系统的输入吗？135(5)用户或人的因素

用户类型？各种用户熟练程度？需受何种训练？用户理解、使用系统的难度？用户错误操作系统的可能性？(5)用户或人的因素用户类型？136(6)数据需求输入、输出数据的格式？接收、发送数据的频率？数据的准确性和精度？数据流量？数据需保持的时间？(6)数据需求输入、输出数据的格式？137(7)资源需求

软件运行时所需的数据、软件。内存空间等资源。软件开发、维护所需的人力、支撑软件、开发设备等。(7)资源需求软件运行时所需的数据、软件。内存空间等资138(8)安全保密要求需对访问系统或系统信息加以控制吗？如何隔离用户之间的数据？用户程序如何与其它程序和操作系统隔离？系统备份要求？(8)安全保密要求需对访问系统或系统信息加以控制吗？139二、逻辑模型结构化分析——数据流图（DFD）面向对象分析——类图和用例图二、逻辑模型结构化分析——数据流图（DFD）面向对象分析——140三、需求评审对需求文档进行正式审查以需求为依据编写测试用例编写用户手册在需求开发早期即可起草一份用户手册确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的

三、需求评审对需求文档进行正式审查141四、编写文档1.编写“需求说明书”；2.编写初步的用户使用手册；3.编写确认测试计划；4.修改完善项目开发计划。四、编写文档1.编写“需求说明书”；142第3章 需求分析3.2需求分析的过程 需求分析阶段可分为四个过程：调查研究、分析与综合、书写需求分析的文档和评审。（1）调查研究 系统分析员协同程序员向用户做需求调查，阅软件计划中的可行性报告和项目开发计划报告，访问系统现场，并由此确定当前系统必须做什么，并获得当前系统的具体模型，用数据流图或IPO图表示出来。

第3章 需求分析3.2需求分析的过程143软件工程导论第3章需求分析144软件工程导论第3章需求分析145第3章 需求分析（2）分析与综合 分析员需从数据流和数据结构出发，逐步细化所有的软件功能，找出系统中各元素之间的联系、接口特征和设计上的限制，分析它们能否满足功能要求，是否合理。依据功能需求、性能需求、运行环境需求等，剔除其中不合理的部分，增加其需要的部分。最终综合成系统的解决方案后，给出目标系统的详细逻辑模型。第3章 需求分析（2）分析与综合146软件工程导论第3章需求分析147软件工程导论第3章需求分析148(3)编制需求分析阶段的文档软件需求说明书数据要求说明书初步的用户手册修改、完善与确定软件开发实施计划(3)编制需求分析阶段的文档149(4)需求分析评审系统定义的目标是否与用户的要求一致;系统需求分析阶段提供的文档资料是否齐全;文档中的所有描述是否完整、清晰、准确反映用户要求;与所有其它系统成分的重要接口是否都已经描述;(4)需求分析评审系统定义的目标是否与用户的要求一致;150被开发项目的数据流与数据结构是否足够，确定;所有图表是否清楚，在不补充说明时能否理解;主要功能是否已包括在规定的软件范围之内，是否都已充分说明;设计的约束条件或限制条件是否符合实际;开发的技术风险是什么;被开发项目的数据流与数据结构是否足够，确定;151是否考虑过软件需求的其它方案;是否考虑过将来可能会提出的软件需求;是否详细制定了检验标准，它们能否对系统定义是否成功进行确认;是否考虑过软件需求的其它方案;152软件工程导论第3章需求分析1533.3与用户沟通获取需求的方法

访谈是最早开始使用的获取用户需求的技术，也是迄今为止仍然广泛使用的需求分析技术。访谈有两种基本形式，分别是正式的和非正式的访谈。正式访谈时，系统分析员将提出一些事先准备好的具体问题。在非正式访谈中，分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法。3.3.1访谈3.3与用户沟通获取需求的方法

访谈是最早开始使用的获取154会谈法（1）识别信息源（2）计划会谈内容（3）进行访问（4）概括获取内容优点：面对面，灵活，适应性强；探讨较深入缺点：费时；获取信息难以评价；访问者带有偏见；被访者刻意隐瞒会谈法（1）识别信息源优点：面对面，灵活，适应性强；155发调查表法发调查表法156软件工程导论第3章需求分析157所有问题应局限于一个主题应考虑回答者的背景：如受教育程度、行话等应易于打分所提供答案应具有排他性所提问题用词应准确优点：经济、易于管理；可以快速将结果制表并分析缺点：只能采集一些特殊的、数量有限的信息；不具备灵活性；不能对问题的回答做进一步的探索和研究设计调查表应注意：优点：经济、易于管理；设计调查表应注意：158观察法

观看与系统有关的实际处理过程进行信息采集工作取样

采集有关现行系统运行情况的信息，如错误率和错误分布情况

观察法159软件系统本质上是信息处理系统，而任何信息处理系统的基本功能都是把输入数据转变成需要的输出信息。数据决定了需要的处理和算法，数据显然是需求分析的出发点。在可行性研究阶段许多实际的数据元素被忽略了，需求分析的目标之一就是把数据流和数据存储定义到元素级。3.3.2面向数据流自顶向下求精软件系统本质上是信息处理系统，而任何信息处理系统的基本功能都160面向数据流自顶向下求精过程软件工程导论第3章需求分析161使用传统的访谈或面向数据流自顶向下求精方法定义需求时，用户处于被动地位而且往往有意无意地与开发者区分“彼此”。由于不能像同一个团队的人那样齐心协力地识别和精化需求，这两种方法的效果有时并不理想。为了解决上述问题，人们研究出一种面向团队的需求收集法，称为简易的应用规格说明技术。这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。3.3.3简易的应用规格说明技术使用传统的访谈或面向数据流自顶向下求精方法定义需求时，用户处162快速建立软件原型是最准确、最有效、最强大的需求分析技术。快速原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。构建原型的要点是，它应该实现用户看得见的功能(例如，屏幕显示或打印报表)，省略目标系统的“隐含”功能(例如，修改文件)。3.3.4快速建立软件原型快速建立软件原型是最准确、最有效、最强大的需求分析技术。快速163用户不清楚软件将会以什么形式实现业务，而对现有业务是非常清楚的。通过原型法，用户能直观的看到将来用软件是怎样实现业务，是否符合用户的期望值。

原型主要描述2个问题：用户不清楚软件将会以什么形式实现业务，而对现有业务是非常清楚1641

界面处理流程和后台业务处理流程是否正确。

界面处理流程：界面是指用户面对的界面。用户只有看到具体的软件界面，才会形成感性的知识，才能对开发的系统提出具体要求，和进一步的改进需求。才能理解我们推荐的解决方案。另一方面，这也是检验PM对用户需求的理解是否正确，能否做出符合要求的产品。-

后台处理流程：建模！解释后台处理的逻辑。模型是用户方面的技术人员。好的模型对于系统的扩展和改变至关重要。

1

界面处理流程和后台业务处理流程是否正确。1652

原型法处理界面设计问题

在不少项目中，一旦用户对界面挑剔起来将会花费大量时间。因此，在原型阶段，就应包括界面设计的原则。从界面风格，易用性，友好化，用户习惯等多方面达成一定规定，会对程序员在界面设计上节省大量时间。

2

原型法处理界面设计问题

1661、原型可以用于吸引需求，也有风险a、开发周期的控制更难。b、用户的需求扩大。（个人意见）

2、原型可以做技术评估（大规模开发和实现之前，考核方案是否合适，规格说明是否可靠；找出软件方案中比较难的技术问题进行解决，解决不了换方案，工作量太大换方案，影响系统性能换方案....）

3、原型不能用作进度估计（至少一般情况如此）

4、做原型参与竞标，争夺项目（展示形原型）

1、原型可以用于吸引需求，也有风险167例如：大多数的动态网站，都是在客户初步的需求基础上，先制作一个大体上能表现功能的静态网站出来，然后客户根据这个静态网站提出进一步的详细需求，开发便按照这个详细需求来进行。

例如：大多数的动态网站，都是在客户初步的需求基础上，先制作一168为了快速地构建和修改原型，通常使用下述3种方法和工具：(1)第四代技术第四代技术包括众多数据库查询和报表语言、程序和应用系统生成器以及其他非常高级的非过程语言。第四代技术使得软件工程师能够快速地生成可执行的代码，它们是较理想的快速原型工具。为了快速地构建和修改原型，通常使用下述3种方法和工具：169第一代编程语言机器语言特征：面向机器。第二代编程语言汇编语言特征：用针对指令的符号代替二进制代码。第三代编程语言C、C++、pascal、特征：有类型的、过程式语言；标准化的和独立于硬件的；在这些语言中的操作必须用详细的、一步接一步的算法方式指定；做很少的隐含处理；是通用的

第一代编程语言机器语言170第四代编程语言4GL特征：通常有自由形式的变量使用；通常不需要类型定义并允许动态类型的变量；不强调模块化、基于过程的编码式样；包含一些预定义的过程来进行各种高层操作，这些高层操作涉及大量隐含的处理。

第四代语言(4GL)应当尽可能的提供你需要的简单语句，而不是如何处理它的详细过程。第四代编程语言4GL第四代语言(4GL)应当尽可能的提供171第三代程序fori=1to10

printinexti语句多数被限制在算术操作上，带有有限的字符串功能。

使用shell你可以在几分钟或几小时中把应用程序组装起来，而不是使用3GL要求的几周或几个月。在4GL中你应当可以用一或两行来写多数应用程序。使用

shell

你可以有如下表示:$cutsomecolumns<file|grep'string'|sort|lpr

这个简短的程序得到一个文件中的一些列，连接管道通过grep来得到带有特定字符串的行、排序它们并把它们发送到行打印机。在COBOL、PL/I、C和多数商业4GL中相同的报告将使用数十到数百行。

第三代程序fori=1to10语句多数被限制在算术操作172(2)可重