需求分析（中文版）

　　 本书首先明确了需求分析的目的及其重要性。然后作者通过介绍、分析现有的多种技术，来解释如何进行有效的需求分析。书中为读者掌握从商业角度到软件构架的过程提供了有效指导。
　　 本书可作为软件学院及大学计算机等专业相关课程的教材，也可以作为软件公司各级管理和开发人员的参考资料。
　　

第1章 软件构架框架
1．1 zachman框架
1．2 构架框架
1．3 分析过程
1．4 含义
第2章 项目管理
2．1 引言
2．2 开发阶段概述
2．3 关于战略
2．4 关于需求分析
2．5 工序1：确定范围
2．6 工序2：规划工序
2．7 工序3：收集信息
2．8 工序4：对企业进行描述
2．9 工序5： 确定对新系统的需求
2．10 工序6：确定现有系统的环境
2．11 工序7：筹划变迁
2．12 小结
第3章 第1列：数据
3．1 对数据的看法

　　 需求分析就是对系统开发工作提出明确要求的过程，是软件开发的一个重要环节，其结果将成为后续的系统开发工作的基础。软件开发人员都清楚需求分析的重要意义，或至少知道有这样一个环节。但在实际开发时，经常由于种种原因而在需求分析这一环节偷工减料，其结果是在后续阶段付出更高的代价。
　　 需求分析又是一项复杂的工作，其实践经常缺乏有效的理论指导，将分析与设计混为一谈者也不鲜见。本书不是简单地阐述需求分析的某种(些)技巧，而是以更广的视角，全面而清晰地阐述了应如何进行需求分析。在系统开发生命周期和软件构架框架两个概念的基础上，借鉴前人的研究成果，给出了构架框架，指出需求分析过程中所运用的任何技巧(无论本书是否讲到之)都可填写到此框架矩阵中。全书内容按照这一框架而展开，对需求分析过程中可运用的各种方法和技巧做了全面介绍和精辟分析。这一框架既可使读者清楚地认识到系统开发是由具有不同观点的若干类人员共同完成的这一基本事实，又可帮助读者加深对每一种开发技巧的认识，为需求分析实践提供了明确的指导。
　　 本书作者David C.Hay在信息技术领域经验丰富。自20世纪80年代中期以来，一直潜心从事用于战略信息规划和需求规划的数据模型的研发，并出版有关数据模型方面的专著。他的公司——Essential Strategies公司一致力于帮助客户确定信息构架、搞清需求及规划如何采用更先进的系统。
　　 本书第1～5章由孙学涛翻译，第6～8章由赵凯翻译，附录A、B、C、D由朱卫东翻译。孙学涛还翻译了前言、绪论等内容，并负责全书的统稿工作。参加翻译的还有王中尚、张力等。计算机文献的翻译在语言和计算机专业两个方面对译者都有较高的要求，虽然我们付出了巨大的努力，但书中可能仍有不妥之处，欢迎读者批评、指正。
　　 译者
　　 2004．1．30
　　

