第2章需求工程.pptx

《第2章需求工程.pptx》由会员分享，可在线阅读，更多相关《第2章需求工程.pptx（50页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第第2章章 需求工程需求工程l领域分析领域分析l需求获取需求获取l需求分析与建模需求分析与建模l需求规约与验证需求规约与验证l需求管理需求管理1西安交通大学 刘海岩2.1 领域分析领域分析1、领域分析的概念、领域分析的概念 软件工程要处理两类工程：软件工程要处理两类工程：（1）面向用户的业务过程工程）面向用户的业务过程工程（2）面向市场的产品工程）面向市场的产品工程（见下图）（见下图）领域领域(domain)，就是指解决问题的范围，从最高层的，就是指解决问题的范围，从最高层的角度（业务域）描述系统。角度（业务域）描述系统。系统分析可以发生在许多不同的抽象层次：系统分析可以发生在许多不同的抽象层

2、次：在业务或企业级层次，可定义描述模拟整个业务的功在业务或企业级层次，可定义描述模拟整个业务的功能、结构和行为的模型；能、结构和行为的模型；在应用层次，建模着重于特定的用户需求。在应用层次，建模着重于特定的用户需求。2西安交通大学 刘海岩企业企业业务域业务域业务域业务域信息系统信息系统过程需求过程需求信息战略计划信息战略计划（全局视图）（全局视图）业务域分析业务域分析（领域视图）（领域视图）系统分析与设系统分析与设计建模计建模构造与集成构造与集成业务过程工程层次业务过程工程层次3西安交通大学 刘海岩完整产品完整产品软件软件能力能力功能功能过程需求过程需求 产品需求产品需求（全局视图）（全局视图

3、）构件工程构件工程（领域视图）（领域视图）分析与设计分析与设计建模建模构造与集成构造与集成产品工程层次产品工程层次数据数据行为行为硬件硬件4西安交通大学 刘海岩 Firesmith对软件领域分析的定义是：领域分析指对软件领域分析的定义是：领域分析指特定应用领域中公共需求的标识、分析和规约，即发特定应用领域中公共需求的标识、分析和规约，即发现或创建那些可广泛应用的对象，其现或创建那些可广泛应用的对象，其目的目的使它们使它们在应在应用域中多个项目间能被复用用域中多个项目间能被复用。领域分析的角色是设计。领域分析的角色是设计和建造可复用构件（类似于制造环境中工具制造者的和建造可复用构件（类似于制造环

4、境中工具制造者的角色），它们被很多相似但不一定是相同的应用开发角色），它们被很多相似但不一定是相同的应用开发的人所使用。的人所使用。Lethbridge的定义是：领域分析是软件工程师的定义是：领域分析是软件工程师了解了解背景信息的过程背景信息的过程。为了理解问题并在需求分析和软件。为了理解问题并在需求分析和软件工程过程的其他阶段作出合理的决策，软件工程师必工程过程的其他阶段作出合理的决策，软件工程师必须了解使用该类软件的一般性商业和技术领域中足够须了解使用该类软件的一般性商业和技术领域中足够的信息。的信息。5西安交通大学 刘海岩 2、领域分析过程的活动领域分析过程的活动 （1）定定义义被被调查

5、调查的的领领域域中感兴趣的项中感兴趣的项 从从业务业务域、系域、系统类统类型或型或产产品范畴品范畴中中分离分离出出感感兴兴趣趣的的“项项”。感感兴兴趣的趣的项项包括：包括：现现存存的的应应用用软件软件的的规约规约、设计设计和代和代码码，支持，支持软件软件（如（如GUI或数据或数据库访问库访问构件构件）以及以及和和领领域相关的构件域相关的构件库库以及以及测试测试案例。案例。（2）对对从从领领域中抽取出来的域中抽取出来的项进项进行分行分类类并建立分并建立分类类层层次。次。6西安交通大学 刘海岩 （3）收集）收集领领域中域中应应用用系统系统的代表性的代表性样样本。本。（4）分析）分析样样本中的每个本

6、中的每个应应用用 标识候选的每个可复用对象。标识候选的每个可复用对象。指明指明对对象被象被标识为标识为可复用的理由。可复用的理由。定定义对义对象的适象的适应应性。性。估算在估算在领领域中复用域中复用这这些些对对象的象的应应用的百分率。用的百分率。使用配置管理技使用配置管理技术术控制控制这这些些对对象。象。（5）为对象开发分析模型。）为对象开发分析模型。7西安交通大学 刘海岩 3、领域分析的价值领域分析的价值 领域分析除了为软件复用奠定基础外，还为较低领域分析除了为软件复用奠定基础外，还为较低抽象层次的一般的系统分析带来如下好处：抽象层次的一般的系统分析带来如下好处：快速开快速开发发。有助于集中

