第四章(需求分析).ppt

《第四章(需求分析).ppt》由会员分享，可在线阅读，更多相关《第四章(需求分析).ppt（165页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、u软件需求软件需求u需求工程需求工程u分析建模分析建模u需求管理需求管理u本章小结本章小结【学习目标学习目标】本章介绍需求分析的意义、概念和方本章介绍需求分析的意义、概念和方法，了解结构化分析方法和需求管理的关法，了解结构化分析方法和需求管理的关键活动；要求学会运用实体关系图、数据键活动；要求学会运用实体关系图、数据流图和状态控制图进行结构化分析建模，流图和状态控制图进行结构化分析建模，能够编写软件需求规格说明。能够编写软件需求规格说明。第四章软件需求分析与建模【学习方法学习方法】正确理解需求工程涉及的基本概正确理解需求工程涉及的基本概念，结合具体实例运用结构化分析技念，结合具体实例运用结构化

2、分析技术，从而达到理论学习及在实际项目术，从而达到理论学习及在实际项目中应用的目的。中应用的目的。第四章软件需求分析与建模【难重点难重点】本章的学习重点在于理解软件需求的本章的学习重点在于理解软件需求的概念和重要性，熟悉需求开发和需求管理概念和重要性，熟悉需求开发和需求管理的基本思想和主要活动，掌握结构化的分的基本思想和主要活动，掌握结构化的分析方法；难点是怎样在实际的软件项目中析方法；难点是怎样在实际的软件项目中灵活运用这些思想和方法。灵活运用这些思想和方法。第四章软件需求分析与建模【课前思考课前思考】u软件需求存在什么问题？软件需求存在什么问题？u什么是软件需求？什么是软件需求？u什么是需

3、求工程？什么是需求工程？u常见的需求分析方法是什么？常见的需求分析方法是什么？u需求分析的结果可以验证吗？需求分析的结果可以验证吗？u需求规格说明有什么质量要求？需求规格说明有什么质量要求？第四章软件需求分析与建模第四章软件需求分析与建模【本节知识点本节知识点】u软件需求的定义软件需求的定义u需求的层次需求的层次u导致需求缺陷的原因导致需求缺陷的原因4.1 软件需求软件需求第四章软件需求分析与建模随着计算机技术的飞速发展，软件已随着计算机技术的飞速发展，软件已经成为人们生活中不可缺少的一部分。人经成为人们生活中不可缺少的一部分。人们在使用软件的过程中，常常会抱怨它无们在使用软件的过程中，常常会

4、抱怨它无法执行某些基本操作。但对于软件开发人法执行某些基本操作。但对于软件开发人员而言，用户不断提出新的要求是一件多员而言，用户不断提出新的要求是一件多么烦人的事。么烦人的事。4.1 软件需求软件需求第四章软件需求分析与建模其实，在软件开发过程中遇到的许多问其实，在软件开发过程中遇到的许多问题，都是由于收集、编写、协商、修改软件题，都是由于收集、编写、协商、修改软件需求过程中的失误带来的，诸如信息收集不需求过程中的失误带来的，诸如信息收集不全、功能不明确、交流不充分、文档不完善、全、功能不明确、交流不充分、文档不完善、需求发生变化等。可以这样说，软件项目中需求发生变化等。可以这样说，软件项目中

5、百分之四十至百分之六十的问题都是在需求百分之四十至百分之六十的问题都是在需求分析阶段埋下的分析阶段埋下的祸根祸根。4.1 软件需求软件需求第四章软件需求分析与建模开发软件系统最为困难的部分就是开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性准确说明开发什么。最为困难的概念性工作便是编写详细的技术需求，包括所工作便是编写详细的技术需求，包括所有面向用户、面向机器和其它软件系统有面向用户、面向机器和其它软件系统的接口。的接口。4.1 软件需求软件需求第四章软件需求分析与建模IEEEIEEE软件工程标准词汇表将需求定义为：软件工程标准词汇表将需求定义为：（1 1）用户解决问题或达到目

6、标所需的条）用户解决问题或达到目标所需的条件或能力。件或能力。（2 2）系统或系统部件要满足合同、标准、）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或规范或其它正式规定文档所需具有的条件或能力。能力。（3 3）一种反映上面（）一种反映上面（1 1）或（）或（2 2）所描述）所描述的条件或能力的文档说明。的条件或能力的文档说明。4.1.1 软件需求的定义软件需求的定义第四章软件需求分析与建模下面列出其他几种关于下面列出其他几种关于“需求需求”的定义：的定义：u需求是用户所需要的并能触发一个程序或需求是用户所需要的并能触发一个程序或系统开发工作的说明；系统开发工作的说明；

