软件工程游戏系统论文报告 课程设计报告.docx

软件工程游戏系统论文报告 课程设计报告.docx

《软件工程游戏系统论文报告 课程设计报告.docx》由会员分享，可在线阅读，更多相关《软件工程游戏系统论文报告 课程设计报告.docx（11页珍藏版）》请在冰点文库上搜索。

软件工程游戏系统论文报告课程设计报告

软件工程论文报告

课程名称：

软件工程

论文题目：

需求分析的重要性

院系：

信息技术学院

班级：

10级计算机科学与技术1班

编写者：

普应祥

学号：

201011010118

指导教师：

赵卿

设计时间：

2012-12-31—2013-1-4

信息技术学院

目录

引言

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

三、需求分析阶段的调研方法3

3.1访谈阶段3

3.2诱导需求阶段3

3.3确认需求阶段3

四、需求分析阶段的要点分析4

4.1需求获取4

4.2需求分析和编制规格说明书5

4.3需求验证5

4.4需求管理6

五、软件工程中的需求分析6

1.创建数据字典7

2．确定需求的优先级别7

3．分析需求可行性7

4．使用质量功能调配7

5．衡量需求稳定性7

6．绘制系统上下文示意图7

7．作为功能需求的补充7

四、软件工程中的需求的风险7

六、需求的标准8

七、需求管理技巧8

1、理解涉众需要8

2、定义系统8

3、管理系统规模8

4、改进系统定义9

5、管理变更的需求9

八、评审需求以保证需求的质量9

九、总结10

引言

我国的信息化已经走过了20多年的历程，但许多软件开发公司仍不得不在收集、编写和管理产品需求中疲于奔命。

而缺乏用户参与、不完整的需求及不断变更需求，是导致信息技术项目不能按进度安排和资金预算完成全部功能的主要原因。

　　需求分析是软件工程中的一个重要环节。

是关乎软件项目开发成败的重要因素。

现在的软件项目中返工开销几乎占了总开发的一半，而导致返工的主要原因是需求分析不明确．从而引发项目开发中的一系列更改。

这些更改可能导致浪费大量资源、软件项目无法按时完成等严重问题。

因此不难看出，需求分析是软件设计和实现的基础，是软件项目迈向成功的重中之重。

关键字：

软件工程需求分析

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

一个软件项目的开发主要分为五个阶段：

需求分析阶段、设计阶段、编码阶段、测试阶段和维护阶段。

而需求分析阶段所得到的结果。

是软件项目开发中其他四个阶段的必备条件。

从以往的经验来看，需求分析中的一个稍稍的偏差．就可能导致整个项目无法达到预期的效果。

需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。

在这个过程中。

用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。

需求分析阶段结束后．要求得到：

1．SRS文档（SystemRequirementSpecification）；2．DRM文档；3AcceptancePlan。

从广义上理解需求分析则包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。

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

　　软件需求是指用户对目标软件在功能、行为、性能、设计约束等方面的期望。

通过对问题及其环境的理解与分析，为问题涉及的信息、功能及行为建立模型，将用户需求精确化、完全化，最终形成需求规格说明，整个活动构成软件开发生命周期的需求分析阶段。

在需要的开发中，问题的获取包括业务需求、用户需求、功能需求。

业务需求的参与者主要是业务流程分析员，对企业目前的业务流程进行评估。

确定进行何种程度的业务建模；用户需求重心是如何收集用户需求，确定角色和用例，获取需求的方法倾向组织访谈会：

功能需求依赖于用户需求。

是用户需求在系统上的一个映射，为用户做一个软件原型是一个很好的方法。

三、需求分析阶段的调研方法

下面简单介绍一下需求阶段的调研方法，因为只有方法正确，需求才能完整。

同时，这也是监理工作所依附的基础。

总的来讲，信息系统工程需求分析阶段的工作，可以细分为访谈阶段、诱导需求阶段以及确认需求阶段，每个阶段的工作侧重点有所不同。

3.1访谈阶段

　　这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观信息，建立起良好的沟通渠道和方式。

针对具体的职能部门设定情况，应尽可能与具体业务承办人进行充分的沟通。

　3.2诱导需求阶段

