计算机科学与工程学院实验报告

课程名称		软件需求分析与建模			班级	18软5
实验名称		我对需求分析与建模的认识与应有内容建议			教导教师	董瑞生
姓名	陈思达		学号	1814080902504	日期	2020.10.4

 

目录

 

一、序言.................................................................................................................................. 1

二、 软件生产的需求问题.................................................................................................. 1

1、需求问题的种类........................................................................................................ 1

2、 需求问题具体原因分析.......................................................................................... 3

3、 需求工程.................................................................................................................. 3

三、 需求基础....................................................................................................................... 4

1、 定义.......................................................................................................................... 4

2、 问题和需求.............................................................................................................. 5

3、 解决问题的基础...................................................................................................... 6

4、 解决问题的方法...................................................................................................... 7

四、 需求工程过程............................................................................................................... 7

1、 概述.......................................................................................................................... 7

2、 需求工程活动.......................................................................................................... 8

3、 需求分析.................................................................................................................. 9

4、 需求规格说明.......................................................................................................... 9

五、 总结................................................................................................................................ 9

 

我对需求分析与建模的认识与应有内容建议

一、序言

如果把软件比喻做一座楼房，从整体上来说，是因为他有基础，有主体，有装饰，意思就是在操作系统之上的基础设施软件、实现计算逻辑的主体应用程序、方便使用的用户界面程序。这句话虽然看起来简简单单，但在实际上的学习中，我却发现这句话并没有自己想象中的那么简单。这是一门有严密逻辑的课程，里面的内容是历代开发者在探索软件开发的途中遇见一些困难之后，发现了现有软件设计体系的不足和缺陷。并在提出改进和解决方案之后，对软件设计流程进行不断的改进的优化。最终才是我们看到的现代软件设计流程。

对以前来说，软件需求分析位于软件工程的一个起始阶段，是软件系统开发中的一个重要的独立工作阶段，为软件工程后续阶段提供了工作基础。对于软件项目的成败起到了决定性的作用。

但是，随着软件系统规模体系的不断扩大和复杂程度的增长，以需求分析为重心的传统需求处理技术已经不能满足现代软件技术发展的需要。完整的需求工程过程由此应运而生。对于大部分本科生来说，在学校其实很难接触到多大的工程，大多数人接触到的一般都是在学完一门课程之后做出的一些小程序，也就是所谓的期末课程设计。

对于这样小型的程序来说，其实内部结构并不算多么复杂，一个人在开发的过程中并不会遇到一些复杂的问题。因此，使用传统的需求分析方法来设计软件，并不见得会出现很大的问题。所以有些人可能对需求工程这门科目并不是相当的重视。

但是对于社会上的企业开发来说，随着软件系统规模越来越大、越来越复杂，传统的需求分析中单纯的建模与分析已经不能满足这样大规模软件的需要了。企业需要对这些需求的信息进行进一步的获取、建模、文档化、验证以及管理。在这种背景之下，就越彰显出软件建模与分析这门科目的重要性，人们认为这门科目将会是解决目前软件问题的一门重要科目。

• 软件生产的需求问题

1、需求问题的种类

既然我们说到了软件开发，那就不得不谈到一个困扰着全世界企业和开发者的一个很重要的问题——需求问题。

无论是实践者的切身体会，还是各种调查数据，都明确指出需求问题是当前软件开发中遇见的最主要的问题之一。所有的调查数据中，以美国的一项专门从事跟踪工厂项目成功或者失败的权威机构Standish Group 的CHAOS 系列报告最广为人知。

在这项报告中显示，在所有的项目中，只有16.2%的项目能够被称之为成功项目，而有31.1%的项目，在开发途中就已经由于总总原因中途撤销，或者产品最终无法提交使用，这种项目被称为失败项目。而更多的项目，虽然并没有失败，最终完成开发并且能够提交使用，但是这个项目在生产中出现成本超支、项目超期或者无法实现一些需求功能的问题。这些问题被称为问题项目。而问题项目，占据所有项目的52.7%。

