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

软件需求分析是一个不断认识和逐步细化的过程。该过程将软件计划阶段所确定的软件范围（工作范围）逐步细化到可详细定义的程度，并分析出各种不同的软件元素，然后为这些元素找到可行的解决办法。需求过程要适应客户和项目的环境，并作为配置项纳入配置管理。关于配置管理的具体内容我们将在后面第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）进入和退出审查的标准

① 文档进入审查的标准：

— 文档符合标准模板；

— 文档已经做过拼写检查和语法检查；

— 作者已经检查了文档在版面上所存在的错误；

— 已经获得了审查员 …… 此处隐藏：2615字，全部文档内容请下载后查看。喜欢就下载吧 ……