软件需求分析案例分析

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

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

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

操作 预约验证 参与主体

对应需求

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

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

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

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

小品角色：

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

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

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

场景A

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

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

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

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

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

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

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

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

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

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

场景C

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

篇3：软件需求分析的思考

一般可以从用户角度 (即系统的外部行为) 和从开发者角度 (即系统的内部特性) 两个方面来阐述软件需求的定义。

从用户角度一般认为软件需求是“指明系统必须实现什么的规格说明”。它描述了系统的行为、特性或属性, 是在开发过程中对系统的约束。

从开发者角度可以认为需求是“用户所需要的并能触发一个程序或系统开发工作的说明”。有些需求分析专家拓展了这个概念:“从系统外部能发现系统所具有的满足于用户的特点、功能及属性等”。

从上面这些不同形式的定义不难发现:这些定义都强调产品是什么样的, 而并非产品是怎样设计和构造的。很难给软件需求一个准确的定义, 真正的“需求”实际上在客户的脑海里, 但一般情况下, 用户并不能描述自己的需要, 只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对。

2 软件需求的类型

软件需求包括三个不同的层次:业务需求、用户需求和功能需求 (也包括非功能需求) 。

业务需求:反映了组织机构或客户对系统、产品高层次的目标要求, 它们在项目视图与范围文档中予以说明。

用户需求:文档描述了用户使用产品必须要完成的任务, 这在使用实例文档或方案脚本说明中予以说明。

功能需求和非功能需求:功能需求定义了开发人员必须实现的软件功能, 使得用户能完成他们的任务, 从而满足了业务需求。作为功能需求的补充, 软件需求规格说明还应包括非功能需求, 它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约;外部界面的具体细节;性能要求;设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述, 从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。

下面通过与文字处理系统相关的部分需求来说明需求的分类。业务需求是:“用户能有效地纠正文档中的拼写错误”, 该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。而对应的用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时, 该拼写检查器还有许多功能需求, 如找到并高亮度提示错词的操作;显示提供替换词的对话框以及实现整个文档范围的替换。

3 需求分析的任务

开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出软件需求规格说明, 所谓软件需求规格说明是软件应满足的全部需求, 并可以用文档的方式完整和精确地陈述这些需求, 包括所有面向用户、面向机器和其它软件系统的接口。这项工作非常关键, 一旦做错, 将最终会给系统带来极大损害, 并且以后再对它进行修改也极为困难。一个质量较高的软件需求规格说明通常应具备完整性、正确性、可行性、无二义性等基本特征。

4 需求分析过程

可把整个软件需求工程研究领域划分为需求开发和需求管理两部分。需求开发可进一步分为:问题获取、分析、编写规格说明和验证四个阶段。这些子项包括软件类产品中需求收集、评价、编写文档等所有活动。需求开发活动包括以下几个方面:确定产品所期望的用户类别;获取每个用户类的需求;了解实际用户任务和目标以及这些任务所支持的业务需求;分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息;将系统级的需求分为几个子系统, 并将需求中的一部份分配给软件组件;了解相关质量属性的重要性;与客户商讨实施优先级的划分;将所收集的用户需求编写成文档和模型;评审需求规格说明, 确保对用户需求达到共同的理解与认识, 并在整个开发小组接受说明之前将问题都弄清楚。

需求管理需要建立并维护在软件工程中同客户达成的合同。这种合同都包含在编写的需求文档与模型中, 客户的接受仅是需求成功的一半, 开发人员也必须能够接受他们, 并真正把需求应用到产品中。通常的需求管理活动包括:定义需求基线 (迅速制定需求文档的主体) ;评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它;以某种可控制的方式将需求变更融入到项目中;使当前的项目计划与需求一致;估计变更需求所产生影响并在此基础上协商新的承诺, 并体现在项目解决方案上;让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪;在整个项目过程中跟踪需求状态及其变更情况。

以上几点说明是根据国内外的一些系统实施的相关成功经验, 进行了总结。

5 需求分析的过程中应注意的若干问题

