计算机科学与工程学院实验报告（首页）
课程名称 软件需求分析与建模 班级 18软件工程5班
实验名称 我对需求分析与建模的认识与应有内容建议 教导教师 董瑞生
姓名 郑远曦 学号 1814080902515 日期 2020．10.9

目录
一、背景 2
二、认识 2
第一章 2
1.1.1需求问题是当前软件开发面临的主要问题 2
1.1.2软件的模拟特性。软件的模拟特性来源于其知识载体的特性 2
1.1.3需求问题具体原因分析 3
1.2需求工程 3
1.2.1需求工程简介 3
1.2.2需求工程与系统工程 4
1.2.3需求工程的重要性需求工程的重要性 4
1.2.4需求工程的复杂性 4
1.3需求工程师 4
第二章 4
2.1需求的定义 4
2.2满足需求就是解决问题 4
2.2.1问题与需求 4
2.2.2问题解决的两个方面——问题域与解系统 5
2.2.3问题解决的基础——模拟与共享现象 5
2.2.4问题解决的方法——直接与间接 5
2.2.5问题解决方案——需求规格说明 5
2.2.6问题解决的困难性 5
2.3需求和问题都有层次性 5
2.3.1战略问题与业务需求 5
2.3.2任务问题与用户需求 5
2.3.3系统行为问题与系统级需求 6
2.3.4需求开发要遵从层次性 6
2.4需求的分类与表述 6
2.4.1需求的分类 6
2.4.2功能需求 6
2.4.3性能需求 6
2.4.4质量属性 6
2.4.5对外接口 7
2.4.6约束 7
2.4.7其他需求 7
2.5优秀需求的特性 7
第三章 7
3.2需求工程活动 7
3.2.1需求获取 7
3.2.2需求分析 8
3.2.3需求规格说明 8
3.2.4需求验证 8
3.2.5需求管理 8
3.3需求开发过程是迭代和并发的 8
3.4实践方法的应用 8
3.4.1细节知识的实践性 8
3.4.2重要的实践方法 8
3.5需求开发过程实例 9
3.6需求开发过程与软件工程过程的相互影响 9
三、总结 9

我对需求分析与建模的认识与应有内容建议
一、背景
软件需求位于软件工程的起始阶段，是软件系统开发中一个重要的独立工作阶段，为软件工程后续阶段提供了工作基础，对软件项目的成败至关重要。20世纪末，随着软件系统规模的扩大和复杂程度的增长，以需求分析为重心的传统需求处理技术已经不能适应现代软件技术发展的要求，完整的需求工程过程应运而生。需求工程是开发者在进一步深入理解软件项目需求处理活动之后提出的一个阶段性活动。同传统的需求分析相比，在需求工程中，软件需求处理不仅仅停留在单纯的分析与建模，需求的获取、建模、文档化、验证及管理等都是其中必需和重要的工作。
到目前为止，学术界与产业界在需求工程领域取得了较大的进展，研发了一系列有效的需求技术、方法和工具，构成了一个完整的需求工程过程框架。但是，尚有大量理论、方法和技术有待于广泛传播和全面应用，特别是需要进行系统化的实践。本书是关于软件需求工程的专门著述，目标是从开发者的视角出发，侧重于实践者的技术与方法，系统地介绍需求工程中的最新进展，促进需求工程领域理论、方法和技术的全面融合应用，指导需求工程各阶段的系统化实践。

