软件需求分析师简历

软件需求分析师简历（通用9篇）

篇1：软件需求分析师简历

，

4、 有较强的文档编写能力;熟悉CMM文档规范者优先;

5、 良好的英语读写水平，有独立查阅英文专业资料的能力;

6、 需有较强的团队协作精神。有效的沟通技巧，在团队协作中具有精炼思维和解决复杂问题的能力，具备良好的学习能力，责任心强，能够承受较大的工作压力;

篇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：软件需求分析的思考

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

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

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

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

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：软件需求分析师的基本职责

1、主持或参与公司产品和业务规划工作，为公司产品和业务规划提供专业的分析与意见。

2、主持或参与公司重大软件产品或项目的需求调研与分析、系统整体设计与详细设计工作。

3、指导项目开发，指导系统安全性分析与设计，并控制项目质量与进度。

4、负责项目售前阶段市场需求的调查及分析，指导可行性研究报告的编制，指导项目的申报与立项。

5、参与新业务新领域的前期调研与分析工作，与项目或产品人员进行产品设计工作，参与编写项目调研报告和

基本要求

1、大专及以上学历，计算机相关专业者优先。

2、熟练掌握office办公软件、熟悉软件工程过程或互联网产品开发工程;有意向往需求分析方面发展;有需求分析工作经验者优先;

4、有优秀的文字表达、业务理解、交流能力，能独立编写需求文档。

5、良好的自我学习能力;

篇7：软件需求分析师的职位职责

1. 参与用户需求调研、需求讨论、需求分析、需求跟进。

2. 参与后期系统开发过程解释及协调工作。

3.编写需求分析文档，完成功能、流程、界面设计。帮助主设计人员理解需求分析。

4.负责及协助设计人员与用户之间的沟通工作。

5. 用户手册编写与用户培训。

6. 可参与部分测试用例设计。

7.对需求变更进行影响分析，把控项目开发进度

任职要求：

1. 大学本科及以上学历，计算机及相关专业。

2. 2年以上相关工作经历。1年以上保险/金融行业相关项目工作经验。

3.熟悉软件开发过程，熟悉保险运作原理、熟练操作Office、Visio等办公软件。

4.精通Axure 软件的使用，有一定原型设计能力。

篇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

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

在学校建立和完善网络的同时，教育软件的应用业已成为这些已经建立自己校园网的学校目前最为关注的问题。“校校通”工程更是进一步推进了教育软件市场的发展，据赛迪顾问调查，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％的教师表示非常需要教育软件来辅助教学。这说明，目前的教学软件还远远不能满足需求。

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