第二章 软件需求分析 一、复习要求 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用于行为建模。 数据建模 数据模型包括三种互相关联的信息：数据对象，描述对象的属性，描述对象间相互连接的关系。 ( 数据对象 ：是需被目标系统所理解的复合信息的表示。所谓复合信息是具有若干不同特征或属性的信息。 数据对象可以是外部实体（如显示器），事物（如报表或显示），角色（如教师或学生），行为（如一个电话呼叫）或事件（如单击鼠标左键），组织单位（如研究生院），地点（如注册室）或结构（如文件）。 数据对象只封装了数据，没有包含作用于这些数据上的操作。这与面向对象范型中的类和对象不同。具有相同特征的数据对象组成的集合仍然称为数据对象，其中的某一个对象叫做该数据对象的一个实例。 ( 属性 ：定义了数据对象的特征。它可用来：① 为数据对象的实例命名；② 描述这个实例；③ 建立对另一个数据对象的另一个实例的引用。如学生数据对象的属性可以有学号、姓名、性别、出生年月、籍贯等。为了唯一地标识数据对象的某一个实例，定义数据对象中的一个属性或几个属性为关键码(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。顶层下面的第一层数据流图为DFD／L1。第二层数据流图DFD／L2.1、DFD／L2.2及DFD／L2.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=a＋b，表示x由a和b组成。 例如，x=[a, b]，x=[a|b]，表示x由a或由b组成。 例如，x={a}，表示x由0个或多个a组成。 例如，x=3{a}8，表示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】软件需求分析的操作性原则和需求工程的指导性原则是什么？ 【2-7】数据流图的作用是什么？它有哪些基本成份？ 【2-8】考务处理系统的分层数据流图如下图所示。 该考务处理系统有如下功能： 对考生送来的报名表进行检查； ② 对合格的报名表编好准考证号码后将准考证送给考生，并将汇总后的考生名单送给阅卷站； ③ 对阅卷站送来的成绩表进行检查，并根据考试中心指定的合格标准审定合格者； ④ 填写考生通知单（内容包含考试成绩及合格∕不合格标志），送给考生； ⑤ 按地区、年龄、文化程度、职业、考试级别等进行成绩分类统计及试题难度分析，产生统计分析表。 (1) 图(c)中，加工1.1的输入数据流是( A )，输出数据流是( B )，图(b)中，加工2的输出数据流是( C )，它是由( D )和( E )组成。 供选择的答案： A ( E. ① 统计分析表 ② 报名表 ③ 准考证 ④ 考生通知单 ⑤ 合格报名表 ⑥ 难度分析表 ⑦ 错误成绩表 ⑧ 分类统计表 (2) 图(d)中的文件“试题得分表”是否在图(b)中漏掉了？ 回答是( F )。 供选择的答案： F. ① “试题得分表”没有在图(b)中画出，是错误的。 ② “试题得分表”是图(b)中加工的内部文件，不必在图(b)中画出。 ③ “试题得分表”是多余的。 【2-9】Petri网可以描述计算机软件系统的执行。现有一个程序如下（类似于Pascal语言） L : S1; WHILE P1 DO BEGIN IF P2 THEN S2 ELSE S3; COBEGIN S4; S5; S6; COEND END; GOTO L; 其中，P1和P2为逻辑表达式，S1(S6是单个执行语句，COBEGIN和COEND是并行执行开始和并行执行结束（即S4，S5和S6语句并行执行）。试用Petri网描述这段程序的执行过程。 【2-10】数据词典的作用是什么？它有哪些基本词条？ 【2-11】传统的软件开发模型的缺陷是什么？原型化方法的类型有哪些？原型开发模型的主要优点是什么？ 【2-12】试简述原型开发的过程和运用原型化方法的软件开发过程。 【2-13】软件需求分析说明书主要包括哪些内容? 【2-14】阅读下列关于开发人事管理系统的交互式工作方式的叙述，再回答问题。 某大企业最近决定采用高性能微机开发人事管理系统，将四台联机终端分置于人事处的三个科室。该系统可供操作员和程序员使用，也可供人事处负责人和主管人事的副厂长等查询人事信息用。人事管理系统通过录入人事数据和修改、删除等操作，产生和更新各类人事文件，通过搜索这些文件进行各类人事信息的查询。 该企业有3000多个工人、干部和技术人员，大体可分成机关科室、生产车间、后勤服务和开发研制部门等几类部门。厂领导决定由计算机应用科来负责协调和开发应用系统。计算机应用科科长指示系统工程师张某负责进行系统分析。 考虑到人事处有大量的查询信息要求、频繁的人事信息修改和文件存档、查阅等特点，计算机应用科决定认真设计人机交互界面，首先设计好在终端上的交互式会话的方式。 系统工程师张某通过调查收集到如下10条意见： 某程序员认为：系统在屏幕格式、编码等方面应具有一致性和清晰性，否则会影响操作人员的工作效率。 某操作人员认为：在交互式会话过程中，操作人员可能会忘记或记错某些事情，系统应当提供HELP功能。 某操作人员认为：既然是交互式会话，那么对所有的输入都应当作出响应，不应出现击键后，计算机没有任何反应的情况。 某操作人员认为：在出错的时候，交互式会话系统应当给出出错信息，并且尽可能告诉我们出错的性质和错在什么地方。 某程序员认为：终端会话也应当符合程序员编制程序时的习惯，这样可以更高效地维护人事管理系统。 教育科干部甲认为：应当对操作员进行一些必要的培训，让他们掌握交互式会话系统的设计技巧，有助于提高系统的使用效率。 教育科干部乙认为：尽管操作人员的指法已经强化训练但在交互式会话时应尽可能缩短和减少操作员输入的信息，以降低出错概率。 某程序员认为：由于本企业中有很多较大的文件，文件的查找很费时间，交互式会话系统在响应时间较长时应给予使用者以提示信息。 人事处干部丙认为：我们企业的人事资料相当复杂，格式非常之多，希望交互式系统使用十分清晰的格式，并容易对输入数据中的错误进行修改。 人事处干部丁认为：人事管理系统应当具有相当的保密性和数据安全性，因此在屏幕上显示出的信息应该含混一些，以免泄密。 系统工程师张某对上述调查情况和其他要求作了分析后，发现收集到的10条意见中有3条意见是不能接受的，写出编号并各用40字以内叙述理由。 五、习题解答 【2-1】所谓当前系统可能是需要改进的某个已在计算机上运行的数据处理系统，也可能是一个人工的数据处理过程。当前系统的物理模型客观地反映当前系统实际的工作情况。但在物理模型中有许多物理的因素，随着分析工作的深入，有些非本质的物理因素就成为不必要的负担，因而需要对物理模型进行分析，区分出本质的和非本质的因素，去掉那些非本质的因素即可获得反映系统本质的逻辑模型。所以当前系统的逻辑模型是从当前系统的物理模型抽象出来的。 【2-2】软件需求分析过程中，由于最初分析员对要解决的问题了解很少，用户对问题的描述、对目标软件的要求也很凌乱、模糊，再加上分析员和用户共同的知识领域不多，导致相互间通信的需求。首先，由于分析员和用户之间需要通信的内容相当多，业务知识上的不足，表达方式的不足，可能对某些需求存在错误解释或误解的可能性，造成需求的模糊性。其次，用户和分析员之间经常存在无意识的“我们和他们”的界限，不是按工作需要组成统一的精干的队伍，而是各自定义自己的“版图”，并通过一系列备忘录、正式的意见书、文档，以及提问和回答来相互通信。历史已经证明，这样会产生大量误解。忽略重要信息，无法建立成功的工作关系。 【2-3】系统分析员处在用户和高级程序员之间，负责沟通用户和开发人员的认识和见解，起着桥梁的作用。一方面要协助用户对所开发的软件阐明要求，另一方面还要与高级程序员交换意见，探讨用户所提要求的合理性以及实现的可能性。最后还要负责编写软件需求规格说明和初步的用户手册。  为能胜任上述任务，分析员应当具备如下的素质: (1) 能够熟练地掌握计算机硬、软件的专业知识，具有一定的系统开发经验。 (2) 善于进行抽象的思维和创造性的思维，善于把握抽象的概念，并把它们重新整理成为各种逻辑成分，并给出简明、清晰的描述。 (3) 善于从相互冲突或混淆的原始资料中抽出恰当的条目来。 (4) 善于进行调查研究，能够很快学习用户的专业领域知识，理解用户的环境条件。 (5) 能够倾听他人的意见，注意发挥其它人员的作用。 (6) 具有良好的书面和口头交流表达能力。 【2-4】可行性研究主要做4个方面的研究： ( 经济可行性 ：进行成本∕效益分析。从经济角度判断系统开发是否“合算”。 ( 技术可行性 ：进行技术风险评价。从开发者的技术实力、以往工作基础、问题的复杂性等出发，判断系统开发在时间、费用等限制条件下成功的可能性。 ( 法律可行性 ：确定系统开发可能导致的任何侵权、妨碍和责任。 ( 方案的选择 ：评价系统或产品开发的几个可能的候选方案。最后给出结论意见。 【2-5】什么是信息？广义地讲，信息就是消息。宇宙三要素（物质、能量、信息）之一。它是现实世界各种事物在人们头脑中的反映。此外，人们通过科学仪器能够认识到的也是信息。信息的特征为：可识别、可存储、可变换、可处理、可传递、可再生、可压缩、可利用、可共享。我们通常讲的信息域就是对信息的多视角考虑。信息域包含3个不同的视图：信息内容和关系、信息流和信息结构。为了完全理解信息域，必须了解每一个视图。 信息结构：它是信息在计算机中的组织形式。一般表示了各种数据和控制对象的内部组织。数据和控制对象是被组织成n维表格，还是组织成有层次的树型结构? 在结构中信息与其它哪些信息相关? 所有信息是在一个信息结构中，还是在几个信息结构中? 一个结构中的信息与其它结构中的信息如何联系? 这些问题都由信息结构的分析来解决。 信息流：表示数据和控制在系统中传递时的变化方式。输入对象首先被变换成中间信息（数据或控制），然后再变换成输出结果信息。沿着变换路径，可能从已有的数据存储（如磁盘文件或内存缓冲区）中引入附加的信息。对数据进行变换是程序中应有的功能或子功能。两个变换功能之间的数据传递就确定了功能间的接口。 所以，没有信息流的系统相当于没有功能的系统，这样的系统的存在是毫无意义的。而没有信息结构的系统是没有信息的系统，这样的系统不是计算机能够处理的系统。 【2-6】所有的需求分析方法都与一组操作性原则相关联： ( 必须理解和表示问题的信息域。 ( 必须定义软件将完成的功能。 ( 必须表示软件的行为（作为外部事件的结果）。 ( 必须对描述信息、功能和行为的模型进行分解，能够以层次方式揭示其细节。 ( 分析过程应当从要素信息转向细节的实现。 通过使用这些原则，分析员可以系统地处理问题。首先检查信息域以便更完整地理解目标软件的功能，再使用模型以简洁的方式表达目标软件的功能和行为，并利用自顶向下、逐层分解的手段来降低问题的复杂性。在这些处理过程中，因处理需求带来的逻辑约束和因其它系统元素带来的物理约束需要通过软件要素和视图的实现加以检验和确认。 除此以外，Davis建议了一组针对“需求工程”的指导性原则： ( 在开始建立分析模型之前应当先理解问题。如果问题没有很好理解就急于求成，常常会产生一个解决错误问题的完美的软件。 ( 强力推荐使用原型。这样做可以使用户了解将如何与计算机交互，而人们对软件质量的认识常常是基于对界面“友好性”的切身体会。 ( 记录每一个需求的起源和原因。这是建立对用户要求的可追溯性的第一步。 ( 使用多个视图，建立系统的数据、功能和行为模型。这样做可帮助分析员从多方面分析和理解问题，减少遗漏，识别可能的不一致之处。 ( 给需求赋予优先级。因为过短的时限会减少实现所有软件需求的可能性。因此，对需求排定一个优先次序，标识哪些需求先实现，哪些需求后实现。 ( 注意消除歧义性。因为大多数需求都是以自然语言描述，存在叙述的歧义性问题，造成遗漏和误解。采用正式的技术评审是发现和消除歧义性的好方法。 遵循以上原则，就可能开发出较好的软件需求规格说明，为软件设计奠定基础。 【2-7】数据流图可以用来抽象地表示系统或软件。它从信息传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程，同时可以按自顶向下、逐步分解的方法表示内容不断增加的数据流和功能细节。因此，数据流图既提供了功能建模的机制，也提供了信息流建模的机制，从而可以建立起系统或软件的功能模型。 数据流图的基本成份有4种：  【2-8】答案：A. ② B. ⑤ C. ① D. ⑥ E. ⑧ F. ② 其中，D与E的答案可互换。 应注意的问题： ① 适当地为数据流、加工、文件、数据的源∕汇点命名。名字应反映该元素的实际含义，避免空洞的名字。如数据、信息处理、计算等名字都不好。 ② 画数据流时不要夹带控制流。数据流图中各种数据的加工没有考虑时序关系，引入控制流后，加工之间就有了时序关系，这与画数据流图不考虑实现细节的初衷相违背。 ③ 一个加工的输出数据流不要与该加工的输入数据流重名，即使它们的组成成分相同。例如图(c)中加工1.1的输入数据流“报名表”与输出数据流“合格报名表”。 ④ 允许一个加工有多个数据流流向另一个加工，也允许一个加工有两个相同的输出数据流流向两个不同的加工。 ⑤ 保持父图与子图的平衡。就是说，父图与它的子图的输入数据流与输出数据流应当在数量与名字上都相同。特别的是，如果父图的一个输入（或输出）数据流对应于子图中几个输入（或输出）数据流，但子图中这几个数据流中的数据项合起来正好是父图中的那个数据流，这时它们还算是平衡的。例如，图(b)中加工2的输出数据流“统计分析表”是由“难度分析表”和“分类统计表”组成，那么图(b)与图(d)仍满足父图与子图平衡的条件。 ⑥ 在自顶向下的分解过程中，若一个文件首次出现时只与一个加工有关，那么这个文件应作为这个加工的内部文件而不必画出。例如，图(d)中的文件“试题得分表”就是图(b)中加工的内部文件，所以在图(b)中没有画出。 ⑦ 保持数据守恒。就是说，一个加工的所有输出数据流中的数据必须能从该加工的输入数据流中直接获得，或者是通过该加工产生的数据。 【2-9】采用条件∕事件网（C∕E网，C―Condition, E―Event）式Petri网。其定义如下： 当事件e激发时条件c开始成立，则称c是e的后继。此关系用“”表示； 当事件e激发时条件c消失成立，则称c是e的前驱。此关系用“”表示； 当事件e激发时条件c不受影响，则c和e之间没有前驱、后继关系，无边。 根据定义，给定程序的C∕E网如下： 【2-10】分析模型中包含了对数据对象、功能和控制的表示。在每一种表示中，数据对象和控制项都扮演一定的角色。为表示每个数据对象和控制项的特性，建立了数据词典。数据词典精确地、严格地定义了每一个与系统相关的数据元素，并以字典式顺序将它们组织起来，使得用户和分析员对所有的输入、输出、存储成分和中间计算有共同的理解。 在数据词典的每一个词条中应包含以下信息： ① 名称：数据对象或控制项、数据存储或外部实体的名字。 ② 别名或编号。 ③ 分类：数据对象？加工？数据流？数据文件？外部实体？控制项（事件∕状态）？ ④ 描述：描述内容或数据结构等。 ⑤ 何处使用：使用该词条（数据或控制项）的加工。 【2-11】传统软件生存期范型的典型代表是“瀑布模型”。这种模型的核心是将软件生存期划分为软件计划、需求分析、软件设计、编码、测试和运行维护等阶段，根据不同阶段工作的特点，运用不同的方法、技术和工具来完成该阶段的任务。软件开发人员遵循严格的规范，在每一阶段工作结束时都要进行严格的阶段评审和确认，以得到该阶段的一致、完整、正确和无歧义性的文档资料，并以它们做为下一阶段工作的基础。 传统思想强调每一阶段的严格性，尤其是开发初期要有良好的软件规格说明，主要是源于过去软件开发的经验教训，即在开发的后期或运行维护期间来修改不完善的规格说明要付出巨大的代价。但是，要想得到一个完整准确的规格说明不是一件容易的事。特别是对于一些大型的软件项目，在开发的早期用户往往对系统只有一个模糊的想法，很难完全准确地表达对系统的全面要求，软件开发人员对于所要解决的应用问题认识更是模糊不清。经过详细的讨论和分析，也许能得到一份较好的规格说明，但却很难期望该规格说明能将系统的各个方面都描述得完整、准确、一致，并与实际环境相符。很难通过它在逻辑上推断出（不是在实际运行中判断评价）系统运行的效果，以此达到各方对系统的共同理解。随着开发工作向前推进，用户可能会产生新的要求，或因环境变化，要求系统也能随之变化；开发人员又可能在设计与实现的过程中遇到一些没有预料到的实际困难，需要以改变需求来解脱困境。因此规格说明难以完善、需求的变更、以及通信中的模糊和误解，都会成为软件开发顺利推进的障碍。尽管在传统软件生存期管理中通过加强评审和确认，全面测试，甚至依靠维护阶段能够缓解上述问题，但不能从根本上解决这些问题。 为了解决这些问题，逐渐形成了软件系统的快速原型的概念。由于运用原型的目的和方式不同，原型可分为以下两种不同的类型： ① 废弃型：先构造一个功能简单而且质量要求不高的模型系统，针对这个模型系统反复进行分析修改，形成比较好的设计思想，据此设计出更加完整、准确、一致、可靠的最终系统。系统构造完成后，原来的模型系统就被废弃不用。 ② 追加型或演化型：先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，最后发展成为最终系统。 建立快速原型进行系统的分析和构造，有以下的优点： ① 增进软件者和用户对系统服务需求的理解，使比较含糊的具有不确定性的软件需求（主要是功能）明确化。由于这种方法能在早期就明确了用户的要求，因此可防止以后由于不能满足用户要求而造成的返工，从而避免了不必要的经济损失，缩短了开发周期。 ② 软件原型化方法提供了一种有力的学习手段。通过原型演示，用户可以亲身体验早期的开发过程，获得关于计算机和被开发系统的专门知识。软件开发人员也可以获得用户对系统的确切要求，学习到应用范围的专业知识。 ③ 使用原型化方法，可以容易地确定系统的性能，确认各项主要系统服务的可应用性，确认系统设计的可行性，确认系统作为产品的结果。因而它可以作为理解和确认软件需求规格说明的工具。 ④ 软件原型的最终版本，有的可以原封不动地成为产品，有的略加修改就可以成为最终系统的一个组成部分，这样有利于建成最终系统。 【2-12】原型的开发和使用过程叫做原型生存期。下图是原型生存期的模型及其细化。 ① 快速分析 ：在分析者和用户的紧密配合下，快速确定软件系统的基本要求。 ② 构造原型 ：根据基本规格说明，尽快实现一个可运行的原型系统。 ③ 运行和评价原型 ：用户试用原型，考核评价原型的特性。纠正过去交互中的误解和分析中的错误，增补新的要求，提出全面的修改意见。 ④ 修正和改进 ：根据修改意见进行修改。如果用修改原型的过程代替快速分析，就形成了原型开发的迭代过程。在一次次的迭代过程中不断将原型完善，以接近系统的最终要求。 ⑤ 判定原型完成 ：经过修改或改进的原型，达到参与者一致认可，则原型开发的迭代过程可以结束。为此，应判断有关应用的实质是否已经掌握，判定的结果有两个不同的转向，一是继续迭代验证，一是进行详细说明。 ⑥ 判断原型细部是否说明 ：判断组成原型的细部是否需要严格地加以说明。 ⑦ 原型细部的说明 ：通过文件加以说明那些不能通过原型说明的项目。 ⑧ 判定原型效果 ：考察新加入的需求信息和细部说明信息，看其对模型有什么影响? 是否会影响模块的有效性? 如果模型受到影响，则要进行修正和改进。 ⑨ 整理原型和提供文档 快速原型方法的提出使得传统的软件生存期在思想方法上受到了影响。如果只是在局部运用原型化方法，若将原型开发过程用于软件生存期的某一个阶段内，那么传统的软件生存期依然不变，只是阶段内部的软件定义或开发活动采用了新的方法。但若原型开发过程代替了传统生存期中的多个阶段，则软件开发过程就成为一种新的形式。    图(a)表示了使用原型方法的软件生存期模型。原型开发过程处于核心，表示可在生存期的任何阶段中引入原型开发过程，也可合并若干阶段，用原型开发过程代替。图(b)详细描述了在各个阶段可能引入原型开发过程的软件开发过程。其中在原型开发过程的最后加上了一个“是否构造新原型”的判断，这是针对在系统开发的过程中有可能为不同的目的而要使用多个原型的情况而设。 ① 辅助或代替分析阶段 ：在分析阶段利用快速原型方法可以得到良好的需求规格说明。在整体上仍然采用传统的模式，但使用原型化方法来补充和完善需求说明以达到一致、准确、完整、无多义性地反映用户要求，从而代替了传统的仅由复审和确认来提高需求规格说明质量的方法。并能在早期克服潜在的误解、遗漏和错误，尽量不让潜在的问题遗留到开发的后期，减少将来维护的代价。 ② 辅助设计阶段 ：在设计阶段引入原型，可根据需求分析得到的规格说明进行快速分析，得到实现方案后立即构造原型，通过运行，考察设计方案的可行性与合理性。在这个阶段引入原型，可以迅速得到完善的设计规格说明。原型可能成为设计的总体框架，也可能成为最终设计的一部分或补充的设计文档。 ③ 代替分析与设计阶段 ：这时不再遵循传统的严格按阶段进行软件开发的要求，而是把原型方法直接应用到软件开发的整体过程。在实施原型开发的过程中，不再考虑完善的需求说明，把分析、定义和设计交织在一起，通过原型的构造、评价与改进的迭代过程，逐步向最终系统的全面要求靠近。由于在分析的同时也考虑了设计与实现的要求，能更有效地确定系统的需求和设计规格说明。 ④ 代替分析、设计和实现阶段 ：在软件开发环境的支持下，通过原型生存期的反复迭代，直接得到软件的程序，交付系统测试。这属于进化型的原型开发，由初始的基本需求得到最初的原型开始，一直进化到软件的整体系统，并满足用户的一切可能的要求。 ⑤ 代替全部定义与开发阶段 ：这是典型的进化型原型开发方法。完全摆脱了传统的软件生存期模式，通过反复的原型迭代过程，直接得到最终的软件产品。系统测试作为原型评价工作的一部分，融入原型的开发过程。 【2-13】软件需求规格说明是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。 软件需求规格说明的框架如下： Ⅰ. 引言 A.系统参考文献 B.整体描述 C.软件项目约束  Ⅱ. 信息描述 A.信息内容表示 B.信息流表示 ⅰ数据流 ⅱ控制流  Ⅲ. 功能描述 A.功能划分 B.功能描述 ⅰ处理说明 ⅱ限制∕局限 ⅲ 性能需求 ⅳ 设计约束 ⅴ 支撑图 C.控制描述 ⅰ控制规格说明 ⅱ 设计约束  Ⅳ. 行为描述 A.系统状态 B.事件和响应  Ⅴ. 检验标准 A.性能范围 B.测试种类 C.期望的软件响应 D.特殊的考虑  Ⅵ. 参考书目  Ⅶ. 附录  【2-14】不能接受的3条意见是 (5)、(6)、(10)。人机交互界面首先考虑的是用户如何使用起来方便，与编程习惯、设计技巧无关。此外，屏幕上信息应很清晰易懂，安全保密与屏幕显示无关。