二、认识
第一部分绪论是对需求工程的宏观介绍，包括第1~3章。
第1章介绍需求工程产生的背景，说明它在整个软件工程中的地位，并简要描述需求工程，介绍了需求工程是所有需求处理活动的总和，反映软件被应用后与其环境互动形成的期望效应。
1.1.1需求问题是当前软件开发面临的主要问题
无论是实践者的切身体会，还是各种调查数据，都明确指出需求问题是当前软件开发面临的主要问题之一。在所有调查数据中，以美国专门从事跟踪工厂项目成功或失败的权威机构Standish Group的CHAOS系列报告最广为人知。在Standish Group的调查中将软件项目分为3种类别：①在预计的时间之内，在预算的成本之下完成预期的所有功能，则项目为成功项目。②已经完成，软件产品能够正常工作，但在生产中或者超支，或者超期，或者实现的功能不全，则项目为问题项目。③因无法进行而被中途撤销，或者最终产品无法提交使用，则项目为失败项目。
1.1.2软件的模拟特性。软件的模拟特性来源于其知识载体的特性
软件在运行中表现出来的特性、行为应该和应用的现实情况保持一致。这样，人们通过观察软件的表现就可以得出相应现实问题的答案，即软件“模拟”了现实。例如，在图书管理软件中，如果在张三没有借书的情况下，软件系统产生了一条张三借书的记录，则该软件系统将会被认为是运行不正常和存在缺陷的，原因即在于借书情况的记录和现实中发生的借书事件没有保持一致。在软件和现实保持一致的情况下，人们不再需要为了查找一本书而翻遍所有的书架，通过软件系统进行书目查询就可以得到准确的答案。软件的冗余功能问题也从另一个侧面很好地反映了它的模拟特性。在软件开发中，一方面只能完成预期功能的60%～70%，另一方面移交软件中却存在着大量的冗余功能，这些功能用户从来不会使用。
应用型软件在“模拟”现实的基础之上接收用户的请求，协助用户完成任务，它正确工作的 基础是具有“模拟”性。“模拟”性具体是指以下几点：
①目的性。软件的目标是直接或间接地满足用户的某些目的或者解决用户的某些问题，软件的功能是据此设立的。
②正确性。软件具备的功能能够保证目标的正确实现。
③现实可理解性。软件实现其功能的基础、手段和过程是在用户领域内现实可理解的，即 软件系统是在理解其现实环境的基础上，通过影响现实的某些环节，或者改变现实各部分的通信 方式，最终达成某些目的或者解决某些问题的。
应用型软件一般以普通用户为应用对象，因此也要求具有使用的方便性。实现功能的“模拟”性和使用的方便性也仅要求所用技术具有可行性。和工具型软件不同，应用型软件通常不是 通用的，它们是为特定的应用环境定制的，对环境的“模拟”性是其主要的关注点。
不同的评判标准和关注点决定了 3类软件在生产中也会有所不同，尤其是 在分析阶段具有截然不同的目标：面向专业用户的工具型软件通常在具有一定的观念创新或技 术创新后执行功能分析，分析阶段的主要目的是为充分利用创新优势而进行巧妙的功能安排；面 向普通用户的工具型软件进行分析的主要目的是进行方案权衡，寻找一套切实有效的功能配置； 应用型软件分析阶段的主要目的是发现人们利用软件的原因（目的），找出需要软件解决的问 题，理解应用环境中的领域知识，保证功能的“模拟”性。
1.1.3需求问题具体原因分析
软件生产中产生需求问题的最大原因在于对应用型软件的模拟特性理解不透彻或应用不坚 决，它会导致软件开发者产生轻视需求的态度问题。除此之外，还有一些技术原因也会导致需求 问题的产生。
1．非技术性和社会性因素重视不足。应用型软件的模拟特性使得需求处理具有很突岀的特性。相对于软件开发的其他阶段而 言，需求处理阶段涉及更多的非技术性和社会性因素，并且其所受的影响也远远高于其他阶段。 20世纪90年代之前的需求处理往往更专注于技术处理，而对其中的非技术性和社会性因素重 视不足。
2、传统需求分析方法的缺陷。传统的需求分析方法，如结构化分析和面向对象分析，都是从设计领域转入分析领域的。虽 然它们在设计阶段取得了很大的成功，但它们并不非常适合于需求阶段的技术处理需要，因此它 们在需求处理中的应用具有一定的先天缺陷。
传统的结构化方法和面向对象方法都是最先在编程领域取得成功的，它们所用的概念和组 织机制都是从编程领域抽象出来的。其后，它们又都相继被用来进行软件设计，因为设计和编程 都有构建高质量(健壮性、可维护性、适应性等)软件的共同目标，而且使用相同的概念和组织机 制保证了从设计到编程的平滑过渡，所以它们在设计领域的应用也取得了成功。而后它们又被 进一步应用到分析领域，但是需求分析除了拥有构建高质量软件的目标之外，还有一个更加重要 的目标是理解现实，而这是传统分析方法所拥有的概念和组织机制所无法实现的，所以说传统分 析方法在需求分析领域的应用具有先天缺陷。
3、软件规模的日益扩大。在软件以单一任务或几个相关任务为应用领域时，软件应用的上下文环境相对局限在某个 部门或者某个角色，甚至某个个人的任务范围之内，涉众非常有限。所以，它所涉及的组织机构 文化、社会背景、商业目标和利益协商等非技术性因素自然也相对较少。而且该类软件的需求来 源往往很有限，所以每条需求相对较为完整和一致，可理解性相对较好，进行技术分析时对“为什 么做”(why)进行描述的要求不是非常必要。
在软件以企业为中心时，很少有用户能够单独给出对全局的理解，进而得出需求。相反，每 个用户往往仅能给出与其相关的片段，需要分析人员将所有用户的片段连接起来，构成全局理 解，导出需求。因此，该类软件要求分析人员能够在拥有相对有限的用户描述片段或者用户描述 片段间有冲突时进行相对正确的解读，即需求分析对规格说明可理解性的要求加强，这样对“为 什么做”进行描述就显得非常重要，因此传统分析方法的缺陷也就更加明显。
4、需求问题的高代价性。需求处理是软件工程的起始阶段，设计、实现等后续阶段的正确性都以它的正确性为前提。 如果在需求处理过程中有错误未能解决，则其后的所有阶段都会受到影响，因此与需求有关的错 误修复代价较高，需求问题对软件成败的影响较大。统计表明，在需求阶段发生的错误如果到了 维护阶段才发现，则在维护阶段进行修复的代价可能高达需求阶段修复代价的100~200倍。这种递增效应也说明了需求问题的高代价性。

