软件工程-第3章需求分析

1、软件工程与软件开发工具软件工程与软件开发工具第第3章章 需求分析需求分析 3.13.1需求分析概述需求分析概述 3.23.2数据流图数据流图 3.33.3数据字典数据字典 3.43.4加工逻辑描述工具加工逻辑描述工具 3.53.5结构化分析方法结构化分析方法 3.63.6复审复审 3.73.7需求分析人员需求分析人员 3.1.2 需求类型1. 按内容分类 软件需求代表系统的综合要求，包括以下几种类型：(1) 系统功能需求 系统功能需求指根据系统所能实现的功能要求，对于每一类功能或者有时对于每一个功能，需要弄清输入、加工和输出等需求。(2) 系统性能需求 按照系统的性能要求分类。例如联机系统的响

2、应时间、系统需要的存储容量、后援存储器、重新启动、安全性和可靠性等方面的要求。3.1.2 需求类型(2)(3) 系统运行需求 这类要求集中表现为对系统运行时所处的环境、使用的资源、安全保密和用户界面的要求。如支持系统运行的硬件和软件是什么，采取哪种数据库管理系统，需要什么样的外存储器和数据通信接口。 (4) 未来可能出现的问题 就是把不属于当前系统开发范围的问题都明确地列出来，因为将来很可能会提出这些问题。这些问题主要是为了系统将来的扩充和修改做准备，当以后需要时就可以很容易地进行扩展和修改了。3.1.2 需求类型(3)2. 2. 按用户的期望分类按用户的期望分类(1) 正常需求 用户陈述的针

3、对系统的目标。(2) 期望需求 隐式的需求，可能由于是非常基础的而用户没有显示的陈述，如人机交互的容易性、整体的操作正确性和可靠性，以及软件安装的容易性。(3) 兴奋需求 在用户的期望范围之外，如果实现将令人愉快和出乎意料。3.1.2 需求类型(4)3. 按必要性分类(1) 强制的需求 是指除非软件与这些需求一致，则该软件是不可接受的 (2) 希望的需求 是指这些需求将增进软件产品功能，但是如果缺乏的话也不是不可接受 (3) 任选的需求 是指这个功能可有可无3.1.3 需求特性(1) 正确性 需求规格说明书中的功能、行为、性能描述必须与用户对目标软件产品的期望相吻合。(2) 无歧义性 对于用户

4、、分析人员、设计人员和测试人员而言，需求规格说明书中的任何语法单位只能有唯一的语义解释。确保无歧义性的一种有效措施是在需求规格说明书中使用标准化术语，并对术语的语义进行显式的、统一的解释。(3) 完整性 需求规格说明书不能遗漏任何用户需求，具体地说，目标软件产品的所有功能、行为、行为约束以及它在所有可能情况下的预期行为，均应完整地包含在需求规格说明书中。(4) 可验证性 对于规格说明书中的每一个需求，均应存在技术和经济上可行的手段进行验证和确认。3.1.3 需求特性(2)(5) 一致性 需求规格说明书的各部分之间不能相互矛盾。这些矛盾可以表现为术语使用方面的冲突，功能和行为方面的冲突，以及时序

5、方面的前后不一致。(6) 可理解性 追求上述目标不应妨碍需求规格说明书对于用户、设计人员和测试人员的易理解性。特别是对于非计算机专业的用户而言，不宜在说明书中使用太多的专业化词汇。(7) 可修改性 需求规格说明书的格式和组织方式应保证能够比较容易地接纳后续的增删和修改，并使修改后的说明书能够较好地保持其他各项属性。(8) 可追踪性 需求规格说明书必须将分析后获得的每项需求与用户的原始需求项清晰地联系起来，并为后续开发和其他文档引用这些需求项提供便利。关于需求分析关于需求分析如何看待需求如何看待需求 理解需求和功能的区别 需求是需要分析的 需求一般不专一，是会变的 （要注意应变） （1）积极的沟

6、通。及时了解变化，并进行变更控制管理。 （2）在系统的架构设计上，为变化做准备。面向对象也好、面向服务也好、三层也好、四层也好，我们为什么把代码分开层次，为什么提供那么多抽象的接口？都是为了应对变化，为了我们在这个需求像云彩一样变化的环境中能够适应。 保持沟通渠道的畅通 需求分析的一般性技术为了克服困难，更有效地开展需求分析工作，为了克服困难，更有效地开展需求分析工作，软件系统分析人员必须掌握一些基本的软件系统分析人员必须掌握一些基本的需求分需求分析技术析技术，主要包括：，主要包括： 初步需求获取技术；初步需求获取技术； 需求建模技术；需求建模技术； 快速原型技术；快速原型技术； 问题的分解与