失败和问题项目，根据我的总结，主要由以下几种问题引起：

 

1、缺少用户参与

在一个项目的开发里，往往是建立在需求分析的基础上的。需求分析问题如果不能得到妥善的分析和处理。这样的项目即使能够按时完成，结果往往也不怎么尽如人意。在没有经过一个系统的软件开发训练的一些小团队里。程序员缺乏一些专业，系统的学习。在开发过程中往往会以想当然的思想去开发软件，以自己的需求去替代用户的需求，在设计的过程中带有很大的随意性。这往往就是软件为什么不尽如人意的原因之一。

而在开发的途中，如果有邀请一些用户来进行测试，也就是所谓的内测。用户在内测的过程中，能够在使用的时候提出自己的建议。开发方通过收集这些信息，对软件进行改进。就能很大程度的避免软件功能不符合用户需求这个问题。

 

2、不完整的需求说明

软件是一个集成了高度逻辑和智力的产品，软件在开发的过程中需要建立庞大的逻辑体系。软件规模越大，意味着逻辑越复杂。当软件规模提升到一定程度的时候，指望一个人去完成所有的工作，那绝对是天方夜谭。因此在一款大规模软件的开发中，往往开发团队需要几十个人甚至上百上千个人才能维持正常的开发进度。

那么这就引出了一个新的问题——如何将成百上千个人的思维整合在一起，指定一个规范化的规则让所有的人能够完成一个软件的开发。

在传统的需求分析中，对于项目需求的构建仅仅停留在单纯的分析与建模。虽然已经客观描述出来了设计软件的方向。但对于实际开发的细节来说，还是显得十分模糊。

我在书上曾经看到过这么一句话“在一个出现需求问题的软件项目上，增加人力只会使其更难按期完成”。说的其实就是这么一个道理，更多的人意味着更快的工作进度。但我们也知道，在生活中每一个人都是有差异的，人与人之间的思维和行为习惯往往是不同的，而人数增加会进一步加大开发组之间的通信成本。如果需求说明不够完善的话，就会留有很大的想象空间，程序员往往也会因为模糊的需求说明而在开发的过程中代入自己的想法，从而造成开发出来的软件功能不能满足用户的需要。

这就体现出软件需求工程的重要性了，需求工程能够对软件需求模型的进一步文档化，对用户的需求进行了极大的规格化与细分。使程序员在开发的途中不会受到自身眼界和体验的限制，能够真正考虑到用户的需要。开发出一个符合用户体验的软件。

 

3、需求变化

有些时候，一个项目在开发的过程中几乎不可避免的会遇见上述这两个问题，即使能解决上述的这两个问题，其实也并不意味着制作组就可以高枕无忧了。在实际情况里，用户的需求并不是一成不变的，而是会随着时间的推移和社会的变化进行改变的。举个例子，在十年前开发一款外卖软件，原本的设计是让用户在外卖点单之后，由外卖员取餐送到家门之后，用户进行货到付款。但是过了几年之后，随着智能手机的普及，移动支付的崛起，实体货币逐渐被用户抛弃，用户出门在外已经不会使用纸币，而是使用移动支付来代替实体货币。那么很明显，外卖平台就会出现一个新的需求——增加一个移动支付外卖订单的功能，这就是需求的变化。而随着时间的推移一直到今天。我们已经可以看到，不能适应电子支付需求变化的外卖平台，已经被市场所淘汰了。

 

由上述例子，我们可以看到，在导致项目失败的这些需求问题的原因中，一个最为重要的原因就是：开发者不能很好地理解和掌握“应用”型软件模拟特性以及由此产生的一系列影响和要求。

1. 需求问题具体原因分析

其实我们在上面的分析中不难发现，在实际上的项目开发中，只有很少一部分的问题是因为技术力不足引起的。也就是说，大部分导致项目失败的原因其实并不是技术。而是开发者对于需求理解的不足。