7、精力关注最重要的。有助于集中精力关注最重要的问题问题，更有效地与相关人更有效地与相关人员进员进行交流，可以更快的确定需求。行交流，可以更快的确定需求。优优化系化系统统。了解。了解领领域的域的细节细节有助于保有助于保证证所采所采纳纳的的解决方案更有效地解决用解决方案更有效地解决用户户的的问题问题。会少犯。会少犯错误错误，知，知道道应该应该遵循那些遵循那些规规程和程和标标准。准。领领域分析域分析给给出一个出一个应应用用领领域的域的总总体体视图视图，会引，会引导导出更好的抽象从而改出更好的抽象从而改进设计进设计。有了有了领领域知域知识识，就可以洞察新，就可以洞察新兴趋势兴趋势及及进进一步开一步开发发

8、的机会，有助于的机会，有助于创创建适建适应应性更性更强强的系的系统统。了解通用性和特殊性，有助于了解通用性和特殊性，有助于创创建出具有更好的建出具有更好的可重用性和更可重用性和更宽宽的的销销售市售市场场的的软软件。件。8西安交通大学 刘海岩 专家提出，没有坚实的领域分析，任何重大的软专家提出，没有坚实的领域分析，任何重大的软件项目都不应该进行。对应用领域的深入理解能极大件项目都不应该进行。对应用领域的深入理解能极大的提高成功的几率。许多非常成功的软件产品的开发的提高成功的几率。许多非常成功的软件产品的开发人员以前都在业务领域工作过段时间，对实际需要人员以前都在业务领域工作过段时间，对实际需要有

9、着深切的感受。有着深切的感受。一旦对领域有了真正的理解，就可进行某一个项一旦对领域有了真正的理解，就可进行某一个项目（或产品）的需求分析，包括定义待解决的问题以目（或产品）的需求分析，包括定义待解决的问题以及开发什么软件来解决它。然而，领域分析永远也不及开发什么软件来解决它。然而，领域分析永远也不应该结束：开发人员有责任在开发过程中不断增进他应该结束：开发人员有责任在开发过程中不断增进他们的理解，后续版本的系统扩充通常需要对子领域进们的理解，后续版本的系统扩充通常需要对子领域进行进一步的领域分析。行进一步的领域分析。9西安交通大学 刘海岩2.2 需求获取需求获取1、需求、需求（requirem

10、ents）的概念的概念 （1）需求的定义）需求的定义 Jones 定义为用户所需要的软件必须达到的目标和定义为用户所需要的软件必须达到的目标和能力。能力。Lethbridge定义为需求是关于系统将要完成什么定义为需求是关于系统将要完成什么工作的一段描述，它们必须经过所有相关人员的认可，工作的一段描述，它们必须经过所有相关人员的认可，其目的是彻底的解决用户的问题。其目的是彻底的解决用户的问题。需求是一段需求是一段描述描述：意思是每个需求是相对短小简意思是每个需求是相对短小简明的一段信息，表现为一个事实。它可以是一段话或用明的一段信息，表现为一个事实。它可以是一段话或用各种图表示。一组需求的集合成

11、为需求文档。各种图表示。一组需求的集合成为需求文档。关于系统将要完成什么工作关于系统将要完成什么工作：需求描述了系统需求描述了系统应当完成的任务，不描述系统将如何实现。应当完成的任务，不描述系统将如何实现。必须经过所有相关人员的认可必须经过所有相关人员的认可：意指需求必须意指需求必须经过评审，才能成为正式的需求。经过评审，才能成为正式的需求。其目的是彻底的解决用户的问题其目的是彻底的解决用户的问题。有助于解决用有助于解决用户的问题，该需求才有存在的价值。户的问题，该需求才有存在的价值。10西安交通大学 刘海岩业务需求业务需求项目范项目范围文档围文档用户需求用户需求用例用例文档文档功能需求功能需

12、求质量属性质量属性其他非功其他非功能需求能需求设计约束设计约束需求需求规约规约非功能需求非功能需求系统需求系统需求需求组成的全景图需求组成的全景图（2）需求的组成需求的组成对系统、产品高层对系统、产品高层次的目标要求。次的目标要求。用户使用产品必用户使用产品必须要完成的任务须要完成的任务11西安交通大学 刘海岩 其中：其中：业务业务需求需求：反映：反映组织组织机构和客机构和客户对户对系系统统、产产品高品高层层次的目次的目标标要求。要求。用用户需求需求：从用户使用的角度给出需求的描述。从用户使用的角度给出需求的描述。如一个小型超市需要一个商品的查询系统。如一个小型超市需要一个商品的查询系统。业务

