业务需求分析师

1、业务需求分析师目录目录2第1章.软件需求现状与常见问题4.1.1. 软件需求现状分析4需求常见问题分析5第2章.软件需求与需求工程8.1.1. 软件需求81.1.1. 软件需求定义8需求的层次8软件需求的类型10软件需求的重要性12优秀需求的标准131.2. 软件需求工程14第3章.需求开发16.需求开发管理16需求获取16需求分析19需求评审50第4章.需求管理.53.4.1. 需求基线管理534.2.1. 需求变更管理53需求变更控制活动55需求变更控制委员会57需求变更波及分析60需求稳定性评估631.3.1. 需求跟踪64需求跟踪目白勺64需求跟踪能力矩阵66需求跟踪能力工具69需求跟

2、踪能力过程701.1. 需求后评估70成本评估71效益评估71第1章.软件需求现状与常见问题软件需求现状分析在信息化高速发展与行业竞争日趋激烈的今天，构建符合中国电信企业战略的信息化系统是我们IT专业人员要解决好地关键课题。然而在软件项目实施过程中，进度超期、经费超预算、变更频繁的现象层出不穷，许多项目无法达到预期目标，归根结底，软件需求质量是问题的主要根源之一。软件需求是软件项目关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点。它不像硬件的需求，是有形的、客观的、可描述的、可检测的。软件需求是软件项目最难把握的问题，同时乂是关系项目成败的关键因素。

3、既然软件需求如此重要，那么需求相关的哪些因素是导致项目失败的根源？美国的第三方机构StandishGroup每隔几年都会对软件项目现状进行分析与统计，其分析报告“CHAOSREPORT”的研究结果显示：高达31.1%勺项目彻底失败，高达52.7%勺项目进度超期或成本超支，被认为成功的项目仅有16.2%为了帮助软件开发组织找到明确的改进方向，StandishGroup还总结出了+大成功保证和十大败因，如表1-1所示。在表1-1中可以看出，十大成功因素中有三个直接与需求相关（已加粗显示），累计权重达37.1%;而十大失败因素中有五个直接与需求相关，累计权重达51.6%,可见需求对项目影响程度之高表

4、1-1项目成败因素分析成功因素权重失败因素权重用户参与15.9%不完整的需求13.1%决策层支持13.9%缺乏用户的参与12.4%清晰的需求描述13.0%资源不足10.6%合适的规划9.6%不且实际的用户期望9.9%现实的客户期望8.2%缺乏决策层的支持9.3%较小的里程碑7.7%需求变更频繁8.7%有才能的员工7.2%规划不足8.1%主权5.3%提供了不需要的功能7.5%清晰的远景和目标2.9%缺乏IT管理6.2%努力工作和稳定的员工2.4%技术能力缺之4.3%其他13.9%其他9.9%1.2.需求常见问题分析下面简要地对需求相关的这些失败因素做初步的分析，更多的内容将随着本书的进程继续深入

5、。1. 不完整的需求在日常工作中，该问题经常困扰着我们“什么样的需求是完整的呢？”如果没有一个有效的“需求完整性评价标准”，那么这个问题将是无解。要破解这个问题。首先应回答一个铺垫性的问题一一“谁更有可能可以对需求的完整性进行评价？”。答案应该是“业务专家或业务代表要比it人员更适合对完整性进行评价”。要想让业务专家能够更好地参与到完整性评价中,应该做到以下两点：采用“业务导向”的树型层次结构展现需求文档。假若“需求规格说明书”中充斥着诸如数据字典、报表子系统、新增客户等以技术动词为主的字眼与结构，很有可能业务人员望而却步。而采用业务导向的结构，是用业务人员熟悉的场景为索引，加之树型层析结构可

6、以将宏观信息与微观信息进行有效剥离。按“组织层次”划分来完成需求的验证。日常工作中常见的场景是用业务代表的签字确认来代替需求验证。需求验证是重要的需求质量环节，目的是暴露出更多的错误，而确认则代表了职责。可一个企业中少有人能上通战略下解具体操作，为了让业务人员有效的验证需求，需求文档的树型结构应面对不同的层面：决策层、管理层、操作层，将需求分成不同部分，让合适的人验证适当的部分。2. 缺乏用户参与在很多项目中，使用者都不能有效地参与到项目中来，诸如“你们先做，做出来我们试试，有问题再改”之类的话也是常常听到。主要应对措施是充分研究业务代表的关注点、利益点，通过业务利益争取使用者参与到需求活动中

7、。不切实际的用户期望很多情况下，业务人员都会提出大量的需求，有些是技术上根本无法实现的，有的则是项目费用、项目时间等预算内无法实现的。究其原因，主要在于软件的无形和软件成本的不透明。要解决这样的问题，在当前国内的软件实施环境下，能做的是it人员主动地帮助使用者更好的理解软件成本，说明活楚为什么做不到，取得理解，达成一致才是关键。需求变更频繁导致需求变更的原因很多，常见的因素包括：开发人员对待需求开发的态度不认真用户参与不够模棱两可的需求。用户和需求开发人员在理解上的差异。过于简单的规格说明。不准确的计划等。有效控制变更应该注意采取合理的需求管理方法：需求分析阶段尽可能采用原型或者用例方法明确用

