谈谈用UML来做需求管理
来源:互联网 发布:宏观经济数据主要指标 编辑:程序博客网 时间:2024/05/01 08:29
今天在看《Agile Software Development》,读到附录中关于UML的介绍,不禁慨叹:我以前在UML的时候怎么就那么的蹩脚呢,特别是在描述需求的时候。
我刚刚设计了一个项目,一开头就碰到一个头疼的问题——需求分析。我想取消我们以前那种繁杂的用文字描述的文档方法,采用UML的图形化来表示。取消的原因有两个,一是项目的组员不怎么愿意看那个文档来了解需求,我们这些搞技术的文字表述能力都不咋样,自己的东西自己看还好,给别人看就禁不住考验了;二是那个文档写起来太麻烦,以后需求改变了,没有时间也没有精力改那个文档,组员之间也是通过口头或者mail里面的只言片语来沟通需求,结果文档就成了一个摆设,需求到最后也没有真正管理起来。
可是怎么用UML来清晰的描述需求呢?认真看了《UML Distilled》,这本写得很通俗易懂,很容易上手。然而在具体的应用过程中,却碰到了麻烦。能够表述需求的,就是那个用例图了,领域图也可以勉强用用。更加要命的是,用例图在描述需求的时候显得太简单了,就是Actor加上Use Case,几乎是把显而易见的东西画了简单明了的图而已。而那个领域图,更加偏向分析设计方面,也不适合跟不懂技术的人员沟通。在这种情况下,只有采用图形+文字的描述方法,通过简单的图形配上大段的文字描述。这也使我一直耿耿于怀。
读了《Agile Software Development》中关于UML的介绍之后,让我有了新的启发。比如说用例图吧,可以通过扩展点(extension point),使用《extend》关系来连接用例。举例说,客户在买单的时候,可以选择多种支付方式,每种支付方式有不一样的处理流程。如果把买单作为用例A,而把多种支付方式作为用例B1,用例B2等,那么用例B1,用例B2就扩展了用例A。这样准确的描述了多种支付方式的需求。其中关于《include》关系的描述也有用途。这些方法以前我也看到过,但是没有今天看得这么清晰。也许是在经历了挫折之后,看到一种新的解决方法,格外的注意。
不过虽然在UML的图形表示法上取得了一些进展,需求管理的根本问题还没有得到解决。有很多的需求(至少客户这么认为),比如:界面上的要求、操作上的要求(要支持触摸等)、流程上细化的需求(要按照星期几促销等)等等,所有的这些需求,跨越了项目范围、关键流程、细化的流程、界面要求等等,怎么管理起来真是一个问题。
我正在思考,也有了一些眉目,这些思考就留在我的下一篇文章中吧。
- 谈谈用UML来做需求管理
- 谈谈用UML来做需求管理
- 用Leangoo做敏捷需求管理
- 作为项目经理来谈谈需求评审
- 从我的三份需求文档谈谈需求管理
- 怎么用leangoo做需求管理?(用户故事地图)
- 来谈谈SEO能做的事情
- 【UML图】——用UserCase Diagram来确定用户需求
- 软件作坊如何做需求管理
- 用UML做系统分析
- 讲到知识管理,我来谈谈密码管理
- 用Ant-Ivy来做类似Maven的包管理
- 谈谈这一年来做项目的经历(1)
- 谈谈这一年来做项目的经历(2)
- 岑辉宇:谈谈这三年来做SEO推广的酸甜苦辣
- 谈谈做产品经理一年来的经历和收获
- 如何使用testlink来管理测试用例以及与需求等
- UML建模—用例与需求
- 用AutoLoad显示位图按钮
- 十句保你职场不败的名言
- 沒有防火墙如何加強端口安全
- 正则表达式之道
- 从我的三份需求文档谈谈需求管理
- 谈谈用UML来做需求管理
- MINICOM 手册中文版
- 另类的实现透明窗体
- “朝圣的路”由来
- 常用位运算
- 心有所属
- 315开始日志
- "做与对"的哲学
- java学习:使用Java操作文本文件