业务需求分析师.docx

业务需求分析师

目 录
目 录 2
第1章. 软件需求现状与常见问题 7
1.1. 软件需求现状分析 7
1.2. 需求常见问题分析 8
第2章. 软件需求与需求工程 11
2.1. 软件需求 11
2.2. 软件需求定义 11
2.2.1. 需求的层次 11
2.2.2. 软件需求的类型 13
2.2.3. 软件需求的重要性 15
2.2.4. 优秀需求的标准 16
2.3. 软件需求工程 17
第3章. 需求开发 19
3.1. 需求开发管理 19
3.1.1. 需求获取 19
3.1.2. 需求分析 22
3.1.3. 需求评审 52
第4章. 需求管理 55
4.1. 需求基线管理 55
4.2. 需求变更管理 55
4.2.1. 需求变更控制活动 57
4.2.2. 需求变更控制委员会 59
4.2.3. 需求变更波及分析 62
4.2.4. 需求稳定性评估 65
4.3. 需求跟踪 66
4.3.1. 需求跟踪目的 66
4.3.2. 需求跟踪能力矩阵 67
4.3.3. 需求跟踪能力工具 71
4.3.4. 需求跟踪能力过程 71
4.4. 需求后评估 72
4.4.1. 成本评估 73
4.4.2. 效益评估 73