8、户需求。采用严格的需求变更管理流程。采用良好的体系结构。采用面向对象思想。详细的方法请参见第3章节内容。3. 提供了不需要的功能很多项目中都或多或少的含了些很少使用或无人使用的功能，这种情况如何在事前预防呢？在需求阶段有效地划分优先级是个办法。这里所说的优先级划分不是“拍脑袋”的产物，而是真正基于业务领域知识来衡量需求的必要性和充分性，在此基础上做出划分。第2章节有关于“合理划分优先级的方法”的详细说明。上述分析是需求工作中常见问题的解决建议，分析比较粗浅。若要有效的解决问题，就需要反思问题背后的本质原因，掌握需求理论与工作方法，针对性的找到适用的需求方法，构思、尝试出真正在本组织内有效的缓解

9、手段。第2章.软件需求与需求工程2.1. 软件需求2.2. 软件需求定义什么是软件需求，这个看似简单的问题并不好回答。也许有很多人简单地认为软件需求就是用户需要实现的功能加上一些非功能方面的要求。但这样的理解并不完整，本意将对一些与需求相关的关键概念进行阐述。软件需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么样的性能。软件人员要准确理解用户的要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转化到相应形式的需求规格说明的过程。对于软件项目的需求，首先要明确用户的要求，澄活模糊的需求，与用户达成共识。2.2.1. 需

10、求的层次有时也可以将软件需求按照层次来说明，包括业务需求、用户需求、软件需求、软件需求规格等层次，它们的关系如下图1-1所示。业务需求用户需求图表2-1软件需求按照层次1. 业务需求业务需求反映了组织机构或客户对系统、产品高层次的目标要求，由管理人员或市场分析人员确定。因为业务需求的提出人通常是企业的管理人员，它完全是从业务角度描述的，是指导软件开发的高层需求。实际上在项目立项阶段就整理完成了。2. 用户需求用户需求是指软件使用者的要求和软件应满足的用户特性，一般是用户协助提供。通常是在业务需求定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立用户角度的需求。用户需求是需求调研

11、的产物，它具有以下特点：零散：用户会提出不同角度、不同层面、不同粒度的需求，而且通常是以一句话的形式提出的。存在矛盾：由于用户处于企业组织的不同层面、地域等，难免出现盲人摸象的现象，从而导致需求的片面性，甚至在不同用户之间会有不同的观点。正因为如此，我们还需要对用户需求（也叫原始需求）进行分析整理，从而整理出更加精确的需求说明。3. 软件需求软件需求定义了开发人员必须实现的软件功能，使得用户通过使用此软件能完成它们的任务，从而满足业务需求。它是分析人员在对用户需求进行分析、提炼、整理，从而生成指导开发的、更精确的软件需求。它是需求分析与建模的产物，即形成软件需求规格。软件需求规格充分描述了软件

12、系统应具有的外部行为，它描述了系统展现给用户的行为和执行的操作等。它包括：产品必须遵从的标准、规范和合约；外部界面的具体细节；非功能性需求（例如性能要求等）；设计或实现的约束条件及质量届性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量届性是通过多种角度对产品的特性进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。软件需求规格在开发、测试、质量保证、项目管理以及相关项目功能中都起到了重要的作用。软件需求的类型软件需求可以分为功能需求、非功能需求和设计约束三种类型。功能需求对于功能需求而言，最为关键的地方是如何对其进行组织，否则一句话、一句话的描述就会显得十分零散，

13、彳艮难保证开发人员逐一满足这些需求。在传统的方法论中，会以系统-子系统-模块-子模块的层次结构来组织，但它更多的是按照程序的结构来梳理，会割裂用户的使用场景。为了解决这个问题，现代需求理论更加强调需求分析人员从用户的角度，将系统理解为一个黑盒子，从横向的使用视角来整理需求。不管是RUP的用例方法还是XP的用户故事，以及特征驱动开发的Feature都是从这个角度进行梳理的。本教材推荐使用用例的方法。1. 非功能性需求非功能需求是一些限制性要求，是对实际使用环境所做的要求，例如性能要求、可靠性要求、安全性要求等。非功能需求比功能需求要求更严格，更不易满足，因为如果不能满足非功能需求，系统将无法运行

14、。非功能需求方面常见的问题有两个：一是信息传递的无效性；二是忽略了非功能需求的局部性。信息传递的无效性：很多需求规格说明书中，会通过一个小意节来说明非功能需求，列出诸如高可靠性、高可用性、高扩展性等要求。但很多开发人员根本不看它，因为这样的定性描述是没有标准的，因此信息的有效性不大。本书的后续意节将说明解决方法。忽略了非功能需求的局部性：我们经常会看到“所有查询响应时间都应该小于5秒”的描述，但是当查询稍长周期的数据量时这样的要求可能无法实现。因此开发人员会认为这项原则是可以破坏的'更科学的做法就是抓住具体的场景来描述。设计约束设计约束看似简单，但如果不了解而导致收集需求时出现遗漏的现

15、象非技术因素决定的选型对软件开发而言，技术选型会基于企业内部的相关规定。例如，必须采用J2EE技术；中问件必须采用WEBSPHERE等。使用的软硬件条件与环境在决定架构、选择实现技术时会受到软硬件设备的影响，如果忽略了此种因素会造成不必要的麻烦。例如，当前导购人员使用的平台电脑的操作系统不支持FLASH插件、乡村支局点的电脑配置较低等。用户的环境也会对软件开发造成影响，需求人员应该搜集此类信息。2.2.3.软件需求的重要性开发软件项目就像和用户一起从河的两边开始修建桥梁，如果没有很好的理解和管理用户的需求，开发出来的软件不是用户希望的，那么这座桥就永远不可能对接成功。没有一个合理的需求管理，将