7、u需求是从系统外部能发现系统所具有的满需求是从系统外部能发现系统所具有的满足于用户的特点、功能及属性等；足于用户的特点、功能及属性等；u需求是指明必须实现什么的规格说明。它需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发描述了系统的行为、特性或属性，是在开发过程中对系统的约束。过程中对系统的约束。4.1.1 软件需求的定义软件需求的定义第四章软件需求分析与建模软件需求包括四个不同的层次：即业软件需求包括四个不同的层次：即业务需求、用户需求和功能需求，另外还有务需求、用户需求和功能需求，另外还有非功能需求。非功能需求。软件需求各组成部分之间的关系如下软件需求各组成部分之

8、间的关系如下图所示。图所示。4.1.2 需求的层次需求的层次第四章软件需求分析与建模4.1.2 需求的层次需求的层次第四章软件需求分析与建模业务需求业务需求反映了组织机构或客户对系统或产品反映了组织机构或客户对系统或产品高层次的目标要求，它们在项目视图与高层次的目标要求，它们在项目视图与范围文档中予以说明。范围文档中予以说明。4.1.2 需求的层次需求的层次第四章软件需求分析与建模用户需求用户需求描述了用户使用产品必须要完成的描述了用户使用产品必须要完成的任务，可以在用例模型或方案脚本中予任务，可以在用例模型或方案脚本中予以说明。以说明。4.1.2 需求的层次需求的层次第四章软件需求分析与建模

9、功能需求功能需求定义了开发人员必须实现的软件功定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而能，使得用户能完成他们的任务，从而满足了业务需求。满足了业务需求。4.1.2 需求的层次需求的层次第四章软件需求分析与建模非功能需求非功能需求是从各个角度对系统的约束和限制，是从各个角度对系统的约束和限制，反映了应用对软件系统质量和特性的额外反映了应用对软件系统质量和特性的额外要求。要求。4.1.2 需求的层次需求的层次第四章软件需求分析与建模非功能需求包括过程需求、产品需求和外非功能需求包括过程需求、产品需求和外部需求三类。其中过程需求有交付、实现方法部需求三类。其中过程需求有交付、

10、实现方法和标准等需求；产品需求包含性能、可用性、和标准等需求；产品需求包含性能、可用性、实用性、可靠性、可移植性、安全保密性、容实用性、可靠性、可移植性、安全保密性、容错性等方面的需求；外部需求有法规、成本、错性等方面的需求；外部需求有法规、成本、操作性等需求。操作性等需求。4.1.2 需求的层次需求的层次第四章软件需求分析与建模需求工程中的缺陷将给项目的成需求工程中的缺陷将给项目的成功带来极大风险，导致缺陷的原因主功带来极大风险，导致缺陷的原因主要包括以下方面：要包括以下方面：4.1.3 需求错误的原因需求错误的原因第四章软件需求分析与建模缺乏足够的用户参与缺乏足够的用户参与客户经常不明白为

11、什么收集需求和确保需求质量需客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫，开发人员可能也不重视用户的参与。花费那么多功夫，开发人员可能也不重视用户的参与。究其原因：一是因为与用户合作不如编写代码有意思；究其原因：一是因为与用户合作不如编写代码有意思；二是因为开发人员觉得已经明白用户的需求了。在某些二是因为开发人员觉得已经明白用户的需求了。在某些情况下，与实际使用产品的用户直接接触很困难，而客情况下，与实际使用产品的用户直接接触很困难，而客户也不太明白自己的真正需求。然而，在项目的早期让户也不太明白自己的真正需求。然而，在项目的早期让具有代表性的用户直接参与到开发队伍中，并一同经历

12、具有代表性的用户直接参与到开发队伍中，并一同经历整个开发过程很重要。整个开发过程很重要。4.1.3 需求错误的原因需求错误的原因第四章软件需求分析与建模用户需求不断增加用户需求不断增加在开发过程中，用户需求经常发生变化，在开发过程中，用户需求经常发生变化，但是不断的变更会使其整体结构越来越乱，整但是不断的变更会使其整体结构越来越乱，整个程序也难以理解和维护。如果要减少需求变个程序也难以理解和维护。如果要减少需求变更的影响范围，就必须在项目的开始对项目视更的影响范围，就必须在项目的开始对项目视图、范围、目标、约束限制和成功标准给予明图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评