第1章. 软件需求现状与常见问题
1.1. 软件需求现状分析
在信息化高速发展与行业竞争日趋激烈的今天，构建符合中国电信企业战略的信息化系统是我们IT专业人员要解决好地关键课题。然而在软件项目实施过程中，进度超期、经费超预算、变更频繁的现象层出不穷，许多项目无法达到预期目标，归根结底，软件需求质量是问题的主要根源之一。
软件需求是软件项目关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点。它不像硬件的需求，是有形的、客观的、可描述的、可检测的。软件需求是软件项目最难把握的问题，同时又是关系项目成败的关键因素。
既然软件需求如此重要，那么需求相关的哪些因素是导致项目失败的根源？
美国的第三方机构Standish Group 每隔几年都会对软件项目现状进行分析与统计，其分析报告“CHAOS REPORT”①的研究结果显示：高达31.1%的项目彻底失败，高达52.7%的项目进度超期或成本超支，被认为成功的项目仅有16.2%。
为了帮助软件开发组织找到明确的改进方向，Standish Group还总结出了十大成功保证和十大败因，如表1-1所示。
在表1-1中可以看出，十大成功因素中有三个直接与需求相关（已加粗显示），累计权重达37.1%；而十大失败因素中有五个直接与需求相关，累计权重达51.6%，可见需求对项目影响程度之高。
表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. 需求常见问题分析
下面简要地对需求相关的这些失败因素做初步的分析，更多的内容将随着本书的进程继续深入。
1. 不完整的需求
在日常工作中，该问题经常困扰着我们——“什么样的需求是完整的呢？”如果没有一个有效的“需求完整性评价标准”，那么这个问题将是无解。要破解这个问题。首先应回答一个铺垫性的问题——“谁更有可能可以对需求的完整性进行评价？”。答案应该是“业务专家或业务代表要比it人员更适合对完整性进行评价”。
要想让业务专家能够更好地参与到完整性评价中，应该做到以下两点：
Ø 采用“业务导向”的树型层次结构展现需求文档。假若“需求规格说明书”中充斥着诸如数据字典、报表子系统、新增客户等以技术动词为主的字眼与结构，很有可能业务人员望而却步。而采用业务导向的结构，是用业务人员熟悉的场景为索引，加之树型层析结构可以将宏观信息与微观信息进行有效剥离。
Ø 按“组织层次”划分来完成需求的验证。日常工作中常见的场景是用业务代表的签字确认来代替需求验证。 需求验证是重要的需求质量环节，目的是暴露出更多的错误，而确认则代表了职责。可一个企业中少有人能上通战略下解具体操作，为了让业务人员有效的验证需求，需求文档的树型结构应面对不同的层面：决策层、管理层、操作层，将需求分成不同部分，让合适的人验证适当的部分。
2. 缺乏用户参与
在很多项目中，使用者都不能有效地参与到项目中来，诸如“你们先做，做出来我们试试，有问题再改”之类的话也是常常听到。主要应对措施是充分研究业务代表的关注点、利益点，通过业务利益争取使用者参与到需求活动中。
3. 不切实际的用户期望
很多情况下，业务人员都会提出大量的需求，有些是技术上根本无法实现的，有的则是项目费用、项目时间等预算内无法实现的。究其原因，主要在于软件的无形和软件成本的不透明。要解决这样的问题，在当前国内的软件实施环境下，能做的是it人员主动地帮助使用者更好的理解软件成本，说明清楚为什么做不到，取得理解，达成一致才是关键。
4. 需求变更频繁
导致需求变更的原因很多，常见的因素包括：
l 开发人员对待需求开发的态度不认真
l 用户参与不够
l 模棱两可的需求。
l 用户和需求开发人员在理解上的差异。
l 过于简单的规格说明。
l 不准确的计划等。
有效控制变更应该注意采取合理的需求管理方法：
l 需求分析阶段尽可能采用原型或者用例方法明确用户需求。
l 采用严格的需求变更管理流程。
l 采用良好的体系结构。
l 采用面向对象思想。
详细的方法请参见第3章节内容。
5. 提供了不需要的功能
很多项目中都或多或少的含了些很少使用或无人使用的功能，这种情况如何在事前预防呢？在需求阶段有效地划分优先级是个办法。这里所说的优先级划分不是“拍脑袋”的产物，而是真正基于业务领域知识来衡量需求的必要性和充分性，在此基础上做出划分。第2章节有关于“合理划分优先级的方法”的详细说明。
上述分析是需求工作中常见问题的解决建议，分析比较粗浅。若要有效的解决问题，就需要反思问题背后的本质原因，掌握需求理论与工作方法，针对性的找到适用的需求方法，构思、尝试出真正在本组织内有效的缓解手段。
第2章. 软件需求与需求工程
1.
2.
1.
2.
2.1. 软件需求
2.2. 软件需求定义
什么是软件需求，这个看似简单的问题并不好回答。也许有很多人简单地认为软件需求就是用户需要实现的功能加上一些非功能方面的要求。但这样的理解并不完整，本章将对一些与需求相关的关键概念进行阐述。
软件需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么样的性能。软件人员要准确理解用户的要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转化到相应形式的需求规格说明的过程。对于软件项目的需求，首先要明确用户的要求，澄清模糊的需求，与用户达成共识。
2.2.1. 需求的层次
有时也可以将软件需求按照层次来说明，包括业务需求、用户需求、软件需求、软件需求规格等层次，它们的关系如下图1-1所示。
图表 21软件需求按照层次
1. 业务需求
业务需求反映了组织机构或客户对系统、产品高层次的目标要求，由管理人员或市场分析人员确定。因为业务需求的提出人通常是企业的管理人员，它完全是从业务角度描述的，是指导软件开发的高层需求。实际上在项目立项阶段就整理完成了。
2. 用户需求
用户需求是指软件使用者的要求和软件应满足的用户特性，一般是用户协助提供。通常是在业务需求定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立用户角度的需求。用户需求是需求调研的产物，它具有以下特点：
Ø 零散：用户会提出不同角度、不同层面、不同粒度的需求，而且通常是以一句话的形式提出的。
Ø 存在矛盾：由于用户处于企业组织的不同层面、地域等，难免出现盲人摸象的现象，从而导致需求的片面性，甚至在不同用户之间会有不同的观点。
正因为如此，我们还需要对用户需求（也叫原始需求）进行分析整理，从而整理出更加精确的需求说明。
3. 软件需求
软件需求定义了开发人员必须实现的软件功能，使得用户通过使用此软件能完成它们的任务，从而满足业务需求。它是分析人员在对用户需求进行分析、提炼、整理，从而生成指导开发的、更精确的软件需求。它是需求分析与建模的产物，即形成软件需求规格。
软件需求规格充分描述了软件系统应具有的外部行为，它描述了系统展现给用户的行为和执行的操作等。它包括：产品必须遵从的标准、规范和合约；外部界面的具体细节；非功能性需求（例如性能要求等）；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特性进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。
软件需求规格在开发、测试、质量保证、项目管理以及相关项目功能中都起到了重要的作用。
2.2.2. 软件需求的类型
软件需求可以分为功能需求、非功能需求和设计约束三种类型。
1. 功能需求
对于功能需求而言，最为关键的地方是如何对其进行组织，否则一句话、一句话的描述就会显得十分零散，很难保证开发人员逐一满足这些需求。
在传统的方法论中，会以系统-子系统-模块-子模块的层次结构来组织，但它更多的是按照程序的结构来梳理，会割裂用户的使用场景。
为了解决这个问题，现代需求理论更加强调需求分析人员从用户的角度，将系统理解为一个黑盒子，从横向的使用视角来整理需求。不管是RUP的用例方法还是XP的用户故事，以及特征驱动开发的Feature,都是从这个角度进行梳理的。本教材推荐使用用例的方法。
2. 非功能性需求
非功能需求是一些限制性要求，是对实际使用环境所做的要求，例如性能要求、可靠性要求、安全性要求等。非功能需求比功能需求要求更严格，更不易满足，因为如果不能满足非功能需求，系统将无法运行。
非功能需求方面常见的问题有两个：一是信息传递的无效性；二是忽略了非功能需求的局部性。
Ø 信息传递的无效性：很多需求规格说明书中，会通过一个小章节来说明非功能需求，列出诸如高可靠性、高可用性、高扩展性等要求。但很多开发人员根本不看它，因为这样的定性描述是没有标准的，因此信息的有效性不大。本书的后续章节将说明解决方法。
Ø 忽略了非功能需求的局部性：我们经常会看到“所有查询响应时间都应该小于5秒”的描述，但是当查询稍长周期的数据量时这样的要求可能无法实现。因此开发人员会认为这项原则是可以破坏的。更科学的做法就是抓住具体的场景来描述。
3. 设计约束
设计约束看似简单，但如果不了解而导致收集需求时出现遗漏的现象。
Ø 非技术因素决定的选型
对软件开发而言，技术选型会基于企业内部的相关规定。例如，必须采用J2EE技术；中间件必须采用WEBSPHERE等。
Ø 使用的软硬件条件与环境
在决定架构、选择实现技术时会受到软硬件设备的影响，如果忽略了此种因素会造成不必要的麻烦。例如，当前导购人员使用的平台电脑的操作系统不支持FLASH插件、乡村支局点的电脑配置较低等。
用户的环境也会对软件开发造成影响，需求人员应该搜集此类信息。
2.2.3. 软件需求的重要性
开发软件项目就像和用户一起从河的两边开始修建桥梁，如果没有很好的理解和管理用户的需求，开发出来的软件不是用户希望的，那么这座桥就永远不可能对接成功。没有一个合理的需求管理，将很难达到用户的真正要求。即使设计和实现的再正确可靠，也不是用户真正想要的东西。所以，需求分析很重要，项目需求是制定项目计划、开发项目产品和从事项目活动的依据。项目的计划、项目的开发活动及开发的产品应与项目需求保持一致，随需求的变化而调整。因此，必须采用有效的方法对项目需求的变化进行管理和控制。项目需求管理过程主要包括对用户提出的出示需求的确认过程和对用户提出需求变更的控制过程。
软件需求研究的对象是软件项目的用户要求。需要注意的是，必须全面理解用户的各项要求，但又不能全盘接受用户所有的要求，因为用户提出的要求并非都是合理的。对于其中模糊的要求，还需要向用户澄清，然后才能决定是否可以采纳。对于那些无法实现的要求，应向用户做充分的解释，以求得用户的谅解。
2.2.4. 优秀需求的标准
通用的优秀需求的标准分为7个：完整性、正确性、无歧义性、必要性、有先后次序、可行性、可验证性。下文将其分为四组，逐一介绍。
1. 完整性
完整性即需求没有遗漏。这点在实际需求活动中很难做到或衡量。第1章中我们提到过完整性的实现要点。
1) 必须从业务角度来组织各种需求项。
2) 必须按人员分层来验证需求。
2. 不失真
需求的正确性和无歧义性是一组相关的要求，指的是确保需求在信息传递的过程中不失真。达到这两个方面的标准需要从两个角度实现：
1) 正确性：要使需求正确应找到正确的人来参与。一方面是在调研阶段找多方面的人来获取需求。避免片面性；另一方面是应该找到直接相关的人员进行验证。
2) 无歧义性：歧义主要是不同背景的人在传递时加入不同理解而导致的，因此仅靠文档来传递需求是不充分的，文档无法代替沟通，还需要配合一些验证活动才能够尽可能的缓解歧义问题。
3. 有优先级
“事有轻重缓急”，一句话概括了区分优先级的重要性。要想更好地对项目进行管理，就需要有效的区分出优先级。很多时候需求会被冠以“高优先级”，实际上是担心IT不去实现。相对科学的划分优先级有充分性和必要性两个维度。用“实现后的收益”（充分性）与“不实现的影响”（必要性）两个量化值相乘，就可得到一个更有参考价值的权重，从而更适合做优先级评价。如下表示例。
需求项
评价项
评价结果
提供键盘快捷方式触发菜单页面方式
实现后的收益
⊙非常显著⊙比较显著●显著⊙一般

