毕业论文--浅谈需求分析在软件开发中的重要性

学生毕业设计（论文）报告
系别
专业
班级
姓名
学号
设计（论文）题目浅谈需求分析在软件开发过程中的重要性指导教师
起迄日期
毕业设计诚信承诺书
本人慎重承诺和声明：
我承诺在毕业设计过程中严格遵守学校有关规定，在指导教师的安排与指导下完成所规定的毕业设计工作，绝不弄虚作假，不请别人代做毕业设计或抄袭别人的成果。

所撰写的毕业论文或毕业设计是在指导老师的指导下自主完成，文中所有引文或引用数据、图表均注明来源，本人愿意为由此引起的后果承担责任。

学生签名：日期：年月日
毕业设计知识产权权属声明
本人在老师指导下所完成的论文及设计成果、知识产权归属学校。

学校享有以任何方式发表、复制、公开阅览、借阅以及申请专利等权利。

学生签名：日期：年月日
指导教师签名：日期：年月日
浅谈需求分析在软件开发过程中的重要性
摘要
软件需求分析是软件工程过程中计划阶段的一个决定性步骤，在这一步将把含糊的软件概念转变成具体的规格说明，从而奠定了软件开发的基础。

本文通过对需求的定义、需求的类型、需求分析的任务、需求分析的方法、需求的变更以及应用实例等几个方面的介绍，对于在软件开发中做好需求分析有一定的借鉴作用。

关键字:软件，开发，需求分析
目录
第1章绪论 (4)
1.1引言 (4)
1.2需求的定义 (4)
第2章软件需求分析的特点 (5)
2.1用户与开发人员很难进行交流 (5)
2.2 用户的需求是动态变化的 (5)
2.3 系统变更的代价呈非线性增长 (5)
第3章软件需求分析过程 (6)
3.1什么是软件需求 (6)
3.2需求过程中的角色 (6)
3.3 需求过程的迭代 (7)
3.4 需求来源 (8)
3.5 需求获取方法 (9)
3.6 软件需求表达 (9)
3.7 需求评审 (10)
3.7.1 需求评审概述 (10)
3.7.2 需求评审过程 (10)
第4章合格需求的标准 (13)
结论 (13)
参考文献 (14)
第一章绪论
1.1引言
软件项目的开发主要分为五个阶段：需求分析阶段、设计阶段、编码阶段、测试阶段和维护阶段，需求调研和分析是软件开发的第一个阶段。

完善的软件需求说明是软件开发项目得以成功的基础。

不管设计如何精心或者编码如何巧妙，如果对软件需求不加以明确规定，将使用户感到失望，并给软件开发者带来严重后果。

据权威部门统计，目前软件的成功率约为25%，75%的软件是失败的。

在这75%的失败中，约有50%以上的软件是由于需求的原因造成的。

另有资料表明，软件开发项目中返工开销几乎占开发总费用的一半，而导致返工的主要原因是需求分析错误或不明确，从而引发项目开发中的一系列更改。

成功的软件需求分析不仅能提高软件的成功率，而且能节省大量的资源，因此需求分析是软件开发的关键阶段。

1.2需求的定义
软件产业存在的一个普遍问题就是缺乏统一定义的名词术语来描述我们的工作。

客户所定义的“需求”对开发者似乎是一个较高层次的产品概念，而开发人员所说的“需求”对用户来说又像是详细设计了。

实际上，软件需求包含着多个层次，不同层次的需求从不同角度与不同程度反映着细节问题。

IEEE软件工程标准词汇表（1997年）将需求定义为：
1) 用户解决问题或达到目标所需的条件或能力。

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

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

IEEE的定义包括从用户角度（系统的外部行为），以及从开发者角度（一些内部特性）来阐述需求，其关键的问题是一定要编写需求文档。

另外，还有其他几种关于“需求”的定义：
需求是用户所需要的并能触发一个程序或系统开发工作的说明；
需求是从系统外部能发现系统所具有的满足于用户的特点、功能及属性等；
需求是指明必须实现什么的规格说明。

它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。

从以上的定义中，我们依然无法得到有关“需求”的清晰概念，真正的“需求”实际上存在人们的脑海中，任何文档形式的需求（例如：需求规格说明）仅是一个模型或一种叙述，但是编写出高质量的需求规格说明书在需求分析阶段还是关键。

需求分析奠定了软件工程和项目管理的基础。

我们在建造软件系统这座大厦的时候，如果需求分析的基础不够坚实和牢固，那么往往会导致软件系统问题百出，甚至被马上丢弃。