13、价需求变更和新特确说明，并将此说明作为评价需求变更和新特性的参照框架。性的参照框架。4.1.3 需求错误的原因需求错误的原因第四章软件需求分析与建模需求模棱两可需求模棱两可模棱两可是需求规格说明中最严重的问题，模棱两可是需求规格说明中最严重的问题，它意味着不同的人对需求说明产生了不同的理它意味着不同的人对需求说明产生了不同的理解，或者是同一个人能用不止一个方式来解释解，或者是同一个人能用不止一个方式来解释某项需求说明。模棱两可的需求带来的后果便某项需求说明。模棱两可的需求带来的后果便是返工是返工-重做一些你认为已做好的事情，返工重做一些你认为已做好的事情，返工会耗费开发总费用的会耗费开发总费用

14、的40%，而而70%85%的的重做是由于需求方面的错误引起的。重做是由于需求方面的错误引起的。4.1.3 需求错误的原因需求错误的原因第四章软件需求分析与建模添加不必要的特性添加不必要的特性有时候，开发人员力图增加一些有时候，开发人员力图增加一些用户用户欣赏欣赏但需求规格说明中并未涉及的新功能，但需求规格说明中并未涉及的新功能，然而常常是用户并不认为这些功能性很有然而常常是用户并不认为这些功能性很有用。开发人员应当为客户构思方案，并为用。开发人员应当为客户构思方案，并为他们提供一些具有创新意识的思路，具体他们提供一些具有创新意识的思路，具体提供哪些功能要在客户的需要和允许时限提供哪些功能要在客

15、户的需要和允许时限内的技术可行性之间求得平衡。内的技术可行性之间求得平衡。4.1.3 需求错误的原因需求错误的原因第四章软件需求分析与建模规格说明过于简单规格说明过于简单客户往往不明白需求分析的重要性，客户往往不明白需求分析的重要性，只是提供一份十分简略的规格说明，仅涉只是提供一份十分简略的规格说明，仅涉及产品概念上的内容，然后让开发人员在及产品概念上的内容，然后让开发人员在项目进展中去完善，从而导致开发人员先项目进展中去完善，从而导致开发人员先建立产品结构再完成需求说明。建立产品结构再完成需求说明。4.1.3 需求错误的原因需求错误的原因第四章软件需求分析与建模忽略了用户分类忽略了用户分类大

16、多数产品是由不同的人使用其不同大多数产品是由不同的人使用其不同的特性，使用频繁程度也有所差异，使用的特性，使用频繁程度也有所差异，使用者受教育程度和经验水平也不尽相同。如者受教育程度和经验水平也不尽相同。如果你不能在项目早期就针对所有这些主要果你不能在项目早期就针对所有这些主要用户进行分类的话，必然导致有的用户对用户进行分类的话，必然导致有的用户对产品感到失望。产品感到失望。4.1.3 需求错误的原因需求错误的原因第四章软件需求分析与建模总体来说，导致需求缺陷的原因主总体来说，导致需求缺陷的原因主要体现在三个方面：要体现在三个方面：u需求的沟通与理解需求的沟通与理解u需求的变化与控制需求的变化

17、与控制u需求说明的明确与完整需求说明的明确与完整 4.1.3 需求错误的原因需求错误的原因第四章软件需求分析与建模需求工程中的缺陷将给项目成功带需求工程中的缺陷将给项目成功带来极大风险，如产品的成本过高、产品来极大风险，如产品的成本过高、产品的功能和质量无法完全满足用户的期望的功能和质量无法完全满足用户的期望等等。即使一个项目团队的人员和配备等等。即使一个项目团队的人员和配备都很不错，但不重视需求过程也会付出都很不错，但不重视需求过程也会付出惨痛的代价。惨痛的代价。4.1.3 需求错误的原因需求错误的原因第四章软件需求分析与建模【本节知识点本节知识点】u需求工程的内容需求工程的内容u需求获取需

18、求获取u需求分析需求分析u编写需求文档编写需求文档u需求验证需求验证4.2 需求工程需求工程第四章软件需求分析与建模 需求工程是指应用已证实有效的原理和方需求工程是指应用已证实有效的原理和方法，系统地描述出待开发系统及其行为特征和法，系统地描述出待开发系统及其行为特征和相关约束。相关约束。通常，需求工程由一些过程组成，可分为通常，需求工程由一些过程组成，可分为需求开发需求开发和和需求管理需求管理两部分两部分;4.2 需求工程需求工程第四章软件需求分析与建模4.2 需求工程需求工程第四章软件需求分析与建模 需求开发又可分为问题需求开发又可分为问题获取获取、分析分析、编写编写规格说明规格说明和和验

