基于Rose的全程建模之三

[青润]

基于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 现象的分析
这，其实是一个好现象，从另一个方面要求我们这些软件公司，软件开发者，能够真正进行工程化的管理，而不是过去的作坊式的开发。对于我们的分工也更明确了，同时在我们这些开发人员中，同样有人提出了这样的很好的理念：是否可以成立“系统分析师事务所”——律师有他们的律师事务所，医生有他们的诊所，我们软件开发者也可以提供类似的工作，对于需求分析这种难度较大，对个人经验和素质要求相对较高的工作，我们也可以考虑成立属于我们自己的专业性工作室——系统分析师事务所。当然，目前还没有，按照国际上已经存在的类似的公司，大概这样的事务所在五年到十年左右的时间内会同样出现在中国大陆上——笔者妄下了一句断语，各位兄弟多多参详，当然，还有各位大姐小妹也多多指教。
其实，这样的要求是合理的，随着工程化的实施，我们的软件产业也要真正的成为一个产业，一个正规的产业，而不是过去的手工作坊。我们将来完全可以培养一些高中程度的毕业生或者一些计算机职业中专生来进行最低层次的编码工作——但是，这并不是说，大学生毕业后不需要从是编码工作，或者中专生就不能从事更高层次的开发工作！相反，笔者身边有一位老大就是中专生，但，他的确是一位非常厉害的高手，这里就不方便提出他的名字了，否则，笔者就有攀龙附凤之嫌了。
……

[w102272]

To mmyytt_2000(小马) ：
老天，我同意你的软件需求工程过程(SREP)的描述，但这么干就太累了。
软件设计那里已经在轻量化，你这里还这么弄，太麻烦了。
能作需求分析的SA本来就没有几个，领域专家就更少了，都照你这么干，就没法干了。

[w102272]

其实我看完全没有必要这么复杂，需求这里只需要考虑1件事情，并细化两个因素就足够了。我的词汇定义可能不专业，请指正。

1.建立一个清晰的业务模式图。业务模式包含了所有业务运行过程中需要体现
的软件，硬件，人，信息流动和处理，以及最终价值的体现。这个图用户必
然看得懂。

2.核心要素（业务功能，潜在需求，以及项目成功的重要影响源）的列表，
并细化。

3.各种约束的列表，并细化。

至于工作是SA完成还是领域专家完成，这都不重要，就一直沟通完成到能向IT架构映射的程度就可以了。
至于你那个需求获取，分析，协商，评审，文档写作，确认，配置管理，说到底好多时候不过就是发生在我们头脑中的一系列连续的快速思考过程罢了。用得着那么机械化吗？

除了配置管理我认为是必要的，因此你毕竟要记录和整理下来需求。

再多说一句，SA和领域专家就是要相互学习，我看最后迟早要先融合后分化。
有一个“需求系统分析员”的职业出现，从产品，利润，销售，领域知识，
商业，信息处理需求，行业发展趋势，约束等各个方面就需求建模，领域知识
必须100%体现在产出的新信息处理模型中。现在的需求捕获不过是把用户片断
化的想法摘录下来整理罢了。其实我们都知道信息系统本身处理模式和传统模
式就是不一样，必须要“源于应用，高于应用”。

如何“源于应用，高于应用”？这本身就是创新。不是什么机械的分析过程。
机械化的需求分析过程，充其量就是邯郸学步罢了。

实施软件工程的目的是为了解决软件危机，保证工期，质量和资源开销。
那保证工期，质量和资源开销的目的又何在呢？

在表层的IT需求下，隐藏了大量的潜在需求和约束，不分析出这些东西，
又如何知道一个完美的软件工程自身，自身是不是合理呢？？？

[zxl_l]

to qingrun:
'在我们获取了的业务需求后（不一定需要完整的业务需求才可以进行下一步的工作，但最后一定要拿到完整的业务需求），我们就可以开始对他们进行分析，分析的过程其实是需求的深化理解的阶段',不但是需求的深化理解，更主要的是分析出业务需求调研的不足部份(分析能力和经验的体现)，最后能拿到完整的业务需求。

[szfanke]

看了各位关于需求的讨论，也谈一下个人的体会，请指正：

需求的重要程度在软件开发的整个生命周期内是众所周知的。楼上关于软件需求工程过程(SREP)的描述可以看作是理想状态下的完整过程，实际使用中也应该是根据项目情况而栽剪的。

对于中小型软件项目的需求获取，我认为较好的办法是从两个方面入手：

一是由客户、项目经理、业务流程分析员共同制定业务需求,这里所指的业务流程分析员应该业务领域专家和技术专家，在不具备的情况下才会是系统分析员。需要注意的是，业务需求是以客户为主导，业务需求的制定是为了合理、充分的榨取用户的实际业务需求。业务需求的描述方法应该是通俗的、易懂的、站在用户角度的、用户及开发商共同确认的基础需求。它应该类似XP方法中的user story，它也应该是软件项目客户验收的标准之一。

