第四章软件需求工程

第四章软件需求工程（通用6篇）

篇1：第四章软件需求工程

软件需求 需求工程 分析建模 需求管理 本章小结 学习目标

本章介绍需求分析的意义概念和方法了解结构化分析方法和需求管理的关键活动要求学会运用实体关系图数据流图和状态控制图进行结构化分析建模能够编写软件需求规格说明 学习方法

正确理解需求工程涉及的基本概念结合具体实例运用结构化分析技术从而达到理论学习及在实际项目中应用的目的 难重点

本章的学习重点在于理解软件需求的概念和重要性熟悉需求开发和需求管理的基本思想和主要活动掌握结构化的分析方法难点是怎样在实际的软件项目中灵活运用这些思想和方法 课前思考 软件需求存在什么问题 什么是软件需求 什么是需求工程 常见的需求分析方法是什么 需求分析的结果可以验证吗 需求规格说明有什么质量要求

本节知识点 软件需求的定义 需求的层次 导致需求缺陷的原因

随着计算机技术的飞速发展软件已经成为人们生活中不可缺少的一部分人们在使用软件的过程中常常会抱怨它无法执行某些基本操作但对于软件开发人员而言用户不断提出新的要求是一件多么烦人的事

其实在软件开发过程中遇到的许多问题都是由于收集编写协商修改软件需求过程中的失误带来的诸如信息收集不全功能不明确交流不充分文档不完善需求发生变化等可以这样说软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”

开发软件系统最为困难的部分就是准确说明开发什么最为困难的概念性工作便是编写详细的技术需求包括所有面向用户面向机器和其它软件系统的接口

IEEE软件工程标准词汇表将需求定义为

1用户解决问题或达到目标所需的条件或能力

2系统或系统部件要满足合同标准规范或其它正式规定文档所需具有的条件或能力

3一种反映上面1或2所描述的条件或能力的文档说明

下面列出其他几种关于需求的定义 需求是用户所需要的并能触发一个程序或系统开发工作的说明 需求是从系统外部能发现系统所具有的满足于用户的特点功能及属性等 需求是指明必须实现什么的规格说明它描述了系统的行为特性或属性是在开发过程中对系统的约束

软件需求包括四个不同的层次即业务需求用户需求和功能需求另外还有非功能需求

软件需求各组成部分之间的关系如下图所示

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

用户需求

描述了用户使用产品必须要完成的任务可以在用例模型或方案脚本中予以说明

功能需求

定义了开发人员必须实现的软件功能使得用户能完成他们的任务从而满足了业务需求 非功能需求

是从各个角度对系统的约束和限制反映了应用对软件系统质量和特性的额外要求

非功能需求包括过程需求产品需求和外部需求三类其中过程需求有交付实现方法和标准等需求产品需求包含性能可用性实用性可靠性可移植性安全保密性容错性等方面的需求外部需求有法规成本操作性等需求

需求工程中的缺陷将给项目的成功带来极大风险导致缺陷的原因主要包括以下方面 缺乏足够的用户参与

客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫开发人员可能也不重视用户的参与究其原因一是因为与用户合作不如编写代码有意思二是因为开发人员觉得已经明白用户的需求了在某些情况下与实际使用产品的用户直接接触很困难而客户也不太明白自己的真正需求然而在项目的早期让具有代表性的用户直接参与到开发队伍中并一同经历整个开发过程很重要

用户需求不断增加

在开发过程中用户需求经常发生变化但是不断的变更会使其整体结构越来越乱整个程序也难以理解和维护如果要减少需求变更的影响范围就必须在项目的开始对项目视图范围目标约束限制和成功标准给予明确说明并将此说明作为评价需求变更和新特性的参照框架

需求模棱两可

模棱两可是需求规格说明中最严重的问题它意味着不同的人对需求说明产生了不同的理解或者是同一个人能用不止一个方式来解释某项需求说明模棱两可的需求带来的后果便是返工--重做一些你认为已做好的事情返工会耗费开发总费用的40而70～85的重做是由于需求方面的错误引起的添加不必要的特性

有时候开发人员力图增加一些“用户欣赏”但需求规格说明中并未涉及的新功能然而常常是用户并不认为这些功能性很有用开发人员应当为客户构思方案并为他们提供一些具有创新意识的思路具体提供哪些功能要在客户的需要和允许时限内的技术可行性之间求得平衡

规格说明过于简单

客户往往不明白需求分析的重要性只是提供一份十分简略的规格说明仅涉及产品概念上的内容然后让开发人员在项目进展中去完善从而导致开发人员先建立产品结构再完成需求说明

忽略了用户分类

大多数产品是由不同的人使用其不同的特性使用频繁程度也有所差异使用者受教育程度和经验水平也不尽相同如果你不能在项目早期就针对所有这些主要用户进行分类的话必然导致有的用户对产品感到失望

总体来说导致需求缺陷的原因主要体现在三个方面 需求的沟通与理解 需求的变化与控制 需求说明的明确与完整 需求工程中的缺陷将给项目成功带来极大风险如产品的成本过高产品的功能和质量无法完全满足用户的期望等等即使一个项目团队的人员和配备都很不错但不重视需求过程也会付出惨痛的代价

本节知识点 需求工程的内容 需求获取 需求分析 编写需求文档 需求验证

需求工程是指应用已证实有效的原理和方法系统地描述出待开发系统及其行为特征和相关约束

通常需求工程由一些过程组成可分为需求开发和需求管理两部分

需求开发的主要活动 确定产品所期望的用户类 获取每个用户类的需求 了解实际用户任务和目标以及这些任务所支持的业务需求 分析源于用户的信息以区别用户任务需求功能需求业务规则质量属性建议解决方法和附加信息

将系统级的需求分为几个子系统并将需求中的一部份分配给软件组件 了解相关质量属性的重要性 商讨实施优先级的划分 将所收集的用户需求编写成规格说明和模型 评审需求规格说明确保对用户需求达到共同的理解与认识并在整个开发小组接受说明之前将问题都弄清楚

需求管理的主要活动 定义需求基线 评审提出的需求变更评估每项变更的可能影响从而决定是否实施它 以一种可控制的方式将需求变更融入到项目中 使当前的项目计划与需求一致 估计变更需求所产生影响并在此基础上协商新的承诺 让每项需求都能与其对应的设计源代码和测试用例联系起来以实现跟踪 在整个项目过程中跟踪需求状态及其变更情况

今天我们引入“需求工程”的概念强调用工程化的方法进行需求开发和需求管理其中需求开发是采用有效方法获得高质量需求的过程而需求管理则是在需求说明形成之后有效地控制其变更的过程二者缺一不可

一工作内容 聆听用户的需求 分析和整理所获取的信息 形成文档化的描述 二基于用例的方法

随着面向对象技术的发展基于用例的方法在需求获取和建模方面应用得越来越普遍这种方法是以任务为中心和以用户为中心的比起使用以功能为中心的方法它可以使用户更清楚地认识到新系统允许他们做什么

