需求分析下软件工程论文

需求分析下软件工程论文（通用8篇）

篇1：需求分析下软件工程论文

需求分析下软件工程论文

1软件工程需求分析的问题

软件工程需求分析最大的问题是开发方和使用方对于软件工程需求分析的轻视，在开发过程中存在着一定的盲目性、急功近利性，致使软件的开发难以满足用户应用需求，甚至一些软件开发到了后期，用户才提出新的需求要求，导致软件工程质量难以保证，工期被迫延长，可见软件工程需求分析的重要性;在软件工程需求分析方案的制定中缺少用户的参与，对于需求分析的收集、编写、管理等环节也多为系统分析员、软件工程师一手包揽，致使软件工程的需求分析存在了一定的空想性、不切实际性，使开发方开发的软件产品缺乏实际应用价值，难以满足用户需求;开发人员与用户在开发之初对于系统需求分析的重要性认识不清，双方的交流、沟通容易发生误解，致使其对软件系统用来“做什么”理解不准确，致使软件开发中问题很多，变更频出，影响了软件开发的效益;软件工程需求分析对于客户需求论述的不完整、不准确，且开发过程中用户需求不断变更，致使软件工程分析方案的制定存在一定的难点和问题。因此，在实际操作中，可以将两者灵活运用，结合起来，即确保了需求调查的准确性，又提高了需求调查的效率。此外，还可以采用回忆座谈、表格调查等方式，以提高用户需求调查的准确性，确保为用户需求分析提供有效的、全面的、准确的分析资料。再次，注重系统后期的需求分析方案的完善，协助用户明确系统要求，对系统的应用环境、信息处理特点等，与用户进行全面的、完整的沟通，以确保软件工程需求分析的最大准确性、科学性，确保软件系统开发者的效益。

2软件工程需求分析方案的制定

