软件系统需求分析案例

软件系统需求分析案例（共8篇）

篇1：软件系统需求分析案例

模拟商场关系系统需求分析

小品：模拟商场关系系统需求分析

小品角色：

主角：商场经理，系统分析员

配角：商场秘书，分析员助手

小品断片台词：（可以进行适当增删）

场景A

商场经理：我们建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部－门店的连锁经营模式。通过通讯手段门店自动订货，供应商自动结算，卖场通过条码扫描实现销售，管理人员能够随时查询门店商品销售和库存情况。

系统分析员：我已经明白这个项目的大体结构框架，这个对于我们来说是非常重要的，但在制定计划之前，我们必须收集一些需求。

商场经理：（作惊奇状）我刚才不是告诉你我们的需求了吗？

系统分析员：实际上，你刚才跟我说的只是整个项目的概念和目标，真正开发这个项目，我还需要跟真正将要使用这个系统的业务人员进行讨论，需要了解和掌握使用系统的业务人员的工作业务流程和每个岗位、每个环节的职责，……

（商场秘书出现，打断谈话，突出经理很忙）

商场经理：他们都很忙的，你们有没有类似的现有的系统可以参照一下，差不多就可以了！系统分析员：……（欲言）

商场经理：（电话响）我真的很忙，请你马上开始开发，随时将你们的进展情况告诉我 场景B

分析员助手：（电话）经理你好，我们想约一下您进行系统需求分析的调查，请问您什么时候方便？

商场经理：什么，我上次不是跟你们说过叫你们开始开发了吗？还没有开始的啊？我真的没有时间啊，你们马上开始吧，就这样！（挂机）

（系统分析员将一个超市的管理系统进行了简单修改送给商场使用）

场景C

商场秘书：经理，XX店说有顾客退货，那个系统那里办理不了，还有……

商场经理：这个小王怎么搞得，作个这样的系统给我们，真是的搞得乱七八糟的！

篇2：软件系统需求分析案例

许多医院存在高峰期挂号排队时间长，就诊等待时间长，倒号现象频发的问题。因此，构建一个网上预约挂号系统，通过推荐患者使用该系统进行出诊信息查询和医生预约，可以缓解就诊压力、节约患者的时间，并且可以在一定程度上保证预约者和就诊者一致，有利于提高医院的服务质量。为了更好的设计并实现这一系统，对系统进行需求建模和分析是十分必要的。

2、情景描述的主要成分

2.1、该系统所涉及的用户

本系统的用户包含患者、医生以及管理员三类。而且该三类用户各自的特征和所要面对的情景也是截然不同的。

对于患者来说，他们在年龄、计算机使用能力等方面存在较大差异，但面对的情景都一样，就是要预约挂号，挂号成功过后就诊。

对于医生来说，普遍具备较高的学历，在医疗方面具备专业知识，有一定的计算机使用能力。所面对的情景有查看挂号信息，确定要就诊的病人。

对于管理员来说，他们负责对出诊信息进行管理，是医院工作的安排者，具备较强的计算机使用能力。

不同的用户，对系统的要求也不相同。患者希望通过完成注册和登录后能够进行挂号预约，查询医生的出诊信息和个人预约信息，并且能够在规定的时间内完成挂号预约或者取消已有的预约；医生则希望能够在登录系统后可以查看病人的预约情况；而管理员希望可以修改出诊信息和调整预约挂号。这些都是功能性的需求。

同时对于所有用户都希望该系统是易用的，而且能够对自己的信息起到保护即系统安全性的要求，还有比如说系统的性能比较高效，能够及时处理自己的预约申请。当然开发系统的成本如果也能较低就更好了。这些都是非功能需求。

2.2、情景描述的主要成分

 目标和关键成功因素

预约挂号情景的目标是“让患者能够及时的挂号，并能顺利的就诊”，而可能的子目标包括：患者能够注册账号，患者能够登录账号，患者能够查询预约记录，患者能够取消已有预约，患者能够查询出诊信息。关键成功因素，要保证系统能够24小时正常稳定的运行，系统里的信息要是实时变化的，即可以预约的医生要和实际在值班的医生要匹配，不能出现挂上号了却没有医生就诊的情况。

 物理上下文和逻辑上下文 物理上下文：医院用于挂号的计算机可以正常的使用，情景中的可以被预约的医生应该是在医院值班的；而对于患者可以选择在医院进行预约，也可选择在家中进行预约，只要在预约时间内能到达医院就可。逻辑上下文：事件发生的条件是患者在系统中进行了预约，然后管理员会根据现有的资源（可以预约的医生）对预约进行处理，如果同意，下一步就是医生就诊；如果没有可以预约的医生或合适的时间，患者的预约就不成功，患者需要重新选择医生或时间进行预约。

 组成情景的主要事件和活动 主要事件：患者预约挂号，管理员对预约挂号的处理，医生就诊。主要活动：患者注册、登录系统，患者在系统中查询可以预约的医生和时间，患者取消已有预约，患者进行就诊；管理员接受或拒绝预约，管理员分配医生；医生查询预约信息。

 涉及的执行者和其他参与者

执行者：医院的医生，预约挂号系统的管理员。其他参与者：医院的相关人员，比如患者，前台咨询员等。

 要使用的信息和资源 要使用的信息和资源包括，可以预约的医生数量，所在科室等，医院中的设备，病房等。 要考虑的约束条件和要使用的规则 约束条件：同一医生同一时间段内只能接受一名患者的预约，根据医疗设备的属性决定是否要排他性的使用。

3、情景需求分析的步骤

需求规格说明输入过程需求目标列表1.目标分析系统模型目标,目的使用情景用户问题实例2.输入事件分析初始系统模型用户,环境事件情景脚本4.输出需求分析3.刻画系统输出情景结构模型系统输出类型信息需求5.社会影响分析Agent目标6.涉众分析需求规格说明

3.1 目标分析

在第2部分情景描述的主要成分中已经对目标进行了分析，即：预约挂号情景的目标是“让患者能够及时的挂号，并能顺利的就诊”，而可能的子目标包括：患者能够注册账号，患者能够登录账号，患者能够查询预约记录，患者能够取消已有预约，患者能够查询出诊信息。3.2 输入事件分析

对于该系统的输入事件可能会包括如下情况：初始使用该系统的用户需要先注册，而对于已经注册的用户在使用系统预约挂号时首先要登录系统。这是最基本的两个输入事件。3.3 刻画系统输出

对于系统输出我们要考虑系统输出的形式，比如消息显示，对话框等形式。不如用户在登录系统是输入的用户名和密码不匹配的时候要给出对应的提示信息，比如用户名未注册或密码不对等。在提交预约挂号申请后系统也应给出预约成功与否的提示。3.4输出需求分析

对于输出需求要根据用户的输入给出对应的输出。比如用户输入查询请求，那么系统应该能够给出详细的信息。系统只给出对应的输出还不够，同时要考虑输出的信息是否合适。比如用户要查询眼科医生的资料，系统的输出就应该只是眼科医生的信息，而没有必要把所有医生的信息都输出。3.5 社会影响分析