不实现的影响
⊙非常显著⊙比较显著⊙显著●一般

总评价
2分 X 1分=2分
4. 有技术早期介入
需求文档的读者是IT开发、测试团队，那么与开发、测试团队交流，探讨文档有哪些不足、缺少什么信息，是改进需求文档的有效方法优秀需求评价标准中的可行性就需要开发团队尽早介入。可验证性则是说明需求提供了验证所需的信息，也能够指导测试活动。
2.3. 软件需求工程
软件工程活动包括需求、系统分析与设计、编码、测试、配置管理等一系列活动。但唯独只有需求被称为工程。需求工程形成于20世纪80年代中期，是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。
如图表 22需求工程图所示，需求工程包括需求开发和需求管理两大范畴。需求开发是收集、分析、整理、编写、验证需求的全过程，重点在于开发出高质量的规格说明。需求管理则是对需求的实现、变化进行追踪的全过程，重点在于开发的软件满足这些需求。

图表 22需求工程图
设计5
编码10
测试20-50
运行与维护200
实行有效的需求工程管理的组织能获得多方面的好处。最大的好处就是在开发后期和整个维护阶段的返工的工作量可以大大减少。研究表明：如果在需求阶段只需花费一个单位时间就能改正的错误拖到设计阶段改正就需要五倍时间，到了编码阶段将是十倍时间，后续阶段耗费时间将更多。