16、很难达到用户的真正要求。即使设计和实现的再正确可靠，也不是用户真正想要的东西。所以，需求分析很重要，项目需求是制定项目计划、开发项目产品和从事项目活动的依据。项目的计划、项目的开发活动及开发的产品应与项目需求保持一致，随需求的变化而调整。因此，必须采用有效的方法对项目需求的变化进行管理和控制。项目需求管理过程主要包括对用户提出的出示需求的确认过程和对用户提出需求变更的控制过程。软件需求研究的对象是软件项目的用户要求。需要注意的是，必须全面理解用户的各项要求，但乂不能全盘接受用户所有的要求，因为用户提出的要求并非都是合理的。对于其中模糊的要求，还需要向用户澄活，然后才能决定是否可以采纳。对于那些

17、无法实现的要求，应向用户做充分的解释，以求得用户的谅解。2.2.4. 优秀需求的标准通用的优秀需求的标准分为7个：完整性、正确性、无歧义性、必要性、有先后次序、可行性、可验证性。下文将其分为四组，逐一介绍。1. 完整性完整性即需求没有遗漏。这点在实际需求活动中很难做到或衡量。第1章中我们提到过完整性的实现要点。1）必须从业务角度来组织各种需求项。2）必须按人员分层来验证需求。2. 不失真需求的正确性和无歧义性是一组相关的要求，指的是确保需求在信息传递的过程中不失真。达到这两个方面的标准需要从两个角度实现：1）正确性：要使需求正确应找到正确的人来参与。一方面是在调研阶段找多方面的人来获取需求。避

18、免片面性；另一方面是应该找到直接相关的人员进行验证。2）无歧义性：歧义主要是不同背景的人在传递时加入不同理解而导致的，因此仅靠文档来传递需求是不充分的，文档无法代替沟通，还需要配合一些验证活动才能够尽可能的缓解歧义问题。3.有优先级“事有轻重缓急”，一句话概括了区分优先级的重要性。要想更好地对项目进行管理，就需要有效的区分出优先级。很多时候需求会被冠以“高优先级”，实际上是担心IT不去实现。相对科学的划分优先级有充分性和必要性两个维度。用“实现后的收益”（充分性）与“不实现的影响”（必要性）两个量化值相乘,就可得到一个更有参考价值的权重，从而更适合做优先级评价。如下表示例。需求项评价项评价结果

19、提供键盘快捷方式触发采单贝面方式实现后的收益非常显著O比较显著显著一般不实现的影响非常显著O比较显著显著一般总评价2分X1分=2分4.有技术早期介入需求文档的读者是IT开发、测试团队，那么与开发、测试团队交流，探讨文档有哪些不足、缺少什么信息，是改进需求文档的有效方法优秀需求评价标准中的可行性就需要开发团队尽早介入。可验证性则是说明需求提供了验证所需的信息，也能够指导测试活动。2.3.软件需求工程软件工程活动包括需求、系统分析与设计、编码、测试、配置管理等一系列活动。但唯独只有需求被称为工程。需求工程形成丁20世纪80年代中期，是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析

20、人员理解问题并定义目标系统的所有外部特征的一门学科。如图表2-2需求工程图所小，需求工程包括需求开发和需求管理两大范畴需求开发是收集、分析、整理、编写、验证需求的全过程，重点在丁开发出高质量的规格说明。需求管理则是对需求的实现、变化进行追踪的全过程,重点在丁开发的软件满足这些需求。需求获取需求验证编写规约需求分析需求开发需求工程变更管理需求跟踪基线管理需求管理需求评估图表2-2需求工程图3.1. 实行有效的需求工程管理的组织能获得多方面的好处。最大的好处就是在开发后期和整个维护阶段的返工的工作量可以大大减少。研究表明：如果在需求阶段只需花费一个单位时间就能改正的错误拖到设计阶段改正就需要五倍时

21、间,图表2-3需求工程工作量分布图示了编码阶段将第3章.需求开发需求开发管理需求开发工作要点包括需求获取、需求分析、需求规格编写、需求评审四个具体的活动。这些活动工是多次迭代的，每次过程如图表3-1:需求开发工作。图表3-1:需求开发工作般在整个软件开发过程中要至少需要迭代三次。3.1.1. 需求获取需求获取是需求开发的第一个活动，需求获取是通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求。如何提高需求获取的有效性一直以来是困扰大家的问题。需求获取的要点在丁计划性和科学性。计划性体现在对调研对象、问题、实践的计划；科学性则表现在如何有效地选择合适的方法。需求获

22、取执行的活动与主要方法:需求获取有许多方法，每种各有缺点，使用的时机与具体执行的活动也不相同，因此需求分析人员需要了解方法的使用要点。1. 用户访谈用户访谈是最常见、也是最基本的需求获取技术。访谈者是否善于访谈，将直接影响最终的结果。用户访谈的优缺点用户访谈的优点是直接有效，形势灵活、交流深入。缺点是占用时间长，信息可能存在片面性。用户访谈是需求获取的主体技术，只要有可能，就应该尽可能多地进行访谈。用户访谈的类型需要了解客户方的所有用户类型以及潜在的类型。然后，根据他们的要求来确定系统的整体目标和系统的工作范围。一般将访谈者分成不同类型，一般分为高层管理者、中层管理者、操作层。在不同阶段访谈不