在进行社会影响分析时要同时考虑到积极和消极两个方面的问题。系统是否可以提高效率，减少人员的工作量。同时也要考虑过多的自动化是否会削弱人对整个系统的意识，导致人对意外处理的能力降低，比如系统临时出现问题，是否有一套应急措施使医院日常工作能够正常的进行。

4、需求说明文档

基于之前构建的模型，并参照IEEE 830-1998标准模板，撰写的系统需求说明文档如下。

4.1 引言

引言部分将对本文档的编写目的、系统的开发目的、名词定义以及参考资料进行说明，并对文档的后续内容进行概述。4.1.1 编写目的

网上预约挂号系统是基于Web开发技术完成的网站。为了更好的设计并实现这一系统，对系统进行需求建模和分析是十分必要的。因此，基于之前构建的各类模型，撰写系统的需求说明文档，并将其作为后续项目设计、项目开发和项目测试的指导。

本文档连同之前构建的模型，可用来与客户进一步明确需求，同时可供项目经理、设计人员、开发人员参考。4.1.2 系统目的

许多医院存在高峰期挂号排队时间长，就诊等待时间长，倒号现象频发的问题。因此，构建一个网上预约挂号系统，通过推荐患者使用该系统进行出诊信息查询和医生预约，可以缓解就诊压力、节约患者的时间，并且可以在一定程度上保证预约者和就诊者一致，有利于提高医院的服务质量。4.1.3 名词定义  患者预约系统

网上预约挂号系统的子系统，主要用于为患者提供预约挂号、信息查询等功能。 医生工作查询系统

网上预约挂号系统的子系统，主要用于为医生提供各时段预约患者的信息。 医务管理系统

网上预约挂号系统的子系统，主要用于为管理员提供出诊信息修改、预约挂号调整等功能。 账号控制系统

网上预约挂号系统的子系统，主要用于用户账号的注册及登录控制。 安全保障系统

网上预约挂号系统的子系统，主要用于保障系统的程序、网络及数据库安全。4.1.4 参考资料

[1]Objectiver: A KAOS tutorial.Respect-It(2004)[2]吴双兵,刘伟.网上预约挂号系统设计与实现[J].医学信息学杂志, 2015, 36(1):36-39.4.1.5 文档概述

需求说明文档主要分为三个部分。本节属于引言部分，主要用于对文档本身进行定义和描述。文档的第二部分为系统的整体描述，包括系统的预期目标、限制条件以及用户的需求、特征。文档的第三部分是需求说明，包含对系统需求的明确定义。

4.2 整体描述

本节将对系统预期、用户需求、用户特征、条件与限制、假定与依赖以及需求分配进行说明。

4.2.1 系统预期

为了方便用户在不需安装任何软件的情况下使用系统，本系统整体采用B/S结构，用户可以通过浏览器对其进行访问。4.2.2 用户需求

参照之前完成的目标模型，对用户的需求进行整理和定义。由于系统整体较为复杂，因此本小节只包含已构建目标模型的功能性需求和非功能性需求。 功能性需求

1.患者进行预约选择

为了实现患者进行预约选择的目标，系统应完成的需求如下。（1）系统拥有患者预约页面以及预约按钮：

系统的预约页面可以显示未来1至3天的出诊医生及其所有可被预约的出诊时段。其中，尚未被预约的时段拥有预约按钮；已被预约的时段无法被其他患者预约，因此无预约按钮。（2）系统接收到预约请求：

当患者点击预约按钮，系统可以接收到预约请求。（3）患者被告知预约选择结果：

系统可以对患者是否预约成功进行判定，如果成功则跳转至信息确认页面，否则弹出对话框给予患者相应提示。2.患者确认预约信息

为了实现患者确认预约信息的目标，系统应完成的需求如下。（1）系统拥有预约信息确认页面以及预约提交按钮：

系统的预约信息确认页面会显示预约的医生和时段，患者的个人信息，以及预约提交按钮，患者可以在提交预约前核对这些信息。（2）系统接收到预约提交请求：

当患者点击提交按钮，系统可以接收到预约提交请求。（3）患者被告知预约提交结果：

系统可以对预约是否提交成功进行判定，并弹出对话框给予患者相应提示。 非功能性需求 1.安全的系统

为了保证预约挂号系统的安全性，系统应完成的需求如下。（1）用户程序安全：

系统应明确区分不同类别用户的权限。并且在用户登录时，输入的密码不可见、不可复制。（2）系统网络安全：

系统应采取安全的网络传输协议，网络数据在被传输前应进行加密。（3）数据库安全：

数据库中存储的数据应具备完整性，且密码应在加密后被存储到数据库中。此外，数据库中的数据应该可以被备份和恢复。2.低成本的系统 为了保证预约挂号系统的低成本，系统应完成的需求如下。（1）系统开发成本低：

开发团队应具备合理的项目管理，且在开发前应尽可能明确系统的需求。（2）系统运营成本低：

系统在运行过程中，应该尽可能少的占用资源。（3）系统维护成本低：

系统应该健壮可靠，出现问题后应该易于修复，且系统的功能应该易于扩展。考虑到系统健壮可靠与系统开发成本低存在一定的冲突，因此需要进行一定的权衡。4.2.3 用户特征

本系统的用户包含患者、医生以及管理员三类，其特征如下。 患者

个体间在年龄、计算机使用能力等方面存在较大差异。 医生

普遍具备较高的学历，在医疗方面具备专业知识，有一定的计算机使用能力。 管理员

负责对出诊信息进行管理，是医院工作的安排者，具备较强的计算机使用能力。4.2.4 条件与限制

为了保证系统的可移植性和可扩展性，本系统应使用Java语言进行开发。4.2.5 假定与依赖

本系统假定提供的大、中、小三种字体大小可以满足不同患者的需求，并且患者可以在系统的引导和提示下正常使用系统。4.2.6 需求分配

由于文档中并未列出系统的全部需求，因此无法对所有需求进行优先级排序。但已经列出的均为系统较为核心的功能性需求和非功能性需求，应具有高优先级。

4.3 需求说明

需求说明部分将参照之前完成的模型，对系统结构、对象模型以及操作过程模型进行详细描述。

4.3.1 系统结构

本部分将主要参照图 3-1所示的责任模型，根据主体对需求进行划分。考虑到系统较为复杂，因此只列出主体“患者预约系统”的相关需求。 患者预约系统

系统拥有患者预约页面以及预约按钮。

系统接收到预约请求。

患者被告知预约选择结果。

系统拥有预约信息确认页面及预约提交按钮。

系统接收到预约提交请求。

患者被告知预约提交的结果。4.3.2 对象模型

本部分将主要对图 4-1所示的对象模型的结构进行解释。

网上预约挂号系统可以被详细划分为患者预约系统、医生工作查询系统、医务管理系统、账号控制系统、安全保障系统等五个子系统。患者预约系统、医生工作查询系统、医务管理系统的使用者分别为患者、医生和管理员，这些用户通过系统提供的页面与系统进行交互。

对象模型中所涉及的名词在4.1.3小节中有具体解释。4.3.3 操作过程模型

本部分将主要对图 5-1，图 5-3和图 5-4所示的操作过程模型进行说明，并以表格的形式列出各操作过程的参与主体及对应需求。 患者进行预约选择