图表 23需求工程工作量分布图示
第3章. 需求开发
3.
3.1. 需求开发管理
需求开发工作要点包括需求获取、需求分析、需求规格编写、需求评审四个具体的活动。这些活动工是多次迭代的，每次过程如图表 31：需求开发工作。

图表 31：需求开发工作
一般在整个软件开发过程中要至少需要迭代三次。
3.1.1. 需求获取
需求获取是需求开发的第一个活动，需求获取是通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求。
如何提高需求获取的有效性一直以来是困扰大家的问题。需求获取的要点在于计划性和科学性。计划性体现在对调研对象、问题、实践的计划；科学性则表现在如何有效地选择合适的方法。
需求获取执行的活动与主要方法：
需求获取有许多方法，每种各有缺点，使用的时机与具体执行的活动也不相同，因此需求分析人员需要了解方法的使用要点。
1. 用户访谈
用户访谈是最常见、也是最基本的需求获取技术。访谈者是否善于访谈，将直接影响最终的结果。
Ø 用户访谈的优缺点
用户访谈的优点是直接有效，形势灵活、交流深入。缺点是占用时间长，信息可能存在片面性。
用户访谈是需求获取的主体技术，只要有可能，就应该尽可能多地进行访谈。
Ø 用户访谈的类型
需要了解客户方的所有用户类型以及潜在的类型。然后，根据他们的要求来确定系统的整体目标和系统的工作范围。一般将访谈者分成不同类型，一般分为高层管理者、中层管理者、操作层。在不同阶段访谈不同类型的人，访谈的话题与目的也有所不同。
Ø 访谈的沟通技巧
访谈过程是一个对沟通技巧要求较高的活动，要求访谈者善于倾听、善于表达。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需要注意的是，每一次交流一定要求记录，对于交流的结果还可以进行分类，便于后续的分析活动。例如，可以将需求细分为功能需、非功能需求（如响应时间、平均无故障时间、自动恢复时间等）、环境限制、设计约束等类型。
在此描述主要的一些策略或技巧。
（1） 制作访谈问卷并事先发给访谈者
（2） 把握语言节奏，尽量使用简单语言表达清楚问题。
（3） 灵活采用封闭式问题（类似判断题）、半封闭式问题（类似选择题）和开放式问题（类似简答题）。
（4） 安排好问题顺序，一般遵循业务逻辑排序。
（5） 访谈中最好及时用草图绘制模型（用例、DFD、思维图）。
（6） 注意沟通细节， 说话语气不要过于强势、业务人员使用的术语不懂应及时请教。
Ø 访谈计划的制定
访谈应有计划性，在访谈前做好时间、人员、问题等各类计划。
2. 用户调查
Ø 优缺点
优点是调查面广，能够获得更多人的反馈，能够克服访谈的片面性。缺点是不易深入。
Ø 调查问卷设计要点
应注意问题的篇幅与布局；注意问题类型的选择，多选择半封闭性问题，还应有一定比例的开放性问题。
Ø 调查问卷分析要点
应注意筛除无效问卷；按填写人类型分类；对于回答含混不清的可做针对性访谈。
3. 文档研究
Ø 优缺点
优点是能详细、直观地对一些细节进行了解与分析，缺点是在企业中文档量比较大，有时还会有误导性。
Ø 适用性
适用于数据类需求的获取，尤其是研究、分析、细化数据需求的手段。
4. 原型法
Ø 优缺点
优点是最直观、生动的方式，用户对界面也提供了早期评审。缺点是花费时间多，效率低。
5. 现场观摩法
Ø 优缺点
优点是开发团队对业务可建立直观认识。缺点是花费时间多，有时结果会失真。
Ø 选用时机
在对关键业务不清晰时，可采用此法。
3.1.2. 需求分析
3.1.2.1. 需求分析的内涵
需求分析是需求开发的核心任务，它是通过对业务问题的研究，本质上是业务分析，即选择一种业务导向的线索将零散的用户需求串起来，形成一个体系完整、内容清晰的需求框架。
需求分析的任务并不是分析系统如何实现用户的需要，而是解决目标系统“做什么”的问题。需求也是与技术无关的。技术的实现细节是在后面的设计阶段才需要考虑的事情。很多情形下，分析用户需求实际上是与获取用户需求并行的。
3.1.2.2. 需求建模的目标与要点
需求建模是需求分析的主要手段，它通过一组模型来简化、帮助需求分析人员理清思路、提供一种详细说明所需系统特性的方法。
为什么要需求建模？在日常生活中我们会发现模型早已在各个领域得到广泛使用。盖房子会有一整套的建筑图模型，很少看到用大篇幅的文字来描述要建的房子；电子设备制造同样会有各类电路图。这些模型有效的帮助人们更好的认识、应用、设计复杂的事物。软件行业的复杂度相比其他领域有过之无不及，有了模型，可以让我们更好的理解要建设的系统。
在实际建模过程中，应注意以下几点：
选择创建什么建模方式或模型对如何解决问题、形成解决方案由深远影响。
最好的模型是与现实相联系的。
不能为了建模而建模，如果不能对构建系统起到作用，那就是资源浪费。
3.1.2.3. 需求建模主要方法
需求建模可以使用建模工具，利用建模方法论来指导我们有效建模。
建模方法论的发展见下表1-2。
方法论
所处时代
建模要点
程序=数据结构+算法
上世纪50~60年代，主要解决科学计算问题
选择合适的数据结构与算法
结构化分析与设计
上世纪60~70年代，主要解决与数据处理相关问题
一、确定由那些数据，格式、存储，提供E/R模型；二、确定数据的加工处理过程，提供DFD图
面向对象分析与设计
上世纪80~90年代，主要支持业务过程相关问题
数据不是唯一视角，人的视角得到重视。
表1-2
3.1.2.3.1. 结构化分析方法
结构化需求分析是20世纪70年代由Yourdon、Constaintine及DeMarco提出的一种面向数据流的需求分析方法。它基于“分解”和“抽象”的基本思想，逐步建立目标系统的逻辑模型，进而描绘出满足用户要求的软件系统。
“分解”是指对于一个复杂的系统需求，为了将复杂性降低到可以掌握的程度，可以把大问题分解为若干个小问题，然后再分别解决。下图演示了对目标系统X进行自顶向下逐层分解的示意图。