从需求处理的任务上来看，我们需要重视非技术性的问题和社会性因素。这也是需求工程这门课要做的主要任务。它要做的是帮你发现问题并解决问题。而现实是问题的发生地，软件系统是人们应对问题的手段。但是单纯的软件系统是不能解决问题的，它只有和现实之间形成一种有效的互动才能解决问题。因此，相对与软件系统的构造问题，人们更应该去关注软件系统和现实之间的互动效应。也就是说，需求处理不应该以新系统的功能性和内在特征为主要的处理目标，而是更应该集中精力于分析环境的构成、现状和它们将来能与软件达成的期望互动效应。因此，作为软件系统环境的组织机构文化、社会背景和系统涉众的目标与利益比软件内部的数据流与状态更应该得到重视。

从需求处理的手段上来看，需要重视非技术性和社会因素。建模与分析技术是进行需求处理的主要手段，这些技术本身都是概念性的，不依赖于某些特殊的应用环境条件，可以被广泛应用于各种应用场景。但是利用这些技术构建的解决方案一定是和具体的应用环境相关的，不存在不依赖于具体应用环境的解决方案。因此，在利用建模与分析技术进行需求处理的时候，不能忽视具体应用环境中的相关因素，例如组织机构的文化、行业规范和社会背景等，都会约束解决方案的构建空间。

从需求处理的过程来看，需要重视非技术性和社会性因素。在需求处理的过程中，试图单纯通过技术的运用来建立一个一致，完整的需求模型是不太可能的。因为在现实中，因为涉众的不同立场而产生的利益冲突的情景非常常见，这些冲突是根本无法单纯通过技术手段能解决的。因此，在需求处理的过程中，要重视非技术性和社会性因素所导致的问题的解决，面对冲突环境要能够分析社会原因和组织机构方面的原因，引导涉众进行利益协商，进而建立一个一致、完整的需求模型。

1. 需求工程

综上所述，根据上文，其实我们已经很明显的感受到了传统需求分析的有限性和不足。也已经感受到了需求分析进行进一步深究的必要性。

“需求工程”自产生以来，其概念和其领域内的其他名词一样，没有形成较为一致的定义，不同的人从不同的角度出发，根据各自不同的理解，会得出不同的定义。

简单来说，需求工程是所有需求处理活动的综合，它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终反映到软件上被应用后与其环境互动形成的期望效应。

通过上文，我们就可以将其定义如下：需求工程是软件工程的一个分支，它关注软件系统所应实现的现实世界目标、软件系统的功能和软件系统应当遵循的约束，同时也关注以上因素和准确的软件行为规格说明之间的联系，关注以上因素与其随时间或跨越产品而演化之后的相关因素之间的联系。

需求工程有以下三个主要任务：

1. 需求工程必须说明软件系统将被应用的环境及其目标，说明用来达成这些的目标的软件功能，还要说明在设计和实现这些功能时上下文环境对软件完成任务所用方式、方法所施加的限制和约束，即要同时说明软件需要“做什么”和“为什么”需要做。
2. 需求工程必须将目标、功能和约束反映到软件系统之中，映射为可行的软件行为，并对软件行为进行准确的规格说明。需求规格说明是需求工程最为重要的成果，是项目规划、设计、测试用户手册编写等很多后续软件开发阶段的工作基础。
3. 现实世界是不断变化的世界，因此是需求工程还需要妥善处理目标、功能和约束随着时间的演化情况。同时，为了节省开支和进行需求规格说明的重用，需求工程还需要对目标、功能和约束在软件产品中的演化和分布情况进行综合考虑和处理。

 

在系统化的需求工程出现之后，需求处理在整个系统开发中所处的位置也发生了变化。