患者点击预约按钮后，患者预约系统会收到患者的预约请求，并触发预约验证操作，得到预约验证结果。接下来，患者预约系统会以得出的预约结果为基础，进行预约结果判定，进而执行页面跳转或消息框弹出操作。 患者确认预约信息

患者点击提交按钮后，患者预约系统会收到患者的预约提交请求，并触发预约提交操作。接下来，患者预约系统会根据提交结果弹出包含相应信息的提示框。

以上部分涉及到的操作过程及与之对应的主体、需求如下表所示。

以上部分涉及到的操作过程及与之对应的主体、需求如表 4-1所示。

操作 预约验证 参与主体

对应需求

患者预约系统 系统接收到预约请求，患者被告知预约选择结果

篇3：软件系统需求分析案例

《软件需求工程》是软件工程专业的一门专业核心课程, 该课程主要讲述软件需求工程的过程、任务、常用的分析模型与建模技术知识。通过本课程的学习, 使学生能够全面深入了解和掌握需求领域的各项方法与技术, 具备作为软件需求工程师所需的专业能力[1]。由于《软件需求工程》是一门理论性很强的课程, 课程重点在于阐述一般原理和方法, 对于如何基于这些原理指导实践阐述的不够。因此, 采用传统的偏重于课堂讲授的教学模式进行授课, 很多学生感到内容抽象枯燥, 常常是似懂非懂, 甚至觉得本课程没什么实用价值, 失去了学习的兴趣, 直接影响了课程的教育质量和教学效果, 因此需要对软件需求工程课程教学模式进行改革。

案例教学法是以案例分析为主线, 通过案例设置教学问题, 并提出各种解决问题的方案, 以解决问题来激发学生的求知欲, 调动学生积极性, 使学生主动地学习, 形成科学的教育观念的一种教学方法[2]。该方法的主要目的是为了培养和提高学生学习知识的能力, 其主要以个人或小组合作的方式进行, 学生通过亲身实践获得实践经验, 是实现理论联系实际的主要途径。

为了改善教学效果, 让学生理解并感受到软件需求工程理论从实践中来又到实践中去的思想, 更好地掌握软件需求理论, 本文尝试采用案例教学法进行《软件需求工程》教学模式研究。

1 基于案例的《软件需求工程》课程教学模式

基于案例的教学模式是对软件需求各方面的技术, 用案例分层次地进行教学, 根据不同水平、不同层次学生的特点, 结合理论进行需求获取、需求分析、规格说明、需求验证、需求管理等需求开发过程学习, 体现需求工程的原理和实践。通过采用基于案例的教学模式培养学生的创新能力和实践能力, 使学生具有扎实的基础、合理的知识结构、较强的需求开发和需求管理能力。教学方法的实施分理论教学和实践教学两个方面。

1.1 理论教学

采用分步递进的案例分析方法, 该方法主要分为以下3步:

(1) 教师先系统讲授需求工程每一步需要的理论知识 (方法和技术) , 在讲理论知识时针对比较抽象的问题结合实践经验穿插一些案例, 但案例一般不宜过长, 不适合论证复杂的综合性问题。例如:在讲到需求获取技术时, 会讲到需求获取是需求工程中最重要的过程, 获取用户需求时会遇到各种各样的困难, 只有解决了困难才能获取完整的用户需求。对怎样解决困难, 学生会很迷惑, 这时就应该通过案例说明, 可以举这样一个案例:假如要给一个企业开发一个财务管理系统, 该企业的会计年龄较大, 缺乏计算机知识, 不想使用财务软件管理账务, 因此对需求信息的收集工作采取消极态度, 不愿与需求分析人员交谈, 这就是进行需求获取时可能会遇到的困难。解决方法:1先给老会计讲解使用财务软件管理账务的优点;2演示操作计算机的简单过程;3演示已有的财务软件, 主要演示处理数据的速度。通过教师讲解案例, 进一步阐述相关理论的现实应用及意义, 加深学生对该理论的理解和认识。

(2) 理论知识讲授结束后, 教师拿出学生比较熟悉的案例, 如:学籍管理系统、图书管理系统等。根据讲授的理论知识, 系统地应用解决实际问题。例如, 需求获取章节讲授结束后, 通过一个完整的案例来分析需求获取的整个过程:确定需求开发计划、确定项目的目标和范围、确定调查对象、获取需求信息时应采用的方法[1]。在获取需求信息时, 可以让学生扮演不同的获取对象给需求分析人员提供软件需求。通过教师分析案例让学生学习如何应用理论知识解决实际问题, 进一步加深对理论知识的理解。

(3) 在学生充分掌握了相关理论知识之后进行此步骤。例如, 教师在讲完“软件需求获取、需求分析、规格说明、需求验证”知识点后, 学生选择一个案例, 分组练习以加深对理论知识的应用。每组由4~6名学生组成, 每组学生担当不同的角色。这种案例一般是一个完整的软件项目, 需要用较长的时间分析。分析过程中要求学生亲自获取相关信息, 以培养他们获取信息、发现问题、解决问题的能力, 加强学生实际动手操作的能力。案例的具体内容安排由学生自己决定, 教师只给出指导性意见。案例实施时, 首先将学生分成若干个小组, 组长在教师的指导下, 确立案例分析方案。要求运用软件需求工程的理论和方法, 按照需求过程规范分阶段实施, 各小组应独立完成项目, 每个阶段都要有成果;接下来, 小组成员向全体学生讲解案例, 讲解结束后其它小组就此案例进行讨论, 共同研究需求分析过程;最后教师评分总结, 并要求该小组写出案例分析的相关文档。

1.2 实践教学

实践教学要注重学生的主动参与, 培养学生的实际动手能力和团队协作能力[3]。实践题目主要选择学生比较熟悉的软件系统, 内容要尽可能结合工程技术实际。在实践过程中, 学生进行分组, 每组5~6名学生, 每组选择不同的实验题目, 严格按照需求工程过程完成, 并编写过程材料。实践教学中采用分阶段的案例教学法, 分为需求获取、需求分析、规格说明和需求验证4个阶段, 每一阶段教师要制定具体实施要求[4]:1 需求获取阶段:要求先制定需求获取计划, 组长给成员分配任务, 并到相应的单位进行调研, 获取需求信息。学生在教师的指导下, 整理获取的信息, 并对信息进行分类, 撰写需求文档;2 分析阶段:要求小组成员对获得的用户需求信息进行分析和综合, 对于错误和不确定的需求, 小组相关成员要再次进行调研, 找相应用户获取完整、正确的需求。采用一种建模技术建立系统的逻辑模型, 建模时对组内成员要进行分工协作, 例如:学生的实践题目是信息管理系统, 应该采用结构化的需求分析技术, 用到的建模技术主要是分层的数据流图, 可要求1名学生画顶层的数据流图, 2名学生画中间层数据流图, 2~3名学生画底层的数据流图;3规格说明阶段:要求学生以文档的形式给出在需求获取阶段和需求分析阶段所获得的所有用户需求和需求模型, 即规范的需求规格说明书, 说明书采用IEEE标准830-1998 模板, 描述语言采用自然语言, 最后需求规格说明书要打印提交;4验证阶段:要求学生采用正式评审的方式进行, 本组部分成员和其它小组的部分成员组成评审会, 并扮演不同的角色, 组长扮演评审会的主持人, 组内成员扮演作者和记录员, 其它组的组长扮演评审专家。实践结束后, 教师要对每组学生的实践成果进行点评, 并给出相应的成绩, 以激发学生的学习积极性。

