第四部分 \r\n现代软件工程的需求过程
《现代软件工程》
传统的需求分析方法-1\r\n面向对象的需求分析方法-2\r\n基于UML的需求分析方法-3\r\n需求工程与需求管理的实现-4
第四部分 现代软件工程的需求过程
第一章 传统的需求分析方法\r\n需求概念与需求过程-1.1\r\n问题定义阶段的需求分析-1.2 \r\n传统软件工程的需求分析方法-1.3\r\n传统软件工程的建模方法-1.4
第四部分 现代软件工程的需求过程
1.4 传统软件工程的建模方法
回顾一下：上节课我们学习了\r\n问题定义阶段的需求分析\r\n确定系统目标\r\n确定系统边界\r\n传统软件需求分析（9个步骤）\r\n1、系统分析\r\n2、组织结构与功能分析\r\n3、业务流程分析\r\n4、数据与数据流分析\r\n5、产生数据字典\r\n6、功能/数据分析\r\n7、系统功能划分\r\n8、数据资源分布和应用部署\r\n9、新系统总体方案的建立\r\n结果：产生系统功能定义\r\n这节课开始，我们介绍需求分析的下一步工作：建模
1.4.1 建模：作用与意义
需求说明：\r\n描述了软件要做什么——系统要实现的功能（性能、特征等）\r\n通常是非正式描述，与未来的用户一起准备，正式合同的基础，常作为软件开发的起点\r\n需求说明的形式：\r\n非正式的大纲\r\n高度抽象和结构化的功能说明\r\n程序员非正式的理解\r\n原型系统（与未来用户一起开发）\r\n适合于 只有一个或几个程序员的简单系统\r\n数据和子系统结构可以装在程序员的脑子里
系统功能只是软件系统最基本的外部表征\r\n系统功能主要是面向用户的\r\n大型复杂的系统，靠一些简单的功能定义，是无法实现的\r\n手工作坊式的开发是由小功能（小系统）堆砌成大系统\r\n混乱的（没有分析）控制流、信息流（传统）\r\n大量类似的事件，但却采取不一致的、而又基本重复的处理（对象）\r\n一种结果是：建立无数个信息“孤岛”\r\n另一种结果是：系统内部纵横交错、关联关系错综复杂，一个小问题可能牵涉系统全身，系统非常不稳定\r\n怎么办？需求分析的下一步工作，建立系统模型\r\n用模型来进一步描述系统需求
需求分析与系统建模
《天津联通本地网营业系统》客户申请数据的流向图
信息入口
功能模块
根据不同的申请和情况,决定走不同的路线、经过不同的处理流程
大型系统通常十分复杂，很难直接对它们进行分析设计，因此，人们经常借助模型来设计分析系统。\r\n绘画、书法、音乐、戏剧等等，这些复杂的系统，都可以分析出它的一些特有的固定模式。\r\n例如：要了解京剧，可能先要搞清楚什么是行当、流派、程式，等等。“标签”帮助我们对系统的了解。\r\n模型是现实世界中的某些事物的一种抽象表示。\r\n抽象的含义是抽取事物的本质特性，忽略事物的其他次要因素，使得我们能比较容易地认识事物的本质。\r\n模型抽取是理解、分析、开发或改造事物原型的常用手段。\r\n开发复杂的软件系统，系统分析员建立的分析模型，可以从不同侧面，从复杂的背景下，抽象出系统清晰的目标特征，便于用户理解和开发实现
需求分析与系统建模
对于复杂系统，模型是需求和体系结构之间的过渡： \r\n需求的抽象，成为需求模型\r\n系统体系结构的特定方面来自需求模型\r\n模型用需求的抽象视图表示，这种功能的文档称为模型（Model）
模型的作用\r\n整个系统太复杂，难以一下子抓住，通过模型简洁地描述系统某个方面 \r\n交流。（项目组成员之间，与客户）\r\n将系统体系结构归档\r\n模型的表述：模型语言\r\n 模型Model 表示法Notation\r\nModel: 表示系统的结构\r\n设计系统时可以在高层进行讨论，\r\n而不用太早进入代码的细节\r\nNotation: 以图、表、文字等将模型文档化
模型建立的思路有两种：\r\n自顶向下、逐步求精\r\n自底向上、综合集成。 \r\n描述系统模型最常见的方法是形式化描述和图示化描述。\r\n形式化描述方法非常精确、严谨，易于系统以后的实现，但难以掌握和理解，模型可读性差，往往只有专业人员才会使用，因而难于推广。\r\n图示化方法直观、自然，易于描述系统的层次结构、功能组成，且简单易学，通常还有工具软件支持，因而成为信息系统的主要描述工具，但这种方法的精确性和严谨性不够。
需求分析与系统建模
分析模型Analysis models\r\n描述应用领域（问题域）\r\n设计模型 Design models\r\n描述软件系统（问题的解域结构 ）\r\nOOA与OOD\r\n面向对象技术的分析模型和设计模型之间使用相同的模型和建模概念\r\n解决从分析阶段到设计阶段的过渡问题，防止不一致\r\n因此，OOA与OOD经常联系在一起
面向过程的建模\r\n面向过程的建模方法是把过程看作系统模型的基本主线，数据是随着过程而产生的。最有影响的面向过程的设计方法是Yourdon的结构化分析与设计方法（SA-SD-SP方法）。 \r\n面向数据的建模\r\n面向数据的建模方法把模型的输入输出看成是系统的主线，因此，首先定义的是数据结构，而过程模块是从数据结构中导出的，即功能跟随数据。最有影响的面向数据的设计方法是Jackson设计方法。\r\n面向对象的建模\r\n面向对象的需求分析方法是采用面向对象技术的建模概念，以对象、消息和事件及其处理为主线。如实体、关系、属性等，同时运用封装、继承、多态等机制来构造模型，模拟现实系统。
考察高速公路上的收费站与汽车的关系\r\n面向过程是功能控制过程\r\n传统的结构化需求分析和建模技术的基本点是构建过程，在系统的需求开发过程中，系统被分解成若干个过程。\r\n以收费站的观点看汽车，汽车进来、出去都要经过收费站，这是面向过程的观点，收费站是功能，汽车是输入、输出数据。\r\n以过程为重点，过程是主要的 ，数据是依附的\r\n面向数据是数据控制过程\r\n站在汽车的观点看收费站，汽车可以经过收费站，还可以去加油站、休息站。接受不同的服务功能，交不同的费用。\r\n同样这些站是功能，汽车是数据。但以汽车为观察点，汽车是核心数据，功能依附于数据，这是面向数据的观点\r\n而面向对象的方法是采用问题模型的观点，在系统的需求开发过程中，系统被分解并建造出一个问题域的模型。\r\n汽车、收费站、加油站、都在一个整体内，但分别被定义为不同的对象类。适合按不同的需要进行考察和处理\r\n在面向对象的设计中，考察的目标是对象，然后将具有共同特征的对象归纳成类，组织类之间的等级关系，构造类库。\r\n在应用开发时，在类库中选择相应的类。
模型的分类
分类：根据从何种角度来理解和描述系统的结构\r\nStructured Methods：\r\n包括结构化分析，结构化设计等\r\n通常用Dataflow diagram描述数据如何经过各个处理流程\r\n适于关系数据库设计（大量数据，数据的处理可由数据之外的函数处理）\r\n几种典型的需求分析建模方法\r\nDFD数据流建模\r\nIDEF功能建模\r\nSTD行为建模\r\nE-R实体-关系建模\r\nObject-oriented Methods： \r\n 将数据和函数统一\r\n建议迭代、增量（iterative, incremental）开发\r\nExample: UML, Shlaer-Mellor.
需求分析和设计与建模过程
1.4.2 数据流建模
数据流建模方法是一种面向结构化分析的方法，主要工具是数据流程图（DFD）\r\n数据流表示信息在系统中流动和处理的过程，并不表示具体实现，因此，是系统分析员与用户沟通交流的工具\r\n数据流图也是系统设计的依据，设计人员根据数据流图，可以确定子系统的边界\r\n从数据流图可以进一步分解出数据存储和数据加工，这是系统的最基本功能\r\n数据存储产生数据字典，数据加工产生数据处理说明\r\n数据流建模方法就是这样建立了对系统的描述\r\n我们在上一节课中已经介绍了DFD过程
IDEF建模
IDEF的含义是集成计算机辅助制造（Integrated Computer－Aided Manufacturing，ICAM) DEFinition。最初的IDEF方法是在美国空军ICAM项目建立的。\r\n最初开发的3种方法是：\r\n功能建模（IDEF0）\r\n信息建模（IDEF1）\r\n动态建模（IDEF2）\r\n随着信息技术的相继开发，产生了所谓IDEF族方法：\r\n数据建模（IDEF1X）\r\n过程描述获取方法（IDEF3）\r\n面向对象的设计（OO设计）方法（IDEF4）\r\n使用C＋＋语言的OO设计方法（IDEF4C＋＋）\r\n实体描述获取方法（IDEF5）\r\n设计理论（rationale）获取方法（IDEF6）\r\n人－系统交互设计方法（IDEF8）\r\n业务约束发现方法（IDEF9）\r\n网络设计方法（IDEF14）等。
IDEF建模
根据用途，可以把IDEF族方法分成两类： \r\n第一类IDEF方法的作用是沟通系统开发人员之间的信息交流。主要有：IDEF0、IDEF1、IDEF3、IDEF5。\r\nIDEF0通过对功能的分解、功能之间关系的分类（如按照输入、输出、控制和机制分类）来描述系统功能。\r\nIDEF1用来描述企业运作过程中的重要信息。\r\nIDEF3支持系统用户视图的结构化描述。\r\nIDEF5用来采集事实和获取知识。 \r\n第二类IDEF方法重点支持系统开发的设计过程部分。目前有两种IDEF设计方法：IDEF1X和IDEF4。\r\nIDEF1X可以辅助语义数据模型的设计。\r\nIDEF4可以产生面向对象实现方法所需的高质量的设计产品。\r\n在需求分析阶段，我们重点介绍第一类IDEF0和IDEF1，在介绍面向对象方法时，我们将简单介绍IDEF3
IDEF0只使用盒子和箭头这样二种容易\r\n 理解的图形语言，代表一个真实系统\r\n有效的IDEF0模型有助于组织系统分析，\r\n 便于模型的构造者和流程的执行者交流。\r\nIDEF0建模方法确立了分析的范围，流\r\n 程的设计者使用IDEF0方法，提高了认\r\n 识和决策的一致性。\r\n右图是基本的IDEF0模型图\r\n盒子表示一种活动，是IDEF0最基本的元件，通常使用动词描述活动特性。\r\n箭头表示输入、控制、输出和机制，箭头用以连接系统中各活动，箭头通常是由名词描述：\r\n输入（Input）：实行或完成特定活动所需的资源，置于框图的左侧\r\n输出（Output）：经由活动处理或修正后的产出，置于框图的右侧\r\n控制（Control）：活动所需的条件限制，置于框图的上方\r\n机制（Mechanisms）：完成活动所需的工具，包括人员、设施及装备，置于框图的下方
（1）IDEF0——功能建模
IDEF0方法不仅可以描述独立的活动，而且可以显示出由几个活动组成的连续流程，同时显示了各个活动的相互关系。\r\n右图描述了产品A，B，C的生产过程，基本活动是建立机制、制造产品、检查产品。\r\n建立机制的输出文档作为制造产品活动的输入，制造产品活动的产品A、B、C输出作为检查产品活动的输入。
生产过程的IDEF0
在这里我们可以看到，IDEF0丰富和深化了“功能”的概念——描述了“功能”间的联系（输入/输出）和控制机制
IDEF0的多层分解结构
建立IDEF0模型是自上而下的分解活动。\r\n首先依据活动的边界划定IDEF0中的框图。\r\n在顶层框图完成以后，根据实际流程，可以把活动分解成下一层更小的活动。\r\n这种阶梯结构有利于确定模型的范围。\r\n通过观察图形，得到更深入的理解，防止系统描述中不必要的繁琐和疏漏。
IDEF0的建模步骤： \r\n（1）资料的收集：了解流程的相关背景，包括相关人员、事物及制度。建模需要与专家和流程的实际操作者广泛讨论。对收集到的信息分类加工整理。\r\n（2）定义范围：在资料收集的基础上，分析关键性流程，如外部接口、系统与环境的边界等。\r\n（3）针对收集到的资料绘图，根据IDEF0的绘制原则和符号，设计第一层。\r\n（4）分解：对第一层进行分解，针对每个阶层编写辅助说明文字，并与父层共同构成完整模型。\r\n（5）确认：模型建构者把初步的IDEF0图形和相关文件再次和相关人员进行讨论，确认最终结果。
（2）IDEF1——信息建模
IDEF1信息建模方法主要用于对所建系统的信息资源进行分析和交流。IDEF1X是IDEF系列方法中IDEF1的扩展版本,是在E-R(实体联系)法的原则基础上,增加了一些规则, 使语义更为丰富的一种方法。用于建立系统信息模型。\r\n主要内容是，对在组织中正在使用的信息，在现有流程分析过程中，确立哪些约束是由于缺乏合适的信息引起的，以及实施新流程所需要的信息。\r\nIDEF1明确了现存的信息，以及在企业内部需要被管理的信息。\r\nIDEF1是一种组织方法，可以标定和分析信息。\r\nIDEF1是一种分析的工具，可以完成对以下问题的分析：\r\n（1）企业中信息的收集、保存、管理。\r\n（2）控制信息管理的规则。\r\n（3）企业中信息的逻辑关系。\r\n（4）由于缺乏有效的信息管理所导致的问题。
IDEF1模型
IDEF1方法模型的表达，由实体集，属性集和关联集组成。\r\n在IDEF1图中关联集由实体集之间的连接表示。\r\n在连接端部的菱形和连接中部的半菱形代表关系集的额外的信息（主要和附属的）
在建立信息模型时首先确认模型中有哪些实体（Entity）\r\n一个IDEF1的实体（Entity）代表了组织中真实和抽象的事物\r\n一个IDEF1实体集（EntityClass）代表了实体的集合\r\n区分实体的两个基本原则：\r\n1）它们是永久的，组织可以对实体进行观察、加密、记录、组织、储存。\r\n2）它们可以被分离，可以从其它实体中区分出来。\r\n实体具有特定的属性(Attribute)，属性记录了现实事物的特征值\r\n集聚所有相同属性名字或属性值就形成了属性集（Attribute Class）\r\n属性值可以区分实体集。凭借一个或多个属性集，把实体从实体集中区分出来的属性集被称为关键集（KeyClass）。\r\n关联是实体和实体之间的联系，一个关联集可以被认为是实体集之间的存在关系。例如：一个的关联是“工作于”连接了实体集“雇员”和实体集“部门”。
IDEF1建模过程
1.4.3 行为（状态）建模
与功能、数据模型不同的是，行为（状态）模型重点描述系统状态和行为（控制）的模型，既：\r\n用来描述系统与某些要素（如时间）相关的动态行为与系统的控制逻辑，描述对象彼此间经过相互作用后，随要素（时间）改变的不同运算顺序。\r\n不是由数据和处理，而主要是由事件和控制组成\r\n行为模型以“事件”（Events）和“状态”（States）为其模型的主要概念，动态模型以状态图形式呈现。\r\n状态转换图（State-Transition diagram STD）是行为（状态）建模的主要工具\r\n主要应用于具有多种行为（状态）相互转换的系统分析
状态1
Do:活动1
状态2
.…...
事件1[条件1] /动作1
结束\r\n事件
初始\r\n事件
空闲
可视菜单
左边按钮按下/显示弹出菜单
左边按钮弹起/擦除弹出菜单
光标移动/高亮菜单项
弹出菜单动作
行为模型表示方法 状态图：状态和事件的网络，侧重描述每一类对象的动态行为。
事件： \r\n可以是：瞬时发生的行为\r\n 按动鼠标按钮（按钮、位置）\r\n可以是：引起对象状态转换的控制信息\r\n飞机起飞（航线、航班号、城市）\r\n脚本和事件踪迹\r\n 脚本是系统某一次特定运行时期内发生的事件序列。（脚本也叫场景scenarios ）\r\n事件追踪图\r\n侧重说明发生于系统执行过程中的一个特定“场景”
状态： 对象属性和对象关联的抽象形式\r\n状态的特征表示方法举例：\r\n状态：闹铃响\r\n描述：闹铃响表示预定时间到\r\n产生本状态的事件序列：\r\n 设置闹钟（预定时间）\r\n 不包括清除闹铃的任何后续操作\r\n 当前时间=预定时间\r\n表征本状态的条件：\r\n 闹铃=开，从预定时间起没有按键的情况下， \r\n 目标时间?当前时间 ?目标时间 20秒\r\n本状态接受的各种时间：\r\n 事件 动作 下一个状态\r\n当前时间=目标时间 20 重新设置闹钟 正常\r\n按下按钮（任意按钮） 重新设置闹钟 正常
案例：通话脚本（只包括影响电话线的事件）
事件追踪图举例：打电话的事件追踪图
此时有电话打进来将如何？\r\n此时线路中断将如何？\r\n此时……
此时有电话打进来将如何？\r\n此时线路中断将如何？\r\n此时……
此时有电话打进来将如何？\r\n此时线路中断将如何？\r\n此时……
举例：饮料自动售货机系统的状态图
投入硬币\r\n（有效的）
投入硬币金额\r\n (1元、5元、10元)
金额计算器
存量计算器
顾客
售货机
选择键
举例：饮料自动售货机系统的事件追踪图
售完灯
历史\r\nＥ-Ｒ模型：Entity-Relationship Model\r\n1976年，P.P.S.Chen提出Ｅ-Ｒ模型，用Ｅ-Ｒ图来描述概念模型\r\n观点\r\n世界是由一组称作实体的基本对象和这些对象之间的联系构成的\r\n数据库技术的发展，软件系统分析的方法，向面向数据方向转变，数据代替功能成为第一位的\r\n主要关注的对象是：\r\n要处理的数据对象是什么\r\n数据对象的组成形式\r\n数据对象的属性\r\n数据对象的位置和相互关联关系\r\n对数据对象的加工和处理
1.4.4 实体-对象（E-R）建模
Ｅ-Ｒ模型-实体
（1）实体：\r\n 是客观世界中存在的、且可相互区分的事物。它可以是人或物，也可以是具体事物或抽象事物。\r\n例如：教师、学生、课程是实体。\r\n实体用矩形框表示，如：
教师
（2）联系：客观世界中的事物彼此之间有联系，描述实体与实体之间的关系。联系有三种：\r\n1：1（一对一联系）\r\n 例如：实体“校长”与“大学”之间的联系为“1：1”\r\n1：N（一对多联系）\r\n 例如：实体“学校”与“院系”之间的联系为“1：N”\r\nM：N（多对多联系）\r\n 例如：实体“学生”与“课程”之间的联系为“M：N”\r\n联系用菱形框表示，如：
Ｅ-Ｒ模型-联系
Ｅ-Ｒ模型-属性
（3）属性：属性是实体或联系所具有的性质。通常一个实体或联系由若干属性来刻画。
教师
学生
课程
教授
1
N
M
N
成绩
选修
对ER模型的理解（一）
ER模型是人们认识客观世界的一种方法、工具。ER模型具有客观性和主观性两重含义。\r\nER模型是在客观事物或系统的基础上形成的，在某种程度上反映了客观现实，反映了用户的需求，因此ER模型具有客观性。\r\n但ER模型又不等同于客观事物的本身，它往往反映事物的某一方面，至于选取哪个方面或哪些属性，如何表达则决定于观察者本身的目的与状态，从这个意义上说，ER模型又具有主观性。
对ER模型的理解（二）
ER模型的设计过程，基本上是两大步：\r\n先设计实体类型（此时不要涉及到“联系”）；\r\n再设计联系类型（考虑实体间的联系）。\r\n具体设计时，有时“实体”与“联系”两者之间的界线是模糊的。\r\n数据库设计者的任务就是要把现实世界中的数据以及数据间的联系抽象出来，用“实体”与“联系”来表示。\r\n另外，设计者应注意，ER模型应该充分反映用户需求，ER模型要得到用户的认可才能确定下来。
以数据库应用为中心的分析过程
目标：核心应用是数据库管理信息系统\r\n实现数据库应用的主要过程\r\n用传统软件工程方法，分析数据流，得到数据对象，确定数据字典\r\n筛选数据：输入数据；校验数据；转换数据；综合数据。\r\n分析数据间联系\r\n定义数据库表结构\r\n编制与调试应用程序\r\n数据库试运行\r\n功能测试\r\n性能测试（时空代价）
联系的设计
联系集 \r\n 联系集是n（n≥2）个实体集上的数学关系，这些实体集不必互异。如果E1，E2，…，En为n个实体集，那么联系集R是{(e1，e2，…，en）|e1∈E1 ,e2∈E2，…，en∈En}的一个子集，而（e1，e2，…，en）是一个联系。 \r\n联系的元数 \r\n一个联系涉及到的实体集个数 \r\n联系的连通词 \r\n联系涉及到的实体集之间实体对应的方式 \r\n实体的基数 \r\n有两个实体集E1和E2，E1中每个实体与E2中有联系实体的数目的最小值min和最大值max，称为E1的基数，用（min，max）形式表示
联系的设计
联系的设计
ER模型的操作 包括实体类型、联系类型和属性的分裂、合并、增删等等
ER模型的操作 包括实体类型、联系类型和属性的分裂、合并、增删等等
ER模型的操作 包括实体类型、联系类型和属性的分裂、合并、增删等等
采用ER方法的数据库概念设计 ——设计局部ER模式
范围划分的原则：\r\n范围的划分要自然，易于管理；\r\n范围之间的界面要清晰，相互影响要小；\r\n范围的大小要适度。太小了，会造成局部结构过多，设计过程繁琐，综合困难；太大了，则容易造成内部结构复杂，不便分析。
采用人们习惯的划分；\r\n避免冗余，在一个局部结构中，对一个对象只取一种抽象形式，不要重复；依据用户的信息处理需求
确定属性的原则：\r\n属性应该是不可再分解的语义单位；实体与属性之间的关系只能是1:N的；不同实体类型的属性之间应无直接关联关系。
属性分配的原则：\r\n 当多个实体类型用到同一属性时， 一般把属性分配给那些使用频率最高的实体类型，或分配给实体值少的实体类型。\r\n 有些属性不宜归属于任一实体类型，只说明实体之间联系的特性
局部模式分析过程
现有的教学\r\n管理系统
初步分析系统的对象
根据服务种类分析教师子模块
……
建立教师管理部分的ER图
其他局部模式
现有的教学\r\n管理系统
初步分析系统的对象
根据服务种类分析学生子模块
……
建立学籍管理部分的E-R图
局部ER图
其它局部模式
现有的教学\r\n管理系统
初步分析系统的对象
根据服务种类分析课程子模块
……
局部ER图
建立课程管理部分的E-R图
P
N
采用ER方法的数据库概念设计 ——设计全局 ER模式
属性冲突 ：如，重量单位有的用公斤，有的用克。 \r\n结构冲突 ：同一对象在不同应用中的不同抽象 ；同一实体在不同局部ER图中属性的个数或次序不同 ；实体之间的联系在不同的局部ER图中呈现不同的类型 \r\n命名冲突 ：属性名、实体名、联系名之间存在同名异义或异名同义冲突
采用ER方法的数据库概念设计 ——全局ER模式的优化
实体类型的合并\r\n1:1联系的两个实体类型 \r\n具有相同键的实体类型 \r\n冗余属性的消除 \r\n冗余联系的消除：利用规范化理论中函数依赖的概念消除冗余联系
1
例子：三个局部ER图\r\n合并成一个ER图的教学管理E-R图
教师
管理
1
1
ER图转换成关系模式集的规则
将每个实体类型转换成一个关系模式，实体的属性即为关系模式的属性，实体标识符即为关系模式的键\r\n二元联系类型的转换\r\n若实体间联系是1:1，可以在两个实体类型转换成的两个关系模式中任意一个关系模式的属性中加入另一个关系模式的键和联系类型的属性。 \r\n若实体间联系是1:N，则在N端实体类型转换成的关系模式中加入1端实体类型的键和联系类型的属性。 \r\n若实体间联系是M:N，则将联系类型也转换成关系模式，其属性为两端实体类型的键加上联系类型的属性，而键为两端实体键的组合 \r\n一元联系类型的转换:同二元联系 \r\n三元联系类型的转换 \r\n总是将三元联系类型转换成关系模式，其属性为三端实体类型的键加上联系类型的属性，而键为三端实体键的组合。
ER模型到关系模型的转换实例
ER模型到关系模型的转换实例
采用ER方法的逻辑设计步骤
例子：库存销售信息管理系统的 ER模型及转换
库存系统ER图
车间(车间号,车间名,主任名) \r\n产品(产品号，产品名，单价) \r\n仓位(仓位号，地址，主任名) \r\n客户(客户号，客户名，联系人，电话， \r\n地址，税号，账号)\r\n销售员(销售员号,姓名,性别,学历,业绩）
实体
入库（入库单号,入库量,入库日期,经手人, \r\n车间号,仓位号,产品名）\r\n出库（出库单号，出库量，出库日期，经手人，\r\n客户号，产品名，仓位号）\r\n订单（订单号，数量，折扣，总价，订单日期，\r\n产品号，客户号，销售员号） \r\n存储(仓位号,产品号,核对日期,核对员,存储量)
联系
1.4.5 案例分析：一个自顶向下的系统需求分析过程\r\n\r\n系统：《天津联通综合营业管理系统》\r\n业务范围：\r\n市话、 GSM、CDMA、CDMA1X、数据业务、165卡业务、193长途、互联网、寻呼、WVPN、PPC、112等 \r\n以市话为例，包括：\r\n服务业务：市话普通电话业务、CENTREX业务、模拟中继线业务、数字中继业务、ISDN业务\r\n营业受理：\r\n（1）一般申请包括：新装、拆机、移机、改号、改名、过户、停机保号、停机保号开机、增减新业务、改付费信息、合户分户、欠费停机、欠费停机开机、修改优惠信息、改帐目、改计费类别、改客户、改呼出密码，改催停标志、预存话费、改密码、改电话装机地址、改号簿、改号通知音。\r\n（2）特殊申请包括：单机改中继、单机改201/公用电话、单机改ISDN、单机改CENTREX、201/公用电话改单机、模拟中继线扩容、中继改单机、ISDN改单机、CENTREX改单机\r\n系统流程：以业务受理（处理）为主线、以业务服务为环节
《天津联通本地网营业系统》客户申请数据的流向图
信息入口
功能模块
根据不同的申请和情况,决定走不同的路线、经过不同的处理流程
业务处理子系统
外部接口子系统\r\n营业系统和帐务、1001、大客户、详单打印、小秘书等外部系统的接口 \r\nGSM和上海贝尔交换机接口\r\nCDMA和联创前端接口 \r\nCDMA1X和AAA、增值业务平台的接口 \r\nPPC、WVPN和上海贝尔接口\r\nWVPN和总部的接口
内部管理子系统\r\n添加用户模块\r\n删除用户模块\r\n用户属性修改（口令、权限等）模块 \r\n静态数据维护模块
外部界面\r\n用户人机界面\r\n打印报表界面
需求分析——第一步：\r\n根据业务处理流程和数据流，划分出三个主要的子系统\r\n子系统之间存在大量的内部联系
实例：市话业务处理主流程
需求分析第二步：对每一个功能\r\n分析业务流程——建立顶层IDEF0图
市话业务处理主流程\r\n\r\n建立与数据库的连接\r\n用户身份验证\r\n获取系统设置、初始化全局变量\r\n进入系统营业受理处理\r\n等待用户输入\r\n用户受理相关业务\r\n生成业务工单\r\n调度业务工单\r\n进行相应环节的处理\r\n送相关系统接口\r\n完成业务工单竣工
进入不同的处理子流程
定义：客户办理新装电话、中继线、专线等，并单独占有一个独立电话号码（或一个副号码、内部号码）或专线号码的，称为新装。\r\n流程：处理流程一般是由营业受理—配线配设备—外线施工—工单回笼形成一个闭环。\r\n处理：完成对用户信息的审核，信息录入，对申请所占用的产品进行收费。\r\n工位：涉及的具体工位有“营业综合受理工位”、“收费工位”。\r\n\r\n用户原始资料审核的内容\r\n（1）用户资信分析，以便于设备租赁、优惠政策享受的办理。\r\nA.在用用户的信用确认，B.新装用户的信用确认\r\n（2）原有电信客户办理装用其它电信产品或第二、三部原电信产品时，其原客户是否还存在欠费；是否处在停话、拆机、暂拆保号、割接保号状态；是否已换号、更名过户；户名地址是否相符、是否已办理移机或其它与新办业务互斥的业务。\r\n（3）申请各类业务用户的手续、证件是否齐备（集团用户的证明，个人用户的身份证件）。\r\n（4）办理涉及号码的变动业务时，应检查是否存在以此号码为引示号的在用用户\r\n（5）分期付款用户在费用付清之前应规定用户的业务处理限制。并在受理时作出提示。
相关业务子流程：市话新装业务需求描述
用户申请
实例：市话营业受理新装业务流程
市话新装受理处理
新装的内部处理流程\r\n根据工单所处的每个环节、状态进行相应的业务处理\r\n主要包括：\r\n机线资源配线配号\r\n程控机房交换实现\r\n测量外线外线施工\r\n业务工单送HLR\r\n业务工单送接口\r\n业务工单竣工\r\n业务工单根据系统流程调度的规则，到达不同的环节、状态。
机线资源的配线、配设备功能描述
配线配设备岗位在接收到相应的配线、配设备号的信息后，通过手工或自动地址匹配的方式，完成对该服务的线路配置情况以及设备配置情况，并且把这种配置情况写入到营业系统的相应的数据表中。\r\n信息流处理分析\r\n电话对应的设备号表（EL）\r\nMDF跳线表\r\n交接箱的配置表\r\n分线盒的配置表\r\n要有专门的功能，来管理对退单的重新配置。
案例小结
《天津联通综合营业系统》是一个基于业务流为主的系统\r\n业务：市话、G网、C网、长话、IP等等\r\n服务：初装、移机、改号、开通等等\r\n系统处理流程：\r\n选择业务\r\n选择服务\r\n进入相应的处理流程\r\n系统本身的处理\r\n送相应接口（交换机等立即处理）\r\n与其他系统的接口处理（帐务、大客户、总部认证等）\r\n人工处理（出工单）\r\n需求分析的方法与过程\r\n功能划分\r\n根据信息流划分子功能\r\n具体业务处理描述\r\n用户确认：功能/流程符合实际吗？处理满足要求吗？\r\nOK！需求分析完成。这是一个典型的传统需求分析的方法
手工作坊式开发\r\n功能大量重复 接口关系复杂 大型系统非常困难
案例小结
系统公用的模块和函数
系统规范的界面和接口
系统标准处理模块
业务逻辑模块
结构化的开发\r\n简化接口关系 划分合理的功能模块大型系统工作量巨大
面向对象的开发\r\n更简化的接口 更高的功能抽象 大型系统优势更明显