介绍 |
| 术语需求工程被用来描述通过分析问题的迭代合作过程来开发需求的系统过程，以各种表示格式记录所得到的观察结果，并检查所获得理解的准确性。需求工程是将业务关注点转换为信息系统需求的过程。因此，我们可以将需求工程定义为[1]:引出、组织和记录系统需求的系统方法，以及在客户和项目团队之间建立和维护关于系统需求变化的协议的过程。需求工程是软件工程过程的第一个阶段，在这个阶段中，收集、理解和指定用户需求。需求工程被认为是一项关键的任务，因为许多软件故障源于不一致的、不完整的或仅仅是不正确的需求规范。与软件开发相关的许多最常见、最严重的问题都与需求有关。 |
需求工程过程的分类 |
| 在本节中，我们将介绍需求工程发生的总体框架。需求工程阶段的结果记录在需求规范中。需求规范反映了分析师和客户之间对要解决的问题的相互理解。需求规范作为下一阶段，即设计阶段的起点。为了实现包含满足这些先决条件的用户需求的定义良好的文档，我们可以在需求工程[2]中区分三个过程。这些过程包括迭代和反馈(图1)。已经为需求工程提出了几种分类。[3]: |
| a.需求引出 |
| b.需求说明 |
| c.需求验证和确认。 |
 |
| 图1:需求工程过程 |
需求获取: |
| 需求引出是对问题的理解。一般来说，需求分析师不是被建模领域的专家。通过与领域专家的交互，他必须为自己建立一个足够丰富的领域模型。这一过程涉及不同的学科，这一事实使问题复杂化。在许多情况下，分析师不仅仅是建模领域的外部观察者，只是从领域专家那里引出事实 |
需求规格说明: |
| 一旦理解了问题，就必须在需求规范文档中对其进行描述。本文档描述的是将要交付的产品，而不是产品的开发过程。 |
需求验证和验证: |
| 一旦问题被描述出来，涉及的各方必须就其性质达成一致。我们必须确定正确的需求被陈述(验证)，并且这些需求被正确陈述(验证)。 |
需求工程和软件开发生命周期 |
| 系统和/或软件生命周期存在许多模型，生命周期是系统从首次实现需求到构建、操作和退役所经历的一系列步骤。几乎所有模型都包含一个或多个阶段，其名称类似“需求分析”或“用户需求开发”。许多模型需要生成一个称为需求规范的文档，或者服务于需求规范的功能。即使那些不需要这样的文档的公司，例如Jackson System Development，也有一个产品，例如包含或表达用户需求和开发目标的图的图。随后简要讨论了瀑布模型，并提出了需求工程适用于瀑布模型的方法。其中使用最广泛的模型是基线管理和瀑布模型，基线管理是基于瀑布模型[6]。 |
| 在这个模型中，如图2和3所示，在任何实现开始之前，需求的确定应该是完整的，或者差不多是这样的。基线管理提供了高度的管理可见性和控制，已经被发现适合于非常大的规模的开发，在这些开发中，不太复杂的方法经常失败，并且是许多软件开发系统所需要的。然而，这个模型在某种程度上是不可信的，因为当开发大型复杂系统时，我的实践是，通常不可能开发出一套精确的需求集，它将在需求完成后的几个月或几年的开发过程中保持稳定。 |
 |
| 图2:基线管理和瀑布模型 |
 |
| 图3:线性软件开发生命周期 |
需求工程实践 |
| 上面描述的需求工程的原则是有效和重要的，但是对于实际应用，还需要额外的说明。这些指定方法和工具提供的参数。方法，有时被称为方法论，描述一种一般的方法;工具，通常但不总是自动的，提供详细的，一步一步的方法来执行一个方法。方法:需求分析方法大致可以分为四类，如图4所示。分类不应被视为绝对的:大多数方法具有所有类别的某些特征，但通常 |
 |