19、证验证四个阶段，如图所示：四个阶段，如图所示：需求开发的主要活动需求开发的主要活动 u确定产品所期望的用户类；确定产品所期望的用户类；u获取每个用户类的需求；获取每个用户类的需求；u了解实际用户任务和目标以及这些任务了解实际用户任务和目标以及这些任务所支持的业务需求；所支持的业务需求；u分析源于用户的信息以区别用户任务需分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、求、功能需求、业务规则、质量属性、建议解决方法和附加信息；建议解决方法和附加信息；4.2.1 需求工程的内容需求工程的内容第四章软件需求分析与建模u将系统级的需求分为几个子系统，并将需求中将系统级的需求分为几个

20、子系统，并将需求中的一部份分配给软件组件；的一部份分配给软件组件；u了解相关质量属性的重要性；了解相关质量属性的重要性；u商讨实施优先级的划分；商讨实施优先级的划分；u将所收集的用户需求编写成规格说明和模型；将所收集的用户需求编写成规格说明和模型；u评审需求规格说明，确保对用户需求达到共同评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。前将问题都弄清楚。4.2.1 需求工程的内容需求工程的内容第四章软件需求分析与建模需求管理的主要活动需求管理的主要活动 u定义需求基线；定义需求基线；u评审提出的需求变更、

21、评估每项变更评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它；的可能影响从而决定是否实施它；u以一种可控制的方式将需求变更融入以一种可控制的方式将需求变更融入到项目中；到项目中；4.2.1 需求工程的内容需求工程的内容第四章软件需求分析与建模u使当前的项目计划与需求一致；使当前的项目计划与需求一致；u估计变更需求所产生影响并在此基础上估计变更需求所产生影响并在此基础上协商新的承诺；协商新的承诺；u让每项需求都能与其对应的设计、源代让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪；码和测试用例联系起来以实现跟踪；u在整个项目过程中跟踪需求状态及其变在整个项目过程中跟踪

22、需求状态及其变更情况。更情况。4.2.1 需求工程的内容需求工程的内容第四章软件需求分析与建模 今天，我们引入今天，我们引入 需求工程需求工程 的概念，的概念，强调用工程化的方法进行需求开发和需强调用工程化的方法进行需求开发和需求管理。其中，需求开发是采用有效方求管理。其中，需求开发是采用有效方法获得高质量需求的过程，而需求管理法获得高质量需求的过程，而需求管理则是在需求说明形成之后有效地控制其则是在需求说明形成之后有效地控制其变更的过程，二者缺一不可。变更的过程，二者缺一不可。4.2.1 需求工程的内容需求工程的内容第四章软件需求分析与建模一、工作内容一、工作内容 u聆听用户的需求聆听用户的

23、需求u分析和整理所获取的信息分析和整理所获取的信息u形成文档化的描述形成文档化的描述4.2.2 需求获取需求获取 第四章软件需求分析与建模分析人员应该与各种层次的客户进行充分析人员应该与各种层次的客户进行充分的交流和沟通，包括决策领导、使用部门分的交流和沟通，包括决策领导、使用部门的领导、具体使用人员、系统维护人员等，的领导、具体使用人员、系统维护人员等，尽量清楚地理解用户的问题和要求。尽量清楚地理解用户的问题和要求。对于用户提供的各种问题和要求，分析人员需要对于用户提供的各种问题和要求，分析人员需要对其进行归纳和整理，借助一些工具和方法，从用户对其进行归纳和整理，借助一些工具和方法，从用户一

24、般性的陈述里面提取用户的真正需求，并由此确定一般性的陈述里面提取用户的真正需求，并由此确定软件的功能、性能、接口关系、约束条件等。软件的功能、性能、接口关系、约束条件等。不论是用户的提出问题，还是最终获取的不论是用户的提出问题，还是最终获取的需求，都应该形成文档化的描述，这种描述需需求，都应该形成文档化的描述，这种描述需要各种人员的一致理解和认同。要各种人员的一致理解和认同。二、基于用例的方法二、基于用例的方法随着面向对象技术的发展，基于用例随着面向对象技术的发展，基于用例的方法在需求获取和建模方面应用得越来的方法在需求获取和建模方面应用得越来越普遍。这种方法是以任务为中心和以用越普遍。这种方

25、法是以任务为中心和以用户为中心的，比起使用以功能为中心的方户为中心的，比起使用以功能为中心的方法，它可以使用户更清楚地认识到新系统法，它可以使用户更清楚地认识到新系统允许他们做什么。允许他们做什么。4.2.2 需求获取需求获取 第四章软件需求分析与建模用例模型以用户和任务为中心，将整个工用例模型以用户和任务为中心，将整个工作的焦点集中在从用户的角度说明系统能够干作的焦点集中在从用户的角度说明系统能够干什么，完全不考虑具体的实现细节，从而达到什么，完全不考虑具体的实现细节，从而达到准确地理解客户需求的目的。在用例模型中，准确地理解客户需求的目的。在用例模型中，角色和用例是两个基本概念，分别代表着