系统化的需求工程将软件需求开发和系统需求开发结合起来，在系统工程的开始阶段起到重要的作用。在20世纪90年代中期之后，系统需求开发又被称作需求工程的早期阶段。软件需求开发相应被称为需求工程的后期阶段。

系统需求开发的主要目的是获得整个系统的期望目标，包含功能特征和非功能特征。为此需要判断系统的涉众，采集他们的目标与要求，研究系统的环境，确定系统的约束，并进行一些整体性的需求分析。系统需求开发阶段的需求分析主要是分析系统的成本效率及系统的组织和行政策略，处理相互依赖、冲突、重叠或不一致的涉众需求，检查并弥补需求缺失，检查技术储备、外部系统等环境约束。系统需求开发的结果会写入系统需求规格说明。

系统需求开发阶段获得的需求将被分配到软件工程、硬件工程或人力工程部分。其中硬件工程和人力工程的需求一般比较容易落实，但软件工程的需求还需要进行更加细致的处理，即进行软件需求开发。软件需求开发用来确定系统需求中应该由软件满足的部分，将其映射为软件行为，产生软件需求规格说明。

 

• 需求基础

1. 定义

需求是一个比较模糊的词汇，个人觉得这是一个比较难以精准定义的词汇，因为它可能代表很多东西。而在书里，作者是比较倾向于IEEE的需求定义：

1. 用户为了解决问题或达到某些目标所需要的条件或者能力；
2. 系统或系统不见为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力；
3. 对1或2中的一个条件或一种能力的一种文档化表述。

IEEE的定义中同时包含了用户的观点（第一种条件和能力）和开发者的观点（第二种条件和能力），它强调了“需求”的两个不可分割的方面：需求是以用户为中心的，是与问题相联系的；需求要被清晰、明确地写在文档上。

 

1. 问题和需求

我们都知道，需求的产生就是用户在日常生活中产生的各种需要，既然需求源于问题，那么要精准的理解需求，就必须明确它与问题之间的关系。书中的理解是，当现实的状况和人们期望的状况产生的差距的时候，就产生的问题。问题中的差距要么是某些事件、事务的状态不理想，要么是某些事情的发生过程不理想。要解决问题，就需要改变这些事件、事务的状态，或者改变其状态变化的演进顺序，使其达到期望的状态和理想的演进顺序。

人们开发软件系统的目的就是希望用它作为解决方案来解决问题，使得现实改善到期望的状况。解决问题、改善现实、满足用户期望的条件与能力就是需求。

 例如，一个利润率仅为2%的企业希望通过开发和应用一个软件系统，能够将利润率提高到5%。那么2%的利润率就是现实，“利润率低”（低了3个百分点）就是企业面临的问题，利润率为5%是期望的状况，将利润率提高3个百分点或者将利润率提高到5%就是需求。

由以上我们可以得知问题在现实世界与软件系统的互动中得到解决。软件系统在应用于现实之后，就成为现实世界的一个部分。当然，软件系统不会也不需要与整个现实世界互动，它只需要与现实世界中的一部分互动即可。这部分就是问题的发生地，也是问题解决的基本 范围一一解决问题必须涉及的事件和事物，我们将他们称呼为问题域。问题域是需求的背景，要理解需求就必须先理解问题域。例如要准确理解需求"将利润率提高到5%"，就需要弄明白利润由哪些部分组成，各自的比例是多少，工作是如何现实世界完成的……再如，要准    确理解需求"用户可以查询商品详细信息"，就需要了解哪些用户在哪些任务中需要查看哪些商品的详细信息……总之，虽然表达期望的需求看起来比较简单，但是只有明白问题域的复杂背景信息才能真正理解需求的含义。

而软件系统通过影响问题域来帮助人们解决问题，书中称之为解系统，在解系统中软件起到了主要的作用，它是软件解决方案在通用计算机上的实现。

解系统是问题的解决手段，并不是问题的产生地。所以解系统并不是问题域的一部分。