二是由系统分析员、业务流程分析、项目经理共同制定的功能需求（包括技术性很的非功能需求）。功能需求应该是在业务需求的基础上，以系统分析人员为主导而制定的用于指导设计、开发的技术性需求。功能需求应该是站在设计人员、开发人员的角度描述的项目组内部人员充分认可的基础需求。它应该是项目测试及内部验收的标准之一。

在需求获取的过程中，业务需求及功能需求的分离的好处是十分明显的。对较小的软件公司，人员角色难以确定的情况下，也应该尽可能由客户、项目经理完成业务需求，系统分析员、项目经理完成功能需求。这里项目经理的角色定义从严格意义的软件过程中来说是错误的，但在很多软件公司角色不全的实际情况中，项目经理通常应该是角色多变的。

需要强调的是，业务需求应该是以用户为核心，项目经理也好、业务流程分析员也好，都应该站在用户的角度来考虑问题、描述需求。功能需求是以系统分析员为核心，从专业的角度、技术可行性的角度去对业务需求进行需求建模。在这种思想指导下，项目组内部项目经理（业务流程分析员）、系统分析员应该是即对立又沟通的角色，项目经理（业务流程分析员）应该站在用户一方对项目进行严格的要求，系统分析员应该站在开发一方保证项目的技术可行性及合理性。这样通过对立、沟通、平衡之后，产出的项目才能更容易达到用户及开发商的共同目标。而很多的软件公司，项目经理、业务流程分析员、系统分析员、开发人员全部站在开发商的角度来考虑问题、获取需求、设计系统，这样出来的系统，用户抱怨自然是很难避免的了。

[青润]

to zxl_l(凌龙):
当然是这样。我在前面并没有说一定要全部稳定下来才可以进行下一步的工作。
但是你能够进行下一步工作的内容一定是稳定下来的内容，或者尽可能基本稳定的内容，否则，一天一改的方式会让分析人员“造反”的！
分析的时候是对需求的深入理解的过程，会让你发现一些调研时没有遇到的问题，但其实，如果你仔细研究一下你后来提出的问题，你会发现至少50%都是当时问过的问题，但是却没有清晰地记录下来或者两个人记录的有偏差或者造成理解上的不同而不得不找用户再次询问。
这也就是在进行用例阐述过程中会经常需要反复的过程，但是分析的主要目的不是为了分析出调研不足的部分，他是为了让开发人员可以更好的理解需求并进行下一步的设计任务。这两者的轻重缓急是有差别的。
在开发过程中，每个阶段都会有一些前一阶段的工作反复，但是，一定要抓住当前阶段的工作重点和中心，不要偏离了，否则，你的项目就很难以调控了。因为你的脑子就会被首先搞乱。

[mmyytt_2000]

我觉得精简后可以把需求工程的活动划分为以下5个独立的阶段：

　　（1）需求获取：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求；

　　（2）需求建模：为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义；

　　（3）形成需求规格：生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约；

　　（4）需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性；

　　（5）需求管理：支持系统的需求演进，如需求变化和可跟踪性问题。

[商海连横]

mark!

[zhoujian2003]

青润兄：
可否将您在《程序员》中的《基于Ｒｏｓｅ全程建模实例》的内容更详细的发到我的邮箱[e-mail].
不胜感激！

[青润]

zhoujian2003(财迷)，这个我可能做不了。你如果要要的话，请与amone联系，因为这是投稿，我不能随便散发。请见谅。

[chengl1977]

给位好，小弟也一直在试图能够将软件工程理论应用到日常的系统设计与开发过程中。只是在实行过程中，文档的编写总是跟不上。目前用户需求的分析过程已初步掌握，能够比较完整的理解用户的需求，同时与用户一同进行新的需求设计。小弟认为，在做需求分析的过程中，需要保持与用户最密切沟通，需要花一番力气使得用户能够明白你的意思，也就是我们需要让用户看得懂我们的数据流程图和功能模型图。这两个图是我们根据用户对系统的初步要求转化而来，进一步就需要用户和需求分析人员共同来完善和修整这两个图形。

[lizongqi]

收藏

[warren04]

up

[zgpp]

收藏一下

[marsan]

各位师兄的高见，小弟看后收益非浅啊！！
希望以后会长看到！！！

[MouseEasy]

thanks!
继续关注

[susuny]

thanks!

[susuny]

thanks!

[青润]

放假回来了。
这个贴子也够长了。结清去年的帐！呵呵，顺祝大家新年快乐！

[zgpp]

关注

[zlq219]

呵呵，开始学习