　 自顶向下逐层分解
图表 32：结构化分析
最顶层描述了整个目标系统需求，中间层将目标系统需求划分为若干个模块，每个模块完成一定的功能，而最底层是对每个模块实现方法的细节性描述。可见，在逐层分解的过程中，起初并不考虑细节性的问题，而是先关注问题最本质的属性，随着分解自顶向下进行，才逐渐考虑越来越具体的细节。这种用最本质的属性表示一个软件系统需求的方法就是"抽象"。
分解和抽象是结构化需求分析的基本指导思想。在结构化需求分析的过程中，通常还需要借助数据流程图、数据字典、E-R图、结构化语言、判定表、判定树等工具。接下来我们介绍数据流图、数据字典和E-R图的相关知识。
3.1.2.3.2. 结构化需求分析的工具
1. 数据流图
数据流图（Data Flow Diagram，DFD）是描述系统中数据流的图形工具，是一种用来表示信息流和信息变换过程的图解方法，可以标识一个系统的逻辑输入和逻辑输出，以及把逻辑输入转换为逻辑输出所需的加工处理。数据流图把软件系统看成是由数据流联系的各种功能的组合，在需求分析的过程中，可以用来建立目标系统的逻辑模型。
结构化需求分析采用的是"自顶向下，由外到内，逐层分解"的思想，开发人员要先画出系统顶层的数据流图，然后再逐层画出低层的数据流图。顶层的数据流图要定义系统需求范围，并描述系统需求与外界的数据联系，它是对系统需求架构的高度概括和抽象。底层的数据流图是对系统需求某个部分的精细描述。
在绘制数据流图的过程中，主要用到了4个基本符号：
信息源符号：，表示数据的源点或重点，它是系统之外的实体，可以是人、物或者其他系统
加工：，表示对数据进行加工或处理，比如对数据的算法分析和科学计算。
数据存储：，表示输入或输出文件。这些文件可以是计算机系统中的外部或者内部文件，也可以是表和账单等。
数据流：，表示数据的流动方向。数据流可以从加工流向加工，从加工流向文件，或者从文件流向加工。
在绘制数据流图的过程中，要注意以下几点。
1) 数据的处理不一定是一个程序或一个模块，也可以是一个连贯的处理过程。
2) 数据存储是指输入或输出文件，但它不仅仅可以是文件，还可以是数据项或用来组织数据的中间数据。
3) 数据流和数据存储是不同状态的数据。数据流是流动状态的数据，而数据存储是指处于静止状态的数据。
4) 当目标系统需求的规模较大时，为了描述的清晰和易于理解，通常采用逐层分解的方法，画出分层的数据流图。在分解时，要考虑到自然性、均匀性和分解度几个概念。
5) 自然性是指概念上要合理和清晰。
6) 均匀性是指尽量将一个大问题分解为规模均匀的若干部分。
7) 分解度是指分解的维度，一般每一个加工每次分解最多不宜超过7个子加工，应分解到基本的加工为止。
8) 数据流图分层细化时必须保持信息的连续性，即细化前后对应功能的输入和输出数据必须相同。
2. 数据字典
用数据流图来表示系统的逻辑模型直观且形象，但是缺乏细节描述，也就是说它没有准确和完整地定义各个图元。可以用数据字典（data dictionary，DD）来对数据流图做出补充和完善。
数据字典用于定义数据流图中各个图元的具体内容，为数据流图中出现的图形元素做出确切的解释。数据字典包含4类条目：数据流、数据存储、数据项和数据加工。这些条目按照一定的规则组织起来便构成了数据字典。定义规则时，常用的符号如表1-3所示。
表1-3　数据字典符号
符号
含义
示例
=
被定义为

