软件工程 教学课件 作者 郑人杰 马素霞 麻志毅 第2章 软件需求获取与确定.pptVIP

第一部分 软件工程基础 第2章 软件需求获取与确定 2.1 软件需求获取的任务 软件需求（software requirement）是为了解决用户的问题或实现用户的目标，用户所需的软件必须满足的能力和条件 。 获取软件需求要涉及到多种人员，每种人员对需求的描述是不同的 主要的需求种类 业务需求：描述了使用软件系统要达到什么目标。 系统需求：为了满足用户解决问题需要的条件或能力，系统或系统成分必须满足或具有的条件或能力。 功能需求：规定了软件必须实现的功能性需求。 非功能需求 :在满足功能需求的基础上，软件系统还必须具有一定的特性和必须遵循一定的约束，非功能需求描述相应的特性和约束。 2.2 软件需求的获取与确认过程 2.3 快速原型化方法 原型法（prototyping）是这样的一种软件开发技术，通过开发软件的初期版本让用户进行反馈来确定软件的可行性，研究开发技术或开发过程支持的其他问题。 快速原型化（rapid prototyping）是一种原型法，它的重点是在开发过程的早期就开发出原型，使反馈和分析提前，以支持开发过程[1]。 2.3 快速原型化方法 （1）演示原型 通过演示原型向用户展示一些界面，让用户判断基于该原型的系统是否能够满足他们的要求。 （2） 技术验证原型 该原型在技术层上实现软件的部分功能，以验证技术上的可行性。 2.4 基于用况的方法 基于用况的方法通过建立用况模型来获取与确定需求。 在建立用况模型时，要确定系统边界，找出在系统边界以外与系统交互的事物，然后从这些事物与系统进行交互的角度，通过用况来描述这些事物怎样使用系统，以及系统向它们提供什么功能。 2.4.1系统边界 系统边界是系统的所有内部成分与系统以外各种事物的分界线。 系统只通过边界上的有限个接口与外部的系统使用者（人员、设备或外系统）进行交互。 2.4.1系统边界 2.4.2参与者 参与者(actor)定义了一组在功能上密切相关的角色，当一个事物与系统交互时，该事物可以扮演这样的角色。 2.4.2参与者 识别参与者 参与者是在系统之外的与系统进行交互的任何事物。这些事物可为人员、外部系统或设备。 2.4.2参与者 人员 直接使用系统的人员是参与者。这里强调的是直接使用，而不是间接使用。 外部系统 所有与本系统交互的外部系统都是参与者。 相对于当前在正在开发的系统而言，外部系统可以是其他子系统、下级系统或上级系统，也即任何与它进行协作的系统，但对这样的系统的开发并不是开发本系统的人员的责任。 设备 识别所有与系统交互的设备：这样的设备与系统相连并向系统提供外界信息，也可能系统要向这样的设备提供信息，设备在系统的控制下运行。 2.4.3 用况 用况(use case)是描述系统的一项功能的一组动作序列，这样的动作序列表示参与者与系统间的交互，系统执行该动作序列要为参与者产生结果。 2.4.3 用况 使用用况来可视化、详述、构造和文档化所希望的系统行为。尽管用况中描述的行为是系统级的，但在用况内所描述的交互中的动作应该是详细的，准则是对用况的理解不产生歧义即可。若描述得过于综合，则不易认识清楚系统的功能。 用况描述中的一个动作应该描述参与者或系统要完成的交互中的一个步骤。 在用况中只描述参与者和系统彼此为对方直接地做了些什么事，不描述怎么做，也不描述间接地做了些什么。 系统所产生的结果，是指系统对参与者的动作要做出响应。 用况描述的是参与者所使用的一项系统功能，该项功能应该相对完整。也即应该保证用况是某一项功能的完整的规格说明，而不能只是其中的一个片段。 在用况描述中，由参与者首先发起交互的可能性较大，但有些交互也可能是由系统首先发起的。 2.4.3 用况 用况与参与者之间的关系 一个参与者可以同多个用况交互，一个用况也可以同多个参与者交互。 把参与者与用况间的这种交互关系称为关联。若没做具体的规定，交互是双向的，即参与者能够对系统进行请求，系统也能够要求参与者采取某些动作。 把参与者和用况之间的关联表示成参与者和用况之间的一条实线。若要明确地指出参与者和用况之间的通讯是单向的，就在关联线上接收通讯的那端加一个箭头，用以指示方向。 2.4.3 用况 2.4.3 用况 2.4.3 用况 2.4.3 用况 2.4.3 用况 2.4.3 用况 2.4.3 用况 2.4.4 用况图 2.5 需求管理 （1）需求标识和分类 若功能需求的数目较大且以后往往要发生变化，需要为每个功能性需求指定一个唯一的标识，为以后的引用需求、变更需求、跟踪需求和复用需求提供便利。 最简单的方式是为每个需求赋予一个唯一的序列号。可以为序列号规定一个结构，如用序列号的前2项描述需求的类型。 也可以按功能需求的抽象