在建造软件系统的过程中，如果我们经常习惯地沿用一些不规范的方法，其后果便是产生一条鸿沟──开发者开发的与用户所想得到的软件存在着巨大的“期望差异”。

因此“需求”这个名词的定义不仅仅是从用户角度对系统外部行为的描述，以及从开发人员角度对系统内部特性的描述，其关键的一点是“需求”必须文档化。

第二章软件需求分析的特点
2.1用户与开发人员很难进行交流
在软件生命周期中，其他4个阶段都是面向软件技术方面的，只有本阶段是面向用户的。

需求分析是对用户的业务活动进行分析，以便明确在用户的业务环境中软件系统应该“做什么”。

但是在开始时，开发人员和用户双方都不能准确地提出系统要“做什么”，因为软件开发人员不是用户问题领域的专家，不熟悉用户的业务活动和业务环境，又不可能在短期内搞清楚；而用户不熟悉计算机应用的有关问题。

由于双方互相不了解对方的工作，又缺乏共同语言，所以在交流时存在着隔阂。

2.2用户的需求是动态变化的
对于一个大型而复杂的软件系统，用户很难精确、完整地提出它的功能和性能要求。

一开始只能提出一个大概、模糊的功能，只有经过长时间的反复认识才逐步明确。

有时进入到设计、编程阶段才能明确，更有甚者，到开发后期还在提新的要求。

这无疑给软件开发带来困难。

2.3系统变更的代价呈非线性增长
需求分析是软件开发的基础。

假定在该阶段发现一个错误，解决它需要用一个小时的时间，到设计、编程、测试和维护阶段解决，则要花费2.5、5、25甚至100倍的时间。

第三章软件需求分析过程
3.1 什么是软件需求
从根本上讲，软件需求就是为了解决现实世界中的特定问题，软件必须展现的属性。

软件需求包括两部分：功能性需求和非功能性需求。

虽然功能性需求是对软件系统的一项基本需求，但却并不是唯一的需求。

除功能性需求外，软件质量属性的特性，称为系统的非功能性需求。

这些特性包括：系统的易用性、执行速度、可靠性，处理异常情况的能力与方式等。

在决定系统的成功或失败的因素中，满足非功能性需求往往比满足功能性需求更为重要。

软件需求的属性包括可验证性、优先级、唯一性和定量化。

（1）可验证性
可验证性是软件需求的基本属性。

软件需求必须是可验证的，否则软件的评审和测试就没有相应的依据。

（2）优先性
软件需求具有优先级，应该能够在有限的资源（资金、人员、技术）情况下进行取舍。

（3）唯一性
软件需求应唯一地标识出来，以便在软件配置管理和整个软件生命周期中进行管理。

（4）定量化
软件需求应尽可能地表述清楚，没有二义性，进行适当的量化，应避免含糊、无法测试、无法验证的需求出现。

软件质量的可靠性和用户界面的友好性等非功能性需求的量化尤为重要。

例如，系统应支持2000个并发用户，系统回应时间应低于10秒，这就是需求的量化。

3.2 需求过程中的角色
对于涉众的各种需求通常很难完全满足，系统分析师应根据预算、技术等条件进行取舍。

3.3 需求过程的迭代
软件需求分析是一个不断认识和逐步细化的过程。

该过程将软件计划阶段所确定的软件范围（工作范围）逐步细化到可详细定义的程度，并分析出各种不同的软件元素，然后为这些元素找到可行的解决办法。

需求过程要适应客户和项目的环境，并作为配置项纳入配置管理。

关于配置管理的具体内容我们将在后面第8章中详细讲解。

当前的软件业面临着巨大竞争压力，要求软件企业有更低的构建成本和更短的开发周期。

有些项目受环境的影响很大，有些项目是对原有项目的升级，有些项目客户要求在指定的架构下完成。

在项目初期，客户不能完全确定需要什么，对计算机的能力和限制不甚了解，所以需求过程很难是一步到位的过程。

随着项目的深入，需求将随时间变化而发生变化。

因此，需求过程是一个迭代的过程，每次迭代都提供更高质量和更详细的软件需求。

这种迭代会给项目带来一定的风险，上一次迭代的设计实现可能会因为
需求不足而被推翻。

但是，系统分析师应根据项目计划，在给定的资源条件下得到尽可能高质量的需求。

在很多情况下，对需求的理解会随着设计和实现的过程而不断深入，这也会导致在软件生命周期的后期重新修订软件需求。

原因可能来自于错误的分析、客户环境和业务流程的改变、市场趋势的变化等。