1.2需求工程
在对软件工程中的需求问题进行了大量调查和分析之后，于20世纪90年代提出了重视需 求处理的要求。这时人们认识到需求处理除了核心的建模与分析活动之外，还有其他的活动也 需要慎重对待，因此提出了“需求工程”的说法，即利用工程化的手段进行需求处理，以保证需求处理的正确进行。
1.2.1需求工程简介
需求工程有以下3个主要任务。
① 需求工程必须说明软件系统将被应用的环境及其目标，说明用来达成这些目标的软件功 能，还要说明在设计和实现这些功能时上下文环境对软件完成任务所用方式、方法所施加的限制 和约束，即要同时说明软件需要“做什么”和“为什么”需要做。
② 需求工程必须将目标、功能和约束反映到软件系统中，映射为可行的软件行为，并对软件 行为进行准确的规格说明。需求规格说明是需求工程最为重要的成果，是项目规划、设计、测试、 用户手册编写等很多后续软件开发阶段的工作基础。
③ 现实世界是不断变化的世界，因此需求工程还需要妥善处理目标、功能和约束随着时间 的演化情况。同时，为了节省开支和进行需求规格说明的重用，需求工程还需要对目标、功能和 约束在软件产品族中的演化和分布情况进行综合考虑与处理。
1.2.2需求工程与系统工程
系统需求开发的主要目的是获得整个系统的期望目标，包含功能特征和非功能特征（如性能 要求等）。为此需要判断系统的涉众，釆集他们的目标与要求，研究系统的环境，确定系统的约 束，并进行一些整体性的需求分析。系统需求开发阶段的需求分析主要是分析系统的成本效率 及系统的组织和行政策略，处理互相依赖、冲突、重叠或不一致的涉众需求，检査并弥补需求缺 失，检查技术储备、外部系统等环境约束。系统需求开发的结果会写入系统需求规格说明。
1.2.3需求工程的重要性需求工程的重要性
增强了项目涉众du对复杂产品特征在细zhi节和相互依赖关系上的理dao解， 增强了项目涉众对需求( 尤其是复杂需求) 的掌握 ; 增进了项目涉众之间的交流， 减少了可能的误解和交流偏差; 需求管理能够更加有效地处理需求变更，提高了生产效率; 需求跟踪信息能够更加准确地反映项目的进展情况，以便进行更好的项目决策; 使得项目涉众认识到需求在项目工作中的重要性， 使得需求的作用得到重视和有效发挥。良好的需求分析和管理工作， 才能把系统的功能描述和性能指标转化为具体的软件需求规格说明书，成为系统建设的依据和基础。
1.2.4需求工程的复杂性
1、处理范围广泛；2、设计诸多参与方；3、处理内存多样；4、处理活动互相交织。
1.3需求工程师
1、需求工程师是涉众和开发者之间的桥梁。需求工程师的重要性就体现在他的桥梁作用上，如图1-8所示。如果没有需求工程师的工 作，设计师、程序员等开发者就会在深入并准确理解涉众的想法上出现困难，涉众在见到最终的 软件之前也无法把握软件是否满足了他们的想法，最终会导致涉众与开发者之间出现大量的沟 通不畅与误解，导致项目返工甚至失败。需求工程师一切工作的核心就是扮演好桥梁作用：在面对涉众时，需求工程师就是后续软件 开发者的代理，负责设计软件方案以满足涉众的各项需求；在面对后续软件开发者时，需求工程 师就是涉众的代理，准确地将各项需求告知开发者。2、需求工程师需要具备的技能。合格的需求工程师需要具备多方面的知识和技能、必须熟练掌握软件开发方法与技术、要有非常精准的表达能力，要有非常好的交流沟通能力。3、需求工程师要重视“软技能”：1）交流技能；2）观察技能；3）抽象分析与问题解决技能；4）写作技能；5）关系协调和团队工作技能。4、需求工程师需要创新。1）软件系统并不仅仅是模拟现实，还要让现实变得更好。这需要需求工程师以现实为基础 构思现实中不存在的软件解决方案；2）需要认识到的是,这些创新并不是脱离现实随意构思的与涉 众不同的想法，而是需要需求工程师敏锐地洞察现实才能实现的创新。5、需求开发是团队行为。

