[读书笔记]UML和模式应用 ---- 进化式需求

定义:需求

       需求(Requirement)就是系统(更广义的说法是项目)必须提供的能力和必须遵从的条件[JBR99]

" Requirements are capabilities and conditions to which the system—and more broadly, the project—must conform". [JBR99]

 

    UP(Unified Process)提出了一系列的最佳实践,其中之一就是需求管理 (requirement management)。需求管理不主张采用瀑布的观点,即在编程之前项目的第一个阶段就试图完全定义和固化需求。在变更不可避免,涉众医院不明朗的情况下,UP更推崇用"一种系统的方法来寻找、记录、组织和跟踪系统不断变更 的需求"[RUP](Rational Unified Process)

    简单言之,就是通过迭代巧妙的进行需求分析,而非草率和随意为之。

    需求分析的最大挑战是寻找、沟通和记住(通常是指记录)什么是真正需要的,并能够清楚地讲解给客户和开发团队的成员。

 

寻求需求可以采用的方法

  • 与客户一同编写用例
  • 开发者和客户共同参加需求研讨会
  • 请客户代理参加焦点小组
  • 向客户演示每次迭代的成果以求得反馈

需求的类型和种类

在UP中,需求按照"FURPS+"模型进行分类[Grady92]

  • 功能性(Functional):特性、功能、安全性。
  • 可用性(Usability):  人性化因素、帮助、文档。
  • 可靠性(Reliability):故障频率、可恢复性、可预测性。
  • 性能(Performance):响应时间、吞吐量、准确性、有效性、资源利用率。
  • 可支持性(Supportability):适应性、可维护性、国际化、可配置性。

FURPS+中的”+“是指一些辅助性的和次要的因素,比如:

  • 实现(Implementation):资源限制、语言和工具、硬件等。
  • 接口(Interface):强加于外部系统接口之上的约束。
  • 操作(Operation):对其操作设置的系统管理。
  • 包装(Packaging):例如物理的包装盒。
  • 授权(Legal):许可证或者其他方式。
IBM RUP对FURPS+的定义

The FURPS+ System for Classifying Requirements

One such classification system was devised by Robert Grady at Hewlett-Packard. 2 It goes by the acronym FURPS+ which represents:

* Functionality
* Usability
* Reliability
* Performance
* Supportability

The "+" in FURPS+ also helps us to remember concerns such as:

* Design requirements
* Implementation requirements
* Interface requirements
* Physical requirements

 

UP制品如何组织需求

     UP提供了一些需求制品。同所有的UP制品一样,它们都是可选的。其中关键的制品包括:

  • 用例模型 :一组使用系统的典型场景。主要用于功能(行为的)需求。
  • 补充性规格说明 :基本上是用例之外的所有内容。主要用于所有非功能需求,例如性能或许可发布。该制品也用来记录没有(或者不能表示)为用例的功能特性,例如报表生成。
  • 词汇表 :词汇表以最简单的形式定义重要的术语。同时也包含了数据字典 (data directionary)的概念,其中记录了关于数据的需求,流入有效性规则,容许值等。词汇表可以详述任何元素:对象属性、操作调用的参数、报表布局等。
  • 设想 :概括了高阶需求,这些需求在用例模型和补充性规格说明中进行细化。设想也概括了项目的业务案例。设想是简短的执行概要文档,用以快速了解项目的主要思想。
  • 业务规则 :业务规则(也称为领域规则)通常描述了凌驾于某以软件项目的需求或政策,这些规则是领域或业务所要求的,并且许多应用应该遵从这些规则。领域规则的细节可以记录在补充性规格说明中,但是因为这些规则通常更为持久,并且不止对一个软件项目适用,所以应将其放入集中的业务规则制品(供公司的所有分析员共享),以便在这方面做出的分析工作能够被更好的重用。

总结:UP的推崇迭代和进化式需求,强调了需求的"不断变更 "的重要特性。使用一种系统的方法来寻找、记录、组织和跟踪系统不断变更的需求[RUP]--需求管理(manage requirement)。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
前言 第一部分 绪论 第1章 面向对象分析和设计 1.1 本书的主要内容 1.2 最重要的学习目标 1.3 什么是分析和设计 1.4 什么是面向对象分析和设计 1.5 简短示例 1.6 什么是UML 1.7 可视建模的优点 1.8 历史 1.9 参考资料 第2章 迭代、进化和敏捷 2.1 什么是UP?其他方法能否对其进行补充 2.2 什么是迭代和进化开发 2.3 什么是瀑布生命周期 2.4 如何进行迭代和进化分析和设计 2.5 什么是风险驱动和客户驱动的迭代计划 2.6 什么是敏捷方法及其观点 2.7 什么是敏捷建模 2.8 什么是敏捷UP 2.9 UP的其他关键实践 2.10 什么是UP的阶段 2.11 什么是UP科目 2.12 如何定制过程和UP开发案例 2.13 判断你是否理解迭代开发或UP 2.14 历史 2.15 参考资料 第3章 案例研究 3.1 案例研究中涵盖的内容 3.2 案例研究策略:迭代开发+迭代学习 3.3 案例一:NextGen POS系统 3.4 案例二:Monopoly游戏系统 第二部分 初 始 阶 段 第4章 初始不是需求阶段 4.1 什么是初始 4.2 初始阶段的持续时间 4.3 初始阶段会创建的制品 4.4 何时知道自己并不了解初始阶段 4.5 初始阶段中有多少UML 第5章 进化需求 5.1 定义:需求 5.2 进化需求与瀑布需求 5.3 寻找需求可以采用的方法 5.4 需求的类型和种类 5.5 UP制品如何组织需求 5.6 本书是否包含这些制品的示例 5.7 参考资料 第6章 用例 6.1 示例 6.2 定义:参与者、场景和用例 6.3 用例和用例模型 6.4 动机:为什么使用用例 6.5 定义:用例是功能性需求吗 6.6 定义:参与者的三种类型 6.7 表示法:用例的三种常用形 6.8 示例:详述风格的处理销售 6.9 各小节的含义 6.10 表示法:有其他格吗?两栏变体 6.11 准则:以无用户界面约束的本质风格编写用例 6.12 准则:编写简洁的用例 6.13 准则:编写黑盒用例 6.14 准则:持有参与者和参与者目标的视点 6.15 准则:如何发现用例 6.16 准则:什么样的测试有助于发现有用的用例 6.17 应用UML:用例图 6.18 应用UML:活动图 6.19 动机:用例还有其他益处吗?语境中的需求 6.20 示例:Monopoly游戏 6.21 过程:在迭代方法中如何使用用例 6.22 历史 6.23 参考资料 第7章 其他需求 7.1 如何完成这些示例 7.2 准则:初始阶段是否应该对此彻底地进行分析 7.3 准则:这些制品是否应该放在项目Web站点上 7.4 NextGen示例:(部分)补充性规格说明 7.5 注解:补充性规格说明 7.6 NextGen示例:(部分)设想 7.7 注解:设想 7.8 NextGen示例:(部分)词汇表 7.9 注解:词汇表(数据字典) 7.10 NextGen示例:业务规则(领域规则) 7.11 注解:领域规则 7.12 过程:迭代方法中的进化需求 7.13 参考资料 第三部分 细化迭代1—基础 第四部分 细化迭代2—更多模式 第五部分 细化迭代3——中级主题 第六部分 其他主题
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值