	探究需求管理的本质勇于直面需求变更从程序员到系统分析员需求的问题互连网软件工程浅谈浅谈网站工程的管理与规范系统规格说明典型系统分析边际需求递减规律如何写系统分析书
	探究需求管理的本质 ------什么才是需求管理（作者：万成编译　2001年03月13日 10:03）　　本文旨在探究需求管理的本质，需求管理所要涉及的任务在文中将适时提及，以阐释"需求管理之需求（requirements for requirements）"的涵义。 ☆概要　　需求管理恰如裁缝的量体裁衣，它直接关系到最终产品的成型。仅从字面出发，如果一个产品满足了客户需求，那它无疑就是成功的。需求管理的过程，从需求分析开始贯穿整个项目始终，力图实现最终产品同需求性的最佳结合（参见Figure 1）。通过对需求管理在项目进程中实施的不同任务进行分析，我们可以看出需求管理所起的作用。　　需求管理能够确证：　　●我们确知客户的需求是什么（质量）；　　●满足客户需求的最佳解决办法（统一性）；　　著名学者Crosby对于质量的定义是"同需求保持统一"。从这个意义上说，需求管理正是从质量出发以确定需求。每个人都应当始终明白他们所做的具体任务其意义何在。然而，在一个产品的生命周期里，其需求性是能动的，是处于变化之中的。　　对于系统工程没有严格统一的定义，因此很难找到足够的数据以说明系统工程所起的作用。有些致力于研究需求分析的组织认为，一项开发计划应当至少将8-15%的资源投入到系统工程方面。如果低于这一标准，将很可能导致无法对客户群做出准确把握。如果该项开发计划含有许多创新或实验的成分，那么这一百分比还应当适度提高。 ☆需求管理所要完成的任务　　可以说需求是一种模型，是产品的早期雏形，通过进行需求分析，我们可以对最终产品做出优化。需要始终保持注意的是，需求性是始终处于变化之中的。需求管理需要完成的任务包括：　　●明确需求并达成共识；　　●建立关联；　　●根据不同需求设计相应解决办法；　　●进行系统优化；　　●提出设计方案；　　●监控和解决可能出现的问题以及需要做出的改变；　　●控制不同开发任务的开展；　　●对最终产品做出评测；　　●监控可能出现的重复开发；　　●提出项目实施时间表；　　●确定最终用户界面。　　有时侯我们所进行的需求分析只停留于分析本身，而没有进一步去思索我们为什么要进行需求分析。需求性是项目开发的源头，只有进行认真的需求分析，我们才能做到对症下药、量体裁衣，才能才设计开发中去伪存真，不断改进。"需求之需求"正是强调了贯穿始终的需求分析的重要。离开了能动的、变化的系统进程而空谈需求管理，无异于纸上谈兵。需求管理所产生的效益或许并不明显，或许要日后才能体现，但是无序的，没有经过精心策划的需求管理是不可能产生效益的。　　以下篇幅分别介绍需求管理在系统工程中的不同应用。需求共识：　　首先，用户需求通过非术语的形式进行表述，这种表述应当使每一位开发者明确自己的职责所在，并且清楚知道不同开发工作之间的关联。这里的"用户"泛指在实际应用环境中每一位可能使用最终产品的人。如果一个产品不能满足客户所需，那么设计方案再出色也无济于事，许多方案有很高的技术设计水准却最终不能获得成功，其原因正在于此。可以把产品功能说得天花乱坠，但却无法改变用户需求决定最终产品基本模式的事实。　　需求管理的首要任务在于使开发人员和用户双方对于需求都有一个明确的认识。因此用来进行需求分析的语言组织应当使所有相关人员，包括用户，都能够理解，都能够进而对整个项目有一个整体把握，并明确每一个人在项目中所起的作用。因而需求管理需要解决的第一位也是最基本的任务就是明确需求，并使所有相关人员达成共识。根据需求设计解决办法：　　我们在进行系统设计时，应当首先建立一个需求模型，但不能是为了建模而建模，需求模型实际是最终产品的抽象化表现。需求模型的建立使我们在明确需求的基础上更进一步，使我们知道我们将要生产何种产品，该产品都具有那些功能。同时，创建需求模型的过程也使开发者明确自己的工作如何同整个项目有机地结合在一起。建立需求模型应当充分研究不同类型、不同架构建模方式的可行性，切忌主观武断。系统优化：　　任何设计都应以考虑用户需求为优先，用户需求的满足程度即成为衡量设计优劣的标准。在一个项目设计周期中，开发人员经常会面临选择，以提炼需求，决定开发的优先次序，并在不同的实施方案中作出选择。这些选择必须考虑到收益与付出地平衡比例，这种选择的重要性尤其在建立需求模型的后期凸现出来。基本需求在这时都已明确，而实施方案还未敲定，为了使用户的基本需求得到落实，一定程度的开销用于搭建不同构架的需求模式是合理的。假使我们已经有了一套翔实的需求分析，我们甚至不必将每一套方案都付诸实行，就可以成功地对系统设计进行优化。　　面对不同的可行性而需要作出选择时，我们也必须参照收益与付出的比例关系。例如，在被要求提供计划书时（Request for Proposal），我们应当尽量做到每一份计划书的提供都物有所值。方案设计：　　明确需求后，开发人员就可以进行方案设计。通过对用户需求和设计方案之间所存在关联性进行分析比较，我们就能够对设计方案进行评估。必要的修改：　　方案的设计不可能是一成不变的，经常会有方案设计同需求相悖的情况。如果我们无法准确把握用户需求同方案设计之间的关系，我们就无法在需要对方案进行必要修改时正确判断。优秀的需求分析应当非常精确细致地对用户需求作出描述，同时也应该最大程度地给予方案设计者充分发挥的余地。任务划分：　　一个大的开发项目可能涉及20-30组不同的开发队伍，人员包括技术工程师、软件工程师以及具体项目主管等等，而每一个模块都有它自己的开发工具和开发语言。　　主持一个大项目的开发并不是件容易的事，总体项目主管的首要任务是对开发项目进行任务划分，将整体开发任务细化为多个子模块，从而使这些子模块能够平行开发而无需太多的干预。总体项目主管可以将细化的不同模块的需求分析交给不同的开发队伍，对于开发进程的监控只需参照需求的解决情况，对于具体的开发细节则不必过问太多。　　不同的开发队伍会使用不同的开发语言和开发工具，会使用不同的符号和标记。相反，作为总体项目主管所使用的语言、符号和标记等则必须简单易懂，以使所有的开发人员都等理解。换言之，总体项目主管应当使用自然语言，或只涉及少量的，简单的术语和专用词汇。产品测试：　　需求的满足情况是决定最终产品成败的判定基础，对最终产品的测试评估必须以产品所试图解决的需求为标准。下图标示了不同的开发阶段所对应的测试需求。　　这里有一个需求、产品和测试系统之间的关系问题，确定需要进行的测试属于总体开发主管的工作范畴，虽然具体工作并非都要由开发主管来亲自完成。重复开发：　　对于总体开发主管而言，针对方案设计的修改是一项经常性的工作（因为修改而造成的影响则应当尽可能减小）。在进行项目开发时，随着开发进程的深入，各种修改的建议和问题的报告是屡见不鲜的，每解决一个问题，就是将产品同其需求性的结合又完善了一步。存在问题正是需求性尚未满足的表现。　　方案设计的完善和需求性的满足是同步的，因此真正的用户对于产品的评价和建议尤其具有重要意义。在那些一步到位的产品设计中，真正用户无法左右开发进程；但在一个能够进行重复设计、重复开发的产品生命期中，开发人员应当及时搜集用户对于产品的反馈信息，并将这些信息结合到下一步的开发工作中去。如下图所示，用户反馈同产品开发是统一的。项目管理的辅助：　　在有些地方，需求管理被作为一个技术问题来处理，需求管理所针对的对象只是产品，而同项目管理所涉及的问题例如进程安排或资源分配等无关。实际上，项目管理涉及三方面问题：进程安排、资源分配和质量管理（同需求的统一）。　　　试想以下三种情况：　　●一场高水准的音乐会，预算合理，演出时间却晚了两天。　　●质量优良的小轿车，交货及时，然而造价是市价的两倍。　　●一套系统，完全满足了用户需求，但在开发过程中使用非法劳工。　　这三种情况虽然都满足了用户所需，然而缺乏实际意义，因此都以失败告终。　　"我付了钱，但这不是我想要的"，没有用户愿意这么说。要避免出现这种情况，在进行项目管理和财务预算时，也必须以需求管理为基础。仅仅完成了一件设计并不意味着工作的结束，只有这件设计充分解决了需求，它才具有里程碑般的意义。同样的，一件产品只有在测试和实际操作中完全满足了需求，已经完全准备好了投入到下一阶段的运营，才意味着这件产品在本阶段工作的结束。　　开发进程中的每一块里程碑都意味着需求的解决又前进了一步，这样的每一块里程碑也都是委托商付款的重要参照，产品开发的整个进程都可以通过需求管理进行监控。　　里程碑构造机制的基本方法之一就是进程管理，一项需求的满足就意味着一块里程碑的确立。我们应当对用户需求、针对需求而进行的模块设计以及每个子模块的开发进程之间的关联做到心中有数。　　通过我们对需求管理实际应用的分析，几个关键因素凸现出来。首先，需求管理在开发周期中是自始至终存在的。注意：不要把它简单理解为"需求周期"，需求管理必须始终保持更新，它构成了技术管理的基础。　　其次，需求管理同项目管理是密不可分的。如果我们把每一个需求的解决看作一个里程碑，并以此出发对整个开发进程进行监控，我们就应该对整体开发工作进行精密细致的划分，从而将需求分析具体化。 ☆需求管理的概念化阐释　　需求管理应当具有以下几个特征：能够在开发周期的初期就建立需求模型；建模的成本很低；易于以后的具体化和优化；本身能体现最终解决方案的特征。也许某些细节是抽象的，但需求管理模型本身必须是完整的。需求模型不应当具有诱导性或倾向性，必须为开发工作留有充分发挥和优化的空间。同时，我们能够通过需求模型对最终产品作出评估。但不幸的是，这些特征本身也不是彼此完全兼容的，很难在一个简单模型中做到面面俱到。　　在开发初期针对需求而搭建产品模型（Early Models）是容易的，成本也不会太高，但是这样的模型是很抽象的，绝非等同于最终产品。随后的产品原型（Prototypes）或高级模型 (Qualification Models) 将更接近于最终产品，但搭建这样的模型会要求更高的成本，同时可供修改的余地也更少。需求管理的多种模式：　　需求管理所要搭建的不同模式是由系统工程所采用的标准决定的。传统上需求管理有两种模式：客户模式和系统需求模式。从这两种模式出发的方案应该分别进行设计，不幸的是我们常常将此二者混为一谈。　　用户模式着重描述用户面临的问题或希望得到的结果。用户模式的语言组织很象使用场景的实地描述，指明时间，侧重结果。无论谁搭建用户模式，都必须从用户的角度出发。　　系统需求模式实际是抽象化的解决方案。系统需求模式的语言组织经常运用功能描述或使用详解性的说明文字，事实上功能描述和使用详解正是系统需求模式语言组织的典型风格。　　实际上设计方案应当是第三种模式，即具体化的解决方案。很明显这种模式已经非常接近于最终解决方案。很多不同的设计方案都能解决用户需求，而在用户需求既定的同时对设计方案作出修改也是切实可行的。在硬件系统设计中，最终进行规模生产的产品体现的往往是第四种模式。其他设计模式：　　搭建多种系统设计模式需要付出相当的工作量，因为每种设计都做到条理清晰并不是件容易的事。如果设计构架和最终方案是一致的，那么工作量可能会减少一些。有些设计方案从产品角度出发，认为不同设计模式最好采用相同构架。但在实际应用当中，设计模式必须采用不同构架，这是因为：　　●有些设计中同功能无关的需求，放在其他条件下则可能引起变化；　　●出于重复利用现存模块的考虑；　　●出于对机构效率的考虑；　　●不同设计方案涉及的步骤要求，我们并不是都要实现；　　以上每种因素都会导致设计方案同最初模式不尽相同。设计开发仅仅采用一种模式是很脆弱的。　　我们必须记住，一套完整的系统开发要求有不同侧重点的多种设计模式与之配合，例如：框架配置模式侧重于大致的工作方向，而工作细化模式则标明了需要完成的各种具体工作。各种模式之间并不是孤立的，在实际需求和各种设计模式之间存在着多种关系。这些关系表现在：　　●关联性：不同模式下开发的产品应当具有一致性（系统需求和用户需求）。　　●应用性：非功能需求同功能需求之间的联系。　　●评估测试：需求管理同评测系统之间的联系（以及产品）。　　●设计开发：需求管理同设计模式或产品之间的联系，我们必须清楚每一部分工作同相应需求之间的对应关系。何谓需求管理　　以下段落将通过分析传统需求管理模式的特点，看看传统需求管理模式同"需求管理之需求"是如何发生关联的。需求管理模型的特点：　　顾名思义，需求管理是完整管理模式中的一环，同其他特性诸如一体性（completeness）、一致性（consistency）等不可分割，彼此相关而成一体。一套需求管理应当是已知系统需求的完整体现，每部分解决方案都是对总体需求一定比例的满足（甚至是充分满足），仅仅解决部分需求是没有意义的。对关键需求的疏忽很可能是灾难性的，试想一架飞机的安全设计不过关将会带来什么样的后果。不同的需求组合起来，构成了一套完整的需求模型。用户需求决定了系统设计所要解决的问题，所要带来的结果。可以说，需求管理指明了系统开发所要做和必须做的每一件事，指明了所有设计应该提供的功能和必然受到的制约。需求的特点：　　需求的提出是进行切实可行的系统开发而存在的客观必然。需求性的描述可以是抽象的，也可以是具体的；它针对的可以是产品本身，也可以是产品开发的方式。　　需求性的提出是建立在可验证的基础上的，就是说，我们能够根据需求而通过设定某种检验标准对最终产品进行评估，并给出或是或非的唯一回答。在测试中，我们永远不能说产品完全解决了需求，只能说它更加接近于满足需求。存在的各种关联：　　需求管理的一项重要工作就是在整个计划不同项目之间建立联系，这也许是在进行系统工程设计时自然而然得到的一种结果。如果我们对需求模式的阐释正确，并对需求与设计的统一性有了确证，那么我们就有了进行成功开发的坚实基础。在出色的系统设计中，系统各部分所存在的各种联系应当是清晰简明的。系统的相关性、可追溯性保证了从不同侧重点出发的系统设计能取得一致的结果。举例来说：　　●系统需求满足于用户需求；　　●设计方案满足于系统需求；　　关联性是客观存在的，对它的描述常被用于展示：　　●非功能性需求同功能性需求适用性之间的关系；　　●方案设计同需求性的满足关系；　　●开发框架内部的关系（例如目标管理、进度安排、任务细分等）；　　●开发过程中各类信息的存档与交换；　　●对每一需求的验证；　　●对于核心需求的合理阐释。需求管理的工具：　　需求管理所用到的工具必须能够处理和应用于本文所提到的各种需求，应当有助于我们分析需求，确定相应开发和支持工具以处理相关信息，进而处理系统相应模块。系统工程师始终致力于用简单的工具将需求形象化的展现出来，常用的工具比如附有标注说明的系统发布工具以及相关数据库等。　　需求管理涉及到一系列复杂的对象，其任务面向很广，关系到整个设计开发的方方面面。其使用的工具应当提供如图列举的一些功能： ☆总结：需求管理　　本文论述围绕于需求管理工程。需求管理是开发工作有效进行的确证。很明显需求管理是一种很高层次的系统行为，涉及整个开发过程和产品本身。　　需求管理首先要针对需求做出分析，随后应用于产品并提出方案。需求分析的模型正是产品的原型样本，优秀的需求管理提高了这样的可能性：它使最终产品更接近于解决需求，提高了用户对产品的满意度，从而使产品成为真正优质合格的产品。从这层意义上说，需求管理是产品质量的基础。　　<全文完>

	主页论坛留言打印联系


	勇于直面需求变更　　 Windy. J 　关键词：需求、需求变更、需求分析、代价估算、面向对象技术、封装、继承、多态、UML 、软件设计、软件可维护性、可扩展性、软件可重用性、接口　摘要：作者针对当前软件系统建设中普遍存在的需求变更问题提出了自己的见解，并提出除了从客观上采取加强培训和代价分析等方法外，更重要的是通过采用合理的分析设计方法，进行可扩展性设计可以有效地降低需求变更引起的风险和维护代价，并给出了可扩展性设计的一个具体例子。　软件系统开发过程中的需求变更问题　作为软件开发人员或者软件系统客户，相信我们都遭遇过因为需求变更而需要修改系统的情况，一般说来客户会要求改变界面，改变操作方式，甚至改变业务，说，当时我是那样要求的，不过现在我们的业务调整了…这时需要中断正在进行的工作，需要查证以往的资料，需要修正计划，需要… 需求包括业务需求、用户需求和功能需求。业务需求（Business Requirement ）反映了组织机构或客户对系统、产品高层次的目标要求，用户需求（User Requirement ）描述了用户使用产品必须完成的任务，功能需求（Functional Requirement ）定义了开发人员必须实现的软件功能。在软件系统开发过程中，有很多问题都是由于在需求分析阶段没有正确地收集、编写、协商、修改产品真实需求而产生的，造成这样的状况有几方面的原因: 　对需求的理解分歧　当客户向需求分析人员提出需求的时候往往是通过自然语言来表达的，这样的表达对于真实的需求来说是一种描述（甚至只是某个角度的描述），远远不能保证这样的描述可以得到百分之百的正确理解，也许在同客户交流的第一时刻就埋下了理解分歧的种子，打一个比方说客户说我要的是大象，身子象一堵墙，耳朵象扇子，四条腿象四根柱子，尾巴象绳子，分析人员想，哦，墙、扇子、柱子、绳子这些我都知道，但是真的画出来的时候客户当然会跳起来了！这是理解分歧的问题，一般跟分析员的知识、背景，还有客户表述的标准程度、双方的交流情况有关；　系统实施时间过长　一个大中型系统的建设可能要延续一段时间，当客户提出要求之后，他当时并不能看到系统的运行情况，当双方认为理解大概没有分歧的时候（事实上还会有个Deadline ），开发方就开始工作了。当客户拿到差不多可以试用的产品时他可以实际操作，这时候他就会对系统的界面、操作、功能、性能等有一些切身的体会，有可能提出需求变更要求；　客户具体情况不一　当前客户的情况不一，有可能客户行业的竞争度高，需要随时作出调整和反应，那么他们自然会经常提出需求变更的要求；也有可能客户所在的行业操作不规范，本身存在很多人为因素，这时候开发方更是需要随时准备应变；　开发本身要求　有可能是来自开发方自身版本升级或性能改进、设计修正的要求出现需求变更，这时更是无法绕开这个问题的了！所以说就算分析人员和客户之间不存在理解分歧，客户对于实际的系统还是会提出一些个人意见，就算没有个人意见，他们自己的业务会变化或环境发生变化，这些都是无法避免的，所以不要梦想那么理想的需求分析，当你开始一个项目的时候就应该意识到，客户需求变更一定会有的，那么对于这样的现状，我们该怎么办呢？客户是上帝，难道我们就象以前一样，跟着客户的需求不停地修改软件，到最后工期延长，员工疲惫，成本成倍增长，客户满意度降低，原来的设计也会改变得支离破碎，系统难以维护？　　客观面对需求变更　如果需求一定会变化，如果我们不得不面对，如果我们已经痛定思痛，想要变革，那么还有什么办法可以改善我们的现状答案是有的。　加强人员培训　从客观方面可以采取的措施来说，首先，我想不容置疑的是加强对需求分析人员的培训，尽可能增强软件系统、行业的背景知识，提高与客户的沟通能力，增强服务意识和责任感，因为将要开发的系统直接建立在需求分析的基础上；同时规范需求分析人员和客户沟通的方式，以及规范需求说明的格式，如果可能的话，尽量采取象XP 的UserStory ，或者用户可以理解的用例图来对需求进行标准、规范的描述，保证双方在工具的协助下对需求达到共同的认识，这一点是老生常谈，就不多说。　确定文档的有效性（Validity ）　顺便要提的一句是关于文档，需求文档是相当重要的，可是目前存在一种奇怪的现象，本来说必须要有文档，而且是按照某种特定的格式，当然这没有错，但接下来，却没有人关心文档的真正内容是否正确，格式是否真的合理，是否实用（而且很多情况下是在几天时间里赶出来或补上去的），例如我遇到一个例子，需要在原来的需求基础上进行后续开发，文档找到了，完全符合格式的要求，但是我在里面找到的线索是有限的，结果是自己花几天的时间查找数据表结构、甚至查看数据表的内容，询问当时的开发人员，才分析到所要的关系，这种情况在设计文档里也存在，所以同时提一提，希望我们的开发人员、PM 以及各级领导可以注意文档的有效性和有用性问题，甚至对文档的格式进行一下合理性检查。建立代价估算（Cost Estimate ）概念这一点对开发方和客户同样重要，因为如果出现需求变更，不可避免将带来成本的增加、开发时间延长等不良后果，这样的影响是双方的。这时候需要区分需求变更的原因，是客户方必要/不必要的要求，还是由于开发方的工作失误，还是双方都有原因，然后对现实情况进行分析，得出双方实现变更需求的需要的成本，包括时间，人力，资源等等方面，再与客户商讨是否必要进行变更和如何在最小代价下实现变更。当客户看到实际的代价估算，他们也会再一次慎重地考虑需求变更问题，也会更容易理解系统建设中的进行状况，自然开发方也不用负担所有的需求变更成本，所以进行成本分摊还是有其积极意义的。当然还有建立需求变更版本控制等等专业的需求管理，在这里不做专门论述。　从软件分析和设计着手　前面说了面对需求变更的几种策略，那么从软件系统分析和设计的角度来看，通过采用合理的分析设计方法，进行可扩展性设计可以有效地降低需求变更引起的风险和维护代价。　采用OO 技术　采用OO 技术可以建立易于改变和加强可重用性的软件系统。对于OO 技术，我想现在已经不是什么陌生的概念： 1 封装（Encapsulation ）可以把问题影响的范围缩小，外部的变化要求对系统的影响可以限定到某个类层次或某些类层次中，从而改变系统的一部分相对简单； 2 继承（Inheritance ）可以使改变基于原有技术基础，很大程度上减少重复开发工作； 3 多态（Polymorphism ）的应用可以使开发和设计人员在相对统一的接口下更改系统的实现细节，从而改变系统的行为； 4 而且由于对OO 的类体系结构业界有非常清楚明晰的描述方式，就是目前规范的描述语言-UML ，非常易于被开发组的理解并达成共识，促进开发组成员之间的合作以及加强软件开发工作的可延续性；可见本身即是一种增强软件可维护性、健壮性以及保持设计稳定性的一种分析和设计方法，本身可以在一定程度上快速对需求变更进行反应，并可相对减少需求变更需要的成本。（OO 的意义在于分析和设计软件系统的思考方式，以及建立对象库以后的软件重用将给软件系统的开发带来质的改变，但是在建立OO 开发体系之前的过程，一定会是一段荆棘遍布的路，需要付出加倍的努力以及达成思想的转变。这里还有一个误区需要澄清的是很多人以为用了C++，PB ，VB ，DELPHI 就是面向对象的开发了，其实只是用了一些面向对象的工具，骨子里仍然是结构化的分析和设计方法，套上一层OOP 的外壳而已。）　可扩展性设计（Extensible-Design ）其次，从我们可以控制的软件设计来说，怎样进行合适的设计才能最大程度减少需求变更带来的代价？也许有人说，我的设计极为灵活，我已经预计了客户可能提出的要求，并设计几种应对的方式，到时候客户提出来，呵呵，我已经解决了。这样的想法不错，至少比僵硬的设计强，但是谁可以保证设计者可以预知以后的需求变化？而同时为了达到这种灵活（万能/多能？）的设计，设计将变得复杂，而且可能那些多余的设计从来不会被用到？复杂的设计将增加实现的难度和提高成本，并有可能带来潜在的Bug ，使得系统难以维护。设计的思想应该有一些小小的转变，那就是，设计确实要灵活，但是要体现在可扩展性上面，也就是说，设计可以简单，但是一定要易于转变，需要给出便于改变的接口，这一点很重要。例如，现在有一个类叫做TCPConnection ，来代表计算机网络通信中典型的TCP 连接，对于这个连接而言，它可能处于以下几种状态：Established （连接已建立），Listening （正在侦听），Closed （连接关闭）。一个连接对象需要从其他的对象接受请求，至于它的反应则决定于连接对象所处的状态，对于（打开连接的请求），如果是在连接关闭状态，则进行Open （），处于其他状态则不做反应；同样，如果在连接建立和侦听状态，可以进行Close （），在连接建立状态可以进行Acknowledge （），即接收数据。对于这样的状况，最不可取的设计应该是用一系列的Switch 语句（甚至If/else 语句）进行Hard 设计，对于以后每一次需求改变，都需要改变源代码，接踵而来的系统一致性、文档更新等工作将使开发人员不可避免地陷入一场灾难，这样的后果将导致原来就不合理的设计变得更加支离破碎，系统维护的代价将越来越大；就算没有需求变更发生，这些设计的可重用性也会极差。稍好一些的设计是预先估计并设置TCPConnection 类所有可能的状态，并预先加入设计，这种需要付出更多的设计、开发、维护的代价，而且也很难达到完美的效果，所以不多说了。下面介绍一种经典的设计思路，这种设计可以充分体现“为（系统）将来改变预留接口”的可扩展性（Extensible-Design ）思想，并且很好的实现了这一思想。在这里，我们引入一个抽象类TCPState 来代表TCPConnection 类的状态，给出具体各种状态的通用操作接口，并派生出不同的子类（实现具体的操作）去实现TCPConnection 类的不同状态，例如派生出TCPEstablished 类来实现TCPConnection 类的连接建立状态。结构图示如下：　　　只需要在TCPConnection 类中包含一个TCPState 的状态引用，并在TCPConnection 的状态改变时更新为当前的状态引用，例如在连接关闭时进行Open （），状态引用就应该从TCPClosed 变成TCPEstablished ，这样就实现了原来的要求。但这个设计思路的意义远不止于此。我们可以看到，抽象类TCPState 已经为TCPConnection 类将来可能的状态留出接口，只需要不断派生具体的不同状态子类就可以实现将来的状态变更，并且无须影响原有的设计，也无须加入多余的代码来实现现在还不需要的功能，所以这是一个优美的、可扩展的设计思路，非常清晰，易于维护，相信可以给我们在做软件设计时带来一些启发。　　结论可见，在面对需求变更时，除了客观上可以通过人员培训、代价分析等管理方式进行有效的需求管理外，从分析和设计的角度可以通过采用合理的分析和设计方法，还有改变我们设计的意识，可以做到对需求变更的灵活应对，至少可以在一定程度上降低维护代价和提高用户满意度。软件需求的管理和控制是非常专业的学问，作者在这里结合自己的实践提出一些粗浅的认识，只是想起到一个抛砖引玉的作用，希望大家可以一起来面对和想办法解决我们在系统开发过程中的实际问题，我想那样才是我真正想达到的目的。参考文献： 1.《软件需求》，（美）Karl E. Wiegers 著，陆丽娜、王忠民、王志敏等译，机械工业出版社，2000 2.《Design Patterns:Elements of Reusable Object-Oriented Software 》，（美）Erich Gamma 、Richard Helm 、Ralph Johnson 、 John Vlissides 著，Addison-Wesley ，1994 3.《Is Design Dead 》，（美）Martin Fowler ，Thought Works ，2000 Face the Requirement Changes Abstract: This article illustrates the general requirement-changes during software system construction. It discovers many useful ways such as Object-Oriented technology and Extensible-Design to resolve the problems mentioned above, other than the enhancement of training and cost analysis. Also an Extensible-Design example is involved in this article for better understanding. Keywords:Requirement, Requirement Changes, Requirement Analysis,Cost Estimate,Object-Oriented technology, Encapsulation, Inheritance, Polymorphism, UML, Software Design, Software Maintainability, Software Extensibility, Software reusablilty, Interface

	主页论坛留言打印联系


	从程序员到系统分析员　（来自LinuxAid.com.cn, Axing制作，isaxu提注）大家应该对这两个词很熟悉了,但是对词里包含的意义可能并不是特别清楚。首先必须说明的是,程序员和系统分析员不存在谁高级谁低级的分别，他们是两种职业，对职业技能的要求完全不同。所以厉害的程序员就是系统分析员的说法是不对的。当然，系统分析员的技能要求他必须要懂得如何写程序，但是他的重心在于如何把一个很大的项目切割成适合个人的小块，然后将这些小块组织起来。程序员的职责就是如何更好更快的实现这些小块。在这章之前，我们讨论的都是一个合格的程序员应当具备的技能，当然不止那一些内容。之所以在这里插进来讨论系统分析员的事情，是因为我们的栏目叫做软件工程而不是程序员从入门到精通之类的。在正式开始之前，我们还是来看在Thinking In Java中作者对分析和设计的一段精辟见解：分析和设计面向对象的范式是思考程序设计时一种新的、而且全然不同的方式，许多人最开始都会在如何构造一个项目上皱起了眉头。事实上，我们可以作出一个“好”的设计，它能充分利用OOP提供的所有优点。请原谅在这里突然出现了OOP这个词，他的意思是面相对象，虽然在之前没有提到，但是在现在OO概念满天飞的软件世界里，大家应该对他不会太陌生。这里我简要的说明一下。在之前我介绍的实际上都是在很早以前程序写作流传下来的经验（什么，教我们老古董，打他！），但是以前的非OO（就是基于过程）的软件设计方法目前在国际上已经很少采用，所以我这里讲软件设计的时候所有的概念都是基于OO的。即使OO的概念很简单的啦，大家思考一下，我们再学习C++的时候一开始使用的类不都是一些动物啦、正方形啦之类的，都是生活中的例子，对吧。其实OO就是我们看世界的一种方式。可是最早由于计算机技术的不发达，我们不得不用一些很奇怪的描述来表达我们的意思，只有这样计算机才能理解，很笨不是吗。比如我们必须使用参数、过程、函数。所以当时的软件设计方法都是基于过程的。举一个简单的例子来显示OO设计方法和基于过程的设计方法之间的差别：一句简单的日常短语－－“我吃饭”，用OO的方法来表述还是“我吃饭”，可是如果用基于过程的方法来描述的话就变成“我吃饭（饭）”，是不是很别扭呢。如果大家觉得对于OO的方法还有什么问题的话，可以去看一下软件工程专栏下的另一篇专题：《Thinking In Java赏析》有关OOP分析与设计的书籍大多数都不尽如人意。其中的大多数书都充斥着莫名其妙的话语、笨拙的笔调以及许多听起来似乎很重要的声明。我认为这种书最好压缩到一章左右的空间，至多写成一本非常薄的书。具有讽剌意味的是，那些特别专注于复杂事物管理的人往往在写一些浅显、明白的书上面大费周章！如果不能说得简单和直接，一定没多少人喜欢看这方面的内容。毕竟，OOP的全部宗旨就是让软件开发的过程变得更加容易。尽管这可能影响了那些喜欢解决复杂问题的人的生计，但为什么不从一开始就把事情弄得简单些呢？因此，希望我能从开始就为大家打下一个良好的基础，尽可能用几个段落来说清楚分析与设计的问题。不要迷失在整个开发过程中，最重要的事情就是：不要将自己迷失！但事实上这种事情很容易发生。大多数方法都设计用来解决最大范围内的问题。当然，也存在一些特别困难的项目，需要作者付出更为艰辛的努力，或者付出更大的代价。但是，大多数项目都是比较“常规”的，所以一般都能作出成功的分析与设计，而且只需用到推荐的一小部分方法。但无论多么有限，某些形式的处理总是有益的，这可使整个项目的开发更加容易，总比直接了当开始编码好！也就是说，假如你正在考察一种特殊的方法，其中包含了大量细节，并推荐了许多步骤和文档，那么仍然很难正确判断自己该在何时停止。时刻提醒自己注意以下几个问题： (1) 对象是什么？（怎样将自己的项目分割成一系列单独的组件？） (2) 它们的接口是什么？（需要将什么消息发给每一个对象？）在确定了对象和它们的接口后，便可着手编写一个程序。出于对多方面原因的考虑，可能还需要比这更多的说明及文档，但要求掌握的资料绝对不能比这还少。整个过程可划分为四个阶段，阶段0刚刚开始采用某些形式的结构。阶段0：拟出一个计划第一步是决定在后面的过程中采取哪些步骤。这听起来似乎很简单（事实上，我们这儿说的一切都似乎很简单），但很常见的一种情况是：有些人甚至没有进入阶段1，便忙忙慌慌地开始编写代码。如果你的计划本来就是“直接开始开始编码”，那样做当然也无可非议（若对自己要解决的问题已有很透彻的理解，便可考虑那样做）。但最低程度也应同意自己该有个计划。在这个阶段，可能要决定一些必要的附加处理结构。但非常不幸，有些程序员写程序时喜欢随心所欲，他们认为“该完成的时候自然会完成”。这样做刚开始可能不会有什么问题，但我觉得假如能在整个过程中设置几个标志，或者“路标”，将更有益于你集中注意力。这恐怕比单纯地为了“完成工作”而工作好得多。至少，在达到了一个又一个的目标，经过了一个接一个的路标以后，可对自己的进度有清晰的把握，干劲也会相应地提高，不会产生“路遥漫漫无期”的感觉。从我刚开始学习故事结构起（我想有一天能写本小说出来），就一直坚持这种做法，感觉就象简单地让文字“流”到纸上。在我写与计算机有关的东西时，发现结构要比小说简单得多，所以不需要考虑太多这方面的问题。但我仍然制订了整个写作的结构，使自己对要写什么做到心中有数。因此，即使你的计划就是直接开始写程序，仍然需要经历以下的阶段，同时向自己提出一些特定的问题。阶段1：要制作什么？在上一代程序设计中（即“过程化或程序化设计”），这个阶段称为“建立需求分析和系统规格”。当然，那些操作今天已经不再需要了，或者至少改换了形式。大量令人头痛的文档资料已成为历史。但当时的初衷是好的。需求分析的意思是“建立一系列规则，根据它判断任务什么时候完成，以及客户怎样才能满意”。系统规格则表示“这里是一些具体的说明，让你知道程序需要做什么（而不是怎样做）才能满足要求”。需求分析实际就是你和客户之间的一份合约（即使客户就在本公司内部工作，或者是其他对象及系统）。系统规格是对所面临问题的最高级别的一种揭示，我们依据它判断任务是否完成，以及需要花多长的时间。由于这些都需要取得参与者的一致同意，所以我建议尽可能地简化它们——最好采用列表和基本图表的形式——以节省时间。可能还会面临另一些限制，需要把它们扩充成为更大的文档。我们特别要注意将重点放在这一阶段的核心问题上，不要纠缠于细枝末节。这个核心问题就是：决定采用什么系统。对这个问题，最有价值的工具就是一个名为“使用条件”的集合。对那些采用“假如……，系统该怎样做？”形式的问题，这便是最有说服力的回答。例如，“假如客户需要提取一张现金支票，但当时又没有这么多的现金储备，那么自动取款机该怎样反应？”对这个问题，“使用条件”可以指示自动取款机在那种“条件”下的正确操作。应尽可能总结出自己系统的一套完整的“使用条件”或者“应用场合”。一旦完成这个工作，就相当于摸清了想让系统完成的核心任务。由于将重点放在“使用条件”上，一个很好的效果就是它们总能让你放精力放在最关键的东西上，并防止自己分心于对完成任务关系不大的其他事情上面。也就是说，只要掌握了一套完整的“使用条件”，就可以对自己的系统作出清晰的描述，并转移到下一个阶段。在这一阶段，也有可能无法完全掌握系统日后的各种应用场合，但这也没有关系。只要肯花时间，所有问题都会自然而然暴露出来。不要过份在意系统规格的“完美”，否则也容易产生挫败感和焦燥情绪。在这一阶段，最好用几个简单的段落对自己的系统作出描述，然后围绕它们再进行扩充，添加一些“名词”和“动词”。“名词”自然成为对象，而“动词”自然成为要整合到对象接口中的“方法”。只要亲自试着做一做，就会发现这是多么有用的一个工具；有些时候，它能帮助你完成绝大多数的工作。尽管仍处在初级阶段，但这时的一些日程安排也可能会非常管用。我们现在对自己要构建的东西应该有了一个较全面的认识，所以可能已经感觉到了它大概会花多长的时间来完成。此时要考虑多方面的因素：如果估计出一个较长的日程，那么公司也许决定不再继续下去；或者一名主管已经估算出了这个项目要花多长的时间，并会试着影响你的估计。但无论如何，最好从一开始就草拟出一份“诚实”的时间表，以后再进行一些暂时难以作出的决策。目前有许多技术可帮助我们计算出准确的日程安排（就象那些预测股票市场起落的技术），但通常最好的方法还是依赖自己的经验和直觉（不要忘记，直觉也要建立在经验上）。感觉一下大概需要花多长的时间，然后将这个时间加倍，再加上10％。你的感觉可能是正确的；“也许”能在那个时间里完成。但“加倍”使那个时间更加充裕，“10％”的时间则用于进行最后的推敲和深化。但同时也要对此向上级主管作出适当的解释，无论对方有什么抱怨和修改，只要明确地告诉他们：这样的一个日程安排，只是我的一个估计！阶段2：如何构建？在这一阶段，必须拿出一套设计方案，并解释其中包含的各类对象在外观上是什么样子，以及相互间是如何沟通的。此时可考虑采用一种特殊的图表工具：“统一建模语言”（UML）。请到http://www.rational.com/去下载一份UML规格书。作为第1阶段中的描述工具，UML也是很有帮助的。此外，还可用它在第2阶段中处理一些图表（如流程图）。当然并非一定要使用UML，但它对你会很有帮助，特别是在希望描绘一张详尽的图表，让许多人在一起研究的时候。除UML外，还可选择对对象以及它们的接口进行文字化描述（就象我在《Thinking in C++》里说的那样，但这种方法非常原始，发挥的作用亦较有限。我曾有一次非常成功的咨询经历，那时涉及到一小组人的初始设计。他们以前还没有构建过OOP（面向对象程序设计）项目，将对象画在白板上面。我们谈到各对象相互间该如何沟通（通信），并删除了其中的一部分，以及替换了另一部分对象。这个小组（他们知道这个项目的目的是什么）实际上已经制订出了设计方案；他们自己“拥有”了设计，而不是让设计自然而然地显露出来。我在那里做的事情就是对设计进行指导，提出一些适当的问题，尝试作出一些假设，并从小组中得到反馈，以便修改那些假设。这个过程中最美妙的事情就是整个小组并不是通过学习一些抽象的例子来进行面向对象的设计，而是通过实践一个真正的设计来掌握OOP的窍门，而那个设计正是他们当时手上的工作！作出了对对象以及它们的接口的说明后，就完成了第2阶段的工作。当然，这些工作可能并不完全。有些工作可能要等到进入阶段3才能得知。但这已经足够了。我们真正需要关心的是最终找出所有的对象。能早些发现当然好，但OOP提供了足够完美的结构，以后再找出它们也不迟。阶段3：开始创建读这本书的可能是程序员，现在进入的正是你可能最感兴趣的阶段。由于手头上有一个计划——无论它有多么简要，而且在正式编码前掌握了正确的设计结构，所以会发现接下去的工作比一开始就埋头写程序要简单得多。而这正是我们想达到的目的。让代码做到我们想做的事情，这是所有程序项目最终的目标。但切不要急功冒进，否则只有得不偿失。根据我的经验，最后先拿出一套较为全面的方案，使其尽可能设想周全，能满足尽可能多的要求。给我的感觉，编程更象一门艺术，不能只是作为技术活来看待。所有付出最终都会得到回报。作为真正的程序员，这并非可有可无的一种素质。全面的思考、周密的准备、良好的构造不仅使程序更易构建与调试，也使其更易理解和维护，而那正是一套软件赢利的必要条件。构建好系统，并令其运行起来后，必须进行实际检验，以前做的那些需求分析和系统规格便可派上用场了。全面地考察自己的程序，确定提出的所有要求均已满足。现在一切似乎都该结束了？是吗？阶段4：校订事实上，整个开发周期还没有结束，现在进入的是传统意义上称为“维护”的一个阶段。“维护”是一个比较暧昧的称呼，可用它表示从“保持它按设想的轨道运行”、“加入客户从前忘了声明的功能”或者更传统的“除掉暴露出来的一切臭虫”等等意思。所以大家对“维护”这个词产生了许多误解，有的人认为：凡是需要“维护”的东西，必定不是好的，或者是有缺陷的！因为这个词说明你实际构建的是一个非常“原始”的程序，以后需要频繁地作出改动、添加新的代码或者防止它的落后、退化等。因此，我们需要用一个更合理的词语来称呼以后需要继续的工作。这个词便是“校订”。换言之，“你第一次做的东西并不完善，所以需为自己留下一个深入学习、认知的空间，再回过头去作一些改变”。对于要解决的问题，随着对它的学习和了解愈加深入，可能需要作出大量改动。进行这些工作的一个动力是随着不断的改革优化，终于能够从自己的努力中得到回报，无论这需要经历一个较短还是较长的时期。什么时候才叫“达到理想的状态”呢？这并不仅仅意味着程序必须按要求的那样工作，并能适应各种指定的“使用条件”，它也意味着代码的内部结构应当尽善尽美。至少，我们应能感觉出整个结构都能良好地协调运作。没有笨拙的语法，没有臃肿的对象，也没有一些华而不实的东西。除此以外，必须保证程序结构有很强的生命力。由于多方面的原因，以后对程序的改动是必不可少。但必须确定改动能够方便和清楚地进行。这里没有花巧可言。不仅需要理解自己构建的是什么，也要理解程序如何不断地进化。幸运的是，面向对象的程序设计语言特别适合进行这类连续作出的修改——由对象建立起来的边界可有效保证结构的整体性，并能防范对无关对象进行的无谓干扰、破坏。也可以对自己的程序作一些看似激烈的大变动，同时不会破坏程序的整体性，不会波及到其他代码。事实上，对“校订”的支持是OOP非常重要的一个特点。通过校订，可创建出至少接近自己设想的东西。然后从整体上观察自己的作品，把它与自己的要求比较，看看还短缺什么。然后就可以从容地回过头去，对程序中不恰当的部分进行重新设计和重新实现（注释⑩）。在最终得到一套恰当的方案之前，可能需要解决一些不能回避的问题，或者至少解决问题的一个方面。而且一般要多“校订”几次才行。构建一套系统时，“校订”几乎是不可避免的。我们需要不断地对比自己的需求，了解系统是否自己实际所需要的。有时只有实际看到系统，才能意识到自己需要解决一个不同的问题。若认为这种形式的校订必然会发生，那么最好尽快拿出自己的第一个版本，检查它是否自己希望的，使自己的思想不断趋向成熟。反复的“校订”同“递增开发”有关密不可分的关系。递增开发意味着先从系统的核心入手，将其作为一个框架实现，以后要在这个框架的基础上逐渐建立起系统剩余的部分。随后，将准备提供的各种功能（特性）一个接一个地加入其中。这里最考验技巧的是架设起一个能方便扩充所有目标特性的一个框架（对这个问题，大家可参考第16章的论述）。这样做的好处在于一旦令核心框架运作起来，要加入的每一项特性就象它自身内的一个小项目，而非大项目的一部分。此外，开发或维护阶段合成的新特性可以更方便地加入。OOP之所以提供了对递增开发的支持，是由于假如程序设计得好，每一次递增都可以成为完善的对象或者对象组。 ⑩：这有点类似“快速造型”。此时应着眼于建立一个简单、明了的版本，使自己能对系统有个清楚的把握。再把这个原型扔掉，并正式地构建一个。快速造型最麻烦的一种情况就是人们不将原型扔掉，而是直接在它的基础上建造。如果再加上程序化设计中“结构”的缺乏，就会导致一个混乱的系统，致使维护成本增加。计划的回报如果没有仔细拟定的设计图，当然不可能建起一所房子。如建立的是一所狗舍，尽管设计图可以不必那么详尽，但仍然需要一些草图，以做到心中有数。软件开发则完全不同，它的“设计图”（计划）必须详尽而完备。在很长的一段时间里，人们在他们的开发过程中并没有太多的结构，但那些大型项目很容易就会遭致失败。通过不断的摸索，人们掌握了数量众多的结构和详细资料。但它们的使用却使人提心吊胆在意——似乎需要把自己的大多数时间花在编写文档上，而没有多少时间来编程（经常如此）。我希望这里为大家讲述的一切能提供一条折衷的道路。需要采取一种最适合自己需要（以及习惯）的方法。不管制订出的计划有多么小，但与完全没有计划相比，一些形式的计划会极大改善你的项目。请记住：根据估计，没有计划的50％以上的项目都会失败！非常佩服作者对软件构建过程的精辟见解，软件工程是一门内容非常繁杂的学科，但是作者能够用浅显易懂的句子把它描述出来，真的是非常不简单。软件工程最早的提出者并不是计算机的专业人士，而是一位建筑设计师，所以软件工程的很多思想来自于建筑学。经过了几十年的发展，软件工程经历了很多次的蜕变。形成了今天的世界上以一些大公司提出的架构为主的形式：比如微软提出的COM及COM+以及基于其上的DNA体系，SUN提出的EJB，CORBA，还有BEA、WebLogic、IBM等公司的架构。虽然架构有不同，但是他们的思想都是相通的，架构的作用都是起到辅助开发者实现规范的、科学的软件开发过程。至于谈软件项目的管理和开发，那么Rational公司就是这方面的鼻祖。综合来说，目前世界范围内的软件工程提倡的就是以渐进的、螺旋式的开发方法构建基于组件的软件产品。现在说这些东西可能有些画饼的嫌疑，随着我们专题讨论的继续深入，这些概念就会很清晰的展现在面前。虽然很希望能够继续的讨论软件工程方面的东东，但是我们的这个专题毕竟是讨论如何编写优美的程序的，离题还是不要太过分的好，至于软件工程的详细讨论，我会在接下去的专题中继续。在接下去的篇幅中，我们会继续讨论程序员和系统分析员之间的差别。四个阶段这里我不想举一大堆的数字和实例来描述软件危机和论证软件工程的重要性，这方面的资料有很多，如果一一列举的话，会被怀疑别有用心(^_^)。在上一篇中，作者告诉即使我们建立的是一所狗舍，不必需要那么详尽的设计，但仍然需要一些草图，以做到心中有数。事实上，建造狗舍和写一个小的软件没有很大的区别。虽然你认为你的能力可以很轻松的完成小型的软件系统，根本不需要任何的计划。好！我来问问你，你在写程序代码的时候，有没有过漏这漏那，程序快接近完成的时候却发现少了一个很重要的模块；有没有过在书写了大量的代码之后觉得自己写出来的东西不堪入目，恨不得重头开始；有没有过写程序花了两天的时间，但是Debug却花了一个星期的时间；有没有过听到软件的使用者说要改需求，你就恨不得狠狠揍他一顿。如果都没有，那么只有两种可能：你是个超级天才，所有人类能够想到的美好品质你都具有，另一种可能：你根本没有开发过软件。即便是个人开发的软件，软件工程科学中也有相应的方法来指导软件的开发过程，这种方法叫做PSP（个人软件开发过程），与此相对的，还有TSP（小组软件开发过程）。这些被事实证明行之有效的方法包括了一整套的规范，帮助你开发你的软件，不让你的程序变得无法控制。可以说，对于任何一个软件系统来说，只要你花一些时间去设计，即便你的设计仅仅只是在草稿纸上随便的涂抹，在软件开发完成后，你就会惊喜的发现，你在软件开发早期的小小投入，已经为你带来了额外的好处。路标和RUP 在阶段0中，我想最重要的思想就是就是“路标”的概念了，和这个概念相类似的概念还有“周期”和“里程碑”的概念，这些概念在Rational公司的RUP(Rational Unified Process 软件统一过程)中有详细的论述。不论这些概念叫做什么，他们体现出来的是一种迭代开发的思想。面对当今的复杂的软件系统，使用连续的开发方法：如首先定义整个问题，设计完整的解决方案，编制软件并最终测试产品，是不可能的。需要一种能够通过一系列细化，若干个渐进的反复过程而生成有效解决方案的迭代方法。 Rational Unified Process支持专注于处理生命周期中每个阶段中最高风险的迭代开发方法，极大地减少了项目的风险性。迭代方法通过可验证的方法来帮助减少风险－－经常性的，可执行版本使最终用户不断的介入和反馈。因为每个迭代过程以可执行版本告终，开发队伍停留在产生结果上，频繁的状态检查帮助确保项目能按时进行。迭代化方法同样使得需求、特色、日程上战略性的变化更为容易。(出自《Rational Unified Process白皮书》) 上面这段好像很复杂，但是他所要说明的思想却是很简单的，就拿搭建狗舍来说，你的第一个“路标”可能是要搭一个框架，这个框架是由几根结实的木头组成，等到框架完成之后，你会把你的小白叫来，让他试一下，糟糕的是，这个框架对于小白来说小了一些，这时候你嘘了一口气，因为你原来是打算把整个狗舍搭好以后再叫小白来试一下的，如果你那样做的话，你剩下的木头可能就不够再盖一间狗舍了。好吧，既然有了些问题，我们就把框架调整一下，可能这个过程也花了你一些木头，不过所幸木头还够。在修整完毕后，你觉得第一步的计划虽然有些挫折，不过仍可以算是成功的，接下来你就要建立第二个“路标”了：第二个的“路标”是为狗舍钉上墙板和做出一个底座，你可能花了一些时间来思考以及和你的小白商量是否要在墙壁上开一个窗户和给底座加上轮子，在决定之后，你很快的达成了第二个“路标”。而且在经过了小白的测试后，你发现完全没有问题，你自己都觉得有些佩服自己了，很快的，你又完成刷油漆等“路标”。整个过程进展的非常顺利，而你在做狗舍方面很有天赋的名声也在你的街坊四邻间不胫而走。很简单是吧，其实本来就是简单的，软件工程的目的就是要把复杂的软件开发过程条理化，简单化。记住，在你使用迭代开发方法的时候，它在每个周期后的产品是一份可执行代码，是一份可以让你的用户品头论足的东西。而这份可执行代码不仅包括了程序本身，可能还有其他的产成品，例如：文档等。问题和场景在阶段1中，非常重要的一点是问题描述，在多数情况下，问题描述来自于你的软件的使用者，就是用户。用户的需求决定了问题描述，糟糕的是，用户多半不懂计算机，对他们来说，他们只能够用日常的语言来表达自己的需要。而你的任务就是要把他们的语言翻译成计算机语言，不过并不是指象C那样的高级语言，而是便于你构造系统的需求描述语言。这同样很简单：你只需要问自己几个问题就可以：在什么场合？有什么条件？做些什么事？回答好这三个问题，你就完成了一个完整的问题描述了。举一个简单的例子：一个银行的信贷系统有这样的问题描述： “若顾客采取信用贷款方式，销售员就请求信用部门的审核人员查核顾客的信用，此时审核人员会向销售员取得顾客信用编号和销货总金额。” 在某种条件下应该做什么事情，这就是这个问题描述的表现形式，很简单是吧。实际上，这里可以引申出两个概念：场景(context)和问题(problem)，场景指的是一种特定的情况，会导致某种问题的发生；而问题是在某个场景之中，但它也有可能产生出新的场景。过程和对象有必要说明一下以前基于过程的软件开发和目前基于对象的软件开发的不同。在没有OO的年代里，DFD(Data Flow Diagram 数据流程图)是一份软件设计中的非常重要的文档，注意力的关键也是集中在数据如何在各个系统之间传递。可是在现在的OO概念中，数据大有为消息(message)所替代的趋势。比如你到麦当劳快餐店，要花10块钱买一份汉堡。在DFD的时代，就是这样表示的：如果你用消息表示法来表示话，就是另一种方式：怎么样，你觉得那一种方式更自然呢。(如果你敢回答第一种的话我就...)。再比如上一段话中关于问题描述的例子，如果用传统的数据描述的方法的话，就会是这样子的： “若采取信用贷款方式，销售员就将顾客信用编号及总金额交给信用部门的信用审核人员。” 请比较其中的两句话： “若采取信用贷款方式，销售员就将顾客信用编号及总金额交给信用部门的信用审核人员。” “若顾客采取信用贷款方式，销售员就请求信用部门的审核人员查核顾客的信用，此时审核人员会向销售员取得顾客信用编号和销货总金额。” 了解其中的不同之处了吗，用自然的语言去描述你的问题，这是写出好的软件的第一步。系统分析员的语言场景描述是一个很不错的方法，可是随着你对系统的分析的深入，参与开发的人员的增加，你渐渐的感觉这种方法不够用了。原因有很多：文字的描述不够直观，不可能到达一种很细致的程度。这时候就需要一种能够描述问题、描述解决方案、起沟通作用的语言。这就是UML。 UML(Unified Modeling Language 统一建模语言)是由Rational公司发明，目前由OMG(标准化对象管理机构)维护。作为一种建模语言,UML的定义包括UML语义和UML表示法两个部分： UML语义　描述基于UML的精确元模型定义。元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明,使开发者能在语义上取得一致,消除了因人而异的最佳表达方法所造成的影响。此外UML还支持对元模型的扩展定义。 UML表示法　定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型,在语义上它是UML元模型的实例。标准建模语言UML的重要内容可以由下列五类图(共9种图形)来定义：用例图、静态图、行为图、交互图、实现图。从应用的角度看,当采用面向对象技术设计系统时,首先是描述需求；其次根据需求建立系统的静态模型，以构造系统的结构；第三步是描述系统的行为。其中在第一步与第二步中所建立的模型都是静态的，包括用例图、类图(包含包)、对象图、组件图和配置图等五个图形，是标准建模语言UML的静态建模机制。其中第三步中所建立的模型或者可以执行，或者表示执行时的时序状态或交互关系。它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语言UML的动态建模机制。因此，标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。这样说，你可能还是不了解UML到底是什么，不过UML并不是我们讨论的重点，你只需要知道UML是一种建模语言，他的目的就是在开发团队之间提供一种通用的、简单的沟通机制，并且UML是面相对象的。上面所说的这些就是阶段2的重点所在。使用UML语言对阶段1中提出的问题描述进行深化，从各方各面看待问题：顺序、流程、数据、状态、接口等。最终你得到的是一套完整的文档，做为详细的程序设计的参考和标准。不要累坏自己上面说了这么多在编程之前要做的工作，但是要注意的是，不是所有的开发工作都必须做这么多的工作的。对于你来说，抓住最重要的内容，不要涉及到太多的细节。对你写出来问题描述，必须要仔细的分析，而这里的分析呢，并不是要你用程序来实现你的问题描述，而是你必须从问题描述中分析出对象(object)、事件(event)和消息(message)。例如上面所提到的例子： “若采取信用贷款方式，销售员就将顾客信用编号及总金额交给信用部门的信用审核人员。” 你可能看到这句话以后就会在想做一个审核信用的函数，参数部分有信用编号和总金额，然后开始设计程序的细节。如果你是这样干的话，这说明你还没有真正了解OO的思想，你的开发方式仍然停留在以前基于过程的开发方式中。那么面相对象的分析是怎样进行的呢。我们还是来看这段话，撇开你的程序，你的语言，你从这句话中获得了什么信息？是的，你知道说这个企业中有销售员、有信用审核人员；要求审核顾客信用是他们的工作之一；顾客的信用编号和总金额是审核顾客信用的时候的重要信息。这是任何一个普通的人看到这段话后的感觉，这就是OO的分析(在OO中这种的分析方法称为OOAD)。其实是很简单的，和你采用什么样的程序一点关系都没有。软件重用(Reuse)是软件工程中最重要的思想之一，只有软件重用，才能降低软件成本，提高软件的质量。你在对一个软件进行分析的时候，找出可以重用的对象，有助于你开发高效的软件系统。正如前面所说的，你不必把软件分析的过分细致，你只需从中找出关键性的、能够重用的对象就足够了。剩下的事情，就是对这些对象分配属性和方法，并充分的使用这些对象就好了。还是那个例子：我们已经从中看到了一些对象：销售员、信用审核人员。但是他们在系统中不具备重用性，至少是重用性不强。信用部门这个对象也存在这个问题。所以不能够把他们作为底层的对象，我们用一个术语Entity Objects 来称呼底层对象。那什么是软件系统中的Entity Objects呢？毛主席教导我们要透过现象看本质。上面的描述中有很多隐含的信息：顾客请求信用贷款：这里就包括两个Entity Objects：顾客、信用贷款。销售员、信用审核人员都是员工，所以员工也是一个Entity Objects。观察一个Entity Objects，你会发现，Entity Objects已经是最小的单位，是使用软件的用户(这里是银行)最小的单位。当然不但是这个软件有Entity Objects，比如我们最常用的Word，我们可以想象一下它的Entity Objects有什么，可能是一种叫做图元的Entity Objects，一个图元包括了文字、图象以及其他的对象。用OO的方法分析你的软件，从设计到实现都是非常的自然，可能你学习面向对象时是从C++开始的，被其中的虚函数、多态性、多基类继承搞得一头雾水。但是实际上OO的方法要比以前的方法简单的多，不相信？试一试，你就知道了。校订、校订再校订第3个阶段称为校订，这个称呼真是太贴切了，既不是测试，也不是返工。任何事物从诞生起都必须经历不断的改进才有可能成熟。(呵呵，说出这么有哲理的话，我都很佩服自己啊。)软件同样不例外。事实上，在阶段0中，我们就讨论了“路标”的概念，当你的第一个路标达成之后，剩下的应该都是属于校订的事了。通过和用户的交互，确定新的“路标”，不断的改进系统功能，优化系统结构，修正系统Bug。正如作者所说的那样，真正OO的软件是经得起修改的，由于采用了多层的结构以及面向对象的思想，以前软件的致命伤(修改)在新的开发方法面前不会是个大问题。(注意，这并不是说你可以无规划构建你的软件) 由于以前的系统大多会将GUI、事务处理、数据存储都做在一起，当你需要修改一个地方的时候，你就会发现问题的严重性：一个小小的需求变动都意味着你的系统将面临伤筋动骨般的修改。在OO的时代里，所有的对象的访问都是通过接口(Interface)进行的，对象中方法的改变并不会接口产生影响，也就是说，调用该接口的模块不用做任何的修改。另外，如果你打算把你的系统的界面从C/S方式向B/S方式改变，同样不会有问题，你可以很容易的把GUI部分从原有的系统中剥离出来。软件的修改对你来说不再是一个恶梦。

	主页论坛留言打印联系