用例模型以用户和任务为中心将整个工作的焦点集中在从用户的角度说明系统能够干什么完全不考虑具体的实现细节从而达到准确地理解客户需求的目的在用例模型中角色和用例是两个基本概念分别代表着系统外部的执行者和系统应包含的功能因此建立用例模型的主要工作是确定角色确定用例和描述用例 A确定角色

角色代表着与系统交互的人或事通过确认系统功能使用者和维护者以及与系统接口的其他系统或硬件设备等可以有效地识别出系统角色 B确定用例

一个完整的系统包含若干个用例每个用例具体说明应完成的功能识别用例首先要确定系统所能反映的外部事件并把这些事件与参与的执行者和特定的使用实例联系起来最终绘制出用例图 C描述用例

单纯地使用用例图不能提供用例所具有的全部信息因此需要使用文字描述那些不能反映在图形上的信息用例描述实际上是关于角色与系统如何交互的规格说明要求清晰明确没有二义性

建立用例模型是一种需求获取的有效方法其简洁清晰的描述方式容易被软件人员和用户共同理解和接受这种方法已经在许多大型系统的开发中取得成效实践证明它能有效地解决用户参与的问题

需求分析主要是对收集到的需求进行提炼分析和仔细审查以确保所有的风险承担者都明白其含义并找出其中的错误遗漏或其它不足的地方形成完整的分析模型分析的目的在于开发出高质量的和具体的需求从而支持项目的估算和软件的设计开发和测试

需求分析的主要活动包括 绘制系统关联图 创建用户接口原型 分析需求可行性 确定需求的优先级别 创建数据字典 为需求建立模型

绘制系统关联图

这种关联图用于定义系统与系统外部实体间的界限和接口的简单模型

创建用户接口原型

当开发人员或用户不能确定需求时开发一个用户接口原型可以使许多概念和可能发生的事更为直观明了用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题同时找出需求文档与原型之间所有的冲突之处 分析需求可行性

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

确定需求的优先级别

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

需求的图形分析模型是软件需求规格说明极好的补充说明它们能提供不同的信息与关系以帮助找到不正确的不一致的遗漏的和冗余的需求这些模型包括数据流图实体关系图状态变换图对话框图对象类及交互作用图等 创建数据字典

数据字典是对系统用到的所有数据项和结构的定义以确保开发人员使用统一的数据定义在需求阶段数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语

分析建模的方法有很多其中最重要的两种方法是结构化分析和面向对象分析 结构化分析方法提供实体关系图数据流图和状态转换图三种图形模型分别进行数据建模功能建模和动态建模

人们习惯于用自然语言来描述软件需求但这会产生许多意想不到的问题如不精确二义性等因此需要采用适当的方法形成一致的完备的和无二义性的软件需求规格说明

通常编写软件需求规格说明有三种方法 将结构化语言与自然语言结合编写文本型文档 建立可视化的模型 采用形式化的方法进行需求规格说明

软件需求规格说明是需求开发的最终结果它精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件软件需求规格说明不仅是系统测试和用户文档的基础也是所有子系列项目规划设计和编码的基础

软件需求规格说明是用户分析人员和设计人员之间进行理解和交流的手段 测试人员可以根据软件需求规格说明中对产品行为的描述制定测试计划测试用例和测试过程 文档人员根据软件需求规格说明和用户界面设计编写用户手册等 软件需求规格说明指导着整个系统的开发过程评审过的需求规格说明需要进行变更控制

a 引言

概要叙述软件需求规格说明便于读者理解文档如何编写以及如何阅读和解释

在软件项目中开发组织应该采用一种标准的软件需求规格说明的模板现在有许多软件需求规格说明模板可以使用这里介绍其中的一种 a1 目的

对产品进行定义在该文档中详尽说明了这个产品的软件需求包括修正或发行版本号如果这个软件需求规格说明只与整个系统的一部分有关系那么就只定义文档中说明的部分或子系统 a2 文档约定

描述编写文档时所采用的标准或排版约定包括正文风格提示区或重要符号

a3 预期的读者和阅读建议

列举了软件需求规格说明所针对的不同读者例如开发人员项目经理营销人员用户测试人员或文档的编写人员描述了文档中剩余部分的内容及其组织结构提出了最适合于每一类型读者阅读文档的建议 a4 产品范围

提供了对指定的软件及其目的的简短描述包括利益和目标 a5 参考文献

列举了编写软件需求规格说明时所参考的资料或其它资源可能包括用户界面风格指导合同标准系统需求规格说明使用实例文档或相关产品的软件需求规格说明在这里应该给出详细的信息包括标题名称作者版本号日期出版单位或资料来源以方便读者查阅这些文献 b 综合描述

这一部分概述了正在定义的产品以及它所运行的环境使用产品的用户和已知的限制假设和依赖 b1 产品的前景

描述了软件需求规格说明中所定义的产品的背景和起源说明了该产品是否是产品系列中的下一成员是否是成熟产品所改进的下一代产品是否是现有应用程序的替代品或者是否是一个新型的自含型产品如果软件需求规格说明定义了大系统的一个组成部分那么就要说明这部分软件是怎样与整个系统相关联的并且要定义出两者之间的接口 b2 产品的功能

概述了产品所具有的主要功能其详细内容将在d中描述所以在此只需要概略地总结例如用列表的方法给出很好地组织产品的功能使每个读者都易于理解用图形表示主要的需求分组以及它们之间的联系例如数据流程图的顶层图或类图都是有用的 b3 用户类和特征

确定你觉得可能使用该产品的不同用户类并描述它们相关的特征有一些需求可能只与特定的用户类相关将该产品的重要用户类与那些不太重要的用户类区分开 b4 运行环境

描述了软件的运行环境包括硬件平台操作系统和版本还有其它的软件组件或与其共存的应用程序 b5 设计和实现上的限制

确定影响开发人员自由选择的问题并说明这些问题为什么成为一种限制可能的限制包括如下内容

必须使用或者避免的特定技术工具编程语言和数据库 所要求的开发规范或标准 企业策略政府法规或工业标准 硬件限制例如定时需求或存储器限制 数据转换格式标准 b6 假设和依赖

列举出在对软件需求规格说明中影响需求陈述的假设因素以及项目对外部因素存在的依赖 c 外部接口需求

利用本节来确定可以保证新产品与外部组件正确连接的需求 c1 用户界面

陈述所需要的用户界面的软件组件描述每个用户界面的逻辑特征以下是可能要包括的一些特征

将要采用的图形用户界面 G U I标准或产品系列的风格 屏幕布局或解决方案的限制 将出现在每个屏幕的标准按钮功能或导航链接例如一个帮助按钮 快捷键 错误信息显示标准

c2 硬件接口

描述系统中软件和硬件每一接口的特征这种描述可能包括支持的硬件类型软硬件之间交流的数据和控制信息的性质以及所使用的通信协议 c3 软件接口

描述该产品与其它外部组件由名字和版本识别的连接包括数据库操作系统工具库和集成的商业组件明确并描述在软件组件之间交换数据或消息的目的描述所需要的服务及内部组件通信的性质确定将在组件之间共享的数据 c4 通信接口

