军衔: PMU初级一星
财产:
经验:
魅力:
来自: 四川成都市
鉴定: 本功能已经被关闭
发帖: 43篇
注册: 2002-8-26

--------------------------------------------------------------------------------


基于Rose的全程建模之三

如何进行需求分析

Version 1.0.7

作者:青润

文档信息
项目名: 基于Rose的全程建模之三

作者: 青润

创建日期: 2002-10-14

上次更新日期: 2002-12-11

使用者: <文档用户>

标题: 如何进行需求分析

版本: 1.0.7

分类: 稿件

版权声明: ©,2002

修订文档历史记录
日期 版本 说明 作者
2002-10-14 1.0.0 创建文档 青润
2002-10-20 1.0.1 完成了2.1的内容 青润
2002-11-26 1.0.2 初步完成了2.2中的内容 青润
2002-11-27 1.0.3 修改了2.3中的内容 青润
2002-11-28 1.0.4 正在撰写2.4中的内容 青润
2002-12-04 1.0.5 修改了部分内容 青润
2002-12-05 1.0.6 修改了2.5中的内容和部分格式 青润
2002-12-11 1.0.7 添加了2.3.3.1的内容 青润

目录

1. 概述 1
1.1 目的 1
1.2 关于CMM 1
2. 如何在需求阶段开展工作 1
2.1 需求调研 1
2.1.1 调研中的问题 1
2.1.2 过去和现在的对比 2
2.1.3 现象的分析 2
2.1.4 笔者的观点 2
2.1.5 关于蓝领工人和大学毕业生 3
2.1.6 一点闲话 3
2.1.7 如何和用户交流 4
2.1.8 需要注意的一些问题 6
2.2 业务建模 6
2.2.1 目的 6
2.2.2 基本步骤 7
2.2.3 建议 7
2.2.4 常见的问题 8
2.2.5 实例说明 8
2.3 用例模型部分 8
2.3.1 用例图的绘制 9
2.3.2 如何查找用例和主角 9
2.3.3 用例的处理 9
2.3.4 如何分包 11
2.4 如何阐述用例 12
2.4.1 用例阐述的目的 12
2.4.2 用例阐述的基本要求 12
2.4.3 用例阐述中可能出现的问题 12
2.5 如何进行交互建模 12
2.5.1 目的 12
2.5.2 基本要求 13
2.5.3 可能出现的问题 13