2 结语

《软件需求工程》课程是软件工程专业的重要核心课程, 对该课程进行教学模式改革符合课程建设的要求[5]。案例教学法作为一种启发式教学方法, 是对传统教学法的改革。经过近两年的基于案例的软件需求工程课程教学模式的实施, 证明该方法能寓理论于实际, 有利于学生能力的提高, 有利于学生素质的提高, 同时对促进教学改革和加强素质教育有着积极的意义, 但在实施过程中仍存在一些问题, 如理论知识点教授与案例分析的有机结合等。在今后的教学模式实施中, 针对存在的问题需要进一步更新、完善教学内容, 以保证取得较好的教学效果。

参考文献

[1]毋国庆.软件需求工程[M].北京:机械工业出版社, 2008.

[2]彭佳红, 彭佳文, 曹晓兰.基于案例的软件工程课程教学研究[J].高等农业教育, 2009, 11 (11) :60-62.

[3]何成万.注重教学和科研相结合的软件工程教学实践[J].软件导刊, 2008, 7 (7) :176-177.

[4]刘寒冰, 靳宗信, 赵文安.《软件需求工程》课程教学改革研究[J].现代计算机, 2010 (8) :44-46.

篇4：教育软件市场需求分析

在学校建立和完善网络的同时，教育软件的应用业已成为这些已经建立自己校园网的学校目前最为关注的问题。“校校通”工程更是进一步推进了教育软件市场的发展，据赛迪顾问调查，2001年教育软件市场规模达到16.3亿元。

教育软件市场现状

目前市场上的教育软件种类很多，但基本上可以划分为教育资源库、辅助教学软件、教育管理软件和针对个人的学习软件几大类。学习软件包括各类语言、电脑教育，以及题库等类型的针对个人学习的软件，这类软件在教育软件中占有较大的比率，教育资源库自2001年以来一直保持快速增长，2002年上半年资源库在教育软件中占26.1个百分点。

教育软件区域市场分布的特点是华东、华南比较强，西部地区较弱，城乡差别突出。此类软件的主要采购地区仍然是信息化工程比较领先的大中城市，这说明原有的市场进一步提升，尚未开发出的西部市场，以及农村中小学的信息化工程仍然有待支持。

目前从事教育软件开发的厂商有200多家，产品也有3000多种，并且不断地有新产品问世。教育软件的市场份额占整个软件市场的17％左右。

科利华、翰林汇、金洪恩、中教育星等公司在教育软件领域都有一定的市场份额。这些厂商都开发包括资源库、课件库、网络教室、电子图书馆，以及学科同步学习软件等系列产品，并且能够提供相对完整的应用方案。各个开发商在教育软件市场中也有其侧重点，例如科利华学习软件市场占有量比较大，中教育星注重资源库的开发等。

随着教育行业信息化的不断深入，教育软件的需求量也不断在增长。其中资源库、辅助教学软件、教育管理软件等类别的教育软件的增长也各有不同。由于参与教育软件市场竞争的厂商不断增多，产品层出不穷，价格战无法避免。2002年上半年教育软件的价格普遍有所下降，教育软件价格的下降刺激用户对于学习软件的需求，英文学习软件的销售量增长非常突出，带动了原本不够活跃的学习软件市场。与此同时，其它软件的销售额的增长比率相对于销售量的增长比率都有不同程度的下降。

教育软件市场存在主要问题

据调查，我国68万所中小学实现信息化建设的不足10％，其中能有效应用信息化手段辅助教学和改革传统教育的更是很少。其中一个重要的原因是教育软件的应用水平远远不能达到教育信息化的需求。其中有学校的原因，也有开发商对学校教育缺乏足够的认识的因素。教育软件市场依然突显以下几个主要问题。

缺乏统一的规范和标准

教育行业是比较特殊的行业，各学校之间、学校与教委之间需要数据交换，但目前的情况却是各个学校在应用不同的产品之后形成了数据壁垒，这在很大程度上影响了信息化进程，而其中必然会产生资源浪费。“校校通”教育城域网的推进更突显了这一问题。

近日，国家教委颁布了《教育管理信息化标准》(第一部分：学校管理信息标准)。《教育管理信息化标准》将为教育部门对教育数据进行总体的规划和组织，建立起统一的数据平台提供有力的技术保证；它将带动教育管理信息存储、访问、更新、传递方式的变革，进一步减轻学校人力资源和财政管理的负担。

建立教育管理软件认证制度，防止一些低劣的管理软件进入教育系统，影响教育管理信息化工作的健康发展。同时，配合标准的实施工作，加快标准应用示范软件的开发与应用。《教育管理信息化标准》的出台，无疑会使得很多厂商的教育管理软件面临重大调整。

而对于整个教育软件行业，国家教育部将逐步出台教育信息化软件方面的标准和规范，要求教育软件开发商必须从全局考虑教育软件的设计。教育软件的整体规划是指设计上有超前意识，要通盘考虑，而不仅仅是着眼于眼前要实现的功能，要使整体方案具有良好的扩展性。

开发商对教学理解得不够深入

我国各类学校校园网已有一定规模。对于已经建立校园网的学校，最主要的任务已经由建网转向如何充分利用已有的校园网络、教育软件产品等教学资源，进一步加强教育理念、教学内容与方法的改革。对于这些学校来说，他们迫切需要的是采用一套软件系统，能够将已有的硬件设备整合起来，充分发挥其系统化、立体化的作用。

目前市场上资源库类教育软件虽然很多，但并未真正走进学校。资源库的设计在很大程度上忽视了教材的特殊性和教师、学生的互动性。教师教学比以往更加注重创新，为了提高教学效率，他们需要丰富的教学资源。但是，教学方法的不同，使得教师在应用资源的时候，会加入自己的理解，他们希望能利用已有的资源制作出能比较准确表达自己教学思想的课件。开发商提供的产品具有很好的原创性才能有更强的吸引力，这主要是解决了技术和设计上的问题，为了教师教学提供便利，尤其是对于教学难点的阐释，资源库具有很强的应用功能。资源库不一定要以量取胜，关键是要切合教学需要。但是，很多资源库软件开发工作缺乏针对性，对目前国内教育结构和教材、以及学生心理认识不够，设计出来的产品不能准确、灵活地表达教学的内容。另外，厂商更重视开发理科类教学软件，其他领域涉及的还不够充分。艺术类、体育类的教育软件很少涉及。教育软件在学科分类上需要更为丰富和清晰。

教育软件的应用尚未进入实质性阶段

