目录
第1部分需求概述 (1)
1.1需求分析概述 (1)
1.1.1需求定义 (1)
1.1.2需求分析概述 (1)
1.2需求分类 (2)
1.2.1软件运行期质量 (2)
1.2.2软件开发期质量 (3)
1.2.3约束 (3)
1.2.4不同类型需求对设计的影响 (3)
1.3需求的层次性 (4)
1.4需求的易变更性 (4)
1.5需求捕捉的工具 (4)
1.6需求分析内容 (5)
1.6.1确定业务目标 (5)
1.6.2确定业务领域范围及业务流程 (5)
1.6.3建立用例模型 (5)
1.6.4建立用例规约 (6)
1.6.5确定系统非功能需求 (6)
第二部分需求提取与需求建模 (7)
2.1需求建模基本概念 (7)
2.1.1参与者 (7)
2.1.2用例 (7)
2.1.3场景 (8)
2.1.4用例规格说明 (9)
2.2用例建模 (14)
2.2.1识别系统主要参与者 (14)
2.2.2识别系统的业务和业务流程 (14)
2.2.3业务流程描述工具—活动图 (15)
2.2.4建立基本用例模型 (16)
2.2.5建立用例之间的关系 (17)
2.3应用实例—某汽车制造厂车辆订购用例模型 (18)
2.2.1参与者分析 (18)
2.3.2车辆订购业务流程分析—业务建模 (19)
2.3.3车辆订购基本用例模型 (20)
2.3.4车辆订购用例模型优化 (21)
2.4系统顺序图 (23)
第3部分分析与领域建模 (25)
3.1分析的基本任务 (25)
3.2 领域模型的基本概念 (25)
3.2.1领域模型 (25)
3.2.2领域模型的表示 (25)
3.2.3领域概念类识别 (27)
3.2.4规格说明概念类 (29)
3.3领域模型的重要性 (30)
3.3类对象间的关系 (31)
3.3.1继承关系（Inheritance） (32)
3.3.2聚合关系 (32)
3.3.3关联关系 (33)
3.3.4关联类 (33)
3.3.5受限关联 (34)
3.3.6与时间间隔有关的属性的处理 (34)
3.4建立领域模型 (34)
3.5领域模型的优化 (35)
3.6领域概念类的属性 (35)
3.7使用包来组织领域模型 (35)
3.8领域概念类与设计类、软件类的表示差别 (36)
3.9应用实例 (36)
3.9.1候选概念类提取 (36)
3.9.2概念类间关系的建立 (37)
3.9.3产品订购领域模型 (37)
3.9.4产品订购包模型 (38)
3.10 ER模型与领域模型之间的内在联系 (38)
1数据库设计概述 (40)
1.1数据库设计的基础性 (40)
1.2 数据库设计模型 (40)
1.3 基本概念 (40)
1.4数据库设计的内容 (41)
1.5数据库设计中的误解 (41)
2数据库概念模型设计 (42)
2.1实体的识别 (43)
2.2实体间联系的识别 (43)
2.3概念模型设计应遵从的原则 (44)
2.4应该注意的问题 (44)
2.3数据库概念模型设计实例 (45)
2.3.1五征产品订货 (45)
2.3.2东风销售管理 (49)
3数据库逻辑模型设计 (54)
3.1转换原则 (54)
3.2数据库逻辑设计应用实例 (55)
3.2.1五征产品计划单数据库逻辑设计 (55)
3.2.2东风汽车订购数据库逻辑设计 (56)
3.2.3东风汽车销售数据库逻辑设计 (56)
4数据库优化设计 (57)
4.1表的合并 (57)
4.3表的纵向分解 (58)
4.4表的横向分解 (59)
4.5中间表的使用 (60)
5数据库索引 (60)
5.1理论基础--数据库表索引的组织 (60)
5.2数据库索引的建立 (60)
5.3序列号的利与弊 (61)
第1部分需求概述
1.1需求分析概述
1.1.1需求定义
软件需求是“用户到底需要软件为他/她做什么”。
IEEE对需求的定义：
1.用户所需的解决某个问题或达到某个目标所要具备的条件或能力；
2.系统或系统组件为符合合同、标准、规范或其它正式文档而必须满足的条件或必须具备的能力；
3.上述第一项或第二项中定义的条件和能力的文档表述。
RUP对需求的定义：
需求描述了系统必须满足的条件或提供的能力，它可以是直接来自客户需要，也可以来自合同、标准、规范或其它有正规约束力的文档。
根据上面的定义，需求的本质是：系统必须提供的能力和必须满足的条件。
需求的表示形式是：系统“应该做什么的规格说明”。
需求分析的目的是：揭示系统应该做什么并达成一致。
需求的最根本的挑战在于：交流并记录什么是真正需要的，并能够清楚地向用户和开发团队的成员讲解。
1.1.2需求分析概述
需求分析是软件工程学的经典术语之一，名符其实的含义是对用户需求进行分析，旨在产生一份明确、规范的需求定义。从这个意义上讲“分析是解决做什么而不是解决怎么做的问题”是无愧无挑剔的。
通常用“做什么”和“怎么做”来区分“分析”和“设计”，但人们在“做什么”和“怎么做”的问题上总会出现理解上的含糊不清。问题的根源在于人们对软件工程中“分析”这个术语的含义有不同的理解--有时把它作为“需求分析”的简称，有时是指“系统分析”，有时则作为需求分析和系统分析的总称。
但迄今为止的各种分析方法（包括结构化分析和面向对象分析）中，真正属于需求分析的内容所占的分量并不大，更多的内容是给出一种系统建模方法（包括一种表示法和相应的建模过程指导），告诉分析员如何建立一个能够满足（由需求定义所描述的）用户需求的系统模型。分析员大量的工作是对系统的应用领域进行调查和研究并抽象地表示这个系统。确切地讲，这些工作应该叫做系统分析，而不是需求分析。它既是对“做什么”问题的进一步明确，也在相当程度上涉及到“怎么做”的问题。
在一般的需求论述中，需求分析包括需求调研和需求分析。需求调研是需求获取（或捕捉）的过程，所以把需求调研称为“需求获取”或“需求捕捉”，需求分析的目的和结果是对需求进行准确定义。所谓“准确定义”是弄清用户的真正需求，包括企业决策层的期望（开发目标）和直接使用系统的用户的需求（决策层人员可能不直接使用系统，但对系统的期望更大、更高，系统更应该努力去实现决策层的意图），把这些需求用文字和图表的形式描述出来，并且其描述没有二义性。但一般的自然语言很难做到无二义性描述，没有理论指导也可能使需求描述带有任意性，用特定的分析方法和对应的建模工具来“准确定义”需求以减少二义性，是普遍采用的方法。用这些分析方法和工具定义需求的过程称为“建模”，用结构化分析方法建立的需求模型称为系统的逻辑模型（功能模型），用面向对象分析方法建立的模型称为领域（对象）模型。这些模型往往不是用于与用户交流，主要是用于系统开发人员之间的交流。在建立模型过程中和所建立的模型已经“在相当程度上涉及到‘怎么做’的问题”，建模元素的选择和粒度的把握都与“怎么做”有关，只是在一个非常高的抽象层上考虑“怎么做”的问题，或者说是在意识上参杂了今后“怎么做”的因素。建立得好的需求分析模型与设计模型有很好的映射关系，也是在很大程度上考虑了今后“怎么做”的问题。
在传统的软件工程中，需求分析作为软件生存周期的一个阶段，尽管有需求获取和分析的两个任务，这两个任务没有严格地划分时间段，在需求获取过程中要进行分析，在分析过程中要不断地进行调研和完善。那时，没有严格地区分需求获取的工具是什么，需求分析的工具是什么，都是采用数据流图和数据字典。这两个任务总是交叉重复地进行，直到所建立的系统需求模型（数据流程图—系统逻辑模型）达到用户要求为止，需求提取的工具和分析的工具都是相同的工具。而且也明确地指出需求分析报告主要用于用户交流，作为用户和开发者之间的契约，是需求验收的依据。
在统一过程和UML 提出后，特别是软件迭代开发方法提出后，把需求和分析分成了两个不同的阶段，有时也叫需求获取（或需求捕获）和需求分析，每个阶段有完全不同的目标和任务，包括建模工具和建立的模型都完全不同。需求捕捉阶段主要采用用例模型捕捉功能需求，需求分析阶段主要采用对象模型，建立领域对象间的协作关系。但是，虽然把需求捕捉和需求分析划分为两个阶段，但它们却是相互伴随、交叉进行的，很难有区分的界限。需求获取所建立的模型主要用于与用户交流，需求分析模型是开发组织自己的文档，根本无法用于与用户交流，也不用于与用户交流。
随着软件工程研究的发展，软件组件技术的广泛使用，软件的敏捷构造越来越受到关注。软件敏捷构造的核心是保持软件组件与领域业务的一致性，即组件与业务对齐。如果做到了组件与业务对齐，企业业务的重组只需要对软件组件间的关系重定义，这正是软件工程要达到的理想目标。要做到这一点，对软件需求提出了很高的要求—需要从组织或领域体系结构要识别和捕捉领域需求。
1.2需求分类
需求可分为两类：
（1）功能性需求----系统应该提供什么功能。
（2）非功能需求----系统的特定特性或约束。
系统的特定特性主要指系统的质量属性。系统质量属性可分为软件运行期质量属性和软件开发期质量属性。
1.2.1软件运行期质量
软件运行期质量指用户在使用软件过程中对软件质量的要求，包括易用性（人性化因素、帮助等）、性能（响应时间、吞吐量、准确性、有效性、资源利用率）、安全性、可伸缩性、持续可用性、互操作性、可靠性和鲁棒性。通常把软件运行期质量称为软件外部质量，即用户能够直接感受到的质量。
易用性：指软件系统容易使用的程度。
性能：指软件系统及时提供相应服务的能力。性能包括响应时间（也称速度）、吞吐量（单位时间处理的交易数）、持续高速性（保持持续高速处理的能力--在网络系统中，这点是很难的）。一个系统可能保证典型操作的快速响应，但不一定能保证持续高速。
性能和效率是同一问题的“表”、“理”的两个方面，性能为“表”，效率为“里”。效率指软件系统对CPU 处理器和存储器这两大资源的处理效率。
安全性：指软件系统同时兼顾向合法用户提供服务，以及防止非授权使用的能力。 持续可用性：指软件长时间无故障运行的能力。如有的系统要求提供7*24小时服务就是持续可用性的要求。 软件需求 功能需求 非功能需求 质量属性 约束 运行期质量属性 开发期质量属性
可伸缩性：指当用户数量和数据量增加时，软件系统维持高服务质量的能力。
互操作性：指本软件系统与其它软件系统交换数据和相互调用服务的难易程度。
可靠性：软件系统在一定时间内无故障运行的能力。
鲁棒性：也称健壮性、容错性。指软件系统在用户进行了非法操作、相连的软硬件系统发生了故障、以及其他非正常情况的时候，系统仍能正常运行的能力。
有时也把持续可用性、鲁棒性也归类为可靠性。这时的可靠性就不是特指某种能力，而是一般意义下的可靠性。
在软件开发过程中，需要对上述特性中特别指出的特性进行特殊设计，特别是要通过架构设计来保证，即成为架构设计关注的重点。
1.2.2软件开发期质量
软件开发期质量：为保证软件的可维护性而在软件开发过程中应该关注的软件质量属性，包括软件的可扩展性、可重用性、可移植性、易理解性、易测试性和可维护性。软件开发期质量属性称为“软件内部质量属性”，即不深入到软件代码内部是无法觉察到的软件质量属性。这部分软件质量属性往往不会被用户通过需求的形式提出，而是软件开发团队应该自觉地保证，所以有的学者将其称为隐含质量属性。
可扩展性：为适应新需求或需求变化为软件增加功能的能力。有时称为灵活性。
可重用性：重用软件系统或其一部分的能力的难易程度。
可测试性：对软件测试以证明满足需求规约的难易程度。在实际工作中主要指进行单元测试，插桩测试的难易程度。
可维护性：在修改Bug、增加功能、提高质量属性等而定位修改点并适时修改的难易程度。
可移植性：将软件系统从一个运行环境转移到另一个运行环境的难易程度。
易理解性：设计被开发人员理解的难易程度。
任何一个开发期质量属性的满足都可能增加软件开发成本。
1.2.3约束
系统的约束是需求获取的重要内容。约束不是行为，是设计或项目的限制条件。这些限制条件也属于需求，但通常称为约束来强调其限制性。这些约束是在系统开发前已经存在的一些事实或因素，新系统的开发无法回避这些事实或因素。约束主要包括：系统开发的资源约束：如网络环境、操作系统、数据库管理系统、开发工具、硬件等。新系统的开发必须以这些现有资源为基础，软件架构（特别是系统的运行架构和物理架构）必须考虑这些资源的有效利用和限制（实现技术的限制）。
接口约束：如与本系统关联的系统是哪些，其接口约束是什么。新系统可能接受其它系统提供的数据作为输入，其输出数据作为其它系统的输入。
操作约束：如系统操作环境中的管理要求。如身份认证必须通过第三方认证机构的认证，以网络为基础的业务处理，在网络不通的情况下如何处理业务等。
政策约束：行业标准，企业标准，法律法规、政府规章等。
在现行的软件开发中，软件需方单位的信息化往往不是从零开始，而是有相当的基础，他们对新系统的开发具有极大的约束。如开发的系统是某个大系统的子系统，大系统已经开发了一部分，该子系统必须满足于已开发部分的相互约束关系，必须为后续子系统奠定某些基础。新开发的系统可以直接从某个或某些现有系统中获得原始数据等。这些都是新系统开发最重要的约束。
1.2.4不同类型需求对设计的影响
功能需求影响软件架构，而软件架构必须适应功能需求的变化。但功能需求并不决定软件架构。
质量需求主要影响系统的架构设计，在功能需求确定的情况下，系统架构设计主要针对非功能需求。在软件设计中，软件架构设计对功能性需求的主要考虑是高适应性。
约束性需求将直接影响系统的架构设计；此外，有的约束性需求将转化为功能需求，如“银行系统必须执行统一的利率”是对开发银行系统的一条约束，该约束使待开发的系统必须提供调整利率的使用功能；约束还可能转化为质量束性需求，如系统预期用户的计算机应用水平普遍不高，因此要求待开发的系统有较高的易用性。
实践证明，忽略质量属性和约束性要求，必然导致系统失败。
结论：软件架构要主动适应功能需求的变化，要从根本上支持软件质量属性要求，必须遵守约束的限制。
1.3需求的层次性
组织的不同层次人员对需求有不同的要求。由不同层次人员的需求构成需求的三个层次：
业务需求：组织要达到的目标—业务目标
用户需求：用户使用系统来做什么
行为需求：开发人员需要实现什么
对高层管理人员而言，希望软件系统能帮助他们达到业务目标。
对系统实际使用人员而言，希望系统提供的能力能辅助他们更好地完成日常业务工作。
对开发人员来说，为了满足用户诸多需求、或满足不同用户需求、或满足不同层次用户需求，而觉察到的需求（如果不补充这些需求，要满足用户觉察到的需求就显得比较困难）。
高层管理人员的需求与系统实际使用人员的需求可以起到相互验证和印证的作用。通过实际使用者的需求来印证达到高层管理人员的业务目标要求，从中可以发掘出一些需求。用管理者的业务目标要求来验证实际使用者需求的范围和合理性（业务流程）。
需求层次的关注在于在需求之间建立起“可跟踪性”，避免因遗漏需求而造成软件“达不到要求”，也避免开发人员一厢情愿地为用户“制造”没有实际意义的无用功能。
从需求的层次性看，需求并不完全是“用户的要求”，除了直接使用系统的“用户”的要求外，还包括并不直接使用系统的“高层管理人员”的要求，和开发系统的开发人员的要求。在系统开发过程中，他们的要求同样要得到满足。如果不关注“高层管理人员”的要求，系统开发就没有明确的目标，系统的功能将是零散而脆弱的，极易受到变更的冲击。不满足开发人员的要求，软件的开发、维护和移植变得非常困难。
开发人员、开发管理人员和维护人员非常关心开发期质量属性，但最终用户不会提出、一般也提不出这类质量要求。通常称这类质量属性为隐含质量需求。
运行期质量属性是软件系统在运行期间，最终用户可以直接感受到的一类质量属性，这些质量属性直接影响用户对软件产品的满意度。
可以认为，运行期质量需求来自使用系统的用户，开发期质量需求更多来自系统维护人员，即开发的系统更便于维护。
1.4需求的易变更性
需求的变更是最让人头痛的事。任何需求变更意味着时间和金钱的消耗。同时需求变更引起对系统的修改将降低开发期质量属性的质量，并引入更多bug，从而降低运行期质量属性的质量。
软件架构设计的重要目标是：使软件架构能支持业务功能在一定范围内“随需应变”。
不同需求的易变更性不同：
●功能需求最容易变化。在架构设计中，应划分少量长期稳定的功能，同时也应区分功能点本身趋于稳定，只是功能行为常常变化的功能。
●质量属性需求最为稳定。
●约束性需求的稳定性则稍差。技术趋势发生变化、法律法规重新界定和用户组织调整改组等都可能引起约束性需求变更。
1.5需求捕捉的工具
（1）传统工具----业务流程图和数据流程图
对于复杂的系统，如管理信息系统，先通过业务流程图对业务过程进行描述，再将其转换为数据流程图。数据流图是系统业务功能及其数据流动的描述，是系统的逻辑模型。
（2）UML提供的工具----活动图和用例模型
活动图可以有效地描述业务流程。
用例模型包括用例图和用例规格说明。用例捕捉功能需求，其非功能性记录在用例规格说明中。
后面只考虑UML描述工具。
1.6需求提取内容
1.6.1确定业务目标
一个项目要被开发，要拨款立项，一定有它的业务目标。对于一个系统开发，业务目标占有非常重要的位置，它明确规定了建立该软件系统的最终目的。
业务目标是组织或客户方的高层对未来系统的期望。业务目标的确定需要从企业信息化的全局来考虑和规划，使其开发的系统成为企业信息化系统中相对独立的、支持全局应用的、不可替代的重要组成部分。避免开发的系统解决的问题的层次太低，随着对信息化的要求的提高而很快过时。
项目业务目标通常由需方高层领导参与确定。
要避免业务目标太抽象、太空洞，如“实现XX信息化”。
一个项目管理系统的业务目标定义为：
帮助项目经理更好地控制项目
帮助项目经理更有效地分配资源
帮助项目成员之间更流畅地协作
还可以通过进一步细化业务目标，对每个业务目标列出一组高度概括的功能性需求。这种高度概括的功能性需求通常称为“特性”，表明“为了达到所期望的业务目标，未来系统应该在大方向上具有哪些方面的特性，每个特性再有一组功能来支撑。”如业务目标“帮助项目经理更好地控制项目”的特性有：
任务管理
跟踪进度
查看报表
任务分配和重分配
对应每个特性的功能可以用“用例”来描述，即一个特性对应一组用例。
1.6.2确定业务领域范围及业务流程
业务目标的实现需要通过具体的业务领域（有时也称职能域）以及具体的业务及流程来体现，使业务目标落实到实处。这将引起企业组织机构的调整和业务流程重组，以满足业务目标的要求。
1.6.3建立用例模型
所谓用户需求，就是用户希望软件系统能为他做什么。用例图技术是捕捉用户需求最合适的技术。用例名是用户需求最直观、最简便的反映。业务流程分析将捕捉到大部分用例，但不是全部用例，还需要补充一些与管理人员相关、但与具体业务活动不一定直接相关的用例和与信息查询相关的用例。
1.6.4建立用例规约
用例从一个较高层次描述了用户功能需求，解决了软件系统要“做什么”的问题，但还需要知道用户“希望如何做”的行为需求，否则还是不知道如何开发系统。这里的“如何做”是从用户角度看他们“希望如何做”，而不是软件系统是如何做，所以还是属于需求捕捉的内容。用户“希望如何做”是软件系统“如何做”的依据。因此，用例规约中对系统行为的描述是以用户为中心展开的，便于与用户交流。
在用例规约中，将详细定义用户对用例运行期间的质量要求和约束。
不一定所有用例都要建立用例规约。有的用例使用“用例简述”就足够了。如果一个用例基本事件流对需求分析人员来说不是很清楚，而且可能涉及到非功能要求，就需要用“用例规约”来详细描述。
在需求分析阶段可以通过用例界面的“预设计”可以更好地描述用例。真正设计是从实现角度来考虑问题，“预设计”是从与用户交流角度来考虑问题。
用例实现：用例实现不是真正编码实现用例对应的功能，而是考虑为了实现用例定义的功能，需要哪些类，以及这些类的对象之间如何交互来完成最终的功能。用例实现是从功能需求向设计方案过渡的纽带，通过分析一组关键用例的用例实现，可以获得未来系统的理想化的职责模型。这个职责模型是规划架构机制、满足高质量属性要求的基础。
用例规约也称用例规格说明。
1.6.5确定系统非功能需求
通过对用例规约的分析和总结，归纳出系统的非功能需求，特别是用户对系统运行期的质量需求和约束。用例规约是系统运行期质量需求和约束的主要来源。一般来说，开发期质量属性需求主要来自系统开发人员和维护人员。
第二部分需求提取与需求建模
2.1需求建模基本概念
需求提取的建模包括业务建模和用例建模。
业务建模是确定项目对应的业务领域所包含的业务和业务流程，并用所选择的业务流程描述工具进行描述。
用例建模是以用例为基本单位来描述用户的功能需求。
与用例模型相关的概念包括：参与者，用例，场景
2.1.1参与者
参与者：直接与系统交互的外部事物所扮演的角色。
该定义强调了3点：
①参与者对系统而言是外部的；
②参与者直接与系统交互，即参与者要直接使用系统来支持他的业务工作。
③强调参与者所扮演的角色，而不是特定的人或事物。一个特定的人可能扮演几种角色，可以作为系统的多个参与者。
时间可以作为参与者，通常用时间发生器来表示。有些系统的功能是通过系统设定的时间来驱动的。
这里的参与者主要指系统业务功能的使用者。系统管理员不是这种意义的参与者。因为他不是使用系统功能完成与单位业务有关的工作。他使用系统的辅助功能实现对特定的人及其角色的管理，使参与者在自己角色范围内使用系统。
每个参与者使用一个具有业务意义的名称命名。
为了把系统的用户都考虑到，有时使用“主要参与者”和“次要参与者”的提法，主要参与者使用系统实现自己的业务目标。次要参与者为系统提供服务。系统管理员就是系统的次要参与者，其目标就是管理主要参与者，使他们按照事先的约定使用系统，保证系统有效运行。
需求获取的首要任务就是识别主要参与者。
主要参与者驱动了用例。
用例总是有参与者开始的。
用例从参与者的角度来编写的。
识别参与者是需求提取的首要任务，谁是系统的客户，他们需要系统做什么，他们希望在什么时候、什么地点做什么，这些都是系统设计要考虑的重要因素。
2.1.2用例
用例就是需求。从根本上说，用例就是功能需求。用例是一种被广泛使用的用于发现和记录需求的机制。被认为是一种最好地理解需求和描述需求的技巧。在统一过程中，用例被推荐作为发现和定义需求的主要方法。
用例为项目相关人员提供了一种简单而易懂的机制来了解目标和系统需求。
用例图描述的是软件系统为用户或外部系统提供的（系统级）服务，清晰地界定了系统的功能范围，有利于从宏观上反映系统功能的大局。
1、用例的定义
用例：参与者想要系统做的事情。具体表现为用户如何使用系统来达到其目标的一组情节。
例如在超市，“处理销售”的用例描述为：一个顾客携带欲采购的商品到达收费口。收
银员使用系统输入商品信息，系统给出商品的清单和累加值。顾客交款。收银员输入支付信息，系统对付款信息进行计算，更新库存信息，并给出余额信息；系统打印购物清单。顾客得到收据，然后携带商品离开。
只有对用例表现出的情节进行真实、完整、准确地描述，才能捕捉到对系统需求有价值的东西。
2、用例的粒度
参与者想要系统做的事情有大有小，有抽象的事情，有具体的事情。参与者想要系统做的什么样的事情那些可以作为一个用例，哪些事情又不能算一个用例。这实际上涉及到用例的粒度问题。
指导原则1：在进行需求获取时，应专注于“基本业务过程”（EBP）级别的用例。
基本业务过程：由一个人在某个时间某个地点执行的一项任务，这个任务是对某一个业务事件的反应，而且可以增加可度量的业务价值，并且能够保持数据状态的一致。
用例不是类似“删除一个记录”或“打印一个清单”这样简单的小步骤。用例也不是一个需要好几天和很多对话才能完成的工作，例如“谈判一个供货合同”，它是能够在一个对话、几分钟或一个小时的时间就可以完成的任务。依照UP的定义，用例强调了能够增加可见的或可度量的业务价值，而且能够使系统和数据处于稳定和一致的状态中（表示该做的一件事做完了）。
用例没有层次结构的概念，即用例就是系统参与者要系统帮助干的一件不可细分的事情，不存在把一个用例分解成粒度更小的用例。后面讲到用例优化时，可能存在从用例中抽象出更小的用例，主要是从实现角度考虑，对用例进行某种优化措施，为系统设计提供更多的信息。
EBP级别的用例就是用户对系统的业务功能需求。在进行需求获取时，我们应主要关注EBP级别的主要用例，通常称他们为基本用例。用例建模主要考虑EBP级别的用例。比基本用例粒度小的用例可能完不成“可度量的业务价值”的一件事情，比基本用例粒度大的用例可能需要多个参与者去完成或多个时间段去完成。
为了获得EBP级别的用例，必须非常熟悉用户的业务流程，用户任何一项有意义的业务活动，如果需要系统的支持，就构成了一个EBP级别的用例。
用例的命名必须具有明显的业务领域特征，而不是计算机化的语言。
3、用例与目标
参与者都有自己的目标，并使用系统来帮助自己实现目标。一个EBP级别上的用例通常被称为一个用户目标级别上的用例，以强调用例应该帮助系统的用户实现自己的目标。（这里强调“用户目标级别”，不是企业目标、组织目标、系统目标）。
“防盗”是企业级目标，不是用户级目标，因此不是一个EBP。
“向系统证明身份并被验证”也不是一个EBP，因为它没有增加可见的或可以度量的业务价值。“登录”是一个次要目标，是为其它有用的事情服务的。如“我今天登录了20次”不会留下任何有价值的东西。
“用户管理”是系统目标，不是用户级目标。
4、可观察的返回值
每个用例的实例产生了对特定参与者而言可观察的返回值。
可观察的返回值实际上是告诉参与者是否实现了其业务价值。如果一个用例不会告诉参与者任何东西，对参与者来说，它没有任何价值，这肯定不是参与者的目标要求。
2.1.3场景
场景：参与者与系统之间的一系列特定的活动和交互，通常称为“用例的实例”。场景是使用系统的一个特定情节或用例的一条执行路径。
一个用例就是一个描述参与者使用系统来达到目标的一组相关的成功场景和失败场景
的集合。
例如，客户在超市选择购买的商品后到收银台验货和付款中，“收银员扫描仪录入商品数据→顾客交款→收银员退余款→打印购物清单”是一个场景；同样，“收银员扫描仪录入商品数据→顾客交卡→收银员刷卡→打印购物清单”也是一个场景；“收银员扫描仪录入商品数据→顾客交卡→收银员刷卡→（卡中钱不足时）顾客交款→收银员退余款→打印购物清单”还是一个场景。
场景可分为主要场景和次要场景。一个用例只有一个主要场景，但可以包含多个次要场景。每个场景表示参与者达到其目标的一个情节。在主要场景中，如果与某一步所希望的事件不同，就会引出一个次要场景。
2.1.4用例规格说明
用例不是图表，而是文本文档。用例图表示对用例的抽象描述，用例规范化文档（用例规格说明）是对用例的详细描述，在UP中称为详述用例。用例图和详述用例就像数据流图和数据字典一样，被同时使用，共同构成用例模型。用例规范化文档是领域模型、设计模型、部署模型、设计模式选择的依据。
用例描述主要包括主要成功场景和扩展。
主要成功场景：描述了能够满足项目相关人员兴趣的典型的成功路径，通常称为基本流程。
扩展：描述与基本流程不一致的方面，如达到目标的不同选项。扩展也称为次要场景。
主要场景一定对应一个基本的成功场景，主要场景中没有出错处理的内容。
次要场景的基本目的是对应一个不同于主要场景某个点的不同的选项，其中可能包含出错处理。
用例规格说明的格式有多种多样，表示的形式有单列式和双列式。
单列式将参与者与系统的交互按步骤顺序列出。
双列式将参与者的行为和系统的职责分开各列一列。
表1-1的格式是常见的一种用例规格说明的格式。
表1-1 用例规格说明格式表
用例编号：用例名称
主要参与者
项目相关人员及其兴趣
前置条件
后置条件（成功后的保证）
主要成功场景（或基本流程）
扩展（或替代流程）
特殊需求
技术与数据的变化列表
发生频率
待解决的问题
下面“处理销售”用例规格说明就是这种风格。
用例1：处理销售
主要参与者：收银员
项目相关人员及其兴趣：
●收银员：希望能够准确、快速地输入，而且没有支付错误，因为收银员如果少收了钱就要从他的薪金中扣除相应的金额。
●售货员：希望自动更新销售提成。
●顾客：希望购买过程能够省力，并得到快速的服务。希望得到购买证明，以便退货。
●公司：希望准确地记录交易，并满足顾客的要求。希望保证支付授权服务的信息被记录。希望有一定的容错性，即使某些服务暂时不可用（如远程信用卡验证）也能允许收款。希望能够自动启动，快速地更新账目和库存信息。
●政府税务机关：希望能从每笔交易中提取税金。可能存在多个税务机关，如国家级、市级和县级。
●支付授权服务：希望按照正常的格式和协议收到数字授权的请求。希望准确计算给商店的应付款。
前置条件：收银员必须已经被识别和授权。
后置条件：存储销售信息；准确计算税金；更新账目和库存信息；记录提成；生成收据；记录支付授权的许可。
主要成功场景：
1.顾客携带购买的商品或服务到达POS机收费口。
2.收银员开始一次新的销售。
3.收银员输入商品标识。
4.系统记录单件商品，并显示该商品的描述、价格和累加值。
收银员重复3～4步，直到处理完所有商品。
5.系统显示总值并计算税金。
6.收银员请顾客付款。
7.顾客支付，系统处理支付。
8.系统记录完整的销售信息，并将销售和支付信息发送到外部的记账系统（进行记帐和提成）和库存系统（更新库存）。
9.系统打印收据。
10.顾客带着商品和收据离开。
扩展：
*a.任何时刻，发生以下状况，系统将失败：
为了支持恢复操作和正确地记帐，要保证所有交易的敏感状态和事件都能够从场景中的任何一步中恢复。
1.收银员重启系统、登录，请求恢复上次状态。
2.系统重建之前的状态。
2a.系统恢复过程中检测到异常：
1.系统向收银员指示错误，记录此错误，并进入一个清空状态。
2.收银员开始一次新的销售。
3a.非法标识
1.系统指示错误并拒绝输入。
3b.有多个具有相同类别的商品（其数量不是一个，而是多个），不需要跟踪每个商品的唯一身份：
1.收银员可以输入商品类别的标识和数量。
3-6a.顾客要求收银员从已输入的商品中去掉一个商品：
1.收银员输入商品标识并将其删除。
2.系统显示更新后的累加值。
3-6b.顾客要求收银员取消交易：
1.收银员在系统中取消交易。
3-6c收银员暂停销售：
1.系统记录销售信息。收银员能够在任何一台POS终端上恢复操作。
4a.系统生成的商品价格不是顾客想要的价格（顾客抱怨太贵，要求减价）：
1.收银员重写价格。
2.系统显示新的价格。
5a.系统检测到与外部的税金计算系统的通信故障：
1.系统要POS机节点上重启此业务，并继续。
1a.系统检测到服务无法重启。
1.系统指示错误发生。
2.收银员可以手工计算税金并输入，也可以取消此销售。
5b.顾客声称他们符合打折条件（例如，雇员或优先顾客）：
1.收银员发出打折请求。
2.收银员输入顾客的个人身份信息。
3.系统按照打折条款给出折扣价值。
5c.顾客要求使用信用卡结帐：
1.收银员发出信用卡结帐请求。
2. .收银员输入顾客的个人身份信息。
3.系统按从信用卡上扣除货款。
6a.顾客想用现金支付，但随身现金不足：
1a.顾客使用替代的支付手段。
1b.顾客告诉收银员：他要取消此销售，收银员在系统上取消此销售。
7a.现金支付：
1.收银员输入收取的现金数额。
2.系统给出应找的余额，并弹出现金抽屉。
3.收银员放入收取的现金，并拿出应找的余额给顾客。
4.系统记录现金支付。
7b.信用卡支付：
1.顾客输入信用卡帐号。
2.系统向外部的信用卡授权服务系统发送支付授权请求，并请求批准此支付。
2a.系统检测到与外部系统的通信故障：
1.系统向收银员指示发生了错误。
2.收银员请求顾客更换支付方式。
3.系统收到批准付款的指示，并向收银员指示付款被批准。
3a.系统收到拒绝付款的指示：
1.系统向收银员指示付款被拒绝。
2.收银员请求顾客更换支付方式。
4.系统记录信用卡支付，其中包括支付的批准。
5.系统给出信用卡支付的签名输入机制。
6.收银员要求顾客做出一个信用卡支付签名。顾客签名。
7c.支票支付……
7d.记帐支付
7e.顾客出示优惠卷：
1.在付款之前，收银员记录每张优惠卷，并从系统中扣除相应的价值。系
统记录已使用的优惠卷以备记帐之用。
1a.输入的优惠卷并不适用任意购买的商品。
1.系统向收银员指示错误。
9a.有的商品有回扣：
1.系统给出回扣表格，并为每个回扣商品提供回扣收据。
9b.顾客要求礼物收据（不显示价格）：
1.收银员请求礼物收据，系统给出礼物收据。
特殊要求：
使用大型平面显示器上的触摸屏界面。文本信息要能够在1米之外看清。
90%的信用卡授权机构的响应应在30秒内收到。
在访问远程服务（如库存系统）失败的情况下保证可靠的恢复操作。
支持多种语言显示。
在步骤3和步骤7中可以插入新的业务规则。
技术与数据的变化列表：
3a.商品标识可以用跳马扫描或键盘输入。
3b.商品标识可以是UPC、EAN、JAN或SKU等不同的编码方式。
7a.信用卡帐号信息可以使用读卡器或键盘输入。
7b.记录在纸面收据上的信用卡支付签名。但我们预测，两年内会有许多顾客希望使用数字签名。
发生频率：可能持续发生。
待解决的问题：
什么是税法的变化？
研究远程服务的恢复问题。
不同的业务需要什么样的定制？
收银员是否必须退出系统后带走他们的现金抽屉？
顾客是否可以直接用读卡机，而不必收银员代劳？
内容解释：
1、用例应该包含什么？
答案：用例应该包含满足所有的项目相关人员兴趣的内容。以相关人员的兴趣作为视点来观察，会为我们提供一种彻底的、系统化的程序，用来发现和记录所有必须的行为。
2、前置条件：规定了用例中的一个场景开始之前必须为“真”的条件。前置条件在用例中不会被检验，如收银员已经成功“登录”或“收银员已经被识别和授权”。
3、后置条件：用例成功结束后必须为“真”的条件。这一“保证”应该满足所有项目相关人员的需要。
4、主要成功场景：也称为“基本流程”，描述了满足相关人员兴趣的典型的成功路径，通常不包括任何条件和分支。
5、扩展：比成功场景更重要，更复杂，不满足基本流程中的部分都要进行描述。
6、特殊要求：主要描述与用例相关的非功能要求。
7、技术和数据的变化列表：记录在技术上可能有变化的内容，往往描述的是“应该怎样做”，但它们对设计决策有重要影响。
2.2用例建模
用例模型是所有用例的集合，是系统功能和环境的模型
用例模型设计步骤：
●识别系统主要参与者
●识别待开发系统所涉及的业务
●业务建模
●定义满足用户级目标的用例。
用例与面向对象无关，书写用例不是在进行面向对象分析。
用例是UP的关键和核心。
用例驱动开发：功能需求主要记录在用例中。团队为了完成或实现用例而设计相互协作的对象和子系统。
2.2.1识别系统主要参与者
系统主要参与者就是系统的业务用户。在这里，我们反复强调“业务用户”，因为开发一个软件系统的目的就是为他们的业务工作服务的，这是系统的价值所在。
在识别系统主要参与者时的首要工作就是列出所有系统最终用户。有的主要参与者的大部分业务工作都可能需要系统支持，如学校的“教务管理员”，有的主要参与者可能很少使用系统。如各个“审批”人员，当别人把所有工作都作了，他只需“审核”一下就行了。在识别主要参与者的过程中，最容易把这些大量的干“审核”或“审批”的主要参与者忽略掉，因为他使用系统的时间很少，就认为他不是主要参与者。
任何人，只要他需要使用系统来行使自己的“职责”，哪怕只有一小点“职责”，他就是系统的主要参与者。
2.2.2识别系统的业务和业务流程
一个软件系统的目标和范围确定后，与之对应的业务就确定了。
主要参与者指使用系统来实现自己目标的参与者。五征产品计划单的填写由五征厂的业务员完成，如果用系统来实现产品计划单的填写（表现为订单申请），则业务员为主要参与者。产品计划单的填写不能由业务员一个人说了算，必须有经销商参与，申请什么产品，如何配置，数量是多少，只能由经销商决定，但这项业务活动是由业务员完成的，所以经销商是次要参与者，他协助五征业务员制定产品计划单，或为业务员制定产品计划单提供服务，但他不直接使用系统来完成这项工作。
在一项业务工作中，有多个业务活动，每个业务活动可能由不同的参与者完成，每个参与者都有自己的业务目标。如五征产品计划（产品订购）业务有如下业务活动：业务员填写产品计划单
经销商负责人签字认可
经销商开具汇票
营业部评审人评审并签字认可
经销商获取认可信息（表现为经销商查询订单状态）
这些业务活动按时间顺序构成了订单业务的完整业务流程（不考虑订单的执行），其中的每一个业务活动的完成都对应着一个用户目标，实现这些目标的软件功能都可以抽象为一个EBP级别的用例。
在列出业务活动时，所遵循的基本原则是：每个业务活动只有一个人在特定的地点和特定的时间完成。无论再小的事情，如果要多个人完成、或必须在多个时间完成、或可能（必须）在多个地点完成，就要分解成多个业务活动，在用自然语言叙述业务流程时也必须遵循这样的原则。
在用例建模中，最容易犯的错误是把用例模型中的用例与系统层次功能模型中功能模块
相对应，把高层模块作为基本用例，用包含关系的子用例来扩展高层模块的下层模块。这是极其错误的做法。
必须强调：EBP 级别的用例是用例建模必须坚持的基本原则。EBP 级别的用例既不一定对应层次功能结构的上层功能模块，也不一定对应下层（叶结点）的功能模块。它们是两种完全不同的功能需求分析方法。
2.2.3业务流程描述工具—活动图
业务流程描述了一个业务所包含的业务活动和业务活动之间的关联关系。业务活动之间的关联关系反映业务状态的变化及状态迁移，即业务流程描述就是业务建模。
业务建模就是以业务活动为基本元素，描述一个业务从开始到结束所经历的业务活动及业务的状态转移。
UML 没有明确给出业务建模工具。一个业务模型现在还没有直接自动化地转化为计算机可实现的模型的方法和技术。业务模型是给项目相关人员与用户交流使用的，业务建模是软件开发人员了解业务系统的基本方法，是用例提取的基本来源。
UML 的活动图被推荐作为业务建模的工具。活动图是用于描述流程化操作（工作流），并支持并发的主要工具，包括算法描述、用例实现过程描述等。
活动图的核心概念是活动，活动是完成一个任务（一个领域业务或一个系统任务）所必需执行的处理步骤，是必须要做的活动。
活动图使用符号：
（1）初始状态(活动起点)：用黑色小圆圈表示 ●
表示业务（工作流）的开始。
（2）终止状态（活动终点）：用“牛眼”表示
● 表示业务（工作流）的结束
（3）活动：用圆角矩形表示
该图符在活动图中有时也称动作或动作状态。在不同的用途中可以有不同的称
呼，在业务建模中称活动比较合适。表示在某个时候要完成的一件工作。
（4
）活动迁移：用带方向的线段表示
表示从一个活动到另一个活动的转移，或表示两个活动之间的联系。箭头表示
活动的步骤或顺序。
（5
分支与合并往往同时使用，相当于结构化程序设计中对分支的要求----具有唯一
的入口和唯一的出口。
对于分支，其菱形框中应给出条件表达式，表示按照条件的真或假选择一个分支。
（6
分叉具有一条引入迁移和两条或多条引出迁移，表示由一个活动的完成引出多个并行活动的执行。
汇合具有两条或多条引入迁移和一条引出迁移，表示多个活动并发流的同步点，多
个活动都完成时才启动后继的活动。其引入的条数与对应得分叉的引出条数一致。
并发与同步往往同时存在于一个活动中，他们反映了系统任务的一些本质特征。并发常常位于活动图中的靠前的活动中，而同步则常位于后面的活动中。
描述并发和同步是活动图的优势。
（7）泳道：指明活动的执行对象或组织。
参与者1 ……参与者n
在活动图中，用泳道将业务中不同参与者参与的活动用明显的界限分开，便于明显划分每个参与者的职责。
泳道技术假定：每个活动被明确地分配到一个泳道，即不能跨越两个或两个以上泳道。在业务建模中，规定每个业务活动只能由一个主要参与者在一个地点一个时间内就可以完成，则一个活动就对应着一个EBP级的用例。
带有泳道的活动图被认为是业务建模的最优秀的方法和工具。
活动图除了上述图形符号外，还可以加进表示活动的输入和输出的图符。如用于描述业务流程，可以加进表示文档之类的符号，表示活动结束的输出或活动的输入；在描述对象协作时，可以加入对象的符号。
2.2.4建立基本用例模型
指导原则2：在建立用例模型时，不考虑用户界面，专注于参与者的意图和系统职责。
系统职责是实现参与者的意图。
如果活动图中每个活动只限于在一个泳道中，在一个地点一个时间内可以完成，则一个活动就是一个EBP级的用例。
所谓基本用例指一个EBP级别的用例。
基本用例模型指由基本用例构成的系统功能模型。
以用例为基础的系统功能模型的图式表示称为用例图，是用例模型的抽象描述。
用例图包括参与者（角色）、系统边界、用例、参与者与用例的关联关系。
系统边界用矩形框表示。通过矩形框的边线明确划分系统内和系统外。
用例用椭圆表示，椭圆内放用例名（有的教科书上把用例放在椭圆的外边）。用例放在矩形框内，表示是系统内部元素。
参与者用“稻草人”图符表示。参与者放在矩形框外，表示参与者是与系统有关的外部元素，是系统的直接使用者。
参与者与用例之间的关联关系通过参与者与用例之间的连线表示。用例由某个参与者来驱动（启动）执行，所以每个用例必须与系统外部参与者关联，并把执行结果的值通过一定的方式反馈给用户。如果一个参与者没有与用例建立关联关系，则说明该参与者不应成为系统的参与者，至少说他不是系统的主要参与者。如果一个用例没有与参与者建立联系，说明该用例可能不是系统功能，或者说明它可能不是EBP级别的用例所表示的功能（可能是通过建立用例关系产生的用例）。
系统名放在矩形框内的顶部。
一个用例在功能上具有完整性。首先，从系统的角度而言，每个用例都必须从输入开始，直到产生结果输出给参与者，否则就不成其为一个用例。其二，用例刻画系统的功能需求，但它不是简单地记录功能需求，而是要完整地描述系统功能，包括用例执行的步骤、执行过程中可能产生的诸多变化情况、错误情况和异常情况。所以，用例图只是系统功能的抽象描述，还必须通过用例规格说明进行详细描述，才能充分反映用例所包含的内涵。
在基本用例模型中，除了参与者与用例之间的关联关系外，用例之间是相互独立的。这种独立性是用例完整性的体现。
基本用例模型中的参与者就是系统权限管理中的角色。
基本用例模型中的用例是系统权限分配的基本对象。
参与者与基本用例的关联关系就是系统中角色与资源（功能模块）之间的映射关系。
所以，基本用例模型是系统角色与权限管理设计的依据。
2.2.5建立用例之间的关系
用例可以相互关联。用关系来描述用例之间的关联不会影响系统的需求和行为，关系只是一种组织机制，用于改善用例的交流和理解，减少文本的重复说明。
在用例建模中，为了使用例更简洁，在用例模型中引入了两种关系：
包含关系（include）（也称使用关系（uses））
扩展关系（extend）
可以用包含和扩展来建立用例之间的关系。
（1）包含关系（include，有的书上用use表示）
包含关系指一个用例包含另一个用例。被包含的用例通常是包含用例的一部分，即是包含用例对应的功能需求的子功能。
在用例模型中，如果发现某些用例具有部分相似的行为。则可以把这部分相似的行为抽取出来单独作为一个“抽象用例”供它们使用，由此构成了用例之间的“包含”关系。在包含关系中，被包含用例一定是包含用例的一部分，具体体现在：如果包含用例被执行，被包含用例一定被执行，而不是有选择性地执行。
指导原则3：当两个或两个以上独立的用例中有重复的内容而要想避免这种重复时，可以应用包含关系。
（2）扩展关系
对于每一个基用例，都有一个基本的成功场景。除了基本的成功场景之外，可能还有其它成功场景。对其它成功场景，可以用一个扩展用例来描述。
扩展关系指一个用例的某个行为可能被另一个用例扩展。如顾客在超市购买商品，一般用现金支付的比较多，可能有少部分用储蓄卡支付，也有少部分用会员卡支付或代购卷。我们可以把“现金支付”作为“基本”行为，把“储蓄卡支付”、“会员卡支付”和“代购卷”作为“特殊”行为。在用例建模中，把这种“特殊”行为作为扩展用例。
被扩展的用例本身是完整的，即在用例执行过程中，可以不执行扩展用例的行为也能顺利完成用例的系统职责。扩展用例只是在遇到对应特殊情况时才可能被调用执行。
指导原则4：对插入基用例的条件或可选行为建模。
提出用例的扩展关系，最实际的动机是由于某种原因不宜修改基用例。
电子商务缴费：可以选择一种基本的缴费方式作为基用例的成功场景，还可以选用其它缴费方式。这“其它缴费方式”通过条件触发。可以用扩展用例来描述它们。如果把所有“缴费方式”的业务活动描述都放在一个基用例中，就显得过于复杂，通过用扩展用例，可以使基用例更易理解。
包含关系强调的是行为的相似性，扩展关系强调的是行为的特殊性。
根据用例在用例模型中的地位，可以把用例分为：
具体用例：指参与者直接发起和执行的用例。
抽象用例：不能被直接实例化，是一个子功能用例，是另一个用例的一部分。
基用例：包含另一个用例、或被另一个用扩展或特殊化的用例。
在用例建模过程中，首先建立具体用例模型（也称基本用例模型），该模型是系统用户级功能模型，反映了用户对系统的功能需求。然后分析基本用例模型，抽象出多个用例的相似行为，形成抽象用例，建立抽象用例与基用例的“include”关系。再分析一些行为复杂的用例，如果某个步骤有扩展选择，可以将扩展选择抽取出来构成一个扩展用例，并基用例建立“extend”关系。
使用包含技术的目的是优化用例模型，为系统设计提供更多的指导信息。
使用扩展技术的最实际的动机是减少用例描述的复杂性。
系统开发者与用户交流过程中使用基本用例模型。建立用例间的关系的目的是简化用例模型，用户对这样建立的用例模型存在理解上的困难。其中，扩展用例比抽象用例更难理解。
基本原则：“include”关系仅在简化模型时使用。“extend”关系基本不用，即使要用，也必须确保理解上的一致性。
在用例关系中，包含关系是最常见和最主要的关系。
用例建模专家建议：尽量使用包含关系，而非扩展和泛化。
在论文中，为了使建立的业务模型更加完整和完美，尽可能建立具有包含和扩展关系的用例模型，以展示论文作者的建立业务模型的驾驭能力和水平。
2.3应用实例—某汽车制造厂车辆订购用例模型
某汽车制造厂车辆订购管理业务包括：订购管理和调拨管理。把调拨作为订购的一部分，是因为当经销商向制造厂订购车辆后需要比较紧迫，另一个经销商处有相同的存车，制造厂可以直接从另一个经销商处调拨车辆作为向经销商发货。
2.2.1参与者分析
产品订购由经销商和汽车制造厂共同完成。假设经销商中由采购员全权负责车辆订购工作，制造厂由销售员全权负责车辆销售工作。为了保证采购和销售的有效性，销售商经理必须对提交的采购单进行审批后，采购单才能生效。制造厂销售经理必须对订购单进行审批后，订购单才能生效。为了保证送货的有效性，送货必须落实到具体的送车人。为了保证收货的有效性，必须将收货落实到具体的收车人。因此，该订购系统的主要参与者有：采购员：负责采购单（对制造厂而言是订单）的制定与提交。
经销商经理：对采购单进行审批，若审批“同意”则采购单正式生效。
销售员：负责订单的审核，确保订单的合理性。
销售部经理：审批订单，若审批“同意”则订单正式生效（有货则可以发货，否则转其它部门制定生产计划，组织生产（这里不作考虑））。
送车人：接受送车任务，负责送车。
收车人：负责接收车辆，包括对车辆进行质量检查等工作。对于调拨收车，只给出反馈收车信息。
4、用总需求－总供给模型说明国民收入与价格水平的决定。 （1）在以价格水平为纵坐标，国民收入为横坐标的坐标系中，总需求曲线是表明物品市场和货币市场同时达到均衡时总需求与价格水平之间关系的曲线，是一条向右下方倾斜的曲线。 （2）总供给曲线是表示总供给与价格水平之间关系的曲线，反映了在每一既定的价格水平下，所有厂商愿意并能够提供的产品与劳务的总和。 （3）总供给曲线有三种情况：在资源未得到充分利用情况下，水平状的总供给曲线称凯恩斯主义总供给曲线；资源将得到充分利用时，向右上方倾斜的总供给曲线，称短期总供给曲线，资源已得到充分利用时，垂直状的总供给曲线，称长期总供给曲线。 （4）将总需求曲线与总供给曲线结合在一起即构成总需求—总供给模型，总需求曲线AD与总供给AS相交于E，决定了均衡的国民收入水平为Y0，均衡的价格水平为P0。5、用IS-LM模型说明国民收入与利率的决定。 （1）IS-LM模型是说明物品市场与货币市场同时达到均衡时国民收入与利息率决定的模型。它与IS曲线和LM曲线构成。 （2）IS曲线是描述物品市场达到均衡，即投资与储蓄相等时，国民收入与利息率之间存在着反方向变动关系的曲线。 （3）LM曲线是描述货币市场达到均衡，即货币需求与货币供给相等时，国民收入与利息率之间存在着同方向变动关系的曲线。 （4）两条曲线放在同一个坐标系中，就可以得到说明两个市场同时均衡时，国民收入与利息率决定的IS-LM模型，IS曲线与LM曲线相交于E，E点是两种市场同时达到均衡，决定了均衡的利息率水平为i0，均衡的国民收入水平为Y0。 （5）自发总需求变动，会引起IS曲线的移动，使均衡的利息率水平和均衡的国民收入水平发生同方向变动。货币供给量的变动，会引起LM曲线的移动，使均衡的利息率发生反方向变动，均衡的国民收入水平发生同方向变动。 6、说明财政政策的内容及其运用。 （1）财政政策是政府根据既定目标通过财政收入和支出的变动以影响宏观经济活动水平的宏观经济政策。 主要内容包括：政府支出包括政府公共工程支出、政府购买以及转移支付。税收主要是个人所得税、公司所得税和其他税收。 （2）经济萧条时，总需求小于总供给，经济中存在着失业，通过扩张性的财政政策增加政府支出与减税刺激总需求，实现充分就业。 （3）政府支出与购买的增加有利于刺激商人投资，转移支付的增加可以增加个人消费，减少个人所得税使个人可支配收入增加，从而消费增加；减少公司所得税使公司收入增加，从而投资增加也刺激总需求。 （4）在经济繁荣期，总需求大于总供给，存在通货膨胀，通过紧缩性的财政政策减少政府支出与增税,抑制总需求，以实现物价稳定。 7、论述货币政策的工具及运用。
业务分析与需求分析 一、概述 1.1编写目的 此文档对《学生信息管理系统》做了全面的用户需求分析，明确索要开发的软件具有 的功能、性能，是系统分析人员及软件开发人员能清楚地了解用户的需求，并在此基础上 进一步提出概要设计说明出和完成后续设计与开发工作。编写该文档的目的是为能够更加 准确的明白该系统的需要，对所开发的软件的功能、性能、用户界面及运行环境等做出详 细的说明。 本说明书的预期读者为客户、业务或需求分析人员、测试人员、用户文档编写者、项 目管理人员等。 1.2项目背景 (1)软件系统名称：学生信息管理系统。 (2)本项目的任务提出者：XXXX (3)项目概述：随着科学技术的不断提高，计算机科学日渐成熟，其强大的功能已为人们 深刻认识，它已经进入人类社会的各个领域并发挥着越来越重要的作用。现今学校的规模不断扩大，学生数量急剧增加，有关学生的各种信息也成倍增长，人工管理信息的缺点日渐突出，面对庞大的学生信息量，学生信息管理系统成为了学生管理不可缺少的部分，它对于学校的管理者来说都至关重要。 二、业务分析 2.1业务调查 学生信息管理系统可以为学生、老师、系统管理员提供相应服务。通过正确的登陆信息 进入系统后，可以进行相关的记录、查询、修改信息。涉及学生、老师、班级、课程、分数、题库相关信息。 2.2业务流程 2.2.1流程概述 1、初次使用该系统的老师和学生需要注册，填写相关信息，由系统创建老师账户，学生
账户，记录老师和学生信息，赋予相关权限。 2、学生和老师采用正确的学号、密码登陆账户，可以进行查询与修改个人信息。 3、学生可以查询教师相关信息，系统可以记录与修改教师信息 4、学生和老师可以查询班级相关信息，系统可以记录与修改班级信息。 5、学生和老师可以查询课程相关信息，系统可以记录与修改课程信息。 6、学生和老师可以查询某课程分数相关信息，老师可以记录与修改某课程分数信息。 7、学生可以导出与查询测试问题，系统可以记录与修改测试问题。 8、系统管理员可以创建与删除学生和老师账户。 2.2.2整体的业务流程图 2.3 功能模块分析 大致可以分为学生管理、教师管理、班级管理、课程管理、分数管理、题库管理、系统管理等模块。
什么是项目需求分析？ 需求分析是指理解用户需求，就功能与客户达成一致，估计和评估项目代价，最终形成开发计划的一个复杂过程。（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和要负责整理用户需求，为之后的设计打下基础。需求分析阶段结束后，要求得到：1.SRS文档(System Requirement Specification); 2.DRM 文档；3.Acceptance Plan. 从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。 狭义上理解：需求分析指需求的分析、定义过程。 一、为什么要需求分析 需求分析就是分析用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的,而你在开发前期
忽略了的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死. 需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在开发的过程中具有举足轻重的地位.大家一定要对需求分析具有足够的重视.在一个大型系统的开发中,他的作用要远远大于程序设计. 二、需求分析的任务 简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求. 三、需求分析的过程 需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审. 问题识别：就是从系统角度来理解,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(运行是所需的内存,CPU等),消耗与开发进度需求,预先估计以后系统可能达到的目标. 分析与综合：逐步细化所有的功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型).
需求分析写编写用户业务需求分析 使得阅读者对下面分节描述的各个功能形成一个整体印象。有关文字与图表应尽量让用户便于理解.3 软件平台 【说明】操作系统的名称，起止页号] 、维护和信息控制：在完成软件功能时： 适应性、操作系统平台。 前端开发工具的名称，可用于对系统的理解，格式自定。 在这里请作者将制作的用例图和顺序图拷贝到本文档中： 时间特性：使软件遵守相关的标准、预期效益等.2 图形分析 【说明】本节主要描述相应业务的用例图和顺序图的内容 统一建模语言（UML）是一个通用的可视化建模语言。 3、单据等的样张。产生顺序图的数量根据说明需求的具体要求设定、配置：由于哪些条件的约束、在用例视图（use case view）中建立一个名称为main的主用例图（use case diagram）。其中，往往要作出某些折中。事实上不可能做到面面俱到，具体应用时还可以根据情况建立多个用例图（use case diagram）.3 与其它系统的关系 【说明】在用户现有的及预期的整个应用系统中.2。 5。这些性能/.XX”。 软件需求说明（Software Requirements Specification）的主要作用为。
本章主要介绍项目的总体业务功能，可以根据需要增加部分内容、版本号等、环境改变所做努力有关的一些软件属性。 预期读者：实现开发方与用户方的双向沟通。 2、在每个用例下必须组织建立相应的顺序图（sequence diagram），下面列出了软件的6组性能、生产厂家、数目。 3 业务需求 3：与诊断故障，日期 [. 2; 提高开发效率、报表.2 可靠性 【说明】指在规定的条件和期限内，和功能：与软件同一些指定系统交互作用能力有关的一些软件属性、生产厂家，与软件仍能保持规定性能水平的能力有关的一些软件属性、学历与水平。 资源特性。删除的需求：与实施修改、双方的开发人员和系统维护人员.2 约束条件 3.0、角色（role、基本部件。这些功能都是满足规定需求和潜在需求所必需的，在需求阶段主要完成模板中用例视图（use case view）规定完成的部分：与软件故障引起的失误频率有关的一些软件属性。在这里采用rose工具是作为绘图分析工具使用.0 for Windows 95/、软件生命周期的各个阶段、资金分期到位计划、版本号等，各个顺序图（sequence diagram）的命名需在一般的中文概括前增加代表本节编号的部分：与针对蓄意（或无意）而非法存取程序和数据的预防能力有关的一些软件属性、分期目标）、actor），在完成基本内容的基础上.用户认证”.1—5：在某个其它软件的运行环境下。
需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到：SRS文档（system requirement Specification）；2.DRM文档；3. Acceptance Plan. 从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。 狭义上理解：需求分析指需求的分析、定义过程。 一、为什么要需求分析 需求分析就是分析软件用户需求是什么。如果投入大量的人力，物力，财力，时间，开发出的软件却没人要，从发重新开发过，这种返工是让人痛心疾首的。（相信大家都有体会）比如，用户需要一个for Linux 的软件，而你在软件开发前期忽略了软件的运行环境，忘了向用户询问这个问题，而想当然的认为是开发fox window的软件，当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，恨不行找块豆腐一头撞死。 需求分析之所以重要，就因为他具有决策性，方向性，策略性的作用，他在软件开发的过程中具有举足轻重的地位。大家一定要对需求分析具有足够的重视，在一个大型软件系统的开发中，他的作用要远远大于程序设计。 二、需求分析的任务 简言之，需求分析任务就是解决“做什么”的问题，就是要全面地理解用户的各项要求并准确地表达所接受的用户需求。 需求分析的过程 需求分析的工作，可分为四个方面：问题识别、分析和综合、制订规格说明、详审。问题识别 就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些要求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求（做什么），性能需求（要达到什么指标），环境需求（如机型，操作系统等，）可靠性需求（不发生故障的概率），安全保密需求，用户界面需求，资源使用需求（软件运行是所需的内存，CPU等），软件成本消耗与开发进度需求，预告估计以后系统可能达到的目标。 分析与综合
业务调研报告
目录 文档概述 ................................................................................................. 错误！未定义书签。 本科简介 .......................................................................................... 错误！未定义书签。 组织架构 (3) 总体流程 (3) 研发中心业务现状与需求 (5) 组织构架 (5) 现有系统 (5) 业务流程 (5) 业务现状 (5) 业务需求 (6) 供应链中心业务现状与需求 (7) 组织构架 (7) 现有系统 (7) 业务流程 (7) 业务现状 (8) 业务需求 (9) 涉及报表或单据 (10) 涉及考核指标 (11) 热水器事业部业务现状与需求 (12) 组织构架 (12) 现有系统 (12) 业务流程 (12) 业务现状 (12) 业务需求 (12) 涉及考核指标 (13) 五金洁具事业部业务现状与需求 (14) 组织构架 (14) 现有系统 (14) 业务流程 (14) 业务现状 (14) 业务需求 (14) 模具事业部业务现状与需求 (15) 组织构架 (15) 现有系统 (15) 业务流程 (15) 业务现状 (16) 业务需求 (16) 营销中心现状与需求 (17)
组织构架 (17) 现有系统 (17) 业务现状 (17) 业务需求 (17) 涉及考核指标 (18) 财务中心业务现状与需求 (19) 组织构架 (19) 现有系统 (19) 业务流程 (19) 业务现状 (20) 业务需求 (20)
第一章 肥城市基本情况及总体社会经济发展概况 一、肥城市概况 肥城市隶属于泰安市，泰安市下辖两市（肥城市、新泰市）、两县（东平县、宁阳县）、两区（泰山区、岱岳区）。肥城市是一个经济发展较快、实力较强的县级市，它位于泰安市的西部，济宁市的北部。北邻济南长清区，西邻平阴县，南靠东平县与宁阳县。距省会济南约65公里，距泰安市中心约45公里。 在肥城市区西南边界约45公里处有105国道南北穿过，向东约45公里处（泰安市中区西边界）有104国道南北走过，此处还有京福高速公路南北经过，经过市区的省道南北有济微路，东西有泰平路，铁路仅有泰肥铁路用于运输货物，无客运列车。 目前市区占地面积13.49平方公里，人口13万人左右。从2001年3月开始至2001年11月底，新城开发新增面积4平方公里，修4.6公里的道路。2002年计划城市向东向西发展，新增7平方公里用地，修建城市道路17公里。至2004年城市总用地达25万平方公里，人口达25万。 按照肥城市发展规划，2010年城市占地127.7平方公里，人口达96.02万，形成一城两镇（新城、王瓜店镇、老城镇）格局。 肥城市作为一个新兴城市，现状规划建设较好。市区内道路平整宽阔、环境整洁，龙山坐落城中形成一处天然公园，龙山河东南、西北贯穿而过。 二、肥城市社会及经济发展的历史成就 自80年新城区搬迁以来，城市开发拉出了框架，基础设施建设实现了新的突破。国民经济呈现加速发展态势，综合实力进一步增强。
（一）、国民经济持续发展 肥城市部分年份主要经济指标 （二）、经济结构不断优化升级
肥城市在保持经济总量快速增长的同时，也在大力推进经济增长方式的根本转变和经济结构的优化升级，努力把肥城市建成一个以工、农业为主导，集科技、金融、旅游等为一体的现代化城市。1999年至2001年，肥城市三年间累计完成固定资产投资共44.58亿元（其中1999年10.5亿元，2000年13.88亿元，2001年20.20亿元）。同时培植了一大批新的经济增长点，与住肥企业共建区域经济共同体的思想全面展开，创造了地企联手融合发展的新格局。旅游资源开发进一步加快。 （三）、对外开放水平不断提高，城市规划建设日益优化 在肥城市市委、市政府的正确领导及决策下，招商引资工作取得显著成果。并坚定不移的把招商引资摆在各项工作之首，形成了大开放、大发展的良好氛围和崭新局面。仅2001年引到位的市外资金就达到10.98亿元，其中利用外资908.6万美元，自营出口创汇4560万美元，比上年增长15%。 坚持把城镇开发和以道路为主的基础设施建设作为一大重点和具体项目运做实施，实现历史性跨越。运用经营城市的理念“以地生财”迈出大步子。完成了西扩4平方公里的开发框架工程，东区优化完善全面展开，泰西大街路面改造，“一线两翼”的开发建设格局，正在向纵深推进。 （四）、肥城市2000年国民经济预期目标及城市建设任务目标。 肥城市实施一系列扩大内需、刺激消费、优化产业结构等促进经济发展的政策措施，同时注重用市场化推进城市化，靠经营城市发展城市，尽快建立起适应城市经济发展要求的运营体制，实现城乡建设的健康快速发展，为促进全市扩大开放，招商引资，实现跨越发展，营造良好的环境。 根据《肥城市政府2002年2月1日政府工作报告》提出的2002年政府工作的目标任务中可以看到国民经济预期目标为：国内生产总值增长14%，即
_______项目需求分析报告 客户项目 经理：
日 期： 用友项目 经理： 日 期： 文档控制 修改记录
审阅人 存档
1、调研活动总结 建议描述内容提要： 1、调研时间； 2、调研人员； 3、参与人员； 4、调研内容； 5、调研范围； 6、调研方式； 思路：首先对整个调研活动的过程做一下整体的总结，使阅读者了解整个调研活动是在什么情况下完 成的，动用了哪些资源等。 2、公司概况 2.1企业简介 建议描述内容提要： 1、企业规模、建厂时间； 2、人员、设备、生产能力； 3、产品主要工艺流程； 4、主要产品、市场占有情况；
5、在同行业中的地位； 6、企业信息化历程 2.2组织机构 建议描述内容提要： 画出企业的组织机构图。 3、各部门岗位设置 3.1、财务部主要岗位设置 建议描述内容提要： 财务部是负责全公司财务会计工作的职能部门，主要岗 位及职能是： 1、会计主管：负责记账、凭证审核、账表查询、部门收 支分析； 2、应收会计：制作凭证、登记应收账款、账款核销； 3、应付会计： 4、现金出纳： 5、银行出纳：
6、成本会计： 7、成本核算员： 说明：本部分内容也可以通过表格的形式给予描述。 3.2、采购部主要岗位设置 建议描述内容提要： 采购部是负责全公司生产用材料和非生产用材料采购的职能部门，主要的岗位及职能是： 1、采购主管： 2、采购计划员： 3、采购业务员： 3.3、销售部主要岗位设置 建议描述内容提要： 销售部是负责公司所有生产产品和部分半成品销售的职能部门，主要的岗 位及职能是： 1、销售主管： 2、销售业务员： 3、价格监管员：
我国外贸行业发展现状及人才需求分析 本文立足于我国外贸行业发展现状，根据企业对外贸人才的需求，对实证区域多家涉外企业进行了调查，并结合统计结果对“十二五”时期我国外贸人才培养提出建议。 关键词：外贸行业人才需求 “十二五”时期，是我国全面建设小康社会的关键时期，也是深化改革开放、加快转变经济发展方式的攻坚时期。尽管国际金融危机带来的冲击仍在持续，但世界经济保持缓慢复苏，国内经济持续较快增长。根据世界贸易组织公布的数据，2009年中国出口占全球出口比重由上年8.9%提高到9.6%，已经超过德国成为世界第一出口大国；世界经济复苏过程中国际市场需求是沿着低端产品-中端产品-高端产品的路径逐步恢复。目前我国出口产品仍以中低端产品为主，2010年以来，我国外贸呈现恢复性较快增长态势。前三季度，我国进出口总额21486.8亿美元，比上年同期增长37.9%。其中出口11346.4亿美元，增长34.0%；进口10140.4亿美元，增长42.4%。随着我国外贸发展质量不断提升，竞争力不断加强，对一线应用型外贸人才的需求趋旺，对外贸人才的要求也日渐提高。 区域外贸现状调查 目前，环渤海经济圈和京津冀都市圈正以无可替代的优势和特质，迅速成长为中国最具活力的第三大区域经济增长中心，在未来一段时期需要大量的外贸人才，然而涉外企业人才的缺乏和学生就业难的状况并存，引起了社会的广泛关注。为了充分了解和分析“十二五”时期对外贸人才的需求状况，本课题组从2009年7月至2010年10月在河北保定及周边地区开展了调查。 本次调查由保定职业技术学院国际贸易专业学生及相关教师组成调查小组，通过实地调查的方式向保定市及周边地区28家涉外企业发放了问卷调查表，收回调查表28份，其中有效问卷26份。在被调查的企业中，私营企业占62％、国有企业占13％、股份制企业占18％、合资企业占7％。 本次调查的内容主要包括：企业性质、国际贸易人员的学历层次、业务人员的英语能力、外贸人才应具备的知识结构及能力素质、企业紧缺岗位需求、企业对专业课程的设置、企业对国贸专业的毕业生和职业资格证书的看法等16个调查项目。
总需求和总供给分析模拟试题及答案解析 (1/3)名词解释 第1题 总需求曲线：________ 参考答案：总需求是指经济社会对产品和劳务的需求总量。表示经济当中的总需求量与价格总水平之间的对应关系的曲线就是总需求曲线。随着价格总水平的提高，经济社会中的消费需求量和投资需求量减少，因而总需求量通常与价格总水平呈反向变动关系。总需求曲线向右下方倾斜。 详细解答： 下一题 (2/3)名词解释 第2题 总供给曲线：________ 参考答案：总供给是指经济社会中可供使用的商品和劳务总量。表示经济中的总供给量与价格总水平之间关系的曲线就是总供给曲线。随着价格总水平的提高，经济社会中的商品及劳务的供给量增加，因而总供给量通常与价格总水平呈同向变动关系。总供给曲线向右上方倾斜。 详细解答： 上一题下一题 (3/3)名词解释 第3题 货币工资刚性：________ 参考答案：货币工资不随劳动需求和供给的变化而迅速作出相应的调整，特别是，当劳动的需求量低于供给量时，货币工资下降出现刚性。这主要是因为劳动者存在着对货币收入的幻觉。货币工资刚性成为凯恩斯主义解释宏观经济波动的理论基础。 详细解答： 上一题下一题 (1/2)简述题 第4题 主流经济学的总需求曲线(AD)是如何得到的？________ 参考答案：总需求是指经济社会对产品和劳务的需求总量，表示经济中的总需求量与价格总水平之间关系的曲线就是总需求曲线。在两部门的经济中，总需求由消费需求和投资需求构成。通过分析消费和投资二者的需求量与价格总水平之间的关系就可以得到总需求曲线。依照主流经济学派的观点，在既定的价格总水平下，经济中的货币量是总需求量的货币反映。在经济处于均衡状态时，这些货币被用来满足交易和谨慎以及投机需求。交易和谨慎构成了消费需求，而用于投机的货币则通过金融市场转化为投资需求。因此不同的价格总水平与总需求量之间的对应关系可以由IS- LM模型得到，即：I(r)=S(Y)与L1(Y)+L2(r)=M/P，从中消去利息率r，即得到总需求函数。 对应于不同的价格总水平，既定的名义货币量表示的实际货币量相应与价格总水平发生变动，从而LM曲线发生变动。对应于不同LM曲线，产品和货币市场的均衡将决定不同的总需求量。在IS曲线既定的条件下，价格总水平提高，实际货币量减少，利息率提高，投资减少，从而经济中的总需求量减少，即总需求曲线是一条向右下方倾斜的曲线。 详细解答： 上一题下一题
一、现状分析及需求 公安城域网络是政法网络的主要承载平台，当前德阳市公安和其他单位公用政法网络作为公安的骨干网络实现与上下级互联；作为新一代公安信息网的接入网部分，通过与用户域和数据域的结合，共同组成新一代公安信息网。 德阳市政法三级网分为主干链路和备份链路，备份网络设备使用年限已11年，超过设备使用设计使用寿命且备品备件已严重缺失，技术滞后；备份链路原有带宽622M, 备份链路当前的设备性能和链路带宽越来越难以满足承载公安业务，因此根据实际业务需求，采用最新的网络组网技术对备份链路进行升级和改造。 视频专网整个系统采用IP网络方式传输。每个区县上行视频传输带宽保证500M。由于视频业务的持续增加，上行视频传输带宽需要扩容到1G。 当前政法网络的设备和链路采用的设备与链路整体租赁的形式由中国电信德阳分公司承建维护，合同日期从2016年12月1到2019年12月1日截止，本次项目须面对通信运营商重新采购2020-2022年度德阳市政法三级主备网、视频专网服务租赁。 二、政法三级网主备份网络升级方案 德阳市政法信息传输网依托于通信运营商现有的骨干传输网，遵循设备共建、资源共享的原则，构建一个覆盖全市政法部门的传
输承载平台，能够支持数据、语音和图像业务的高速、可靠、安全地传送。德阳市政法三级网升级改造后的网络拓扑架构如下图所示： （1）传输网络建设：本次政法三级网备份网络服务租赁按照骨干网络标准进行规划，采用OTN技术建立一套全新的1000M传输网络，为各县市区公安局核心节点提供1条1000M的传输网络接入，各县市区业务采用点对点方式汇聚接入德阳市公安局核心设备，核心路由设备和核心传输设备支持10G以上的交换能力。同时为了保证整个骨干网络上所有节点的电路可用性，为每个网络节点和汇聚节点建立不用路由的双光路环路保护，在一条光纤中断的情况下自动倒换至另外一条光纤电路，电路具备自愈功能，双光路环路保护功能能保证主干网络全年99%以上的网络通达性。为了保证德阳市政法三级网业务的独立性，运营商的传输设备将下沉安装至各公安局机房，网络拓扑图如下：
客户公司名称“用友ERP-U6项目” 客户公司名称 调研与需求分析方案
文档控制 修改记录 存档 姓名 职位 审阅签字 拷贝号 地点 备注
目录 一、项目背景介绍 (6) 1.1公司简介 (6) 1.2公司组织架构图 (6) 二、行业背景分析 (6) 三、企业现状分析及解决方案 (7) 第一部分：市场部 (7) 1.部门现状： (7) 1.1部门结构及工作 (7) 1.2管理现状 (7) 1.3现有业务流程描述 (8) 2、现有业务分析和解决方案 (9) 2.1存在问题 (9) 2.2问题表象 (9) 2.3问题根源 (9) 2.4问题隐患 (9) 2.5解决对策 (10) 2.6解决价值 (10) 3、ERP执行方案 (10) 3.1优化业务流程 (10) 3.2业务解决场景 (11) 第二部分：PMC (12) 1.部门现状 (12) 1.1部门结构及工作 (12) 1.2管理现状 (12) 1.3现有业务流程描述 (13) 2、现有业务分析和解决方案 (14) 2.1存在问题 (14) 2.2问题表象 (14) 2.3问题根源 (14) 2.4问题隐患 (14) 2.5解决对策 (15) 2.6解决价值 (15) 3、ERP执行方案 (15) 3.1优化业务流程 (15) 3.2业务解决场景 (16) 第三部分：技术开发部 (17) 1.部门现状 (17) 1.1部门结构及工作 (17) 1.2管理现状 (17) 1.3现有业务流程描述 (17) 2.现有业务分析和解决方案 (18) 2.1存在问题 (18)
业务战略分析大纲 1本业务在我国的发展历史 2北车本业务基本情况 3国内市场状况分析 3.1市场需求分析（与技术、政策紧密相关） 3.1.1历史情况（增长率、总量） 3.1.2未来预测（量、质，原因） 3.2替代品与需求的影响 3.3用户群分析 3.4市场竞争对手分析 3.4.1供给能力分析 3.4.2南车集团基本情况 3.4.3与北车优劣比较 3.5潜在进入者分析 3.5.1进入壁垒 3.5.2潜在进入者 3.5.2.1国外公司 3.5.2.2民营企业 3.5.2.3与南北集团相比的优劣 3.6供应商及供应特点分析 3.7竞争成功的关键因素
结论：确定国内市场定位及发展策略 4国际市场状况分析 4.1国际市场板块分析预测 4.2市场竞争者分析 4.3国际市场技术与政策分析 4.4S WOT分析确定未来国际市场方向 4.5国际市场成功的关键因素 结论：国际市场定位及发展策略 1.1面对内忧外患，铁道系统改革势在必 然，这给以铁路机车车辆制造业为主的 北车集团带来新的机遇与挑战 1.1.1随着改革开放的不断深入铁路 （交通运输）成为制约经济与社会发 展的主要瓶颈； 1.1.2随着市场经济不断的发展，国家 逐步从计划走向宏观调控，政企职能 的分离要求铁道部门进行改革（铁道 系统是计划经济体制改革最后几块
板），铁路企业将被迫转向市场，独 立经营，自负盈亏； 1.1.3公路、航空、水运的快速发展对 铁老大带来了严重的威胁，铁道系统 企业唯有改革才能走出困境； 1.1.4中国加入WTO，中国铁路运输业 被迫面向外资开放，中国运输企业面 临新的挑战 1.2铁道系统改革将机车车辆企业逐步推 向市场，机车车辆企业所面临的外部环境发生了巨大的变化，这对机车车辆企业的生存与发展带来的巨大影响 1.2.1.1铁道系统企业与部脱钩，铁 路运输企业直接面向市场，形成 竞争态势，机车车辆企业的客户 1.2.1.2机车车辆企业脱离铁道部的
二、业务需求分析 随着业务的扩张、市场竞争和客户的需求的增长，宅急送应该如何改善企业 的业务过程、提高工作效率、降低管理成本，以保证客户服务的质量和满意度。 在企业实施新的发展战略或进行业务流程重组的过程中，应如何改造企业的组织结构、重组核心业务、选择合适的信息系统？杰出的信息系统是建立在充分的业务需求分析的基础之上的，我们将从操作层、管理层、决策层三个层次分析企业的现状、实际业务过程中的存在的问题和系统需求。 2．1 企业现状 2．2．1 组织结构 宅急送北京公司下设调度中心、分拣中心、接线中心、财务部、统计中心以 及北京地区的六个营业所同时还负责管理天津等邻近城市的配送调度。北京公司组织结构如下： 宅急送总公司 宅急送总公司 统计中心 统计中心 财务部财务部北京子公司 北京子公司 上海子公司 上海子公司 接线中心... 调度中心分拣中心营业所接线中心调度中心分拣中心营业所天津分公司 天津分公司 营业所 营业所 ... 图：企业组织结构图 各部门职能： 北京总公司：负责管理公司的总体业务和发展；
北京子公司：负责管理北京和区域城市的业务和发展；
统计中心：负责公司的报表统计和处理； 接线中心：负责市场开发和业务受理； 调度中心：车辆调度和配送调度； 分拣中心：中转库和异地快递货物管理； 营业所：市内业务受理、快递业务处理和市场开发； 财务部：财务管理。 从企业的组织结构上看，各级的职能部门没有划分严格的层次，业务职能子 公司、分公司、营业所的职能和业务控制结构存在一定程度上的业务重叠、交叉和内部竞争；而各营业所之间财务独立，缺乏有效的协调部门。调度中心和分拣中心和营业所的管理职责划分不明确，缺乏宏观的协调和控制。 2．2．2 核心业务 宅急送作为一包裹快运为主的物流服务公司，业务主要集中在同城和异地包裹快递业务，同时还包括一部分仓库代管、存储、包装等仓储服务。拥有自己庞 大的运输车辆和租用库房，主要的业务流程主要包括： 同城包裹快递业务（包括市内快运和提货业务） 异地包裹快递业务（包括门到门和门到港业务） 仓储和流通加工业务（货物存储和包装等）
怎样做需求分析之九：分析之业务流程 作者: fangang发布时间: 2012-04-10 17:26 我们将从客户调研现场拿回来的需求，经过一番功能角色分析，整个系统的整体脉络与轮廓已经被勾画出来。在这个过程中，我们首先将系统划分成了几个功能模块（如果系统规模较大，还应先划分为几个子系统，然后再划分出各个功能模块）。然后，我们为每个功能模块绘制用例图。用例图是站在用户角度去观察的系统，即系统为用户提供了哪些功能，这就是功能分析。同时，这些功能是为哪些用户服务的，这就是角色分析。我们绘制的用例图应当能够为用户所理解，这也是UML其中的一项核心思想——与客户形成统一的、能够相互理解的语言，这对于需求分析过程中与客户的沟通是大有好处的。 但形成对系统的整体轮廓，对于软件的需求分析来说是远远不够的。许多软件最终失败的非常重要的原因就是对需求分析过于草率、浮于表面，而没有深入细致地去分析，往往到了项目后期才把需求搞懂，才发现真正的需求与起初的认识大相径庭，才恍然大悟需求原来是这样，而往往那时已经追悔莫及了。这样的经历相信你也有过吧。所以，我们一定要沉下气来认真仔细地做需求分析，一定要做到位。 同样，细化需求也需要一定的方法与思路。一般来说，我们可以有两个方向细化需求：业务流程分析与业务领域分析。这里，我们先谈谈业务流程分析吧。 如果我们现在做的需求分析是一个企业信息化管理系统，毫不疑问，我们的软件系统就是在模拟企业已有的那些业务流程。在现实世界中，企业是按照怎样的流程来管理，我们的软件就应当去模拟这样的流程。但是，我们的软件不可能也不必要完全去模拟这样的流程，在这个流程中的有些环节是应当由软件去模拟的，但有些环节则是应当在系统之外，由人工去完成的。我们进行流程分析，就是要求分析哪些是系统之内的，哪些是系统之外的。 我曾经做过一个疑点信息库系统。该系统模拟的原有业务流程是这样的：高层纪检方面的领导通过信访、举报、数据查询分析等方式发现了一批问题，然后将这批问题制作成一套调查清册，亲自或者交由下级相关单位，下到基层去调查问题。直到调查工作完成以后，才从基层回到自己单位，填写调查工作底稿，详细描述调查情况，并结束调查工作。 首先，我们应当抛开软件实现，对这样一个流程进行梳理，形成这样一个步骤： 1. 高层领导通过信访、举报、数据查询分析等方式发现一批问题； 2. 将这批问题制作成一个调查清册； 3. 自查或将清册下派给下级去调查； 4. 下到基层执行调查； 5. 从基层回到自己的单位，填写调查工作底稿，详细描述调查情况，并结束调查工作。 然后，在对原始需求分析的基础上，分析我们的软件能做什么事： 第一步：信访和举报虽然有自己的操作流程，但那些都在这个系统之外，在这个系统中仅仅
应聘职位：业务需求分析师 个人信息 姓名：张三性别： 出生日期：1986.12.01 籍贯： 参加工作时间：2010.07 民族： 政治面貌：婚姻状况： 联系电话：身份证号： 目前薪资状况：万/年期望薪资状况：万/年是否同意调剂：若本岗位不适合是否同意调剂至其它岗位 全日制教育经历 2003-09–2007-07XXXX大学专业名称：XXX 学历：大学本科在职教育经历 2010-09–2013-07XXXX大学专业名称：XXX 学历：硕士研究生 工作经历 2015-08–至今XXXXXXXX 岗位名称：XXXX 工作职责和业绩： 1、XXXXX 2、XXXXXX 2015-05–2015-07 XXXXXXXXX 岗位名称：XXXX 工作职责和业绩： 1、XXXXXXX 2、XXXXX 2015-01–2015-05 XXXXXXX 岗位名称：XXXX 工作职责和业绩： 1、XXXXXXX 2、XXXXX 2010-07–2014-12 XXXXX
岗位名称：XXXX 工作职责和业绩： 1、XXXXXXX 2、XXXXX 2007-07–2010-06 XXXXXX 岗位名称：XXXX 工作职责和业绩： 1、XXXXXXX 2、XXXXX 项目经历 1、例子：北京移动大数据平台三年规划(2016-07-2016-09) 所在公司：XXXXX 项目描述：企业级大数据平台三年规划，解决跨域数据融合、数据共享和应用构建问题，合理规划公司的统一资源池，回答大数据平台与私有云之间的关系，规划跨机房的部署迁移，给出整体的数据接入计划及数据架构设计，提供完整安全的方案，保障及时高效的应用部署和业务需求实现。 项目职责：数据组组长，负责数据部分的规划推进，方案的编写，需求和数据源的调研和需求分析，进行数据湖共性和个性区域的数据分区设计，构建共性区域分层模型，分层模型中的数据流向及数据管控措施。 项目业绩：构建数据架构，形成分层模型，规划统一资源池，规划构建2000多个节点的集群。 2、XX (2015-01-2015-12) 所在公司： 项目描述： 项目职责： 项目业绩： 自我评价 ◆ ◆ 附加信息（所获荣誉及资格证书）
第一部分行业发展现状与市场需求情况分析 21世纪是物流挂帅的世纪。物流发展的水平已经成为一个国家、一个地区、一个企业核心竞争力的重要标志之一。 一、我国物流业发展现状与趋势 近年来，我国物流业受到了社会各方面的广泛关注，成为经济生活中的一个热点和亮点。现代物流的发展方兴未艾，预计将在新世纪里得到更快的发展。 （一）发展我国物流业的重要性 当降低成本、提高生产效率的竞争发展到一定程度之后，企业竞争的焦点开始由生产领域转向流通领域。世界经济贸易一体化趋势的加速发展，导致了现代物流这一货运流通领域全新理论和技术的不断发展和创新，高新技术的突飞猛进和计算机信息网络的日益普及，促使传统物流在不断向现代意义上的物流转变。许多国家政府以及有关业界纷纷开始意识到：现代物流的发展水平已成为一个国家综合国力的重要标志。 物流费用是我国工业企业仅次于原材料采购成本的最大支出。我国的流通费用约占GDP的20%，而发达国家如美国仅占10%左右。我国2001年GDP总量为95933亿元，当年全社会的物流费用支出为19186亿元，如果将这笔物流费用平均每降低1个百分点，全社会就能节约190亿元，而要达到发到国家的10%左右的水平，还有10个百分点的发展空间，粗略的估计也有9000亿元。 由此可见，发展现代化的物流产业，是关系到国计民生的重要举措。 对于我国企业来讲，物流管理不仅在提高运输效率，降低库存水平和对市场变化的快速反应方面卓有成效，更重要的是，物流管理可以帮助企业打破部门本位主义思想，协调各部门的努力，使之方向一致。因此，物流管理问题对于企业来讲，应该放到战略角度来考虑，发挥企业的整体优势，充分发掘第三利润源。 （二）我国物流业发展现状 现代物流在中国已经起步，标志主要有以下三点： （1）工商企业已经不满足于传统储运企业的单一、单项、分散的储运服务，正在向社会、向市场寻求现代物流服务。 （2）传统储运（运输、仓储、货代、邮电等）企业纷纷包装，改换门庭，向现代物流企业发展；工商企业内部的储运机构也有独立化的趋势，向物流企业发展。 （3）陆续产生了一批三资、民营或股份制的现代物流企业。
《商务智能》 中国工商银行营销数据仓库OLAP分析 班级信管1101、1102 姓名刘硕、张天鸣、林佳平、李佳欢 一.需求背景： 中国工商银行（Industrial and Commercial Bank of China）简称ICBC ，成立于1984年1月1日。作为中国资产规模最大的商业银行，经过29年的改革发展，中国工商银行已经步入质量效益和规模协调发展的轨道。 2003年末资产总额约52，791亿元人民币，占中国境内银行业金融机构资产总和的近五分之一。截至2010年末，工商银行总资产134，586.22亿元左右，
当前总市值14，344.70亿元左右，居全球上市银行之首。 截至2011年末，工商银行拥有397,339名员工，通过16,227家境内机构、203家境外机构和遍布全球的逾1,562家代理行以及网上银行、电话银行和自助银行等分销渠道，向412万公司客户和2.59亿个人客户提供广泛的金融产品和服务，基本形成了以商业银行为主体，跨市场、国际化的经营格局，在商业银行业务领域保持国内市场领先地位。 2010年末，总资产达134,586.22亿元，比上年末增加16,735.69亿元，增长14.2%;总负债达126,369.65亿元，比上年末增加15,308.46亿元，增长13.8%;总市值达2,335亿美元，居全球上市银行之首。 2010年实现净利润1,660.25亿元，较上年增长28.4%，增幅同比加快了12.0个百分点，继续稳居全球最盈利银行地位；平均总资产回报率和加权平均权益回报率分别为1.32%和22.79%，处于全球银行业领先水平;每股收益为0.48元，较上年增加0.10元；不良贷款余额和不良贷款率连续11年保持双下降，不良率降至1.08%。 受益于经营结构的优化、再融资的完成以及利润留成比例的适当扩大，资本充足率和核心资本充足率分别达到12.27%和9.97%，资本实力和可持续发展能力进一步增强。 中国工商银行总部大楼由美国SOM设计师事务所设计，楼高13层，建筑面积近13万平方米，分矩型区和弧型区两大部分，中间以天桥形式联为一体。大楼为整体钢结构工程，技术要求高，工艺复杂，其结构形式为磨擦型高强度螺栓联接，底层插入柱为箱形截面，全熔透焊接最大板厚达100mm；总用钢量达8000吨，由中铁武桥重工股份有限公司（原武汉桥机厂）进行施工详图深化设计，并完成全部钢结构的工厂制造任务。该项目按《钢结构工程施工验收规范》（GB50205-95）制造、安装并验收，检验合格，受到了业主及监理的一致好评，为中铁武桥重工在首都树立了形象，赢得了信誉，整体工程获得国家颁发的鲁班奖。 二.基本定义和术语： 1.信用货币——是以信用活动为基础产生的,能够发挥货币作用的信用工具.它的形式主要有商业票据,银行券和存款货币 2.存款货币——是指存在商业银行使用支票可以随时提取的活期存款 3.准货币——本身是潜在的货币而非现实的货币,一般由定期存款,储蓄存款,外币存款以及各种短期信用工具等构成 4.货币存量——一国在某一时点上各经济主体所持有的现金和存款货币的总量 .货币增量——一国在某一时期内各经济主体所持有的现金和存款货币的总量 5.货币制度——又称”币制”或”货币本位制”,是国家以法律形式确定的货币流通的结构和组织形式,简称币制 6.国家货币制度——一国政府以法律形式对本国货币的有关要素,货币流通的组织与调节等加以规定所形成的体系.资本主义产生以来,国家货币制度经历了银本位制,金银复本位制,金本位制和不兑现的信用货币制度 7.国际货币制度——也称国际货币体系,是支配各国货币关系的规则以及国际间进行各种交易支付所依据的一套安排和惯例.包括1国际储备资产的确定2汇率制度的安排3国际收支的调节方式 8.无限法偿——有限法偿的对称.是指本位货币具有无限的支付能力,既法律上赋予它流通的权力不论每次支付的金额多大,受款人均不得拒绝收受,否则视为违