第三章 软件需求分析基础.ppt

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

1、第三章第三章 软件需求分析基础软件需求分析基础 主要内容n需求分析的概念和原则需求分析的概念和原则 n传统的软件需求分析基础传统的软件需求分析基础 3.1 需求分析的概念和原则需求分析的概念和原则 n需求分析的基本任务是准确地回答需求分析的基本任务是准确地回答“系统必须做什么系统必须做什么？”这一核心问题。这一核心问题。n需求分析是发现、求精、建模和规约的过程。这一过需求分析是发现、求精、建模和规约的过程。这一过程包括：详细精化最初由系统分析员建立在软件项目程包括：详细精化最初由系统分析员建立在软件项目计划中确定的软件范围，创建所需数据流、控制流以计划中确定的软件范围，创建所需数据流、控制流以

2、及操作行为的模型，在此基础上选择解决方案。及操作行为的模型，在此基础上选择解决方案。问题定义阶段n在需求分析之前，需要描述和定义问题。问题在需求分析之前，需要描述和定义问题。问题定义阶段必须回答的关键问题是定义阶段必须回答的关键问题是“要解决的问要解决的问题是什么题是什么”。n系统分析员扼要地写出对问题的理解，提出关系统分析员扼要地写出对问题的理解，提出关于问题性质、工程目标和规模的书面报告，最于问题性质、工程目标和规模的书面报告，最后得出使用户和使用部门负责人都满意的文档。后得出使用户和使用部门负责人都满意的文档。n问题定义阶段是软件生存周期中最简短的阶段，问题定义阶段是软件生存周期中最简短

3、的阶段，一般只需要一天甚至更少的时间。一般只需要一天甚至更少的时间。可行性研究阶段 n这个阶段要回答的关键问题是这个阶段要回答的关键问题是“对于上一个阶对于上一个阶段所确定的问题有行得通的解决办法吗？段所确定的问题有行得通的解决办法吗？”n系统分析员需要进行一次大大压缩和简化了的系统分析员需要进行一次大大压缩和简化了的系统分析和设计的过程系统分析和设计的过程。n只有当投资取得较大效益时，该工程项目才值只有当投资取得较大效益时，该工程项目才值得继续进行下去。得继续进行下去。n系统分析员得出该工程项目不值得做的结论，系统分析员得出该工程项目不值得做的结论，应该及时中止投资该工程项目，避免更大的浪应

4、该及时中止投资该工程项目，避免更大的浪费。费。可行性研究n问题识别问题识别n市场调查市场调查n分析准备分析准备n环境分析环境分析n物理分析物理分析n功能分析功能分析n信息分析信息分析n动态分析动态分析n确立系统方案，确立系统方案，作出各种估算作出各种估算n模型评审模型评审问题的初步认识n了解系统应解决的问题，这些问题了解系统应解决的问题，这些问题是如何提出的是如何提出的n设想这些问题如何解决才能满足要设想这些问题如何解决才能满足要求求n了解问题的结构了解问题的结构市场调查n了解市场对待开发软件的需求情况了解市场对待开发软件的需求情况n调查市场上已有的类似软件系统的功能、调查市场上已有的类似软件

5、系统的功能、性能、价格情况性能、价格情况分析准备n确立分析计划确立分析计划n规定由谁参加分析作业，任务分配规定由谁参加分析作业，任务分配n对参加分析的人员进行必要的培训对参加分析的人员进行必要的培训环境分析明确系统的目的和限制条件明确系统的目的和限制条件n使用单位的状况、经营方针和组织机构使用单位的状况、经营方针和组织机构n使用单位的计算机利用情况使用单位的计算机利用情况n相关的硬件、软件及其它接口部分相关的硬件、软件及其它接口部分n用户的操作环境及操作要求用户的操作环境及操作要求n习惯、法律、制度上对软件的制约习惯、法律、制度上对软件的制约n开发能具备的技术条件和设备条件开发能具备的技术条件

6、和设备条件物理分析n了解实际业务活动状况，特别对一些活了解实际业务活动状况，特别对一些活动要点进行分析动要点进行分析n明确在这些要点之间什么东西在流动，明确在这些要点之间什么东西在流动，如何进行流动如何进行流动n对物理流量进行分析对物理流量进行分析n对其模型化，得到实际业务系统（当前对其模型化，得到实际业务系统（当前系统）的物理模型系统）的物理模型功能分析功能分析n决定系统应具备的功能决定系统应具备的功能(工作域工作域)n分析功能的结构：功能展开和功能分配分析功能的结构：功能展开和功能分配n分析各功能之间的关系，整理它们之间分析各功能之间的关系，整理它们之间传递的信息传递的信息n利用数据流图，