23、同类型的人，访谈的话题与目的也有所不同。访谈的沟通技巧访谈过程是一个对沟通技巧要求较高的活动，要求访谈者善于倾听、善于表达。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需要注意的是，每一次交流一定要求记录，对于交流的结果还可以进行分类，便于后续的分析活动。例如，可以将需求细分为功能需、非功能需求（如响应时间、平均无故障时间、自动恢复时间等）、环境限制、设计约束等类型。在此描述主要的一些策略或技巧。(1) 制作访谈问卷并事先发给访谈者把握语言节奏，尽量使用简单语言表达活楚问题。(2) 灵活采用封闭式问题(类似判断题)、半封闭式问题(类似选择题)和开放式问题(类似简答题)。

24、(3) 安排好问题顺序，一般遵循业务逻辑排序。(4) 访谈中最好及时用草图绘制模型(用例、DFD、思维图)。(5) 注意沟通细节，说话语气不要过于强势、业务人员使用的术语不懂应及时请教。访谈计划的制定访谈应有计划性，在访谈前做好时间、人员、问题等各类计划。用户调查优缺点优点是调查面广，能够获得更多人的反馈，能够克服访谈的片面性。缺点是不易深入。调查问卷设计要点应注意问题的篇幅与布局；注意问题类型的选择，多选择半封闭性问题，还应有一定比例的开放性问题。调查问卷分析要点应注意筛除无效问卷；按填写人类型分类；对于回答含混不活的可做针对性访谈。文档研究优缺点优点是能详细、直观地对一些细节进行了解与分析

25、，缺点是在企业中文档量比较大，有时还会有误导性。适用性适用于数据类需求的获取，尤其是研究、分析、细化数据需求的手段。原型法优缺点优点是最直观、生动的方式，用户对界面也提供了早期评审。缺点是花费时问多，效率低。现场观摩法优缺点优点是开发团队对业务可建立直观认识。缺点是花费时间多，有时结果会失真。选用时机在对关键业务不活晰时，可采用此法。3.1.2.1. 需求分析需求分析的内涵需求分析是需求开发的核心任务，它是通过对业务问题的研究，本质上是业务分析，即选择一种业务导向的线索将零散的用户需求申起来，形成一个体系完内、内容活晰的需求框架。需求分析的任务并不是分析系统如何实现用户的需要，而是解决目标系统

26、“做什么”的问题。需求也是与技术无关的。技术的实现细节是在后面的设计阶段才需要考虑的事情。很多情形下，分析用户需求实际上是与获取用户需求并行的。3.1.2.2. 需求建模的目标与要点需求建模是需求分析的主要手段，它通过一组模型来简化、帮助需求分析人员理活思路、提供一种详细说明所需系统特性的方法。为什么要需求建模？在日常生活中我们会发现模型早已在各个领域得到广泛使用。盖房子会有一整套的建筑图模型，很少看到用大篇幅的文字来描述要建的房子；电子设备制造同样会有各类电路图。这些模型有效的帮助人们更好的认识、应用、设计复杂的事物。软件行业的复杂度相比其他领域有过之无不及，有了模型，可以让我们更好的理解要

27、建设的系统。在实际建模过程中，应注意以下几点：选择创建什么建模方式或模型对如何解决问题、形成解决方案由深远影响。最好的模型是与现实相联系的。不能为了建模而建模，如果不能对构建系统起到作用，那就是资源浪费。3.1.2.3. 需求建模主要方法需求建模可以使用建模工具，利用建模方法论来指导我们有效建模。建模方法论的发展见下表1-2。方法论所处时代建模要点程序=数据结构+算法上世纪5060年代，主要解决科学计算问题选择合适的数据结构与算法结构化分析与设计上世纪6070年代，主要解决与数据处理相关问题一、确定由那些数据，格式、存储，提供E/R模型；二、确定数据的加工处理过程，提供DFD图面向对象分析与设

28、计上世纪8090年代，主要支持业务过程相关问题数据不是唯一视角，人的视角得到重视。表1-23.1.2.3.1结构化分析方法结构化需求分析是20世纪70年代由Yourdon、Constaintine及DeMarc。提出的一种面向数据流的需求分析方法。它基丁“分解”和“抽象”的基本思想，逐步建立目标系统的逻辑模型，进而描绘出满足用户要求的软件系统。“分解”是指对丁一个复杂的系统需求，为了将复杂性降低到可以掌握的程度，可以把大问题分解为若干个小问题，然后再分别解决。下图演示了对目标系统X进行自顶向下逐层分解的示意图。自顶向下逐层分解图表3-2:结构化分析最顶层描述了整个目标系统需求，中问层将目标系统

29、需求划分为若干个模块，每个模块完成一定的功能，而最底层是对每个模块实现方法的细节性描述。可见，在逐层分解的过程中，起初并不考虑细节性的问题，而是先关注问题最本质的届性，随着分解自顶向下进行，才逐渐考虑越来越具体的细节。这种用最本质的届性表示一个软件系统需求的方法就是”抽象"。分解和抽象是结构化需求分析的基本指导思想。在结构化需求分析的过程中，通常还需要借助数据流程图、数据字典、E-R图、结构化语言、判定表、判定树等工具。接下来我们介绍数据流图、数据字典和E-R图的相关知识。1. 3.1.2.3.2结构化需求分析的工具数据流图数据流图(DataFlowDiagramDFD)是描述系统中