描述与产品所使用的通信功能相关的需求包括电子邮件Web浏览器网络通信标准或协议及电子表格等等定义了相关的消息格式规定通信安全或加密问题数据传输速率和同步通信机制 d 系统特性 d1 说明和优先级

简短说明该系统的特性并指出该特性的优先级是高中还是低另外还可以包括对特定优先级部分的评价例如利益损失费用和风险 d2 激励响应序列

列出输入激励用户动作来自外部设备的信号或其它触发器和定义这一特性行为的系统响应序列 d3 功能需求

详列出与该特性相关的详细功能需求这些是必须提交给用户的软件功能使用户可以使用所提供的特性执行服务或者使用所指定的使用实例执行任务 e 其他非功能需求 e1 性能需求

阐述了不同的应用领域对产品性能的需求并解释它们的原理以帮助开发人员作出合理的设计选择确定相互合作的用户数或者所支持的操作响应时间以及与实时系统的时间关系 e2 安全设施需求

详尽陈述与产品使用过程中可能发生的损失破坏或危害相关的需求定义必须采取的安全保护或动作还有那些预防的潜在的危险动作明确产品必须遵从的安全标准策略或规则 e3 安全性需求

详尽陈述与系统安全性完整性或私人问题相关的需求这些问题将会影响到产品的使用和产品所创建或使用的数据的保护定义用户身份确认或授权需求明确产品必须满足的安全性或保密性策略 e4 软件质量属性

详尽陈述与客户或开发人员至关重要的其它产品质量特性这些特性必须是确定定量的并在可能时是可验证的 e5 业务规则

列举出有关产品的所有操作规则例如什么人在特定环境下可以进行何种操作这些本身不是功能需求但它们可以暗示某些功能需求执行这些规则 e6 用户文档

列举出将与软件一同发行的用户文档部分例如用户手册在线帮助和教程明确所有已知的用户文档的交付格式或标准 f 其他需求

定义在软件需求规格说明的其它部分未出现的需求例如国际化需求或法律上的需求你还可以增加有关操作管理和维护部分来完善产品安装配置启动和关闭修复和容错以及登录和监控操作等方面的需求这一部分可以省略

需求验证是为了确保需求说明准确完整地表达必要的质量特点当你阅读软件需求规格说明时可能觉得需求是对的但实现时却很可能会出现问题当以需求说明为依据编写测试用例时你可能会发现说明中的二义性而所有这些都必须改善因为需求说明要作为设计和最终系统验证的依据

正确性 完整性 可验证性 无二义性 可修改性 可跟踪性 一致性

审查需求文档

对需求文档进行正式审查是保证软件质量的有效方法组织一个由不同代表如分析人员客户设计人员测试人员组成的小组对SRS及相关模型进行仔细的检查

以需求为依据编写测试用例

根据用户需求所要求的产品特性写出黑盒功能测试用例客户通过使用测试用例以确认是否达到了期望的要求从测试用例追溯回功能需求以确保没有需求被疏忽并且确保所有测试结果与测试用例相一致同时要使用测试用例来验证需求模型的正确性如对话框图和原型等

编写用户手册

在需求开发早期即可起草一份用户手册用它作为需求规格说明的参考并辅助需求分析 确定合格的标准

让用户描述什么样的产品才算满足他们的要求和适合他们使用的将合格的测试建立在使用情景描述或用例的基础之上

需求验证包括需求评审和需求测试两个部分需求评审又包括正式的和非正式的两种形式

需求评审是一种有效的需求验证手段通常以用例模型为基础编写测试用例进行检验虽然没有在运行系统上执行测试用例但是设计测试用例的过程可以解释需求的许多问题

本节知识点 分析模型--实体关系图数据流图状态转换图 数据字典 结构化分析过程

多年来人们提出了许多分析建模的方法其中占主导地位的两种方法是传统的“结构化分析”方法和当今流行的“面向对象的分析”方法本节重点介绍结构化分析方法面向对象的分析方法在后面章节介绍

需求分析产生的模型使人们可以更好地理解将要建造的系统它有助于系统分析员理解系统的信息功能和行为成为确定需求规格说明完整性一致性和精确性的重要依据奠定了软件设计的基础

结构化分析导出的分析模型包括数据模型功能模型和行为模型该模型以数据字典为核心描述了软件使用的所有数据对象围绕这个核心的是实体关系图数据流图和状态转换图具体形式如下图所示 实体关系图ER数据建模的基础描述数据对象及其关系 数据流图DF功能建模的基础描述数据怎样转换以及转换的功能 状态转换图ST行为建模的基础表示系统的各种行为状态以及状态间的转换方式 数据模型包括三种基本元素 数据对象 属性 关系 它们对理解问题的信息域提供了基础

两个数据对象之间有以下三种关联ER在数据对象之间的连线上用数字或字母表示

一对一11对象 A的一个实例只能关联到对象B的一个实例对象 B的一个实例也只能关联到对象A的一个实例如一个丈夫只能有一个妻子一个妻子也只能有一个丈夫

一对多1N对象 A的一个实例可以关联到对象B的一个或多哥实例而对象 B的一个实例只能关联到对象A的一个实例如一个母亲可以有多个孩子而一个孩子只能有一个母亲

多对多MN对象 A的一个实例可以关联到对象B的一个或多个实例同时对象 B的一个实例也可以关联到对象A的一个或多个实例如一个叔叔可以有多个侄子一个侄子也可以有多个叔叔

数据建模的其他图形工具层次方框图

层次方框图通过树型结构的一系列多层次的矩形框描述复杂数据的层次结构树型结构顶端的矩形框只有一个用于代表完整的数据结构下面各层的矩形框是对完整数据结构的逐步分解和细化得到的数据子集底层的矩形框代表组成该数据结构的基本元素是数据的最小单位不可再分割

数据建模的其他图形工具层次方框图 层次方框图非常适合描述自顶向下的需求分析方法中数据的层次关系系统分析员可以从对顶层信息的分类开始沿着层次图中的每条路径逐步细化直到确定了数据结构的全部细节为止

例如某单位职工的实发工资由应发工资和扣款两部分组成每部分又可进一步细分如应发工资又可分为基本工资和奖金基本工资又可分为国家工资津贴补贴奖金也可分为出勤奖和业绩奖津贴和补贴还可以再进一步地细分 实发工资的层次方框图如下图所示

数据流图是结构化分析的基本工具它描述了信息流和数据转换通过对加工进行分解可以得到数据流图

DF有四种元素其基本符号如下图所示

外部实体与系统进行交互但系统不对其进行加工和处理的实体用带标记的矩形表示 加工对数据进行的变换和处理用带标记的圆圈表示 数据流在数据加工之间或数据存储和数据加工之间进行流动的数据用带标记的箭头表示 数据存储在系统中需要存储的实体用带标记的双实线表示

第0层DF称为基本系统模型可以将整个软件系统表示为一个具有输入和输出的黑匣子用一个圆圈表示上一层DF中的每一个圆圈可以进一步扩展成一个独立的数据流图以揭示系统中程序的细节部分

