软件需求分析案例
软件工程案例分析
一、阅读下列系统需求陈述，回答问题1、问题2、问题3和问题4。
某银行准备开发一个网上信用卡管理系统CCMS，该系统的基本功能为：（1）信用卡申请。
非信用卡客户填写信用卡申请表，说明所要申请的信用卡类型及申请者的基本信息，提交CCMS登录。
如果信用卡申请被银行接受，客户会收到银行的确认函，并告知用户信用卡的有效期及信贷限额；否则银行会发送一封拒绝函给该客户。
客户收到确认函后，需再次登录CCMS ，用信用卡号和密码激活该信用卡。
激活操作结束后，CCMS将激活通知发送给客户，告知客户其信用卡是否被成功地激活。
（2）月报表生成。
在每个月第一天的零点，CCMS为每个信用卡客户创建一份月报表，对该客户上月的信用卡交易情况及交易额进行统计。
信用卡客户可以登录CCMS查看月报表，也可以要求CCMS提供打印出的月报表。
（3）信用卡客户信息管理。
信用卡客户的个人信息可以在 CCMS中进行在线的管理。
每个信用卡客户可以在线查询其个人信息。
（4）信用卡交易记录。
信用卡客户使用信息卡进行的每一笔交易都会记录在CCMS中。
（5）交易信息查询。
信用卡客户可以登录CCMS查询并核实其信用卡交易记录及交易额。
在系统的需求分析阶段，使用用例对系统需求建模。
表1—1和表1—2给出了其中两个用例的概要描述。
［问题1］）将表1—1和表1—2中的（1）~（10）填充完整。
［问题2］除了表1—1和表1—2给出的用例外，从上述系统陈述中还可以获取哪些由信用卡客户发起的用例？（给出用例名称即可）［问题3］用400字以内文字，简要说明用例获取的基本步骤。
［问题4］用例除了使用表1—1和表1—2所示的形式描述外，还可以使用UML的用例图来表示。
分别用50字以内文字，解释UML用例图中扩展用例和抽象用例的内涵。
二、阅读以下关于工作流系统性能分析的叙述，回答问题1、问题2和问题3。
某企业正在创建一个工作流管理系统，目前正处于过程定义阶段，即创建工作流模型阶段。
软件需求-案例分析
1、问题描述许多医院存在高峰期挂号排队时间长，就诊等待时间长，倒号现象频发的问题。
因此，构建一个网上预约挂号系统，通过推荐患者使用该系统进行出诊信息查询和医生预约，可以缓解就诊压力、节约患者的时间，并且可以在一定程度上保证预约者和就诊者一致，有利于提高医院的服务质量。
为了更好的设计并实现这一系统，对系统进行需求建模和分析是十分必要的。
2、情景描述的主要成分2.1、该系统所涉及的用户本系统的用户包含患者、医生以及管理员三类。
而且该三类用户各自的特征和所要面对的情景也是截然不同的。
对于患者来说，他们在年龄、计算机使用能力等方面存在较大差异，但面对的情景都一样，就是要预约挂号，挂号成功过后就诊。
对于医生来说，普遍具备较高的学历，在医疗方面具备专业知识，有一定的计算机使用能力。
所面对的情景有查看挂号信息，确定要就诊的病人。
对于管理员来说，他们负责对出诊信息进行管理，是医院工作的安排者，具备较强的计算机使用能力。
不同的用户，对系统的要求也不相同。
患者希望通过完成注册和登录后能够进行挂号预约，查询医生的出诊信息和个人预约信息，并且能够在规定的时间内完成挂号预约或者取消已有的预约；医生则希望能够在登录系统后可以查看病人的预约情况；而管理员希望可以修改出诊信息和调整预约挂号。
这些都是功能性的需求。
同时对于所有用户都希望该系统是易用的，而且能够对自己的信息起到保护即系统安全性的要求，还有比如说系统的性能比较高效，能够及时处理自己的预约申请。
当然开发系统的成本如果也能较低就更好了。
这些都是非功能需求。
2.2、情景描述的主要成分●目标和关键成功因素预约挂号情景的目标是“让患者能够及时的挂号，并能顺利的就诊”，而可能的子目标包括：患者能够注册账号，患者能够登录账号，患者能够查询预约记录，患者能够取消已有预约，患者能够查询出诊信息。
关键成功因素，要保证系统能够24小时正常稳定的运行，系统里的信息要是实时变化的，即可以预约的医生要和实际在值班的医生要匹配，不能出现挂上号了却没有医生就诊的情况。
软件需求分析案例
图书馆管理信息系统的2层数据流程图有： 图书馆管理信息系统的 层数据流程图有：图书 层数据流程图有 采编系统数据流程图、图书借阅系统数据流程图、 采编系统数据流程图、图书借阅系统数据流程图、 图书查询系统数据流程图、 图书查询系统数据流程图、图书预定系统数据流 程图、读者留言系统数据流程图、 程图、读者留言系统数据流程图、图书维护系统 数据流程图、 数据流程图、读者管理系统数据流程图和电子读 物系统数据流程图。 物系统数据流程图。
3
n
有指定的图书馆工作人员来帮助顾客像使用一般 书目索引一样使用基于电脑的工具。 书目索引一样使用基于电脑的工具。图书馆也必 须联网到其他的图书馆，以满足馆际互借的要求。 须联网到其他的图书馆，以满足馆际互借的要求。 这些相互连接的图书馆允许顾客可以直接访问它 们的馆藏。 们的馆藏。 图书馆工作人员的最后职责是获取和淘汰馆 藏图书。在获取新书的过程中， 藏图书。在获取新书的过程中，他们试图在满足 顾客的要求和达到广泛的收集之间取得平衡。 顾客的要求和达到广泛的收集之间取得平衡。当 图书的内容已经过时并且没有历史价值时， 图书的内容已经过时并且没有历史价值时，这本 图书将被淘汰。理想情况下，当一本书过时后， 图书将被淘汰。理想情况下，当一本书过时后， 它只有在一本内容更新的书在馆藏中代替它时才 会被淘汰。 会被淘汰。
19
n
n n n n n n
n
数据项组成： 借阅日期）＋ 数据项组成：OrderDate （借阅日期）＋ BookName（书名）＋ ）＋RederID（读者账号）＋ （书名）＋ （读者账号）＋ ReaderName（读者姓名）＋ ）＋O_Quantity（借阅 （读者姓名）＋ （ 数量） 数量） 数据流量： 数据流量：1000部/日 部日 高峰流量： 高峰流量：5000部/日 部日 数据流编号： 数据流编号：D03 数据流名称： 数据流名称：填写借阅记录 简述： 简述：填入借阅表的记录 数据流来源： 数据流来源：P2_13 检查合格的借阅图书信息录人 到借阅库中 数据流去向： 数据流去向：借阅库
软件安全需求分析
《软件安全需求分析》xx年xx月xx日CATALOGUE目录•软件安全需求概述•识别安全需求•分析安全需求•验证安全需求•管理安全需求•实践案例分析01软件安全需求概述软件安全需求是关于软件系统在面对潜在的威胁或攻击时，为确保系统的机密性、完整性和可用性而提出的一系列要求。
这些要求包括对系统进行安全防护、检测和响应的能力。
重要性随着信息技术的快速发展和广泛应用，软件系统面临着越来越多的安全威胁。
确保软件系统的安全性已经成为信息安全领域的重要任务之一。
软件安全需求分析是确保软件系统安全性的关键步骤之一，它能够识别潜在的安全威胁，提出相应的安全措施，降低或消除潜在的安全风险。
定义定义与重要性VS安全需求与功能需求的关系安全需求是功能需求的一部分安全需求是软件系统在功能方面的一种表现，它与功能需求密切相关。
一个安全的软件系统需要满足一系列的安全标准或规范，而这些标准或规范可以转化为具体的功能需求。
安全需求与功能需求的区别虽然安全需求与功能需求有密切的联系，但它们之间也存在一些区别。
功能需求关注的是系统应该做什么，而安全需求关注的是系统如何保护自己和用户的信息不受攻击或损害。
在软件开发过程中，需要将安全需求与功能需求结合起来考虑，以确保软件系统的安全性和可用性。
0102确定安全目标首先需要明确软件系统的安全目标，这些目标应该与系统的实际应用场景相关联。
例如，银行系统的安全目标可能是保护客户的账户信息和交易记录不被未经授权的访问或篡改。
识别潜在威胁根据确定的安全目标，需要识别出可能对系统造成威胁的各种因素。
这些威胁可能来自外部的攻击者、内部的恶意用户或系统的自身漏洞等分析安全需求针对每一种潜在的威胁，都需要分析相应的安全需求。
这些需求包括对威胁的检测能力、防护能力、响应能力等制定安全策略根据分析的安全需求，需要制定相应的安全策略。
这些策略包括对用户的身份认证、访问控制、数据加密、日志记录等验证与测试制定安全策略后，需要对其实施效果进行验证和测试。
《软件需求分析》课件
关系定义
定义实体之间的关系，如 关联、依赖、聚合等。
实体关系图绘制
使用图形化工具绘制实体 关系图，展示实体之间的 关联关系。
Part
04
需求规格说明
需求规格说明编写
确定需求来源
明确软件需求来自哪些方面，如用户、市场、技术等 ，确保全面覆盖。
编写规范统一
遵循统一的编写规范，确保需求规格说明的清晰、准 确和一致性。
需求分析的过程
需求调研
通过与用户沟通、调查问 1
卷、现场观察等方式，了 解用户需求和业务场景。
需求确认
4
将分析出来的需求与用户 进行确认，确保双方对需 求的理解一致。
需求分析
2
对收集到的需求进行整理
、分类、抽象，形成系统
需求。
需求评审
3 对分析出来的需求进行审
查和评估，确保需求的正 确性和完整性。
访谈技巧
注意倾听、引导和追问，以获得深入的需求 信息。
记录和分析
详细记录访谈内容，并进行分析，提取关键 需求。
问卷调查
设计问卷
根据软件的功能和目标，设计合理的问卷。
选择调查对象
确保调查对象的代表性和广泛性。
发布和收集问卷
通过适当的渠道发布问卷，并确保问卷的完整性和准确性。
数据分析
对收集到的数据进行统计分析，提取关键需求。
详细描述
社交网络平台用户数量庞大，用户交互频 繁，对系统的可用性和响应速度要求极高 。同时，由于社交网络平台的功能更新频 繁，需求变化较快，需求分析需要关注系 统的可扩展性和灵活性。此外，社交网络 平台还需要考虑用户隐私和数据安全等问 题。
THANKS
感谢您的观看
非功能需求定义
软件工程需求分析案例
11.假设你在一所职业高中工作，负责该校信息系统的建设与维护。
财务科长请你研究用学校拥有的微型计算机生成工资明细表和各种财务报表的可能性。
请详细描述你用结构化分析方法分析上述问题的过程。
答：通常，结构化分析过程包括问题定义、可行性研究和需求分析3个阶段。
下面分别叙述这3个阶段的分析过程。
（1）问题定义从何处着手解决财务科长提出的问呢？立即开始考虑实现工资支付系统的详细方案并动手编写程序，对技术人员无疑是很有吸引力的。
但是，在这样的早期阶段就考虑具体的技术问题，却很可能会是我们迷失前进的方向。
会计部门（用户）并没有要求在学校自己的计算机上实现工资支付系统，仅仅要求研究这样的可能性。
后者是和前者很不相同的问题，它实际上是问，这样做预期将获得的经济效益能超过开发这个系统的成本吗？换句话说，这样做值得吗？优秀的系统分析员还应该进一步考虑，用户面临的问题究竟是什么。
财务科长为什么想研究在自己的计算机上实现工资支付系统的可能性呢？询问财务科长后得知，该校一直由会计人工计算工资并编制财务报表，随着学校规模扩大工作量也越来越大。
目前每个月都需要两名会计紧张工作半个月才能完成，不仅效率低而且成本高。
今后学校规模将进一步扩大，人工计算的成本还会进一步提高。
因此，目标是寻找一种比较便宜的生成工资明细表和各种财务报表的办法，并不一定必须在学校自己的计算机上实现工资支付系统。
财务科长提出的要求，实际上并没有描述应该解决的问题，而是在建议一种解决问题的方案。
这种解决方案可能是一个好办法，分析员当然应该认真研究它，但是也还应该考虑其他可能的解决方案，以便选出最好的方案。
良好的问题定义应该明确地描述实际问题，而不是隐含的描述解决问题的方案。
分析员应该考虑的另一个关键问题，是预期的项目规模。
为了改进工资支付系统最多可以花多少钱？虽然没人明确提出来，但是肯定会有某个限度。
应该考虑下述3个基本数字：目前计算工资所花费的成本，新系统的开发成本和运行费用。
(完整word版)软件需求规格说明书(案例)
软件开发方向“成绩管理系统"软件需求规约安博教育集团二零零八年十月修订历史记录目录1 引言 (5)1。
1 目的 (5)1。
2 文档格式 (5)1.3 预期的读者和阅读建议 (5)1.4 范围 (6)1.5 术语 (7)1。
6 参考文献 (7)2 系统概述 (7)2。
1 概述 (7)2。
2 功能 (7)2.3 运行环境 (8)2.4 假设与依赖 (9)3 系统特性 (9)3。
1 系统角色 (9)3.2 学生管理 (11)3.2。
1 增加学生信息 (11)3。
2。
2 修改学生信息 (11)3。
2.3 删除学生信息 (11)3.2.4 导入学生信息 (11)3。
3 教师管理 (12)3.3.1 增加教师信息 (12)3。
3.2 修改教师信息 (12)3.3。
3 删除教师信息 (12)3。
3。
4 导入教师信息 (12)3。
4 课程管理 (13)3.4.1 增加课程基本信息 (13)3。
4。
2 修改课程基本信息 (13)3。
4。
3 删除课程基本信息 (13)3。
4。
4 维护课程学生信息 (13)3。
5 成绩查询 (14)3。
5.1 学生查询成绩 (14)3.5。
2 教师查询成绩 (14)3。
6 成绩分析与统计 (14)3。
6。
1 考试成绩表 (14)3.6。
2 班级各科平均成绩表 (14)3.6。
3 年级成绩排名表 (15)3。
7 系统维护 (15)3。
7.1 数据字典维护 (15)4 非功能性需求 (15)4。
1 性能需求 (15)4。
2 安全性需求 (15)4。
3 可用性需求 (16)4.4 用户文档 (17)4。
5 其它需求 (17)5 外部接口需求 (17)5.1 用户接口 (17)5.2 硬件接口 (17)5.3 软件接口 (18)5.4 通信接口 (18)1 引言1.1 目的该文档首先给出了整个系统的整体网络结构和功能结构的概貌，试图从总体架构上给出整个系统的轮廓，然后又对功能需求、性能需求和其它非功能性需求进行了详细的描述。
软件需求变更管理案例分析及解决方案
软件需求变更管理案例分析及解决方案典型场景：最近比较烦，烦客户！我们现在正在给XX做一个电子政务项目，其中有一项功能是网上婚姻申请登记功能。
因为前一段取消了强制性体检这个环节，所以我们的工作流程也相应的变更。
没想到客户从中得到启发：我们的许多工作流程做好后改动的可能性很大，干脆给我们做成可定制的功能，我们提一个最大的功能集合，你们做好了我们自己就可以随需而变，嗯，这样好！可是对项目组来说这可是个灾难啊！因为可定制的功能往往意味着工作量的倍增！分析：先说说大家对于这种现象的应对方法吧。
最典型的是通过与客户的沟通来解决问题。
怎么样沟通呢？因为尤其是对于软件项目的合同很难在签订之初就能够精确定义的每项功能，所以靠合同是帮不上忙的。
我和许多IT公司的老总们作交流，大家往往只有苦笑：有什么办法呀，客户着急了就是一句潜台词：做不做，不想做滚蛋！想做的公司多着呢。
所以你看合同是没用的，那怎么办呢？通常都是通过感情联络争取客户的同情。
就像上面的场景中谈到的一样，明明是不合理的要求，可是客户也会狡辩呀，“凭什么不给我们做，这可是合同范围内的工作！”。
因为原来只说要实现工作流，而没有谈到定制的工作流算不算。
问题出来了，看看怎么办吧。
当然了，如果现在遇到类似的问题，您的组织都可以举重若轻的化解，那您就不用往下看了。
我们常听到一句话就是“合情合理”，大家说这有什么好希奇的呀，老生常谈！不过这句话在软件项目的变更管理中却有独特的表现形式。
从感情上与客户去沟通很重要，但是您注意到它只做了一半工作，还有一半工作需要去讲理。
大家会反驳我说：讲什么理！我们的客户就是上帝，让你做你就做！哪儿那么多废话呀你。
我注意到一个社会现象：客户方的直接项目负责人从年龄上来看往往有年轻化的趋势——三四十岁居多。
这些人有什么特点呢？首先从教育程度上讲他们往往都接受过正规教育，所以还比较讲理——或者是因为现在职位还不够高（开玩笑）？其次这些人是真正希望在工作上出成绩的。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
业务主管：对于业务人员提出的业务系统问题和 EMAIL 建立问题，需要由 业务主管来审核。业务主管被授权审核一类或者多类问题。
3
软件学院教学实践案例
IT 主管：负责审核本 IT 部门报给其他 IT 部门的问题。并对问题单的处理进 行管理。
动作执行者： 问题提交人员
状态来源：已受理
发生的动作 通过确认
约束条件 状态流向 操作提醒. 已解决关闭 无.
未通过确认，驳回给问题 处理人员
关闭
已受理
问题处理人员.
信息反馈 问题处理人员、选择链条上的所 有下级 IT 部门、问题提交人员 无
描述：对于一些无意义的问题直接关闭掉，问题终结。
状态来源：请求关闭、待分配
动作执行者：各级 IT 部门的问题分配人员
状态来源：未提交、待审核、审核中（来至下不同级别的 IT 部门）、已受理
（来至不同级别的 IT 部门）
发生的动作
约束条件 状态流向
操作提醒.
信息反馈
关闭
关闭
无.
问题提交人员，可选择相关人员
未解决关闭
未解决关闭
无.
问题提交人员，可选择相关人员
指派
已受理
问题处理人员
分公司系统管理员：负责 IT 问题管理和知识管理系统的管理工作，主要负 责分公司一级公司用户角色的指定。组织机构的管理。
问题提交人员：问题提交人员是指提交业务系统问题、网络问题、EMAIL 问题和 EMAIL 建立问题的人员。根据规定，问题提交人员只能提交指定类别的 问题。
问题分配人员：问题分配人员是 IT 部门负责问题分配的角色，他/她将所有 的问题分配给相关的问题处理人员。问题分配人员被授权分配一类或者多类问 题。
状态来源：未通过审核
配置内容：
提交部门与问题单的对应关系
问题单类型、提交部门和问题处理部门的对应关系
动作
约束条件
状态流向
操作提醒.
信息反馈
修改
问题单未提交
无.
无
删除
问题单未提交
提交审核 提交分配
非 IT 部门提出的业系统问题。 邮件帐号建立 一般邮件问题 网络问题 IT 部门提出的业务系统问题
提交审核
1．问题单类型、问题处理部门、处理规则的对应关系
发生的动作 通过审核 未通过审核
约束条件 状态流向 其他 IT 部门的‘待分配’ 已受理
操作提醒.
信息反馈
上一级 IT 部门问题分配 问题处理人员
人员.
问题处理人员.
无
请求关闭
描述：问题处理人员对于一些无意义的问题和不能解决的问题请求问题分配
人员关闭掉。
1 概述………………………………………………………………………………2 2 系统边界与角色…………………………………………………………………3 3.业务流程分析…………………………………………………………………….4
（1）问题单处理流程描述..................................................................................4 （2）问题流程分析..............................................................................................5 8.点评方式 .........................................................9
知识库管理员：知识库管理员负责知识库结构的维护，和维护知识库的用户 角色。
知识库审核人员: 负责对知识的申请进行审核，并分类。 知识库浏览者：查看和查找知识库的内容（在授权范围内） 知识提交人员：IT 部门人员可以提交自己的知识，报知识库审核人员。
3.业务流程分析
（1）问题单处理流程描述
邮件帐号问题 支公司和分公司的邮件帐号增加 分公司 IT 部门提出Æ经分公司分管老总确认Æ总公司网络处 总公司人事部门提出Æ经人事经理确认Æ总公司网络处 北分公司人事部门提出Æ经人事经理确认Æ北分公司网络处 办公应用问题 任何部门可以提出，不需要任何审核，流程等同于业务类问题。 网络故障问题 网络故障问题由 IT 部门提出，不需要审核，流程等同于业务类问题。 业务系统问题 问题单流向：支公司、分公司业务部门（也可以分公司电脑部直接提出）――》 分公司电脑室――》总公司系统维护处――软件开发处
（2）问题流程分析
经过对现有问题单处理流程的分析，并考虑问题单处理流程的规范化和未来 新的类型问题单的处理流程，将问题单处理流程总结为以问题单为核心的有限状 态转移的形式，这种问题处理的流程不仅能够满足现有多种不同类型的问题单的 处理，而且能够适应新类型的问题单的处理。
需要修改
修改 未提交
提交
删除
[需要审核[]不需要审核]
提交审核 待分配
无.
无
部门负责人.
无
IT 部门的问题分 无
配人员.
描述：对于已经提交的问题单，如果跨越部门需要部门负责人审核。
动作执行者：提出者的部门负责人。如果为建立邮件帐号问题，审核人员为
分公司分管老总（为分公司，支公司人员建立邮件帐号）、和总公司人力资源部
（为总公司人员建立邮件帐号）
状态来源：未提交
动作执行者：总公司分公司支公司的任何部门（包括中心支公司业务部门、
支公司电脑室、分公司业务部门、分公司电脑室、总公司业务部门、总公司信息
技术部系统维护处、总公司信息技术部软件开发处）
业务系统问题任何部门都可以提出
一般邮件问题由任何部门提出
网络故障问题由 IT 部门提出
邮件帐号建立由分公司 IT 部门提出,总部由人事部提出,支公司不会提出
信息反馈 无
处理 回复给问题提交人员
已受理 需确认
无.
无
问题提交人员 无
请求关闭 直接已解决关闭
请求关闭 已解决关闭
问题分配人员. 无.
无 可选择链条上的所有 下级 IT 部门、问题提 交人员
升级审核（在其他 IT 部门 业务系统问题
提交前发生的动作）
邮件帐号建立
审核中
部门负责人.
无
一般邮件问题 将问题升级到其他 IT 部门
软件学院教学实践案例
如上图所示,Windows AD 系统为 IT 问题管理与知识管理系统提供用户认证 机制，IT 问题管理与知识管理系统为第三方系统提供问题自动录入接口和问题 状态查询接口。系统中的角色包括:
系统管理员：负责 IT 问题管理和知识管理系统的管理工作，主要负责总公 司用户角色的指定。组织机构的管理。
动作执行者：问题分配人员
状态来源：已受理
发生的动作
约束条件
状态流向
操作提醒
.信息反馈
驳回关闭请求
已受理
问题处理人员. 无
关闭
已解决关闭 无.
问题处理人员、问题提交人员
未解决关闭
未解决关闭 无.
问题处理人员、问题提交人员
需确认
描述：问题处理人员处理问题之后需要提交给问题提交人员，确认问题是否
已经得到最后的解决。
无
已受理
描述： 问题处理人员接收到相关部门提交的问题单，并且对问题单进行处
理。
动作执行者：问题处理人员（IT 部门人员 ） 状态来源：待分配、需确认、审核中、请求关闭
配置内容：
1．问题单类型、问题处理部门、处理规则的对应关系
发生的动作 指派
约束条件 同一部门问题 处理人员
状态流向 已受理
操作提醒. 问题处理人员.
未解决关闭
描述：问题终结。
状态来源：请求关闭、待分配
8
软件学院教学实践案例
已解决关闭 描述： 问题的答复已经经过问题提交人确认，问题终结。 状态来源：需确认、已受理
8.点评方式
教师专门安排时间对案例的完成情况进行统计、分析、总结、点评。
9
软件需求分析与设计实践案例二
东北大学软件学院
软件学院教学实践案例
目录
1.案例名称 .........................................................2 2.案例目标 .........................................................2 3.适用课程 .........................................................2 4.适用阶段 .........................................................2 5.预备知识 .........................................................2 6.能力目标 .........................................................2 7.案例内容 ...................................................速发展及机构网络布局的全国化，公司的运营维护管理信息
化应用需求日益增长。目前，某公司总部及其 29 家分公司和 78 家中心支公司的 业务系统、邮件系统和 AD 等信息系统的运营维护依然使用电话、传真和邮件 等方式，维护人员少、任务重、效率低，非常不便于对运营中的问题进行有效收 集和管理。没有自动化的系统，很难对系统中经常出现的问题进行分析、统计， 从而做出有效和正确的规划和相应的解决办法；同时也非常不利于维护人员快速 有效解决问题。并对维护中问题的解决办法进行知识的积累，已形成丰富、系统 的知识库，为新的维护人员或其他分公司维护人员提供宝贵的经验和知识。