7、描述信息在系统流动与利用数据流图，描述信息在系统流动与处理的情况处理的情况信息分析n调查系统的输入、输出、保存信息调查系统的输入、输出、保存信息n明确信息的结构及各信息之间的关系明确信息的结构及各信息之间的关系n调查各信息的信息量调查各信息的信息量n调查各种报表和文件的格式调查各种报表和文件的格式n建立粗略的数据词典，定义系统中使用建立粗略的数据词典，定义系统中使用的数据的数据动态分析n系统内每一部分有几种状态系统内每一部分有几种状态n各种状态转换的条件各种状态转换的条件n同步产生的条件与同步后状态的变化同步产生的条件与同步后状态的变化确立系统方案，进行各种估算n粗略地估算成本粗略地估算成本n

8、估算可能取得的效益估算可能取得的效益n提出可能需要的资源，包括人员、硬件、提出可能需要的资源，包括人员、硬件、软件等软件等n提出大概的进度安排提出大概的进度安排模型评审n将目标系统的逻辑模型提出管理部分与将目标系统的逻辑模型提出管理部分与用户进行评审用户进行评审n复查问题定义、工程规模和系统目标复查问题定义、工程规模和系统目标系统建模n为了开发系统模型，可通过构造模型进一步分析系为了开发系统模型，可通过构造模型进一步分析系统统。n可以用系统流程图，数据流图和数据字典。可以用系统流程图，数据流图和数据字典。3.1.1 需求分析需求分析 n需求分析需求分析是一种软件工程活动，使得系统分析是一种软件

9、工程活动，使得系统分析员能够刻划出软件的功能和性能、指明软件和员能够刻划出软件的功能和性能、指明软件和其他系统元素的接口、并建立软件必须满足的其他系统元素的接口、并建立软件必须满足的约束。约束。n需求分析是软件设计师进行软件分解的基础，需求分析是软件设计师进行软件分解的基础，需求分析建造了软件处理的需求分析建造了软件处理的数据模型数据模型、功能模功能模型型和和行为模型行为模型。n需求规约为软件设计师和客户提供了软件建造需求规约为软件设计师和客户提供了软件建造完后，进行质量评估的依据。完后，进行质量评估的依据。1.软件需求的概念和分类软件需求的概念和分类 n比比较较权权威威的的需需求求的的定定义

10、义来来自自于于IEEE软软件件工工程程标标准准词词汇汇表中的定义：表中的定义：nl l用户解决问题或达到目标所需要的条件。用户解决问题或达到目标所需要的条件。nl l系系统统或或系系统统部部件件要要满满足足合合同同、标标准准、规规范范或或其其他他正式规定的文档所要具有的条件。正式规定的文档所要具有的条件。nl l反映上面两条的文档说明。反映上面两条的文档说明。n需求一方面反映了系统的外部行为，另一方面反映了需求一方面反映了系统的外部行为，另一方面反映了系统的内部特性，反映的方式是系统的内部特性，反映的方式是需求文档需求文档。n比较通俗的需求定义如下比较通俗的需求定义如下：需求是指明系统必须实现

11、：需求是指明系统必须实现什么的规格说明，它描述了系统的行为、特性或属性，什么的规格说明，它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。是在开发过程中对系统的约束。需求的类别 n功能需求：功能需求：指定系统必须提供的服务，通过需指定系统必须提供的服务，通过需求分析应该划分出系统必须完成的所有功能；求分析应该划分出系统必须完成的所有功能；n性能需求：性能需求：指定系统必须满足的定时约束或容指定系统必须满足的定时约束或容量约束，通常包括速度（响应时间）、信息量量约束，通常包括速度（响应时间）、信息量速率、主存容量、磁盘容量、安全性等方面的速率、主存容量、磁盘容量、安全性等方面的需求；需

12、求；n可靠性和可用性需求：可靠性和可用性需求：定量地指定系统的可靠定量地指定系统的可靠性与可用性；性与可用性；n出错处理需求：出错处理需求：说明系统对环境错误应该怎样说明系统对环境错误应该怎样响应；响应；n接口需求：接口需求：描述应用系统与其环境通信的格式，描述应用系统与其环境通信的格式，常见的接口需求有用户接口需求、硬件接口需常见的接口需求有用户接口需求、硬件接口需求、软件接口需求和通信接口需求；求、软件接口需求和通信接口需求；n约束：约束：描述了应用系统应遵守的限制条件，常描述了应用系统应遵守的限制条件，常见的约束有：精度约束、工具和语言约束、设见的约束有：精度约束、工具和语言约束、设计约