这种循序渐进的细化过程可以继续进行直到最低层的图仅描述原子过程操作为止每一层数据流图必须与它上一层数据流图保持平衡和一致因此子图的所有输入输出流要与其父图相匹配

状态转换图通过描述状态以及导致系统改变状态的事件来表示系统的行为它没有表示出系统所执行的处理只表示了处理结果可能的状态转换

ST用带标记的圆圈或矩形表示状态用箭头表示从一种状态到另一种状态的变换箭头上的文本标记表示引起变换的条件 例如在操作系统中当存在多个申请占用CPU运行的进程 进程是分配CPU的最小处理单位 时系统将按照某种调度策略为各个进程分配CPU此时进程的状态可能有三种就绪运行和等待 就绪等待分配CPU 运行占用CPU进行相应的处理 挂起

name=baidusnap1>放弃CPU的使用

数据流图是结构化分析的基本工具体现了自顶向下逐步求精的分析过程确定了系统的任务流和数据流 实体关系图描述了系统的数据关系从而帮助开发人员分析和理解系统数据的组成并为系统设计阶段定义系统数据库的物理结构打下基础 状态转换图描述了系统状态之间的变化过程它对于实时系统和控制系统尤为重要

数据字典描述数据流图的数据存储数据加工 最底层加工和数据流它记录的主要内容有 基本信息名字别名描述 定义数据长度数据类型数据结构 使用特点取值范围使用频率使用方式等 控制信息来源用户引用程序读写权限等 其他说明

在数据字典中数据元素的定义可以是基本元素及其组合数据进行自顶向下地分解直到不需要进一步解释且参与人员都清楚其含义为止

数据组合有三种方式

顺序以确定的次序连接多个数据项

选择从多个数据项中选取一个

重复将某个数据项重复多次 为了能够对数据流中的各组成成分进行准确的定义在数据字典中使用了多种具有特定意义的符号如下

结构化分析过程实质上就是创建数据模型功能模型和行为模型其中数据建模的工具是实体关系图功能建模的工具是数据流图行为建模的工具是状态转换图另外使用数据字典定义系统的所有数据项

为了理解和学会使用这些建模工具我们结合一个学生成绩管理系统的实例讲解整个分析过程并给出部分实体关系图数据流图状态转换图和数据字典

下面列出用户对学生成绩管理系统的要求 教务人员录入学生信息课程信息和成绩信息 学生可以随时查询自己所选课程的成绩 由于学生成绩属于敏感信息系统必须提供必要的安全措施以防非法存取

在需求收集的过程中要求客户列出应用软件或业务过程涉及到的“事物”将其演化成数据对象 一次考虑一个对象分析员和客户定义这个对象和其他对象之间是否存在连接 如果存在连接应创建一个或多个关系

对每一个关系确定其关联类型

重复步骤2到步骤4直到定义了所有关系

定义每个实体的属性

形式化并复审实体关系图 重复步骤1到7直到数据建模完成

实例分析 学生成绩管理系统 实体学生课程成绩 实体属性定义

学生学号姓名性别出生日期入学年月

课程课程编号课程名称课程学分课程描述

成绩学号课程编号分数考核日期

显然学生课程和成绩都是系统的实体并且可以初步定义它们的属性

教务人员虽然是系统的用户但其信息与系统处理无关因此不用作为实体 由于成绩信息包含了选课信息因此选课信息不用单独记录

因此系统的实体是学生课程和成绩

我们分析这些实体之间的关联关系从实际情况得知一个学生可以选多门课程一门课程也可以有多个学生选修但每个学生选一门课程必须有一个成绩根据上述分析我们得到如图所示的实体关系图

实体关系图

通常数据流图是分层绘制的整个过程反映了自顶向下进行功能分解和细化的分析过程 顶层也称第0层DF用于表示系统的开发范围以及该系统与周围环境的数据交换关系 最底层DF代表了那些不可进一步分解的原子加工 中间层DF是对上一层父图的细化其中的每一个加工可以继续细化中间层次的多少由系统的复杂程度决定

第0层DF将整个系统表示成一个加工 2 确定并标记主要的输入和输出 分离出下一层中的加工数据对象和存储 并对其进行细化一次细化一个加工 4 标记所有加工和箭头 重复步骤3和4直到所有的加工 只执行一个简单的操作可以很容易地用 程序实现

绘制第0层DF的时候将整个系统看成一个加工然后找出作用于该加工的外部实体以及相应的数据输入和输出

绘制下一层数据流图时细化第0层的加工从而描述系统的主要功能 继续进行分解直到所有的加工只执行一个简单的操作为止

实例分析 学生成绩管理系统 第0层DF图

1教务人员维护学生信息和课程信息并登录学生的选课成绩 2学生查询自己的成绩单

对于学生成绩管理系统而言整个系统就是一个加工学生成绩管理

教务人员是数据的源点学生是数据的终点 教务人员需要录入学生信息课程信息和成绩说明学生信息课程信息和成绩是数据流同样查询请求和查询结果也是数据流 根据上述分析得到如图所示的第0层DF图

第1层DF图

对第0层DF图中的加工学生成绩管理 展开得知学生信息是教务人员需要录入的一个信息因此加入一个加工录入学生信息同样得到录入课程信息登记成绩两个加工另外数据流查询请求和查询结果应该由加工查询成绩来完成

这样我们用录入学生信息录入课程信息登记学生成绩和查询学生成绩四个加工代替第0层的学生成绩管理同时增加这些数据流对应的数据存储即学生课程和成绩最后得到如图所示的第1层DF图

第2层DF图

为了继续进行分解我们分析第1层DF中的加工查询学生成绩

学生查询成绩时需要提供合法性检查因此查询学生成绩可以分解为合法性检查和查询成绩两个处理步骤从而形成第2层DF如下图所示

根据以上实例和经验绘制数据流图应当遵循以下原则 1 分层时子图的输入输出数据流必须和父图中相应加工的输入输出数据流一致 加工的编号应该唯一且具有层次性 加工不应该只有输入或只有输出通常既有输入又有输出 4 数据流图不应反映处理的顺序 加工之间应通过数据存储进行通信避免从一个加工直接流到另一个加工 数据应通过加工进行流动避免从一个数据存储直接流到另一个数据存储 数据流图中所有元素的命名应当对客户有意义且与业务相关 8 不要在一个图中绘制7个以上的加工否则难于绘制和理解

数据字典

以下列出“学生成绩管理系统”的部分数据字典条目

4331 创建实体关系图 第四章 软件需求分析与建模 4331 创建实体关系图 第四章 软件需求分析与建模 4331 创建实体关系图 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 在系统功能扩充时可能增加定义项 其他说明 随时但经常在新生入学时期 峰值 10000左右 数据量 学号 姓名 性别 出生日期 入学年月 定义 无 别名 包括学生的主要信息 描述 学生 数据项名 4332 创建数据流模型 第四章 软件需求分析与建模 学号不能重复 其他说明 6位字符 长度 字符串 类型 无 别名 唯一标识学生的编号 描述 学号 数据流名 4332 创建数据流模型 第四章 软件需求分析与建模 在系统功能扩充时可能增加种类 其他说明 随时但经常在学期开学 峰值 10000次左右 频率 无 别名 系统处理的一个命令 描述 学生成绩查询 数据流名 4333 创建行为模型 第四章 软件需求分析与建模