尽管政府和教育部门在积极推进教育信息化工程，但是多数学校对于教育信息化的理解仍然停留在概念性的层次，还没有实质性的实施。原因也是多方面的，有些开发商在没有能力整合软件硬件，不具备系统集成能力的情况下，只向学校提供价格昂贵的硬件或随便搭配软件，导致应用无法开展。除此之外，一些学校受厂商影响，片面追求硬件设备的先进性和网络建设一步到位，结果软件和应用跟不上，设备闲置浪费。开发商和学校对于教育行业软件的应用的认识还没有与实际很好地结合。

教育信息化的一个重要内容是要对教师和学生进行信息化技术培训。由于目前教育软件厂商还不够重视产品服务，以及学校设备、师资条件的不足，教师和学生都没有能够得到良好的技术培训，致使大多数学校的信息化资源没有发挥应有的作用，教师对于教育软件资源的利用观念还没有提升到信息化要求的层次。

应试教育影响教育软件走向

需求是市场导向，教育软件的用户的应试教育思想成为影响教育软件发展的主要因素。首先是学校方面，有经验的教师大都在35岁以上，升学率的压力使他们没有更多的时间去了解教学软件，更无法有效应用。另一方面，主要表现在学习软件上，绝大多数个人用户在选择学习软件的决定因素是软件是否与教材同步，大都要考量软件是否紧扣课本。由于各地同一年级所有的教材亦有所不同，要找到完全符合用户理想需求的同步学习软件比较困难。2001年教学大纲调整以后，很多软件在用户眼里已经是过去式，目前市场上的学习软件大都标明是按照新的教学大纲设计等字样。应试教育思想在一定程度上阻碍了学习软件的转型。

软件价格影响市场规范

教育软件因为开发技术等方面原因，价格一直相对较高。例如，资源库的价格一般要上万元，应用于学校的资源库软件目前也只有几千套。大多数学校因为教育经费的问题，没有能力系统地购买教育软件。

教育软件厂商市场分割不明确，几乎每个厂商都涉及的所有类型的教育软件的开发。开发商上演的价格战让用户受益的同时，也使软件在质量上、满足用户需求方面大打折扣。抄袭情况严重，加之盗版的问题，教育软件市场要走向专业化、标准化还需要一定时间。

教育软件市场的发展前景

尽管教育软件市场还没有完全跟上教育的步伐，但其潜在的市场容量，国家政策支持，以及厂商与用户的有效沟通都在从不同方面推进教育软件的发展。目前，全国台式PC年销售量在1000万台以上，其中有50％以上进入了家庭，而知识经济时代所显示出来的知识的价值又让人们充分认识到了学习、教育的重要性。广大用户对教育软件的投入也有很大的增长，而这种增长的趋势还将因为国家教育政策以及教育软件市场的特性进一步升温。未来几年里，教育软件的需求量增长每年都将超过50％。

由于教育布局的调整，2001年全国职业类学校招生人数略有下降，而普通高中招生人数增长了85.29％万人，高等教育的招生规模继续快速增加，2001年普通高等教育招生268.28万人，比上年增加47.67万人，增长21.61％。成人高等教育招生增长25.48％。据赛迪顾问调查，全国各类学校拥有台式PC的数量至少在500万台以上，每年仍至少有10％的增长。这是一个动态市场。

政府不但从政策上支持高科技软件企业的发展，而且还投入大量资金建设教育基础设施，积极发展素质教育，这也就为教育软件市场提供了良好的成长空间。“西部大学校园计算机网络建设工程”项目于2002年上半年正式启动。该项目建设总投资9亿元。

未来的教育软件的目的将是为了真正完善人们的知识结构，提高人们的综合素质和竞争力。教育软件要适应新课程改革的需要，深入理解和考虑教材、教师、学生、环境等要素。教育软件不仅要具有开放性、交互性，前瞻性，也要有较好的二级开发能力。

从用户的角度考虑，教育软件应该内容精良，适用性强。教育软件的用户包括学生和教师，不同的人有不同的需求，软件的灵活性和创造性是尤其需要突出的。据了解，74％的教师表示非常需要教育软件来辅助教学。这说明，目前的教学软件还远远不能满足需求。

随着网络技术的飞速发展和网络使用频率的持续提升，人们将会越来越多地在网上接受教育，所以教育软件的网络化趋势是不可避免的。网络教学是今后学校教育的一个重要方向。软件与网络、教育与网络的融合是今后发展的必然趋势。

篇5：数据分析的需求理解和案例

业务需求的几个来源：

1) 企业高层的决策需要

2) 产品部等做产品调研，市场分析的需要

3) 产品运营时期，为了获知用户和客户质量需要

4) 市场部做营销运营，为验证转化率的需要

5) 客服的效果统计，编辑部门 做内容的转化率如何

具体可以分成以下常见的业务需求

第一方面：高层需求

1) 新的市场机会在哪里，哪些未上架的服务能够带来新的收入增长?

2) XX总监要求，就XX营销活动的效果进行分析，得失和用户结果等进行量化处理

第二方面：市场和产品部门需求

1) 市场推广方式是否有效，以及能否进一步提效;

2) 访问网站的用户是否是目标用户，哪种渠道获取的用户更有价值(跟第一个需求有交集也有不同);

3) 用户对网站的感觉是好还是不好，除了商品本身之外的哪些因素影响用户的感觉;

4) 除了撒谎外，什么样的商业手段能够帮助说服客户购买或二次购买;

5) 从什么地方能够进一步节约成本，运营成本，开发维护成本;

6) 如何为运营部门做好客户会员等级设计，做好数据支持工作?

第三方面：技术部门需求

网站速度和错误率，较以前改善了多少?使得用户满意度有所提高

第四方面：客服编辑等部门的需求

客服的服务流程，在哪一块可以得到优化改善，提高客服效率

这些根本性的业务需求每天都会被网站管理层以各种各样的方式提出，

如果网站分析不能围绕这些问题进行，那么任何分析的努力都不过是隔靴搔痒，价值低迷。

所以，当你被你的老板命令，做一个数据统计(分析)需求的时候，

最好能够问一下自己，它背后的业务需求是什么。这个业务需求靠谱不?

这个思维方式能让你把工作干得更好。

有些时候，电子商务网站分析还没有开始进行就已经失败了，这是因为先期的实施为日后的工作埋下了麻烦的种子。

业务逻辑和彼此关系

数据的属性

既有的产品，其数据的统计，周期性变化的统计

举例说明：截止到2月底，XX网站的注册用户量达到45.08万，

近1个月增加了1800个，较上个月增加速度上升了11.5%，较历史峰值降低了7%

其中核心用户达到8500个，

近1个月增加了75个，较上个月增加速度上升了23，较历史峰值降低,4%;

页面PV达到240万，较上个月这一天增加速度上升了23，较历史峰值降低4%;

数据分析的一些名词定义

就以世界工厂网社区为例，做一些名词定义解释：

1)转化率：用户执行了某种我方期望的动作的比重。=进行了相应的动作的访问量/总访问量

2)跳出率：代表着访问者看到的仅有的一页的比率

3)有效用户：是工厂网注册用户，且至少在论坛发过一个帖子(含回复)，

可以进一步分为活跃用户，非活跃用户，流失用户等几个类型;

4)活跃用户：是指经常参与帖子回复和话题交流的工厂网注册用户