7、抽象；问题的分解与抽象； 多视点分析技术等。多视点分析技术等。初步需求获取技术原因：原因：在分析阶段的初期，由于分析人员和用在分析阶段的初期，由于分析人员和用户的共同知识领域可能不多，致使分析人员对户的共同知识领域可能不多，致使分析人员对问题往往知之不多，而用户对目标软件的要求问题往往知之不多，而用户对目标软件的要求及对要求的描述常常是零乱而模糊的，从而会及对要求的描述常常是零乱而模糊的，从而会造成相互交流和相互理解上的困难。造成相互交流和相互理解上的困难。为了克服困难，获取初步需求，可以采用如下为了克服困难，获取初步需求，可以采用如下的的技术手段：技术手段： 访谈与会议；访谈与会议； 观察用

8、户工作流程；观察用户工作流程； 分析人员和用户组成联合小组。分析人员和用户组成联合小组。1访谈与会议分析人员采用个别访谈或小组会议的形式与用户进分析人员采用个别访谈或小组会议的形式与用户进行初步交流。在访谈和会议之前，分析人员根据对行初步交流。在访谈和会议之前，分析人员根据对问题的初步描述精心准备问题的初步描述精心准备一系列问题一系列问题，通过用户对，通过用户对问题的回答或互相商讨来逐步理解用户的需求。问题的回答或互相商讨来逐步理解用户的需求。准备问题的原则有：准备问题的原则有：首先应搞清一般性、整体性问题，然后再涉及细节首先应搞清一般性、整体性问题，然后再涉及细节问题。问题。在组织问题时要尽

9、量做到客观、公证，不应限制用在组织问题时要尽量做到客观、公证，不应限制用户的自由发挥。户的自由发挥。所提问题汇总后应能反映应用问题及其子问题的全所提问题汇总后应能反映应用问题及其子问题的全貌、并且不要过分详细。貌、并且不要过分详细。2观察用户工作流程通过实际观察用户的手工操作过程来提通过实际观察用户的手工操作过程来提取新系统的初步用户需求。取新系统的初步用户需求。第一手资料第一手资料软件开发和应用的经验软件开发和应用的经验发现不合理的用户需求、提出用户发现不合理的用户需求、提出用户还没有意识到的潜在的但却很有价还没有意识到的潜在的但却很有价值的用户需求值的用户需求获得用户满意的分析结果获得用户

10、满意的分析结果观察手工操作过程观察手工操作过程3用户和开发人员共同组成联合小组目的：目的：为加强信息沟通、减少误解和避免产生遗漏、为加强信息沟通、减少误解和避免产生遗漏、充分调动用户的积极性。充分调动用户的积极性。方法：方法：建立由开发方和用户方共同组成的联合小组。建立由开发方和用户方共同组成的联合小组。联合小组成员：联合小组成员：双方的分析人员双方的分析人员 专门的记录员专门的记录员 负责会议议程的人员负责会议议程的人员 资料员资料员 另外：制定小组的规章制度和计划，选定一种易于另外：制定小组的规章制度和计划，选定一种易于理解、简洁、精确的表示机制作为双方的共同语言，理解、简洁、精确的表示机

11、制作为双方的共同语言，比如采用带文字说明的流程图等。比如采用带文字说明的流程图等。【例】这里以“家庭保安系统”为例，简要说明初步需求的获取过程。假设用户的原始需求描述如下： 根据家庭保安市场的增长趋势，我根据家庭保安市场的增长趋势，我们希望建立一种基于微处理器的家们希望建立一种基于微处理器的家庭保安系统，它能够识别异常事件庭保安系统，它能够识别异常事件并采取相应的报警措施。这些并采取相应的报警措施。这些异常异常事件有：非法进入、火灾、水淹事件有：非法进入、火灾、水淹，等等。当传感器一旦探测出相应的等等。当传感器一旦探测出相应的异常事件时，系统应异常事件时，系统应自动用电话向自动用电话向监控中心