13、需求：进货人员需要查询商品库存以便保证及业务需求：进货人员需要查询商品库存以便保证及时进货；收款员需要查询商品的销售价格以便结账；经时进货；收款员需要查询商品的销售价格以便结账；经理需要查询商品的销售及盈利情况。理需要查询商品的销售及盈利情况。用户需求用户需求:这三类用户怎样去查询系统，查询哪些信这三类用户怎样去查询系统，查询哪些信息，还需要哪些操作。息，还需要哪些操作。12西安交通大学 刘海岩 系系统需求需求：从：从系统或技术的角度描述为实现业务需求和系统或技术的角度描述为实现业务需求和用户需求而提供的服务以及所受到的约束。用户需求而提供的服务以及所受到的约束。功能性需求功能性需求：描述系统

14、应该做什么，即为用户和其它系：描述系统应该做什么，即为用户和其它系统完成的功能。统完成的功能。非功能性需求非功能性需求：产品必须具备的属性或品质。：产品必须具备的属性或品质。设计约束束：设计与与实现必须遵循的标准、约束条件。如实现必须遵循的标准、约束条件。如运行平台、协议、选择的技术、编程语言和工具等。运行平台、协议、选择的技术、编程语言和工具等。（3 3）需求的描述）需求的描述 自然自然语言、言、结构化语言、结构化语言、PDL 图形化表示（使用图形化表示（使用Rational Rose、Microsoft Visio、Enterprise Architect等工具）等工具）数学描述（形式化语

15、言描述）数学描述（形式化语言描述）13西安交通大学 刘海岩2、需求工程过程、需求工程过程 需求工程是一个包括创建和维持系统需求文档所必需求工程是一个包括创建和维持系统需求文档所必需的一切活动的过程。它包含了如下活动：需的一切活动的过程。它包含了如下活动：系统可行性研究、需求获取和分析、需求描述和文系统可行性研究、需求获取和分析、需求描述和文档编写、需求有效性验证、需求管理（管理需求工程档编写、需求有效性验证、需求管理（管理需求工程的变更）。的变更）。可行性研究可行性研究需求获取需求获取和分析和分析需求描述需求描述需求有效需求有效性验证性验证可行性研可行性研究报告究报告系统模型系统模型用户需求和

16、用户需求和系统需求系统需求需求规约需求规约需求工程过程需求工程过程需求管理需求管理14西安交通大学 刘海岩l可行性研究是需求工程过程的开始。在较短的时间内可行性研究是需求工程过程的开始。在较短的时间内作出结论。集中回答以下问题：作出结论。集中回答以下问题：（1）系统是否符合组织机构的总体目标。系统不支）系统是否符合组织机构的总体目标。系统不支持这些目标，就没有价值。持这些目标，就没有价值。（2）系统是否可能在现有的技术条件、预算和时间）系统是否可能在现有的技术条件、预算和时间限制内完成。限制内完成。（3）系统能否与已经存在的系统集成。）系统能否与已经存在的系统集成。l该活动要广泛收集信息并评估

17、，回答一些有关的问题，该活动要广泛收集信息并评估，回答一些有关的问题，写出研究报告，得出结论：写出研究报告，得出结论：系统是否值得开发？给出系统是否值得开发？给出具体的意见和建议具体的意见和建议。可能对系统高层需求、功能范围、。可能对系统高层需求、功能范围、预算和时间安排提出修改意见。预算和时间安排提出修改意见。l写出可行性研究报告，该文档可作为项目建议书、投写出可行性研究报告，该文档可作为项目建议书、投标书的基础标书的基础 15西安交通大学 刘海岩计算机软件文档编制规范（计算机软件文档编制规范（计算机软件文档编制规范（计算机软件文档编制规范（GB/T8567-2006GB/T8567-200

18、6）可行性分析（研究）可行性分析（研究）可行性分析（研究）可行性分析（研究）报报告告告告模版模版模版模版1 引言引言 1.1 标识（标题、版本号）标识（标题、版本号）1.2 背景背景 1.3 项目概述项目概述（用途、特性、用户、运行环境等）（用途、特性、用户、运行环境等）1.4 文档概述（用途、内容、保密性等）文档概述（用途、内容、保密性等）2 引用文件引用文件3 可行性分析的前提可行性分析的前提 3.1 项目的要求项目的要求 3.2 项目的目标项目的目标 3.3 项目的环境、条件、假定和限制项目的环境、条件、假定和限制 3.4 进行可行性分析的方法进行可行性分析的方法16西安交通大学 刘海岩

19、4 可选的方案可选的方案 4.1 原有方案的优缺点、局限性和存在的问题原有方案的优缺点、局限性和存在的问题 4.2 可重用的系统与要求之间的差距可重用的系统与要求之间的差距 4.3 可选的系统方案可选的系统方案1 4.x 选择最终方案的准则选择最终方案的准则5 所建议的系统所建议的系统 5.1 系统的说明系统的说明 5.2 数据流程或处理流程数据流程或处理流程 5.3 与原系统的比较与原系统的比较 5.4 影响或要求（设备、软件、运行、开发、影响或要求（设备、软件、运行、开发、环境、经费）环境、经费）5.5 局限性局限性17西安交通大学 刘海岩6 经济可行性（成本经济可行性（成本-效益分析）效

