OOA&D实践之路——真实案例解析OO理论与实践（五、需求分析之前的故事）

查看本系列全部文章：
《OOA&D实践之路——真实案例解析OO理论与实践》索引贴

高质量软件的第一要素
      到目前为止，我们做了很多工作，但是我一直在强调这些都还不是需求分析。在很多人心目中，软件开发的第一件事就是先做需求分析。那么我们为什么不这样做呢？这牵扯到一个关键的问题：我们都希望开发高质量的软件，而本系列文章的重点也是如何通过OO实践开发高质量软件，那么什么是高质量软件？
      对于这个问题，也许很多人会说，是灵活的、是易于修改和扩展的、是可维护性高的、是用户体验好的、是文档完整的、是代码规范的、是性能处理优秀的……好吧，我承认，这些都是高质量软件必不可少的元素，但是，还有一个更重要的要素，就是：软件必须做客户希望它做的事。你的软件再灵活、编码再规范，客户不关心，客户最关心的是软件是不是完成了他期待的功能，可以做他希望软件做的事。所以，高质量软件的第一要素就是：让软件做客户希望它做的事。
      知道了这点，就知道为什么第一步不是做需求分析了，因为需求分析的重点不是“让软件做客户希望它做的事”，而是“将需求分解归纳成开发人员容易进行领域分析和设计的信息片段”。所以，需求分析是开发人员面的东西，而不是客户面的东西。作为开发人员，我们要首先站在客户的角度看问题，而不能总是站在开发人员角度，和客户隔着一条河对话。我们要走过去，去河的另一岸。

回顾我们的工作
      现在来总结一下我们目前所做的工作，你会发现，我们所做的全部工作，其目的就是让软件做客户希望它做的事。
      我们首先总结出特性列表，然后通过分析和询问降低了风险，同时修改了特性列表，最后从做出一张用例图，使得从全局角度对系统进行一个概览。所有这一切，其实都是开发人员在“努力变成客户”，或说努力让自己站在客户的角度看系统，真正了解客户想让希望做什么。因为，最好的理解需求的方式就是理解客户想让系统做什么。

我们在哪里？看看地图吧
      做了这么多工作，是不是有点迷失方向的感觉？似乎我们已经迷失在OO从林中，不知现在身在何处。好的，那我们看看“OO地图”吧，一方面搞清楚我们在什么地方，另一方面看看我们后续有哪些路要走。



      以上就是实践中的大致开发流程。一般来说，开发大致分为两个阶段：前一阶段我们要站在用户角度，搞清用户想要系统做什么；后一阶段要回到开发人员角度，进行分析、设计、编码、测试等一系列操作。而我们现在正处在两个阶段的交界处。
      一般在迭代阶段提倡使用迭代与增量的方式进行开发。至于这样有什么好处，以及OO如何于迭代增量方式结合这些问题，我们将在下一篇文章中结合我们的案例详细讨论。

重点总结
      1.高质量软件的第一要素是：软件做客户希望它做的事。
      2.在开发初期，我们要尽量站在客户角度。
      3.理解需求的最好方法是明白客户希望软件做什么。
      4.开发流程大约分为两个阶段：搞清用户想要系统做什么和迭代开发。

作者：T2噬菌体
出处：http://leoo2sk.cnblogs.com
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。Tag标签: 面向对象,OOposted @ 2008-12-13 11:13 EricZhang(T2噬菌体) 阅读(2048) 评论(17)  编辑 收藏 网摘 所属分类: 面向对象技术
发表评论  回复  引用     #1楼 2008-12-13 11:53 | CS1 [未注册用户] 我们一直“试图”站在客户的角度
  回复  引用  查看     #2楼 [楼主]2008-12-13 12:15 | T2噬菌体       @CS1
多谢提醒，已经修改
  回复  引用  查看     #3楼 2008-12-13 13:08 | 飞鱼2006       你的地图看的有点晕，用例图是需求分析的产物吧?没有需求分析哪来的用例图？
  回复  引用  查看     #4楼 2008-12-13 13:16 | Astar       楼主加油
  回复  引用  查看     #5楼 [楼主]2008-12-13 14:21 | T2噬菌体       @飞鱼2006
用例图不仅仅用于需求分析。UML本身是一个交流工具，并没有规定某个图必须用于什么阶段。
用例有业务用例和系统用例之分，用例本身还有不同的粒度，不同阶段可以根据具体需要绘出相应用例图。需求分析阶段主要是分析用例，用例图以系统用例居多。在这之前，一张粗粒度的业务用例图有助于全局把握系统。具体请看上一篇文章。而且在用例驱动迭代开发中，主要指的就是这里的粗粒度用例图而不是需求分析阶段的用例图，具体在后续文章会详细阐述。
  回复  引用  查看     #6楼 2008-12-13 14:35 | 飞鱼2006       @T2噬菌体