13、束、应该使用的标准、应该使用的硬件平计约束、应该使用的标准、应该使用的硬件平台等；台等；n逆向需求：逆向需求：说明软件系统不应该做什么。理论说明软件系统不应该做什么。理论上有无限多个逆向需求，我们应该仅选取能澄上有无限多个逆向需求，我们应该仅选取能澄清真实需求且可消除发生误解的那些逆向需求；清真实需求且可消除发生误解的那些逆向需求；n将来可能提出的要求：将来可能提出的要求：应该明确地列出那些虽应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。很可能会提出来的要求。另一种分类n功能性需求功能性需求n产品的范围产品的范围n功能

14、与数据需求功能与数据需求n非功能性需求非功能性需求n观感需求观感需求n易用性易用性n性能性能n限制条件限制条件n 操作需求操作需求n 可维护性和可以执行需求可维护性和可以执行需求n 安全性需求安全性需求n 文化与政策文化与政策n法律需求法律需求需求的质量n完整性完整性n正确性正确性n可行性可行性n必要性必要性n划分优先级划分优先级n无二义性无二义性n可验证性可验证性n设计无关性设计无关性2.需求分析的任务需求分析的任务 n需求分析的任务需求分析的任务是借助于当前系统的物理模型是借助于当前系统的物理模型导出目标系统的逻辑模型，解决目标系统导出目标系统的逻辑模型，解决目标系统“做做什么什么”的问题

15、。的问题。n所要做的工作是深入描述软件的所要做的工作是深入描述软件的功能和性能功能和性能，确定软件设计的限制和软件同其他系统元素的确定软件设计的限制和软件同其他系统元素的接口细节，定义软件的其他有效性需求。接口细节，定义软件的其他有效性需求。n必须全面理解用户的各项要求，但只能接受合必须全面理解用户的各项要求，但只能接受合理的要求。理的要求。n要将软件的需求准确地表达出来，形成要将软件的需求准确地表达出来，形成软件需软件需求说明书求说明书。目标系统目标系统当前系统当前系统物理模型物理模型逻辑模型逻辑模型模型化抽象化物理模型物理模型逻辑模型逻辑模型具体化实例化理理解解需需求求表表达达需需求求导出

16、怎么做怎么做做什么做什么需求分析的任务需求分析的任务 n获得当前系统的物理模型获得当前系统的物理模型：首先，分析、理解：首先，分析、理解当前系统是如何运行的，并用一个具体的模型来当前系统是如何运行的，并用一个具体的模型来反映自己对当前系统的理解。反映自己对当前系统的理解。n 抽象出当前系统的逻辑模型：抽象出当前系统的逻辑模型：在理解当前系统在理解当前系统“怎样做怎样做”的基础上，取出非本质因素，抽取出的基础上，取出非本质因素，抽取出“做什么做什么”的本质。的本质。n建立目标系统的逻辑模型：建立目标系统的逻辑模型：分析目标系统与当分析目标系统与当前系统逻辑上的差别，明确目标系统要前系统逻辑上的差

17、别，明确目标系统要“做什么做什么”，从而从当前系统的逻辑模型中，导出目标系，从而从当前系统的逻辑模型中，导出目标系统的逻辑模型。统的逻辑模型。n 对目标系统逻辑模型进行补充：对目标系统逻辑模型进行补充：具体内容如具体内容如用户界面、启动和结束、出错处理、系统输入输用户界面、启动和结束、出错处理、系统输入输出、系统性能、其他限制等等。出、系统性能、其他限制等等。3需求分析的主要工作需求分析的主要工作 n软件需求分析可被划分成软件需求分析可被划分成5个工作阶段：问题分个工作阶段：问题分析；问题评估和方案综合；建模；规约；复审。析；问题评估和方案综合；建模；规约；复审。n例1.汽车零件的主要供应商需

18、要一个库存控制汽车零件的主要供应商需要一个库存控制系统，系统分析员发现与当前的手工系统相关系统，系统分析员发现与当前的手工系统相关的问题包括：（的问题包括：（1）不能快速地获得部件的状况；）不能快速地获得部件的状况；（2）更新卡片文件需要）更新卡片文件需要2至或至或3天的工作量；天的工作量；（3）由于没有办法查找相关厂商的部件信息，）由于没有办法查找相关厂商的部件信息，而使得对同一厂商同一货品多次再订货，等等。而使得对同一厂商同一货品多次再订货，等等。一旦问题被标识出来，系统分析员将确定新系一旦问题被标识出来，系统分析员将确定新系统该产生什么信息，以及将提供什么信息。统该产生什么信息，以及将提

19、供什么信息。n例2.客户希望得到指明什么零件从库存中取出、客户希望得到指明什么零件从库存中取出、以及还剩余多少相似零件的日报表。客户指明以及还剩余多少相似零件的日报表。客户指明一旦当该零件离开仓库时库存管理员就该记载一旦当该零件离开仓库时库存管理员就该记载每个零件的标号。通过对当前问题和希望的信每个零件的标号。通过对当前问题和希望的信息（输入和输出）进行的评估，系统分析员开息（输入和输出）进行的评估，系统分析员开始综合一个或多个解决方案。为了便于开始，始综合一个或多个解决方案。为了便于开始，必须详细地定义系统的数据、处理功能和行为。必须详细地定义系统的数据、处理功能和行为。n例3.在例在例1与