20、益分析）6.1 投资（成本）投资（成本）6.2 预期的经济效益预期的经济效益 （一次性（一次性/非一次性收益，不可定量的收益，收益非一次性收益，不可定量的收益，收益/投投资比，投资回收周期）资比，投资回收周期）6.3 市场预测市场预测7 技术可行性（技术风险评价）技术可行性（技术风险评价）8 法律可行性法律可行性9 用户使用可行性用户使用可行性10 其他与项目有关的问题（如未来的变化）其他与项目有关的问题（如未来的变化）11 注释注释12 附录附录18西安交通大学 刘海岩需求获取与需求分析的区别需求获取与需求分析的区别 需求获取是开发人员与客户或用户一起对应用领域进需求获取是开发人员与客户或用

21、户一起对应用领域进行调查研究，收集系统需求的过程。行调查研究，收集系统需求的过程。需求分析是将获取到的需求准确的理解、求精，并将需求分析是将获取到的需求准确的理解、求精，并将其转化为完整的需求定义（包括建模），进而生成需求规其转化为完整的需求定义（包括建模），进而生成需求规约的过程。约的过程。需求获取和分析的难度需求获取和分析的难度 项目相关人目相关人员通常并不真正知道希望通常并不真正知道希望计算机做什么，算机做什么，让他他们清晰的表达出需要系清晰的表达出需要系统做什么是件困做什么是件困难的事，他的事，他们或或许提出不切提出不切实际的要求。的要求。19西安交通大学 刘海岩 项目相关人目相关人员

22、用自己的用自己的语言表达需求，言表达需求，这些些语言言包含很多工作中的包含很多工作中的专业术语和和专业知知识。系。系统分析分析员没有没有这些知些知识和和经验，而他，而他们又必又必须了解了解这些需求。些需求。不同的不同的项目相关人目相关人员有不同的需求，可能以不同有不同的需求，可能以不同的方式表达，分析人的方式表达，分析人员必必须发现所有潜在的需求所有潜在的需求资源，源，而且能而且能发现这些需求的相容或冲突之些需求的相容或冲突之处。经济和和业务环境决定了分析是境决定了分析是动态的，需求在分的，需求在分析析过程中会程中会发生生变更。个更。个别需求的重要程度会改需求的重要程度会改变，新的需求会从新的

23、新的需求会从新的项目相关人目相关人员那里得到。那里得到。20西安交通大学 刘海岩需求获取技术需求获取技术 建立由客户（用户）、系统分析员、领域专家参加的建立由客户（用户）、系统分析员、领域专家参加的联合小组。联合小组。需求获取的方法：个别访谈、召集会议、文档研究、需求获取的方法：个别访谈、召集会议、文档研究、问卷调查、观察用户工作流程、建立原型。问卷调查、观察用户工作流程、建立原型。获取的需求的表达方式：获取的需求的表达方式：（1）需求列表）需求列表 需求与系统的特殊视角或环境的关系需求与系统的特殊视角或环境的关系 （2）业务流程图（状态）业务流程图（状态/活动图）活动图）（3）用例（）用例（

24、Use-Case）/场景（场景（Scenario）/用户故事用户故事（user story)（4）数据流图）数据流图 （5）实体关系图）实体关系图 （6）用例图、类图、活动图、时序图、状态图等。）用例图、类图、活动图、时序图、状态图等。21西安交通大学 刘海岩用例用例 Jacobson说说“用例帮助定义系统之外存在什用例帮助定义系统之外存在什么（参与者）以及系统应该完成什么么（参与者）以及系统应该完成什么”。把系。把系统分成一组逻辑的、互相联系较少的部分，每统分成一组逻辑的、互相联系较少的部分，每一部分都一部分都描述了系统与外部角色交互所提供的描述了系统与外部角色交互所提供的服务服务，即用例的

25、集合代表了所有将会在系统需，即用例的集合代表了所有将会在系统需求中出现的交互。因此容易求中出现的交互。因此容易从使用的角度理解从使用的角度理解系统应达到的功能系统应达到的功能。而。而“用户故事用户故事”是某种形是某种形式的简化版用例。式的简化版用例。场景场景 场景是用例的具体描述。一个用例封装了一场景是用例的具体描述。一个用例封装了一组场景，每个场景就是一个单个线程。组场景，每个场景就是一个单个线程。22西安交通大学 刘海岩 例例1：列出图书馆系统与以下参与者（角色）交互的最：列出图书馆系统与以下参与者（角色）交互的最小用例集：借阅者、借书员、图书管理员、会计系统。小用例集：借阅者、借书员、图