26、系统角色和用例是两个基本概念，分别代表着系统外部的执行者和系统应包含的功能，因此，建外部的执行者和系统应包含的功能，因此，建立用例模型的主要工作是确定角色、确定用例立用例模型的主要工作是确定角色、确定用例和描述用例。和描述用例。4.2.2 需求获取需求获取 第四章软件需求分析与建模A、确定角色、确定角色角色代表着与系统交互的人或事。通角色代表着与系统交互的人或事。通过确认系统功能使用者和维护者以及与系过确认系统功能使用者和维护者以及与系统接口的其他系统或硬件设备等，可以有统接口的其他系统或硬件设备等，可以有效地识别出系统角色。效地识别出系统角色。4.2.2 需求获取需求获取 第四章软件需求分析

27、与建模B、确定用例、确定用例一个完整的系统包含若干个用例，每一个完整的系统包含若干个用例，每个用例具体说明应完成的功能。识别用例个用例具体说明应完成的功能。识别用例首先要确定系统所能反映的外部事件，并首先要确定系统所能反映的外部事件，并把这些事件与参与的执行者和特定的使用把这些事件与参与的执行者和特定的使用实例联系起来，最终绘制出用例图。实例联系起来，最终绘制出用例图。4.2.2 需求获取需求获取 第四章软件需求分析与建模C、描述用例、描述用例单纯地使用用例图不能提供用例所具单纯地使用用例图不能提供用例所具有的全部信息，因此，需要使用文字描述有的全部信息，因此，需要使用文字描述那些不能反映在图

28、形上的信息。用例描述那些不能反映在图形上的信息。用例描述实际上是关于角色与系统如何交互的规格实际上是关于角色与系统如何交互的规格说明，要求清晰明确，没有二义性。说明，要求清晰明确，没有二义性。4.2.2 需求获取需求获取 第四章软件需求分析与建模建立用例模型是一种需求获取的有效方建立用例模型是一种需求获取的有效方法，其简洁清晰的描述方式容易被软件人员法，其简洁清晰的描述方式容易被软件人员和用户共同理解和接受。这种方法已经在许和用户共同理解和接受。这种方法已经在许多大型系统的开发中取得成效，实践证明它多大型系统的开发中取得成效，实践证明它能有效地解决用户参与的问题。能有效地解决用户参与的问题。4

29、.2.2 需求获取需求获取 第四章软件需求分析与建模需求分析主要是对收集到的需求进行提需求分析主要是对收集到的需求进行提炼、分析和仔细审查，以确保所有的风险承炼、分析和仔细审查，以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏担者都明白其含义并找出其中的错误、遗漏或其它不足的地方，形成完整的分析模型。或其它不足的地方，形成完整的分析模型。分析的目的在于开发出高质量的和具体的需分析的目的在于开发出高质量的和具体的需求，从而支持项目的估算和软件的设计、开求，从而支持项目的估算和软件的设计、开发和测试。发和测试。4.2.3 需求分析需求分析第四章软件需求分析与建模需求分析的主要活动包括：需求

30、分析的主要活动包括：u绘制系统关联图绘制系统关联图u创建用户接口原型创建用户接口原型u分析需求可行性分析需求可行性u确定需求的优先级别确定需求的优先级别u创建数据字典创建数据字典u为需求建立模型为需求建立模型4.2.3 需求分析需求分析第四章软件需求分析与建模绘制系统关联图绘制系统关联图这种关联图用于定义系统与系这种关联图用于定义系统与系统外部实体间的界限和接口的简单统外部实体间的界限和接口的简单模型。模型。4.2.3 需求分析需求分析第四章软件需求分析与建模创建用户接口原型创建用户接口原型当开发人员或用户不能确定需求时，当开发人员或用户不能确定需求时，开发一个用户接口原型可以使许多概念和开发

31、一个用户接口原型可以使许多概念和可能发生的事更为直观明了，用户通过评可能发生的事更为直观明了，用户通过评价原型将使项目参与者能更好地相互理解价原型将使项目参与者能更好地相互理解所要解决的问题，同时找出需求文档与原所要解决的问题，同时找出需求文档与原型之间所有的冲突之处。型之间所有的冲突之处。4.2.3 需求分析需求分析第四章软件需求分析与建模分析需求可行性分析需求可行性在允许的成本和性能要求下，分在允许的成本和性能要求下，分析每项需求实施的可行性，明确与每析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其项需求实现相联系的风险，包括与其它需求的冲突、对外界因素的依赖和它需求的冲突

