需求获取

　　我通读了这本书的第一部分，这里主要讲述了需求工程的一些入门知识。通读之后，我也有所收获。 　　下面，我把自己对需求工程的基础的理解进行简单描述。 　　一、需求过程的第一步时需求获取。需求获取是从人、文档或者环境中获取需求的过程。在需求获取中，需求工程师通常需要执行以下步骤： 　　1、收集背景资料。 　　2、定义项目前景和范围。 　　3、选择信息的来源。 　　4、选择获取方法，执行获取。 　　5、记录获取结果。 　　二、第二步是需求分析，它的主要工作是通过建模来整合各种信息，从而使人们更好的理解问题。同时，需求分析工作还会为问题定义一个需求集合，这个集合能够为问题界定一个有效的解决方案。需求分析还需要检查需求需求中存在的错误、遗漏、不一致等各种缺陷，并加以修正。其主要任务为： 　　1、背景分析。 　　2、确定系统边界。 　　3、需求建模。 　　4、需求细化。 　　5、确定优先级。 　　6、需求协商。 　　三、下一步是需求规格说明。获取需求需要被编写成文档，而编写文档的主要目的是为了在系统涉众之间交流需求信息，因此编写的文档应该具有一定的质量。 　　然后是需求验证。为了尽量不给设计、实现、测试等后继开发活动带来不必要的影响，需求规格说明文档中定义的需求必须正确、正确地反映用户的意图。因此，需求规格说明文档至少要满足下面几个标准： 　　① 文档内每条需求更正确、准确地反应了用户的意图

读《需求工程——软件建模分析》第一部分绪论 有感 软件的发展经历了以“机器”为中心、以应用为中心、以“应用”为中心、以“企业”为中心3个阶段。随着以“应用”为中心软件的发展，原有的个体化“软件作坊式”的软件开发方法带来了诸多问题，新的形势带来了新的挑战，面对转折，人们在思考体系结构、构件、中间件等新技术方法的同时，也在审视着新时期的软件生产情况，时刻关注着可能出现的新型软件危机。为此，20世纪90年代出现了大量对软件生产状况的调研和评估，发现了一些非诚严峻的事实。 　　应用型软件在模拟现实的基础上，接受用户的请求，协助用户完成任务，它正确工作的基础是具有模拟性。模拟性具体指：目的性、正确性、现实可理解性。软件生产中产生需求问题的最大原因在于对应用型软件的模拟特性理解不透彻或应用不坚决，他会导致软件开发者产生轻视需求的态度问题，但除此之外，还有一些技术原因也会导致需求问题的产生：非技术性和社会性因素的重视不足、传统需求分析方法的缺陷、软件规模的日益扩大、需求问题的高代价性。 　　需求工程是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终反映软件被应用后与其环境互动形成的期望效应。需求工程的主要任务有以下三点，需求工程必须说明软件系统将被应用的环境及其目标，说明用来达成这些目标的软件功能，还要说明在设计和实现这些功能时上下文环境对软件完成任务所用方式

IEEE对需求定义为：①用户为了解决问题或达到某些目标所需要的条件或能力。②系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力。③对①或②中的一个条件或一种能力的一种文档化表述。通过这个定义了解了需求并不是用户想要的，想实现的，了解了需求本质的内涵。 功能需求是软件系统需求中最常见、最主要和最重要的需求，同时也是最为复杂的需求。功能需求通常体现为三个层次：业务需求、用户需求、系统需求。 业务需求描述了组织为什么要开发系统，满足用户的业务需求。业务需求是用户需要在业务上使自己更加方便的开展工作的需求。 用户需求表达了用户对系统的期望，但是要透彻和全面地了解用户的真正意图，仅仅拥有期望是不够的，还需要期望的背景知识。因此，对所有的用户需求，都应该有充分的问题域知识作为背景支持。而在实际工作中，用户表达自己的期望时，通常不会提及需求所涉及问题域知识，所以需求工程需要根据用户的需求整理完整的问题域知识。 系统需求是用户对系统行为的期望，一系列的需求联系在一起可以帮助用户完成任务，达到用户需求，进而满足业务需求。需求工程可以直接映射为系统行为，定义了系统中需要实现的功能，描述了开发人员需要实现什么。 将用户需求转化为系统需求的过程，在该过程中，首先需要分析问题领域的特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型