通常来说行为建模用于实时系统 实时系统中可能存在许多脚本很多实体需要进行状态划分和描述状态转换图 在事务系统中系统行为相对简单只有某些行为较复杂的实体才需要建立其状态转换图 4333 创建行为模型 第四章 软件需求分析与建模 1 分析外部事件所谓外部事件是指外部实体与系统的一次交互 分析事件的响应者该响应者为了响应该事件要进行怎样的活动这种活动又会激发哪些事件等 根据事件和活动划分实体的状态考虑发生怎样的事件使该实体进入这个状态怎样的事件使该实体从这个状态转换到另一状态等 4333 创建行为模型 第四章 软件需求分析与建模 实例分析学生成绩管理系统

在学生成绩管理系统中学生成绩信息必须采取安全措施我们采取登录方法避免非法使用系统这样该系统存在登录正常和出错等状态的转换如下图所示 4333 创建行为模型 第四章 软件需求分析与建模 431 分析模型 第四章 软件需求分析与建模 431 分析模型 第四章 软件需求分析与建模 4311 实体关系图 第四章 软件需求分析与建模

数据对象表示具有不同属性的事物ER用带有标记的矩形来表示 关系表示数据对象之间的相互连接ER用直线连接相关联的数据对象并在直线上用带标记的菱形框来表示关系 属性也称性质指数据对象某一方面的特征 ER用带有标记的椭圆来表示 4311 实体关系图 第四章 软件需求分析与建模 属性 ER图中的基本符号 连接 4311 实体关系图 第四章 软件需求分析与建模 4311 实体关系图 第四章 软件需求分析与建模 4311 实体关系图 第四章 软件需求分析与建模 4311 实体关系图 第四章 软件需求分析与建模 学生选课ER图 4311 实体关系图 第四章 软件需求分析与建模 工资计算系统ER图 4311 实体关系图 第四章 软件需求分析与建模 4311 实体关系图 第四章 软件需求分析与建模 4311 实体关系图 第四章 软件需求分析与建模 4311 实体关系图 第四章 软件需求分析与建模 4312 数据流图 第四章 软件需求分析与建模 4312 数据流图 第四章 软件需求分析与建模 4312 数据流图 第四章 软件需求分析与建模 工资计算系统的顶层 0层 数据流图 4312 数据流图 第四章 软件需求分析与建模 4312 数据流图 第四章 软件需求分析与建模 4313 状态转换图 第四章 软件需求分析与建模 4313 状态转换图 第四章 软件需求分析与建模 4313 状态转换图 第四章 软件需求分析与建模 431 分析模型 第四章 软件需求分析与建模 432 数据字典 第四章 软件需求分析与建模 432 数据字典 第四章 软件需求分析与建模 432 数据字典 第四章 软件需求分析与建模 432 数据字典 第四章 软件需求分析与建模 符 号 含 义 说 明 表示定义为 用于对 左边的条目进行确切的定义 表示与关系 X ab表示X由a和b共同构成 [ ] [ ] 表示或关系 X [ab]与X [ab]等价表示X由a或b组成 表示可选项 X a 表示a可以在X中出现也可以不出现 表示重复 大括号中的内容重复0到多次 m n 表示规定次数的重复 重复的次数最少m次最多n次 表示基本数据元素 中的内容是基本数据元素不可再分 连接符 month 112表示month可取1～12中的任意值 表示注释 两个星号之间的内容为注释信息 433 结构化分析过程 第四章 软件需求分析与建模 433 结构化分析过程 第四章 软件需求分析与建模 433 结构化分析过程 第四章 软件需求分析与建模 4331 创建实体关系图 第四章 软件需求分析与建模 4331 创建实体关系图 第四章 软件需求分析与建模 4331 创建实体关系图 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 425 需求验证 第四章 软件需求分析与建模 4251 需求说明的质量特性 第四章 软件需求分析与建模 需求规格说明对系统功能行为性能等的描述必须与用户的期望相吻合代表了用户的真正需求 需求规格说明应该包括软件要完成的全部任务不能遗漏任何必要的需求信息注重用户的任务而不是系统的功能将有助于你避免不完整性 需求规格说明对各种需求的描述不能存在矛盾如术语使用冲突功能和行为特性方面的矛盾以及时序上的不一致等 需求规格说明中的描述对所有人都只能有一种明确统一的解释由于自然语言极易导致二义性所以尽量把每项需求用简洁明了的用户性的语言表达出来 需求规格说明的格式和组织方式应保证后续的修改能够比较容易和协调一致我们可以使用软件工具或者使用目录表索引和相互参照列表等方法使软件需求规格说明更容易修改 可跟踪性意味着每项需求都能与其对应的来源设计源代码和测试用例联系起来 需求规格说明中描述的需求都可以运用一些可行的手段对其进行验证和确认 4252 需求验证的方法 第四章 软件需求分析与建模 4252 需求验证的方法 第四章 软件需求分析与建模 4252 需求验证的方法 第四章 软件需求分析与建模 4252 需求验证的方法 第四章 软件需求分析与建模 43 分析建模 第四章 软件需求分析与建模 43 分析建模 第四章 软件需求分析与建模 431 分析模型 第四章 软件需求分析与建模 431 分析模型 第四章 软件需求分析与建模 42 需求工程 第四章 软件需求分析与建模 需求开发又可分为问题获取分析编写规格说明和验证四个阶段如图所示 421 需求工程的内容 第四章 软件需求分析与建模 421 需求工程的内容 第四章 软件需求分析与建模 421 需求工程的内容 第四章 软件需求分析与建模 421 需求工程的内容 第四章 软件需求分析与建模 421 需求工程的内容 第四章 软件需求分析与建模 422 需求获取 第四章 软件需求分析与建模 分析人员应该与各种层次的客户进行充分的交流和沟通包括决策领导使用部门的领导具体使用人员系统维护人员等尽量清楚地理解用户的问题和要求 对于用户提供的各种问题和要求分析人员需要对其进行归纳和整理借助一些工具和方法从用户一般性的陈述里面提取用户的真正需求并由此确定软件的功能性能接口关系约束条件等 不论是用户的提出问题还是最终获取的需求都应该形成文档化的描述这种描述需要各种人员的一致理解和认同 422 需求获取 第四章 软件需求分析与建模 422 需求获取 第四章 软件需求分析与建模 422 需求获取 第四章 软件需求分析与建模 422 需求获取 第四章 软件需求分析与建模 422 需求获取 第四章 软件需求分析与建模 422 需求获取 第四章 软件需求分析与建模 423 需求分析 第四章 软件需求分析与建模 423 需求分析 第四章 软件需求分析与建模 423 需求分析 第四章 软件需求分析与建模 423 需求分析 第四章 软件需求分析与建模 423 需求分析 第四章 软件需求分析与建模 423 需求分析 第四章 软件需求分析与建模 423 需求分析 第四章 软件需求分析与建模 423 需求分析 第四章 软件需求分析与建模 423 需求分析 第四章 软件需求分析与建模 424 编写需求文档 第四章 软件需求分析与建模 424 编写需求文档 第四章 软件需求分析与建模 4241 软件需求规格说明 第四章 软件需求分析与建模 4241 软件需求规格说明 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 第四章 软件需求分析与建模 第四章 软件需求分析与建模 第四章 软件需求分析与建模 第四章 软件需求分析与建模 第四章 软件需求分析与建模 41 软件需求 第四章 软件需求分析与建模 41 软件需求 第四章 软件需求分析与建模 41 软件需求 第四章 软件需求分析与建模 41 软件需求 第四章 软件需求分析与建模 411 软件需求的定义 第四章 软件需求分析与建模 411 软件需求的定义 第四章 软件需求分析与建模 412 需求的层次 第四章 软件需求分析与建模 412 需求的层次 第四章 软件需求分析与建模 412 需求的层次 第四章 软件需求分析与建模 412 需求的层次 第四章 软件需求分析与建模 412 需求的层次 第四章 软件需求分析与建模 412 需求的层次 第四章 软件需求分析与建模 412 需求的层次 第四章 软件需求分析与建模 413 需求错误的原因 第四章 软件需求分析与建模 413 需求错误的原因 第四章 软件需求分析与建模 413 需求错误的原因 第四章 软件需求分析与建模 413 需求错误的原因 第四章 软件需求分析与建模 413 需求错误的原因 第四章 软件需求分析与建模 413 需求错误的原因 第四章 软件需求分析与建模 413 需求错误的原因 第四章 软件需求分析与建模 413 需求错误的原因 第四章 软件需求分析与建模 413 需求错误的原因 第四章 软件需求分析与建模 42 需求工程 第四章 软件需求分析与建模 42 需求工程 第四章 软件需求分析与建模