不重视需求分析过程将会给项目的开发带来失败的风险, 为尽量减少项目风险, 在需求分析的过程中应注意以下几个问题带来的风险。

5.1 无足够用户参与

在实施项目时, 若无足够的用户参与, 系统人员获得的需求是片面的, 不完整的, 这样系统在需求之初就埋下风险。应让具有代表性的用户在项目早期直接参与到开发队伍中, 并一同经历整个开发过程。客户和开发人员应积极合作, 共同开发项目需求。有时开发人员觉得已经明白用户的需求了, 但是在某些情况下, 而客户并不太明白自己的真正需求。

5.2 用户需求的不断增加

在开发中若不断地补充需求, 项目就越变越庞大以致超过其计划及预算范围。计划并不总是与项目需求规模与复杂性、风险、开发生产率及需求变更实际情况相一致, 这使得问题更难解决。实际上, 问题根源在于用户需求的改变和开发者对新需求所作的修改。

要想把需求变更范围控制到最小, 必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明, 并将此说明作为评价需求变更和新特性的参照框架。说明中包括了对每种变更进行变更影响因素分析的变更控制过程, 有助于所有风险承担者明白业务决策的合理性, 即为何进行某些变更, 相应消耗的时间、资源或特性上的折衷。

5.3 模棱两可的需求

模棱两可是需求规格说明中最为可怕的问题。它的一层含义是指诸多读者对需求说明产生了不同的理解;另一层含义是指单个读者能用不止一个方式来解释某个需求说明。

模棱两可的需求会使不同的风险承担者产生不同的期望, 它会使开发人员为错误问题而浪费时间, 并且使测试者与开发者所期望的不一致。处理模棱两可需求的一种方法是组织好负责从不同角度审查需求的队伍。仅仅简单浏览一下需求文档是不能解决模棱两可问题的。如果不同的评审者从不同的角度对需求说明给予解释, 但每个评审人员都真正了解需求文档, 这样二义性就不会直到项目后期才被发现, 那时再发现的话会使得更正代价很大。

5.4 过于精简的规格说明

有时, 客户所作的规格说明过于精简, 仅涉及了产品概念上的内容, 然后让开发人员在项目进展中去完善, 结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明。这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况。但在大多数情况下, 这会使开发人员在不正确的前提和有限的指导下工作, 也会使客户无法得到他们所设想的产品。

参考文献

篇4：浅谈软件工程之软件需求分析

【关键词】软件工程 软件需求 需求工程 需求开发 需求管理

【中图分类号】TP311.5【文献标识码】A 【文章编号】2095-3089（2015）06-0181-02

软件工程师所需解决的问题往往十分复杂，了解问题的性质可能是非常困难的，尤其当系统是全新的时候。

1.综述

软件工程中包含需求、设计、编码和测试四个阶段，其中需求工程是软件工程第一个也是很重要的一个阶段，这个阶段的任务仍然不是具体地解决问题，而是准确地确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须具备哪些功能。本文以企业人事信息管理系统为例详细介绍了需求工程的构成和进行方法。

2.需求的标准

定義需求标准有所不同，但在思想上是相同的，都是为了保证项目的顺利进行。一般的标准为：明确（Clear）、完整（Complete）、一致（Consistent）、可测试（Testable），还有可跟踪、可修改等等。

明确：目前大多数的需求分析采用的仍然是自然语言，自然语言对需求分析最大的弊病就是它的二义性。所以对需求分析中采用的语言应该做某些限制尽量采用主语+动作的简单表达方式。还有，不要使用计算机术语。需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。

完整：需求的完整性是非常非常重要的，要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各方各面，贯穿了整个过程，从最初的计划制定到最后的需求评审。

一致：用户需求必须和业务需求一致，功能需求必须和用户需求一致。严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。

可测试：需求的几项标准都是为了保证需求的可测试性，只有系统的所有需求是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。

需求工程分为了需求开发和需求管理两个阶段：下面就以这两个阶段说明：

3.需求开发