虽然解决问题的方法和满足需求的手段是引入解系统，但是问题和需求都来自于用户，用户关注的是问题域，所以需求是用户对问题域中的实体状态或事件的期望描述。

解系统的核心是软件解决方案和解决方案在通用计算机上面的实现。虽然解决方案及其实现都相比较而言更注重于软件系统的本身，但它们相互之间也是有所不同的。解决方案描述的是软件系统与问题域交互的过程，侧重于软件系统中于外界交互的部分。实现部分则主要是软件内部的组成元素、结构关系、物理实现等软件系统的构造要素。需求工程所关心的仅仅但是解决方案，不涉及软件的实现细节。我们也可以了解到，在需求开发过程中在那个，问题域中的用户提出问题与需求。需求工程师接受用户问题和需求，分析问题域背景，建立软件解决方案，并将解决方案传递给后续的软件开发者，实际上可能并不参与软件开发。因此在这门课中，其实我们学习的重点并不是代码的实现，而是要学习如何对一个需求提出一个合理且完善的解决方法。

1. 解决问题的基础

在书中我们可以看到，解系统之所以处在问题域之外，却仍然能够解决问题域之中的问题，是因为问题域和解系统之间存在有效的互动，并在互动中产生相互的影响。而问题域与解系统能够形成互动的基础是解系统部分模拟了问题域。

初看上去，问题域与解系统原本是两个相互独立的系统，相互独立性使得它们之间难以互相影响。但是一旦认识到解系统对问题域的模拟性，它们就会变得紧密联系，互相影响也会自然形成。

书本中提供了一个图书馆的例子帮助读者理解解系统对于问题域中的模拟：一个图书馆中有图书、借书人、借书规则等现实信息，图书馆管理系统中就会建立相应的数据表, 这个是简单的仿制。如果图书馆中有一本书《软件需求工程》因为磨损而报废了，那Book表中就需要删除" Name =《软件需求工程》＂的数据行。如果在表 Borrower中有一个数据行是" Name=张三，BorrowedNum = 5 " , 那么管理员就会认为张三巳经借走了5本书。如果张三实际上只借走了3本书，那么管理员就会认为管理系统出了错误，不能正常工作。这种带有交互性的模拟就是解系统与问题域能够互相影响的原因和途径。

对于这个例子，其实我相信学习过数据库概论的同学应该都能理解这个例子，并对问题域和解系统之间的关系产生更深入的理解。总的来说，解系统就是对现实实际问题的一种模拟。我们在客观世界上看到的任何一个客观存在并可相互区分的物体，其实本质上都是可以将其细分为一个个属性加以标识的。这样的物体，我们在数据库的术语中将其称之为实体，比方说，对于一个普通人，我们可以将其添加两个属性：性别与年龄，这样的话，在数据库中我们就可以对普通人进行一个区分——男人或者女人，儿童或者青年，又或者是中老年。如果我们再继续细分下去，比方说增加居住地，工作/学校地点，收入……等等属性对其社会属性进行模拟，只要添加的区分属性足够多，我们最终可以将全世界70亿人口之间每一个人都区分开来。这就是解系统对于现实世界中的模拟。

解系统与问题域模拟的交互性其实是由人在意识中强制建立的。如果用户并未将现实发生的情况实时地输入到软件系统之中，或者用户在工作时忽视了软件系统提供的输出，那么软件系统就会失去影响和改变现实的能力，就不可能解决现实问题或者满足现实需求。例如上面所提到的图书管理系统，如果图书馆管理员在有图书库存变动，或者图书被借出归还的情况出现之后，并没有及时的将数据输入到软件系统，那么我们可以预见的是，这个系统将很快就会失去使用价值。这充分的说明了软件系统必须得到用户的认可，否则就没有存在的意义。