篇2：第四章软件需求工程

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

1软件工程

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

2软件需求分析具体过程

篇3：第四章软件需求工程

软件需求是软件开发的开端与基础。在项目需求分析阶段, 开发方和委托方 (客户或本公司领导) 必须全面且尽可能细致地讨论并确定项目的应用背景、功能要求、性能要求、操作界面要求、与其他软件的接口要求以及对项目进行评估的各种评价标准。在进行需求分析时, 可以首先分析客户原有系统的建设情况, 对客户的原有产品进行分析, 明确建设目标等。

一项目需求工程

1. 需求工程的定义

需求工程是所有与需求直接相关活动的通称。开展需求工程的目的是使开发方和委托方对项目需求有共同、清晰的理解, 并能够依据双方确认的需求开展后续开发工作。

2. 需求工程活动的分类

需求工程中的活动可分为两大类:需求开发和需求管理, 需求开发和需求管理又可细分为6个活动。

二软件需求开发

软件需求开发是软件工程的第一个重要环节, 在包括需求、设计、编码、测试和维护等阶段的软件生命周期中, 需求开发处于软件工程的开始部分, 它提供构建软件项目的根基, 决定软件开发成果与客户需求的匹配程度。软件需求开发的主要活动如下:

客户需求调研:通过各种途径, 来获取客户 (购买者、使用者和影响者) 的原始需求。软件需求获取的方法有:与用户交流, 向用户提出问题;参观用户的工作流程, 观察用户的操作;用户工作的情景分析;现有系统的问题报告和改进要求;事件和响应;市场调查或向用户群体发调查问卷;与同行、专家交谈, 听取他们的意见;分析已经存在的同类软件产品, 提取需求;从现有产品或竞争产品的文档中提取需求;从行业标准、规则中提取需求;从Internet上搜查相关资料等。

客户需求分析:需求分析是对各种途径获取的客户需求原始信息进行分析, 消除错误, 补充细节等。确保最终的需求文档能够正确地反映客户的真实意图。

项目需求定义:在需求调查和需求分析的基础之上, 按照指定的格式撰写需求文档, 即《需求规格说明书》, 项目团队依据《需求规格说明书》开展后续工作 (设计、开发、测试等) 。

三软件需求管理

1. 需求管理在软件项目管理中的地位

在软件项目管理中需求开发是软件开发的第一步, 是关键的一步, 也是最难把握的一步。同时, 从软件的项目立项、研发一直到维护, 用户的经验在增加, 对使用软件的感受有变化, 以及整个行业的新动态, 都为软件带来功能不断完善、性能优化、提高用户友好性等需求变更要求。可以说, 需求变更贯穿于软件项目的整个生命周期, 如果不能有效处理这些需求变更, 项目计划会一再调整, 软件交付日期一再拖延, 项目研发人员的士气将越来越低落, 将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须要重视需求管理并拥有行之有效的需求管理策略。需求管理做得好坏会直接影响到软件的质量, 甚至软件项目的成败。

2. 需求管理的主要活动

需求管理主要包括项目需求评审、项目需求跟踪、项目需求变更控制三个方面, 三个方面相互关联, 构成一个有机的整体。

2.1项目需求评审

根据需求调查和需求分析的结果, 撰写的《需求规格说明书》应当进行需求评审, 确保需求确定的科学性。可采用下列指标进行评审: (1) 正确性:每条需求都正确代表构建软件系统所要完成的事情。 (2) 无歧义:每条需求只有一种解释。 (3) 完备性:需求不能发生遗漏, 应全面考虑相关问题。 (4) 一致性:用户需求必须和业务需求一致, 功能需求必须和用户需求一致。 (5) 重要性和稳定性分级:现有资源不足以实现所有需求时, 可以根据级别的高低决定实现的先后, 舍弃一些级别低的需求以保证项目的按期交付。 (6) 可验证性:需求分析是可测试的, 只有系统的所有需求都是可以被测试的, 才能够保证软件始终围绕着用户的需要, 保证软件系统是成功的。 (7) 可修改性:每一条需求都易于完整一致的进行变更, 且不改变需求集的结构和风格。 (8) 可跟踪性:每条需求都是可溯源的, 且存在一种机制使得在以后的工作中引用需求是可行的。 (9) 可理解性:用户和开发人员都完全理解需求集的整体行为、所提供的功能及其中的每条需求的含义。

2.2项目需求跟踪

需求跟踪的目的是建立与维护“需求-设计-编程-测试”之间的一致性, 确保所有的工作成果符合客户需求。很多人这样认为:如果依照“需求→设计→编程→测试”这样的顺序来开发软件, 由于每一步的输入就是上一步的输出, 所以不必担心设计、编程、测试会与需求不一致。需要指正的是, 在实际情况下即使采用严格的瀑布模型也不能保证每个环节的工作成果与需求保持一致。因为软件开发者是人而不是机器。人们的表达能力、理解能力不可能完全相同, 人与人之间的协作很难达到天衣无缝的境界。假如没有需求跟踪的话, 开发过程中的每个环节都可能发生偏差, 最终面目全非。