在软件工程需求分析方案的制定中，首先，要明确软件编写的目的，一方面，要对软件工程的编写背景进行深入的、全面的调查和了解，以准确确定软件编写的目的。例如，软件工程开发的背景是用户为解决分散管理，数据易丢失等问题，那么软件工程的需求就应向数据共享、规范管理方面考虑，以解决用户工实际工作中的各种问题。另一方面，通过各种手段调查、了解用户需求，以用户的使用目的为参考依据进行软件工程需求分析。例如，在学籍档案管理中，软件系统的功能是准确管理学生档案，对学生的情况进行真实的、可靠的记录，同时还要确保修改的方便，对学生奖罚等情况的及时记录、修正等等，在了解了用户的使用范围和功能要求的基础上进行用户需求分析，能更好地抓住用户的使用心态，提高软件产品的质量和性能。其次，明确用户对软件系统的性能要求，合理的设计用户权限，备份和恢复功能等，确保系统数据的长期性、全面性和正确性，确保系统的便于操作、无故障运行。一方面，注重系统应用的安全性、可靠性设计，对用户权限、使用目的等进行深入分析，以确保用户重要信息资源的安全共享。例如，酒店软件系统开发中，点菜权限只需要使用系统的菜名、价位等数据，对于菜品的成本价钱等无需让点菜服务人员知晓、更不能随意更改菜品单价、打折等状态，在权限设计上就可以加以控制，以避免用户不必要的信息流失或信息泄露等问题，同时应避免不相关用户登录后对数据的随意更改，这些都需要用户权限予以约束。另一方面，应注重用户使用平台的`要求分析，例如用户使用的运行环境，如XP与windows7的系统运行环境是有所区别的，只有准确了解用户使用的运行环境，才能为题更好地提供各种软件服务，使软件产品更符合用户使用需求。再次，提高对软件产品层次概念的理解，从不同角度挖掘系统工程需求的细节问题，对软件工程开发的各个层次进行科学、细致的分类，准确把握用户需求。例如，在编写用户需求图示或需求文档时，可按照用户对产品的使用频度、用户对产品的需求特点等进行，以便更准确地掌握不同层次的用户需求，开发更合理、更使用的软件产品。另一方面，科学选择产品的用户代表，针对用户和开发者的接口进行需求分析，绘制关联图，有效地创建开发原型，并研究软件工程需求分析可行性，在进入实施阶段，确保软件工程需求分析环节的准确、有效、科学。总之，认真、严格地把握软件工程需求分析中需求分析、总体概述、具体要求、软件质量特点等等环节，建立全面的、真实的、科学的用户需求分析模型，使软件工程需求分析能够为软件的开发提供可靠的指导依据。

篇2：需求分析下软件工程论文

项目名称：学生智能管理系统一、引言：

1、编写目的：

对庞大的信息随着学校的规模不断扩大，学生数量急剧增加，有关学生的各种信息也成倍增长。有必要开发学生信息管理系统来提高学生管理工作的效率。通过这样的系统，可以做到信息的规范管理、科学统计和快速查询，从而减少管理方面的工作量，同时也可以方便学生对信息的获取。

学生信息系统也是实现学校管理现代化和信息化的重要内容。因此，学生信息管理系统应该能够为用户提供充足的信息和快捷的查询手段，并且，面对学生生活的不断丰富化，各种小方面管理软件的泛滥，身为学生以及考虑学校本身管理的多方面的统一。本小

组所开发系统是基于C/S结构，使用 Visual Basic程序设计语言及SQLServer2000数据库进行设计与开发。

本系统针对软件界面的人性化，生活化，做了突破性的工作，以及多项管理功能的集成上作了初步的拓展，目的在于使管理者和访问者易于甚至乐于接受，并提出学校管理系统的一体化概念，使学校的管理更有效率。

2、定义：

（1）静态数据：系统内部有关的数据结构和操作规程

（2）动态数据 ：程序运行时输入和输出的数据

（3）数据字典： 数据字典(DD，Data Dictionary)是关于数据流

程图中出现的所有名字（数据流、处理、数据存储）的定义的集合。

3、参考资料：

[1]张向宏.软件生命周期质量保证与测试.北京：电子工业出版

社.2009 [2]张海藩.软件工程导论.北京：清华大学出版社.2005 [3]张焕君.基于VB和SQL的数据库编程技术.北京：清华大学出版

社.2008

二：任务概述：

1、目标:（1）给出软件系统的数据流程图和数据结构。

（2）提出详细的功能说明，确定设计限定条件，规定性能需求。

（3）密切与用户的联系，使用户明确自己的任务，以便实现上述两项

目标。

（4）以最低的成本，在最短的期限内开发出具有管理学生和学生信息

功能的智能管理系统。（包括：人力与设备费用的节省；处理速

度的提高；人员工作效率的提高）

2、用户特点：

本系统所面向的用户是大学学生和教师，对用户计算机专业方面的知识要求不是很高，只要对电脑能熟练操作就ok。易于操作，这也是本软件设计的一大目标。

3、条件与限制：

（1）建议该系统运行的最短寿命为5年；

（2）进行该系统方案选择比较的期限为2个月；

（3）建议该系统软件投入使用的最迟时间为2009年12月20日；

（4）该系统要受资金、寿命、社会等系列因素的制约和限制。

（5）由于系统较小，且在Windows系统开发，故在Windows环境下运

行没有什么限制。

三：数据描述:

1、静态数据：

静态数据是系统内部有关的数据结构和操作规程。具体包括：系统用户表格、学生基本信息表格、班级信息表格、课程基本信息表格、年级课程设置信息表格、学生成绩信息表格……

2、动态数据：

动态数据包括程序运行时输入和输出的数据，具体是数据库的各个表的各个不同元素与属性值，就是学生信息。

3、数据描述：

根据上面的分析就可以设计出能够满足用户需求的各种数据实体，以及它们之间的关系，为后面的逻辑结构设计打下基础，这些实体包括各种具体信息，通过相互之间的作用形成数据的流动。

本系统的实体有：学生实体、课程实体、日常工作实体、教师实体。各个实体具体的描述E_R图如下：

日常安排活动通知系内工作姓名性别督办日常工作执行成绩日常记录档案联系教师教学生学证件课程部门教师任课表（学期）课程安排表（学期）教学进度安排表专业核心课程个学期周数分配表

4、数据字典:

（1）数据流条目——数据流条目给出某个数据流和定义，它通常是列 出该数据流的各组数据元素。

该系统的数据流条目： 数据流名：学生

别名 ：无

组成 ：学号+姓名+性别+个人电话+家庭电话+籍贯+系别+ 年级+班级+备注 数据流名：教师 别名 ：无

组成 ：证件号码+姓名+性别+个人电话+系别 数据流名：课程信息 别名 ：无

组成 ：课程编号+课程名称+课程类型+任课老师+上课时间+课

时+学分

数据流名：学生成绩信息

别名 ：无

组成 ：考试编号+学生学号+学生成绩

数据流名：学生课余活动信息

别名 ：无

组成 ：活动编号+活动名称+活动时间+活动类型+参 与院系

（2）数据存储条目—— 对数据存储的定义

文件名：学生记录

别名 ：学生信息

简述 ：存放所有学生信息

组成 ：学生信息文件={学生基本信息记录}+{学生成绩记录}+{学生 课余活动信息记录}+{学生课程信息记录} 组织：按学生学号编排

存取要求：关键字是：学生学号+课程号+活动编号

查询要求：要求能立即查询

文件名：教师记录

别名：教师信息

简述：存放所有的教师信息

组成：教师信息文件=｛教师基本信息记录｝

组织：按教师证件号编排

存取要求：关键字是：教师证件号

查询要求：要求能立即查询

（3）数据项条目——给出某个数据单项的定义，通常是数据项值类型。

数据项名：学生学号

别名：无

取值：8｛数字｝8 注释:无

数据项名：年级

别名：无

取值：〔Ｆ｜Ｍ｜Ｊ｜Ｓ〕 Ｆ－freshmen, 一年级

Ｍ－sophomore,二年级

Ｊ－junjor, 三年级

Ｓ－senior, 四年级

注释:F,M,J,S可分别用1,2,3,4代替 数据项名：系和班级编号 别名：无 取值：8｛数字｝8 注释：无

数据项名：课程编号 别名：无 取值：8｛数字｝8 注释：无

数据项名：活动编号 别名：无 取值：6｛数字｝6 注释：无

数据项名：考试编号 别名：无 取值：8｛数字｝8 注释：无

数据项名：教师证号 别名:无

取值：11｛数字｝11 注释：无

（4）处理说明条目——给出数据流程图中不分解的变换处理说明定义。

处理名：查阅学生信息库

激发条件：接受到有效用户名和密码

优先级：普通

输入：用户名和密码

输出：学生信息

加工逻辑：根据学生信息库记录 IF输入用户名和密码有效 THEN显示学生信息

ELSE请重新输入（最多三次）ENDIF

（5）数据流图

输入用户名和密码分析用户类型输入用户类型分析用户名有效和密码用密户名码和注册用户名和修改密码用户显示结果学生信息添加及删除反馈给用户系统界面输入有效命令修改用户名及密码学生添删密码修改用户注册表处理命令学生选课选课密码修改学生信息表存储修改信息修改学生课程表学生成绩及信息查询查询密码

5、数据采集:

系统数据采集是由数据库系统在软件运行期间通过人机界面来提示用户输入的。

四：需求规定：

1、功能需求：（1）对功能的规定

1）学生管理功能： a、修改当前登录用户的密码。

b、可以浏览，查看，搜索页面信息。

2）教师管理功能： a、教师可以在线浏览，查看，搜索各类页面。

b、可以在线添加、删除、修改学生各种信息。c、可以在线通知学生各种消息。3）管理员管理功能：a、可以进行学生资料录入

b、可以对学生信息查询、修改、删除、添加。

（2）功能描述：

1）登录功能：验证登录用户是否为数据库中的合法用户，判断登陆的用户是一般学生还是教师。一般学生只能实现浏览，查看，搜

索功能；教师可以查看、修改、添加、删除学生某方面的信息。管理员可以对用户信息进行修改。

2）主界面功能：可以浏览学生各方面的信息，还可以进入登陆页面，可以查找某个学生信息。

3）用户管理功能：管理员（即超级用户）可以添加新的用户以及修

改当前登录用户的密码。也可实现登录用户的重新登录和退出，可以修改学生信息。一般学生则可以浏览，搜索，查看各种信息。

2、性能需求：(1)对性能的规定

1）精度：查询时应保证查询率，所有在相应域中包含查询关键字的 记录都应能查到，同时保证准确率。

2）时间特性要求：一般操作的响应时间应在1－2秒内。

3）适应性：满足运行环境在允许操作系统之间的安全转换和与其它

应用软件的独立运行要求。

4）灵活性：在需求发生变化时，本系统的对这些变化的适应能力相

对而言是比较强的，包括操作方式上的变化；运行环境 的变化；同其他软件的接口的变化；精度和有效时限的变化。(2）功能结构图

学生智能管理系统行政楼3#实验楼图书馆教学楼大学生活动中心邮局师生互动教务处电信系办公室电信系辅导员办公室

3、运行需求:（1）用户界面

系统运行时主界面大致要求为Windows的经典运行界面，主界面可以是SDI(单文档界面)即每个窗体之间是独立的，也可以是MDI（多文档界面）：有一个主窗，可以包含其他窗体。本系统采用多文档界面，这样可以使程序更加美观，整齐有序。（2）硬件接口

软件较小除硬盘外，还有DVD光驱，打印机等。（3）软件接口

在这里主要考虑软件与操作系统的接口，考虑到文档处理的需要有可能可以包括与较常用的办公软件的接口。

（4）开发环境

操作系统： WindowsXP或更高

数据库类型：SQL Server 2000 CPU：P2000mmx以上，内存大于64M。

需要建立WEB服务器

（5）故障处理

在用户的输入有错误的情况下，对于用户的输入错误应给出适当的改正提示。若运行时遇到不可恢复的系统错误，也必须保证数据库

完好无损。

4、界面需求：

(1）登录界面：验证登录用户是否为数据库中的合法用户，选择登录的用户是一般学生还是教师。一般学生只能实现浏览，查看，搜

索功能；教师可以查看、修改、添加、删除学生某方面的信息。管理员可以对用户信息进行修改。

(2）主界面：可以浏览用户各方面的信息，还可以进入登录页面，可以查找某个学生信息。

（3）注册界面：用户可以在主界面上选择注册，进入注册界面，填写用户基本信息（名字、班级、年级……）。

5、其他需求：

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

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

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

需求分析是指理解用户需求, 就软件功能与客户达成一致, 估计软件风险和评估项目代价, 最终形成开发计划的一个复杂过程。在这个过程中, 用户的确是处在主导地位, 需求分析工程师和项目经理要负责整理用户需求, 为之后的软件设计打下基础。需求分析阶段结束后, 要求得到: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

篇4：需求分析下软件工程论文

关键词：双向协同；物资需求计划管理；电网事业；实践分析

中图分类号：F426.61 文献标识码：A 文章编号：1006-8937（2013）18-0060-02

1 物资需求计划及其在电网工程中的现状

1.1 物资需求计划原理

物资需求计划主要是根据客户订单，通过预测来安排生产计划的一种库存控制手段，在制造企业中应用相当广泛，但在电网工程中的应用比较有限。其工作原理就是以用户订单为基础，分析当前市场需求，制定出适宜的生产计划，然后结合产品结构及库存状况，借助计算机技术对所需物资的时间和数量进行计算，最终确定生产进度。此管理模式经不断发展，应用范围越来越广，从生产计划、库存物资管理逐渐向物流、资金流以及信息流等扩展。

1.2 物资需求计划在电网企业中的现状

首先，电网企业结构庞大，管理工作十分困难，需要耗费大量的时间，而且其生产计划涉及诸多方面，往往需要根据实际情况进行适当的调整，波动较大。由于各地的经济、技术等条件都有差异，不确定因素较多，需求也就难以统一，对设备的各项参数需求也大大不同，给项目工程的物资需求带来很大的不确定性。其次，由于诸多不确定因素存在，各个企业的所需物资都有各自的标准，电力设备的型号也不尽相同，以至于物资种类繁多，且没有统一的标准，难以具体分类，管理起来相当复杂，而且其管理缺乏标准化、规范化，很容易出现混乱。

此外，在电网企业中，工程项目和物资管理往往是相互独立的，缺乏应有的交流，由于协调性不好，导致信息不够通畅，因而很难及时获得所需信息，且对信息的准确度和安全性也有一定程度的影响。

1.3 电网工程中物资需求的特点

电网工程项目涉及很多程序和部门，工作量大，要保证整体质量，需要各部分有极好的协调性。由于物资种类繁多，受外部环境的影响较大，物资清单缺乏统一的标准，单件性较为明显，不具备批量复制性，而且整体管理比较困难，周期很长。

基于以上特点，在引进物资需求计划管理模式时，应结合电网工程的实际需求和具体情况做适当的调整。

2 物资需求计划的协同管理

在电网企业中，由于部门众多，事务繁杂，物资计划管理部门在工作中应该和其他部门多多交流，加强彼此间的沟通，进行协调管理，增强整体协调性，以获得更准确的信息。

2.1 降低物资需求的不确定性

由于电网工程受外部环境影响较大，存在着很多不确定因素，物资需求计划的准确性成了关注的重点。该管理模式主要是靠预测对生产进度等做决定的，所以首先要保证预测的准确性。需求预测主要涉及需求内容、数量和时间等，其中，需要什么物资及多需物资的数量主要由设计部门负责，而物资的到货时间则由工程部门确定，这就要求在计划管理中，务必要做好双向协同工作。

具体来说，可采取工程计划安排倒推法，严格遵循电网规划，从最终的投产日期往前推，进而确定工程的合理开始日期。倒推法能够从整体上把握各个环节的起止时间，从而制定相应的计划，保证各个环节能够顺利进行，此外，由于电网工程和物资需求计划具有相互独立性，很容易延长到货期限，增加额外成本，倒推法可在一定程度上减少这种情况的发生。

物资需求信息是建立在设计单位的基础上的，所以在工程中的每一个环节都应由设计单位提出相应的物资清册，在项目建设中根据所需对其进行调整修订，以减少管理中的不确定因素。

2.2 实现物资的标准化

因电网工程中的物资需求缺乏标准化，所以首先要加强标准化建设，如根据不同的要求将物资分类，尽量统一其采购标准；同时应加大通用设计应用的推行力度，尽快建立起结构物资清单，并将物资采购标准延伸至设计源头。

①物资需求计划能否发挥其最大作用，和物资清单是否标准化有很大关系，在电网工程中，企业应根据各自的类型和环境来选择相适应的型号，以及各项参数，建立起独有的物资采购标准，并在此标准范围内进行各种选择，进而减少差异。

②电网工程项目具有明显的单件性，直接导致了其物资清单的单件性，对项目工程的电压容量、等级等因素进行对比，针对类型不同的项目，可提前设计好相应的结构化物资清单，对采购范围进行初步把握，以便物资部门采取合理可行的采购策略。

③设计部门在电网工程中的作用极其关键，物资需求信息多由该部门确定，必须加强沟通，与其建立合作关系，将物资采购标准的应用扩及到设计环节，避免以后建设中的来回转换，有利于减少工作量，提高工作效率，而且为物资使用的规范性也提供了良好的保障，有利于规模采购。

3 完善预警机制，降低风险

3.1 预警计划

对电力企业而言，其采购计划通常有批次计划和年度计划两种，年度计划主要是从整体对年度的购买状况进行的规划，批次计划则可看做是其分计划，是对整个采购计划的具体执行，所以必须对批次计划进行有效管控，保证其精确度，唯有如此，才能实现精确的物资采购和配送。电力企业以物资信息储备库为平台，建立并完善预警机制，使其能够按照计划安排提出合理的时间。此外，为保持物资流、资金流和信息流之间的一致，应实现项目计划和预算系统以及计划执行单元三者间的联动，进而发现其中存在的差异，并及时发送有违于采购计划的预警报告，对其中的差异和问题加以分析解决，避免缺货的情况发生，降低风险。

3.2 预警库存问题

因电网工程中的不确定因素较多，库存中的数据常会发生动态变化，这些数据包括总需求量、净需求量、库存量以及订货情况和一些盘点记录，通过对这些数据的收集掌握，才能进行合理的物资计划管理，提高库存整体水平，为保证库存数据的精确度，应采取相应的方法，如准确预测总需求量，实时对库存量进行盘点，一旦出现数据的变化，应及时更新；对一些尚未得到解决的订货进行追踪更新，实时把握其动态，从而更好地对物资采购管理情况进行监控；物资的入库和使用要有规范的程序，对以往先领料后入系统的方式加以改进，且领料必须有单据凭证，保证物资的流转情况能够及时准确地反映在系统中。

4 结 语

物资需求计划管理在电网工程建设中发挥着重大作用，有利于提高电力企业的工作效率，降低成本，必须加以重视，不断完善，针对现阶段出现的问题，应及时解决。

参考文献：

[1] 邬斌弢，张玉鑫.基于双向协同的物资需求计划管理在电网工程中的应用研究[J].华东电力，2012，（5）.

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

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

1软件工程

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

2软件需求分析具体过程

篇6：软件需求-案例分析

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

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

操作 预约验证 参与主体

对应需求

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

篇7：需求分析下软件工程论文

一.编写目的……………………………………………………………………………………3 1.1预期的读者和阅读建议………………………………………………………………3 1.2背景及范围……………………………………………………………………………3 1.3参考资料………………………………………………………………………………3 二.综合描述……………………………………………………………………………………3 2.1 产品的前景…………………………………………………………………………3 2.2 用户类和特征………………………………………………………………………4 三.功能需求……………………………………………………………………………………4 3.1 需求规定……………………………………………………………………………4 3.2 功能分类……………………………………………………………………………5 3.3 具体需求……………………………………………………………………………6 四.非功能需求…………………………………………………………………………………15 4.1 性能需求…………………………………………………………………………15 4.2 属性…………………………………………………………………………………15 4.3 其他需求……………………………………………………………………………15

/ 15

一.编写目的

本需求的编写是为了研究图书管理系统软件的开发途径和应用方法。同时它也是进行项目策划、概要设计和详细设计的基础，是维护人员进行内部维护，信息更新，验收和测试的依据

1.1预期的读者和阅读建议

本需求的预期读者是我院图书馆管理员，部分学员。

1.2背景及范围

本项目的名称：图书馆管理系统。

本项目的任务提出者及开发者是图书管理系统软件开发小组,用户是学院图书馆及相关读者。

本产品是针对电脑管理图书的需求设计的，主要包括管理员管理模块和学员自助服务模块。其中，管理员管理模块可以完成读者登记、购入新书、图书检索、读者借还书、图书注销等主要功能，学员自助服务模块可以完成学员电子阅读，图书检索功能。

1.3参考资料

《软件工程导论》——张海藩 编著 清华大学出版社

二.综合描述

为方便对图书馆书籍，读者资料，借还书等进行高效的管理，特编写该程序以提高图书馆的管理效率。使用该程序后，图书馆管理人员可以管理读者的登记，图书的购入、借出、归还以及注销等；还可以查询某位读者、某本图书的借阅情况，对当前借阅情况给出一些统计，给出统计表格，以全面掌握图书的情况。

2.1 产品的前景

/ 15 图书馆在正常运营中面对大量书籍、读者信息以及两者间相互联系产生的借书信息、还书信息。现有的人工记录方法既效率低又错误过多，大大影响了图书馆的正常管理工作。因此需要对书籍资源、读者资源、借书信息、还书信息进行管理，及时了解各个环节中信息的变更，有利用管理效率的提高。本系统通过强大的计算机技术给图书管理人员和读者借、还书带来便利。

产品的功能

(1)读者信息的制定、输入、修改、查询，包括种类、性别、借书数量、借书期限、备注。

(2)书籍基本信息制定、输入、修改、查询，包括书籍编号、类别、关键词、备注。

(3)借书信息制定、输入、修改、查询，包括书籍编号、读者编号、借书日期、借书期限、备注。

(4)还书信息制定、输入、修改、查询，包括书籍编号、读者编号、还书日期、还书期限、备注。

(5)有条件、多条件查询各种信息.2.2 用户类和特征

本系统的最终用户有三种：一是管理员（图书管理员和其它管理人员），他们可以删除图书信息、删除或增加学生信息等；二是读者（老师和同学等），可以查看他们的借阅信息。他们都具有一定的计算机应用基础，可以比较熟练操作计算机；三是系统维护人员为计算机专业人员，熟悉数据库、操作系统、网络维护工作。管理员和读者都是经常性用户，维护人员为间隔性用户。

三.功能需求

3.1 需求规定

在图书管理系统中，管理员要为每个读者建立借阅账户，并給读者发放不同类别的借阅卡（借阅卡可提供卡号、读者姓名），账户内存储读者的个人信息和借阅记录信息。持有借阅卡的读者可以通过管理员（作为读者的代理人与系统交互）借阅、归还图书，不同类别的读者可借阅图书的范围、数量和期限不同，可通过互联网或图书馆内查询终端查询图书信息和个人借阅情况，以及续借图书 3 / 15（系统审核符合续借条件）。

借阅图书时，先输入读者的借阅卡号，系统验证借阅卡的有效性和读者是否可继续借阅图书，无效则提示其原因，有效则显示读者的基本信息（包括照片），供管理员人工核对。然后输入要借阅的书号，系统查阅图书信息数据库，显示图书的基本信息，供管理员人工核对。最后提交借阅请求，若被系统接受则存储借阅纪录，并修改可借阅图书的数量。归还图书时，输入读者借阅卡号和图书号（或丢失标记号），系统验证是否有此借阅纪录以及是否超期借阅，无则提示，有则显示读者和图书的基本信息供管理员人工审核。如果有超期借阅或丢失情况，先转入过期罚款或图书丢失处理。然后提交还书请求，系统接受后删除借阅纪录，并登记并修改可借阅图书的数量。

图书管理员定期或不定期对图书信息进行入库、修改、删除等图书信息管理以及注销（不外借），包括图书类别和出版社管理。为系统维护人员提供权限管理、数据备份等通用功能。

3.2 功能分类

/ 15

图书馆信息系统参数设置基础信息管理管理员设置书架设置图书词库设置新书购入管理子系统学生借书学生还书图书馆管理系统系统登陆图书注销学生信息查询查询子系统图书信息查询

/ 15 3.3 具体需求

系统的总体图

图书馆管理人员用户名和密码1登陆信息验证输入管理请求数据2处理管理请求数据显示显示器密码错误信息当前日期系统时钟管理员表当前日期用户输入查询信息3处理查询请求数据查询结果

第一层图：

（1）：登陆子系统

图书馆管理人员用户名和密码1.1密码验证用户名1.2验证权限显示器登陆错误信息权限显示管理员表1.3显示可用的控件和界面 6 / 15

（2）管理子模块

/ 15 图书馆管理人员输入购入新书数据2.1处理新书购入非法信息图书目录文件入库单退货单输入图书字段和学生字段罚款单接受借书2.2处理学生借书输入图书字段罚款单非法信息当前日期学生文件借书文件显示器当前日期输入注销图书字段2.3处理学生还书欠款金额信息非法信息还书成功当前日期罚款单图书目录文件非法信息2.4图书注销注销成功当前日期系统时钟

（3）查询模块

/ 15 图书馆管理人员|学生输入学生查询关键字3.1学生信息查询学生信息学生文件借书文件显示器输入图书查询关键字图书目录文件3.2图书信息查询图书信息第二层图：

（1）：处理新书购入 1）规格说明

输入新书的全部信息。2）引言

为了输入新书的全部信息（包括：分类目录号，流水号书名，作者，内容摘要，价格和购书日期等）。3）输入

新书的全部信息。4）处理

通过图书管理系统写入图书目录文件。5）输出

新书的全部信息。

/ 15

入库单出版社档案文件图书馆管理人员（采购员）输入购入新书数据2.1.1查找数据库，确认信息非法输入数据退货单添加操作显示器管理员表2.1.2操作验证非法操作输入添加信息显示结果系统时钟当前日期2.1.3保存添加记录图书目录文件

（2）处理学生借书

1）规格说明

查询读者借书的相关信息。2)引言

为了查询读者借书的相关信息。3)输入

借书信息的关键字。4)处理

利用关键字在借书文件中找到此流水号图书的相关信息。5)输出

借书相关信息。

/ 15

罚款单学生文件非法学生信息2.2.1检查学生欠费情况图书馆管理人员输入学生字段欠款超额，拒绝借书显示器接受借书，输入图书信息借书成功系统时钟当前日期2.2.2更新数据库借书文件（3）：处理学生还书

1）规格说明 输入读者还书信息。2）引言

为了把读者还书的相关信息（包括：图书分类号，流水号，读者号，借阅日期和还书日期等）写入还书文件中。3）输入 读者还书信息。4)处理

通过图书管理系统写入还书文件中。5）输出

读者还书信息的全部内容。

2.3.1根据图书字段查找数据库图书馆管理人员输入图书字段借书信息和学生信息2.3.2计算欠款结果欠款金额显示器借书文件还书成功当前日期系统时钟学生文件图书目录文件罚款单 11 / 15（4）：处理图书注销

1）规格说明

注销图书的相关内容。2）引言

为了注销图书的相关信息。3）输入

图书信息的关键字（图书分类号或书名）。4）处理

利用关键字在图书目录文件中找到此图书分类号或书名图书的相关信息。5)输出

图书的注销信息。

2.4.1根据图书字段，查找数据库图书馆管理人员输入注销图书字段修改操作2.4.2操作验证非法操作输入修改信息图书目录文件系统时钟当前日期2.4.3保存修改记录注销成功显示器

（5）处理学生信息查询

1）规格说明

读者登记，即读者的具体信息。2）引言

为了把读者的具体信息（包括：读者编号，姓名，学院，专业，年级等）写入读者目录文件中。3）输入 读者具体信息。

/ 15 4）处理

通过图书管理系统写入读者目录文件中。5）输出 读者具体信息。

图书馆管理人员|学生输入查找字段3.1.1确定查询类型及字段查找字段，关键字3.1.2查找数据库查询结果显示器学生文件借书文件（6）处理图书信息查询

1）规格说明

查询图书的相关内容。2）引言

为了查找图书的相关信息。3）输入

图书信息的关键字（图书分类号或书名）。4）处理

利用关键字在图书目录文件中找到此图书分类号或书名图书的相关信息。5）输出

图书的相关信息。

3.2.1确定查询类型及字段图书馆管理人员|学生输入查询关键字查询字段及关键字3.2.2查找数据库查询结果显示器借书文件图书目录文件

/ 15 四.非功能需求

4.1 性能需求

1）精度需求

在精度需求上，根据使用需求，在各项数据的输入，输出及传输过程中，可以满足各种精度的需求。

2）时间需求

在软件方面，响应时间，更新处理时间都比较快且迅速，完全满足用户要求。3）灵活性

当用户需求，如操作方式，运行环境，结果精度，数据结构与其他软件接口等发生变化时，设计的软件要做适当调整，灵活性非常大。

4）故障处理

内部故障处理：在开发阶段可以随即修改数据库里的相应内容。

外部故障：对编辑的程序进行重装载时，第一次装载认为错，修改。第二次运行，在需求调用时出错，有错误提示，重试。

4.2 属性

1）保密性

本软件作为教学管理辅助设备，它的规模比较小，不需要保密技术，先顶一个程序中某些区域的规约，给不同的模块分配不同的功能。2）可维护性

本软件的组成程序组构较为简单，直观意义上较独立。因此，给予电子化的所构成的硬件的简单可维护的特点，决定了该软件的简单。他与文件系统的

4.3 其他需求

1）数据库

数据库是实现有组织的，动态的存储大量关联数据，方便多用户访问的计算机软硬自愿组成的系统。他与文件系统的重要区别时数据的充分共享，交叉访问，与应用程序的高度独立性。

由于本软件的整体结构比较简单，所涉及的数据相对来说也比较少，组成文件的最小单位是记录。

/ 15 2）操作 a.初始化操作

b.数据处理的功能较强 c.后援和恢复操作

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

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

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

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

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

2 软件需求的类型

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

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

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

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

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

3 需求分析的任务

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

4 需求分析过程

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

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

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

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

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

5.1 无足够用户参与

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

5.2 用户需求的不断增加

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

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

5.3 模棱两可的需求

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

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

5.4 过于精简的规格说明

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

参考文献