| 面向过程的方法主要关注系统将输入转换为输出的方式，较少强调数据本身和控制方面。经典的结构分析和结构分析与设计技术[7,8]，以及维也纳开发方法和Z (A formal Specification method)等形式化方法都属于他的范畴。面向数据的方法强调将系统状态作为一个数据结构[9,10]。虽然结构化分析和结构化分析与设计技术具有数据观点的次要方面，但实体关系建模和Jackson系统开发主要是面向数据的。面向控制的方法强调同步、死锁、排除、并发以及进程激活和去激活。结构化分析和设计技术以及对结构化分析的实时扩展[11,12]是次要的面向控制的。流程图主要是面向过程的。最后，面向对象方法将需求分析建立在系统对象类及其相互之间的交互的基础上。支持需求工程的工具的数量正在迅速增长，即使是最粗略的调查也超出了本文的范围。然而，需求工程的一些特征的讨论 |
| 工具和趋势在这些特征上，是顺理成章的。其中一位研究人员将需求工具分类如下: |
| a.图形编辑 |
| b。可追溯性 |
| c.行为建模 |
| d.数据库和文字处理 |
| e。混合 |
需求工程实践的重要性 |
| 软件系统成功的主要衡量标准是它达到预期目的的程度。广义地说，软件系统需求工程是发现目标的过程，通过识别涉众及其需求，并以一种易于分析、交流和后续实现的形式记录这些需求。在这个过程中有一些固有的困难。涉众(包括付费客户、用户和开发人员)可能数量众多且分布广泛。他们的目标可能会有所不同和冲突，这取决于他们对工作环境的看法和他们希望完成的任务。他们的目标可能不明确或难以表达，而且，不可避免地，这些目标的满足可能受到他们无法控制的各种因素的限制。 |
结论 |
| 与软件开发相关的最常见、最严重的问题与需求分析有关。从术语定义入手，讨论了需求工程及其维度。最后，我们分析了需求工程实践，并从几个角度给出了需求工程实践对设计高质量软件产品的重要性。 |
参考文献 |
- Romisatriawahono，â ' ”分析需求工程Problemâ ' ”，IECI日本工场，日本，第55-58页，2009
- P. Loucopoulos和V. Karakostas:软件需求工程，McGraw-Hill,1995。
- Alan M. Davis，《私人通讯》，1996年。
- IEEE标准610.12-1990,IEEE标准软件工程术语表，IEEE, NY, 1990。
- Cameron, John R.，â '  ' JSD概述，â '  ' IEEE软件工程汇刊，Vol. 12, No. 2, pp. 222-240, 2011
- Royce, Winston W.， â '  '管理大型软件系统的开发，â '  '论文集，IEEE Wescon, 1970年8月。转载于《软件工程第九届国际会议论文集》(蒙特利，CA, pp 328-338, 2008年)。
- Cyril P. Svoboda， â '  '结构化分析教程，â '  '系统和软件需求工程，R.H. Thayer和M. Dorfman主编。， IEEE计算机协会出版社，加州洛斯阿拉米托斯，1990年。
- Ross, Douglass T.， â '  '结构化分析(SA):一种交流思想的语言，â '  ' IEEE软件工程学报，第3卷，第1期，第17-29页，2007年1月
- Bjoerner, Dines， â '  '关于在软件开发中使用形式方法，â '  "第九届软件工程国际会议论文集(蒙特利，加州，1987年3月30日- 4月2日)，IEEE计算机学会出版社，华盛顿，17-29页，2006。
- Norris, M.， â '  ' Z(一种形式化的规范方法)。《汇报报告》，â ' ”开始，国家计算中心有限公司，1986年。转载于R.H. Thayer和M. Dorfman主编的《系统和软件需求工程》。， IEEE计算机协会出版社，加州洛斯阿拉米托斯，1990年。
- Ward, Paul T.和Stephen J Mellor，实时系统的结构化开发技术(3卷)。Prentice-Hall，恩格尔伍德悬崖，新泽西州，1985年。
- Hatley, Derek J.， â '  ' '结构化方法在大型基于软件的航空电子系统开发中的使用，â '  ' AIAA论文84-2592，第六届数字航空电子系统会议(巴尔的摩，马里兰州。1984年12月3日至6日)。
|
菜单
