1 / 28

需求获取

需求获取. 这是什么?我们如何割草? 首先找到功能,然后找工作对象 对于客户描述系统的各种行为,我们首先找到系统有什么功能,再考虑系统为什么有这些行为。. 需求. 客户:我们需要这个软件,它。。。 开发者:。。。. 功能描述. 面临复杂问题. 处理复杂性有三条道路 抽象 分解(技巧:拆开,然后征服它) 架构(技巧:分层) 分解的两条路 面向对象,然后功能上做分解。 功能上的分解导致代码的不可维护。 根据系统的目的,各种对象是能够被找到的。. 什么是正确的途径? 从对功能的要求(用例模型)开始,进行寻找对象(对象模型)的活动。 需要哪些活动、哪些模型?

kathie
Download Presentation

需求获取

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 需求获取

  2. 这是什么?我们如何割草? • 首先找到功能,然后找工作对象 • 对于客户描述系统的各种行为,我们首先找到系统有什么功能,再考虑系统为什么有这些行为。

  3. 需求 • 客户:我们需要这个软件,它。。。 • 开发者:。。。

  4. 功能描述

  5. 面临复杂问题 • 处理复杂性有三条道路 • 抽象 • 分解(技巧:拆开,然后征服它) • 架构(技巧:分层) 分解的两条路 • 面向对象,然后功能上做分解。 • 功能上的分解导致代码的不可维护。 • 根据系统的目的,各种对象是能够被找到的。

  6. 什么是正确的途径? • 从对功能的要求(用例模型)开始,进行寻找对象(对象模型)的活动。 • 需要哪些活动、哪些模型? • 这一次将把我们带到软件生命周期。

  7. 软件生命周期的定义 • 软件生命周期:支持软件系统开发的活动及其相互间的关系。 • 典型问题 • 为此软件项目选择哪些活动? • 活动之间的依赖关系是什么? • 怎么给活动做出时间安排? • 活动的结果是什么?

  8. 软件生命周期活动 需求获取 系统设计 对象设计 需求分析 实现 测试

  9. RUP(统一)开发方法 工作流 业务建模 需求 分析与设计 实现 测试

  10. 建立需求的第一步 • 系统的开发不只是对场景(应用域)拍照。 • 需要回答两个问题 • 怎么标识系统的目的? • 关键是系统边界的定义:什么在系统里、什么在系统外? 需求过程的两个活动 • 需求获取:以客户理解的术语描述系统的定义。(问题陈述) • 需求分析:以开者理解的术语描述系统的规范。(问题规范)

  11. 需求过程的产品

  12. 需求获取 • 需求获取是非常有挑战性的活动 • 需要具有不同背景的人们合作 • 具有应用域知识的用户 • 具有解决域知识(设计,实现)的开发者 • 用户与开发者之间的桥梁 • 场景:系统使用的示例 • 用例:可描述一类场景的抽象

  13. 系统规范对比分析模型 • 两种模型都集中在从用户视角看的系统的需求 • 系统规范使用自然语言 • 分析模型使用形式或者半形式的记号语言(例如,UML之类的图形语言。) • 出发点是问题陈述

  14. 问题陈述 • 问题陈述是客户开发的、系统所解决的问题的描述。 • 其他说法,工作陈述。 • 一个好的问题陈述描述了 • 当前情况 • 系统应当支持的功能 • 系统布署的环境 • 客户期望提交的工作产品 • 提交日期 • 接受标准

  15. 问题陈述的成分 • 当前情况:待解决的问题。 • 一个或多个场景的描述。 • 需求 功能和非功能需求 约束(伪需求) 4. 项目时间表 有主要里程碑,包括与客户在截止日期交流的活动。

  16. 5. 目标环境 6. 接收标准

  17. 当前情况:待解决问题 • 当前情况下的问题,例如 • 玩跳棋时,响应时间太慢。 • 我要玩围棋,但是找不到在我这个水平的对手。 • 变化下的问题,例如 应用域中的变化:新功能(业务过程)引入了这个业务。 解决域中的变化:一个新技术出现了。

  18. 场景 • 具体的、集中的、一个参与者使用系统时,单个特点(比如,正常使用)的非形式描述。

  19. 场景:仓库着火 • 图4-6,P100

  20. 如何找到场景 • 通过对话 • 你帮助客户把需求形式化。 • 客户帮助你理解需求。 • 需求在进化(逐步完善),当场景被开发时。

  21. 启发式规则 • 问自己或客户如下问题 • 当系统需要运行时,它的主要任务是什么? • 参与者将在系统中创建、保存、改变、移除、添加什么数据? • 系统需要知道有什么外部的变化? • 需要通知系统的参与者什么变化或事件?

  22. 寻找用例 • 在场景中找用例,用例可确定所有的场景。 • 描述用例细节 • 参考者 • 入口条件 • 事件流 • 出口条件 • 异常情况 • 特别需求(非功能,约束)

  23. 用例:报告紧急情况 • 图4-7,P102

  24. 用例 • 系统的功能完全由用例集合决定。 • 例子,事件管理系统Friend(P98)的用例模型 现场工作人员 调度者 打开事件 报告紧急情况 分配资源

  25. 形式化用例的步骤 • 命名 • 找参与者 泛化具体的名字,张三泛化为学生,约翰泛化为现场工作人员。 3. 写作事件流

  26. 启发式规则 • 纵向+横向+原型 • 纵向:系统的纵向切片,即一个场景。 • 横向:系统的横向切片,即用许多场景定义系统的范围。 • 原型:讲解用的视觉模型,即界面和接口。

  27. 用例写作指南 • 图4-8,P103

  28. 写得不好的用例 • 图4-9,P103

More Related