无论什么原因，系统分析师应认识到需求变化的必然性，并采取相应的措施减少需求变更对软件系统的影响。

进行变更的需求必须经过仔细的需求评审、需求跟踪和比较分析后才能实施。

3.4 需求来源
理解问题域的第一步是提取需求，即确定需求的来源，识别软件的涉众，确立开发团队与客户间的关系。

提取需求时，要求用户与开发人员之间保持良好的沟通。

软件的需求来源很多，我们要尽可能多地识别显式的来源和潜在的来源，并评估这些来源对系统的影响。

典型的来源包括以下5种。

（1）系统目的
系统目的是指软件的整体目的或高层的目标。

这是进行软件开发的动机，但它们通常表达比较模糊。

系统分析师需要仔细地评估这些目标的价值和成本，对系统的整体目标进行可行性研究。

（2）行业知识
系统分析师需要获取业务领域内的相关知识。

因为涉众对于通用的行业知识会一概而过，一些行业惯例需要系统分析师根据环境进行推断。

当需求发生矛盾时，系统分析师可以利用行业知识对各种需求进行权衡。

（3）软件涉众
应充分考虑不同软件涉众的需求，如果只强调某一角色的需求，忽略其他角色的需求，往往将导致软件系统的失败。

系统分析师应从不同涉众的角度去识别、表述他们的需求。

用户的文化差异、客户的组织结构，常常会是系统难以正常实施的原因。

（4）运行环境
软件的运行环境包括地域限制、实时性要求和网络性能等。

系统的可行性和软件架构都依赖于这些环境需求。

（5）组织环境
软件作为一个组织的业务流程支持工具，受到组织结构、企业文化和内部政策的影响。

软件的需求也与组织结构、企业文化和内部政策有关。

3.5 需求获取方法
常用的需求获取方法有：
（1）实地参加
通过亲身参加业务工作来了解业务活动的情况。

这种方法可以比较准确地理解用户的需求，但比较耗费时间。

（2）开调查会
通过与用户座谈来了解业务活动情况及用户需求。

座谈时，参加者之间可以相互启发。

（3）请专人介绍
（4）面谈
对某些调查中的问题，可以找专人询问。

（5）设计调查表请用户填写
如果调查表设计得合理，这种方法是很有效的，也很易于被用户接受。

（6）查阅记录
查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。

通过调查了解获取了用户需求后，还需要进一步分析和表达用户的需求。

3.6 软件需求表达
如何有效地表达软件需求？我们这里建议使用用例建模技术。

用例建模技术是十多年来最重要的需求分析技术，在保障全球各类软件的成功开发中发挥了极其重要的作用。

实践证明，用例技术是迄今为止最为深刻、准确和有效的系统功能需求描述方法。

功能需求是指系统输入到输出的映射，以及它们的不同组合，任何功能必然要通过外部环境与系统之间的交互才能完成，因此，我们可以在内容和形式上把用例和系统的功能需求等同起来。

用例建模技术不同于结构化功能分解的特点有：
（1）显式地表达用户的任务目标层次，突出系统行为与用户利益间的关系。

（2）通过描述执行实例情节（交互行为序列、正常/非正常事件流），能够完整地反映软件系统用以支持特定功能的行为。

（3）以契约（前/后置条件等）的形式突出了用户和系统之间常常被忽略的背后关系。

（4）部署约束等非功能需求与系统行为直接绑定，能够更准确地表达此类需求。

3.7 需求评审
3.7.1 需求评审概述
需求评审是一项精益求精的技术，它主要由非软件开发人员来进行。

通过评审发现二义性的或不确定的需求，还有那些实际上是设计规格说明的所谓的“需求”，这些“需求”是不能作为设计基础和依据的。

需求评审也为风险承担者们提供了在特定问题上达成共识的方法。

需求评审可以分为非正式评审和正式评审。

—非正式评审：可以根据个人爱好的方式进行评审，包括在任何场合的交流、征求意见。

它是非系统化的、不彻底的，或者在实施过程中具有不一致性。

非正式
评审不需要记录备案，没有人对提出的意见负责。

—正式评审：正式技术评审的最好类型叫做审查，它遵循预先定义好的一系列步骤、过程及规定的方法和要求进行，评审内容需要记录在案，正式评审小组的成
员对评审的质量负责。

3.7.2 需求评审过程
（1）确定参与者
① 审查参与者必须代表3个方面的观点：
—需求提出人员和产品代表者的观点；
—需求分析、开发、管理人员的观点；
—软件设计、开发、测试、管理人员的观点。

② 审查组中的审查人员应限制在7个人左右或者更少。