5)流失用户：曾经访问过网站或注册过的用户，由于种种原因，已经抛弃了社区，不可能再为社区创造任何价值

6)核心用户：经常发帖回帖，给论坛提意见和参与话题活动，在线时间很长，对某些版块的一些话题意见独特有价值，并且可以影响一部分人成为论坛用户。符合其中2项以上特征就是核心用户。

7)用户流失率：计算公式：网站用户流失比率=3个月内没有登录的用户数量/3个月前站内的用户总数

具体的应用场合分为：按照具体产品和具体业务需求几种角度

1.按照具体产品和位置来分：

登录与注册会员后台积分帮助中心企业网站采购供应资讯和专题社区和圈子学堂百科 广告支付展会服务 工厂店等

2.按照具体业务需求来分：

1) 产品体验优化：网页改版后的用户调查分析，用户注册量变化分析，PV 和IP分析

2) 新服务的运营效果，比如pv ip 用户注册率使用情况客服投诉率

3) 用户分析：对用户的行为，访问情况，来源

4) 流量来源：那些产品贡献的流量多，那些贡献的少，流量时段变化，较前一段增加还是减少，搜索引擎关键词分析，所在区域的流量分布

5) 转化率分析：这个是最核心的数据了，没有转化率，其他一切都是免谈!某些牛B的网站能做到4%的询盘转化率!某些却仅仅是0.1%。转化率就是对站内数据流分析，主要用来分析页面的流程是否顺畅和产品分布是否合理

6) 营销活动：

7) 用户活跃度分析：

篇6：软件系统需求分析案例

惯例先讲一个貌似不太有关系的事。

前几天有一个据说是白富美的妞在论坛上问，像她这样的白富美怎样才能嫁个有钱人？有个回复是这样的：“姑娘你快别逗了，真正聪明的有钱人只会跟你交往，不会跟你结婚。因为美貌会日渐贬值，明智的选择是租赁，不是长期持有。”

这个故事告诉我们：白富美神马的都是浮云。

额其实我想说的是：要用投资的眼光看问题，面对各种数据的时候要坐怀不乱，不要只是看某一时的数据表现好就不淡定了。天知道还能美多久。

前一阵和一个朋友聊到现在的各种数据分析软件，发现很多人都不太清楚看数据的目的。

数据分析能带给我们什么？

我们希望通过数据分析做什么决策？

除了维持基本的店铺运营，数据还能帮我们做什么？

如何从现在的数据看到未来的发展趋势？

如何利用数据进行预测？

那下面我们来好好分析一下，我们手中的软件都可以为我们带来什么。以下是对于目前数据市场大致分析工具所能达到的功能结构图。

我们在用数据之前，要先问自己几个“为什么”。因为有方向的发现，才是真正有价值的发现，才会真的有所发现。

那么，你找到你的店铺到底需要什么功能了吗？

我们来看一个店铺的数据。

这是一家童装店，由于最近正是入夏好时节，各种上新，所以这家店决定将首页推出一个专区，每天轮番更新不同宝贝。

目的在于：

1测试店铺新品表现情况，发现黑马宝贝，打造爆款。

2首页的不停变化，吸引新客户流量以及老客户二次消费。

3保持店铺宝贝均衡销售，提升整体质量。

我们可以先用热力图看一下首页流量和销量的数据情况：

导航栏流量

我们发现按照我们的分类来说，非常热门的类目有：新品区，连衣裙，男童区，亲子装。

而且第一幕，第二幕，第三幕的表现非常好，流量主要集中在这一部分。所以我们初步将前三幕定为专区区域。

我们按照热力值的范围选择相对热门的宝贝进行详细分析

下面我们分别分析一下“连衣裙，男童区，亲子装”这三个类目下的“黑马宝贝”。

我们要寻找的不是目前销量最好的宝贝，而是未来一周有可能销量最好的宝贝。

第一款第二款都是流量很高的，可以重点观察一下后面三款的情况，而且从目前的数据来看，这三款都有黑马宝贝的特征。

亲子类目不如连衣裙类目火爆，可以选择转化率比较高的几款宝贝进行测试。套装区的第三款宝贝转化率很高，就是访客数不是很高，观察其在首页的位置，发现这款宝贝非常符合“黑马”特征。

综合以上，将以上三个类目中的黑马宝贝放在前三幕进行重点推广。以下是四天后的测试数据

环比增长率和专区贡献度都有很大提升，仅仅7件宝贝就为店铺带来的48914.48的销量业绩。表现非常好。

总结：

1、不要基于不停的打造爆款，爆款只是引入流量的手段，在店铺整体情况非常好前提下，打造爆款会带来非常大的收益。但不要只是依赖于爆款。

2、数据是诚实的，我们应该学会如何利用目前的数据指标挖掘新的潜在的业务机会。

3、可以找个外在美谈谈恋爱烧烧钱，但最终还是要找个内在美娶回家当老婆。

4、每个行业的数据都是不一样的。当店铺运营到一定规模，就要关注自己在本行业的比重，本行业的销售趋势，要不停的顺应行业内的趋势环境才能有更好的增长。

5、数据分析最核心价值是人对于数据的分析，要多维度思考。

文章来源：派代网

篇7：软件需求分析报告

软件需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。进行需求分析时，应注意一切信息与需求都是站在用户的角度上。尽量避免分析员的主观想象，并尽量将分析进度提交给用户。在不进行直接指导的前提下，让用户进行检查与评价。从而达到需求分析的准确性。分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据和功能表示。在软件完成后，制定的软件规格说明还要为评价软件质量提供依据。

需求分析的任务

开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。目前，国内产品的庞杂，一家企业可能有几个系统并立运行，它们之间接口是系统开发人员最头痛的问题。对于商业最终用户应用程序，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的。但是对于我们开发人员来说，并没有编写出客户认可的需求文档，我们如何知道项目于何时结束？而如果我们不知道什么对客户来说是重要的，那我们又如何能使客户感到满意呢？然而，即便并非出于商业目的的软件需求也是必须的。例如库、组件和工具这些供开发小组内部使用的软件。当然你可能偶尔勿需文档说明就能与其他人意见较为一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价，这些血的教训正在国内的软件开发者身上发生。近来，我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件。不幸的是，当他们开发完这个工具后，发现这个工具不能打印出源代码文件，使用者当然希望有这个功能。结果这个小组只好手工抄写源代码文档以供代码检查。这说明那怕需求明确无误并构思准确，如果我们没有编写文档，软件达不到期望目标也只能是咎由自取了。相反的情况，我曾见一个要集成到“错误跟踪系统”中的简单界面写了一页需求说明。而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用。他们依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且未发现任何错误。事实上，需求文档在开发过程中一直起指导作用。需求的类型

下面这些定义是需求工程领域中常见术语的定义。软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。1．业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。2．用户需求(user requirement)文档描述了用户使用产品必须要完成的任务，这在使用实例（usecase）文档或方案脚本说明中予以说明。3．功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。在软件需求规格说明书（SRS）中说明的功能需求充分描述了软件系统所应具有的外部行为。软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。对一个大型系统来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于子系统（或软件部件）。作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反

篇8：软件系统需求分析案例