26、书管理员、会计系统。借阅者：借阅者：按题目查询书籍按题目查询书籍 按作者查询书籍按作者查询书籍 按主题查询书籍按主题查询书籍 预定已被其他人借出的书籍预定已被其他人借出的书籍 查询借阅者的个人信息并列出借阅的书籍查询借阅者的个人信息并列出借阅的书籍23西安交通大学 刘海岩 借书员：借书员：所有借阅者的用例，再加上所有借阅者的用例，再加上 为借阅者查找某一书籍为借阅者查找某一书籍 登记已归还的书籍登记已归还的书籍 续借一本书续借一本书 登记缴纳的罚款登记缴纳的罚款 添加新的借阅者添加新的借阅者 更新借阅者的个人信息（地址、电话号码等）更新借阅者的个人信息（地址、电话号码等）图书管理员：图书管理员

27、：所有借阅者和借书员的用例，再加上所有借阅者和借书员的用例，再加上 添加藏书添加藏书 删除藏书删除藏书 改变系统中对已有书籍的记录信息改变系统中对已有书籍的记录信息 会计系统（独立运行）会计系统（独立运行）获得借阅者支付的超期罚款获得借阅者支付的超期罚款24西安交通大学 刘海岩l例例2：一个：一个SafeHome系统，系统激活的基本用例用自系统，系统激活的基本用例用自然语言陈述如下：然语言陈述如下：（参考教材（参考教材1)房主观察控制面板以确定是否系统已准备好接收输房主观察控制面板以确定是否系统已准备好接收输入。如果系统未准备好，房主必须物理地关闭门入。如果系统未准备好，房主必须物理地关闭门/

28、窗户，窗户，以便使以便使“准备好准备好”指示灯亮。指示灯亮。房主使用键盘输入房主使用键盘输入4 4位密码，系统将密码与存储在位密码，系统将密码与存储在配置库中的有效密码比较，如果密码不正确，控制面配置库中的有效密码比较，如果密码不正确，控制面板鸣叫一次并复位等待再次输入。如果密码正确，控板鸣叫一次并复位等待再次输入。如果密码正确，控制面板等待进一步的动作。制面板等待进一步的动作。房主选择键入房主选择键入“stay”stay”（仅激活外部的传感器）或（仅激活外部的传感器）或“away”away”（激活所有的传感器）以启动系统。（激活所有的传感器）以启动系统。当激活时，房主可观察到一个红色指示灯。

29、当激活时，房主可观察到一个红色指示灯。25西安交通大学 刘海岩 用例：用例：房主激活监测房主激活监测 场景：场景：1、房主：观察控制面板。、房主：观察控制面板。2、房主：输入密码。、房主：输入密码。3、房主：选择、房主：选择“stay”或或“away”。4、房主：观察红色指示灯显示系统已被打开。、房主：观察红色指示灯显示系统已被打开。异常：异常：1、控制面板未就绪。、控制面板未就绪。2、密码不正确。、密码不正确。3、密码不识别。、密码不识别。未解决的问题：未解决的问题：1、是否有不使用密码激活系统的方式。、是否有不使用密码激活系统的方式。2、控制面板是否还应显示附加的文字信息。、控制面板是否还

30、应显示附加的文字信息。3、房主输入密码的时间有无约束。、房主输入密码的时间有无约束。4、在系统真正激活之前有无办法关闭系统。、在系统真正激活之前有无办法关闭系统。26西安交通大学 刘海岩2.3 需求分析与建模需求分析与建模 需求分析是发现、规约和求精的过程，指需求分析是发现、规约和求精的过程，指开发人员准确的理解用户的需求，通过分析，开发人员准确的理解用户的需求，通过分析，将不规范的需求陈述转化为完整的需求定义，将不规范的需求陈述转化为完整的需求定义，并产生需求规格化说明的过程。并产生需求规格化说明的过程。获取的需求可能有模糊的、冗余的、有冲获取的需求可能有模糊的、冗余的、有冲突的或不易理解的

31、地方，需要用文字和图形描突的或不易理解的地方，需要用文字和图形描述不同视图以揭示更深的、易混淆的问题，确述不同视图以揭示更深的、易混淆的问题，确保与所有风险承担者达成共识。保与所有风险承担者达成共识。27西安交通大学 刘海岩 需求分析活动具有以下任务：需求分析活动具有以下任务：（1）分析需求的可行性：允许的成本、性能；）分析需求的可行性：允许的成本、性能；与其他需求的冲突；外界因素的依赖和技术障碍与其他需求的冲突；外界因素的依赖和技术障碍等。等。（2）对于渐增式开发要确定需求的优先级别，）对于渐增式开发要确定需求的优先级别，以便确立产品版本。以便确立产品版本。（3）建模：模型能突出或强调某些关