30、数据流的图形工具，是一种用来表示信息流和信息变换过程的图解方法，可以标识一个系统的逻辑输入和逻辑输出，以及把逻辑输入转换为逻辑输出所需的加工处理。数据流图把软件系统看成是由数据流联系的各种功能的组合，在需求分析的过程中，可以用来建立目标系统的逻辑模型。结构化需求分析采用的是”自顶向下，由外到内，逐层分解”的思想，开发人员要先画出系统顶层的数据流图，然后再逐层画出低层的数据流图。顶层的数据流图要定义系统需求范围，并描述系统需求与外界的数据联系，它是对系统需求架构的高度概括和抽象。底层的数据流图是对系统需求某个部分的精细描述。在绘制数据流图的过程中，主要用到了4个基本符号：信息源符号：口,表示数据

31、的源点或重点，它是系统之外的实体，可以是人、物或者其他系统加工：匚.，表示对数据进行加工或处理，比如对数据的算法分析和科学计算。数据存储：表示输入或输出文件。这些文件可以是计算机系统中的外部或者内部文件，也可以是表和账单等。数据流：，表示数据的流动方向。数据流可以从加工流向加工，从加工流向文件，或者从文件流向加工。在绘制数据流图的过程中，要注意以下几点。1）数据的处理不一定是一个程序或一个模块，也可以是一个连贯的处理过程。2）数据存储是指输入或输出文件，但它不仅仅可以是文件，还可以是数据项或用来组织数据的中间数据。3）数据流和数据存储是不同状态的数据。数据流是流动状态的数据，而数据存储是指处丁