这一阶段是在承建单位已经了解具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体、客观的信息基础上，结合现有的硬件、软件实现方案，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。

用户可以操作简单演示的DEMO，来实际体验整个业务流程的设计合理性、准确性等等问题，及时地提出改进意见和方法。

3.3确认需求阶段

这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建单位必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。

用户方可以通过审查业务流程报告、数据项表以及操作承建单位提供的DEMO系统，来提出反馈意见，并对可接受的报告、文档签字确认。

整体来讲，需求分析的三个阶段是需求调研中不可忽视的部分，三个阶段或者说三步法的实施和采用，对用户和承建单位都提供了项目成功的保证。

当然在系统建设的过程中，特别在采用迭代法的开发模式时，需求分析的工作需一直进行下去，而在后期的需求改进中，工作则基本集中在后两个阶段中。

四、需求分析阶段的要点分析

　　根据需求分析工作的阶段划分，需求的管理包括需求获取、需求分析、编制需求说明书、需求验证和需求管理。

监理单位基于在项目中的职责定位，结合相关的标准规范，应该在该阶段的工作中起到应有的作用。

具体分析、总结如下：

4.1需求获取

　　需求获取一般是需求阶段的开始过程，也是整个项目的开始阶段，所以，监理的重点应在如下几个方面：

　　a.审核需求获取计划。

首先监理应该审查用户获取需求的计划或方案。

这个计划并不只是一个时间表，而是详细描述了承建单位获取需求的方法、调研的对象，以及获取需求的范围。

监理应着重检查是否充分利用了上一章节说的调研方法，调研对象是否分类，是否合理，调研范围是否全面。

　　b.参与需求获取过程。

监理下一步工作就是参与需求获取的过程，这有两层含义，一是首先监理也要了解用户的需求，只有清晰地了解了用户的需求，才能理解项目最终的目标。

二是监督承建单位是否按照需求获取计划进行调研，调研过程中是否真正获取了用户需求，调研记录是否认真记录。

必要的时候，监理也可以协助承建单位引导用户的需求。

如果以第二层的作用来看，监理不用全部参与用户的调研会议，因为监理更重要的作用是整体把握调研活动，但是，对于核心业务，监理还是应该参与会议的。

　　c.审查需求获取的记录。

监理本阶段另一项任务是审核记录，而且，不应该等调研结束了才去审核记录，而是应该在调研过程中随时检查承建单位的记录，这样才能更早的发现问题，更早的纠偏。

4.2需求分析和编制规格说明书　　

　　需求分析包括提炼、分析和仔细审查已收集到的需求，以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其他不足的地方。

分析员通过评价来确定是否所有的需求和软件需求规格说明都达到了优秀需求说明的要求。

分析的目的在于开发出高质量的需求，这样能做出实用的项目估算并可以进行设计、构造和测试。

最终需求分析的结果是形成需求规格说明书。

　　监理本阶段的工作比较少，但是比较重要，就是看承建单位需求分析的方法是否合理，如必要时，可以建议承建单位采用Demo的方式，更好的促进以后的需求确认。

　　同时，本阶段应检查承建单位的需求规格说明书的模板是否全面，是否包含了需求的所有方面，这样做的好处是监理能更早的提醒承建单位按照标准来编写需求规格说明书，而不是等需求规格说明书出来后才发现缺少很多，那个时候已经耽误了不少的时间了。

所以，要求提出的越早越好。

4.3需求验证

验证是为了确保需求说明准确、完整地表达必要的质量特点。

同时让用户确认是否是他们的实际需求。

还有就是发现那些可能觉得需求是对的、但实现时却很可能会出现问题。

当以需求说明为依据编写测试用例时，你可能会发现说明中的二义性。

而所有这些都必须改善，因为需求说明要作为设计和最终系统验证的依据。

监理本阶段的工作是协助用户对需求进行验证，而监理的审核方面和用户的审核方面是不同的，他们的侧重点不同，用户侧重的是业务需求方面，监理的侧重点如下：

　　a.需求的完整性，是否包括了质量的六个方面，尤其是易用、安全、性能等需求。

　　b.需求的准确性，包括需求的内部一致性，需求语言的无二义性，需求与业务目标、合同的依从性、外部一致性。