2.3需求变更控制

需求发生变更的主要原因有: (1) 随着项目进展, 开发方和客户方对需求的了解越来越深入。发现原先的需求文档可能存在这样那样的错误或不足, 因此要变更需求。 (2) 市场发生了变化, 原先正确的需求可能跟不上新的市场需求, 因此要变更需求。提出需求变更的动机是好的, 目的是希望开发成果更加符合客户的需求。但是对项目开发团队而言, 变更需求意味着要重新分配任务、修改前期工作成果等, 为此付出较重的代价。如果每次需求变更请求都被采纳的话, 这个项目也许永远不能按时完成。

3. 软件需求管理中存在的问题

目前在软件需求管理中存在一些问题, 主要体现在对需求描述的细致性、正确性、完备性把握不足以及对软件需求的变更难以控制和正确处理。

3.1需求描述的细致性

软件需求在整个软件系统开发中起着非常重要的作用, 一般来说, 需求描述越详细越好。有人认为, 项目的开发方与用户在各种问题上的要求基本轮廓达到一致即可, 具体的细节可以以后再填充, 这是一种非常危险的思想。不管需求分析做得多么细致, 以后对需求的变更都是必然的。另一方面, 在需求分析阶段, 开发人员希望再多投入一些时间, 但是用户却不这么认为, 因为需求阶段是软件系统开发首先要进入的阶段, 离最终开发出可用的系统还有很长一段距离, 这也导致了双方的不一致。同时, 如果在需求阶段投入很多时间, 时间越长, 可能的变化就越多, 对设计的限制也就越严格。因此在需求描述的问题上, 没有统一的界定, 需要开发人员学会适当的把握。

3.2需求描述的正确性

软件开发是一种专业行为, 一般的用户难以理解软件开发人员的开发理念。所以在和用户交流时, 他们讲述的需求在实际中利用现有的技术可能是实现不了的, 用户以为自己很清楚自己的需求, 但实际上他们只是依据当时的工作需求提出的。随着开发工作的不断进展, 用户可能想到更多的功能和特色, 进而对以前的需求进行改动, 导致需求的不一致。

3.3需求描述的完备性

系统的需求层出不穷, 我们不可能做到把所有的需求都一一列举出来, 并且随着时间的推进, 用户的需求也会越来越多, 要穷举需求是不可能做到的。另外, 并不是用户提出的所有需求都要满足, 在项目的最后, 改变一个需求对整个项目的影响或损失很可能会超过需求本身给用户带来的益处。

3.4需求的变更

需求的变化问题是每个开发人员、每个项目经理都遇到的问题, 也是最头痛的问题, 一旦发生了需求变化, 不得不来修改已有的设计、重写相关代码、修改测试用例、调整项目计划等等, 需求的变化好比是万恶之源, 为项目的正常的进展带来不尽的麻烦, 怎么办?必须加强管理, 使需求在受控的状态下发生变化, 而不是随意变化, 需求管理就是要按照标准的流程来控制需求的变化。但难题随之而来, 需求中的变化一般不是突发的革命性的变化, 最常见的是项目需求的渐变问题, 这种渐变很可能是客户与开发方都没有意识到的, 当达到一定程度时, 双方才发现已经物是人非, 整个需求发生了质的变化。

4解决问题的策略

针对软件需求管理中存在的问题, 必须建立解决问题的有效策略, 特别是针对需求变更, 必须要有正确的认识, 也要有有效的管理机制以及与用户良好的沟通机制。

4.1对需求文档版本控制

客户签收的所有过程文档都要作为基线确定下来, 做好相关文档的管理工作。需求的基线是指是否容许需求变更的分界线, 需求分析人员在充分与客户用户进行沟通的基础上形成第一个版本的需求文档, 这个需求文档在通过需求评审后即可以建立第一个需求基线。此后每次需求变更并经过需求评审后, 都要重新确定新的需求基线, 以免将来用户需求发生变更时, 原来的需求无法查找。为有效进行需求变更控制, 必然要做的工作就是保存好各个版本的需求基线, 维护需求基线文档, 以备不时之需。

4.2正确认识需求变更

变更的需求之所以变得难以管理, 不仅是因为一个变更了的需求意味着要花费或多或少的时间来实现某一个新特性, 而且也因为对某个需求的变更很可能影响到其他需求。应确保赋予需求一个有弹性的结构, 使它能适应变更, 并且确保使用可追踪性链接可以表达需求与开发生命周期的其他工件之间的依赖关系。管理变更包括建立基线, 确定需要追踪的重要依赖关系, 建立相关项之间的可追踪性, 以及变更控制等活动。

4.3管理需求变更

变更控制不应该只是软件开发过程应该考虑的事情, 随着软件产品的开发和时间的推进, 用户会提出越来越多的新需求, 甚至在交付软件产品的最后阶段用户还会有不同的需求, 因此需求变更的管理应贯穿于整个项目生命周期的全过程。为了使变更对项目的影响降到最小, 就应当采取合适有效的变更控制策略, 确定一个选择、分析和决策需求变更的过程, 所有的需求变更都需遵循此流程。对需求的变更的处理应该分以下几个步骤:提出变更、变更评估、实施变更、监督变更过程。

4.4与用户充分沟通

在需求管理过程中与用户的沟通很重要, 因为它直接决定着最终软件产品是否满足客户的要求, 即很大程度上决定着项目的成败。在沟通时, 双方对需求的认识要一致, 不能模棱两可。讨论需求及变更需求时, 需求人员与客户及用户应该尽量采取协作的态度, 良好的工作氛围也会提高工作效率, 很难想象双方在“刁难”与“对付”的态度下是多糟糕的工作场景。确定需求基线的过程也是与客户用户交流的过程, 而频繁大量的需求变更在很大程度上也是交流不充分的后果。所以, 有效的充分的交流尤为重要, 需求人员认真听取客户用户的要求, 进行分析和整理, 并最终取得用户的确认。

四结束语

需求管理是一个持续的不断完善的过程, 软件项目开发过程中需求管理的问题有很多, 随时都有用户需求变更, 需求分析的错误也时常发生, 需求质量难以保证, 针对这些问题, 如何采取有效的措施以尽可能减少这些问题可能给项目造成的影响也显得尤其重要, 另外关于需求的质量问题, 需要结合CMMI标准进行需求的质量管理, 有效提高软件的总体质量水平。我们相信随着软件工程的发展和进一步成熟, 软件需求管理的发展会取得更大的进步。在实际项目中, 我们要坚持改善软件工程的管理, 并在实践中总结适合自身的经验, 这样才有利于需求管理技术的不断进步和软件项目的顺利完成, 创造出更高的品质和更大的效益。

参考文献

[1]侯悦.浅析软件项目需求变更管理[J].福建电脑.2009年07期

[2]陈丽杰.浅析软件项目管理中的需求管理[J].科技资讯.2007年14期

篇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、编写目的：

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

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