软件开发项目不论其类型或规模大小, 需求变更的有效管理是必要的。实施需求变更如同给病人动手术, 要花费成本, 延误开发进度, 有可能使需求规格说明出现错误, 影响软件开发质量, 甚至导致开发失败。需求通常是很不稳定的, 用户希望把一个需要点击两次的功能, 改成点击一次, 就会导致需求变更, 并影响编码、测试及软件维护[1]。需求变更风险管理重在预防, 有效预防需要有效的预测机制, 需要有效识别需求变更原因, 需要建立合理的原因分类依据和分类结构。

2 研究现状概述 (Previous studies)

20世纪80年代前, 主张冻结需求的瀑布模型盛行, 但随着软件应用的日益普及, 软件规模和复杂度不断增大, 冻结需求的做法已经行不通, 需求频繁变更给软件开发及其维护带来了巨大的挑战。为迎合需求变更, 减少变更带来的影响和危害, 出现了多种开发技术, 例如:联合应用设计、原型法、快速应用开发、敏捷方法等。同时, 需求变更的原因成为业界和学术界一直关注的问题, 学术界展开了广泛的探讨和研究。20世纪90年代, Harker等[2]详细分析了组织和用户需求有可能发生变更的五种来源:动态变更的环境、用户参与需求获取、用户使用系统并参与开发、情景行动和任务变更、有计划的组织开发约束, 并探讨预防变更的相应对策。Kotonya和Sommerville[3]探讨了软件开发过程中需求变更的各种可能原因, 例如:需求错误、冲突、不一致;技术、进度或成本问题;用户组织需求改变等。Mc Gee和Greer[4,5]运用文献分析和实证分析手段, 建立需求变更来源的分层视图并验证这种分类在实际开发过程中的效果。事实上, 需求变更是对需求问题的修正。在引起需求问题的众多因素中, 人是非常重要的因素。开发人员和客户的认知能力、情绪及人际关系都与需求变更问题相关。Anitha等[6]重点研究了作为非技术因素的人在敏捷开发过程中有可能引起的需求变更问题以及相应的对策。Janes等[7]的研究涉及探讨开发人员的感知和理解力、交际能力、情绪和行为特征在需求变更问题上所起的影响作用。

关于需求变更原因的识别和分类中, 当前存在三个主要问题: (1) 没有建立需求变更原因与软件风险因素间的联系, 没有发掘这两类因素之间的共通性; (2) 需求变更原因的分类缺乏原则指导, 分类结构层次不清晰、不完整。

针对这些问题, 本文首先建立诱发需求变更的因素与软件风险因素之间的共通性, 然后从风险管理角度, 提出需求变更原因分类依据, 并对变更内因和外因进行分析, 建立软件生命周期需求变更原因分类结构, 并通过问卷调查, 获得了开发人员的认可。

3 软件风险与需求变更风险的共通性 (The commonality between software risk and requirements change)

3.1 软件风险因素是需求变更的诱因

常见的软件风险因素有[8]: (1) 合同风险; (2) 需求变更风险; (3) 沟通不良风险; (4) 缺乏领导支持风险; (5) 进度风险; (6) 质量风险; (7) 系统性能风险; (8) 工具风险; (9) 技术风险; (10) 团队成员能力和素质风险; (11) 团队成员协作风险; (12) 人员流动风险; (13) 工作环境风险; (14) 系统运行环境风险。这些风险因素会直接或间接地诱发各种需求问题 (图1) , 导致需求变更[7,9]。

3.2 需求变更原因的分类依据