需求的问题

需求的问题，是一个简单的问题

需求决定了软件做什么，要提供什么功能。

软件工程初期的一般过程是，软件开发的计划，确定要实现的目标和进度等，然后就是需求规格说明书，该说明书要得到用户的认可。用户往往提供了一份要求的说明，开发人员在这个基础上进行了加工和整理。此后的开发过程，都是围绕着需求规格说明书进行进一步地细化，直至开发出产品。当然，测试计划中也要针对需求进行验证，看看是否满足了用户的要求。

一般来说，用例视图可以很好地表现需求。用例图中，若干角色actor与系统提供的用例（功能）之间的连接关系。

以下是参考《IEEE推荐的软件需求规格说明的方法（IEEE 830-1998）》的一个系统规格说明书SRS模板：

一、引言

（一）目的
（二）文档约定
（三）预期的读者和阅读建议
（四）产品的范围
（五）参考文献

二、综合描述

（一）产品的前景
（二）产品的功能
（三）用户类型和特征
（四）运行环境
（五）设计和实现上的限制
（六）假设和依赖

三、外部接口需求

（一）用户界面
（二）硬件接口
（三）软件接口
（四）通信接口

四、系统特性

（一）说明和优先级
（二）激励/响应序列
（三）功能需求

五、其它非功能需求

（一）性能需求
（二）安全设施需求
（三）安全性需求
（四）软件质量属性
（五