需求开发又分为需求获取、需求分析、编写规格说明书和需求验证。以下列出和讲解分析常规的步骤，当然应按照项目的大小和特点等实际情况我们应该自己确定合适的步骤。

3.1需求获取：

这是该阶段的一个最重要的任务。以下为获取用户需求需要执行的活动。

了解客户方的所有用户类型以及潜在的类型。然后，根据他们的要求来确定系统的整体目标和系统的工作范围。

对用户进行访谈和调研。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。例如，可以将需求细分为功能需求、非功能需求（如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型。

需求分析人员对收集到的用户需求做进一步的分析和整理。

需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员。大家共同确认需求分析人员所提交的结果是否真实地反映了用户的意图。

3.2需求分析

需求分析是软件定义时期中很重要的一个阶段，它的基本任务是准确地回答“系统必须做什么？”这个问题。在很多情形下，分析用户需求是与获取用户需求并行的，主要通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。这些模型是对需求的抽象，以可视化的方式提供一个易于沟通的桥梁。用户需求的分析与获取用户需求有着相似的步骤，区别在于分析用户需求时使用模型来描述，以获取用户更明确的需求。

用于需求建模的方法有很多种，最常用的包括数据流图（DFD）、实体关系图（ERD）和用例图（Use Case）三种方式。DFD作为结构化系统分析与设计的主要方法，已经得到了广泛的应用，DFD尤其适用于MIS系统的表述。DFD使用四种基本元素来描述系统的行为，过程、实体、数据流和数据存储。DFD方法直观易懂，使用者可以方便地得到系统的逻辑模型和物理模型，但是从DFD图中无法判断活动的时序关系。

ERD方法用于描述系统实体间的对应关系，需求分析阶段使用ERD描述系统中实体的逻辑关系，在设计阶段则使用ERD描述物理表之间的关系。需求分析阶段使用ERD来描述现实世界中的对象。ERD只关注系统中数据间的关系，而缺乏对系统功能的描述。如果将ERD与DFD两种方法相结合，则可以更准确地描述系统的需求。

3.3编写规格说明书

项目视图和范围文档包含了业务需求，而使用实例文档则包含了用户需求。你必须编写从使用实例派生出的功能需求文档，还要编写产品的非功能需求文档，包括质量属性和外部接口需求。软件需求规格说明阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件，它不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。

采用软件需求规格说明模版：采用需求规格说明书模板在你的组织中要为编写软件需求文档定义一种标准模板。该模板为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。注意，其目的并非是创建一种全新的模板，而是采用一种已有的且可满足项目需要并适合项目特点的模板。

3.4需求验证

需求分析阶段的工作结果是开发软件系统的重要基础，大量统计数字表明，软件系统中15%的错误起源于错误的需求。为了提高软件质量，确保软件开发成功，降低软件开发成本，一旦对目标系统提出一组要求之后，必须严格验证这些需求的正确性。一般说来，要按以下步骤进行需求验证：

1）审查需求文档；2）依据需求编写测试用例；3）编写用户手册；4）确定合格的标准。

4.需求管理

需求开发的结果应该有项目视图和范围文档、使用实例文档、软件需求规格说明及相关分析模型。经评审批准，这些文档就定义了开发工作的需求基线。这个基线在客户和开发人员之间就构筑了计划产品功能需求和非功能需求的一个约定。需求约定是需求开发和需求管理之间的桥梁，需求管理包括在工程进展过程中维持需求约定集成性和精确性的所有活动。

5.企业人事管理系统

5.1企业人事管理系统概述

企业人事管理系统是针对企业人事方面的大量业务处理工作而开发的管理软件。根据用户的要求，实现人员基本情况管理、工资管理、和考勤管理等几个方面的功能。用户通过输入工资、考勤、职工履历等基本信息，由系统自行生成相应的统计数据及各类统计报表以供用户查询、打印。

5.2系统功能分析

系统开发的总体任务是实现企业人事信息关系的系统化、规范化和自动化。