12、报警监控中心报警。此外，系统应允许。此外，系统应允许户主对其行为实施程序式控制户主对其行为实施程序式控制。【例】为进行初步的需求分析，这里采用开发方和用户方组为进行初步的需求分析，这里采用开发方和用户方组成联合小组的方法。为此，联合小组成联合小组的方法。为此，联合小组应制定工作制度应制定工作制度：每次会议开始前必须有确定的议程，小组成员必须针每次会议开始前必须有确定的议程，小组成员必须针对议程进行充分准备并应形成文字。对议程进行充分准备并应形成文字。联合小组会议联合小组会议首先应明确问题的范围、问题与环境的首先应明确问题的范围、问题与环境的关系，并就开发软件产品的必要性达成共识。关系，并就开发

13、软件产品的必要性达成共识。小组负责人要求小组负责人要求每位参加者每位参加者根据负责的范围列出应用根据负责的范围列出应用问题及环境中有关的对象、对象的操作及对象间的关问题及环境中有关的对象、对象的操作及对象间的关系。系。 如：如：市场营销人员列出控制面板、电话机、监控中心市场营销人员列出控制面板、电话机、监控中心等对象和用户编程控制、电话拨号、报警等操作；等对象和用户编程控制、电话拨号、报警等操作； 负责传感器的用户可能列举烟雾传感器、门窗监负责传感器的用户可能列举烟雾传感器、门窗监视器、警报器等对象。视器、警报器等对象。【例】将对这些列举的对象和操作将对这些列举的对象和操作进行更详细的讨论进行

14、更详细的讨论和描述和描述，比如，详细地描述接收传感器事件、，比如，详细地描述接收传感器事件、用户编程控制、电话报警等操作等。用户编程控制、电话报警等操作等。用户用户可能提出一些约束条件。比如，造价不应可能提出一些约束条件。比如，造价不应超过超过30003000元，对传感器事件的响应时间不得元，对传感器事件的响应时间不得超过超过1 1秒，事件必须按优先级顺序进行处理等秒，事件必须按优先级顺序进行处理等等。等。小组负责人应对这些小组负责人应对这些信息加以整理信息加以整理并形成文档，并形成文档，该文档应能反映该文档应能反映“家庭保安系统家庭保安系统”的全貌。的全貌。【例】根据根据“家庭保安系统家庭保

15、安系统”的特点，的特点，将联合小组分将联合小组分成两个小组成两个小组，并行处理用户编程控制和传感器，并行处理用户编程控制和传感器检测两个子系统，以便使子问题的软件需求进检测两个子系统，以便使子问题的软件需求进一步细化，这时可能又会增加新对象、新操作、一步细化，这时可能又会增加新对象、新操作、新约束条件。在子系统的需求基本明确并形成新约束条件。在子系统的需求基本明确并形成文档后，还应就子系统的整合及需求验证标准文档后，还应就子系统的整合及需求验证标准等进行初步的讨论。等进行初步的讨论。初步需求分析应初步需求分析应形成结论性文档形成结论性文档。比如，经过。比如，经过初步的需求分析，初步的需求分析，

16、“家庭保安系统家庭保安系统”的部分初的部分初步需求文档如下：步需求文档如下：【例】 “家庭保安系统家庭保安系统”的软件允许用户在安装时进行系统配的软件允许用户在安装时进行系统配置，实施对传感器的监控并通过控制面板与户主进行信置，实施对传感器的监控并通过控制面板与户主进行信息交互。息交互。 系统开机后，软件系统负责显示系统当前的工作系统开机后，软件系统负责显示系统当前的工作状态，接收并处理户主的命令。状态，接收并处理户主的命令。 当系统处于配置状态，软件系统允许户主进行配置操当系统处于配置状态，软件系统允许户主进行配置操作。作。配置操作包括：指定每一传感器的种类和编号；配置操作包括：指定每一传感

17、器的种类和编号； 设置开、关机密码；设置开、关机密码； 指定报警电话号码；指定报警电话号码； 指定报警延迟和电话重拨延迟时间指定报警延迟和电话重拨延迟时间（以秒为单位）。（以秒为单位）。 当系统处于监视状态时，软件系统即开始对所当系统处于监视状态时，软件系统即开始对所有传感器实施监控。当软件系统接收到传感器发出的数有传感器实施监控。当软件系统接收到传感器发出的数据后，判别是否出现异常事件，如果是，则经过指定的据后，判别是否出现异常事件，如果是，则经过指定的延迟时间即开始拨报警电话号码，拨号操作将按照重拨延迟时间即开始拨报警电话号码，拨号操作将按照重拨延迟反复进行，直至电话接通。此时软件系统负责