　　 编写此书的源起：面向对象的分析
　　 近年来，面向对象的编程极大地减少了开发系统所需的时间和精力。作为一种来自实时系统的技术，面向对象技术已经成功地应用到了基于视窗的交互式界面及其所支持的系统。面向对象技术的优点之一是模块化程度高，这使得我们可以在无需对整个系统做大的改动的情况下，方便地构建和修改系统的某些部分。而且，模块还可以重用。
　　 同时，面向对象的思想已经影响到了需求分析这一领域。市场上已经出现了许多本关于“面向对象分析”的著作；而且，作为对这一技术的支持，UML也走上了历史的舞台。
　　 但与这一状况相伴的，有3个问题。首先，像所有其他程序员一样，采用面向对象技术的程序员，一般更多关注的是编写程序的技术，对分析某个企业的本质并无多大兴趣。进行这种分析需要其他一些技巧，而这些程序员不大可能具备这些技巧。似乎有人认为面向对象的设计师就是自然系统的分析师，而实际上未必如此。
　　 其次，有些作者认为需求分析是面向对象技术所特有的现象，而并没有注意到来自信息工程或其他方面的一些思想的作用，尽管它们与面向对象领域无关。这种想法有很多问题，其中一点就是简单地忽略了这些数十年来对面向对象领域一直都具有重要作用和价值的学科。
　　 例如，1991年，James Rumbaugh、Michael Blaha、William Premerlani、Frederick Eddy和William Lorensen共同出版了Object-Oriented Modeling and Design一书。此书中给出了一种对象建模表示法，同时还给出了一种称为“对象建模技术”(Obiect Modeling Technique，OMT)的方法。这种表示法中包括若干符号，其中有些表示的是与10年前Clive Finkelstein和James Martin在某信息工程文献中相同的概念。OMT考察的是对象类(实体类型)、关联(关系)和属性。
　　 这种方法虽然号称与“传统软件开发方法”[Rumbaugh等，1991，第146页]有着很大不同，但实际上与信息工程方法很相似。像信息工程方法一样，这种方法也是基于“把开发工作转移到分析”、“在考虑功能之前强调数据结构”和“无缝开发过程”等原则的。而这些原则就是Finkelstein先生和Martin先生早已申明的原则。这两种方法之间的一个比较明显的差异是OMT方法具有更多的面向交互的特色。
　　 在Object-Oriented Modeling and Design一书的第12章，提到PeterChen是实体／关系建模方法的创建者，并称对象建模技术直接来自于实体／关系建模方法[Rumbaugh等，1991，第271页)。但此书的其他部分并未体现出这一点。
　　 现在的需求分析实际上综合了30多年来许多人的贡献。需求分析在系统开发生命周期中的作用比以往更为重要——即使是采用了面向对象技术。与某些人的说法不同的是，需求分析并没有随着这些技术的出现而发生根本变化。
　　 面向对象的思想确实对需求分析有所贡献，但这种贡献要比某些人的说法小得多。需求分析就是要搞清商业上对信息技术的需求，而不是为了确定应用哪种技术来解决这些需求。正确的需求分析结果应能够指引设计师使用任何技术。
　　 第三个问题则来自那些坚持认为需求分析中应包括“面向对象特色”的作者。“控制对象”和“接口对象”都是来自面向对象设计的，但经常被(不合适地)当作需求分析的一部分。
　　 实际上，确定需求的过程与应用某些技术来满足需求的过程有着根本区别。在不必考虑(除了泛泛的了解之外)采用什么实现技术的情况下确定出需求应该是可能的。对同样的一组需求，可能既可以用面向对象技术来实现，也可以采用Oracle公司的关系数据库工具来实现，还可以用某组COBOL程序来实现。
　　 关于本书
　　 本书没有从某一特定实现技术的角度来看待需求分析，而是把需求分析看作是构架层次上的一个过程。具体来说，需求分析就是要回答以下的问题：我们怎样才能搞清企业的体系结构，从而使所要开发的系统能够真正支持这一构架?为此，本书尽可能多地介绍了整个系统开发历史上出现的最优秀的技术和方法(包括来自面向对象领域的某些技术和方法)，并将讨论在开发面向对象的系统或其他系统时应用这些方法和技术是否合适。
　　 Merriam Webster把“构架”定义为“某种统一或一致的形式或结构”[Merriam Webster，2001]。本书为需求分析而描述某构架时，就是在描述整个需求过程的结构。本书受到了John Zachman所做研究的影响，他用一种矩阵来描述系统开发的构架。这一矩阵的行对应于开发过程中各类人员的观点，列则对应于将从各个角度考察的事物。本书所讲述的各种技术对应于这一矩阵中的各个单元格。
　　 本书假定需求分析就是把某企业的企业所有者视图转换成关于该企业的一个全面的构架视图。本书开头几章是一般介绍，之后对从这两种角度看的每一方面(什么、怎样、何处、谁、何时、为什么)各用单独一章讨论。
　　 虽然本书主要关注的是上述两行，但对“范围一行”也必须予以重视，它把我们所做的全部工作都考虑在内。另外，为便于理解(但仍坚持上述观点)，也会偶尔提及对采用某一技术的设计师来说应该受到的启示。
　　 尽管从某种意义上说，本书将涉及某些已有人研究过的领域，但本书独具特色。这是因为本书对分析项目可能给出的各种结果都做了介绍。这种全面性是绝大多数同类图书所不具备的。本书不仅讨论了对数据和处理的分析，而且还阐述了对数据网络、人员与组织、事件、动机等方面的分析。
　　 本书并不是像推理小说那样可以匆匆看完的作品。绪论、第1章和第2章对这一领域做了全面介绍，并指出了应预先阅读的文献。其余6章则既是路线图，又是参考手册。之所以说它们可以起到路线图的作用，是因为它们对构架框架36个单元格中的12个做了一一介绍，并阐明了它们之间的相互联系；说它们是参考手册则是因为对所讲述的每个单元格，都介绍了可采用的多种技术。如果读者曾听说过某个技术，想对其深入地了解并搞清
　　这种技术在全局中所起的作用，应该能够在这些章节中得到满意的答复。