IEEE对需求定义为：①用户为了解决问题或达到某些目标所需要的条件或能力。②系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力。③对①或②中的一个条件或一种能力的一种文档化表述。通过这个定义了解了需求并不是用户想要的，想实现的，了解了需求本质的内涵。 功能需求是软件系统需求中最常见、最主要和最重要的需求，同时也是最为复杂的需求。功能需求通常体现为三个层次：业务需求、用户需求、系统需求。 业务需求描述了组织为什么要开发系统，满足用户的业务需求。业务需求是用户需要在业务上使自己更加方便的开展工作的需求。 用户需求表达了用户对系统的期望，但是要透彻和全面地了解用户的真正意图，仅仅拥有期望是不够的，还需要期望的背景知识。因此，对所有的用户需求，都应该有充分的问题域知识作为背景支持。而在实际工作中，用户表达自己的期望时，通常不会提及需求所涉及问题域知识，所以需求工程需要根据用户的需求整理完整的问题域知识。 系统需求是用户对系统行为的期望，一系列的需求联系在一起可以帮助用户完成任务，达到用户需求，进而满足业务需求。需求工程可以直接映射为系统行为，定义了系统中需要实现的功能，描述了开发人员需要实现什么。 将用户需求转化为系统需求的过程，在该过程中，首先需要分析问题领域的特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型

这次阅读的时间有点长，读的磕磕绊绊，下面是我的一些收获： 相信做软件的都知道，需求获取是一件非常困难的事，王老师说他们做项目的时候，拎着电脑包去做需求调研，里面工作的人一看就嫌弃的表情，他们那些人又来了，同样，在跟对方经理聊天的过程中，对方也经常会打断谈话去处理一些别的事，但对于做一个项目，偏偏需求分析是至关重要的一环，在需求分析的过程中，我们经常会遇到各种各样想象不到的问题。所以了解这些困难对更好地了解需求获取活动的复杂性有重要意义。本书中介绍了几种常见的困难： 1.用户和开发人员的背景不同，立场不同，因此会存在交流困难。要解决这个问题，就要求开发人员在开展需求获取之初，尽力去研究应用的背景，理解组织的业务状况，形成一个能够和用户进行有效沟通的粗略的知识框架； 2.普遍用户缺乏概括性、综合性的表述能力。为解决这个困难，要求开发人员在与用户接触之前就先行确定获取的内容主题，然后设计具体的应用环境和场景条件，让用户在执行细节业务的场景中来描述问题和表达愿望； 3.用户存在认知困境。要解决这类问题，开发者就需要利用各种有效的需求获取方法和技巧，引导用户去发现用户尚未形成明确认知的知识； 4.用户越俎代庖。要解决用户越俎代庖带来的困难，就要求开发者在需求获取的过程中，注意保持业务领域和解决方案的区分界限。而且越俎代庖式需求的出现，往往意味着用户还拥有一些重要的隐藏需求没有被发现

笔记要求：发表一篇阅读笔记，说明本学期《软件需求分析》需要掌握哪些必要的内容？针对每个内容点说出自己的理解，并绘图示意相互之间的关联关系。 　　　　　　　　　 　读《需求工程——软件建模与分析》有感 　　 今天大致的看了一下这本书，对软件需求分析有了初步的了解，我认为学习软件需求分析需要掌握的内容主要包括五个方面：需求基础与过程、需求获取、需求分析、需求的文档化和验证、需求管理与工程管理。 　　 一、需求的基础与过程 　　这一部分主要是对软件需求有一个大致的了解，例如需求的概念，不同群体的人们对需求有不同的理解，IEEE对需求的定义：用户为了解决问题或达到某些目标所需要的条件和能力；系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的需求而需要具备的条件或能力。 　　软件系统通过影响问题域，能够帮助人们解决问题，成为解系统。解系统是问题的解决手段，但是并不是问题的产生地。所以，解系统并不是问题域的一个部分，它们之间存在可以相互影响的接口，以实现交互活动。 　　功能需求被分为：业务需求、用户需求、系统需求。三者之间有所区别，将用户需求转化为系统需求是一个复杂的过程。 　　需求工程的过程就是：需求获取、需求分析、需求规格说明、需求验证、需求管理的过程。 　　 二、需求获取 　　 顾名思义，需求获取就是进行需求收集的一个活动，他从人员、资料和环境中得到的系统开发所需要的相关信息。

需求工程活动分为需求获取和需求分析、需求规格说明、需求验证、需求管理。需求获取是从人、文档或环境中获取需求的过程，需求工程师必须要利用各种方法和技术来 “发现”需求。需求开发的过程包含有学习和认知的过程，而学习和认知的过程是递进的，因此需求获取和分析是交织在一起的，需求工程师需要获取一些信息，随即进行分析和整理，理解、认知到一定程度后在确定要进一步获取内容。在需求获取中，需求工程师需要执行任务包括收集背景资料、获取问题与目标，定义项目前景与范围，识别涉众，选择信息的来源，选择获取方法，执行获取，获取功能与非功能需求，记录获取结果。需求分析阶段，需求工程师主要任务包括 1 背景分析 2 问题分析、目标分析、业务分析、确定系统边界 3 软件需求建模 4 细化需求 5 确定优先级 6 需求协商。 获取的需求下需要编写成文档，业务需求被写入项目前景和范围文档，用户需求被写入用户需求文档（或用例文档），系统级需求被写入需求规格说明。需求工程师在这个阶段主要工作包括定制文档模板好编写文档。需求验证主要任务包括 执行验证、问题修正 。 需求管理主要任务包括 1 建立和维护需求基线集 2 建立需求跟踪信息 3 进行变更控制。需求开发过程是迭代的和并发的，而且它的两个重要活动 - 需求获取与需求分析 - 还是交织的，共同构成一个学习过程。相比与编程，需求是众多因素影响的不确定性，是实践与理论并用。