20、例与例2的基础上，一些可以进一步的基础上，一些可以进一步思考内容是，一旦已经建立这些信息，就该考思考内容是，一旦已经建立这些信息，就该考虑针对实现的基本体系结构，那么客户虑针对实现的基本体系结构，那么客户/服务服务器方法似乎是合适的，但是它确实属于软件计器方法似乎是合适的，但是它确实属于软件计划的范围吗？似乎需要一个数据库管理系统，划的范围吗？似乎需要一个数据库管理系统，但是，该数据库系统真的是用户需要的吗？继但是，该数据库系统真的是用户需要的吗？继续这种评估和综合的过程，直至分析员和客户续这种评估和综合的过程，直至分析员和客户均确信针对后面的开发步骤软件确实已被适当均确信针对后面的开发步骤软

21、件确实已被适当地刻划了。地刻划了。n在整个评估和综合过程中，分析员的主要焦点在整个评估和综合过程中，分析员的主要焦点是是“做什么做什么”，而不是，而不是“怎么做怎么做”，即应该思，即应该思考的是：系统会产生和使用什么数据？系统必考的是：系统会产生和使用什么数据？系统必须完成什么功能？将定义什么界面？会应用什须完成什么功能？将定义什么界面？会应用什么约束？么约束？n在问题评估和综合解决方案的活动中，系统分在问题评估和综合解决方案的活动中，系统分析员创建系统模型，以便可以更好地理解数据析员创建系统模型，以便可以更好地理解数据流和控制流、处理功能和操作行为以及信息内流和控制流、处理功能和操作行为以及

22、信息内容。容。4.系统分析员的主要能力系统分析员的主要能力 n在整个系统分析活动中，系统分析员起着关键在整个系统分析活动中，系统分析员起着关键的作用，其本人应该具备突出的能力，如：的作用，其本人应该具备突出的能力，如：n能掌握抽象概念，能对其进行分类，能从中综合能掌握抽象概念，能对其进行分类，能从中综合出解的能力；出解的能力；n能从冲突或者混淆中吸取恰当事实的能力；能从冲突或者混淆中吸取恰当事实的能力；n能弄清用户环境的能力；能弄清用户环境的能力；n能为用户系统恰当配置软硬件的能力能为用户系统恰当配置软硬件的能力n能较好地用书面和口头形式进行沟通的能力能较好地用书面和口头形式进行沟通的能力n有

23、有“从树木见森林从树木见森林”的能力。的能力。3.1.2 需求获取需求获取 n软件需求分析中需要很好的的相互沟通，沟通软件需求分析中需要很好的的相互沟通，沟通总是要在两方或多方间进行。总是要在两方或多方间进行。n客户和系统分析员之间最常用的交流方式，是客户和系统分析员之间最常用的交流方式，是通过通过预备会议预备会议或或访谈访谈进行的。进行的。n获取用户需求的主要方法是调查研究。获取用户需求的主要方法是调查研究。n做好准备做好准备n制定调研计划制定调研计划n准备调研资料准备调研资料n访谈用户访谈用户n写调研报告写调研报告n评审评审n系统分析员所问的第一组问题可以关注客户、系统分析员所问的第一组问

24、题可以关注客户、整体目标和收益，例如：谁是本工作的最初请整体目标和收益，例如：谁是本工作的最初请求者？谁将使用该解决方案？成功的解决方案求者？谁将使用该解决方案？成功的解决方案的经济收益是什么？的经济收益是什么？n接下来的下一组问题使得系统分析员能够对问接下来的下一组问题使得系统分析员能够对问题做更好的理解，使得客户能够表达其关于解题做更好的理解，使得客户能够表达其关于解决方案的感觉，决方案的感觉，n最后一组问题关注于会议的效果。例如：你是最后一组问题关注于会议的效果。例如：你是回答这些问题的合适人员吗？你的回答是回答这些问题的合适人员吗？你的回答是“正正式的式的”吗？其他人员可以提供附加信息

25、吗？有吗？其他人员可以提供附加信息吗？有其他我应该问你的问题吗？其他我应该问你的问题吗？3.1.3分析原则分析原则 n在过去在过去20年，研究者已经开发出一些实用分析方年，研究者已经开发出一些实用分析方法及相应的建模符号，每种分析方法有独特的观法及相应的建模符号，每种分析方法有独特的观点，然而，所有分析方法都遵循以下操作原则：点，然而，所有分析方法都遵循以下操作原则：n必须表示可理解的问题信息域。必须表示可理解的问题信息域。n必须定义软件将完成的功能。必须定义软件将完成的功能。n必须表示软件的行为（作为外部事件的结果）。必须表示软件的行为（作为外部事件的结果）。n必须划分描述信息、功能和行为的