32、键的系）建模：模型能突出或强调某些关键的系统特征。使用文本统特征。使用文本 和图表形式的组合，以相对和图表形式的组合，以相对容易理解和能直接评审正确性、完整性和一致性容易理解和能直接评审正确性、完整性和一致性的方式来描述数据（信息）、功能和行为的需求。的方式来描述数据（信息）、功能和行为的需求。图形化的表示分析模型可以增强对软件需求的理图形化的表示分析模型可以增强对软件需求的理解，也为软件设计奠定了基础。解，也为软件设计奠定了基础。（4）生成需求规格说明。）生成需求规格说明。28西安交通大学 刘海岩 在过去的数年中，人们提出了许多种分析在过去的数年中，人们提出了许多种分析建模的方法，其中两种在

33、分析建模领域占有主建模的方法，其中两种在分析建模领域占有主导地位：导地位：第一种是结构化分析第一种是结构化分析(Structured Analysis，SA)，70年代末由年代末由DeMarco等人提出，等人提出，这是传统的建模方法。该方法不是被所有的使这是传统的建模方法。该方法不是被所有的使用者一致地使用的单一方法，众多科学家对其用者一致地使用的单一方法，众多科学家对其进行了扩充，因此它是发展了超过进行了扩充，因此它是发展了超过30年的一个年的一个混合物混合物。另一种方法是面向对象的分析，另一种方法是面向对象的分析，如如Coad-Yourdon方法、方法、Booch方法、方法、Rumbaug

34、h方法、方法、Jacobson 方法等。方法等。具体的建模方法有具体的建模方法有:29西安交通大学 刘海岩上下文模型（上下文模型（ERD、包图）、包图）面向流的建模：数据流图（面向流的建模：数据流图（DFD/CFD）数据建模：实体关系图（数据建模：实体关系图（ERD）基于场景的建模：用例图、顺序图、活动图基于场景的建模：用例图、顺序图、活动图基于类的建模：类图、包基于类的建模：类图、包基于行为的建模：基于行为的建模：Petri网、状态图、顺序图、网、状态图、顺序图、协作图、活动图协作图、活动图 30西安交通大学 刘海岩Sommerville认为模型可以从以下角度去描述：认为模型可以从以下角度去

35、描述：1、从外部看，它是对系统上下文或系统环境、从外部看，它是对系统上下文或系统环境建模。（见下页图）建模。（见下页图）2、从行为上看，它是对系统运行行为建模。、从行为上看，它是对系统运行行为建模。3、从结构上看，它是对系统体系结构和系统、从结构上看，它是对系统体系结构和系统数据的结构建模。数据的结构建模。有如下系统模型的实例（有如下系统模型的实例（ppt30）：）：31西安交通大学 刘海岩上下文模型（定义了系统的边界）上下文模型（定义了系统的边界）32西安交通大学 刘海岩 1、数据处理模型数据处理模型 如数据流图，说明系统如数据流图，说明系统的不同阶段数据如何被处理。的不同阶段数据如何被处理

36、。2、组成模型组成模型 实体关系图，说明一个实体与实体关系图，说明一个实体与另外实体间的关系或如何由其他实体组成。另外实体间的关系或如何由其他实体组成。3、体系结构模型体系结构模型 说明构成整个系统的那些说明构成整个系统的那些主要的子系统。主要的子系统。4、分类模型分类模型 如对象模型，说明对象间怎样如对象模型，说明对象间怎样具有共同特性。具有共同特性。5、激励激励-响应模型响应模型 说明系统对来自内部和说明系统对来自内部和外部的事件的响应。外部的事件的响应。具体分析建模的方法请见第具体分析建模的方法请见第3章。章。33西安交通大学 刘海岩2.4 需求规约与验证需求规约与验证1、软件需求规约（

37、、软件需求规约（Software Requirements Specification，SRS）SRS是需求分析阶段的产品，是所有其他开发和管是需求分析阶段的产品，是所有其他开发和管理活动的基础。对系统开发过程中其他活动的影响：理活动的基础。对系统开发过程中其他活动的影响：项目经理根据它制定或修改开发计划。项目经理根据它制定或修改开发计划。设计人员根据它进行系统设计。设计人员根据它进行系统设计。测试人员根据它编写测试计划，设计测试用例。测试人员根据它编写测试计划，设计测试用例。产品发布人员根据它编写产品介绍和用户文档。产品发布人员根据它编写产品介绍和用户文档。培训人员根据它编写培训教程。培训人

38、员根据它编写培训教程。34西安交通大学 刘海岩 需求规约的结构需求规约的结构：1998年的年的IEEE标准为需求规约提出了以下结构，标准为需求规约提出了以下结构，组织机构内部可以基于此标准扩展：组织机构内部可以基于此标准扩展：（1）引言）引言 需求文档的目的、产品范围、文档约定（缩写需求文档的目的、产品范围、文档约定（缩写词与缩略语）、参考文献、文档的其余部分概览词与缩略语）、参考文献、文档的其余部分概览 （2）综合描述）综合描述 产品前景、产品前景、产品功能与优先级、用户特征、运产品功能与优先级、用户特征、运行环境、设计与实现上的约束、假设和依赖性行环境、设计与实现上的约束、假设和依赖性35