第2章介绍从需求产生的根源出发，说明需求工程的内容、目标、作用和意义。
2.1需求的定义
1）用户为了解决问题或达到某些目标所需要的条件或能力；2）系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的 条件或能力；3）对①或②中的一个条件或一种能力的一种文档化表述。

2.2满足需求就是解决问题
2.2.1问题与需求
需求源于问题，要准确理解需求，就必须明确它与问题的关系。认为当现实的状况与人们期望的状况产生差距时，就产生了问题。问题中的差距要么是某些事件、 事物的状态不理想，要么是某些事情的发生过程不理想。要 解决问题，就需要改变这些事件、事物的状态，或者改变其状 态变化的演进顺序，使其达到期望的状态和理想的演进顺序。
2.2.2问题解决的两个方面——问题域与解系统
1）问题域。问题域是需求的背景，要理解需求就必须先理解问题 域。例如，要准确理解需求“将利润率提高到5%”，就需要弄 明白利润由哪些部分组成，各自的比例是多少，工作是如何 完成的……再如，要准确理解需求“用户可以查询商品详细信息”，就需要了解哪些用户在哪些 任务中需要査看哪些商品的详细信息……总之，虽然表达期望的需求看起来比较简单，但是只有 明白问题域的复杂背景信息才能真正理解需求的含义。2）解系统。解系统是问题的解决手段，并不是问题的产生地，所以解系统并不是问题域的一部分。解系 统与问题域之间存在可以互相影响的接口，以实现交互活动。3）问题域和需求。4）解系统与需求规格说明。解系统的核心是软件解决方案和解决方案在通用计算机上的实现。虽然解决方案及其实现 都关注于软件系统本身，但相互间也有所不同。解决方案描述的是软件系统与问题域交互的过 程，侧重于软件系统中与外界交互的部分。实现部分则主要是软件内部的组成元素、结构关系、 物理实现等软件系统的构造要素。需求工程所关心的仅仅是解决方案，不涉及软件的实现细节。
2.2.3问题解决的基础——模拟与共享现象
处于问题域之外的解系统之所以能解决问题域中的问题，是因为问题域与解系统之间存在 有效的互动，并在互动中互相影响。而问题域与解系统能够形成互动的基础是解系统部分模拟了问题域,将这种模拟性称为共享现象。
2.2.4问题解决的方法——直接与间接
因为模拟后的知识一一共享现象，是解系统的一部分，所以解系统可以对其施加操作，适当 改变这些知识。知识的改变会通过交互性传递给问题域，问题域在会接受改变的基础上继续规 律性的运作，使问题得以解决。例如，要用软件跟踪记录用户在银行的存款情况，可以将用户在 银行的账户建模为表Account (ID, Name, Balance),如果用户张三在现实世界中存了1000元 钱，那么软件系统就给“Name='张三的Account记录的Balance增加1 000。当其他银行职员看 到软件系统中的这条记录时，也会接受张三存了 1 000元这个现实。再如，仓储用户想降低库存 成本，软件系统可以将出入库信息建模为表Import和Export,然后软件系统通过计算这两个表过 去一段时间的值，给出将来一段时间会有多少仓储差额的预测值，仓储人员就会接受该预测值以 保持最佳库存，由此自然能降低库存成本。
2.2.5问题解决方案——需求规格说明
因为解系统解决问题的方法是改变共享知识，影响问题域的运行，进而满足用户的需求。所 以需求规格说明主要包括两部分（如图2-5所示）：对共享现象（模型）的描述和对系统对共享现 象所施加的操作的描述。这也是软件系统中最为核心的两个部分:数据与功能。
2.2.6问题解决的困难性
2.3需求和问题都有层次性
2.3.1战略问题与业务需求
业务需求是抽象层次最高的需求，是系统建立的战略岀发点，表现为高层次的目标,它描述了组织为什么要开发系统。
2.3.2任务问题与用户需求
高层次的目标是由组织的决策者提出的，但普通用户才是组织中任务的实际执行者，只有通 过一套具体并且合理的业务流程才能真正实现目标。用户需求就是执行实际工作的用户对系统 所能完成的具体任务的期望，描述了系统能够帮助用户做些什么。用户需求主要来自系统的使 用者——用户。在有些情况下，系统的直接用户不可知，如通用的软件系统或社会服务领域的软 件系统等，所以用户需求也可能来自间接的渠道，如销售人员和售后支持人员等。