　　c.需求的可测试性，是否能完整的准确的设计出测试用例。

　　d.需求阶段文档的齐全，除需求规格说明书外，数据要求、初步的用户手册、初步的验收计划等文档也应该完成。

　　e.其他业务需求的建议。

监理的目标是行业专家＋技术专家＋管理专家，所以，行业知识是监理水平的体现。

　4.4需求管理

　　项目不可避免的还会遇到项目需求的变更，有效的变更管理需要对变更带来的潜在影响及可能的成本费用进行评估。

这也是监理需要注重的工作，监理的工作要点如下：

　　a.确定需求变更控制过程。

组织项目组确定一个选择、分析和决策需求变更的过程。

所有的需求变更都需遵循此过程，商业化的问题跟踪工具都能支持变更控制过程。

　　b.建立变更控制委员会。

组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内估价它们，并对此评估作出决策以确定选择哪些，放弃哪些，并设置实现的优先顺序，制定目标版本。

监理当然是重要的组成人员。

　　c.进行需求变更影响分析。

监理应评估每项选择的需求变更，以确定它对项目计划安排和其他需求的影响。

明确与变更相关的任务并评估完成这些任务需要的工作量。

通过这些分析将有助于变更控制委员会作出更好的决策。

　　d.跟踪所有受需求变更影响的工作产品。

当进行某项需求变更时，要求承建单位参照需求跟踪能力矩阵找到相关的其他需求、设计模板、源代码和测试用例，这些相关部分可能也需要修改。

监理应检查承建单位的变更结果。

　　e.检查需求变更的历史记录。

监理应检查承建单位是否记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新的和更新的新版本号等。

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

需求分析包括提炼、分析和仔细审查已收集到的需求，以确保所有承担风险者都明白其含义。

能找出其的错误、遗漏等地方。

分析员通过评价来确定是否所有的需求和软件需求规格说明都达到了优秀需求说明的要求。

分析的目的在于开发出高质量的需求。

这样你能做出实用的项目估算并可以进行设计、构造和测试。

通常。

把需求中的一部分用多种形式来描述．如同时用文本和图形来描述。

分析这些不同的视图将揭示出一些更深的问题，这是单一视图无法提供的。

分析还包括与客户的交流以澄清某些混淆，并明确哪些需求是更为重要的。

其目的是确保所有风险承担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。

1.创建数据字典

数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。

在需求阶段．数据字典至少应定义客户数据项以确保客户与开发小组使用一致的定义和术语。

分析和设计工具通常包括数据字典组件。

2．确定需求的优先级别

应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。

以优先级为基础确定产品版本将包括哪些特性或哪类需求。

当允许需求变更时，在特定的版本中加入每一项变更．并在那个版本计划中做出需要的变更。

3．分析需求可行性

在允许的威本、性能要求下。

分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。

4．使用质量功能调配

质量功能调配是一种高级系统技术，它将产品特性、属性与对用户价值联系起来。

该技术提供了一种分析方法以明确哪些是客户最为关注的特性。

质量功能调配将需求分为三类：

期望需求，即客户或许并未提及。

但如若缺少会让他们感到不满意；普通需求和兴奋需求，即实现了会给客户带去惊喜，但若未实现也不会受到责备。

5．衡量需求稳定性

记录基本需求的数量和每周或每月的变更数量（添加、修改、删除）。

过多的需求变更“是一个报警信号”意味着问题并未真正弄清楚，项目范围并未很好的确定下来或是政策变化较大。

6．绘制系统上下文示意图

这种示意图是用于定义系统与系统外部实体问的界限和接13的简单模型。

同时它也明确了通过接口的信息流和物质流。

7．作为功能需求的补充

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

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

四、软件工程中的需求的风险

在进行需求分析时存在一些很危险的做法，这些做法会对软件产生致命的影响，具体体现在：

　　1无足够用户参与。

　　2模棱两可的需求。

　　3不必要的特性。

　　4过于精简的规格说明。

　　5忽略了用户分类。

　　6不准确的计划。

六、需求的标准

优秀的需求应该是明确、完整、一致、可测试的，此外还有其他的概念，如可跟踪、可修改等等。