18、向监延迟反复进行，直至电话接通。此时软件系统负责向监控中心报告异常事件发生的地点、时间和性质。控中心报告异常事件发生的地点、时间和性质。【例】 以上文档没有包括约束条件、测试标准等方以上文档没有包括约束条件、测试标准等方面的内容。面的内容。初步需求文档将是后续详细需求分析的基础。初步需求文档将是后续详细需求分析的基础。在此基础上，就可以采用某种需求分析方法进在此基础上，就可以采用某种需求分析方法进行详细的需求分析。行详细的需求分析。分别介绍几种详细的需求分析方法和其中最重分别介绍几种详细的需求分析方法和其中最重要的需求建模技术，它们是：要的需求建模技术，它们是： “面向数据流的需求分析方法面向

19、数据流的需求分析方法”； “面向数据的需求分析方法面向数据的需求分析方法”； “面向对象的需求分析方法面向对象的需求分析方法”。需求建模技术为了使用户需求逐步精细化、完全化、一致化，为了使用户需求逐步精细化、完全化、一致化，通常采用通常采用需求建模技术需求建模技术，即，即用建立目标软件系用建立目标软件系统模型的方法统模型的方法来刻画软件系统中的信息、处理来刻画软件系统中的信息、处理功能和外部行为。功能和外部行为。通常，分析人员选定一种分析方法，通常，分析人员选定一种分析方法，并用该方并用该方法中的一些图形记号分别表示信息流、处理功法中的一些图形记号分别表示信息流、处理功能和系统行为，并利用受限

20、制的自然语言给出能和系统行为，并利用受限制的自然语言给出用户需求的描述。用户需求的描述。这种模型的表示机制还应具这种模型的表示机制还应具有良好的结构化能力，以便处理大型问题的按有良好的结构化能力，以便处理大型问题的按层次分解的问题。层次分解的问题。软件需求分析的过程，实际上是软件模型的建软件需求分析的过程，实际上是软件模型的建造和不断完善的过程。造和不断完善的过程。需求建模的步骤在分析的初期，分析人员通过访谈、会议、实际观在分析的初期，分析人员通过访谈、会议、实际观 察、分析现有系统等方法察、分析现有系统等方法获取初步的用户需求获取初步的用户需求。分析人员根据选定的一种分析方法，在初步用户需分

21、析人员根据选定的一种分析方法，在初步用户需 求的基础上求的基础上构筑初步的模型构筑初步的模型作为开发方和用户相互作为开发方和用户相互 沟通的表示机制。沟通的表示机制。分析人员在用户的密切配合下，利用选定的分析方分析人员在用户的密切配合下，利用选定的分析方 法法不断地对模型进行精细化、一致化、完全化，不断地对模型进行精细化、一致化、完全化，直直 至获得满意的用户需求为止。至获得满意的用户需求为止。在分析阶段构筑的模型在分析阶段构筑的模型不应涉及软件实现的细节不应涉及软件实现的细节，以，以免分散分析人员的注意力、限制软件设计人员为提高免分散分析人员的注意力、限制软件设计人员为提高软件质量和效率而选

22、择实现方法的自由度。软件质量和效率而选择实现方法的自由度。需求分析结束时确立的需求分析结束时确立的软件模型是生成需求规格说明软件模型是生成需求规格说明的依据，也是软件设计和实现的基础的依据，也是软件设计和实现的基础。快速原型技术 如果按照传统的软件开发方法，需要经过漫长的如果按照传统的软件开发方法，需要经过漫长的开发时间之后用户才能看到目标软件的最初版本。开发时间之后用户才能看到目标软件的最初版本。此时用户常常会提出许多修改意见，有时甚至全盘此时用户常常会提出许多修改意见，有时甚至全盘否定，导致开发失败。否定，导致开发失败。为了降低开发风险，在需求为了降低开发风险，在需求分析阶段常常采用快速原

23、型技术。分析阶段常常采用快速原型技术。 1 1快速原型技术的基本思想快速原型技术的基本思想 在软件开发的早期，在软件开发的早期，快速开发一个目标软件系统快速开发一个目标软件系统的原型的原型，让用户对其进行评价并提出修改意见，然，让用户对其进行评价并提出修改意见，然后开发人员根据用户的意见对原型进行改进。当原后开发人员根据用户的意见对原型进行改进。当原型几经改进最终确认后，它将直接进化成软件产品，型几经改进最终确认后，它将直接进化成软件产品，或者由软件设计、编码人员按照模型所确立的外部或者由软件设计、编码人员按照模型所确立的外部特征去实现软件产品。特征去实现软件产品。2采用快速原型技术的具体步骤

