第4章需求工程.pptVIP

第4章 需求工程 软件需求 软件需求文档 需求描述 需求工程过程 需求导出和分析 需求有效性验证 4.1 软件需求 软件需求（requirements）描述了系统应该提供的服务以及实现和运行时所受到的约束。 Lethbridge定义为需求是关于系统将要完成什么工作的一段描述，它们必须经过所有相关人员的认可，其目的是彻底的解决用户的问题。 由于使用不同的方法和抽象层次来表达需求，Sommerville根据需求的来源将需求分成用户需求和系统需求两个不同层次的概念： 用户需求：给出高层概要需求的描述，只描述系统的外部行为。 系统需求：详细描述系统要提供的服务以及所受到的约束。 为了能更好的理解，系统需求可能包括许多不同的模型，因此在需求分析阶段需要建模。 系统需求的进一步分类 1、功能需求 描述系统应该做什么，即必须为用户和其它系统完成的功能、提供的服务以及在特定的条件下系统的行为。 2、非功能需求 指那些不直接与系统具体功能相关的一类需求。 两种需求互相有联系，也可能有冲突。 4.2 软件需求文档 ■ 软件需求文档称为软件需求说明（Software Requirements Specification，SRS ），也称 需求规约，是经过验证的正式文档。它是需求分析阶段重要的产品，是所有其他开发和管理活动的基础。 ■ 需求文档应满足如下要求： ? 具有准确性和一致性 ? 无二义性 ? 直观、易读和易于修改 4.3 需求描述 1、自然语言描述 2、结构化描述 以一种标准方式来书写（使用模板），可以用程序设计语言中的选择结构和重复结构（教材P60图4-10）。 3、表格和图形模型 采用标准的工具将需求进行图形化描述，以减少理解偏差。 描述业务需求、用户需求的图形主要使用例图（确定业务范围）、活动图（描述业务流程）， 功能需求常用的是时序图、协作图、数据流图等。 几种描述方法结合起来。 4.4 需求工程过程 需求工程是一个包括创建和维护系统需求文档所必需的一切活动的过程。它主要包含了如下活动： 业务需求的描述 可行性研究 需求获取（导出）和分析 需求描述和文档编写 需求有效性验证 需求管理（管理需求的变更） 4.5 需求导出和分析 软件开发人员、客户、系统最终用户一起调查应用领域：系统应该提供什么服务，应具有什么性能以及约束。 涉及到多方面的人。 过程模型见下图： 需求导出技术 1、建立由客户（用户）、管理者、系统分析员、业务专家等信息持有者建立的的联合小组。 2、需求导出的方法：个别访谈、召集会议、已有文件的研究、问卷调查、观察用户工作流程、建立原型。 3、获取的需求的表达方式（建模）： （1）需求列表 （2）业务流程图（状态/活动图） （3）视点(viewpoint) /用例(use case)/脚本(scenario)/用户故事（user story)的描述 （4）数据流图 （5）实体关系图 （6）类图、时序图、协作图 等等。 视点(viewpoint) 是一种收集和组织需求的方式，一般用来分类需求源头。如： ? 交互者视点： ? 间接视点： ? 领域视点： 下列经验帮助你识别视点： 脚本 (scenario) 也称为场景，是用例的具体描述。一个用例封装 了一组场景。 脚本可用文本来是写，可附带图（如时序图）。 用例(use case) 根据Jacobson的定义，用例规定了一个动作的序列，系统执行这些动作并产生出对于特定参与者可见的有价值的结果。 用例的集合代表了所有将会在系统需求中出现的交互。因此容易从使用的角度理解系统应达到的功能。 一个用例最简单的形式是：在一个交互中定义参与的角色并命名该交互类型。 4.6 需