看完了问题域与解系统之间的关系后，我们又不得不要提到一个新的概念——共享现象。所谓共享现象，就是解系统所模拟的问题域部分，该部分在两个系统之内同时存在，除了共享现象之外，问题域还有一些没有被解系统模拟的只是，因为现实世界是非常复杂的，我们现有的科技造出的计算机并没有办法完全的将现实世界中的所有情况模拟出来，在实际情况中其实也没有必要对其进行模拟。比方说一个图书的质地，每页纸是否有损坏，是否被涂抹这样的信息不需要在软件系统中进行建模，解系统会从特定的角度对问题域只是进行抽象和简化，并模拟简化后的知识。

其实我们在进行数据库的学习之后，我们也可以发现解系统也有一些并非来自于现实模拟的特征，例如数据管理系统的选择、模型的范式化、索引的建立等等，这些因素并不对应域任何问题域知识，但是却是解系统中必不可少的部分。但这些都是另一门科目的话题了，在此按下不表。

1. 解决问题的方法

说完了问题域和解系统之间的关系之后，我们还得继续谈谈解系统解决问题的方法，因为模拟后的知识一共享现象，是解系统的一部分，所以解系统可以对其施加操作，适当改变这些知识。知识的改变会通过交互性传递给问题域，问题域在会接受改变的基础上继续规律性的运作，使问题得以解决。例如，要用软件跟踪记录用户在银行的存款情况，可以将用户在银行的账户建模为表Account (ID , Name, Balance) , 如果用户张三在现实世界中存了1000 元钱，那么软件系统就给" Name = ‘张三’＂的Account记录的Balance 增加1000。当其他银行职员看到软件系统中的这条记录时，也会接受张三存了1000元这个现实。再如，仓储用户想降低库存成本，软件系统可以将出入库信息建模为表Import和Export , 然后软件系统通过计算这两个表过去一段时间的值 ，给出将来一段时间会有多少仓储差额的预测值，仓储人员就会接受该预测值以保待最佳库存，由此自然能降低库存成本。

以上我们说的是最简单的直接处理方式，但有些情况下软件系统也会使用间接的方法来解决问题：软件系统操纵共享现象影响问题域的一部分，然后利用问题域内在的规律性自动影响另一部分。例如，图书管理员希望能够督促那些超期的借书者将所借的图书尽快归还。直接的解决方法是软件系统将借书者的联系方式建立一个表，并利用表格里的归还时间自动识别超期者并通过一些方式（如发送邮件）督促超期者归还图书。但这种方法有的时候由于成本或者各种各样的原因首先没有办法一一实现满足这种需求。这时候也许就得依靠间接的方法来解决问题，例如软件系统提供超期者的联系方式，然后由管理人员一个个通过软件系统提供的联系方式一个一个地打电话通知超期者归还图书。

 

• 需求工程过程

1. 概述

过程是一组相关活动的集成，通过这些活动的执行，可以完成一项任务或者达到一个目标。需求工程过程是系统开发中需求开发活动的集成，它以用户所面临的业务问题为出发点进行分析和各种转换，最终产生一个能够在用户环境下解决用户业务问题的系统方案，并将其文档化为明确的规格说明。

为了有效地理解用户问题，分析各种可能的系统解决方案，最终产生一个适宜的规格说明文档，需要将需求开发活动组织成一个系统化和严格的需求工程过程，这是人们随着系统 开发的进展而逐渐认识到的。在初期，系统开发的唯一焦点就是编码，此时不论系统大小， 开发都是一个单独的活动——编码。这个时期人们还不认为存在独立的需求开发活动。其后， 随着生命周期模型的引入，对系统开发活动的认知取得重大进展，人们认识到需求开发是系统开发中的一个独立的阶段，即软件开发生命周期模型的第一个阶段。在此后的进一步发展中，人们逐渐认识和接受了系统的演化式开发思想，认识到系统的实现往往是开始于一个并非完备的需求体系，发现需求开发也是一个递进的过程，包含一系列的独立活动。今天，大多数软件专业人士已经意识到需求工程也有属于它自己的生命周期模型，即存在针对需求开发的需求工程过程，这个过程又作为系统工程和软件工程的一个子过程部署在系统开发的初期阶段。

 

