CHP02_需求分析全解.ppt

软件工程第2章　需求分析 IBM缺陷放大模型 提纲 2.1　软件需求的概念 什么是软件需求 软件需求的分类 需求分析过程 2.2　需求分析技术 2.3 需求规格说明书 2.4 需求确认 2.5 需求管理 软件需求定义 按层次划分软件需求 业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。业务需求描述了企业一组概要性的目标，概要性的目标可能要依靠多个用户目标来实现。 用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。用户需求描述了用户目标，是具体明确的任务，但还不是详细的细节。 功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 三类需求的关系 软件需求的非功能性需求 非功能需求:定义产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。 软件需求分析的困难 (1)客户说不清楚需求 有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。 农夫和耕牛的故事 有些客户心里非常清楚想要什么，但却说不明白。 我的鞋是什么样的？ “不懂装懂”或者“半懂充内行”的客户令人恐惧 软件需求的复杂性 (2)需求自身经常变动 软件需求的复杂性 (2)需求自身经常变动 软件需求分析的基本过程-需求工程 需求工程 软件需求工程 需求获取 　 通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求； 需求建模(需求分析) 　为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述； 形成需求规格 　 生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约； 需求验证(需求确认) 　 以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性； 需求管理 　 支持系统的需求演进，如需求变化和可跟踪性问题。 提纲 1.1　软件需求的概念 1.2　需求分析技术 功能分析 数据分析 1.4 需求规格说明书 1.5　需求确认 功能分析工具 用例图 顺序图 活动图 界面定义 原型开发 用例图(UseCase Diagram) 用例是从系统的外部对系统进行黑盒视图描述的一种组织方法。 用例是抽象使用系统的一种方式，用户通过用例与系统交互。用例图主要的作用有三个： 用例图 如何识别参与者? 在系统之外，透过系统边界与系统进行有意义交互的任何事物都是参与者． 对于一般规模的软件系统，参与者不会太多，一般有这样几种类型的参与者： 与系统交互的用户 与系统交互的外部系统 与系统交互的外部硬件 特别注意：有时候时间触发器也可以看成是参与者 如何识别用例？ ＲＵＰ（Jacobson）：用例实例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。一个用例定义一组用例实例。 通俗地，用例是参与者利用系统所要达到的目标． 用例的要点 价值结果 用例的结果形成有意义的目标 执行者可见 采用业务语言，从用户观点描述 一组用例实例 用例的实例也称为场景：是执行者使用系统的一个特定情节或用例的一条执行路径。例如： 通过输入电话号码拨打电话的场景 通过查找电话号码簿拨打电话的场景 通过查找电话号码簿拨打电话,电话打到一半电话欠费的场景 建立用例模型的参考原则 用例是短文 用例可以是一个场景，包括动作和交互 用例可以是一组场景，描述不同场景下的行为。这种书写格式可以在任何时候描述有变化的行为，例如黑盒需求，业务流程，系统设计说明。 用例里不要有系统设计 用例里不要有界面设计 用例里不要有测试 用例应该描述行为需求 用例的主场景最好不要超过9步 用例的最大价值不在于主场景，而在于备选行为。 用例建模的步骤 确定系统的范围和边界 确定执行者 确定用例 对用例进行描述 定义用例之间的关系 审核用例模型 用例的文字描述应包括以下内容 用例的目的（功能）； 该用例在什么情况下被哪个参与者启动执行； 用例与参与者之间交互哪些消息来通知对方作出决定； 交互的主消息流及因此被使用或修改的实体； 用例中可供选择的异常事件流； 用例的结束标志：给参与者返回一个可识别的值． 举例： 　　用例名称：学生选课　　　　执行者：学生 　　目　　的：完成一次学生选课的完整过程． 　　类型：主要的，基本的 　　级别：一级 过程描述： 学生输入学号/密码，系统识别账户的有效性； 对学生进行注册识别； 浏览本学期预开课程； 选择学生自己要上的课程并确认