　　1明确：

对需求分析中采用的语言做某些限制，除了语言的二义性之外，不要采用计算机术语，造成用户理解上的困难。

　　2完整：

需求的遗漏是经常发生的事情，多发生在用户方面。

需求完整性涉及到需求分析过程的各个方面，从最初的计划制定到最后的需求评审。

　　3一致：

用户需求必须和业务需求一致，功能需求必须和用户需求一致。

严格遵守不同层次间的一致性关系，在实现过程中，把一致性关系细化。

　　4可测试：

需求分析是测试计划的输入和参照，只有系统的所有需求是可以被测试的，才能保证软件始终围绕着用户的需求。

七、需求管理技巧　　

需求管理可遵循的方案较多，下面的方案适用于每一个关键的需求管理。

1、理解涉众需要

　　需求有许多来源，它们可来自于对项目结果感兴趣的任何人，客户、合作伙伴、最终用户以及领域专家都是某些需求的来源，而管理人员、项目团队成员、业务策略和管理机构是另外一些需求源。

掌握如何确定哪些人员应该是需求源、如何获得这些需求源以及如何从中获取信息是很重要的。

2、定义系统

解释涉众需求，并整理为对要构建系统的意义明确的说明。

在定义初期，决定需求的构成、文档格式、语言规范、需求等级、请求优先级和预计工作量、技术和管理风险以及系统规模等。

定义活动还包括与最关键的涉众请求直接联系的初期原型和设计模型。

3、管理系统规模

管理系统规模是一个持续不断的活动，需要迭代式和递增式开发，将项目细分为更易于管理的若干个小部分。

使用需求属性作为协商应包含需求的基础，项目推介人能代表组织拒绝那些超出可用资源规模的变更，也应有相应能力扩展资源以适应扩大的规模。

4、改进系统定义

包括两个重要的考虑事项：

制定更详细的高层系统说明和验证系统是否符合涉众需要，是否按说明运行。

说明通常是项目团队的重要参考材料，在制定说明时一定要考虑受众。

5、管理变更的需求

能否适应变更需求是评测团队的涉众敏感度和运作灵活性的一个尺度。

变更不是敌人，而没有管理的变更才是真正的敌人。

一个需求的变更对其他需求可能有影响，管理需求变更包括这样一些活动：

　　设立基线、追踪每个需求的历史、确定哪些依赖关系值得追踪、在相关项之间建立可追踪关系以及维护版本控制等，建立变更控制或批准流程也很重要。

八、评审需求以保证需求的质量

要保证需求的质量必须确认需求的标准，并对其进行评审。

需求的标准包括其正确性、一致性、无二义性、完备性、相关性、可测试性、可跟踪性等几个方面。

依据软件工程中使用的定义技术，上面的其中一些检查可能能够自动化的进行。

我们重点讨论确认需求的技术中最常见的评审。

在评审中，来自开发人员的代表和来自客户职员的代表各自检查需求文档，然后开会讨论识别出的问题。

客户代表包含那些将操作系统的人、准备输入系统的人、以及将使用系统输出的人。

我们则提供设计小组、测试小组和过程小组的相关人员。

在评审过程中有以下工作是比较重要的：

1、评审系统规定的目的和目标。

2、将需求和目标、目的相比较，已确定所有的需求都是必要的。

3、评审系统将要运行的环境，检查我们提议的系统与其他系统之间的接口。

4、客户代表评审信息流和提议的功能。

以证实需求正确的反映了客户的需求的意图。

5、如果在开发过程中或系统实际运行过程中存在任何风险，我们可以评价并在文档中记录这些风险，讨论和比较各种可选方案，并就将要使用的方案达成某种一致。

6、我们可以就测试系统进行讨论：

随着需求的增长和变化，如何重新确认需求等问题。

总之，软件需求分析方法和工具的使用，对我们软件开发过程影响是很深远的，选用高效能的正确的方法与工具，可以使我们的软件更加正确地反映现实需求，更加具有可用性、可扩展性和可维护性；降低了软件项目的风险。

九、总结

　软件需求分析中的关键就是展开分析、发现问题、征服问题。

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