1. 需求工程活动

说到需求工程的活动，我们首先需要了解的是需求的获取，所谓需求获取，就是指需求工程师从人、文档或者环境中获取需求的过程。获取过程并不是简单地将定义良好地需求从人、文档或环境中直接转移到获取的结果文档上，需求工程师必须要利用各种方法和技术来“发现”需求。

需求开发的过程包含由学习和认知的过程，而学习和认知的过程是递进的，即学习一点，增加一些认识，然后在新的认知的基础上继续学习。

那么，我们要如何获取需求呢？从书本上看到，我们可以看到需求工程师主要的任务由以下几点：

1、收集背景资料

通过前面的学习，我们已经了解到需求工程师的主要任务就是发现用户的需求，那么，既然是为了发现用户的需求，就要得跟用户就业务问题进行交流，想要与用户之间进行交流，那么需求工程师应该首先具备能够和用户进行交流的知识基础。否则两者之间就无法形成有效的沟通，这是显而易见的。

2、获取问题与目标，定义项目前景和范围

在有了一定的知识框架之后，需求工程师就可以通过收集数据和文档观察环境，了解用户的需求、期望和关注点，综合推定用户在业务中所遇到的高层次问题。用户解决高层次问题的期望即为系统的业务需求，也就是系统要达到的目标。

 

3、识别涉众，选择信息的来源

在大部分的系统开发中，用户就是需求的主要来源，任何系统都是为了服务用户而存在的。但是一个大型的系统往往拥有着非常多的用户，因此在执行获取的时候想要覆盖所有的用户不仅费时费力，而且也是不必要的。一个可行的方案是通过少数用户来代表全体用户发表看法。但是系统中不同的用户往往在很多方面存在差异，如使用的产品工程，具有的计算机技能和使用产品的频率等。这些具有不同特性的用户对系统的需求往往也是不一样的，因此要想让选取的少数代表完整地表达用户地声音，就需要将用户分成不同地类型，然后在理解每种类型用户特征地情况下为其选择合适地用户代表。这个过程称之为涉众分析。

 

4、选择获取方法，执行获取，获取功能和非功能需求

需求获取的主要目的在于获取用户需求，了解用户在完成任务时遇到的问题与期望。获取有效用户需求的前提是能够正确理解用户的问题，所以针对每个获取的需求都要同时获取相关的问题域特性，在问题域特性充足的情况下，需求才能够正确体现用户的意图。问题域特性往往包含很多细节，要清晰地描述这些细节非常困难。所以简单地向用户提问“你需要系统为你做什么？”是无法达到预期目的的，需求工程师需要运用多种获取方法和技巧才能完成任务。

 

5、记录获取结果

需求工程师获取结果之后，需要将获取的信息及时地记录下来，因为刚刚获取的信息还没有进行分析于处理，所以获取笔录记录的内容往往具有凌乱、模糊、冗余和遗漏等诸多问题。

 

1. 需求分析

需求分析的主要工作就是通过建模来整合各种信息，以使人们更好地理解问题。同时，需求分析工作还会为问题定义一个需求集合，这个结合能够为问题界定一个有效地解决方案。需求分析还需要检查需求中存在地错误、遗漏和不一致等各种缺陷，并加以修正。

在获取系统地问题、目标、前景、范围之后，要使用问题分析、目标分析、业务分析等分析方法与技术对它们进行处理，并基于这些处理明确其解决方案，定义系统地边界。系统边界之内定义地是系统需要对外提供地功能，系统边界之外标识的是对系统有功能要求的外部实体或者对系统有所限制的环境要素。