24、采用一种分析方法生成一个软件系统或其中所关心部分采用一种分析方法生成一个软件系统或其中所关心部分的简化需求规格说明。的简化需求规格说明。对该规格说明进行评审通过后，立即生成设计规格说明。对该规格说明进行评审通过后，立即生成设计规格说明。为了快速生成原型，这种设计为了快速生成原型，这种设计仅注重所关心的问题仅注重所关心的问题，如，如软件的总体结构、用户界面和数据设计、或者某个复杂软件的总体结构、用户界面和数据设计、或者某个复杂的算法等等，不注重过程内部的控制流设计。的算法等等，不注重过程内部的控制流设计。使用可重用软部件、用户界面自动生成器等工具使用可重用软部件、用户界面自动生成器等工具快速生快

25、速生成可运行的软件原型并通过测试成可运行的软件原型并通过测试。将原型提交给将原型提交给用户进行评价用户进行评价，以便征求改进意见。，以便征求改进意见。上述过程上述过程反复迭代反复迭代，直至用户完全满意。此时的原型已，直至用户完全满意。此时的原型已完全、准确地反映了目标软件在所关心方面的需求，可完全、准确地反映了目标软件在所关心方面的需求，可作为需求规格说明的一部分而成为软件设计的基础。作为需求规格说明的一部分而成为软件设计的基础。3快速原型技术的适用场合该技术特别适合于软件产品要求大量的该技术特别适合于软件产品要求大量的用户交互、或产生大量的可视输出、或用户交互、或产生大量的可视输出、或设计一

26、些复杂的算法等场合，目前的绝设计一些复杂的算法等场合，目前的绝大多数软件都适合于快速原型技术。大多数软件都适合于快速原型技术。除非由于问题相当复杂，致使开发快速除非由于问题相当复杂，致使开发快速原型可以获得的支持太少、所冒的风险原型可以获得的支持太少、所冒的风险太大时，就不易采用。但对于其中的某太大时，就不易采用。但对于其中的某些子问题，尤其是用户界面，还可采用些子问题，尤其是用户界面，还可采用快速原型技术进行部分分析。快速原型技术进行部分分析。问题分解与抽象、多视点分析技术问题分解技术问题分解技术 分析人员常常采用一种问题分解的技术。分析人员常常采用一种问题分解的技术。即将一个即将一个大型复

27、杂的问题分解为若干个子问题，然后对每一个大型复杂的问题分解为若干个子问题，然后对每一个子问题逐个进行分析，再自底向上综合成整个问题的子问题逐个进行分析，再自底向上综合成整个问题的分析结果。分析结果。这种分解可以逐级进行，直至子问题的规这种分解可以逐级进行，直至子问题的规模降到合适的程度。模降到合适的程度。问题抽象技术问题抽象技术 分析人员在分析过程中要善于分析人员在分析过程中要善于从诸多的特殊问题中从诸多的特殊问题中抽象出一般的问题，首先关注一般问题的解决途径，抽象出一般的问题，首先关注一般问题的解决途径，再用其指导特殊问题的求解。再用其指导特殊问题的求解。在抽象的过程中，还要在抽象的过程中，

28、还要注意用户的描述所处的抽象级别的不同，以便建立清注意用户的描述所处的抽象级别的不同，以便建立清晰的思路。晰的思路。问题分解与抽象、多视点分析技术 比如，在比如，在“家庭保安系统家庭保安系统”中，用户可能提出中，用户可能提出“系统状态显示系统状态显示”、“用户编制程序时的系统外部用户编制程序时的系统外部行为行为”等的需求。分析人员则应在等的需求。分析人员则应在“用户界面用户界面”这这一抽象级别上统一地规划软件系统与用户的交互行一抽象级别上统一地规划软件系统与用户的交互行为。可见，在不同的抽象级别上去分析不同层次的为。可见，在不同的抽象级别上去分析不同层次的问题，也是解决复杂问题的一个重要方法，

29、它可以问题，也是解决复杂问题的一个重要方法，它可以避免不一致性，减少分析的工作量。避免不一致性，减少分析的工作量。多视点分析技术：多视点分析技术： 为了获得全面的需求分析结果，防止遗漏，有必要为了获得全面的需求分析结果，防止遗漏，有必要从各个视点分别对问题进行理解与分析，然后综合从各个视点分别对问题进行理解与分析，然后综合成全面的理解。成全面的理解。分析人员可以就系统视点与用户视分析人员可以就系统视点与用户视点、信息视点、功能视点与行为视点等多个视点分点、信息视点、功能视点与行为视点等多个视点分别进行分析，以确保需求分析的完全性。别进行分析，以确保需求分析的完全性。需求规格说明与评审需求分析的