③ 审查的工作基础是软件需求规格说明书。

（2）参与者扮演的角色
① 作者：创建或维护正在被审查的产品。

作者在审查中却起着被动的作用，作者经常可以发现其他审查员没有觉察到的错误。

② 协调者：与作者一起为审查制订计划，组织与协调各种活动，并且推进审查会的进行。

督促作者对需求文档做出建议性的更改，以保证向执行者明确说明在审查过程中提出的问题和缺陷。

③ 读者：扮演审查员的角色。

在审查会进行期间，读者一次审查规格说明中的一块内容，并做出解释，而且允许其他审查员在审查时提出问题。

对于一份需求规格说明，审查员每次必须对需求给出注解或一个简短评论。

通过用自己的话来陈述，读者可能做出与其他审查员不同的解释，这将有利于发现二义性或可能的错误。

④ 记录员：用标准化的形式记录在审查会中提出的问题和缺陷。

（3）进入和退出审查的标准
① 文档进入审查的标准：
—文档符合标准模板；
—文档已经做过拼写检查和语法检查；
—作者已经检查了文档在版面上所存在的错误；
—已经获得了审查员所需要的先前系统的运行资料或确认所需要的参考文档，例如系统需求规格说明；
—在文档中打印了行序号以方便对特定位置的查阅和标记；
—所有未解决的问题都被标记为TBD（待确定）；
—文档中使用到的术语词汇表已全部进行了说明。

② 文档退出审查的标准：
—已经明确阐述了审查员提出的所有问题；
—已经正确修改了文档；
—修订过的文档已经进行了拼写检查和语法检查；
—所有TBD的问题已经全部解决，或者已经记录下每个待确定问题的解决过程、目标日期和提出问题的人；
—文档已经录入项目的配置管理系统；
—已将审查过的资料送到有关归档部门。

（4）需求审查清单
① 软件需求规格说明书审查清单：
—组织和完整性；
—正确性；
—质量属性；
—可跟踪性；
—特殊的问题。

② 使用实例审查清单：
—Use Case是否是独立的分散任务；
—Use Case的目标或价值度量是否明确；
—Use Case给操作者带来的益处是否明确；
—Use Case是否处于抽象级别上，而不具有详细的情节；
—Use Case中是否不包含设计和实现的细节；
—是否记录了所有可能的可选过程；
—是否记录了所有可能的例外条件；
—是否存在一些普通的动作序列可以分解成独立的Use Case；
—是否简明书写、无二义性和完整地记录了每个过程的对话；
—Use Case中的每个操作和步骤是否都与所执行的任务相关；
—Use Case中定义的每个过程是否都可行；
—Use Case中定义的每个过程是否都可确认。

第四章合格需求的标准
合格需求的标准概括如下：
1. 必要性：如果没有这项需求，系统仍然能够满足经优化的实际需要，则该项需求是不必要的；
2. 可行性：在可用的费用和时间约束下，该项需求是可以实现和运行的；
3. 正确性：与需求有关的事实是准确的，需求在技术上和法律上是可能实现的；
4. 简明性：需求的描述应该简单明瞭；
5. 无歧义性：各项需求只有唯一的一种解释方法；
6. 完全性：需求应用的全部条件，都得到陈述；
7. 可验证性：需求在系统运行中可以得到验证；
8. 可跟踪性：需求的起源，设计，编码，测试和文档是可跟踪的；
9. 可分配性：需求可以分配到系统的部件，加以实现；
10.设计独立性：需求不应该仅有一种唯一的解决方案；
11.无冗余性：需求不应该重复；
12.使用标准结构陈述：使用命令式语气，采用词汇Shall陈述；
13.具有唯一的识别码：每个需求拥有唯一的标识数码。

14.无不确定词汇：不能使用含义不确定的词汇，例如if, when, but, except, unless, usually, generally, often, normally, and typically。

结论
需求分析是软件工程项目的开始，也是质量控制额开始，同时，需求分析还具有决策性，方向性，策略性的作用，在需求阶段如果出了问题，在后面的阶段问题也随之留下来。

所以不论是在学习软件工程学的过程中，还是在软件的开发
实践中，一定要对需求分析有足够的重视，它是开发出正确的，高质量的软件的前提和重要保证。

参考文献：
（1）龚波. 软件过程管理. 北京：中国水利水电出版社, 2003.
（2）张海藩.软件工程导论.北京 : 清华大学出版社，2003
（3）梁震戈，梁立新，王文君. IT项目的面向对象开发及管理：电子政务系统案例分析，2009。