26、模型，从而能以必须划分描述信息、功能和行为的模型，从而能以层次的方式揭示细节。层次的方式揭示细节。n分析过程应该从要素信息移向细节实现。分析过程应该从要素信息移向细节实现。n除了上面提到的操作性分析原则，除了上面提到的操作性分析原则，Davis提出提出了一组针对需求工程的指导性原则：了一组针对需求工程的指导性原则：n在开始建立分析模型前，先充分理解问题。在开始建立分析模型前，先充分理解问题。n开发原型，使得用户能够了解如何进行人机交互。开发原型，使得用户能够了解如何进行人机交互。n记录每个需求的起源及原因。记录每个需求的起源及原因。n使用多个需求视图。建立数据、功能和行为模型，使用多个需求视图

27、。建立数据、功能和行为模型，为软件工程师提供三种不同的视图。为软件工程师提供三种不同的视图。n给需求赋予优先级。给需求赋予优先级。n努力删除歧义性。努力删除歧义性。1.信息域信息域 n所有的应用软件均可称为所有的应用软件均可称为数据处理系统数据处理系统。n信息流表示了数据和控制在系统中流动时的变信息流表示了数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息（数据和化方式，输入对象被变换为中间信息（数据和/或控制），这些信息被进一步变换为输出或控制），这些信息被进一步变换为输出n数据的变换是程序必须完成的功能或子功能，数据的变换是程序必须完成的功能或子功能，在两个变换（功能）间流动的数

28、据和控制定义在两个变换（功能）间流动的数据和控制定义了每个功能的接口。了每个功能的接口。n信息结构表示了各种数据和控制项的内部组织，信息结构表示了各种数据和控制项的内部组织，2.建模建模 n我们创建模型，以获得对将要建造的实际实体我们创建模型，以获得对将要建造的实际实体有更好的理解。有更好的理解。n要对软件变换的信息进行建模、对变换发生的要对软件变换的信息进行建模、对变换发生的功能（和子功能）进行建模、以及对变换发生功能（和子功能）进行建模、以及对变换发生时的系统行为进行建模。时的系统行为进行建模。n在软件需求分析阶段，我们创建系统模型，这在软件需求分析阶段，我们创建系统模型，这些模型着重于描

29、述系统必须做什么而不是如何些模型着重于描述系统必须做什么而不是如何去做。去做。n我们常使用图形符号创建模型。我们常使用图形符号创建模型。n功能模型：功能模型：记录软件的变换信息，为了达到此记录软件的变换信息，为了达到此目标必须至少完成三个常见功能：输入、处理目标必须至少完成三个常见功能：输入、处理和输出。和输出。n行为模型：行为模型：大多数软件对来自外界的事件做出大多数软件对来自外界的事件做出反应，这种刺激反应，这种刺激-反应特征构成了行为模型的反应特征构成了行为模型的基础。行为模型创建了软件状态的表示，以及基础。行为模型创建了软件状态的表示，以及导致软件状态变化的事件表示。导致软件状态变化的

30、事件表示。需求分析阶段创建模型的作用n模型帮助分析员理解系统的信息、功能和行为，模型帮助分析员理解系统的信息、功能和行为，因此，使得需求分析任务更容易实现。因此，使得需求分析任务更容易实现。n模型变成了复审的焦点，因此，也成为确定规模型变成了复审的焦点，因此，也成为确定规约的完整性、一致性和精确性的重要依据。约的完整性、一致性和精确性的重要依据。n模型变成了设计的基础，为设计者提供了软件模型变成了设计的基础，为设计者提供了软件要素的表示视图，该表示可被转化到实现中去。要素的表示视图，该表示可被转化到实现中去。3.划分划分 n实际的问题经常太大而且复杂难于进行整体理实际的问题经常太大而且复杂难于

31、进行整体理解，我们往往将这样的问题划分为易于理解的解，我们往往将这样的问题划分为易于理解的子问题，并建立各子问题间的接口，以便完成子问题，并建立各子问题间的接口，以便完成整个功能。整个功能。n第四条操作性分析原则第四条操作性分析原则建议划分软件的信息、建议划分软件的信息、功能和行为域功能和行为域。需求分析阶段的文档需求分析阶段的文档n软件需求说明书软件需求说明书n初步的用户手册初步的用户手册n修改、完善与确定软件开发实施计划修改、完善与确定软件开发实施计划3.1.4 需求规格说明需求规格说明 n软件需求规格说明软件需求规格说明是分析任务的是分析任务的最终产物最终产物，美，美国国家标准局、国国家