30、主要阶段性产品是需求规格说明书。它必需求分析的主要阶段性产品是需求规格说明书。它必须通过需求评审后才能生效，这是一个重要的里程碑。须通过需求评审后才能生效，这是一个重要的里程碑。4.3.1 4.3.1 需求规格说明书的作用与内容需求规格说明书的作用与内容1. 1. 需求规格说明书的作用需求规格说明书的作用主要主要有：有：1 1）它是软件设计人员进行设计和编码的）它是软件设计人员进行设计和编码的出发点和基础；出发点和基础；2 2）它是对目标软件产品进行）它是对目标软件产品进行验收测试的依据验收测试的依据。这就要。这就要求需求规格说明书中的各项需求都应该是可测试的；求需求规格说明书中的各项需求都应

31、该是可测试的；3 3）它起到软件开发方和客户（或用户）方之间的一份）它起到软件开发方和客户（或用户）方之间的一份合同的作用合同的作用。需求规格说明书的作用与内容2. 2. 需求规格说明书中的内容需求规格说明书中的内容q应主要包括应主要包括功能与行为的需求描述功能与行为的需求描述和非和非行为需求描行为需求描述。述。功能与行为需求的分析与描述方法将在以后几章中功能与行为需求的分析与描述方法将在以后几章中根据不同的需求建模方法分别介绍。根据不同的需求建模方法分别介绍。非行为需求是指目标软件系统在工作时应具备的属非行为需求是指目标软件系统在工作时应具备的属性，主要有运行效率、可靠性、安全性、可维护性、

32、性，主要有运行效率、可靠性、安全性、可维护性、可移植性等等。可移植性等等。在需求规格说明书中不应包括如人员需求、成本预在需求规格说明书中不应包括如人员需求、成本预算、进度计划、质量保证计划等内容，以便使其简算、进度计划、质量保证计划等内容，以便使其简洁、目标明确。洁、目标明确。需求规格说明书的基本格式框架目录目录1 1 引言引言 1.1 1.1 本说明的编写目的本说明的编写目的 1.2 1.2 软件产品的作用范围软件产品的作用范围 1.3 1.3 定义、同义词与缩写定义、同义词与缩写 1.4 1.4 参考文献参考文献2 2 概述概述 2.1 2.1 产品与其环境间的关系产品与其环境间的关系 2

33、.2 2.2 功能概述功能概述 2.3 2.3 用户特征用户特征 2.4 2.4 约束条件约束条件 2.5 2.5 假设与前提条件假设与前提条件需求规格说明书的基本格式框架3 3功能或行为需求功能或行为需求 3.1 3.1 功能或行为需求功能或行为需求1 1：1 1）引言）引言 2 2）输入）输入 3 3）处理过程描述）处理过程描述 4 4）输出）输出 3.2 3.2 功能或行为需求功能或行为需求2 2：1 1）引言）引言 2 2）输入）输入 3 3）处理过程描述）处理过程描述 4 4）输出）输出 3.n 3.n 功能或行为需求功能或行为需求n: 4n: 4）输出）输出需求规格说明书的基本格式

34、框架4 4外部界面需求外部界面需求 4.1 4.1 用户界面用户界面 4.2 4.2 硬件界面硬件界面 4.3 4.3 软件界面软件界面5 5性能需求性能需求 5.1 5.1 精度精度 5.2 5.2 时间特征时间特征 5.3 5.3 灵活性灵活性6 6设计约束设计约束 6.1 6.1 标准化约束标准化约束 6.2 6.2 硬件约束硬件约束 需求规格说明书的基本格式框架7 7其他需求其他需求 7.1 7.1 数据库需求数据库需求 7.2 7.2 用户操作需求用户操作需求 7.3 7.3 工作场地需求工作场地需求8 8软件产品属性软件产品属性 8.1 8.1 可用性可用性 8.2 8.2 安全性

35、安全性 8.3 8.3 可维护性可维护性 8.4 8.4 可移植性可移植性附录附录索引索引需求评审软件系统中的错误约有软件系统中的错误约有15%15%来源于需求分析中的错来源于需求分析中的错误。而在维护阶段去改正这部分错误是相当困难的。误。而在维护阶段去改正这部分错误是相当困难的。为了及时发现并纠正这类错误，必须对需求规格说为了及时发现并纠正这类错误，必须对需求规格说明书进行评审，即需求评审。明书进行评审，即需求评审。1. 1. 评审标准（按照重要性的次序）评审标准（按照重要性的次序）1 1）正确性。指需求规格说明书中的每一项功能、行）正确性。指需求规格说明书中的每一项功能、行为、性能的描述都