2.3.3系统行为问题与系统级需求
业务需求描述了系统的目标与效益，适合决策者；用户需求描述了具体任务，适合用户；它 们都不适合于软件开发者。适合软件开发者的需求层次是系统级需求，它关注的是软件系统 的行为，尤其是系统与外界的交互行为：在接收到一个外界请求时，软件系统应该给外界提供 响应。所以系统级需求的典型形式是“系统可以XXX”或者"在XX用户提出XX请求时，系统应 该XXX”。
2.3.4需求开发要遵从层次性
在3个不同层次的功能需求中，业务需求具有明显的目的 性和较高的抽象性，比较容易获取和确认。所以需求开发往往 从获取业务需求开始。有了业务需求之后，就可以确定系统的 最终目标和努力方向，进而指导具体的需求获取活动，发现用户需求。用户需求经过明确和细化的处理，可以转化为系统级需求。
2.4需求的分类与表述
需求需要被文档化表述，这要求需求工程师搞清楚需求有哪些类型以及每种类型如何进行 表述。
2.4.1需求的分类
分类的目的是为了区别对待，否则分类就失去了意义。需求分类是为了将需求划分为需要 区别对待的不同类型，每种类型会被文档化到不同的部分，服务于不同的读者、不同的目的。1、广泛意义上的需求谱系。从严格的意义上来说，项目需求与过程需求都不能算是需求，因为它们并不是用户对问题解 决的期望，而是用户对软件开发活动本身的要求。硬件需求与其他需束也不属于用户对问题解 决的期望，而是为了让软件能够成功运营而需要适应的环境与活动。但是在文档化需求的材料 中，经常会出现项目需求、过程需求、硬件需求和其他需求，因为它们对需求工程师及开发者正确 理解软件需求甚至整个产品具有极其重要和不可缺少的作用，所以它们经常出现在需求文档中。2、严格意义上的软件需求分类。从严格意义上讲，软件需求是直接或间接关系到软件系统功能的期望。根据不同的分类标 准，可以将需求分成不同的种类。在各种需求分类中最常见的是［IEEE 1998］的分类,［IEEE 1998］将需求分成下列几个类别。1）功能需求；2）性能需求；3）质量属性；4）对外接口；5）约束。除功能需求之外的其他4种类别需求又被统称为非功能需求(non-functional requirement)。 在非功能需求中质量属性对系统成败的影响极大，因此在某些情况下，非功能需求又被用来特指 质量属性。
2.4.2功能需求
功能需求是软件系统需求中最常见和最重要的需求，同时也是最为复杂的需求。功能需求是一个软件产品得以存在的原因，是软件系统能够解决用户问题和产生价值的基础，也是整个软件开发工作的基础。所有开发者都需要了解功能需求。在复杂的系统中功能需 求数量太多，所以需要将它组织为多个独立部分，然后按照分工原则由不同的开发者来处理不同 的部分。
2.4.3性能需求
[IEEE 1990]对性能的定义是：一个系统或其组成部分在限定的约束下，完成其指定功能的程度，如速度、精确性和内存使用程度等。性能需求定义了系统必须多好和多快地完成专门的功能。常见的性能需求包括以下几种。1）速度；2）容量；3）吞吐量；4）负载；5）实时性。
2.4.4质量属性
1、质量属性的概念。为了度量一个系统的质量，人们通常会选用系统的某些质量要素进行量化处理，建立质量特征，这些特征称为质量属性。2、质量模型。为了更好地根据质量属性描述和评价系统的整体质量，人们从很多质量属性的定义中选择 了一些能够相互配合、相互联系的特征集，它们被称为质量模型。3、质量属性的重要性。质量属性对设计的影响很大。在软件设计中对任何指定的功能都会有多种可选的方案， 不同的方案选择产生不同的设计结果。这些不同的设计结果都体现了共同的功能特性，但它 们之间却有着很大的区别，差异之处即在于拥有不同的质量因素。设计方案的质量因素往往 包含很多不同的质量属性，而且不同的质量属性之间互有折中(如提高可移植性往往会导致 效率降低)，很难会岀现某一个设计方案的质量属性完全优于其他方案的情况。因此，软件 设计必须根据需求的质量属性在多种方案中选择一个最优的方案。如果不存在事先定义 好的质量属性需求，设计方案的选择将完全没有依据，结果就很有可能导致软件不被用户接受。4、质量属性需求的开发。在发现质量属性后，要想了解用户的真正想法，需求工程师还需要和用户以及开发人员一起 从多个角度进行质量的定义。进行质量属性的定义时，应当将其与相联系的功能需求关联起来。 不能和功能需求建立联系的全局性质量属性应该统一进行处理。5、常见的质量属性需求。1）可靠性；2）可用性；3）安全性；4）可维护性；5）可移植性；6）易用性。
2.4.5对外接口
对于解系统而言，问题域中的其他软件系统也属于问题域的一部分，且为一个比较特殊的部 分。因此用户有权对解系统和其他系统之间的软硬件接口提出要求。解系统的对外接口也是一种重要的需求。
2.4.6约束
约束是不受解系统影响，却会给解系统带来极大影响的问题域特性。因为不受解系统的影 响，所以从解决问题的角度来看约束不会要求解系统为其进行专门的设计。但是如果解系统不 满足约束，那就意味着问题域并不能够提供解系统要求的运行环境，解系统将无法在问题域内成 功地部署和运行。因此，约束是在总体上限制了开发人员设计和构建系统时的选择范围。常见的约束主要有以下几种：1）系统开发及运行的环境；2）问题域内的相关标准；3）商业规则；4）社会性因素。
2.4.7其他需求
实践中，需求文档还常常会文档化其他类型的需求，如安装需求0R1、培训需求0R2和数据 需求等，其中数据需求较为常见。
2.5优秀需求的特性
理想情况下，需求应该既是解决用户问题所需要的，又是表述清晰的；既是用户的需要，又是开发者的需要。为此，人们定义了一些优秀需求应该具备的特性，下面是其中比较重要的部分。1、完备性 2、正确性 3、可行性 4、必要性 5、无歧义 6、可验证。