32、、对外界因素的依赖和技术障碍。技术障碍。4.2.3 需求分析需求分析第四章软件需求分析与建模确定需求的优先级别确定需求的优先级别应用分析方法来确定用例、产品特应用分析方法来确定用例、产品特性或单项需求实现的优先级别，以优先性或单项需求实现的优先级别，以优先级为基础确定产品版本将包括哪些特性级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。版本计划中作出需要的变更。4.2.3 需求分析需求分析第四章软件需求分析与建模为需求建立模型为需求建立模型需求的图

33、形分析模型是软件需求规格需求的图形分析模型是软件需求规格说明极好的补充说明，它们能提供不同的说明极好的补充说明，它们能提供不同的信息与关系以帮助找到不正确的、不一致信息与关系以帮助找到不正确的、不一致的、遗漏的和冗余的需求，这些模型包括的、遗漏的和冗余的需求，这些模型包括数据流图、实体关系图、状态变换图、对数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图等。话框图、对象类及交互作用图等。4.2.3 需求分析需求分析第四章软件需求分析与建模创建数据字典创建数据字典数据字典是对系统用到的所有数据项数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一和结构的定义，以确保

34、开发人员使用统一的数据定义。在需求阶段，数据字典至少的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。是使用一致的定义和术语。4.2.3 需求分析需求分析第四章软件需求分析与建模分析建模的方法有很多，其中最重要的两分析建模的方法有很多，其中最重要的两种方法是种方法是结构化分析结构化分析和和面向对象分析面向对象分析。结构化分析方法结构化分析方法提供提供实体关系图实体关系图、数据流数据流图图和和状态转换图状态转换图三种图形模型，分别进行数据三种图形模型，分别进行数据建模、功能建模和动态建模；建模、功能建模和动态建模；

35、4.2.3 需求分析需求分析第四章软件需求分析与建模人们习惯于用自然语言来描述软件需求，人们习惯于用自然语言来描述软件需求，但这会产生许多意想不到的问题，如不精确、但这会产生许多意想不到的问题，如不精确、二义性等。因此，需要采用适当的方法形成二义性等。因此，需要采用适当的方法形成一致的、完备的和无二义性的软件需求规格一致的、完备的和无二义性的软件需求规格说明。说明。4.2.4 编写需求文档编写需求文档第四章软件需求分析与建模通常，编写软件需求规格说明有三种方法：通常，编写软件需求规格说明有三种方法：u将结构化语言与自然语言结合，编写文本将结构化语言与自然语言结合，编写文本型文档；型文档；u建立

36、可视化的模型；建立可视化的模型；u采用形式化的方法进行需求规格说明。采用形式化的方法进行需求规格说明。4.2.4 编写需求文档编写需求文档第四章软件需求分析与建模软件需求规格说明是需求开发的最终软件需求规格说明是需求开发的最终结果，它精确地阐述一个软件系统必须提结果，它精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条供的功能和性能以及它所要考虑的限制条件。软件需求规格说明不仅是系统测试和件。软件需求规格说明不仅是系统测试和用户文档的基础，也是所有子系列项目规用户文档的基础，也是所有子系列项目规划、设计和编码的基础。划、设计和编码的基础。4.2.4.1 软件需求规格说明软件需求规

37、格说明 第四章软件需求分析与建模u软件需求规格说明是用户、分析人员和设计人员之软件需求规格说明是用户、分析人员和设计人员之间进行理解和交流的手段；间进行理解和交流的手段；u测试人员可以根据软件需求规格说明中对产品行为测试人员可以根据软件需求规格说明中对产品行为的描述，制定测试计划、测试用例和测试过程。的描述，制定测试计划、测试用例和测试过程。u文档人员根据软件需求规格说明和用户界面设计，文档人员根据软件需求规格说明和用户界面设计，编写用户手册等；编写用户手册等；u软件需求规格说明指导着整个系统的开发过程，评软件需求规格说明指导着整个系统的开发过程，评审过的需求规格说明需要进行变更控制。审过的需

38、求规格说明需要进行变更控制。4.2.4.1 软件需求规格说明软件需求规格说明 第四章软件需求分析与建模a.引言引言概要叙述软件需求规格说明，便于读者概要叙述软件需求规格说明，便于读者理解文档如何编写以及如何阅读和解释。理解文档如何编写以及如何阅读和解释。在软件项目中，开发组织应该采用一种在软件项目中，开发组织应该采用一种标准的软件需求规格说明的模板。现在有许标准的软件需求规格说明的模板。现在有许多软件需求规格说明模板可以使用，这里介多软件需求规格说明模板可以使用，这里介绍其中的一种。绍其中的一种。4.2.4.2 模板模板 第四章软件需求分析与建模a.1目的目的对产品进行定义，在该文档中详尽说明