32、标准局、IEEE（标准号标准号8301984）以及美国防部门均已提出了软件需求规约（以以及美国防部门均已提出了软件需求规约（以及其他软件工程文档）的候选格式。及其他软件工程文档）的候选格式。n软件需求规格说明必须正确地定义所有的软件软件需求规格说明必须正确地定义所有的软件需求；除了设计上的特殊限制之外，软件需求需求；除了设计上的特殊限制之外，软件需求规格说明中一般不描述任何设计、验证或项目规格说明中一般不描述任何设计、验证或项目管理的细节。管理的细节。需求必须描述的基本问题n功能功能所设计的软件要做什么；所设计的软件要做什么；n性能性能软件功能在执行过程中的速度、可使软件功能在执行过程中的速度

33、、可使用性、响应时间、各种软件功能的恢复时间、用性、响应时间、各种软件功能的恢复时间、吞吐能力、精度、频率等等；吞吐能力、精度、频率等等；n强加给实现的设计限制强加给实现的设计限制在效果、实现的语在效果、实现的语言、数据库完整性、资源限制、操作环境等等言、数据库完整性、资源限制、操作环境等等方面所要求的标准；方面所要求的标准；n属性属性可移植性、正确性、可维护性及安全可移植性、正确性、可维护性及安全性等方面的考虑因素；性等方面的考虑因素；n外部接口外部接口与人、硬件、其他软件和其他硬与人、硬件、其他软件和其他硬件的相互关系。件的相互关系。软件需求规格说明的大纲 1 前言 1.1 目的 1.2

34、范围 1.3 定义、缩写词、略语 1.4 参考资料2 项目概述 2.1 产品描述 2.2 产品功能2.3 用户特点 2.4 一般约束2.5 假设和依据 3 具体需求 3.1 功能需求 3.1.1 功能需求13.1.1.1 引言3.1.1.2 输入3.1.1.3 加工3.1.1.4 输出 3.1.2 功能需求2 3.1.n 功能需求n 3.2 外部接口需求 3.2.1 用户接口 3.2.2 硬件接口3.2.3 软件接口3.2.4 通信接口3.3 性能需求 3.4 设计约束 3.4.1 其他标准的约束 3.4.2 硬件的限制 3.5 属性3.5.1 安全性3.5.2 可维护性 3.6 其他需求 3

35、.6.1 数据库 3.6.2 操作 3.6.3 场合适应性 附录索引 3.1.5 评审评审 n需求审查是需求分析阶段工作的最后一步，是由需求审查是需求分析阶段工作的最后一步，是由软件软件工程师和客户一起进行并完成的。软件软件工程师和客户一起进行并完成的。n目的是发现软件需求规格说明中的目的是发现软件需求规格说明中的错误、二义性错误、二义性和遗漏的需求和遗漏的需求。n 复审首先在宏观的级别上进行，复审者试图保复审首先在宏观的级别上进行，复审者试图保证软件需求规格说明是完整的、一致的、精确的。证软件需求规格说明是完整的、一致的、精确的。例如提出以下问题：叙述的软件目标与系统的目例如提出以下问题：叙

36、述的软件目标与系统的目标是否保持一致？图是否清楚？每个图可以没有标是否保持一致？图是否清楚？每个图可以没有文字补充而单独存在吗？是否考虑过开发的技术文字补充而单独存在吗？是否考虑过开发的技术风险？是否存在不一致性、是否信息被忽略或存风险？是否存在不一致性、是否信息被忽略或存在冗余？和客户全面接触过吗？在冗余？和客户全面接触过吗？n然后复审会更详细，关注软件需求规格说明中的措词。然后复审会更详细，关注软件需求规格说明中的措词。例如例如：n着重于说服性的连接词（例如，当然、因此、明确地、着重于说服性的连接词（例如，当然、因此、明确地、显然地、紧随的），并问显然地、紧随的），并问“为什么为什么”。n

37、观察含糊的术语（例如，一些、有时、经常、通常、观察含糊的术语（例如，一些、有时、经常、通常、一般地、大多数、大多数的），并进行澄清。一般地、大多数、大多数的），并进行澄清。n当给出了不完整的列表时，确定已理解了所有的项。当给出了不完整的列表时，确定已理解了所有的项。关键是查找关键是查找“等等、如此这样等等、如此这样”。n小心含糊的动词如小心含糊的动词如“处理、拒绝、处制、跳过、限制处理、拒绝、处制、跳过、限制”等，它们可以以很多方式来解释。等，它们可以以很多方式来解释。n小心含糊的代词（例如，小心含糊的代词（例如，I/O模块与数据校验模块通模块与数据校验模块通信，且设置它的控制标志，那么标志是