第3章介绍需求工程的活动框架，概述需求工程中的主要活动和实践方法。过程是一组相关活动的集成，通过这些活动的执行，可以完成一项任务或者达到一个目标。 需求工程过程是系统开发中需求开发活动的集成，它以用户所面临的业务问题为出发点进行分 析和各种转换，最终产生一个能够在用户环境下解决用户业务问题的系统方案，并将其文档化为 明确的规格说明。
3.2需求工程活动
3.2.1需求获取
需求获取是从人、文档或环境中获取需求的过程。获取过程并不是简单地将定义良好的需 求从人、文档或环境中直接转移到获取的结果文档上，需求工程师必须要利用各种方法和技术来 “发现”需求。在需求获取中，需求工程师通常需要执行的任务包括以下几方面：1、收集背景资料。获取的目的是发现用户的问题，并经过需求分析步骤转化为用户的需求。2、获取问题与目标，定义项目前景与范围。需求获取中面对的信息内容非常广泛，因此，要保证获取的有效性，一方面要求不能在无关 的内容上花费太大的代价，另一方面也要不遗漏应该获取的重要内容。因此在开展详细信息的 获取工作之前，应先根据业务需求确定项目的获取范围，然后在范围界限的指导下保证获取活动 的正确和顺利进行。在项目开发后期发生需求变更时，还可以依据清晰的项目范围定义来排除 不必要的变化请求。3、识别涉众，选择信息的来源。在大多数系统开发中，用户是需求的主要来源。一个复杂的系统往往拥有很多用户，因此在 执行获取时要想覆盖所有的用户不仅费时费力，而且是困难的，也是不必要的。一个可行的方案 是通过少数的用户来代表全体用户表达看法。但是系统的不同用户往往在很多方面存在差异， 如使用的产品功能、具有的计算机技能和使用产品的频率等。这些具有不同特性的用户对系统 的需求往往也是不一样的，因此要想让选取的少数代表完整地表达用户的声音，就需要将用户分 成不同的类型，然后在理解每种类型用户特征的情况下为其选择合适的用户代表。这个过程称 为涉众分析。表单、报表、备忘录等硬数据是需求获取信息的另一个重要来源。在用户的工作过程中往往 会产生大量的硬数据，它们以清晰、条理和准确的方式描述了实际业务的相关信息，因此是一种 理想的信息来源。4、选择获取方法，执行获取，获取功能与非功能需求。需求获取的主要目的在于获取用户需求，了解用户在完成任务时遇到的问题与期望。需求获取的方法和技巧有很多，常用的方法有面谈、调査表、观察和原型等。它们都有自己 的优缺点和适用情况，没有哪种方法可以有效应用于各种场合，因此需求工程师需要根据信息的 来源与类型、获取的成本和时间等各种因素选择合适的获取方法，执行获取活动。5、记录获取结果。需求获取阶段产生的主要成果有业务需求、项目前景和范围、用户需求以及问题域特性。它们都需要被及时记录下来。
3.2.2需求分析
需求分析的主要工作是通过建模来整合各种信息，以使人们更好地理解问题。同时，需求分 析工作还会为问题定义一个需求集合，这个集合能够为问题界定一个有效的解决方案。需求分 析还需要检査需求中存在的错误、遗漏和不一致等各种缺陷，并加以修正。在需求分析阶段，需求工程师主要的任务包括以下几方面。1、背景分析。系统是作为用户业务问题的解决方案得以被开发的，但仅靠系统本身无法帮助用户达成目 标，它必须和部署的环境形成互动才能解决用户的问题。2、问题分析、目标分析、业务分析，确定系统边界。在获取系统的问题、目标、前景、范围之后，要使用问题分析、目标分析、业务分析等分析方法 与技术对它们进行处理，并基于这些处理明确其解决方案，定义系统的边界。3、软件需求建模。建模是为展现和解释信息而进行的抽象描述活动。模型由一些基本元素和元素之间的关系 组成，它含有丰富的语义。和文本化的自然语言相比，模型能够在有限的空间内表述更加严谨、 准确和高密度的信息。4、细化需求。用户需求往往具有模糊、歧义等诸多不利的特征，这使得它们很难被加以评估和验证。所以 很有必要在系统模型的帮助下发现更多的细节，并依此将用户需求转化为一些具有良好粒度和 特性的细节需求，即系统级需求。5、确定优先级。用户对系统往往有许多需求，而且这些需求并不是处于同等重要的地位，因此需求工程师需 要根据其重要程度为需求设定优先级。6、需求协商。在分析中有时会发生不同用户间的需求冲突，这种情况下用户各自的需求都是合理的，但却 不可能在系统中同时被加以实现。
3.2.3需求规格说明
获取的需求需要被编写成文档。业务需求被写入项目前景和范围文档，用户需求被写入用 户需求文档（或用例文档），系统级需求被写入需求规格说明。1、定制文档模板。2、编写文档。
3.2.4需求验证
需求验证阶段的主要任务包括以下两方面。1、执行验证。2、问题修正。
3.2.5需求管理
在需求开发活动之后，设计、测试、实现等后续的软件系统开发活动都需要围绕需求开展工 作“需求的影响力贯穿于整个软件的产品生命周期，而不是单纯的需求开发阶段。所以，在需求 开发结束之后，还需要有一种力量保证需求作用的持续、稳定和有效发挥，需求管理就是这样的 一个管理活动。需求管理阶段的主要任务包括以下几方面：1、建立和维护需求基线集。2、建立需求跟踪信息。3、进行变更控制。
3.3需求开发过程是迭代和并发的
从需求工程各项活动的内容来看，需求开发活动似乎可以遵循“需求获取-> 需求分析一需求 规格说明T需求验证”的路线顺序执行，并成功地产生有效的成果文档。但正如软件开发过程的 瀑布模型一样，实践者们很快就发现这个线性顺序的过程可以用于解释需求开发中的活动内容， 却无法用于组织成功的需求开发。
3.4实践方法的应用
通过分析需求工程过程可以了解需求工程活动粗略的组织形式和高层视图，但是要进行一 些具体的工作还需要更多的活动细节。这些活动细节是通过应用实践方法来实现的。
3.4.1细节知识的实践性
在任何一个知识领域中，人们都需要在进行相当的探索之后才能为其建立学科化和系统化 的知识体系。这个探索的过程通常很漫长，很多自然科学领域的知识体系都是人们在进行了数 百或上千年的探索之后才逐渐形成的。
3.4.2重要的实践方法
经过长期的实践，人们在需求工程领域发现和创造了很多用于处理这些需求工程细节的方 法和经验，其中一些取得了显著的成功，被人们所广泛接受。因此，需求工程师的一项重要工作 就是理解业界好的实践，并将它们成功地应用到组织的需求工程过程当中去。
3.5需求开发过程实例。
3.6需求开发过程与软件工程过程的相互影响
“需求的好坏对后续软件开发有着极其重要的影响”这一观念已经是开发者的共识了，近些 年的实践研究进一步发现：不仅仅是最终制品一需求，整个需求开发过程都会对其后续的软件 开发过程产生重要影响。需求开发过程之所以对后续软件开发过程有重要影响，并不仅仅是因为它的结果制 品——需求一是后续开发过程的工作基础，更要认识到需求开发过程中还会产生很多正 性信息（如前景与范围定义、涉众描述、分析模型、需求特征描述等）。如果单纯从产生软件 需求规格这个任务来看，这些正性信息都是不必要的，但它们对后续软件开发过程的影响 则是明显的。也就是说，为了让整个软件开发团队的工作能够更加顺利，需求工程师需要 完成很多看上去似乎不属于其本职工作的任务，这就是“团队”的含义。

三、总结
自从学习了软件工程这门课程之后，我对软件及其开发有了更加浓厚的兴趣，同时我也认识到软件工程在软件开发中的重要性。目前国内软件在开发中还没有对软件开发的过程进行明确规定，文档不完整，也不规范，软件项目的成功往往归功于软件开发组的一些杰出个人或小组的努力。这种依赖于个别人员上的成功并不能为全组织的软件生产率和质量的提高奠定有效的基础，只有通过建立全过程的改善，采用严格的软件工程方法和管理，并且坚持不懈地付诸实践，才能取得全组织的软件过程能力的不断提高，使软件开发更规范合理。软件工程理论认为，在软件生命周期中，需求分析（Requirements Analysis)是最重要的一个阶段。软件需求分析的质量对软件开发的影响是深远的、全局性的，高质量需求对软件开发往往起到事半功倍的效果，所谓“磨刀不误砍柴功”。在后续阶段改正需求分析阶段产生的错误将付出高昂的代价。而对于软件需求分析，简单的来说就是要决定“做什么，不做什么，达到用户所期望的效果”，就好比我们自己平常做一件事之前，都会有做好计划，软件开发亦不例外。用软件工程的定义来讲，它就是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。