解决完上述问题之后，我们还需要对软件需求进行建模，这是为了将抽象的信息转化为一个直观的模型为开发提供帮助，这是需求工程中最为重要和基础的一项任务。它将大量信息以清晰、条理的方式集成到一个模型中，让需求工程师对问题形成更为深刻的理解。需求工程师还可以依据模型进行推理，以创建能够界定可行解决方案的需求集合。为系统建立的模型还可以更好地将信息传递给开发人员。

 

 

1. 需求规格说明

在解决完上述问题之后，我们还需要将得到地结果写入说明档案，主要目的是在系统涉众之间交流需求信息，因此编写的文档应该具有一定的质量。这些质量特性有些来自于文档内所有独立需求的质量之和，有些来自于编写者的写作技巧，最重要的质量要求是简洁、精确、一致和易于理解。

需求规格说明在完成之后，我们为了不对设计、实现、测试等后续开发啊活动带来不必要的影响，需求规格说明文档里的每条需求至少要正确、准确的反映了用户的意图，而且需求集中在整体上需要具有完整性和一致性。文档的组织方式和需求的书写方式也应该具有可读性和可修改性。

只有以上条件得到满足，才能算得上是一份合格的需求规格说明文档。

 

• 总结

以上内容就是笔者对需求工程——软件建模与分析这本书1-3章内容的一点拙见。我一直认为软件开发目的的本质就是为了服务于用户，既然是为了服务于用户，那么就应该深入的去了解用户的需求。因此需求工程这门课程应该是对于软件工程的学生而言是非常重要的一门课。需要同学们进行深入的钻研。但是在本篇文章中有很多地方限于个人水平可能并没有对其进行很深入的了解，因此只能略微发表一些浅显的见解。至于建议，笔者深感水平不足，并无法对这本书的内容提出一些有价值的建设性意见，在接下来的时间里，仍需要对这门课程付出更多的努力。

 

 

文献引用

 

[ Robert 2002 ] Glass R L. Facts and fallacies of software engineering. Addison-Wesley , 2002

[ Shaw 1990 ] Shaw M. Prospect s for an Engineering Discip line of Software. IEEE Software , 1 990 , 7 ( 6 ) : 15- 24

[ Siddiqi 199 6 ] STDDlQI J, SHEKARANM C. Requirements engineering: the emerging wisdom . IEEE Software , 1 996,  

 

[ Larnsweerde 2000 ] Lamsweerde V. A Requirements  engineering in the year 00: a  Research perspective. Invited Paper for l CSE ' 2000-22nd International Conference on Software Engineering . Limerick: ACM Press, 2000.

[ Lubars 1993 ] LUBARS M, Potts C, Richter C. A review of the state of the practice in   requirements modeling. FirstInt' ISymp.Requirements Eng. LosAlamitos: IEEE CS Press , I 993: 2-14.

[ Maiden  2007]  MAIDEN  N,  NCUBEL  C,  ROB ERTSO N  S.  Can  requirements  be  Crea tive?  Exper ie nce s   with  an   En? han ced Ai r Space Manageme nt System . 29th Inte rna tional Con ferenc e on Software Engin ee ring ()CSE'07), 2007.

[ Minor 2004 ] MJNOR 0 , ARMA GO J. Requirements engineering: a close look at ind us try needs and model curricu?la. AW RE ' 04.

[ Nikula 2000 J NIKULA U, SJANIEMI J, Kalviainen H. A state- of- the- practice survey on requirements engineering in small- and medium - sized enterprises.Telecom Business Rese arch Center Lappeenranta. Lappeenranta 2000 .

[ Nuseibeh 2000 ] NUSETBEH B, EASTE RBROOK S. Requirements engineering: a road map.  Proceedings. of the 22nd Int' I Conference.on Software Engineering, Future of Software Engineering Track. New York: ACM Press, 2000

[ Oboler 2003 J OBOLER A, SQUIRE D , KORB, K. Why don' t we practice what we teach.Engineering Software forComputer Science Research in Academia . International Conference on Software Engineering Research and Applications (SERA 2003), 2003.