36、是正确的、合理的，并能满足用为、性能的描述都是正确的、合理的，并能满足用户的期望。户的期望。2 2）无歧义性。指规格说明书中的每个需求陈述都只）无歧义性。指规格说明书中的每个需求陈述都只有唯一的解释。要避免产生歧义性，就应使用标准有唯一的解释。要避免产生歧义性，就应使用标准化术语，并对术语的语义进行统一的解释。化术语，并对术语的语义进行统一的解释。1. 评审标准（按照重要性的次序）3 3）完全性。指不遗漏任何用户需求。即需求规）完全性。指不遗漏任何用户需求。即需求规格说明书中包括了所有的功能、行为、性能约格说明书中包括了所有的功能、行为、性能约束等。束等。4 4）可验证性。指需求规格说明书中的

37、每一项需）可验证性。指需求规格说明书中的每一项需求都是可以检验的。求都是可以检验的。5 5）一致性。指陈述的需求之间不存在矛盾之处。）一致性。指陈述的需求之间不存在矛盾之处。6 6）可理解性。指规格说明应尽量简洁、明确，）可理解性。指规格说明应尽量简洁、明确，便于分析人员、客户（用户）、设计人员、测便于分析人员、客户（用户）、设计人员、测试人员和维护人员的理解。因此，应尽量减少试人员和维护人员的理解。因此，应尽量减少专业化的词汇。专业化的词汇。 1. 评审标准（按照重要性的次序）7 7）可修改性。指需求规格说明书的框架结构应能）可修改性。指需求规格说明书的框架结构应能比较容易地实现对其可能进行

38、的增补、删除和修比较容易地实现对其可能进行的增补、删除和修改，并能保持总体结构不变。改，并能保持总体结构不变。8 8）可追踪性。指规格说明可向前追踪，即其中的）可追踪性。指规格说明可向前追踪，即其中的每一项需求与用户的原始需求项清晰地联系起来；每一项需求与用户的原始需求项清晰地联系起来；也可向后追踪，即为后续开发和其他文档引用这也可向后追踪，即为后续开发和其他文档引用这些需求项提供了依据。些需求项提供了依据。2. 需求评审过程 需求评审过程应采用召开正式评审会议的形式需求评审过程应采用召开正式评审会议的形式。 参加的人员应当有用户、系统分析员、系统设计人参加的人员应当有用户、系统分析员、系统设

39、计人员等。在评审会上，分析人员应说明软件产品的总体员等。在评审会上，分析人员应说明软件产品的总体目标，也就是介绍需求规格说明书中的主要内容。之目标，也就是介绍需求规格说明书中的主要内容。之后，与会人员对说明书的核心部分后，与会人员对说明书的核心部分需求模型进行需求模型进行评估。并按照上述的评审标准逐一进行审查，最后确评估。并按照上述的评审标准逐一进行审查，最后确认其是否具有良好的品质、是否构成以后开发的良好认其是否具有良好的品质、是否构成以后开发的良好的基础。如果在评审过程中发现说明书中存在错误或的基础。如果在评审过程中发现说明书中存在错误或遗漏，应责承分析人员返工，并再行评审。需求评审遗漏，

40、应责承分析人员返工，并再行评审。需求评审也可采用先进行技术评审，再进行管理复审的方法进也可采用先进行技术评审，再进行管理复审的方法进行。管理复审应有开发方和客户方（或用户方）管理行。管理复审应有开发方和客户方（或用户方）管理部门负责人参加，复审通过后，双方应签订正式的合部门负责人参加，复审通过后，双方应签订正式的合同。同。1.1. 分析系统的数据要求分析系统的数据要求 数据的源点/终点:是指在系统以外的事物或人 加工处理:表示对数据的处理功能 数据存储:表示对数据存储的逻辑描述，它可以是数据库文件或任何其他形式的数据组织。 数据流:表示数据在系统中流动的方向。 或或或数据的源点/终点加工/处理