+
与
X=a+b表示X由a和b组成
[…|…]
或
X=[a | b]表示X由a或b组成
m{…}n
重复
X= 2{a}6或表示重复2～6次
{…}
重复
X={a}表示X由0个或多个a组成
(…)
可选
X=(a)表示a在X中可能出现，
也可能不出现
“…”
基本数据元素
X=“a”表示X是取值为字符a的数据元素
..
连接符
X=1..9表示X可取1到9中的任意一个值
以某教务系统为例，学生成绩库文件的数据字典描述可以表示为以下形式。
文件名：学生成绩库
记录定义：学生成绩 = 学号+姓名+{课程代码+成绩+[必修|选修]}
学号：由6位数字组成
姓名：2～4个汉字
课程代码：8位字符串
成绩：1～3位十进制整数
文件组织：以学号为关键字递增排列
3. E-R图
E-R图用于描述应用系统的概念结构数据模型，它是进行需求分析，并归纳、整理、表达和优化现实世界中数据及其联系的重要工具。
在建模的过程中，E-R图以实体、联系和属性三个基本概念概括数据的基本结构。实体就是现实世界中的事物，多用矩形框来表示，框内含有相应的实体名称。
属性多用椭圆形表示，并用无向边与相应的实体联系起来，表示该属性归某实体所有。可以说，实体是由若干个属性组成的，每个属性都代表了实体的某些特征。以教育系统为例，学生实体和属性如下图1-5所示。