39、对产品进行定义，在该文档中详尽说明了这个产品的软件需求，包括修正或发行版了这个产品的软件需求，包括修正或发行版本号。如果这个软件需求规格说明只与整个本号。如果这个软件需求规格说明只与整个系统的一部分有关系，那么就只定义文档中系统的一部分有关系，那么就只定义文档中说明的部分或子系统。说明的部分或子系统。4.2.4.2 模板模板 第四章软件需求分析与建模a.2文档约定文档约定描述编写文档时所采用的标准或排描述编写文档时所采用的标准或排版约定，包括正文风格、提示区或重要版约定，包括正文风格、提示区或重要符号。符号。4.2.4.2 模板模板 第四章软件需求分析与建模a.3预期的读者和阅读建议预期的读者

40、和阅读建议列举了软件需求规格说明所针对的列举了软件需求规格说明所针对的不同读者，例如开发人员、项目经理、不同读者，例如开发人员、项目经理、营销人员、用户、测试人员或文档的编营销人员、用户、测试人员或文档的编写人员。描述了文档中剩余部分的内容写人员。描述了文档中剩余部分的内容及其组织结构，提出了最适合于每一类及其组织结构，提出了最适合于每一类型读者阅读文档的建议。型读者阅读文档的建议。4.2.4.2 模板模板 第四章软件需求分析与建模a.4产品范围产品范围提供了对指定的软件及其目的的提供了对指定的软件及其目的的简短描述，包括利益和目标。简短描述，包括利益和目标。4.2.4.2 模板模板 第四章软

41、件需求分析与建模a.5参考文献参考文献列举了编写软件需求规格说明时所参考的资料列举了编写软件需求规格说明时所参考的资料或其它资源，可能包括用户界面风格指导、合同、或其它资源，可能包括用户界面风格指导、合同、标准、系统需求规格说明、使用实例文档，或相关标准、系统需求规格说明、使用实例文档，或相关产品的软件需求规格说明。在这里应该给出详细的产品的软件需求规格说明。在这里应该给出详细的信息，包括标题名称、作者、版本号、日期、出版信息，包括标题名称、作者、版本号、日期、出版单位或资料来源，以方便读者查阅这些文献。单位或资料来源，以方便读者查阅这些文献。4.2.4.2 模板模板 第四章软件需求分析与建模

42、b.综合描述综合描述这一部分概述了正在定义的产品以这一部分概述了正在定义的产品以及它所运行的环境、使用产品的用户和及它所运行的环境、使用产品的用户和已知的限制、假设和依赖。已知的限制、假设和依赖。4.2.4.2 模板模板 第四章软件需求分析与建模b.1产品的前景产品的前景描述了软件需求规格说明中所定义的产品的背景和描述了软件需求规格说明中所定义的产品的背景和起源。说明了该产品是否是产品系列中的下一成员，是起源。说明了该产品是否是产品系列中的下一成员，是否是成熟产品所改进的下一代产品、是否是现有应用程否是成熟产品所改进的下一代产品、是否是现有应用程序的替代品，或者是否是一个新型的、自含型产品。如

43、序的替代品，或者是否是一个新型的、自含型产品。如果软件需求规格说明定义了大系统的一个组成部分，那果软件需求规格说明定义了大系统的一个组成部分，那么就要说明这部分软件是怎样与整个系统相关联的，并么就要说明这部分软件是怎样与整个系统相关联的，并且要定义出两者之间的接口。且要定义出两者之间的接口。4.2.4.2 模板模板 第四章软件需求分析与建模b.2产品的功能产品的功能 概述了产品所具有的主要功能。其详细内容将在概述了产品所具有的主要功能。其详细内容将在d d中描述，所以在此只需要概略地总结，例如用列表中描述，所以在此只需要概略地总结，例如用列表的方法给出。很好地组织产品的功能，使每个读者的方法给

44、出。很好地组织产品的功能，使每个读者都易于理解。用图形表示主要的需求分组以及它们都易于理解。用图形表示主要的需求分组以及它们之间的联系，例如数据流程图的顶层图或类图，都之间的联系，例如数据流程图的顶层图或类图，都是有用的。是有用的。4.2.4.2 模板模板 第四章软件需求分析与建模b.3用户类和特征用户类和特征确定你觉得可能使用该产品的不同确定你觉得可能使用该产品的不同用户类并描述它们相关的特征。有一些用户类并描述它们相关的特征。有一些需求可能只与特定的用户类相关，将该需求可能只与特定的用户类相关，将该产品的重要用户类与那些不太重要的用产品的重要用户类与那些不太重要的用户类区分开。户类区分开。

