需求工程问题

点赞:2632 浏览:8785 近期更新时间:2024-04-20 作者:网友分享原创网站原创

摘 要 :需求工程是软件工程的初始阶段,是整个软件开发过程的基础,也是项目成败的关键阶段之一.近些年来,随着软件规模的不断增大和在各个领域的广泛应用,使软件工程研究越来越重视对需求工程的研究.众所周知,60%的软件产品的错误来源于不正确的需求,但是大部分的软件开发组织仍然没有一个正式的需求过程.许多组织看上去愿意花费巨资用于修改或调整没有很好规定需求的产品,但却不愿意投资相对很少的费用来使需求从一开始就正确.

关 键 词 :需求工程;功能性需求;非功能性需求;需求变更

一、研究需求工程的必要性

需求就是那些您必须在开始构建产品之前发现的东西.如果在构建的过程中才发现需求,或者更糟糕,直到客户已经开始使用您的产品才发现需求,那么代价将是很大的,并且效率将极其低下.在试图构造产品之前,必须明确需求.如果您没有正确的需求,就不能设计或构造正确的产品,进而产品也就不能帮助用户完成他们的工作.

二、需求工程的两个主要活动

需求是系统必须具有的特征,或者为了使客户接受该系统而必须满足的约束.需求工程的目标就是定义所构建系统的需求.需求工程包含两个主要活动:需求的提出(产生客户理解的系统规格说明)和分析(产生开发人员可以清楚解释的分析模型).

第一部分:需求提出(或需求获取)

需求包含功能性需求和非功能性需求.功能性需求是产品必须完成的那些事,即为了向它的用户提供有用的功能,产品必须执行的动作,功能性需求源于产品存在的最基本理由.非功能性需求是产品必须具备的属性或品质.在某些情况下,非功能性需求对于产品的成功是至关重要的,有时它们作为需求的原因是为了增强产品,非功能性需求通常跟在产品功能的后面.也就是说,一旦我们知道了产品要做的事情,就可以确定它的行为方式,它需要具备什么品质以及它应该多大和多快.

◆功能性需求―――产品的功能

产品的范围―――定义产品的边界,以及它与相邻系统的连接情况.

功能与数据需求―――产品必须做的事情和功能进行的数据操作.◆非功能性需求―――产品的品质

观感需求―――预期的外观.

易用性需求―――基于预期用户的操作水平作出.

性能需求―――多快、多大、多精确、多安全、多可靠等等.

操作需求―――产品预期的操作环境.

可维护性和可移植性需求―――产品的可改动性必须达到什么水平.

安全性需求―――产品 的安全性、保密性和完整性.

文化与政策需求―――人的因素.

法律需求―――满足适用的法律.

非功能性需求是您的产品必须具备的属性.这些属性可以看作是一些特征或属性,它们使产品有吸引力、易用、快速或可靠.例如,您可能希望您的产品在指定的时间内作出响应,或者在计算时达到指定的精度.类似地,您可能希望您的产品有某种特定的外观,或者能被无法阅读的人士使用,或者遵守适用于您的这类业务的法律.

需求的获取主要通过下面两个途径:

◆◆做用户的学徒

这一点是基于师傅和学徒的想法.系统分析师成为用户的学徒,与用户坐在一起,通过观察和问问题来学习该工作.不太可能做到许多用户都能以足够详细的方式解释清楚他们在做什么,让分析师能捕获所有的需求.但是,当人们正在做某事时,总是很善于解释他们正在做什么.如果用户正在他日常的位置上做他的工作,他就能提供一份动态的意见和建议,这样能提供一些细节,不这样做的话很可能漏掉这些细节.可能仅当用户在工作时,他才能精确地描述他的任务,告诉您他为什么在做这些事.

需求工程问题参考属性评定
有关论文范文主题研究: 关于需求的论文范文 大学生适用: 学校学生论文、电大毕业论文
相关参考文献下载数量: 82 写作解决问题: 如何怎么撰写
毕业论文开题报告: 论文提纲、论文题目 职称论文适用: 职称评定、初级职称
所属大学生专业类别: 如何怎么撰写 论文题目推荐度: 免费选题

◆用户访谈

用户访谈是需集的传统方法.然而,仅使用这种方法可能并不是最有效率的.我们强烈建议不要把访谈作为唯一的需集方法,而是将它与其他方法一起使用,有时其他方法能产生更好的效果.

第二部分:需求分析

分析的结果是产生准确、完整、一致并且可检验的系统模型.需求提出阶段产生了系统规格说明,开发人员在分析阶段将该系统规格说明形式化,并详细检查边界条件和异常情况.如果发现有任何错误或二义性,开发人员就纠正并澄清系统规格说明.该活动通常涉及客户及用户,特别是当需要改变系统规格说明,以及需要收集附加信息时.

由于项目的特殊性和行业覆盖的广阔性,以及需求分析的高风险性,软件需求分析的重要性是不言而喻的,同时需求分析又的的确确难做.其原因基本上是由于以下情况造成的:

1)客户说不清楚需求.

2)需求自身经常变动.

3)分析人员或客户理解有误.

面向对象的需求分析的基本步骤如下:

1)与用户广泛接触,收集和查看相关资料,对问题域有一个大致的了解.在此基础上,提炼和标识对象.

2)描述对象(类)的属性.

3)描述对象之间的关系,如整体关系和从属关系等.

4))描述问题域的“剧情”,即描述问题域中完成每个任务需要的对象间的协作关系.

以上四个步骤不是孤立进行,而是相互联系的.通过这四个步骤的反复执行,就可以建立一个基于对象的问题域模型.

三、需求存在变化

需求也会更改.通常它们的更改有个很好的理由:业务改变了,或者新的技术优势使得进行改动是值得的.这类改动常常被视为需求蔓延.需求蔓延指的是在大家认为需求过程已经结束以后又进入规格说明书的需求.但是,如果改动导致了在正式需求过程结束后产生新的需求它们不能事先预见那么这类需求蔓延就是不可避免的.很自然,需求过程永远不会结束(产品不断地演进),但是总存在一个项目阶段,在这个阶段您打算要开始构建产品的工作.在这个阶段之后发生的需求被视为需要蔓延.