偏差的地方。
24、简述 ERD的创建步骤。 答：
在获得充分描述信息的情况下，ERD的创建工作可以按照下列步骤进行：
①从描述信息中辨识实体。从描述信息中寻找系统需要收集和存储的信息，然后将其 建模为实体。寻找时，可以重点关注描述信息中的名词，并以系统是否需要收集其相关的特 征为依据来判定是否将其建立为独立的实体元素。
②确定实体的标识符。为每个实体选择能够唯一标识实例且比较稳定的属性为标识符。 ③建立实体之间的关系。从描述信息中辨识实体之间存在的业务联系，描述为独立的 关系元素。并判断各个关系的建立是否会产生新的关联实体或者影响已有的实体特性。
④添加详细的描述信息。在得到一个初步的框架之后，进一步从描述中挖掘信息，为 数据模型添加详细的描述信息，包括实体的详细属性和关系的基数。
25、请说明为什么要编写需求规格说明文档？ 答：（划线部分为必答要点）
（1）编写需求规格说明文档的必要性：
在一个复杂软件系统的开发中，编写需求规格说明文档是非常必要的。
一方面，清晰、明确、结构化的文档可以将软件系统的需求信息和解决方案更好的传 递给所有的开发者。
另一方面，文档可以拓展人们的知识记忆能力。
（2）编写需求规格说明文档的他好处：
①需求规格说明文档可以成为各方人员之间有关软件系统的协议基准。开发者和客户 可以使用它作为合同协议的重要部分，涉众也可以利用它在相互间达成一致。
②需求规格说明文档可以成为项目开发活动的一个重要依据。它可以作为软件估算和 项目进度安排的基础，也可以作为开发人员判断设计、测试等工作的进行是否正确的依据。
③在需求规格说明文档的编写过程中，可以尽早的发现和减少可能的需求错误，从而减 少项目的返工，降低项目的工作量。
④需求规格说明文档可以成为有效的智力资产。这个智力资产可以帮助新加入的团队 成员更快的融入项目，可以帮助更好地将软件产品移交给新客户，也可以帮助开发者更好地 进行其他类似项目或者后续增强项目的开发。
26、试比较编写需求规格说明文档所使用的三种语言。 答：（划线部分为必答要点）
需求工程师在描述需求规格说明文档时使用的语言分为三类： ①非形式化语言，即自然语言。
②半形式化语言，比自然语言具有更丰富的语义和更严格的语法同时又没有严格到完 全基于数学方法的语言，例如ERD、DFD、UML等图形语言。
③形式化语言，基于数学的语言，例如VDM、Z语言等。 自然语言具有复杂的规则和多样化的表达方式，所以它的表达能力最为强大。而且自 然语言属于普通人的语言，每个人都熟知其规则、表达方式和特点，所以非常利于用户的理 解。但同时自然语言也具有松散、模糊、歧义、凌乱等不好的特性。这使得它无法被机器所 理解，它所描述的信息内容也无法准确地映射为机器行为。
形式化语言是基于数学方法的语言，具有数学的表示法特性。使用形式化语言描述的
24
信息内容是可以进行逻辑一致性推导和证明的，所以它能够保证信息的正确性。而且形式化 的信息描述能够被机器所理解，它所描述的信息内容可以准确地映射为机器行为。但是形式 化描述的信息要求读者具备谓词演算方面的知识，这对普通的用户而言显然要求过高，以至 于大多数用户无法读懂以形式化方法描述的信息。形式化方法所能描述的内容也是有限的， 具体的有限性因形式化方法的不同而各异。
半形式化语言是介于自然语言和形式化语言之间的描述语言。一方面，半形式化语言 具有严格的语法，定义方式比自然语言更加严格，这使得它可以避免自然语言模糊、松散、 歧义、凌乱等不好的特性。另一方面，半形式化语言具有丰富的语义，使用规则比形式化语 言更复杂和多样，这使得它具有比形式化方法更强的表达能力。但是，丰富的语义使得半形 式化语言的语法无法严格到可以等价于数学方法的程度，所以它描述的信息还需要进行额外 的处理才能够被机器所理解或者准确地映射为机器行为。同时，严格的语法限制也使得半形 式语言的表达能力无法达到自然语言的程度。而且因为具有独特的语法和语义，所以半形式 语言对普通用户而言无异于一门全新的语言，它所描述的信息很难被用户所理解。
自然语言采用了以文本为主的描述方式；形式化语言也是使用以文本为主的描述方式； 半形式化语言采用了以图形为主的描述方式，因为：
①半形式化语言的语法限制使得它用于信息描述的基本元素是有限的，这个有限性使 得它以限定文本或者限定图形符号为描述方式成为可能。
②半形式化语言追求表达语义的丰富性，而在这一点上图形符号是胜过限定文本的， 所以人们倾向于选择使用图形符号的描述方式。
在进行需求规格说明文档的编写时，用户倾向于使用自然语言，因为其他两种类别的 语言难以理解。开发人员倾向于使用半形式语言和形式化语言，因为自然语言的表达不够严 格和准确。形式化语言在实践中的应用很少，因为需求规格说明对语言的语义和表达能力有 着较高的要求，而这恰恰是形式化语言有所欠缺的。
为了让需求规格说明文档的内容能够同时满足用户和开发人员的需要，需求工程师在 实践中更多时候会综合使用自然语言、半形式化语言和形式化语言。
27、简述评审的过程并说明何时可以结束评审？ 答：（划线部分为必答要点）
常见的评审过程可以分为 6个阶段：
（1）规划阶段（Planning），作者和仲裁者共同制定审查计划，决定审查会议的次数，安 排每次审查会议的时间、地点、参与人员、审查内容。
（2）总体部署阶段（Overview），作者和仲裁者向所有参与审查会议的人员描述待审查材 料的内容、审查的目标以及一些假设，并分发文档。
（3）准备阶段（Preparation），审查人员各自独立执行检查任务。在检查的过程中，他们 可能会被要求使用检查清单、场景等检查方法，记录下来检查中发现的问题，以准备开会讨 论或者提交给收集人员。
（4）审查会议阶段（Inspection Meeting），通过会议讨论，识别、确认和分类发现的错误。 在审查会议结束时，还可以根据审查发现的问题严重程度来确定软件需求规格说明文档是可 以在修正后接受，还是需要在修正后再次进行评审。
（5）返工阶段（Rework），作者修改发现的缺陷。
（6）跟踪阶段（Follow-up），仲裁者要确认所有发现的问题都得到了解决，所有的错误都 得到了修正。仲裁者还要判断修正后的文档是否已满足审查的结束标准，如果不满足就需要 再次进行评审。
若满足下列情况，审查工作可以结束。
25
①审查期间审查人员提出的所有问题都已解决。
②文档中和相关的工作产品中的所有更改都已正确完成。 ③修订过的文档已经进行了拼写检查。
④所有标识为TBD(待确定)的问题都已经解决，或者已经对每个待确定问题的解决过 程、计划解决的目标日期和由谁来解决等编制了文档。
⑤文档已经在项目的配置管理系统中作了登记。 28、简述需求管理的主要作用。 答：（划线部分为必答要点）
在实践中发现的需求管理的作用有：
①增强了项目涉众对复杂产品特征在细节和相互依赖关系上的理解。需求管理将需求 基线纳入了项目的知识管理，能够帮助项目涉众更好地获得并理解这些知识，从而增强了项 目涉众对需求(尤其是复杂需求)的掌握。
②增进了项目涉众之间的交流。需求管理为项目涉众提供了一个共同的需求理解，从 而有助于项目涉众之间的交流，减少了可能的误解和交流偏差。
③减少了工作量的浪费，提高了生产力。需求管理能够更加有效地处理需求的变更， 减少因此产生的返工工作，从而提高了项目的生产率。
④准确反映项目的状态，有助于项目决策。需求管理收集的需求跟踪信息能够更加准 确地反映项目的进展情况，从而帮助项目管理者更好地掌握项目状态，做出更加符合实际情 况的合理决策。
⑤改变项目文化，使得需求的作用得到重视和有效发挥。需求管理可以为项目涉众带 来很多的好处，使得项目涉众认识到需求在项目工作中的重要性，并依照需求开展工作。
29、简述需求管理的重要任务 答：
需求管理的重要任务有： ①交流涉众的需要。
②将需求应用、实施到解决方案。 ③驱动设计和实现工作。 ④控制变更。
⑤将需求分配到子系统。 ⑥测试和验证最终产品。 ⑦控制迭代式开发中的变化。 ⑧辅助项目管理。
30、简述如何进行需求变更控制？ 答：（划线部分为必答要点）
需求开发是一个获取、明确并定义需求的过程，但需求并不是在需求开发结束之后就 会恒定不变的。
为了解决需求变化给项目带来的影响，需要正确地处理需求变化，首先要认识到在很 多情况下，需求的变化是正当和不可避免的：
①问题发生了改变。软件被创建的目的在于解决用户的问题，可是随着时间的发展， 形势可能会发生变化，导致用户的问题也发生了变化。原来的问题可能因为各种原因不解白 破，或者用户将原来的主要问题降为次要问题，而将原来的次要问题升级为主要问题等。所
26
有这些都意味着软件的需求应该发生变化，否则创建的软件将会减小甚至失去服务用户的作 用。
②环境发生了改变。软件是通过与其周围环境进行交互的方式来解决用户的问题的。如 果软件的环境发生了改变（例如法律变化、业务变化等），那么即使用户的问题依旧，软件 的需求也应该发生改变。否则，最终的软件将不能像设想的那样有效地解决用户的问题，因 为旧有的模式已经无法和新的环境形成有效互动。
③需求基线存在缺陷。需求开发的理想结果当然是建立一个完全无缺陷的需求基线， 但这是不可能达到的目标。因为需求工程的复杂性，需求开发得到的需求基线总是或多或少 的会遗留下一些缺陷。当这些缺陷在开发或者使用中暴露出来时，必须予以及时解决。
④用户变动。在开发和使用中，软件产品的用户可能发生的人员更替，这时新的用户 就可能会提出和原有用户不同的要求。在维护期间和比较长的开发周期中往往会发生这类变 更。
⑤用户对软件的认识变化。随着对软件开发和使用的直接参与，用户会对软件领域有 越来越多的了解，这时他们也往往会提出越来越多、越来越具体的需求，其中就夹杂着对原 有需求的修改要求。在一个全新的领域或者为一个没有软件经验的企业开发软件时，这种情 况非常常见。
⑥相关产品的出现。在产品开发的过程中，可能会有竞争产品、类似产品或者需要交 互的其他产品等相关产品出现，这时往往需要开发者根据相关产品的新鲜知识，变更原有的 软件需求和开发计划。
31、在功能分解过程中，最重要的是要保证分解过程的平衡性（Balance）。平衡性是保 证功能分解不会导致需求内容出现偏差的方法，它要求 DFD子图的输入流、输出流必须和 父过程的输入流、输出流保持一致。请对下图的平衡性做出分析。
答：
在上图所描述的功能分解中，父过程 P的输入流是 a，输出流是 b。在 P分解后产生的 子图当中，a是唯一从子图范围之外进入子图的数据流，所以 a是子图唯一的输入流。同样 b是唯一从子图流向范围之外的数据流，所以 b是子图唯一的输出流。这样，P的输入流、 输出流就和子图的输入流、输出流保持了一致，对 P的功能分解就满足了平衡性。
27