需求问题的存在使得需求不得不发生变更[7,9,10]。需求问题可以出现在软件生命周期中的任何阶段, 与各种要素相关:项目的复杂度和规模、开发人员的素质、客户的参与程度和理解力、政策和市场竞争等等。图1中, 有些因素与人有关, 例如:沟通不良、团队成员协作、团队成员的能力和素质、人员流动;有些因素与过程有关, 例如:合同问题、进度问题;有些与组织有关, 例如:缺乏领导支持、工作环境问题。从有效软件风险管理角度出发, 一定要从软件生命周期去识别需求变更的原因, 而且要考虑全面性并兼顾客观性, 不放过任何细小的可能导致需求变更的因素或小概率事件, 因为这些微小的因素有可能使软件开发过程及其产品出现灾难性的后果[7]。因此, 我们提出了四个原则[11]:全局性 (Holistic) 、相关性 (Correlative) 、强内聚性 (Strong Cohesive和弱耦合性 (Weak Coupling) 。

4 基于风险管理的需求变更内外因分析及分类框架研究 (The risk-oriented internal&external cause factors of requirements changes and the identification&classification framework)

Microsoft的量化研究表明, 在风险管理中投入5%的项目工作可以获取50%—75%的如期完成的机会[12], 可见风险管理在软件开发中的重要作用。软件风险管理通常由六个步骤组成:风险识别、估计、分析、计划、控制和监督。风险识别就是识别各种风险因素。一方面, 软件风险因素是诱发需求变更的因素。另一方面, 需求变更是关键的软件风险因素, 诱发需求变更的各种因素就是潜在的软件风险因素。因此, 识别需求变更原因因素就是识别软件风险因素。

4.1 需求变更的内因

内因是指与项目本性相关, 并有可能会诱发需求变更的因素。

Janes等[7]认为诱发需求问题的内部因素有两种: (1) 项目的复杂度和开发持续时间; (2) 组织结构。事实上, 项目的复杂度是客观存在的, 是项目的本性之一, 是影响开发人员认知的重要因素。开发持续时间与多方面因素有关, 既有客观的, 例如项目的复杂度及规模、开发范围, 也有非客观的, 例如开发人员的素质、经验、开发成本、进度计划、客户的配合等因素。这里我们所认为的内因是客观存在的因素, 因此开发持续时间不属于我们所讲的内因。组织结构包括开发组织和客户组织。客户组织通常指的是广大用户的代表。例如, 淘宝购物平台, 社会的每一成员都是其潜在的用户, 但只有淘宝公司的运营部门成员能够代表广大的用户去选择开发组织, 具有一定的主观性。因此组织结构不属于内因。我们所定义的需求变更的内因是:规模因素和复杂度因素。

这两个因素之间的联系是:项目规模大或复杂度高, 将影响开发人员的认知 (影响概念的完整性与一致性) , 影响需求的完整获取, 会诱发需求变更。而且规模大的项目其复杂度通常都高, 例如, 飞机导航系统, 各种子系统之间的一致性、并发性、容错性是复杂的。它们的区别是复杂度高的系统不一定规模大, 例如植入人体的芯片系统, 它涉及医学、人体解剖学, 其复杂性是不言而喻的。

4.2 需求变更的外因

外因是除内因外可能诱发需求问题和需求变更的因素。图1的所有软件风险因素都是需求变更的外因。外因分为六类[12,13]:干系人因素、组织因素、技术因素、过程因素、环境因素和软件效能因素。

(1) 干系人因素。干系人是指参与到软件开发过程中的开发人员、项目经理、营销人员、客户等, 分为两类:a.开发人员:指参与项目开发、管理、销售的人员以及软件的维护人员;b.客户:指项目委托方人员及终端用户。开发人员会存在这些问题:知识结构不完整, 缺乏沟通能力, 经验不足, 技术不熟练, 工具掌握不好, 学习能力不强, 缺乏钻研精神, 不熟悉项目背景, 缺乏责任心, 情绪不良。客户存在的问题:对产品的认识和了解不足, 参与积极性不高, 不积极配合开发人员, 不遵守合同要求。

(2) 组织因素。组织分为两类:开发组织与客户组织 (也称用户组织, 亦包括作为客户组织代表的提供开发资源的第三方组织) 。开发组织存在的问题是:缺乏良好的企业文化和凝聚力, 团队成员之间沟通不足, 对开发人员或客户的培训不足, 领导的市场开拓能力不强、官僚主义, 开发人员流动频繁, 办公环境不佳。客户组织存在的问题:组织结构、运作方式、商业策略发生改变, 业务范围扩展。

(3) 技术因素。技术包括工具在内分为:a.开发技术。开发技术和工具的熟练使用能够提高开发效率, 减少开发过程中的错误包括减少需求问题及需求变更。常用的开发技术或手段有[8]:联合应用设计 (JAD) 、原型法、快速应用开发 (RAD) 、需求检查等。如果缺乏使用或不熟练使用恰当的技术, 无疑会增加需求变更风险;b.管理技术。在开发过程中, 除了要加强项目管理意识, 在软件生命周期中实施规范的管理细则, 还要懂得借助于一些商业变更管理系统工具[14]来协助需求的开发、降低需求变更的影响;c.集成技术。不论是同一个软件系统的开发还是大数据的应用, 都存在着许多子系统, 这些子系统必须集成在一起才能够使软件系统完整。这些子系统之间的集成依赖于接口需求的一致性, 如果不一致, 则会导致需求的变更。软件系统赖以运行的硬件环境、网络环境、支撑软件 (如操作系统) 的配置要与性能需求保持一致性, 否则会诱发需求的变更。

(4) 过程因素。过程分为:a.计划过程;b.开发过程;c.管理过程。计划过程容易出现的问题有合同制订不科学, 项目范围和目标不明确, 对人力、成本、进度等资源估算不足;开发过程常常出现的问题是进度延误、成本超支、不遵守合同、开发范围扩大;管理过程常常存在的问题为项目缺乏合理统筹和管理, 需求缺乏规范和有效的管理, 不能够预见问题的发生, 不遵守科学的管理流程和规则。

(5) 社会环境因素。社会环境因素是指软件在其生命周期中对其生存有影响的并且难于预测和控制的一些社会因素。这些因素具有一定的随机性, 是开发人员和客户无法控制的[14]。它包括:a.市场:出现新需求导致现有产品过时;b.竞争压力:竞争者发布新产品打压、影响正在开发或已经交付的产品。这种竞争压力常常出现在商业软件中[10], 例如现在的手机软件, 同一种应用的软件在手机商店上五花八门, 相互之间形成巨大的竞争;c.政法:政策、法律、法规发生变更。例如税收法的变更会影响税务系统, 商业过程的研究会使商业规则发生变更[10]。

(6) 软件效能因素。软件交付使用之后, 有可能软件的使用成本高、易用性不好、没有真正满足用户需求[15]。软件效能因素包括:a.使用成本的可接受性;b.功能完整性;c.软件性能。例如:易用性、时间响应性、兼容性、适用性、容错性、安全性等。用户满意度就是软件效能因素的综合评价结果 (通常是一个主观量) 。

4.3 需求变更原因分类框架图

为了能够认清需求变更原因, 我们构造了一个软件生命周期中需求变更原因分类框架图 (图2) 。内因有两层, 外因有三层。在叶子层, 仍然可以找出底层的原因因素。例如合同的计划问题属于计划过程问题, 合同的遵循问题属于开发人员问题或客户问题。由此可见, 底层的具体的原因可能属于几种类别, 一定要分析清楚具体的原因才能找出其真正的出处, 以便更有针对性地实施控制和管理需求变更。

图2有助于完整识别各类需求变更的原因, 也有助于找到更细小的原因及其所属来源路径, 使得需求变更的实施更有针对性。在实际的开发过程中, 当找出了各种可能原因, 还要在这些原因中继续判断主要原因和次要原因, 但绝不能够忽略看似微不足道的诱因[2]。

5 变更原因贡献度计算和结果分析 (The calculation and result analysis of the contribution rates of cause factors)

专家访谈与问卷调查是软件工程实证研究的主要手段[16]。为了对需求变更原因获得更直观、深入的理解, 我们在广州一家著名的专注于电子政务系统开发的软件公司的开发人员中进行了一次问卷调查。

5.1 问卷调查的主要内容和方式

问卷主要了解四大部分内容:a.个人开发经历及企业基本情况;b.开发过程中需求获取与分析情况;c.开发过程中需求及变更管理情况;d.常见的软件风险因素、需求问题及变更原因。与本研究相关的问题是:在软件风险管理框架下, 什么因素容易导致需求变更, 其贡献分值是多少 (在0—5中选填一个数字, 数字越大, 贡献分值越高) ?

5.2 原因贡献度

原因贡献度是指某原因会诱发需求变更的可能性大小。贡献度分值越高, 表明该原因越关键, 在软件开发和项目管理时, 越要重视这一因素及其与之关系密切的其他因素。

对回收的112份数据进行统计, 采用算术平均法计算每个原因的贡献分值, 分值再除以5得贡献度, 如表1所示。

从表1可见, 内因中的项目特征“复杂度”因素, 贡献度为70%, 表明复杂度高, 对开发人员的认知是一个挑战。越复杂的项目, 开发人员越要深入了解项目的背景并要与客户保持良好的沟通关系。外因下面的“人”因素下的“客户”子因素的贡献度最高, 达到82%。

这表明客户的积极参与以及开发人员与客户进行有效沟通对避免需求变更有关键作用, 这与我们已有的常识相符。“开发人员”的贡献度为68%, 表明开发人员对成功开发的关键作用, 这是不言而喻的。“开发组织”与“客户组织”分别为68%和66%, 说明组织对开发过程的统一、协调配合及其管理的重要性。“开发过程”与“管理过程”分别为70%和68%, 同样表明开发过程的顺畅性和管理过程的合理性的重要作用。另外, 表1可反映这样一个事实, 需求变更的主要因素是与人相关的因素。

5.3 加权原因贡献度

考虑到参与问卷调查的开发人员中有的经验丰富 (参与开发项目超过30个) , 有的是新手 (只参与了五项) 。为使回收的数据更具有客观性, 在计算原因贡献分值时, 把开发经验折成一定的权值。我们设计了如表2所示的经验权值赋权方法, 计算出这批问卷表对应的平均权值为0.93。利用表1所使用的数据, 并通过加权, 得表3, 最终结果与表1相吻合。

6 结论 (Conclusion)

本文从软件风险管理角度出发, 建立了软件生命周期需求变更的内外因结构框图。这一分类方法具有客观性、全面性和推广性, 有助于识别实际软件开发过程中各种软件风险因素和需求变更因素。我们所进行的实证研究分析结果表明了这一分类的合理性和因素之间的可区分性, 结论是可靠的。