软件工程教案2

第二章 软件需求分析一、复习要求1. 了解软件需求的目标和任务。2. 了解软件软件需求的获取方法。3. 了解可行性研究的方法和可行性研究报告的主要内容。4. 掌握结构化分析方法。5. 了解支持需求分析的原型化方法。6. 了解需求规格说明和需求评审的主要内容。二、内容提要1. 软件需求分析的目标和任务软件需求分析的目标是深入描述软件的功能和性能，确定软件设计的约束和软件同其它系统元素的接口细节，定义软件的其它有效性需求。需求分析阶段研究的对象是软件项目的用户要求。一方面，必须全面理解用户的各项要求，但又不能全盘接受所有的要求，另一方面，要准确地表达被接受的用户要求。只有经过确切描述的软件需求才能成为软件设计的基础。通常软件开发项目是要实现目标系统的物理模型。作为目标系统的参考，需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。其实现步骤如图2.1所示。 图2.1 参考当前系统建立目标系统模型2. 需求分析的过程需求分析阶段的工作，可以分成以下四个方面：(1) 问题识别首先系统分析人员要确定对目标系统的综合要求，即软件的需求。并提出这些需求实现条件，以及需求应达到的标准。这些需求包括功能需求、性能需求、环境需求、可靠性需求、安全保密要求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求，并预先估计以后系统可能达到的目标。此外，还需要注意其它非功能性的需求。如针对采用某种开发模式，确定质量控制标准、里程碑和评审、验收标准、各种质量要求的优先级等，以及可维护性方面的需求。此外，要建立分析所需要的通信途径，以保证能顺利地对问题进行分析。分析所需的通信途径如图2.2所示。 图2.2 软件需求分析的通信途径(2) 分析与综合问题分析和方案的综合是需求分析的第二方面的工作。分析员必须从信息流和信息结构出发，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的限制，判断是否存在因片面性或短期行为而导致的不合理的用户要求，是否有用户尚未提出的真正有价值的潜在要求。剔除其不合理的部分，增加其需要部分。最终综合成系统的解决方案，给出目标系统的详细逻辑模型。(3) 编制需求分析阶段的文档已经确定下来的需求应当得到清晰准确的描述。通常我们把描述需求的文档叫做软件需求说明书。同时，为了确切表达用户对软件的输入输出要求，还需要制定数据要求说明书及编写初步的用户手册。(4) 需求分析评审作为需求分析阶段工作的复查手段，应该对功能的正确性、文档的一致性、完备性、准确性和清晰性，以及其它需求给予评价。为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。评审结束应有评审负责人的结论意见及签字。除分析员之外，用户需求者，开发部门的管理者，软件设计、实现、测试的人员都应当参加评审工作。3. 需求获取技术需求获取技术包括两方面的工作： 建立获取用户需求的方法的框架； 支持和监控需求获取的过程的机制。获取用户需求的主要方法是调查研究。(1) 了解系统的需求。软件开发常常是系统开发的一部分。仔细分析研究系统的需求规格说明，对软件的需求获取是很有必要的。(2) 市场调查。了解市场对待开发软件有什么样的要求；了解市场上有无与待开发软件类似的系统。如果有，在功能上、性能上、价格上情况如何。(3) 访问用户和用户领域的专家。把从用户那里得到的信息作为重要的原始资料进行分析；访问用户领域的专家所得到的信息将有助于对用户需求的理解。(4) 考察现场。了解用户实际的操作环境、操作过程和操作要求。对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。在做调查研究时，可以采取如下的调查方式： 制定调查提纲，向不同层次的用户发调查表。 按用户的不同层次，分别召开调查会，了解用户对待开发系统的想法和建议。 向用户领域的专家或在关键岗位上工作的人个别咨询。 实地考察，跟踪现场业务流程。 查阅与待开发系统有关的资料。 使用各种调查工具，如数据流图、任务分解图、网络图等。为了能够有效地获取和理清用户需求，应当打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自的长处，协同工作。4. 可行性研究和可行性研究报告(1) 可行性研究这是在软件项目计划阶段应该做的事情，包括四个方面的研究： 经济可行性 ：进行成本效益分析。从经济角度判断系统开发是否“合算”。 技术可行性 ：进行技术风险评价。从开发者的技术实力、以往工作基础、问题的复杂性等出发，判断系统开发在时间、费用等限制条件下成功的可能性。 法律可行性 ：确定系统开发可能导致的任何侵权、妨碍和责任。 方案的选择 ：评价系统或产品开发的几个可能的候选方案。最后给出结论意见。(2) 经济可行性分析员需要进行成本效益分析。所谓成本，包括： 购置并安装软、硬件及有关设备的费用； 系统开发费用； 系统安装、运行及维护的费用； 人员培训费用。而效益是指： 系统为用户增加的收入或为用户节省的开支，这是有形的效益； 给潜在用户心理上造成的影响，这是无形的效益。它可以转化为有形的效益。(3) 技术可行性分析员需要根据系统的功能、性能需求，建立系统模型。然后对此模型进行一系列的试验、评审和修改。最后由项目管理人员作出是否进行系统开发的决定。如果开发技术风险很大，或者模型演示表明当前采用的技术和方法不能实现系统预期的功能和性能，或者系统的实现不支持各子系统的集成，则项目管理人员可以作出停止系统开发的决定。(4) 方案的选择分析员考虑问题解决的方案。一般采用将一个大而复杂的系统分解为若干个子系统的办法来降低解的复杂性。如何进行系统分解、如何定义各子系统的功能、性能和界面，实现方案不唯一。可以采用折衷的方法，反复比较各个方案的成本效益，选择可行的方案。(5) 可行性研究报告可行性报告的形式可以有多种，但最重要的内容应当有：. 项目背景： 问题描述 实现环境 限制条件. 管理概要和建议： 重要的研究结果 说明 建议 影响. 候选方案： 候选系统的配置 最终方案的选择标准. 系统描述： 系统工作范围的简要说明 被分配系统元素的可行性. 经济可行性（成本效益分析）： 经费概算 预期的经济效益. 技术可行性（技术风险评价）： 技术实力 已有工作基础 设备条件. 法律可行性： 系统开发可能导致的侵权，违法和责任. 用户使用可行性： 用户单位的行政管理，工作制度 使用人员的素质. 其它与项目有关的问题： 其它方案介绍 未来可能的变化可行性研究报告首先由项目负责人审查（审查内容是否可靠），再上报给上级主管审阅（估价项目的地位）。从可行性研究应当得出“行或不行”的决断。当然，在以后的开发阶段，还要其它“行还是不行”的决定。5. 结构化分析方法结构化分析方法最初由Douglas Ross提出，由DeMarco推广，由Ward和Mellor以及后来的Hatley和Pirbhai扩充，形成了今天的结构化分析方法的框架。结构化分析方法是一种建模技术。它建立的分析模型如图2.3所示。数据对象描述加工规格说明实体关系图数据流图 数据 词典状态迁移图控制规格说明图2.3 分析模型的结构在模型的核心是数据词典，它描述了所有的在目标系统中使用的和生成的数据对象。围绕着这个核心的有三种图：实体关系图(ERD)描述数据对象及数据对象之间的关系；数据流图(DFD)描述数据在系统中如何被传送或变换，以及描述如何对数据流进行变换的功能（子功能）；状态迁移图(STD)描述系统对外部事件如何响应，如何动作。因此，ERD用于数据建模，DFD用于功能建模，STD用于行为建模。(1) 数据建模数据模型包括三种互相关联的信息：数据对象，描述对象的属性，描述对象间相互连接的关系。 数据对象 ：是需被目标系统所理解的复合信息的表示。所谓复合信息是具有若干不同特征或属性的信息。数据对象可以是外部实体（如显示器），事物（如报表或显示），角色（如教师或学生），行为（如一个电话呼叫）或事件（如单击鼠标左键），组织单位（如研究生院），地点（如注册室）或结构（如文件）。数据对象只封装了数据，没有包含作用于这些数据上的操作。这与面向对象范型中的类和对象不同。具有相同特征的数据对象组成的集合仍然称为数据对象，其中的某一个对象叫做该数据对象的一个实例。 属性 ：定义了数据对象的特征。它可用来： 为数据对象的实例命名； 描述这个实例； 建立对另一个数据对象的另一个实例的引用。如学生数据对象的属性可以有学号、姓名、性别、出生年月、籍贯等。为了唯一地标识数据对象的某一个实例，定义数据对象中的一个属性或几个属性为关键码(key)，书写为_id，例如在“学生”数据对象中用“学号”做关键码，它可唯一地标识一个“学生”数据对象中的实例。 关系 ：各个数据对象的实例之间有关联。如一个学生“张鹏”选修两门课程“软件工程”与“计算机网络”，学生与课程的实例通过“选修”关联起来。实例的关联有三种： 一对一(1:1)； 一对多(1:m)； 多对多(n:m)。这种实例的关联称为“基数”。基数表明了“重复性”。如1位教师带学生班的30位同学，就是1:m的关系。但也有1位教师带0位同学的情形。所以实例关联有是“可选”还是“必须”之分。用“”表示关系是可选的，用“”表示关系必须出现1次。如图2.4所示。这表明了关系的“参与性”。 基数：1位教师 基数：多位学生 管带教师学生 参与性：必须的 参与性：可选的 图2.4 基数与参与性 实体关系图 ：数据对象及其关系可用ERD表示。图2.5给出学生选修课程的ERD及描述学生属性的实体对象表。 选课课程学生 数据对象表 学 号姓 名性 别出生年月籍贯图2.5 简单的ERD和数据对象表(2) 功能建模和数据流最初，结构化分析方法仅讨论数据流建模。目标系统被表示成如图2.6所示的数据变换流程图。系统的功能体现在核心的数据变换中。输出信息输入信息目标系统外部实体外部实体输出信息外部实体外部实体输入信息图2.6 数据流图（DFD）功能建模的思想就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止。根据DeMarco的论述，功能模型使用了数据流图来表达系统内数据的运动情况，而数据流的变换则用结构化英语、判定表与判定树来描述。 数据流图图2.7是描述储户携带存折去银行办理取款手续的数据流图。从图中可以看到，数据流图的基本图形元素有四种，如图2.8所示。图2.7 办理取款手续的数据流图图2.8 DFD的基本图形符号在数据流图中，如果有两个以上数据流指向一个加工，或是从一个加工中引出两个以上的数据流，这些数据流之间往往存在一定的关系。为表达这些关系，在这些数据流的加工可以标上不同的标记符号。所用符号及其含意在图2.9中给出。图2.9 表明多个数据流与加工之间关系的符号 分层数据流图为了表达数据处理过程的数据加工情况，用一个数据流图是不够的。稍为复杂的实际问题，在数据流图上常常出现十几个甚至几十个加工。这样的数据流图看起来很不清楚。层次结构的数据流图能很好地解决这一问题。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统。图2.10给出分层数据流图的示例。数据处理S包括三个子系统1、2、3。顶层下面的第一层数据流图为DFDL1。第二层数据流图DFDL2.1、DFDL2.2及DFDL2.3分别是子系统1、2和3的细化。对任何一层数据流图来说，我们称它的上层图为父图，在它下一层的图则称为子图。图2.10 分层数据流图画数据流图的基本步骤概括地说，就是自外向内，自顶向下，逐层细化，完善求精。检查和修改的原则为： 数据流图上所有图形符号只限于前述四种基本图形元素。 顶层数据流图必须包括前述四种基本元素，缺一不可。 顶层数据流图上的数据流必须封闭在外部实体之间。 每个加工至少有一个输入数据流和一个输出数据流。 在数据流图中，需按层给加工框编号。编号表明该加工处在哪一层，以及上下层的父图与子图的对应关系。 规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。 可以在数据流图中加入物质流，帮助用户理解数据流图。 图上每个元素都必须有名字。数据流和数据文件的名字应当是“名词”或“名词性短语”，表明流动的数据是什么。加工的名字应当是“名词宾语”，表明做什么事情。 数据流图中不可夹带控制流。 初画时可以忽略琐碎的细节，以集中精力于主要数据流。 加工规格说明加工规格说明用来说明DFD中的数据加工的加工细节。加工规格说明描述了数据加工的输入，实现加工的算法以及产生的输出。另外，加工规格说明指明了加工（功能）的约束和限制，与加工相关的性能要求，以及影响加工的实现方式的设计约束。必须注意，写加工规格说明的主要目的是要表达“做什么”，而不是“怎样做”。因此它应描述数据加工实现加工的策略而不是实现加工的细节。目前用于写加工规格说明的工具有结构化英语、判定表和判定树。 针对实时系统的Ward & Mellor扩展这种扩展可以适应实时系统提出的以下要求： 在时间连续的基础上接收或产生数据流； 贯穿系统的控制信息和相关的控制处理； 在多任务的情况下可能会遇到同一个加工的多个实例； 系统状态以及导致系统状态迁移的机制。图2.11给出的扩展的图形符号可以让分析员在描述数据流和加工的同时，描述控制流和控制加工。这些符号可以与原来的数据流图的图形符号混用。控制项或事件。时间上间隔发生的数据流，取布尔值或离散值。连续数据流。时间上连续发生的数据流，用做加工的输入或输出。控制加工。由事件驱动的控制处理过程，接受控制和输入，产生控制作为输出。控制存储。为一个或多个控制提供事件源或事件存储服务的库。加工。同一个加工的多个对等的实例。在多任务系统中当产生多个加工时使用。它相当于一些进程。图2.11 Ward & Mellor开发的针对实时系统的扩展的结构化分析符号例如，图2.12给出一个基于计算机的水温控制系统的处理。水温测量仪连续传送水温数据给温度监控加工模块，该加工将水温与允许波动范围进行比较，输出校正数据给温度调节装置。水温测量仪温度温度校正值 温度监视与 调整温度设置范围图2.12 时间连续的数据流与普通数据流图2.13给出一个制造车间的数据和控制流的顶层流图。事件可以作为普通数据加工的输入数据流，控制也可以接收普通的输入数据流。动作警告每个部件的状态 部件状态缓冲器 机器人命令文件处理激活信号起动停止信号位串机器人动作记录机器人初始化 控制移位命令处理定位命令操作设置部件监控与操作界面操作命令图2.13 使用Ward & Mellor符号的数据流和控制流 Hatley和Pirbhai对结构化分析技术的扩展Ward & Pirbhai方法主要关注面向控制的规格说明，而不是扩充数据流图的图形符号。他们建立控制流图(CFD)以区别于数据流图(DFD)。在控制流图中的加工与数据流图中相同，但传递的是控制流而不是数据流。在控制流图中引入实短线“|”表示对控制规格说明的引用。图2.14给出他们建立的实时系统模型。用数据流图表示对数据和操作数据的加工；用控制流图表示事件在加工之间如何流动，说明导致各个加工激活的外部事件。加工模型输入数据流控制模型输出数据流数据流图控制流图加工激活者加工规格说明数据条件输入控制流输出控制流控制规格说明图2.14 数据与控制之间的关系(3) 行为建模行为建模给出需求分析方法的所有操作原则，但只有结构化分析方法的扩充版本才提供这种建模的符号。 状态迁移图利用如图2.15所示的状态迁移图(STD)或状态迁移表来描述系统或对象的状态，以及导致系统或对象的状态改变的事件，从而描述系统的行为。图2.15 状态迁移图与其等价的状态迁移表例每一个状态代表系统或对象的一种行为模式。状态迁移图指明系统的状态如何相应外部的信号（事件）进行推移。在状态迁移图中，用圆圈“”表示可得到的系统状态，用箭头“”表示从一种状态向另一种状态的迁移。在箭头上要写上导致迁移的信号或事件的名字。 如图2.15(a) 所示，系统中可取得的状态S1，S2，S3，事件t1，t2，t3，t4。事件t1将引起系统状态S1向状态S3迁移，事件t2将引起系统状态S3向状态S2迁移，等等。图2.15(b) 就是与图2.15(a) 等价的状态迁移表。另外，状态迁移图指明了作为特定事件的结果（状态）。在状态中包含可能执行的行为（活动或加工）。如果系统比较复杂，可以把状态迁移图分层表示。例如，在确定了如图2.16所示那样的大状态S1，S2，S3之后，接下来就可把状态S1，S2，S3细化。在该图中对状态S1进行了细化。此外，在状态迁移图中，由一个状态和一个事件所决定的下一状态可能会有多个。实际会迁移到哪一个是由更详细的内部状态和更详细的事件信息来决定的。此时，可采用状态迁移图的一种变形，如图2.17那样，使用加进判断框和处理框的记法。 图2.16 状态迁移图的网 图2.17 状态迁移图的变形 Petri网Petri网，简称PNG (Petri Net Graph)。它适用于描述相互独立、协同操作的处理系统，即并发执行的处理系统。在软件需求分析与设计阶段都可以使用。Petri网是一种有向图，它有两种结点：“”表示系统的状态。“”或“”表示系统中的事件。图中的有向边表示对事件的输入，或从事件输出：“”表示对事件的输入；“”表示事件的结果，即从事件的输出。图2.18用Petri网描述了在一个多任务系统中的两个进程PR1和PR2使用一个公共资源R时，利用原语LOCK（对资源加锁）和UNLOCK（对资源解锁）控制R的使用，保证进程间的同步的例子。图2.18 进程同步机制的PNG图中每个进程是一个数据对象，它有三个状态：等待资源（p1或p4），占用资源执行的处理（p2或p5），不占用资源执行的处理（p3或p6），另外系统有一个状态：资源空闲（p7）。在有的状态中有一个黑点“”，称为标记或令牌，表明系统或对象当前正处于此状态。当作为一个事件的输入的所有状态都得到或保有令牌时，才能引起该事件“激发”。使得系统和对象的状态向前推移，完成系统和对象的某些行为。 控制规格说明控制规格说明从两个方面给出系统的行为。其一是状态迁移图(STD)，它是行为的“顺序规格说明”。其二是加工激活表(PAT)，它是行为的“组合规格说明”，表明当事件激发时，数据流图中的哪些加工要被激活。控制规格说明仅描述了系统的行为，不提供被激活的加工的内部工作的细节。(4) 数据词典分析模型中包含了对数据对象、功能和控制的表示。在每一种表示中，数据对象和控制项都扮演一定的角色。为表示每个数据对象和控制项的特性，建立了数据词典。数据词典精确地、严格地定义了每一个与系统相关的数据元素，并以字典式顺序将它们组织起来，使得用户和分析员对所有的输入、输出、存储成分和中间计算有共同的理解。词条描述在数据词典的每一个词条中应包含以下信息： 名称：数据对象或控制项、数据存储或外部实体的名字。 别名或编号。 分类：数据对象？加工？数据流？数据文件？外部实体？控制项（事件状态）？ 描述：描述内容或数据结构等。 何处使用：使用该词条（数据或控制项）的加工。内容描述在数据词典的编制中，分析员最常用的描述内容或数据结构的符号如表2.1所示。 表2.1 数据词典定义式中的符号 符 号 含 义 解 释 .,. .|. . m.n (.) “.” . 被定义为 与 或 或 重复 重复 可选 基本数据元素 连结符 例如，x=ab，表示x由a和b组成。 例如，x=a, b，x=a|b，表示x由a或由b组成。例如，x=a，表示x由0个或多个a组成。例如，x=3a8，表示x中至少出现3次a, 至多 出现8次a。例如，x=(a)，表示a可在x中出现,也可不出现。例如，x=“a”，表示x为取值为a的数据元素。例如，x=1.9，表示x可取1到9之中的任一值。 图2.19 存折格式在图2.7表示的取款数据流图中，数据文件“存折”的格式如图2.19所示，它在数据词典中的定义格式为：存折户名所号帐号开户日性质（印密）1存取行50户名2字母24所号“001”.“999” 注：储蓄所编码，规定三位数字帐号“00000001”.“99999999” 注：帐号规定由八位数字组成开户日年月日性质“1”.“6” 注：“1”表示普通户，“5”表示工资户等印密“0” 注：印密在存折上不显示存取行日期（摘要）支出存入余额操作复核日期年月日字母“a”.“z”|“A”.“Z” 数据词典明确地定义了各种信息项。随着系统规模的增大，数据词典的规模和复杂性将迅速增加。6. 用于支持需求分析的快速原型化方法通常，原型是指模拟某种产品的原始模型。在软件开发中，原型是软件的一个早期可运行的版本，它反映最终系统的部分重要特性。如果在获得一组基本需求说明后，通过快速分析构造出一个小型的软件系统，满足用户的基本要求。使得用户可在试用原型系统的过程中得到亲身感受和受到启发，做出反应和评价。然后开发者根据用户的意见对原型加以改进。随着不断试验、纠错、使用、评价和修改，获得新的原型版本，如此周而复始，逐步减少分析和通信中的误解，弥补不足之处，进一步确定各种需求细节，适应需求的变更，从而提高了最终产品的质量。(1) 原型的分类由于运用原型的目的和方式不同，原型可分为以下两种不同的类型： 废弃型：先构造一个功能简单而且质量要求不高的模型系统，针对这个模型系统反复进行分析修改，形成比较好的设计思想，据此设计出更加完整、准确、一致、可靠的最终系统。系统构造完成后，原来的模型系统就被废弃不用。 追加型或演化型：先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，最后发展成为最终系统。有人把废弃型原型又细分为探索型和实验型。探索型原型的目的是要弄清对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。它主要针对开发目标模糊，用户和开发者对项目都缺乏经验的情况。而实验型原型用于大规模开发和实现之前，考核方案是否合适，规格说明是否可靠。(2) 原型类型的选择1984年Boar提出一系列选择原型化方法的因素。如果是在需求分析阶段要使用原型化方法，必须从系统结构、逻辑结构、用户特征、应用约束、项目管理和项目环境等多方面来考虑，以决定是否采用原型化方法。系统结构：联机事务处理系统，相互关联的应用系统适合于用原型化方法，而批处理、批修改等结构不适宜用原型化方法。逻辑结构：有结构的系统，如操作支持系统、管理信息系统、记录管理系统等适合于用原型化方法，而基于大量算法的系统不适宜用原型化方法。用户特征：不满足于预先做系统定义说明，愿意为定义和修改原型投资，不易肯定详细需求，愿意承担决策的责任，准备积极参与的用户是适合于使用原型的用户。应用约束：对已经运行系统的补充，不能用原型化方法。项目管理：只有项目负责人愿意使用原型化方法，才适合于用原型化的方法。项目环境：需求说明技术应当根据每个项目的实际环境来选择。当系统规模很大、要求复杂、系统服务不清晰时，在需求分析阶段先开发一个系统原型是很值得的。特别是当性能要求比较高时，在系统原型上先做一些试验也是很必要的。1992年Andriole给出6个问题，用来帮助选择原型方法。表2.2指明了对这些问题的典型答案和对使用原型方法的建议。表2.2 选择适当的原型方法 问 题废弃型原型法演化型原型法其它预备工作 目标系统要解决的问题弄清楚了吗？ 是 是 否 问题可以被建模吗？ 是 是 否 客户能够确定基本需求吗？ 是否 是否 否 需求已经被建立而且比较稳定了吗？ 否 是 是 有模糊不清的需求吗？ 是 否 是 需求中有矛盾吗？ 是 否 是(3) 原型生存期原型的开发和使用过程叫做原型生存期。图2.20（a）是原型生存期的模型，图2.20（b）是模型的细化。 图2.20 原型生存期 快速分析 ：在分析者和用户的紧密配合下，快速确定软件系统的基本要求。 构造原型 ：在快速分析基础上，根据基本需求，尽快实现一个可运行的系统。 运行和评价原型 ：用户在开发者指导下试用原型，在试用的过程中考核评价原型的特性，分析其运行结果是否满足规格说明的要求，以及规格说明描述是否满足用户愿望。 修正和改进 ：根据修改意见进行修改。如果用修改原型的过程代替快速分析，就形成了原型开发的迭代过程。开发者和用户在一次次的迭代过程中不断将原型完善，以接近系统的最终要求。 判定原型完成 ：经过修改或改进的原型，达到参与者一致认可，则原型开发的迭代过程可以结束。为此，应判断有关应用的实质是否已经掌握，迭代周期是否可以结束等。判定的结果有两个不同的转向，一是继续迭代验证，一是进行详细说明。 判断原型细部是否说明 ：判断组成原型的细部是否需要严格地加以说明。原型化方法允许对系统必要成分或不能通过模型进行说明的成分进行严格的详细的说明。 原型细部的说明 ：对于那些不能通过原型说明的所有项目，仍需通过文件加以说明。严格说明的成分要作为原型化方法的模型编入词典。 判定原型效果 ：考察用户新加入的需求信息和细部说明信息，看其对模型效果有什么影响? 是否会影响模块的有效性? 如果模型效果受到影响，甚至导致模型失效，则要进行修正和改进。 整理原型和提供文档。总之，利用原型化技术，可为软件的开发提供一种完整的、灵活的、近似动态的规格说明方法。(4) 原型开发技术通常用于构造原型的一些技术包括可执行规格说明、基于场景的设计、自动程序设计、专用语言、可复用的软件构件和简化假设等等。其中前三种还适用于用户界面的设计。 可执行规格说明 ：可执行规格说明是用于需求规格说明的一种自动化技术。可执行规格说明语言可描述系统要“做什么”，但它并不描述系统要“怎样做”。使用这种方法，人们可以直接观察他们用语言规定的任何系统性行为。可执行规格说明包括形式化规格说明、有限状态模型和可执行的数据流图。 基于场景的设计 ：一个场景可模拟在系统运行期间用户经历的事件。它提供了输入处理输出的屏幕格式和有关对话的模型。因此，场景能够给用户显示系统的逼真的视图，使用户得以判断是否符合他的意图。 自动程序设计 ：自动程序设计是可执行规格说明的替身，主要是指在程序自动生成环境的支持下，利用计算机实现软件的开发。它可以自动地或半自动地把用户的非过程性问题规格说明转换为某种高级语言程序，主要手段有以下4种： 专用语言 ：专用语言是应用领域的模型化语言。在原型开发中使用专用语言，可方便用户和软件开发者在计划中的系统特性方面的交流。 软件复用技术 ：软件复用技术可分为两大类：合成技术和生成技术。 合成技术：可复用的软件构件可以是对某一函数、过程、子程序、数据类型、算法等可复用软件成份的抽象，利用这些构件来构造软件系统。用构件合成较大的构件有三种方式：一是连接；二是消息传递和继承；三是管道(pipe)机制。 生成技术：利用可复用的模式，通过生成程序产生一个新的程序或程序段，产生的程序可以看做是模式的实例。可复用的模式有两种不同的形式：代码模式和规则模式。前者的例子是应用生成器，可复用的代码模式就存在于生成器自身。通过特定的参数替换，生成抽象软件模块的具体实体。后者的例子是变换系统，它通常采用超高级的规格说明语言，形式化地给出软件的需求规格说明，利用程序变换系统（有时要经过一系列的变换），把用超高级规格说明语言编写的程序转化成某种可执行语言的程序。 简化假设 ：简化假设是在开发过程中使设计者迅速得到一个简化的系统所做的假设。尽管这些假设可能实际上并不能成立，但它们在原型开发过程中可以使开发者的注意力集中在一些主要的方面。7. 软件需求规格说明和需求评审(1) 制定软件需求规格说明的原则1979年由Balzer和Goldman提出了做出良好规格说明的8条原则。原则1：功能与实现分离，即描述要“做什么”而不是“怎样实现”原则2：要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规格说明。原则3：如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。描述该目标软件与系统的其它系统元素交互的方式。原则4：规格说明必须包括系统运行的环境。原则5：系统规格说明必须是一个认识的模型，而不是设计或实现的模型。原则6：规格说明必须是可操作的。规格说明必须是充分完全和形式的，以便能够利用它决定对于任意给定的测试用例，已提出的实现方案是否都能满足规格说明。原则7：规格说明必须容许不完备性并允许扩充。原则8：规格说明必须局部化和松散的耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，规格说明应被松散地构造（即耦合），以便能够很容易地加入和删去一些段落。尽管Balzer和Goldman提出的这8条原则主要用于基于形式化规格说明语言之上的需求定义的完备性，但这些原则对于其它各种形式的规格说明都适用。当然要结合实际来应用上述的原则。(2) 软件需求规格说明软件需求规格说明是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。表2.3给出简化的大纲作为软件需求规格说明的框架。表2.3 软件需求规格说明的框架. 引言 A.系统参考文献 B.整体描述 C.软件项目约束. 信息描述 A.信息内容表示 B.信息流表示 数据流 控制流 . 功能描述 A.功能划分 B.功能描述 处理说明 限制局限 性能需求 设计约束 支撑图 C.控制描述 控制规格说明 设计约束. 行为描述 A.系统状态 B.事件和响应. 检验标准 A.性能范围 B.测试种类 C.期望的软件响应 D.特殊的考虑. 参考书目. 附录(3) 需求规格说明评审作为需求分析阶段工作的复查手段，在需求分析的最后一步，应该对功能的正确性、完整性和清晰性，以及其它需求给予评价。评审的主要内容是：系统定义的目标是否与用户的要求一致；系统需求分析阶段提供的文档资料是否齐全；文档中的所有描述是否完整、清晰、准确反映用户要求；与所有其它系统成分的重要接口是否都已经描述；被开发项目的数据流与数据结构是否足够，确定；所有图表是否清楚，在不补充说明时能否理解；主要功能是否已包括在规定的软件范围之内，是否都已充分说明；软件的行为和它必须处理的信息、必须完成的功能是否一致；设计的约束条件或限制条件是否符合实际；是否考虑了开发的技术风险；是否考虑过软件需求的其它方案；是否考虑过将来可能会提出的软件需求；是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；有没有遗漏，重复或不一致的地方；用户是否审查了初步的用户手册或原型；软件开发计划中的估算是否受到了影响。为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。评审结束应有评审负责人的结论意见及签字。除分析员之外，用户需求者，开发部门的管理者，软件设计、实现、测试的人员都应当参加评审工作。一般，评审的结果都包括了一些修改意见，待修改完成后再经评审通过，才可进入设计阶段。三、例题分析【例1】软件需求分析阶段的工作，可以分为以下4个方面：对问题的识别、分析与综合、编写需求分析文档以及( )。供选择的答案：A. 总结 B. 阶段性报告 C. 需求分析评审D. 以上答案都不正确答案： C.分析：作为需求分析阶段工作的复查手段，在需求分析的最后一步，应该对功能的正确性、完整性和清晰性，以及其它需求给予评价。一般，评审的结果都包括了一些修改意见，待修改完成后再经评审通过，才可进入设计阶段。【例2】各种需求方法都有它们共同适用的( )。供选择的答案： A说明方法B描述方式C. 准则D基本原则答案： D.分析：虽然各种分析方法都有独特的描述方法，但所有的分析方法还是有它们共同适用的基本原则。这些基本原则包括： 需要能够表达和理解问题的信息域和功能域； 要能以层次化的方式对问题进行分解和不断细化； 要分别给出系统的逻辑视图和物理视图。【例3】在结构化分析方法中，用以表达系统内数据的运动情况的工具有( )。供选择的答案： A. 数据流图 B. 数据词典C. 结构化英语D. 判定表与判定树答案： A. 分析：数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程，所以，它不是描述数据的静态结构，而是描述数据流的传递和变换。数据词典主要用于定义数据和控制对象的细节，结构化英语、判定表和判定树主要用于描述加工规格说明，都不是表达数据在系统内运动情况的工具。【例4】在结构化分析方法中用状态迁移图表达系统或对象的行为。在状态迁移图中，由一个状态和一个事件所决定的下一状态可能会有( )个。供选择的答案： A. 1 B. 2 C. 多个D. 不确定答案： C. 分析：在状态迁移图中，由一个状态和一个事件所确定的下一状态可能会有多个。实际会迁移到哪一个状态，是由更详细的内部状态和更详细的事件信息来决定的，此时在状态迁移图中可能需要使用加进判断框和处理框的记法。状态迁移图的优点：第一，状态之间的关系能够直观地捕捉到，这样用眼睛就能看到是否所有可能的状态迁移都已纳入图中，是否存在不必要的状态等。第二，由于状态迁移图的单纯性，能够机械地分析许多情况，可很容易地建立分析工具。【例5】在结构化分析方法中用实体关系图表达系统中的对象及其关系。在实体关系图中，表达对象的实例之间的关联有三种类型：一对一联系、( )联系、多对多联系。供选择的答案： A. 多对一B. 一对多分析：使用实体关系图，可以建立系统中各个数据对象及对象之间的关系。对象的实例间的关联称为“基数”，共有3种类型的基数：一对一，一对多，多对多。它反映了现实世界中实体之间的联系，多对一的情况可以归入一对多的关联中去。【例6】 软件需求分析的任务不应包括( A )。进行需求分析可使用多种工具，但( B )是不适用的。在需求分析中，分析员要从用户那里解决的最重要的问题是( C )。需求规格说明书的内容不应当包括( D )。该文档在软件开发中具有重要的作用，但其作用不应当包括( E )。供选择的答案： A. 问题分析 信息域分析 结构化程序设计 确定逻辑模型 B. 数据流图 判定表 PAD图 数据词典 C. 要让软件做什么 要给该软件提供哪些信息 要求软件工作效率如何 要让软件具有什么样的结构 D. 对重要功能的描述 对算法的详细过程性描述 软件确认准则 软件的性能 E. 软件设计的依据 用户和开发人员对软件要“做什么”的共同理解 软件验收的依据 软件可行性分析的依据答案：A. , B. , C. , D. , E. 分析：软件需求分析的任务是通过与用户的合作，了解用户对待开发系统的要求；根据对用户要求的系统所在的信息域的调查、分析，确定系统的逻辑模型；并对求解的问题做适当的分解，使之适合于计算机求解。需求分析的结果是软件需求规格说明书。结构化程序设计是在详细设计和编码阶段所采用的技术，而不是需求分析阶段要采用的技术。在需求分析阶段，分析人员可以用数据流图描述系统的数据流的变换和流向，用数据词典定义在数据流图中出现的数据流、数据文件、加工或处理，用判定表表示复杂条件和动作组合的情况。但PAD图是在详细设计阶段使用的描述加工逻辑的工具，不适用于需求分析。此外，软件需求分析阶段只确定软件系统要“做什么”，完成对重要功能、性能、确认准则的描述，至于“怎么做”由后续的设计阶段完成，对算法的详细过程性描述也是在设计阶段给出。软件可行性分析应在需求分析之前，所以需求分析规格说明不能成为可行性分析的依据。【例7】原型化方法是用户和软件开发人员之间进行的一种交互过程，适用于( A )系统。它从用户界面的开发入手，首先形成( B )，用户( C )，并就( D )提出意见，它是一种( E )型的设计过程。供选择的答案： A. 需求不确定性高的 需求确定的 管理信息 决策支持 B. 用户界面使用手册 用户界面需求分析说明书 系统界面原型 完善的用户界面 C. 改进用户界面的设计 阅读文档资料 模拟用户界面的运行 运行用户界面原型 D. 同意什么和不同意什么 使用和不使用哪一种编程语言 程序的结构 执行速度是否满足要求 E. 自外向内 自顶向下 自内向外 自底向上答案：A. B. C. D. E. 分析：通常，原型是指模拟某种产品的原始模型。在软件开发中，原型是软件的一个早期可运行的版本，它反映最终系统的部分重要特性。使用原型的原型化方法特别适用于需求不确定性较高的软件系统的开发。它的基本思想是根据用户给出的基本需求，通过快速实现构造出一个小型的可执行的模型，满足用户的基本要求，这就是系统界面原型。让用户计算机上实际运行这个用户界面原型，在试用的过程中得到亲身感受和受到启发，做出反应和评价，提出同意什么和不同意什么。然后开发者根据用户的意见对原型加以改进。随着不断试验、纠错、使用、评价和修改，获得新的原型版本，如此周而复始，逐步减少分析和通信中的误解，弥补不足之处，进一步确定各种需求细节，适应需求的变更，从而提高了最终产品的质量。它是一种自外向内型的设计过程。四、习题【2-1】在软件需求分析时，首先建立当前系统的物理模型，再根据物理模型建立当前系统的逻辑模型。试问：什么是当前系统？当前系统的物理模型与逻辑模型有什么差别？【2-2】软件需求分析是软件工程过程中交换意见最频繁的步骤。为什么交换意见的途径会经常阻塞？【2-3】你认为一个系统分析员的理想训练和基础知识是什么？请说明理由。【2-4】可行性研究主要研究哪些问题？试说明之。【2-5】信息和信息结构有什么区别？有没有不存在信息流的系统？有没有不存在信息结构的系统？【2-6】软件需求分析的操作性原则和需求工程的