45、4.2.4.2 模板模板 第四章软件需求分析与建模b.4运行环境运行环境描述了软件的运行环境，包括硬件描述了软件的运行环境，包括硬件平台、操作系统和版本，还有其它的软平台、操作系统和版本，还有其它的软件组件或与其共存的应用程序。件组件或与其共存的应用程序。4.2.4.2 模板模板 第四章软件需求分析与建模b.5设计和实现上的限制设计和实现上的限制确定影响开发人员自由选择的问确定影响开发人员自由选择的问题，并说明这些问题为什么成为一种题，并说明这些问题为什么成为一种限制。可能的限制包括如下内容：限制。可能的限制包括如下内容：4.2.4.2 模板模板 第四章软件需求分析与建模u必须使用或者避免的特

46、定技术、工具、编必须使用或者避免的特定技术、工具、编程语言和数据库。程语言和数据库。u所要求的开发规范或标准。所要求的开发规范或标准。u企业策略、政府法规或工业标准。企业策略、政府法规或工业标准。u硬件限制，例如定时需求或存储器限制。硬件限制，例如定时需求或存储器限制。u数据转换格式标准。数据转换格式标准。4.2.4.2 模板模板 第四章软件需求分析与建模b.6假设和依赖假设和依赖列举出在对软件需求规格说明中影列举出在对软件需求规格说明中影响需求陈述的假设因素，以及项目对外响需求陈述的假设因素，以及项目对外部因素存在的依赖。部因素存在的依赖。4.2.4.2 模板模板 第四章软件需求分析与建模c

47、.外部接口需求外部接口需求利用本节来确定可以保证新产品与外利用本节来确定可以保证新产品与外部组件正确连接的需求。部组件正确连接的需求。c.1用户界面用户界面陈述所需要的用户界面的软件组件。陈述所需要的用户界面的软件组件。描述每个用户界面的逻辑特征。以下是可描述每个用户界面的逻辑特征。以下是可能要包括的一些特征：能要包括的一些特征：4.2.4.2 模板模板 第四章软件需求分析与建模u将要采用的图形用户界面（将要采用的图形用户界面（GUI）标准）标准或产品系列的风格。或产品系列的风格。u屏幕布局或解决方案的限制。屏幕布局或解决方案的限制。u将出现在每个屏幕的标准按钮、功能或导将出现在每个屏幕的标准

48、按钮、功能或导航链接（例如一个帮助按钮）。航链接（例如一个帮助按钮）。u快捷键。快捷键。u错误信息显示标准。错误信息显示标准。4.2.4.2 模板模板 第四章软件需求分析与建模c.2硬件接口硬件接口描述系统中软件和硬件每一接口的描述系统中软件和硬件每一接口的特征。这种描述可能包括支持的硬件类特征。这种描述可能包括支持的硬件类型、软硬件之间交流的数据和控制信息型、软硬件之间交流的数据和控制信息的性质以及所使用的通信协议。的性质以及所使用的通信协议。4.2.4.2 模板模板 第四章软件需求分析与建模c.3软件接口软件接口描述该产品与其它外部组件（由名字和描述该产品与其它外部组件（由名字和版本识别）

49、的连接，包括数据库、操作系统、版本识别）的连接，包括数据库、操作系统、工具、库和集成的商业组件。明确并描述在工具、库和集成的商业组件。明确并描述在软件组件之间交换数据或消息的目的。描述软件组件之间交换数据或消息的目的。描述所需要的服务及内部组件通信的性质，确定所需要的服务及内部组件通信的性质，确定将在组件之间共享的数据。将在组件之间共享的数据。4.2.4.2 模板模板 第四章软件需求分析与建模c.4通信接口通信接口描述与产品所使用的通信功能相关的需描述与产品所使用的通信功能相关的需求，包括电子邮件、求，包括电子邮件、Web浏览器、网络通浏览器、网络通信标准或协议及电子表格等等。定义了相关信标准

50、或协议及电子表格等等。定义了相关的消息格式，规定通信安全或加密问题、数的消息格式，规定通信安全或加密问题、数据传输速率和同步通信机制。据传输速率和同步通信机制。4.2.4.2 模板模板 第四章软件需求分析与建模d.系统特性系统特性d.1说明和优先级说明和优先级简短说明该系统的特性，并指出该特性简短说明该系统的特性，并指出该特性的优先级是高、中，还是低。另外，还可以的优先级是高、中，还是低。另外，还可以包括对特定优先级部分的评价，例如利益、包括对特定优先级部分的评价，例如利益、损失、费用和风险。损失、费用和风险。4.2.4.2 模板模板 第四章软件需求分析与建模d.2激励激励/响应序列响应序列列