组所开发系统是基于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、其他需求：

篇6：软件工程实训 需求分析报告

报告名称专业 班级 学号 姓名 指导教师

基于JSP的图书馆管理系统的设计与实现

软件技术

1.引言

随着计算机技术的不断应用和提高，计算机已经深入到社会生活的各个角落，计算机软件也在各方面得到广泛的应用。但是，很多图书馆仍采用手工管理图书的方法，不仅效率低、易出错、手续繁琐，而且耗费大量的人力。为了满足图书馆管理人员对图书馆书籍，读者资料，借还书等进行高效的管理，并结合我院图书馆管理现状，在工作人员具备一定的计算机操作能力的前提下，特编此图书管理系统软件以提高图书馆的管理效率。1.1 编写目的

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

本需求的预期读者是我院图书馆管理员，部分学员，与图书管理系统软件开发有联系的决策人，开发组成人员，扶助开发者，软件验证者。1.3 背景及范围

本项目的名称：图书馆管理系统开发软件。

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

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

1.《软件工程》 ——赛煜、刘文编著东软电子出版社

2.《数据库系统概论》 ——萨师煊、王珊 编著高等教育出版社 3.《JSP项目开发》 ——萨师煊 陈丹丹、高飞 编著清华大学出版社 2.综合描述

为方便对图书馆书籍，读者资料，借还书等进行高效的管理，特编写该程 序以提高图书馆的管理效率。使用该程序后，图书馆管理人员可以管理读者的登记，图书的购入、借出、归还以及注销等；还可以查询某位读者、某本图书的借阅情况，对当前借阅情况给出一些统计，给出统计表格，以全面掌握图书的情况。在学校图书馆内部的现有局域网这个网络环境下,信息由各用户在规定的权限下在各自的工作站上录入，信息上网后各用户可查询，调用，达到信息共享。2.1 产品的前景

图书馆在正常运营中面对大量书籍、读者信息以及两者间相互联系产生的借书信息、还书信息。现有的人工记录方法既效率低又错误过多，大大影响了图书馆的正常管理工作。因此需要对书籍资源、读者资源、借书信息、还书信息进行管理，及时了解各个环节中信息的变更，有利用管理效率的提高。本系统通过强大的计算机技术给图书管理人员和读者借、还书带来便利。本系统除了图书馆内管理的一般功能还外，还包括网上在线查询图书信息、查询本人的借阅情况和续借等功能。系统的功能相对比较完善，根据以后不同的需要，还要对系统进行更新。

2.2产品的功能

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

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

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

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

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

本系统的最终用户为管理员（图书管理员和其它管理人员），他们可以删除图书信息、删除或增加学生信息，可以查看读者的借阅信息。他们都具有一定的计算机应用基础，可以比较熟练操作计算机； 运行环境 1）硬件环境  服务器

(1)处理器（CPU）：双核，Intel奔腾D或AMD速龙64X2以上

(2)内存容量（RAM）：1G以上

 客户端

(1)处理器（CPU）：双核，Intel奔腾D或AMD速龙64X2以上

(2)内存容量（RAM）：1G以上 2）软件环境  数据库服务器端(1)操作系统：Windows7(2)数据库管理系统：MySql，配置TCP/IP协议  Web服务器端

(1)操作系统：Windows7(2)Internet 信息服务（IIS）6.0管理器  客户端

(1)操作系统：Windows 7(2)Web浏览器：Internet Explorer 5.0以上，配置TCP/IP协议

2.4 设计与实现上的限制

开发时间比较紧，机器限制，开发人员的经验少，是开发系统中主要的问题。开发经费不到位，管理不完善，设计时没能全得到考虑，都会影响本项目的开发进程 3.功能需求 3.1 需求规定

在图书管理系统中，管理员要为每个读者建立借阅账户，并給读者发放不同类别的借阅卡（借阅卡可提供卡号、读者姓名），账户内存储读者的个人信息和借阅记录信息。持有借阅卡的读者可以通过管理员（作为读者的代理人与系统交互）借阅、归还图书，不同类别的读者可借阅图书的范围、数量和期限不同，可通过互联网或图书馆内查询终端查询图书信息和个人借阅情况，以及续借图书（系统审核符合续借条件）。借阅图书时，先输入读者的借阅卡号，系统验证借阅卡的有效性和读者是否可继续借阅图书，有效则显示读者的基本信息，供管理员人工核对。然后输入要借阅的书号，系统查阅图书信息数据库，显示图书的基本信息，供管理员人工核对。最后提交借阅请求，若被系统接受则存储借阅纪录，并修改可借阅图书的数量。归还图书时，输入读者借阅卡号和图书号（或丢失标记号），系统验证是否有此借阅纪录以及是否超期借阅，无则提示，有则显示读者和图书的基本信息供管理员人工审核。如果有超期借阅或丢失情况，先转入过期罚款或图书丢失处理。然后提交还书请求，系统接受后删除借阅纪录，并登记并修改可借阅图书的数量。

图书管理员定期或不定期对图书信息进行入库、修改、删除等图书信息管理以及注销（不外借），包括图书类别和出版社管理。3.2 功能分类如图1

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

图1

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

第一层图：

（1）登陆子系统如图3 图书馆管理人员用户名和密码密码验证用户名验证权限显示器登陆错误信息权限显示管理员表显示可用的控件和界面图3管理员登录

（2）查询模块

查询读者信息及其借书情况如图4 图书馆管理输入学生查询关键字学生信息查人员询学生信息学生文件借书文件显示器输入图书查询关键字图书目录文件图书信息查询图书信息图4查询读者信息及其借书情况

第二层图：

（1）处理新书购入（如图5）

 规格说明

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

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

 输入

新书的全部信息。 处理

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

新书的全部信息。

图5输入新书全部信息

（2）处理学生借书（如图6）

 规格说明

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

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

借书信息的关键字。 处理

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

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

（3）处理学生还书（图7）

 规格说明 输入读者还书信息。 引言

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

 输入 读者还书信息。 处理

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

读者还书信息的全部内容。图书馆管理人员输入图书字段根据图书字段查找数据库借书信息和学生信息计算欠款结果还书成功借书文件当前日期系统时钟学生文件图书目录文件 欠款金额显示器罚款单图7输入读者还书信息表

（4）处理图书注销（如图8）

 规格说明

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

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

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

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

 输出

图书的注销信息。

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

（5）处理学生信息查询（如图9） 规格说明

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

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

 输入 读者具体信息。 处理

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

图书馆管理确定查询类输入查找字段查找字段，关键字查找数据库人员型及字段查询结果显示器学生文件借书文件图9读者登记

（6）处理图书信息查询（图10）

 规格说明

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

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

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

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

图书的相关信息。图书馆管理人确定查询类型输入查询关键字查询字段及关键字查找数据库员及字段查询结果显示器借书文件图书目录文件图10 查询图书

4.非功能需求 4.1性能需求 1）精度需求

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

2）时间需求

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

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

4）故障处理

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

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

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

2）可维护性

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

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

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

2）操作