系统功能分析是在系统开发的总体任务的基础上完成的。经过按照以上分析过程进行分析，分析出企业人事信息管理需要完成功能。

6.总结

以上详细介绍了软件需求分析过程。软件工程中包含需求、设计、编码和测试四个阶段，其中需求工程是软件工程第一个也是很重要的一个阶段，要想做好一个项目，必须先做好需求分析，需求工程分为了需求开发和需求管理两个阶段：需求开发又分为需求获取、需求分析、编写规格说明书和需求验证。需求管理就是对需求变更控制的过程。通过介绍企业人事信息管理系统的需求分析阶段，更好地说明了需求分析过程。

参考文献：

篇5：软件工程中软件需求分析的论文

关键词：面向对象；软件工程；软件需求分析

1软件工程

随着电子信息化的迅猛发展，软件工程涉及程序程序、语言、数据库、开发工具、设计模式等各方面的内容，主要是用来进行软件研究及软件分析的一门学科，软件工程师是专门进行软件开发的执行者，也可以根据所负责工作的不同划分为系统分析员、软件设计师、系统架构师及程序员等等。随着信息技术的不断升级，软件工程需要不断研究出新的产品、质量高的产，更能满足人们日常生活所需的软件产品。在这里明确指出的是，软件产品是指运用逻辑思维，将逻辑思维的结构与人们所期望的产品进行结合而研制出来的，是逻辑上存在的产品，并不是某一可以实实在在看到的物件。软件产品在使用过程中会面临许多逻辑上的错误，而且其更新换代非常快，存在很大的过时问题，其必然是需要根据时代的需求，人们的需求进行软件产品的不断更新，增加新的功能。同时，软件功能的实现是依靠用户的使用和软件的运行状态，具有一定的复杂性。

2软件需求分析具体过程

篇6：某项目的软件需求分析

软件可行性研究目的: 用最小的代价在尽可能短的时 间内确定该软件项目是否能够开发， 是否值得开发。设计分析 程序编写 测试移植 运行维护软件需求分析温州医学院附属眼视光医院信息中心王晓幸可行性研究经济可行性 技术可行性 社会可行性 方案的选择可行性研究成本C C C C经济可行性购置并安装软、硬件及有关设备的费用; 系统开发费用; 系统安装、运行及维护的费用; 人员培训费用效益C 系统为用户增加的收入或为用户节省的开支，这 是有形的效益 C 给潜在用户心理上造成的影响，这是无形的效 益。它可以转化为有形的效益。可行性研究技术可行性可行性研究法律可行性 用户操作可行性社会可行性开发的风险：在给出的各种限制范围内，能否设计出 开发的风险：在给出的各种限制范围内，能否设计出 系统，并实现必需的功能和性能? 资源的有效性：资源包括已有的或可以搞到的硬件、 资源的有效性：资源包括已有的或可以搞到的硬件、 软件资源，现有技术人员的技术水平与已有的工作基 础。 技术：相关技术的发展是否能支持这个系统? 技术：相关技术的发展是否能支持这个系统?1

可行性研究方案选择可行性研究报告背景 说明当前系统存在的问题 针对新的系统说明C 经济可行性 C 技术可行性 C 社会可行性 C 其它可选方案Report还有其它更好的方案吗 ?模板或者例子来源： www.google.com需求分析阶段关注的对象是 用户要求软件需求分析是软件生存周期中 决定性的一步在此之前，我们已经 有了可行性研究报告 和简要的开发计划软件需求分析的目标和任务通过调查分析, 理解用户要求 通过调查分析, 把用户的非形式的要求转化为完整的需求定义 再将需求定义转换为相应的形式的规格说明需求分析的过程目标和任务 通过调查分析, 理解用户要求 通过调查分析, 把用户的非形式的要求转化为完 整的需求定义 将需求定义转换为相应的形式的 规格说明 相应的过程问题识别 分析与综合 编制需求分析阶段的 文档需求分析评审2