38、谁的？）信，且设置它的控制标志，那么标志是谁的？）n等等。等等。3.2传统的软件需求分析基础传统的软件需求分析基础 n结构化的分析方法结构化的分析方法是最经典的需求分析方法。适是最经典的需求分析方法。适用于数据处理类型软件的需求分析。用于数据处理类型软件的需求分析。n它提供的工具包括：数据流图、数据字典、结构它提供的工具包括：数据流图、数据字典、结构化英语、判定表和判定树。化英语、判定表和判定树。n系统的分析模型必须达到三个主要目标：系统的分析模型必须达到三个主要目标：n（1）描述客户的需要；）描述客户的需要；n（2）建立创建软件设计的基础；）建立创建软件设计的基础；n（3）定义在软件完成后可

39、以被确认的一组需求。）定义在软件完成后可以被确认的一组需求。实体实体关系图关系图状态迁移图数据流图数据对象描述加工规格说明数据字典控制规格说明n模型的核心是数据字典模型的核心是数据字典一个包含了软件使一个包含了软件使用或生产的所有数据对象描述的中心库。用或生产的所有数据对象描述的中心库。n实体实体-关系图描述数据对象间的关系，实体关系图描述数据对象间的关系，实体-关关系图是用来进行数据建模活动的。系图是用来进行数据建模活动的。n数据流图有两个目的：指明数据在系统中移动数据流图有两个目的：指明数据在系统中移动时如何被变换；描述对数据流进行变换的功能时如何被变换；描述对数据流进行变换的功能（和子功

40、能）。它可以用于信息域的分析，作（和子功能）。它可以用于信息域的分析，作为功能建模的基础。为功能建模的基础。n状态转换图指明系统将如何动作。为此，状态状态转换图指明系统将如何动作。为此，状态转换图表示了系统的各种行为模式（称为转换图表示了系统的各种行为模式（称为“状状态态”），以及在状态间进行变迁的方式，状态），以及在状态间进行变迁的方式，状态转换图是行为建模的基础。转换图是行为建模的基础。3.2.1数据流图数据流图 n任何软件系统（或计算机系统）从根本上来说，任何软件系统（或计算机系统）从根本上来说，都是对数据进行加工或变换的工具。都是对数据进行加工或变换的工具。1.组成符号组成符号 n例4

41、.下面以教材购销系统中的教材销售为例，下面以教材购销系统中的教材销售为例，说明如何画数据流图。说明如何画数据流图。n从用户调查中了解到某高校向学生销售教材的从用户调查中了解到某高校向学生销售教材的手续是：先由系办公室的张秘书开购书证明，手续是：先由系办公室的张秘书开购书证明，学生凭证明找教材科的王会计开购书发票，向学生凭证明找教材科的王会计开购书发票，向李出纳员交付书款，然后到书库找赵保管员领李出纳员交付书款，然后到书库找赵保管员领书。现欲将上述手工操作改为计算机处理，试书。现欲将上述手工操作改为计算机处理，试画出教材销售过程的数据流图。画出教材销售过程的数据流图。n首先找出数据的源点和终点，

42、即找出数据源与首先找出数据的源点和终点，即找出数据源与数据汇，由此确定系统的边界。数据汇，由此确定系统的边界。n由于是由学生开始购书，最后由学生领书，因此数据的源点和终点都是“学生”。n第二步找出加工，需要从描述中抽象出系统要完成的工作。n学生须凭购书证明得到购书发票，然后交付书款，得到领书凭证，最后领书。其间能由计算机完成的工作是审查学生的购书凭证并开出发票，按发票开出领书单，由此我们得到2个加工（审查并开发票，并领书单）。n第三步要找出数据流。第三步要找出数据流。n学生向系统提交购书单，学生从系统得到领书单，在加工之间要传输发票信息，这样我们得到3个数据流。同时还要注意在“审查并开发票”加

43、工中排除了无效的书单，它也因作为一个数据流，因此最后得到4个数据流：购书单，发票，领书单，无效书单。n我们还要补充数据存储。数据存储一般不能通我们还要补充数据存储。数据存储一般不能通过系统描述确定，而要在设计数据流图时按照过系统描述确定，而要在设计数据流图时按照需要添加。需要添加。n实际上在审查购书单和开出发票之前，至少要实际上在审查购书单和开出发票之前，至少要查阅两个文件：查阅两个文件：各班学生用书表，该表用以各班学生用书表，该表用以核对学生是否需用这些教材；核对学生是否需用这些教材；教材存量表，教材存量表，了解有没有该生要买的教材。了解有没有该生要买的教材。n把这两个文件加进上图中，并给加