粗粒度的业务用例图也得需要对需求分析才能得出啊,难道是凭空想想的？
  回复  引用  查看     #7楼 2008-12-13 14:38 | 飞鱼2006       @T2噬菌体
假如我不说任何需求，只是说我要一个系统，那怎么画出一个粗颗粒的用例图呢？肯定还得知道我要一个什么样的系统，大概有什么样的功能，然后根据这些信息才能画出一个粗粒度的用例图。有了对需求的粗粒度的分析才能有粗粒度的用例，用例图的粒度和你对需求分析的粒度是直接关系的
  回复  引用  查看     #8楼 [楼主]2008-12-13 15:12 | T2噬菌体       @飞鱼2006
呵呵，这个用例图是根据特性列表画出的，一般这个阶段不看做需求分析。如果你觉得这个阶段是需求分析，也未尝不可。这不重要，重要的是这个过程一般是这样的。不知你有没有看前几篇文章，看过后你也许就会明白这个用例图是怎么出来的。
  回复  引用  查看     #9楼 2008-12-13 17:20 | o﹎箜絔┌↘       一天一篇呀。。呵呵。。继续学习。。。
  回复  引用  查看     #10楼 2008-12-14 17:43 | 金色海洋（jyk）       越来越不明白“需求分析”的含义了。
  回复  引用  查看     #11楼 2008-12-14 18:03 | 金色海洋（jyk）       http://baike.baidu.com/view/111493.htm

我到baike里面查了一下“需求分析”的解释，感觉“OO地图”的前五站都属于“需求分析”的范围。

　在软件工程中，需求分析指的是在建立一个新的或改变一个现存的电脑系统时描写新系统的目的、范围、定义和功能时所要做的所有的工作。需求分析是软件工程中的一个关键过程。在这个过程中，系统分析员和软件工程师确定顾客的需要。只有在确定了这些需要后他们才能够分析和寻求新系统的解决方法。
　　在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中最简单的一个步骤，但在过去十年中越来越多的人认识到它是整个过程中最关键的一个过程。假如在需求分析时分析者们未能正确地认识到顾客的需要的话，那么最后的软件实际上不可能达到顾客的需要，或者软件无法在规定的时间里完工。

特点：
需求分析是一项重要的工作，也是最困难的工作。该阶段工作有以下特点：
　　（1）用户与开发人员很难进行交流
　（2）用户的需求是动态变化的
（3）系统变更的代价呈非线性增长

  回复  引用  查看     #12楼 2008-12-14 18:04 | 金色海洋（jyk）       一、确定对系统的综合要求
　　虽然功能需求是对软件系统的一项基本需求，但却并不是唯一的需求，通常对软件系统有下述几方面的综合要求。
　　1.功能需求
　　2.性能需求
　　3.可靠性和可用性需求
　　4.出错处理需求
　　5.接口需求
　　6.约束
　　7.逆向需求
　　8.将来可能提出的要求

  回复  引用  查看     #13楼 [楼主]2008-12-14 18:38 | T2噬菌体       @金色海洋（jyk）
其实不用抠这些字眼，因为像“需求分析”这样的词，并没有一个统一的定义，很多书都各执一词，再说很多词有广义和狭义之分，在我的文章里，需求分析定义为一种狭义的意思，主要指开发人员为领域分析和设计工作对需求信息进行的一种分析和分解。
我的文章中什么是需求分析不是重点，重点是整个过程。
  回复  引用  查看     #14楼 2008-12-14 21:26 | 金色海洋（jyk）       我也不想抠字眼，只是我很晕。呵呵。
  回复  引用  查看     #15楼 2008-12-15 09:39 | relax       周末博主也更新了两篇，敬业~！

  回复  引用  查看     #16楼 [楼主]2008-12-15 09:46 | T2噬菌体       @relax
以后更新就慢了……要考试了……7门……T_T
  回复  引用  查看     #17楼 2009-04-10 13:35 | 遇到技术       楼主的例子太小，阶段又划分了这么多。如果是一个大系统这么做就会要命了，大系统不仅仅小系统的和，而且还有很多小系统之间的关联及概括。如果这么多的阶段分下去，需求工作就恐怕遥遥无期了。