学生实体的属性
图表 33：学生实体分析
联系用菱形表示，并用无向边分别与有关实体连接起来，以此描述实体之间的关系。实体之间存在着三种联系类型，分别是一对一、一对多、多对多，它们反映到E-R图中就为相应的联系类型，即1:1、1:n和m:n。
(1) 一对一联系是指甲实体的任何一个实例只能对应到乙实体的一个实例，并且乙实体的任何一个实例只能对应到甲实体的一个实例。比如，在一个座位分配系统中，“学生”实体和“座位”实体之间的关系就是一对一的。

一对一联系
图表 34：一对一联系
(2) 一对多联系是指甲实体的任何一个实例能够对应到乙实体的多个实例，而乙实体的任何一个实例只能对应到甲实体的一个实例。比如，在一个住宿管理系统中，一个“学生”只能分配到一间“宿舍”，而一间“宿舍”可以容纳多个“学生”，如下图所示。

一对多联系
图表 35：一对多联系
(3) 多对多联系是指甲实体的任何一个实例能够对应到乙实体的若干个实例，而乙实体的任何一个实例也可以对应到甲实体的若干个实例。比如，在一个选课系统中，一个“学生”可以选修若干门“课程”，同时一门“课程”也可以被若干个“学生”选修，如下图所示。

多对多联系
图表 36：多对多联系