44、工添上编号，把这两个文件加进上图中，并给加工添上编号，就得到计算机售书系统的完整的数据流图。就得到计算机售书系统的完整的数据流图。2.命名命名 n数据流图中每个成分的命名是否恰当，直接影响数据流图中每个成分的命名是否恰当，直接影响数据流图的可理解性。给这些成分起名字时应该数据流图的可理解性。给这些成分起名字时应该仔细推敲。下面讲述在命名时应注意的问题：仔细推敲。下面讲述在命名时应注意的问题：n为数据流（或数据存储）命名为数据流（或数据存储）命名 n名字应代表整个数据流（或数据存储）的内容，而名字应代表整个数据流（或数据存储）的内容，而不是仅仅反映它的某些成分。不是仅仅反映它的某些成分。考生姓名

45、考生姓名分类后的姓名分类后的姓名录取录取分类分类n注意合适的命名，尽量用现实存在的表格、单据。注意合适的命名，尽量用现实存在的表格、单据。n不要使用空洞的、缺乏具体含义的名字（如不要使用空洞的、缺乏具体含义的名字（如“数数据据”、“信息信息”、“输入输入”之类）。之类）。n不要把控制流作为数据流。不要把控制流作为数据流。汇款单汇款单格式错误格式错误合格的汇款单合格的汇款单核准的汇款单核准的汇款单格式格式检查检查计算计算汇费汇费取下一个取下一个考生成绩考生成绩录取录取分类分类为处理命名n通常先为数据流命名，再为与之相关联的处理命名通常先为数据流命名，再为与之相关联的处理命名n名字应该反映整个处理

46、的功能，而不是它的一部分名字应该反映整个处理的功能，而不是它的一部分功能。功能。n名字最好有一个具体的及物动词加上一个具体的宾语名字最好有一个具体的及物动词加上一个具体的宾语组成。应该尽量避免使用组成。应该尽量避免使用“加工加工”、“处理处理”等空洞等空洞笼统的动词作名字。笼统的动词作名字。n通常名字中仅包括一个动词，如果必须用两个动词才通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个能描述整个处理的功能，则把这个处理再分解成两个处理可能跟恰当些。处理可能跟恰当些。n如果在为某个处理命名时遇到了困难，则很可能是分如果在为某个处理命名时遇到了困难，则很

47、可能是分解不恰当造成的，应该考虑重新分解。解不恰当造成的，应该考虑重新分解。n数据的源点和终点并不需要在系统中实现，它数据的源点和终点并不需要在系统中实现，它们只是系统的外围环境（可能是人员、计算机们只是系统的外围环境（可能是人员、计算机外部设备或传感器等）。通常为数据的源点和外部设备或传感器等）。通常为数据的源点和终点命名是采用它们在问题中习惯使用的名字，终点命名是采用它们在问题中习惯使用的名字，如如“学生学生”，“管理员管理员”。3.分层数据流图分层数据流图 n对于大型的系统，按照其层次结构进行逐步分对于大型的系统，按照其层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，解，并以分

48、层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统。能清楚地表达和容易理解整个系统。n对任何一层数据流图来说，我们称它的上层图对任何一层数据流图来说，我们称它的上层图为为父图父图，在它下一层的图则称为，在它下一层的图则称为子图子图。n在多层数据流图中，顶层流图仅包含一个加工，在多层数据流图中，顶层流图仅包含一个加工，它代表将被开发系统。它的输入流是该系统的它代表将被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据。底层流输入数据，输出流是系统所输出数据。底层流图是指其加工不需再做分解的数据流图，它处图是指其加工不需再做分解的数据流图，它处在最底层。中间层流图则表示对其上

49、层父图的在最底层。中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化，形成子图。细化。它的每一加工可能继续细化，形成子图。4数据流图实例数据流图实例 n建立数据流模型的基本步骤概括地说，就是自建立数据流模型的基本步骤概括地说，就是自外向内、自顶向下、逐层细化、完善求精。外向内、自顶向下、逐层细化、完善求精。n例5.建立一个简化的商业自动化系统。其中：建立一个简化的商业自动化系统。其中：售货员负责录入销售的商品（商品名，编号，售货员负责录入销售的商品（商品名，编号，单价，数量），有时要根据特定情况对销售的单价，数量），有时要根据特定情况对销售的商品进行修改或删除。收款员负责收取现金，商

50、品进行修改或删除。收款员负责收取现金，并将多交的付款退还用户。销售经理需要随时并将多交的付款退还用户。销售经理需要随时查询整个部门的销售情况（时间，商品编号，查询整个部门的销售情况（时间，商品编号，销售金额），并在每日结束时，统计各类商品销售金额），并在每日结束时，统计各类商品的销售金额。的销售金额。首先：建立系统环境，确定系统边界，画出顶层DFD。其中：其中：1 1 数据流为：销售的商品，日销售额等数据流为：销售的商品，日销售额等 2 2 数据源点为：营业员，经理，收款员数据源点为：营业员，经理，收款员 3 3 数据终点为：经理，收款员数据终点为：经理，收款员 4 4 加工名为：要建立的系统