41、数据存储数据流TTTTTTABABABCBCBCCCAAA*+输入A和B变换成C输入A或B，或者A和B变换成C只有输入A或只有B，变换成C（A、B不能同时输入）输入A变换成B和C输入A变换B或C，或者A和B输入A变换成B或C，但不能变换成B和CCB教材管理系统的数据流图教材管理系统的数据流图 采购会计学生供书商订单发单票/收据订书通知到书通知订书单发书单暂存订单采购订单应收款总帐应付款销售历史库存销售付款收款单付款证凭付款单付款收据3.3数据字典DD 数据流图描述系统的逻辑模型，但它不可能表达一个系统的全部逻辑特性，特别是有关数据的详细内容。 数据字典恰恰弥补了数据流图在这个方面的不足，它专门

42、记录有关数据方面的信息，作为对数据流图的补充和解释。 数据流图和数据词典共同构成全面描述软件需求说明书的核心。3.3.1定义方法定义方法 数据字典要对数据流图中出现的所有名字进行定义。 同日常使用的词典一样，为了便于查阅，词典中的所有条目都要按一定的次序排列起来，也可采用卡片的形式，以供开发与维护人员方便地使用。3.3.1定义方法定义方法(2)数据流定义中常用的符号含义如下： =表示“被定义为”； + 表示“和”，连接两个或多个分量； .|. 表示“选择”，即可选择方括号中的一项，用“|”作为各项的分割符； ( ) 表示“可选”，即括号内的项可选可不选； mn表示“重复”，n为重复次数的上限，

43、m为重复次数的下限，如重复次数没有限定可不标出上下限。也可以利用上下标表示。6.数据结构的描述 x x = = a ab b.,. .,. 或或 .|.|. x x = = a a, ,b b ，x x = = a a| |b b . . 或或 m.nm.n x x = = a a ， x x = 3 = 3a a88(.) (.) x x = ( = (a a) )“.”“.” x x = “ = “a a” . . x x = 1.9 = 1.9练习练习: 画出和存折操作有关的基本的数据流图 定义各种类型的数据字典词条3.4 加工逻辑描述工具 对于某些复杂的加工，只用文字说明则存在许多含糊

44、不清之处。此时，可借助一些加工逻辑描述工具来清楚地表达。 常用的加工逻辑描述工具有结构化语言、判断表、判断树和IPO图等。 BEGIN 输入用户账号和口令 IF 输入空的帐号或口令 THEN BEGIN提示错误中断登录 END 验证帐号、口令 IF 非合法用户 OR 权限=“禁止” THEN BEGIN 提示错误 中断登录 END 初试化运行环境n数据库事务操作逻辑数据库事务操作逻辑2. 判定表 判定表也是一种表达加工逻辑的工具。 在某些数据处理中，某数据流图的加工需要依赖于多个逻辑条件的取值，就是说完成这一加工的动作是由于某一组条件取值的组合而引发的。这时使用判定表来描述比较合适。2. 判定

45、表的组成 条件：列出一组条件的对象； 条件取值：列出各种可能的条件取值组合； 操作：列出所有的操作； 操作条目：列出对应的条件组合下所选的操作。判定表的一般结构 条件1条件1取值条件1取值条件2条件2取值条件2取值操作1操作1取值操作1取值操作2操作2取值操作2取值建立判定表的步骤 列出与一个具体加工 (或过程)有关的所有处理 列出过程执行期间的所有条件(或所有判断) 将特定条件取值组合与特定的处理相匹配，消去不可能发生的条件取值组合 将右部每一纵列规定为一个处理规则，即对于某一条件取值组合将有什么动作毕业证、学位证书授予判定表毕业证、学位证书授予判定表 12345没有未通过的必修课程YNNN

46、N未通过的必修课程学分总数小于等于12YNNYY通过的课程学分数大于等于30YYNYN授予毕业证书授予结业证书授予肄业证书不授予任何证书 判定树是判定表的变种，它能清晰地表达复杂的条件组合与所对应的操作之间的关系。 判定树的优点在于它含义清楚，易于理解和使用，比判定表更加直观。 计 算 折 扣量79月，12月16月，10、11月订票量50：15%订票量50：30%订票量=50：20% 输入/处理/输出图 描绘输入数据、对数据的处理和输出数据之间的关系 输入数据左边框 对数据的处理中间框，隐含执行顺序 输出数据右边框成绩单输出IPO统计要求各类课程成绩查询条件统计成绩成绩录入成绩查询各类统计报表成绩记录查询结果3.5.1数据流图的分层3.5.1数据流图的分层(2)012.12.21.31.11.23.23.13.332顶层第一层第二层容易出现的问题 0层DFD概念不清，包含多个加工，往往忽略数据存储，过于简单，不能够建立完整抽象模型 数据流