需求分析的过程解决要求被开发软件做什么，做到什么 程度的问题 这些要求包括:功能要求、性能要求、 环境要求、可靠性要求、安全保密要 求、用户界面要求、资源使用要求、软 件成本消耗与开发进度要求 其它非功能性的要求:针对采用某种开 发模式，确定质量控制标准、里程碑和 评审、验收标准、各种质量要求的优先 级等，以及可维护性方面的要求。问题识别调查方式Cooperation制定调查提纲，向不同层次的用户发调查表 按用户的不同层次，分别召开调查会，了解用户对待开发系统 的想法和建议 向用户领域的专家或在关键岗位上工作的人个别咨询 实地考察，跟踪现场业务流程 查阅与待开发系统有关的资料 使用各种调查工具，如数据流图、任务分解图、网络图等需求分析的过程分析与综合参考当前系统建立目标系统模型获得当前系统的物理模型C 应客观地反映现实世界的实际情况抽象出当前系统的逻辑模型C 区分出本质的和非本质的因素建立目标系统的逻辑模型C C C 确定变更范围 将变化的部分看做是新的处理步骤，对数据流图进行调整 由外向里对变更部分进行分析，凭经验推断其结构，获得目标系统的逻辑模型。补充目标系统的逻辑模型C C C 说明目标系统的用户界面 说明至今尚未详细考虑的细节:启动和结束、出错处理、系统的输入输出和系统性能 等方面 其它:系统的其它必须满足的性能和限制等等需求分析的过程编制需求分析阶段的文档软件需求说明书：把分析人员和用户双方共同的理解和分析结果用规 软件需求说明书：把分析人员和用户双方共同的理解和分析结果用规 范的方式描述出来，作为今后各项工作的基础; 初步的用户手册：着重反映用户功能界面和用户使用的`具体要求。用 初步的用户手册：着重反映用户功能界面和用户使用的具体要求。用 户手册能强制分析人员从用户使用的观点来思考问题; 编写确认测试计划，作为今后确认测试的依据; 编写确认测试计划，作为今后确认测试的依据;需求分析的过程需求分析评审除分析员之外，用户/需求者，开发部门的管理者，软件设计、实现、测试的人员都应当参加评审工作。评审结束应有评审负责人的结论意见及签字。 评审结束应有评审负责人的结论意见及签字。修改和完善软件开发计划：更准确地估算开发成本、进度和资源需求 修改和完善软件开发计划：更准确地估算开发成本、进度和资源需求3

需求分析的过程目标和任务 通过调查分析, 理解用户要求 通过调查分析, 把用户的非形式的要求转化为完 整的需求定义 将需求定义转换为相应的形式的 规格说明 相应的过程结构化分析方法实质：是一种建模技术问题识别 分析与综合编制需求分析阶段的 文档需求分析评审结构化分析方法核心是数据词典：描述所有的数据对象 核心是数据词典：描述所有的数据对象 围绕着这个核心的有三种图C 实体D关系图(ERD) 描述数据对象及数据对象之 实体D 关系图(ERD) 间的关系，用于数据建模 间的关系，用于数据建模 C 数据流图(DFD) 描述数据在系统中如何被传送或 数据流图(DFD) 变换，以及描述如何对数据流进行变换的功能(子 功能)，用于功能建模 功能)，用于功能建模 C 状态D迁移图(STD) 描述系统对外部事件如何响 状态D 迁移图(STD) 应，如何动作，用于行为建模 应，如何动作，用于行为建模实体D关系图(ERD)： 实体D 关系图(ERD)： ----- 描述数据对象和之间的关系 描述数据对象和之间的关系复合信息的表示 可以是…打印机报表病历医务部刷卡医生取药窗口 可以是… 仅包含数据，没有操作 具有属性…医生：姓名职称出生日期专科权限 具有属性… 对象的实例有标志码 :Id员工代码住院号患者身份证 Id 员工代码 住院号 对象之间有一定的关系 》C 具有关联的基数和参与性 》号数据对象之间的关系对象之间具有关联的基数和参与性

篇7：浅论软件需求分析的论文

关键词：软件需求分析；过程；原则；工具；方法

1.软件需求分析的过程

软件需求分析的具体过程可分为软件需求目标的认定、分析与综合、制定规格说明和最终评审。首先来看如何对软件需求目标进行认定，软件需求的目标是指系统分析工程师和程序开发工程师在软件需求分析过程中，确定目标软件工程的综合要求，并提出实现这些要求所需要的条件，以及需求应达到的标准。这些需求具体包括：

（1）功能需求：列举出所开发软件在功能上应做什么。

（2）性能需求：给出所开发软件的技术性能指标。

（3）环境需求：软件系统运行时所处环境的要求。例如硬件环境：主机类型、外围设备、数据通信接口；软件方面：系统软件平台（包括单机操作系统、网络操作系统及应用软件、数据库管理系统等等）；以及使用部门在操作人员方面应达到怎样的条件。

（4）可靠性需求：按照实际运行环境对所开发的软件提出要求，尽量在需求分析阶段将所有的问题进行暴露。对于运行实效后可能产生的后果要有充分估计，应对软件运行的可靠性提出较高的要求。

（5）安全保密要求：在软件的需求分析过程当中应当对所开发的软件的安全性进行特殊设计分析，使其在实际开发完成之后的运行过程中安全性能得到必要的保证。

（6）用户界面的需求：对于用户界面的细致性以及易用性进行需求分析使其达到客户要求。

（7）资源使用需求：通过需求分析使得所开发的软件在运行时所需的系统资源处于用户可接受范围。

（8）软件成本消耗与开发进度需求：通过需求分析对软件开发的进度和各步骤的费用提出大致要求，作为开发管理的依据。

（9）最后对于所开发系统得最终所能达到的目标进行分析，以便在开发过程中对系统进行必要的修改与补充。在我们的需求分析过程中这些问题都是必需要得出分析结果的，并且结果应当得到软件开发工程师的认可。

在实际的软件需求分析中，单单依靠上述过程是不够的，有时候我们还需要通过对所得结论的分析与综合来得出工程系统的详细逻辑模型。

例如，在面向对象的软件工程当中进行软件需求分析时，通过对整个工程的需求进行分析，我们得出的仅是该软件工程的综合项目需求。这时就需要整理逻辑模型。在这个过程中，分析与综合工作需要反复的进行。而常用的分析方法有面向数据流的结构化分析方法、面向数据结构的Jackson方法（简称JSD法）、面向对象的分析方法（简称为OOA）等，以及用于建立动态模型的状态迁移图或Petri网等工具。

通过这一步之后，我们就可以将所得到的分析结果描述成软件需求规格说明书（简称SRS），并编写初步的标准格式用户手册。进行软件需求规格说明书以及标准格式用户手册时，不仅需要正确详实的需求分析数据，还需要较好的文字表达和组织能力。需求分析评审则是指在需求分析的最后阶段，对整个系统的需求分析工作给出其在正确性、完整性和清晰性等几个方面的最终评价。

2.软件需求分析的原则和工具

软件需求分析方法很多，其所使用的描述方法也各不相同，但他们都有着共同的基本准则。首先，他们都必须能够表达和理解问题所包含的数据域和功能域；其次，他们必须按照自顶向下、逐层分解的方式对问题进行分解和不断细化；最后，他们都要能够给出系统的逻辑视图和物理视图。这就说明在需求分析当中无论我们采取什么样的分析方法，都无一例外的会回归到对问题数据域与功能域的分析上来，并且对于问题的分析会自然而然的逐渐细化。

3.软件需求分析的方法

在软件需求分析中方法很多，不同的分析方法也都引入了不同的记号和分析策略。但与此同时，他们也具有着一些共同的性质，具体可以概括为：在支持数据域分析机制方面，所有的方法都直接或间接地涉及到数据流、数据内容或数据结构等数据域的属性。

多数情况下，数据流特征是用将输入转化为输出的变换过程来描述的，数据内容则用数据字典机制来明确表示，或者通过描述数据或数据对象的层次节后隐含地表示；在功能表示方法方面，功能一般用数据变换或加工来表示。还有在接口定义、问题分解的机制以及抽象的支持、逻辑视图和物理视图以及系统抽象模型方面都有着相同或相似的机制。在这里我们重点分析快速原型方法。在传统的软件工程方法学中，一贯强调的是自顶而下的分阶段开发，在每阶段实际开发之前必须对所开发项目进行严格要求的分析和定义。但实践表明，在系统建立起来之前很难仅仅依靠分析就确定出一套完整、有效的需求应用，并且这样预先定义的策略也无法适应用户需求的不断修正与变化。

由此，快速原型方法应运而生，他自顶向下的开发模式，是目前应用十分广泛的开发模式。快速原型方法是根据软件系统的需求快速产生出软件系统一个早期原形的过程。该原型能够表现出目标系统的功能和行为特征，但不一定符合其全部的实现需要。

通过这个方法，软件设计者可以利用原型得到系统可用性的反馈信息，未来用户也可以利用原型得到宝贵的早期经验。并且利用这样的一个快速原型尽早的获得更完整、更正确的需求与设计。

在软件的开发过程当中即使客户对于系统的要求发生了更改，也可以通过对原型就行改进而得到新的目标系统，不必再从头做起。而且在现实中存在的快速原型建造工具可以大大缩减创建系统的时间，可以在短期内迅速有效地建立起系统的原型，充分提高软件开发效率，提高软件质量、减少测试和调试的工作量，最终减少软件开发的总成本。

在快速原型法的实现过程中，由于建立原型的目的不同，实现原型的途径也有所区别，大致划分为以下三类：

（1）探索型。为研究探索而建立的原型。主要强调澄清目标系统的需求及所要求的特征。

（2）实验型。为实验而建立原型。主要强调在正式进行目标系统的大规模开发工作之前，通过建立原型来确定所提出的解决方法是否恰当。这种原型方法通常针对用户的问题的某个方案做出原型以供试验评估，该原型所实现的功能与最终产品的功能是有差别的。

（3）进化型原型。为演示而建立的原型。主要强调通过逐步的分析改进使系统适应变化了的需求。并最终生成一个演进式的系统开发模式。当采用进化型原型方法时，必须进行原型与产品间的变换，除了在开始阶段时采用单独的研究探索性原型方法及实验性原型方法外，圆形的生产环境必须与产品的生产环境集成在一起。

总而言之，快速原型法是具有相当大优势的。因为它可以为开发出较为有用的系统做出极大贡献，并且不会增加总的软件开发费用，开发原型所增加的投资可以因减少误解而节省下来。

参考文献：

[1]王继成,高珍.软件需求分析的研究[J].计算机工程与设计,2002,(8):18-21.

篇8：关于软件工程需求分析探究

一、软件工程中的需求分析概述

一个软件项目的开发主要分为五个阶段:需求分析阶段、设计阶段、编码阶段、测试阶段和维护阶段。而需求分析阶段所得到的结果。是软件项目开发中其他四个阶段的必备条件。从以往的经验来看, 需求分析中的一个稍稍的偏差, 就可能导致整个项目无法达到预期的效果。

需求分析是指理解用户需求, 就软件功能与客户达成一致, 估计软件风险和评估项目代价, 最终形成开发计划的一个复杂过程。在这个过程中, 用户的确是处在主导地位, 需求分析工程师和项目经理要负责整理用户需求, 为之后的软件设计打下基础。需求分析阶段结束后, 要求得到:1.SRS文档 (System Requirement Specification) ;2.DRM文档;3.Acceptance Plan。从广义上理解需求分析则包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。

二、软件工程中的需求工作流程

软件需求是指用户对目标软件在功能、行为、性能、设计约束等方面的期望。通过对问题及其环境的理解与分析, 为问题涉及的信息、功能及行为建立模型, 将用户需求精确化、完全化, 最终形成需求规格说明, 如图1所示, 整个活动构成软件开发生命周期的需求分析阶段。在需要的开发中, 问题的获取包括业务需求、用户需求、功能需求。业务需求的参与者主要是业务流程分析员, 对企业目前的业务流程进行评估, 确定进行何种程度的业务建模;用户需求重心是如何收集用户需求, 确定角色和用例, 获取需求的方法倾向组织访谈会;功能需求依赖于用户需求, 是用户需求在系统上的一个映射, 为用户做一个软件原型是一个很好的方法。

三、软件工程中的需求分析

需求分析包括提炼、分析和仔细审查已收集到的需求, 以确保所有承担风险者都明白其含义, 能找出其的错误、遗漏等地方。分析员通过评价来确定是否所有的需求和软件需求规格说明都达到了优秀需求说明的要求。分析的目的在于开发出高质量的需求, 这样你能做出实用的项目估算并可以进行设计、构造和测试。通常, 把需求中的一部分用多种形式来描述, 如同时用文本和图形来描述。分析这些不同的视图将揭示出一些更深的问题, 这是单一视图无法提供的。分析还包括与客户的交流以澄清某些混淆, 并明确哪些需求是更为重要的。其目的是确保所有风险承担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。

1. 创建数据字典。

数据字典是对系统用到的所有数据项和结构的定义, 以确保开发人员使用统一的数据定义。在需求阶段, 数据字典至少应定义客户数据项以确保客户与开发小组使用一致的定义和术语。分析和设计工具通常包括数据字典组件。

2. 确定需求的优先级别。

应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时, 在特定的版本中加入每一项变更, 并在那个版本计划中做出需要的变更。

3. 分析需求可行性。

在允许的成本、性能要求下, 分析每项需求实施的可行性, 明确与每项需求实现相联系的风险, 包括与其它需求的冲突, 对外界因素的依赖和技术障碍。

4. 使用质量功能调配。

质量功能调配是一种高级系统技术, 它将产品特性、属性与对用户价值联系起来。该技术提供了一种分析方法以明确哪些是客户最为关注的特性。质量功能调配将需求分为三类:期望需求, 即客户或许并未提及, 但如若缺少会让他们感到不满意;普通需求和兴奋需求, 即实现了会给客户带去惊喜, 但若未实现也不会受到责备。

5. 衡量需求稳定性。

记录基本需求的数量和每周或每月的变更数量 (添加、修改、删除) 。过多的需求变更“是一个报警信号”意味着问题并未真正弄清楚, 项目范围并未很好的确定下来或是政策变化较大。

6. 绘制系统上下文示意图。

这种示意图是用于定义系统与系统外部实体问的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。

7. 作为功能需求的补充, 软件需求规格说明还应包括非功能需求, 它描述了系统展现给用户的行为和执行的操作等。

它包括产品必须遵从的标准、规范和合约;外部界面的具体细节;性能要求;设计或实现的约束条件及质量属性。

软件需求分析中的关键就是展开分析、发现问题、征服问题。所有的一切都是为了能够将软件中的错误和漏洞在需求分析和需求工程阶段发现并解决, 这样才能使软件开发的成本收益比达到最大, 使得软件在其生命周期中的维护费用降到最低, 这也是我进行软件需求分析方法研究的目的, 希望可以通过上述的软件需求分析的方法研究为以后软件的开发打下一个良好的基础。

摘要：我国的信息化已经走过了20多年的历程, 但许多软件开发公司仍不得不在收集、编写和管理产品需求中疲于奔命。而缺乏用户参与、不完整的需求及不断变更需求, 是导致信息技术项目不能按进度安排和资金预算完成全部功能的主要原因。

关键词：用户,软件开发,软件工程

参考文献

[1]郑人杰等:实用软件工程 (第2版) , 北京:清华大学出版社, 1997

[2]史济民等:软件工程一原理、方法和应用, 北京:高等教育出版社, 2002

[3]Pres smaI1:软件工程一实践者研究方法 (第4版) .北京:机械工业出版社.1999

[4]张龙祥:UML与系统分析设计.北京:人民邮电出版社, 2007