如何进行需求分析
1. 概述
1.1 目的
目的，简而言之就是：为什么要写这篇文字。其实，笔者在撰写第一篇的时候，就已经打算要写需求分析的相关内容了，但是，笔者在撰写第一篇的时候，在网上进行了一个小范围的调研，加上以往在软件工程板块提出问题大多集中在工具使用部分，所以在最后成文之前，笔者做出了一个决定：删掉需求内容，因为加上需求内容的阐述，笔者本文的推出就会至少延缓一个月的时间，考虑到读者的需求和要求，当时就下了这样的决定。
这次，十月到十一月份笔者到北京进行一项需求调研工作，同时，和北京的许多弟兄见了面，大家也聊起了这篇文章的内容。很多兄弟对此感到有些意外，其实，我也知道，需求工作实际上是软件开发过程中最最重要的一个部分，离开了需求，其他的任何都不能成为现实。因此，在CMM的最低级别（也就是CMM2级）的评估中，第一条就是需求管理——Requirement manage。如果这一项做不到，那么这家公司的软件开发和管理能力就是CMM1，也就是不定义级别，或者说是没有级别。当然，笔者在这里不是在吹嘘CMM是如何的好，只是为了从一个侧面说明需求工作是何等的重要。
好了，废话少说，我们现在就开始实际的内容。
1.2 关于CMM
注意，CMM只有评估，没有认证！
CMM的评估是一个持续不断的过程，CMM的目的是为了帮助目标企业改进其软件开发过程，而不是简单的认证，因此，每过一段时间就需要进行重新的评估，如果再次评估的时候没有达到上次评估的要求，则在CMM的发布中会修改其级别。
2. 如何在需求阶段开展工作
关于需求调研的方式和内容，在很多关于需求工作的书籍和资料中都做了非常详尽的解释和阐述。笔者在这里不想重复那些条条框框，只是想说明一下在中国现在的环境中，如何开展这项工作，以及如何使用Rose工具来进行需求的调研和辅助分析。
2.1 需求调研
如何进行需求调研，在目前中国国内的项目中，一般来说，需求调研的状态仍然处于一个非常不正规的行业状态下。
2.1.1 调研中的问题
下面有一些很实际的例子，也都是实际调研中可能遇到的问题，这里做了一个抽象性归纳，估计很多朋友都遇到过：
1、 比较小的项目，大家有一个意向性的要求，我们这些软件开发商就开始了需求调研的工作，甚至没有签署任何的合同，只是一个表面的意向。在开发过程中，用户就会提出各种各样的问题和要求，以至于需求工作无法正常进行，当然有些时候加上我们开发人员对于用户的业务不熟悉，也会造成双方的隔阂，影响需求工作的进度。
2、 对于比较大的项目，公司也特别想得到这个单子，于是就逼迫我们开发人员，必须如何如何，不惜一切代价去拿下单子，这样也会造成在还没有签订合同和正式协议之前，我们开发人员就不得不进入用户的工作区进行需求的调研工作。
3、 最近一年多以来，用户方也不像几年前那样了（后面我们会说明一年多以前的状态），用户会要求我们先拿出相应的产品或者软件，然后才会考虑和我们签订进一步的合同，用户甚至希望，先试用软件（其实是使用软件），然后签合同，合同签完，软件就全部交付！
2.1.2 过去和现在的对比
几年前，至少在一年半以前，用户还处于下面这种状态：只要软件公司有些名声，派出几个人到客户那里去说几句话，做一个大的规划，用户就会很友好的和软件公司签订协议或者合同，开始软件的开发，虽然客户要求的开发时间很短，实现的功能要求也有很多不合理的地方——其实这两种现象现在仍然存在，这是一个矛盾，也许是无法调和的矛盾，只能具体问题具体分析具体研究具体解决。
现在，大概是从一年前开始，用户方面明显成熟了很多，尤其是在一些大型行业，诸如：电信、税务、电力、金融等。用户方面往往对于一些大型系统的开发，自己已经有了一些成型的考虑，也许是经历了这么多年来的一些折磨，用户方面也开始形成自己的专家组，同时招聘一些相关的技术人员进入其行业内部参与这种信息化，或者说是e化的流程。用户方的技术组往往会提出一些更高层次的理解和要求，同时进行多方的对比，比如一些行业出现了软件系统的工程过程分阶段签约分阶段实施的现象：用户说，我先和你签订做需求的内容，经费也允许的话，我会找很多家来一同做，看看谁做得更好，然后，再进行第二阶段的招投标，再决定下一家谁能够继续开发……
2.1.3 现象的分析
这，其实是一个好现象，从另一个方面要求我们这些软件公司，软件开发者，能够真正进行工程化的管理，而不是过去的作坊式的开发。对于我们的分工也更明确了，同时在我们这些开发人员中，同样有人提出了这样的很好的理念：是否可以成立“系统分析师事务所”——律师有他们的律师事务所，医生有他们的诊所，我们软件开发者也可以提供类似的工作，对于需求分析这种难度较大，对个人经验和素质要求相对较高的工作，我们也可以考虑成立属于我们自己的专业性工作室——系统分析师事务所。当然，目前还没有，按照国际上已经存在的类似的公司，大概这样的事务所在五年到十年左右的时间内会同样出现在中国大陆上——笔者妄下了一句断语，各位兄弟多多参详，当然，还有各位大姐小妹也多多指教。
其实，这样的要求是合理的，随着工程化的实施，我们的软件产业也要真正的成为一个产业，一个正规的产业，而不是过去的手工作坊。我们将来完全可以培养一些高中程度的毕业生或者一些计算机职业中专生来进行最低层次的编码工作——但是，这并不是说，大学生毕业后不需要从是编码工作，或者中专生就不能从事更高层次的开发工作！相反，笔者身边有一位老大就是中专生，但，他的确是一位非常厉害的高手，这里就不方便提出他的名字了，否则，笔者就有攀龙附凤之嫌了。

--------------------------------------------------------------------------------

青人来自崇山间，润心爱在百丈崖。
意如纸雪斩污处，愿胜天下唯文雅。

--------------------------------------------------------------------------------
[ 本文发表于 2002年12月11日 11:45:31 ]