39、西安交通大学 刘海岩 （3）需求描述）需求描述 a.功能需求功能需求 b.数据需求：与功能有关的数据定义和数据关系数据需求：与功能有关的数据定义和数据关系 c.性能需求：响应时间、容量要求、用户数等性能需求：响应时间、容量要求、用户数等 d.外部接口：用户界面、软硬件接口、通信接口外部接口：用户界面、软硬件接口、通信接口 e.设计约束：软件支持环境、报表、数据命名等设计约束：软件支持环境、报表、数据命名等 f.软件质量属性（可维护性、可靠性、可移植性、软件质量属性（可维护性、可靠性、可移植性、可用性、安全性等等）可用性、安全性等等）g.其他需求其他需求 这一节是文档中最实质性的部分，由于在机构

40、组织的这一节是文档中最实质性的部分，由于在机构组织的实践中存在极大的变数，对这一节定义的标准结构可以实践中存在极大的变数，对这一节定义的标准结构可以进行增删。进行增删。（4）附录（词汇表、硬件与数据库的描述、模型、）附录（词汇表、硬件与数据库的描述、模型、待定问题列表等）待定问题列表等）（5）索引）索引36西安交通大学 刘海岩计算机软件文档编制规范（计算机软件文档编制规范（计算机软件文档编制规范（计算机软件文档编制规范（GB/T8567-2006GB/T8567-2006）需求需求需求需求规规格格格格说说明明明明模版模版模版模版1.引言引言 1.1标识 文件状文件状态（草稿草稿/正式正式发布布

41、/正在修改）；文件正在修改）；文件标识；当前版本；当前版本；作者作者 1.2 系系统概述（名称、功能、性能、上下文关系、概述（名称、功能、性能、上下文关系、用用户、开、开发者）者）1.3 文档概述（用途、内容、保密性）文档概述（用途、内容、保密性）1.4 基基线2.引用文件引用文件3.需求需求 3.1 所需的状所需的状态和方式和方式 3.2 需求概述（系需求概述（系统目目标、运行、运行环境、用境、用户特点、特点、关关键点、点、约束条件）束条件）37西安交通大学 刘海岩3.3 需求需求规格格 3.3.1 软件系件系统总体功能体功能/对象象结构构 3.3.2 软件子系件子系统功能功能/对象象结构构

42、 3.3.3 描述描述约定定3.4 能力需求能力需求 3.4.1 能力（功能、性能、主能力（功能、性能、主题、目、目标；对每一个功能每一个功能写出写出输入、入、处理、理、输出的需求）出的需求）3.5 外部接口需求外部接口需求 （用（用户、硬件、硬件、软件、通信等接口需求）件、通信等接口需求）3.6 内部接口需求内部接口需求3.7 内部数据需求（数据内部数据需求（数据库和数据文件的需求）和数据文件的需求）38西安交通大学 刘海岩 3.8 3.12 适适应性、保密性、性、保密性、环境、境、资源、通信等需求源、通信等需求 3.13 软件件质量因素（可靠性、可用性、可量因素（可靠性、可用性、可维护性等

43、）性等）3.14 设计与与实现的的约束束 （故障（故障处理、其他需求，需求的理、其他需求，需求的优先先级等等）等等）4 合格性合格性规定（定（验证方法）方法）5 需求可追踪性需求可追踪性6 尚未解决的尚未解决的问题7 注注释、附、附录39西安交通大学 刘海岩 2、需求验证、需求验证 需求验证的重要性：如果在后续的开发或当系统投入需求验证的重要性：如果在后续的开发或当系统投入使用时才发现需求规约中的错误，就会导致更大代价的返工。使用时才发现需求规约中的错误，就会导致更大代价的返工。由需求问题而对系统做变更的成本比修改设计或代码错误的由需求问题而对系统做变更的成本比修改设计或代码错误的成本要大的多

44、。假设需求阶段引入成本要大的多。假设需求阶段引入1个错误的需求，设计时个错误的需求，设计时对这个需求需要对这个需求需要510条设计实现，条设计实现，1条设计需要条设计需要 510条程序，条程序，1条程序需要条程序需要35种测试组合测试。种测试组合测试。原始需求原始需求正确的规格说明正确的规格说明 错误的规格说明错误的规格说明正确的设计正确的设计 错误的设计错误的设计 对错误需求的设计对错误需求的设计正确的编码正确的编码 错误的编码错误的编码 对错误设计的编码对错误设计的编码 对错误需求的编码对错误需求的编码正确功能正确功能 测试到的错误测试到的错误 没有测试到的错误没有测试到的错误 一一个错误

