软件系统需求分析案例

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

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

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

小品角色：

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

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

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

场景A

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

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

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

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

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

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

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

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

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

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

场景C

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

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

第二篇：软件需求-案例分析

1、问题描述

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

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所示。

操作 预约验证 参与主体

对应需求

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

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

第三篇：软件需求分析报告

软件需求分析

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

需求分析的任务

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

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

映产品功能。多角度描述产品对用户和开发人员都极为重要。下面以一个字处理程序为例来说明需求的不同种类。业务需求可能是：“用户能有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。而对应的用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换。从以上定义可以发现，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。项目也有其它方面的需求，如开发环境需求或发布产品及移植到支撑环境的需求。

第四篇：门禁系统需求分析

门禁系统建设需求分析

1.是否联网通过RS485还是TCP/IP 方式？如果采用485，是否需要配置485 HUB?(增加通讯距离，挂接更多的控制器)如果采用TCP/IP 是直接采用网络转换器还是通过TCP/IP转化器？ 2.门禁控制器类型：单门，双门，四门，八门控制器还是门禁一体机？

3.识别方式：密码，指纹，刷卡，识别脸等? 4.管控方向：单项刷卡还是双向刷卡？

5.卡片类型:EM（智能采用EM 读卡器，需要联网）,Mifare，HID 6.读卡器类型:韦根，485,如何发卡：通过控制器，232读卡器，键盘口读卡器，输入卡号？

7.系统软件：单机版还是网络版？需要考勤，电梯和更新软件模块吗？

8.电控锁类型：磁力锁，电插锁(阳极锁，双向开门)，阴极锁，需要支架吗？

9.供电方式：集中供电还是分散供电？ 10.线材选材：RVVP 还是RVSP? 联网门禁系统说明：

1：

说明：进出安装两个按键读卡器，通过韦根接口连接到单门控制器上，进出均可提供三种开门方式，刷卡、刷卡+密码和安全密码。但不可以设为进门不要密码管制，而出门要密码管制进出安装两个指纹读卡器，通过韦根接口连接到单门控制器上。两台指纹读卡器，可通过485接口连接到控制器的485 总线上，便可通过计算机将采集到的指纹，下传到指纹读卡器中，或者将指纹读卡器中指纹数据备份到计算机中。

2：

 指纹一体机就是集成了指纹读头的单门控制器

 指纹一体机可内置射频读卡模块，提供刷卡+指纹等更多种开门方式

 如果内置了Mifare读写模块，还可以配置成将指纹存储在Mifare卡中。正常情况下，指纹存储在指纹机中。

 指纹存储在Mifare卡中，一个最大的好处是，提供1:1的指纹比对方式，提供系统的安全性，降低误识率；同时一台指纹机管理的员工数量，不再受到指纹机中指纹存储容量的限制，可增加到 10,000个员工。

第五篇：系统需求分析报告

系统需求分析报告

目录

目录.............................................................................................................I

1、项目描述...............................................................................................1 1.1 背景................................................................................................1 1.2研究意义........................................................................................1

2、需求分析...............................................................................................1 2.1功能需求分析................................................................................2 2.1.1 系统管理功能......................................................................2 2.1.2 流量劫持功能....................................................................2 2.2性能需求分析................................................................................2

I

1、项目描述

1.1 背景

随着网络的普及，网络业务应用向深度和广度不断发展，方便用户的同时，也因用户终端存在网络安全漏洞或用户网络安全意识的疏忽，使得网络上涉及如：电子商务、在线游戏、DNS授权服务、网银支付系统、社交网站、论坛、博客、门户网站等在线业务受到黑客及网络犯罪份子的攻击，对个人用户信息（网银、支付钱包账号密码等）的保密和对国家互联网信息管理与审计构成严重威胁。

1.2研究意义

本项目针对以上问题，主要利用了以下两种技术：僵尸网络反制技术及HTTP/HTTPS协议通信的监控技术。

网络攻击已严重威胁着网络的安全，及时的发现网络攻击并在必要的时候劫持与反制网络攻击，成为保障互联网正常运行、保障在线业务系统正常访问的重要方法。

2、需求分析

经过与项目委托方多次讨论，设计系统的目的是为实现对特定非法用户Web（HTTP/HTTPS协议）通信进行监控及反制，具体要求实现的功能有：监控系统远程控制、针对特定非法用户上网流量劫持、针对特定非法用户Web通信进行JS脚本注入、获取非法用户账号和密码、获取非法用户访问某些网站的Cookie。

第 1 页 2.1功能需求分析

根据监控系统的要求对系统的功能进行分析，明确了系统需要实现的功能。系统的功能结构模块：系统管理功能、流量劫持功能、监控与反制功能。

2.1.1 系统管理功能

系统管理模块主要负责系统登录、系统远程控制、黑名单库配置、数据存储和展示。数据展示包含数据存储和数据展示，数据存储负责接收后端和前端JS探针采集的数据并存储到数据库，数据展示负责提取数据库数据并显示。

2.1.2 流量劫持功能

本文流量劫持指DNS协议劫持，主要由四个部分组成：报文捕获、协议解析、IP及域名查找匹配、DNS协议欺骗。

2.2性能需求分析

1.DNS流量劫持成功率

为了达到项目委托单位的要求，需要对特定用户访问特定网站的流量进行准确监控，同时保证流量劫持的成功率（90%以上）。

2.监控与反制系统并发量

监控与反制系统服务器的并发性能直接决定同时能够监听的用户数。当被监控用户数过大，监控与反制系统并发处理能力到极大挑战。

3.系统运行稳定性

第 2 页 系统稳定性是系统最基本也是最重要的要求，运行稳定性关系到系统能否长时间稳定运行。系统的稳定性体现在：随着运行时间的增加，系统并不会出现内存泄露、甚至系统崩溃等情况。其中内存泄露可通过内存消耗、CPU使用率指标度量。

第 3 页