　　 在我儿子5岁时，他与那个年龄的大多数孩子一样，对周围的世界充满了好奇。我在读Dave的这本书时，他天真无邪的样子又浮现在了我脑海中。当时我们一家人正在划船，儿子问船为什么能够浮在水上，而不会沉下去。
　　 为了说明当时的情况，这里有必要交待一下：我丈夫是土木工程师，我是搞数学的。所以，上面这个问题正是我们乐于和孩子们探讨的。实际上，当时我们对儿子的这个问题确实表现出了极大的热情：很精辟地介绍了阿基米德定律，并用该定律的输入、输出参数做了全面的讲解。
　　 那么，熟悉5岁儿童的读者已经知道这样做的结果了。当时儿子立即变得不耐烦起来，他对阿基米德根本不感兴趣。他仅仅是想知道：是船的原因使之能够浮在水上，还是水的原因把船托了起来?
　　 这确实是让我们做父母的感到困惑的典型情况之一：当时我和丈夫哑口无言。这是什么问题?应怎样回答?
　　 当然，John Zachman的框架为解决我们的这种困惑提供了思路。他的框架告诉我们：对同一现象，我们可以用多达6种角度去研究。业务专家和信息构架师的看法不一样，信息构架师和系统设计师的观点也互不相同。更重要的是，每种看法都是合情合理的。
　　 通常，对同一事物(如上面的小船)，观察者总是用他感到最直观的角度去观察它。显然，可怜的儿子当时最希望采用一种直接、具体的视角，弄清所关注的对象受到控制的原因。而我和丈夫当时则更喜欢用所涉及的科学基本定律(或业务策略和父母的道理!)去解释它。
　　 但这两种(及其他一些)看法对这艘小船来说都是合理的——即使当时我们对此还不十分清楚。
　　 在过去的数十年间，因看法的不同而导致的混乱令信息行业的从业人员备受磨难。今天，有了Zachman框架，我们对这一问题认识得更清楚了。换言之，现在我们知道：如果两个人讨论同一个待开发的系统，但却相互不理解，很可能是因为他们各自考虑的是这一框架中的不同内容。未必哪一个人就是错的或考虑不全面，他们只是从不同角度看待同一问题而已。
　　 但Zachman框架则是一种总的视图，其中包括各部分结果在总蓝图上(或者在如Dave在本书绪论中所说的乐谱中)如何关联及在现实世界中如何关联。
　　 要创建这样的蓝图是相当困难的。Zachman框架清楚地表明了这一挑战的广度和深度。但作为具体实践者，我们该如何按照这一框架展开工作呢?直到现在，读者还是靠自己的摸索。但是，Dave的这本书为我们提供了极好的指南。而且，Dave还在书中对这一框架的各个部分所涉及的各种技术做了全面介绍，从而明确了如何把设想转换成构架。
　　 该书的重要价值体现在3个方面。首先，它既适用于新手，又适用于有一定经验的人。因为本质上，此书是对历史的回顾，是一本教程。其次，它对任何读者都有一定价值——无论读者对某个特定系统开发持什么态度。这是因为该书把读者熟悉或不熟悉的学科中所采用的技术很好地结合了起来。其中既有已经验证过的结构化系统分析技术，又有信息工程技术、面向对象技术和最新的商业规则方法。该书作者希望此书成为定义从设想到构架的路线图的权威之作。该书重点突出，条理清楚(这是Dave的写作风格)。我们可能要感谢Dave对这一领域的见解，也感谢他以这样正式而又有趣味的形式与我们共享这些成果。
　　 第三，最重要的是，该书提升了(很有必要!)需求分析工作的重要性。为什么需求分析这么重要呢?
　　 Dave指出：在软件开发行业，我们经常是在没有明确要求的情况下工作的，这很让人烦恼。我们就是即席创作者的典型代表。Knowledge Partners公司的Bob Giordano指出，这并非什么新情况。他说：“我们一直用重复的方法来开发。在20世纪70年代和80年代，由于独立系统总是把所有内容耦合到一起，所以每一次这样的重复要历经数年，耗资上百万。”
　　 今天，这种重复现象更明显、更普遍，或许随着近年来采用重复开发方法的日益增多和范围的扩大，更加剧了这一现象。毫无疑问，这些趋势对系统开发的某些方面——对那些不确定的或随意性的部分——是有益的。但是否暗含有以牺牲分析的基本要素为代价的情况呢?或许是有的。
　　 ， Dave指出，我们是为了最终结果的简单而进行分析。需求分析的目的之一就是为了防止开发出实际上没有必要的复杂系统。分析还可以帮助我们搞清将要发生改变的成分。当今世界，变化的速度越来越快，存在着各种不确定性。当我们开发的系统投入使用时，世界的变化不会终止。因此，我们开发的系统应具有适应变化的能力，使变化永远成为这场游戏的主题——并且不必付出过高的代价。否则，我们的系统可能会有效地使用到某个时间，然后就开始起消极作用。
　　 我们正在用信息技术确定商业变化的速度和方向。我们应该遵循某种规定，使充满不确定性的未来能够有条不紊地展现在我们面前。在创建这种规定时，以本书为指南吧。
　　 时间过得真快。儿子提出船为什么浮在水上这一问题已经是许多年前的事情了。可以想见，儿子可能早就忘了曾经提出过这一问题。已经长大的他像所希望的那样，通过阿基米德定律对这艘船的行为有了更深刻的认识。
　　 到底应该怎样回答儿子当年提出的这一问题?我仍然不知道。因为对他当时的看法，我并不完全清楚，而只知道其中的某些部分。
　　 但是，如果想要搞清这一问题的答案，我可以到上面所说的蓝图中去找。
　　 这样找到的答案会是很完美的。同时，由于其他人的工作，这种答案似乎也是简单的。正如读者将看到的那样，在这种蓝图上的投资是非常有意义的——因为它代表了分析上所做的深入思考。这种思考一方面考虑到了系统的简单性，另一方面也考虑到了适应变化的能力。有了这两方面(简单性和灵活性)的考虑，这种蓝图(或乐谱)就能够经受得住时间的考验。如果跳过了需求分析，就无法享有这些成果。Dave将帮您搞清楚这一切。