需求工程复习 1.2.1需求工程简介 定义 简单地说，需求工程是所有需求处理活动的总和，它收集信息，分析问题，整合观点，记录需求并验证其正确性 从细节上说，需求工程是软件工程的一个分支，它关注软件系统所应实现的现实目标，软件系统的功能和软件系统应当遵守的规约 3个任务： 必须说明软件系统将应用的环境与目标，‘“做什么”，“怎么做” 必须将目标，功能，约束反映到系统软件中 妥善处理目标，功能和约束随着时间的演化 基本活动 需求工程分为 需求开发 与 需求管理 需求管理 ：需求管理是对需求开发所建立的需求基线的管理。它在需求基线完成后正式开始，在需求工程结束之后继续存在 需求开发 需求获取：从项目战略规划开始建立的最初原始需求 需求分析：保证需求的 完整性 与 统一性 需求规格说明：将完整性，一致性的需求与能够满足需求的软件行为以文档方式明确固定下来 需求验证：保证需求及其文档的 正确性 ， 完整性 与 一致性 ，最后统一意见，得出需求规格文档 2.2.2 问题与与解系统 问题域与解系统的关系 问题域：是需求的背景，解决问题必须涉及的事件和事物，即解决问题的基本范围（用户关注的问题） 解系统：指的是软件系统，软件系统通过影响问题域帮助人们解决问题，是软件解决方案在计算机上的实现（开发人员关注的问题） 关系：两者通过接口连接起来，这个接口就是**(模拟性)共享对象**

1 概述 需求工程是应用已证实有效的技术与方法开展需求分析,确定客户需求,帮助分析人员理解问题,评估可行性,协商合理的解决方案,无歧义地规约方案,确认规约以及将规约转换到可运行系统时的需求管理.需求工程是一个不断反复的需求定义,文档记录,需求演进的过程,并最终在验证的基础上冻结需求.需求工程可以分为六个阶段:需求获取,需求分析与协商,系统建模,需求规约,需求验证,需求管理. 2 需求获取 需求获取阶段分析人员通过与用户的交流,对现有系统的观察以及对任务进行分析,确定系统或产品范围的限制性描述,与系统或产品有关的人员及特征列表,系统的技术环境的描述,系统功能列表及应用于每个需求的领域限制,描述不同运行条件下系统或产品使用状况的应用场景等,为需求分析打下基础. 2.1 软件需求 软件需求是指用户对目标软件系统在功能,行为,性能,设计约束等方面的期望,包括: 2.1.1 功能需求 考虑系统要做什么,在何时做,在何时及如何修改或升级等. 2.1.2 性能需求 考虑软件开发的技术性指标,例如,存储容量限制,执行速度,响应时间以及吞吐量. 2.1.3 用户或人的因素 考虑用户的类型,例如用户对使用计算机的熟练程度,需要接受的训练,用户理解,使用系统的难度,用户错误操纵系统的可能性等. 2.1.4 环境需求 考虑未来软件应用的环境,包括硬件和软件,对硬件设备的需求包括机型,外设,接口,地点,分布

一、开发模型 　　传统的软件开发过程可以划分为：问题定义、需求分析、软件设计、软件实现、软件测试等过程。如果采用传统的开发过程，软件体系结构的建立应位于需求分析之后，概要设计之前。 　　基于体系结构的软件开发模型（ABSDM），把整个软件过程划分为为：体系结构需求、设计、文档化、复审、实现、演化等六个子过程。 　　1、体系结构需求 　　需求是只用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。体系结构需求受技术环境和体系结构设计师的经验影像。需求过程主要是获取用户需求，标识系统中所要用到的构件。 　　1.1、需求获取 　　体系结构需求一般来自三方面：系统的质量目标、系统的商业目标、系统开发人员的商业目标。软件体系结构需求获取过程主要是定义开发人员必须实现的软件功能，是的用户能完成他们的任务，从而满足业务上的功能需求。于此同时，还要获得软件质量属性，满足一些非功能性需求。 　　1.2、标识构件 　　这一步又可分为三步实现： 　　第一步：生成类图。使用CASE工具生成类图。 　　第二步：对类进行分组。分组后会简化类图结构，使之更加清晰可读。一般，根据类之间的耦合度和内聚度进行分组。例如，在实践DDD时，就可以把一个聚合进行分组，多个聚合即分为多组。 　　第三步：把类打包成构件。做到构件级的重用。构件和构件又可以打包成更大的构件。 　　1.3、需求评审