45、的需求，纠正成本个错误的需求，纠正成本100元元10 纠正成本纠正成本1000元元10540西安交通大学 刘海岩 对需求规约需执行以下类型的检查：对需求规约需执行以下类型的检查：（1）有效性检查）有效性检查 检查不同用户使用不同功能的有效性。检查不同用户使用不同功能的有效性。（2）一致性检查）一致性检查 在文档中，需求不应该冲突。在文档中，需求不应该冲突。（3）完备性检查）完备性检查 需求文档应该包括所有用户想要的功能和需求文档应该包括所有用户想要的功能和约束。约束。（4）现实性检查）现实性检查 检查保证能利用现有技术实现需求检查保证能利用现有技术实现需求。41西安交通大学 刘海岩 验证技术：

46、验证技术：（1）需求评审：）需求评审：评审需求的评审需求的 一致性一致性 完备性完备性 可检验性（是否可实际测试）可检验性（是否可实际测试）可理解性可理解性 可跟踪性（需求出处是否清晰）可跟踪性（需求出处是否清晰）适应性（需求是否可调节）适应性（需求是否可调节）由分析员、设计员、测试员、用户参与的正式由分析员、设计员、测试员、用户参与的正式或非正式的会议评审。正式会议要有严格的评审程或非正式的会议评审。正式会议要有严格的评审程序，要有会议记录，开发组根据缺陷建议修改需求序，要有会议记录，开发组根据缺陷建议修改需求说明并重审。说明并重审。42西安交通大学 刘海岩 （2）利用原型检验系统是否符合用

47、户的真正）利用原型检验系统是否符合用户的真正需要。需要。（3）对每个需求编写概念性的测试用例。）对每个需求编写概念性的测试用例。（4）编写用户手册。用浅显易懂的语言描述用）编写用户手册。用浅显易懂的语言描述用户可见的功能。户可见的功能。（5）自动的一致性分析。可用）自动的一致性分析。可用CASE工具检验工具检验需求模型的一致性。需求模型的一致性。43西安交通大学 刘海岩计算机软件文档编制规范（计算机软件文档编制规范（计算机软件文档编制规范（计算机软件文档编制规范（GB/T8567-2006GB/T8567-2006）软软件用件用件用件用户户手册手册手册手册模版模版模版模版1 引言引言 1.1标

48、识 文件状文件状态（草稿草稿/正式正式发布布/正在修改）；文件正在修改）；文件标识；当前版本；当前版本；作者作者 1.2 系系统概述（名称、功能、性能、上下文关系、概述（名称、功能、性能、上下文关系、用用户、开、开发者）者）1.3 文档概述（用途、内容、保密性）文档概述（用途、内容、保密性）1.4 基基线2 引用文件引用文件3 软件综述软件综述 3.1 软件用途软件用途 3.2 软件清单软件清单 3.3 软件安装与运行环境软件安装与运行环境44西安交通大学 刘海岩 3.4 软件组织和操作概述软件组织和操作概述 （逻辑部件，其用途，操作；用户期望的性能特性；（逻辑部件，其用途，操作；用户期望的性

49、能特性；该软件执行的功能和所接口的系统；为管理软件采用该软件执行的功能和所接口的系统；为管理软件采用的监控措施等）的监控措施等）3.5 意外事故及运行的备用状态和方式意外事故及运行的备用状态和方式 3.6 保密性保密性 3.7 帮助和问题报告帮助和问题报告4 访问软件访问软件 4.1 首次用户（熟悉设备；访问控制；安装和设置）首次用户（熟悉设备；访问控制；安装和设置）4.2 启动过程（步骤）启动过程（步骤）4.3 停止与挂起停止与挂起45西安交通大学 刘海岩5 使用软件指南使用软件指南 5.1 能力能力 （简述事物、菜单、功能和其他处理之间的关系）（简述事物、菜单、功能和其他处理之间的关系）5

50、.2 约定约定 （缩略语、命名、编码规则等）（缩略语、命名、编码规则等）5.3 处理过程处理过程 （解释功能、菜单、屏幕的组织及完成过程的次序）（解释功能、菜单、屏幕的组织及完成过程的次序）5.4 相关处理相关处理 （脱机、后台等不被用户直接调用的处理）（脱机、后台等不被用户直接调用的处理）5.5 数据备份数据备份 5.6 错误、故障和紧急情况时的恢复错误、故障和紧急情况时的恢复 5.7 完成功能时发出的错误消息、诊断消息和通知性消息完成功能时发出的错误消息、诊断消息和通知性消息 5.8 快速引用指南快速引用指南6 注释、附录注释、附录46西安交通大学 刘海岩2.5 需求管理需求管理 需求管理