需要指出的是，同一个系统的E-R图不具有唯一性，即不同的软件开发人员所设计出来的E-R图可能不同。
3.1.2.3.3. 面向对象的分析方法
3.1.2.3.3.1. 面向对象的基本概念
近年来，为了克服传统软件工程方法存在的复用性和可维护性差以及难以满足用户需要等缺点，面向对象的思想越来越受到人们的欢迎和重视。面向对象的思想提倡运用人类的思维方式，从现实世界中存在的事物出发来构造软件。它建立在“对象”概念的基础上，以对象为中心，以类和继承为构造机制，来设计和构造相应的软件系统。
面向对象的基本思想最先体现在面向对象程序设计语言中，然后才逐渐形成了面向对象的分析和设计方法。20世纪60年代开发的Simula67语言首次提出了对象的概念，它是第一个面向对象程序设计语言。Ada语言是在20世纪70年代出现的又一种支持数据抽象的基于对象概念的程序设计语言。最具有代表性和影响力的面向对象程序设计语言是由美国Xerox（施乐）公司Palo Alto研究中心的Alan Kay开发的Smalltalk语言。Smalltalk全面实现了面向对象技术的机制，丰富了面向对象的概念，它的发布引起了人们对面向对象概念的广泛关注。随后产生了多种面向对象程序设计语言，如C++和Java等，同时，面向对象的分析和设计方法也被广泛应用于软件开发中。比较具有代表性的基于面向对象思想的软件开发方法有Grady Booch提出的面向对象的分析与设计方法论、Jim Rumbaugh提出的面向对象的建模技术和Zvar Jacobson提出的面向对象的软件工程方法学等。
2003年，Alan Kay因在面向对象程序设计上的杰出贡献，成为图灵奖的得主。Alan Kay于1970年加入Xerox（施乐）公司的Palo Alto研究中心。20世纪70年代初期，Alan Kay等人开发了最具代表性和影响力的面向对象语言Smalltalk，因此，被誉为“Smalltalk之父”。
Alan Kay不但是面向对象编程语言Smalltalk的发明人之一，也是面向对象编程思想的创始人之一。他是笔记本电脑最早的构想者，同时也是现代Windows GUI的架构师。Alan Key可谓是计算机领域的大师。
相对于传统的软件工程思想而言，面向对象的思想更符合人类的思维逻辑，它淡化了计算机的观点，以现实世界中的模型作为构造软件系统的依据。面向对象的基本概念包括对象、类、封装、继承和多态，下面一一介绍。
1. 对象
对象可以是客观世界中存在的事物，也可以是概念化的实体，它由一组属性和操作组成。属性是用来描述对象静态特征的数据项，是对客观世界实体所具有性质的抽象。操作是用来描述对象动态特征。比如，把人当成一个对象，那么他的属性就有身高、体重、姓名和年龄等静态特征，他的操作就包括工作、学习、吃饭和运动等；把汽车当成一个对象，那么它的属性就有品牌、颜色、价格和寿命等，它的操作就包括加速、减速和刹车等。
理解对象的概念时，需要注意以下几点。
对象的数据是封装起来的，对数据的处理需要通过特定的操作。
对象之间通过传递消息进行通信，不同的对象独立地处理自身的数据。
对象具有主动性。要处理对象的内部数据时，外界需要通过接口向对象发送消息，请求它执行特定的操作。
2. 类
类是对对象的抽象，是对具有相同属性和相同操作的一组相似对象的定义。通常情况下，很多对象都有相似的特征。比如，对于两个教师，他们虽然可能身高、体重、性别、年龄和籍贯等特征不同，但是职业却是相同的；对于两把椅子，它们可能颜色、形状、价格和位置等特征不同，但是作用却是相同的。在这种情况下，我们就可以忽略事物的非本质特征，只注意那些与当前目标相关的本质特征，从中找出事物的共性，把本质特征相同的事物划分为一类，即将多个对象抽象为类。
对于同类对象，它们具有相同的属性和操作，但是每个对象的属性值可能不同，执行操作的结果也可能不同。比如，在教务管理系统中，可以定义“学生”类，并定义编号、姓名和院系等属性，及登录该系统进行操作。每位学生都有自己特定的编号、姓名和院系等属性值，并且执行登录操作后，都会进入个性化的主页。
谈到类的概念，就必须知道什么是类的实例。实例是由某个特定的类描述的一个具体的对象。比如，对于"教师"类，某位教师"王一"就是类的一个实例；对于"学生"类，某位学生"李二"就是该类的一个实例。
3. 封装
封装是指把对象的属性和操作结合在一起，组成一个独立的单元。封装强调两个概念，即独立和封闭。
独立是指对象是一个不可分割的整体，它集成了事物全部的属性和操作，并且它的存在不依赖于外部事物。
封闭是指与外部的事物通信时，对象要尽量地隐藏其内部的实现细节，它的内部信息对外界来说是隐蔽的，外界不能直接访问对象的内部信息，而只能通过有限的接口与对象发生联系。
可以说，类是数据封装的工具，而对象是封装的实现。类的成员又分为公有成员、私有成员和保护成员，它们分别有不同的访问控制机制。封装是软件模块化思想的重要体现。
4. 继承
继承表示类之间的层次关系，它使得某类对象可以自动拥有另外一个或多个对象的全部属性和操作。比如，某系统已经定义了一个学生类，现在还需要定义一个研究生类。由于研究生也属于学生的一种，它具有学生所有的一切属性和操作，这时就可以采用继承的方法，使研究生类直接获得学生类的一切属性和操作。在这个系统中，研究生类就叫做子类或派生类，学生类就叫做父类或基类。子类可以把父类定义的内容自动作为自己的部分内容，同时再加入新的内容。
继承可以分为单重继承和多重继承。
单重继承是指一个子类只有一个父类。
多重继承是指一个子类可以同时继承多个父类。
单重继承构成的类之间的关系是树状结构，多重继承构成的类之间的关系是网状结构。继承简化了定义一个新类的过程，有利于人们对事物的认识和描述，达到了软件复用的目的。
5. 多态
多态是一种使父类中定义的属性或操作被子类继承后，可以有不同的实现的机制。换句话说，多态允许属于不同类的对象对同一消息做出不同的响应。当一个对象接收到进行某项操作的消息时，多态机制将根据对象所属的类，动态地选用该类中定义的操作。比如，先定义一个父类"几何图形"，它具有"计算面积"的操作，然后再定义一些子类，如"三角形"、"长方形"和"圆形"，它们可继承父类"几何图形"的各种属性和操作，并且在各自的定义中要重新描述"计算面积"的操作。这样，当有计算几何图形面积的消息发出时，对象会根据类的类型做出不同的响应，采用不同的面积计算公式。
多态这种机制极大地减少了软件设计中的冗余信息，提高了软件的可复用性和可扩展性。
3.1.2.3.3.2. 面向对象方法的特征与优势
方法、工具和过程是软件工程方法学的三个重要因素。
方法是指为了完成软件开发的各项任务所采用的技术方法。
工具是为方法的实行提供的自动或半自动的支持。
过程是指为了获得高质量的软件产品所需要完成的一系列任务的框架。
在软件工程领域，“方法学”是被广泛使用的一个词汇。在20世纪70年代，“方法学”一词用于表示“开发软件产品的方式”，而该词实际上是指“方法的科学”。“方法学”应用于整个软件工程的过程。
流行的软件工程方法
目前比较流行的软件工程方法包括面向过程的软件工程方法、面向数据的软件工程方法、面向对象