32、静止状态的数据。4）当目标系统需求的规模较大时，为了描述的活晰和易丁理解，通常采用逐层分解的方法，画出分层的数据流图。在分解时，要考虑到自然性、均匀性和分解度几个概念。5）自然性是指概念上要合理和活晰。6）均匀性是指尽量将一个大问题分解为规模均匀的若干部分。7）分解度是指分解的维度，一般每一个加工每次分解最多不宜超过7个子加工，应分解到基本的加工为止。8）数据流图分层细化时必须保持信息的连续性，即细化前后对应功能的输入和输出数据必须相同2. 数据字典用数据流图来表示系统的逻辑模型直观且形象，但是缺乏细节描述，也就是说它没有准确和完整地定义各个图元。可以用数据字典(datadictionaryD

33、D)来对数据流图做出补充和完善。数据字典用丁定义数据流图中各个图元的具体内容，为数据流图中出现的图形元素做出确切的解释。数据字典包含4类条目：数据流、数据存储、数据项和数据加工。这些条目按照一定的规则组织起来便构成了数据字典。定义规则时，常用的符号如表1-3所示。表1-3数据字典符号符号含义示例=被定义为+与X=a+b表示X由a和b组成-1-或X=a|b母X由a或b组成m-n重复X=2a6或表示重复26次-重复FX=a成示X由0个或多个a组成(.)可选X=(a匿示a在X中可能出现，也可能不出现土.，基本数据兀素X="a”表示X是取值为字符a的数据兀素.连接符X=1.9表示X出取1到9

34、中的任意一个值以某教务系统为例，学生成绩库文件的数据字典描述可以表示为以下形式。文件名：学生成绩库记录定义：学生成绩=学号+姓名+课程代码+成绩+必修|选修学号：由6位数字组成姓名：24个汉字课程代码：8位字符申成绩：13位十进制整数文件组织：以学号为关键字递增排列3. E-R图它是进行需求分析，并归纳、E-R图用丁描述应用系统的概念结构数据模型，整理、表达和优化现实世界中数据及其联系的重要工具在建模的过程中，E-R图以实体、联系和届性三个基本概念概括数据的基本结构。实体就是现实世界中的事物，多用矩形框来表示，框内含有相应的实体名称。届性多用椭圆形表示，并用无向边与相应的实体联系起来，表示该届

35、性归某实体所有。可以说，实体是由若干个届性组成的，每个届性都代表了实体的某些特征。以教育系统为例，学生实体和届性如下图1-5所示。图表3-3:学生实体分析联系用菱形表示，并用无向边分别与有关实体连接起来，以此描述实体之间的关系。实体之间存在着三种联系类型，分别是一对一、一对多、多对多，它们反映到E-R图中就为相应的联系类型,即1:1、1:n和m:n。一对一联系是指甲实体的任何一个实例只能对应到乙实体的一个实例，并且乙实体的任何一个实例只能对应到甲实体的一个实例。比如，在一个座位分配系统中，“学生”实体和“座位”实体之间的关系就是一对一的。学生14分配.1>座位一对一联系:图表3-4:一对

36、一联系一对多联系是指甲实体的任何一个实例能够对应到乙实体的多个实例，而乙实体的任何一个实例只能对应到甲实体的一个实例。比如，在一个住宿管理系统中，一个“学生”只能分配到一间“宿舍”，而一间“宿舍”可以容纳多个“学生”，如下图所示。学生n分配*上1*宿舍一对多联系图表3-5:一对多联系多对多联系是指甲实体的任何一个实例能够对应到乙实体的若干个实例，而乙实体的任何一个实例也可以对应到甲实体的若干个实例。比如，在一个选课系统中，一个“学生”可以选修若干门“课程”，同时一门“课程”也可以被若干个“学生”选修，如下图所示。学生m，:选修n勤课程'多对多联系图表3-6:多对多联系需要指出的是，同一

37、个系统的E-R图不具有唯一性，即不同的软件开发人员所设计出来的E-R图可能不同。3.1.2.3.3面向对象的分析方法3.1.2.3.3.1面向对象的基本概念近年来，为了克服传统软件工程方法存在的复用性和可维护性差以及难以满足用户需要等缺点，面向对象的思想越来越受到人们的欢迎和重视。面向对象的思想提倡运用人类的思维方式，从现实世界中存在的事物出发来构造软件。它建立在“对象”概念的基础上，以对象为中心，以类和继承为构造机制，来设计和构造相应的软件系统。面向对象的基本思想最先体现在面向对象程序设计语言中，然后才逐渐形成了面向对象的分析和设计方法。20世纪60年代开发的Simula67语言首次提出了对

38、象的概念，它是第一个面向对象程序设计语言。Ada语言是在20世纪70年代出现的乂一种支持数据抽象的基丁对象概念的程序设计语言。最具有代表性和影响力的面向对象程序设计语言是由美国Xerox（施乐）公司PaloAlto研究中心的AlanKay开发的Smalltalk语言。Smalltalk全面实现了面向对象技术的机制，丰富了面向对象的概念，它的发布引起了人们对面向对象概念的广泛关注。随后产生了多种面向对象程序设计语言，如C+和Java等，同时，面向对象的分析和设计方法也被广泛应用丁软件开发中。比较具有代表性的基丁面向对象思想的软件开发方法有GradyBooch提出的面向对象的分析与设计方法论、Ji

39、mRumbaugh!出的面向对象的建模技术和ZvarJacobsor®出的面向对象的软件工程方法学等。2003年，AlanKay因在面向对象程序设计上的杰出贡献，成为图灵奖的得主。AlanKay于1970年加入Xerox（施乐）公司的PaloAlt。研究中心。20世纪70年代初期，AlanKay等人开发了最具代表性和影响力的面向对象语言Smalltalk因此，被誉为“Smalltalk之父”。AlanKay不但是面向对象编程语言Smalltalk的发明人之一，也是面向对象编程思想的创始人之一。他是笔记本电脑最早的构想者，同时也是现代WindowsGUI的架构帅。AlanKey可谓是计

40、算机领域的大师。相对于传统的软件工程思想而言，面向对象的思想更符合人类的思维逻辑，它淡化了计算机的观点，以现实世界中的模型作为构造软件系统的依据。面向对象的基本概念包括对象、类、封装、继承和多态，下面介绍。1.对象对象可以是客观世界中存在的事物，也可以是概念化的实体，它由一组届性和操作组成。届性是用来描述对象静态特征的数据项，是对客观世界实体所具有性质的抽象。操作是用来描述对象动态特征。比如，把人当成一个对象，那么他的届性就有身高、体重、姓名和年龄等静态特征，他的操作就包括工作、学习、吃饭和运动等；把汽车当成一个对象，那么它的届性就有品牌、颜色、价格和寿命等，它的操作就包括加速、减速和刹车等。

41、理解对象的概念时，需要注意以下几点。对象的数据是封装起来的，对数据的处理需要通过特定的操作。对象之间通过传递消息进行通信，不同的对象独立地处理自身的数据。对象具有主动性。要处理对象的内部数据时，外界需要通过接口向对象发送消息，请求它执行特定的操作。2. 类类是对对象的抽象，是对具有相同届性和相同操作的一组相似对象的定义。通常情况下，很多对象都有相似的特征。比如，对于两个教师，他们虽然可能身高、体重、性别、年龄和籍贯等特征不同，但是职业却是相同的；对于两把椅子，它们可能颜色、形状、价格和位置等特征不同，但是作用却是相同的。在这种情况下，我们就可以忽略事物的非本质特征，只注意那些与当前目标相关的本

42、质特征，从中找出事物的共性，把本质特征相同的事物划分为一类，即将多个对象抽象为类。对于同类对象，它们具有相同的届性和操作，但是每个对象的届性值可能不同，执行操作的结果也可能不同。比如，在教务管理系统中，可以定义“学生”类，并定义编号、姓名和院系等届性，及登录该系统进行操作。每位学生都有自己特定的编号、姓名和院系等届性值，并且执行登录操作后，都会进入个性化的主贞。谈到类的概念，就必须知道什么是类的实例。实例是由某个特定的类描述的一个具体的对象。比如，对于”教师”类，某位教师”王一”就是类的一个实例；对于"学生"类，某位学生"李二"就是该类的一个实例。3.

43、封装封装是指把对象的届性和操作结合在一起，组成一个独立的单元。封装强调两个概念，即独立和封闭独立是指对象是一个不可分割的整体，它集成了事物全部的届性和操作，并且它的存在不依赖于外部事物。封闭是指与外部的事物通信时，对象要尽量地隐藏其内部的实现细节，它的内部信息对外界来说是隐蔽的，外界不能直接访问对象的内部信息，而只能通过有限的接口与对象发生联系。可以说，类是数据封装的工具，而对象是封装的实现。类的成员乂分为公有成员、私有成员和保护成员，它们分别有不同的访问控制机制。封装是软件模块化思想的重要体现。4.继承继承表示类之间的层次关系，它使得某类对象可以自动拥有另外一个或多个对象的全部届性和操作。比

44、如，某系统已经定义了一个学生类，现在还需要定义一个研究生类。由于研究生也届于学生的一种，它具有学生所有的一切届性和操作，这时就可以采用继承的方法，使研究生类直接获得学生类的一切届性和操作。在这个系统中，研究生类就叫做子类或派生类，学生类就叫做父类或基类。子类可以把父类定义的内容自动作为自己的部分内容，同时再加入新的内容。继承可以分为单重继承和多重继承。单重继承是指一个子类只有一个父类。多重继承是指一个子类可以同时继承多个父类。单重继承构成的类之间的关系是树状结构，多重继承构成的类之间的关系是网状结构。继承简化了定义一个新类的过程，有利于人们对事物的认识和描述，达到了软件复用的目的。5.多态多态

45、是一种使父类中定义的届性或操作被子类继承后，可以有不同的实现的机制。换句话说，多态允许届于不同类的对象对同一消息做出不同的响应。当一个对象接收到进行某项操作的消息时，多态机制将根据对象所届的类，动态地选用该类中定义的操作。比如，先定义一个父类”几何图形”，它具有”计算面积”的操作，然后再定义一些子类，如”三角形”、”长方形”和”圆形”，它们可继承父类"几何图形"的各种届性和操作，并且在各自的定义中要重新描述”计算面积"的操作。这样，当有计算几何图形面积的消息发出时，对象会根据类的类型做出不同的响应，采用不同的面积计算公式。多态这种机制极大地减少了软件设计中的冗余信

46、息，提高了软件的可复用性和可扩展性。3.1.2.3.3.2面向对象方法的特征与优势方法、工具和过程是软件工程方法学的三个重要因素。方法是指为了完成软件开发的各项任务所采用的技术方法。工具是为方法的实行提供的自动或半自动的支持。过程是指为了获得高质量的软件产品所需要完成的一系列任务的框架。在软件工程领域，“方法学”是被广泛使用的一个词汇。在20世纪70年代，“方法学”一词用于表示“开发软件产品的方式”，而该词实际上是指“方法的科学”。“方法学”应用于整个软件工程的过程。流行的软件工程方法目前比较流行的软件工程方法包括面向过程的软件工程方法、面向数据的软件工程方法、面向对象的软件工程方法和形式化的

47、软件工程方法。(1) 面向过程的软件工程方法基于“自顶向下，逐步求精”的原则来完成软件开发各阶段的任务。程序的执行过程主要由顺序、选择和循环等控制结构来控制。(2) 面向数据的软件工程方法中的数据是指元数据。元数据并不表示某一记录的具体信息,而是用来将一些基础数据组织起来,即元数据是组织数据的数据。比如，信息系统中实体名及姓名的集合，或者数据库中物理表的表名及字段名的集合。这种方法与关系数据库联系紧密，特别适合信息系统中数据层的设计与实现。(3) 面向对象的软件工程方法是当前最流行的软件工程方法，它主要有以下几个方面的特征。把数据和操作封装在一起，形成对象。对象是构成软件系统的基本构件。把特征

48、相似的对象抽象为类。类之间可以存在继承或被继承的关系，形成软件系统的层次结构。对象之间通过发送消息进行通信。将对象的私有信息封装起来。外界不能直接访问对象的内部信息，而必须是发送相应的消息后，通过有限的接口来访问。(4) 形式化的软件工程方法基于严格的数学逻辑，多应用于对安全性和可靠性要求较高的特殊领域。面向对象的软件工程方法的优点符合人类的思维习惯。通常人类在认识客观世界的事物时，不仅会考虑到事物会有哪些届性，还会考虑到事物能完成哪些操作，也就是说静态的届性及动态的动作特征都是组成事物的一部分，它们组合起来才能完整地表达一个事物。而面向对象的软件工程方法最重要的特点就是把事物的届性和操作组成

49、一个整体，以对象为核心，更符合人类的思维习惯。此外，面向对象的软件工程方法更加注重人类在认识客观世界时循序渐进，逐步深化的特点。用面向对象的软件工程方法进行软件开发的过程，是一个主动的多次反复迭代的过程，而不是把整个过程划分为几个严格的顺序阶段。稳定性好。传统的软件工程方法基于功能分析和功能分解。当软件功能发生变化时，很容易引起软件结构的改变。而面向对象的软件工程方法则是基于对象的概念，用对象来表示与待解决的问题相关的实体，以对象之间的联系来表示实体之间的关系。当目标系统的需求发生变化时，只要实体及实体之间的联系不发生变化，就不会引起软件系统结构的变化，而只需要对部分对象进行局部修改(如从现有

50、的类中派生出新的子类)就可以实现系统功能的扩充。因此，基于对象的软件系统稳定性比较好。(2) 可复用性好。面向对象技术采用了继承和多态的机制，极大地提高了代码的可复用性。从父类派生出子类，一方面复用了父类中定义的数据结构和代码，另一方面提高了代码的可扩展性。可维护性好。由于利用面向对象软件工程方法开发的软件系统稳定性好和可复用性好，而且采用了封装和信息隐藏机制，易于对局部软件进行调整，所以系统的可维护性比较好。基于以上这些优点，面向对象的软件工程方法越来越受到人们的宵睐。3.1.2.3.3.3. 面向对象需求分析方法面向对象的需求分析基于面向对象的思想，以用例模型为基础。开发人员在获取需求的基

51、础上，建立目标系统的用例模型。所谓用例是指系统中的一个功能单元，可以描述为操作者与系统之间的一次交互。用例常被用来收集用户的需求。首先要找到系统的使用者，即用例的操作者。操作者是在系统之外，透过系统边界与系统进行有意义交互的任何事物。“在系统之外”是指操作者本身并不是系统的组成部分，而是与系统进行交互的外界事物。这种交互应该是“有意义”的交互，即操作者向系统发出请求后，系统要给出相应的回应。而且，操作者并不限于人，也可以是时间、温度和其他系统等。比如，目标系统需要每隔一段时间就进行一次系统更新，那么时间就是操作者。可以把操作者执行的每一个系统功能都看作一个用例。可以说，用例描述了系统的功能，涉

52、及系统为了实现一个功能目标而关联的操作者、对象和行为。识别用例时，要注意用例是由系统执行的，并且用例的结果是操作者可以观测到的。用例是站在用户的角度对系统进行的描述，所以描述用例要尽量使用业务语言而不是技术语言'0确定了系统的所有用例之后，就可以开始识别目标系统中的对象和类了。把具有相似届性和操作的对象定义为一个类。届性定义对象的静态特征，一个对象往往包含很多届性。比如，读者的届性可能有姓名、年龄、年级、性别、学号、身份证号、籍贯、民族和血型等。目标系统不可能关注对象的所有届性，而只是考虑与业务相关的届性。比如，在”图书馆信息管理”系统中，可能就不会考虑读者的民族和血型等届性。操作定义

53、了对象的行为，并以某种方式修改对象的届性目标系统的类可以划分为边界类、控制类和实体类。边界类代表了系统及其操作者的边界，描述操作者与系统之间的交互。它更加关注系统的职责，而不是实现职责的具体细节。通常，界面控制类、系统和设备接口类都届于边界类。控制类代表了系统的逻辑控制，描述一个用例所具有的事件流的控制行为，实现对用例行为的封装。通常，可以为每个用例定义一个控制类。实体类描述了系统中必须存储的信息及相关的行为，通常对应于现实世界中的事物。确定了系统的类和对象之后，就可以分析类之间的关系了。对象或类之间的关系有依赖、关联、聚合、组合、泛化和实现。依赖关系是“非结构化”的和短暂的关系，表明某个对象

54、会影响另外一个对象的行为或服务。关联关系是“结构化”的关系，描述对象之间的连接。聚合关系和组合关系是特殊的关联关系,它们强调整体和部分之间的从届性，组合是聚合的一种形式，组合关系对应的整体和部分具有很强的归届关系和一致的生存期。比如，计算机和显示器就届于聚合关系。泛化关系与类问的继承类似。实现关系是针对类与接口的关系。明确了对象、类和类之间的层次关系之后，需要进一步识别出对象之间的动态交互行为，即系统响应外部事件或操作的工作过程。一般采用顺序图将用例和分析的对象联系在一起，描述用例的行为是如何在对象之间分布的。最后，需要将需求分析的结果用多种模型图表示出来，并对其进行评审。由丁分析的过程是一个

55、循序渐进的过程，合理的分析模型需要多次迭代才能得到。3.1.2.4. 需求分析过程有了上述分析方法、建模的指导，那如何有效地应用到需求分析过程中？本章节主要结合面向对象的分析方法、建模工具来讲述需求分析的各个阶段与任务。分析过程可概括总结为三个阶段，参见下图：一阶段：建立框架，理活业务脉络与框架，初步进行分解（业务流程分析、业务实体分析、角色与使用场景分析），该阶段的输出物是需求说明书中业务流程分析、业务实体分析以及用例分析。二阶段：填充细节，完成上述用例的内容填充、类图填充。这个阶段工作量非常大，也可能需要多次迭代完成。三阶段：非功能性需求细节。包括接口需求、全局性的非功能性需求、全局性的技

56、术约束。表3-7:分析过程3.1.2.4.1L阶段分析过程这个阶段工作的输入是从立项阶段或业务原始需求初步梳理的业务事件列表和报表列表、输出是用例模型和概念层的类图。对应丁RUP中的细化阶段的第一次迭代。该阶段结束的标志是标示出了绝大部分的用例，生成了概念层类图。在整个过程中是针对每个业务事件进行业务流程分析、业务实体分析和用例分析；针对每个报表进行业务实体分析和用例，如下图所示。每个业务事件的过程业务术语间的关系不同角色的任务表3-8:一阶段分析过程第一步：流程图编制。每个业务事件都是一个业务流程的触发，沿着对业务事件的响应序歹0,找到所有相关的业务活动，表述这些业务活动之间的关系、了解这些活动需要接受哪些信息、产生哪些信息（表单），确定数据传送路线，同时标示出活动执行的部门、岗位。由丁业务事件是分类型的，因此流程也是分类型，主要是三类：生产类、管理类、支撑类。后面两类都容易遗漏。借助分类可以获得更完整的流程列表。下表是以cdma为例给出业务事件与流程列表示例：分类业务事件名称流程名称流程编号生产类新装Cdma新装流程YW-LC-CP-001补卡Cdma补卡流程YW-LC-CP-002管理类资费特批资费特批流程YW-LC-ZF-001码号特批码号特批流程YW-LC-ZY-001支持性Uim卡