需求工程 | 格物修齐

理解问题的需求是软件工程师面对的最困难的任务之一：

客户可能不知道自己需要什么；
客户说的可能不是他想要的；
最终用户可能对将给他们带来实际收益的特性和功能没有清楚的认识；
即使客户和最终用户清楚地指导他们的要求，这些要求也会在项目的实施过程中改变。

对于需求理解的误区，开发人员可能认为：

在编写软件的过程中事情会变得清晰；
只有在检验了软件的早期版本后，项目利益相关者才能更好地理解要求；
事情变化太快，以至于理解需求细节是在浪费时间；
最终要做的是开发一个可运行的程序，其他都是次要的。

上面这些论点包含了部分真实情况，但是其中的每个论点都存在一些小问题，汇集在一起就可能导致软件项目失败。

需求工程(Requirement Engineering, RE) 是指致力于不断理解需求的大量任务和技术。从软件过程的角度来看，需求工程是一个软件工程动作，开始于沟通并持续到建模活动。需求为设计和构建奠定了坚实的基础。

需求工程包括七项任务：起始、获取、细化、协商、规格说明、确认和管理，这些任务有时候没有明确的界限。

1 起始 #

如何开始一个软件项目？通常来说，大多数项目都是在确定了商业要求或是发现了潜在的新市场、新服务才开始的。

在项目起始阶段，要建立基本的理解，包括存在的问题、谁需要解决方案、期望的解决方案的性质。在完成一项期间，需要在所有利益相关者与软件团队之间建立沟通，以便开始有效的协作。

在理想情况下，利益相关者和软件工程师在同一个小组中工作。在这种情况下，需求工程就是和组里熟悉的同事进行有意义的交谈。但实际情况往往不是这样。客户或最终用户可能位于不同的城市或国家，对于想要什么可能仅有模糊的想法，对于将要构建的系统可能存在有冲突的意见，他们的技术知识可能很有限，而且只有有限的时间与需求工程师沟通。这种情况都是不希望遇到但又十分常见的，软件开发团队经常不得不在这种情况的限制下工作。

下面是启动需求工程必需的步骤，以便理解软件需求，使得项目自始至终沿着成功解决方案的方向推进：

确认利益相关者
识别多重观点
协作
首次提问
非功能需求
可追溯性

1.1 确认利益相关者 #

Sommerville 和 Sawyer 把利益相关者定义为“直接或间接从正在开发的系统中获益的人”。可以确定如下几个容易理解的利益相关者：

业务运行管理人员
产品管理人员
市场销售人员
内部和外部客户
最终用户
顾问
产品工程师
软件工程师
支持和维护工程师

每个利益相关者对系统都有不同的考虑，当系统成功开发后能获得的利益也不相同，同样，当系统开发失败时面临的风险也是不同的。

在开始阶段，需求工程师应该创建一个人员列表，列出那些有助于获取需求的人。最初的人员列表将随着接触的利益相关者人数的增多而增加，因为每个利益相关者都将被询问“你认为我还应该和谁交谈”。

1.2 识别多重观点 #

因为存在很多不同的利益相关者，所以系统需求调研也将从不同的视角展开。例如：

市场销售部门关心能激发潜在市场、有助于新系统销售的功能和特性；
业务经理关注应该在预算内实现的产品特性，并且这些产品特性应该满足已规定的市场限制；
最终用户希望系统的功能是他们所熟悉的并且易于学习和使用；
软件工程师可能关注非技术背景的利益相关者看不到的软件基础设施，使其能够支持更多的适于销售的功能和特性；
支持工程师可能关注软件的可维护性。

这些参与者(以及其他人) 中的每一个人都将为需求工程贡献信息。当从多个角度收集信息时，所形成的需求可能存在不一致性或相互矛盾。需求工程师的工作就是把所有利益相关者提供的信息 (包括不一致或矛盾的需求)分类，分类的方法应该便于决策制定者为系统选择一个内部一致的需求集合。

为使软件满足用户而获取需求的过程存在很多困难：

项目目标不清晰
利益相关者的优先级不同
人们还没说出的假设
相关利益者对含义的解释不同，很难用一种方式对陈述的需求进行验证。

有效需求工程的目标是消除或尽量减少这些问题。

1.3 协作 #

假设一个项目中有5个利益相关者，那么对一套需求就会有五种(或更多)正确观点。

客户(和其他利益相关者)之间应该团结协作(避免内讧)，并和软件工程人员团结协作，这样才能成功实现期望的系统。但是如何实现协作？

需求工程师的工作是标识公共区域(即所有利益相关者都同意的需求)和矛盾区域(或不一致区域，即某个利益相关者提出的需求和其他利益相关者都同意的需求)。当然解决矛盾区域更有挑战性。

协作并不意味着必须由委员会定义需求。在很多情况下，利益相关者通过提供他们各自关于需求的观点来协作，而一个有力的“项目领导者”(例如业务经理或高级技术员)要对删减哪些需求做出最终决定。

1.3.1 方法：使用“计划扑克” #

使用基于“优先点”的“投票”方案：

解决相互冲突的需求
更好地理解所有需求的相对重要性

具体规则：

所有的利益相关者都会分配到一定数量到优先点，这些优先点可以适用于很多需求；
在需求列表上，每个利益相关者通过给每个需求分配一个或多个优先点来表明(从他的个人观点)该需求的相对重要性；
一旦某个利益相关者的优先点用完，他就不能再对需求采取进一步操作；
所有利益相关者在每项需求上的优先点总数显示啦该需求的综合重要性。

1.4 首次提问 #

在项目开始时的提问应该是“与环境无关的”：

第一组与环境无关的问题集中于客户和其他利益相关者以及整体目标与收益。这些问题有助于识别所有对构建软件感兴趣的利益相关者；此外，这些问题还确认了某个成功实现的可度量收益以及定制软件开发的可选方案。
- 谁是这项工作的最初请求者？(客户是谁？)
- 谁将使用该解决方案？ (用户是谁？)
- 成功的解决方案将带来什么样的经济收益？(价值有多少？)
- 对于这个解决方案，还需要其他资源吗？
第二组问题有助于软件开发者更好地理解问题，并允许客户表达其对解决方案的看法。
- 如何描述由某成功的解决方案产生的“良好”输出的特征？
- 该解决方案强调解决什么问题？
- 能向我们展示(或描述)解决方案使用的商业环境吗？
- 是否存在将影响解决方案的特殊性能问题或约束？
第三组问题关注沟通活动本身的效率。
- 你是回答这些问题的合适人选吗？你的回答是“正式的”吗？
- 我的提问和你想解决的问题相关吗？
- 我的问题是否太多了？
- 还有其他人员可以提供更多的信息吗？
- 还有我应该问的其他问题吗？

这些问题(和其他问题)有助于“破冰”，并有助于交流的开始，而且这样的交流对成功获取需求至关重要。但是，会议形式的问答(Q&A)并非是一定会成功的好方法。事实上，Q&A会议应该仅用于首次接触，接下来应该用问题求解、协商和规格说明等需求获取方式来代替Q&A会议。

1.5 非功能需求 #

可以将非功能性需求(Nonfunctional Requirement, NFR) 描述成质量属性、性能属性、安全属性或一个系统中的常规限制。如果没有必要的非功能属性，那么软件将无法使用。

尽可能定义一个两阶段方法，以帮助软件团队和利益相关者识别非功能需求：

在第一阶段为系统建立一套软件工程指南，其中包括最佳实践指南，还表述了体系结构风格和设计模式的应用。然后开发一套 NFR (例如可用性、可测试性、安全性或可维护性)的列表。在这个简单的表格中，列标签表示 NFR，行标签标识软件工程指南。关系矩阵把每条指南与其他指南对别，帮助团队评估每对指南是否完备、重叠、冲突或独立。
在第二阶段，团队根据一套决策规则(用来决定实施哪些指南、放弃哪些指南) 划分出同类的非功能需求，并为其建立优先级。

1.6 可追溯性 #

可追溯性是软件工程用语，指在软件工程工作产品间记录的文档化链接(例如需求和测试用例)，需求工程师用可追溯矩阵表示需求和其他软件工程产品间的相互关系。用需求名称标识可追溯矩阵的行，用软件工程工作产品的名称标识可追溯矩阵的列(例如设计元素或测试用例)。矩阵的单元格表示两者之间是否存在关联。

可追溯矩阵支持各种工程开发活动。无论采用哪个过程模型，它都能为开发者提供项目从一个阶段到另一个阶段的连续性。可追溯矩阵通常用于确保工程中的工作产品考虑了所有需求。

2 获取需求 #

询问客户、用户和其他人以下问题：

系统或产品的目标是什么？
想要实现什么？
系统和产品如何满足业务的要求？
最终系统或产品如何用于日常工作？

获取过程中最重要的是建立业务目标，这是一个系统或产品必须达到的长期目的。目标可能涉及功能或非功能性(例如可靠性、安全性、可用性等)问题。

目标应该精确定义，并为需求的细化、验证与确认、冲突管理、协商、解释和发展提供基础。目标通常是向利益相关者解释需求的好方法，一旦建立了目标：

就可以处理利益相关者的冲突和矛盾；
就能为开发过程中的每项任务建立优先级并且能为潜在的体系结构(架构)找到合理的设计依据(需要满足利益相关者的目标)。

需求获取将问题求解、细化、协商和规格说明等元素结合在一起。为了鼓励合作，一个包括利益相关者和开发人员的团队共同完成如下任务：确认问题，为解决方案的相关元素提供建议，商讨不同的方法并描述初步的需求解决方案。

敏捷性是需求工程的一个重要方面。需求获取的目的是将利益相关者的想法及时、顺畅地传递给软件团队。在软件产品开发迭代过程中，很可能不断出现新的需求。

2.1 协作收集需求 #

需求收集有很多方法，各种方法适用的场景略有不同，但都是基于下面这些基本原则做了某些改动：

实际的或虚拟的会议由软件工程师和其他利益相关者共同举办和参与。
制定筹备和参与会议的规则。
建议拟定一个会议议程，这个议程既要足够正式，使其涵盖所有的会议要点，但也不能太正式，以鼓励自由交流想法。
由一个“主持人”(可以是客户、开发人员或其他人)掌控会议。
采用“方案论证手段”(可以是工作室、活动挂图、不干胶贴纸、电子公告牌、聊天室或虚拟论坛)。

协作收集需求的目标是识别问题，提出解决方案的相关元素，协商不同方法以及确定一套解决需求问题的初步方案。

收集需求的步骤：

预约会议
- 在需求的起始阶段写下 1～2 页的“产品要求”，
- 选择会议地点、时间和日期，选派主持人，邀请软件团队和其他利益相关者参加会议。
- 在会议日期之前，给所有参与者分发产品需求。
  - 如果系统或产品将为许多用户服务，可以确定的是，需求是从其中有代表性的用户那里得到的；
  - 如果一个用户定义了所有需求，那么接受风险会很高(也就是说，其他利益相关者可能不会接受这个产品)。
准备会议内容。在召开会议评审产品需求的前几天：
- 要求每个与会者列出系统周围环境的对象、由系统产生的其他对象以及系统用来完成功能的对象；
- 此外，要求每个与会者给出服务器操作列表或与对象交互的服务(过程或功能)列表；
- 最后，还要开发约束列表(如成本、规模、业务规则)和性能标准(如速度、精确度安全性)
- 应告诉与会者，这些列表不要求完备无缺，但要反映每个人对系统的理解。
组织会议评审
- 将上面准备的列表用一张大纸钉在房间的墙上或用便签纸贴在墙上或手写在墙板上；
  - 这些列表可能已经发布在一个小组论坛或内部网站上，或者在会议之前发布在一个社交网络环境中供审查；
  - 理想情况下，应该能够分别操作每个列表项，以便于合并列表、删除项以及加入新项。
  - 利益相关者为列表中的条目编写最小规格说明(mini-specification)，或者生成包括对象或服务的用户用例，以对列表描述的对象做更多的解释避免因信息过少导致理解不一致。
  - 编写小规格说明可能会发现新的对象、服务、约束或性能需求，可以将这些新发现加入原始列表中。
- 当某一专题的各个列表被提出后，小组将生成一个组合列表。该组合列表将删除冗余项，并加入在讨论过程中出现的一些新想法，但是不删除任何内容。
- 在所有专题的组合列表都生成后，由主持人组织讨论。
  - 组合列表可能会缩短、加长或重新措词，以求更恰当地反映即将开发的产品或系统，其目标是为所开发系统的对象、服务、约束和性能提供一个意见一致的列表。
- 在所有的讨论过程中，团队可能会提出某些在会议中不能解决的问题，应将这些问题列表保留起来以便这些意见在以后的工作中发挥作用。

2.2 梳理使用场景 #

收集需求时，系统功能和特性的整体愿景开始具体化。但是在软件团队弄清楚不同类型的最终用户如何使用这些功能和特性之前，很难转移到更技术化的软件工程活动中。为实现这一点，开发人员和用户可以创建一系列场景 - 场景可以识别将要构建系统的使用线索。

场景通常称为用例，它描述了人们将如何使用某一系统。

2.3 获取工作产品 #

根据将要构建的系统或产品规模的不同，需求获取后产生的工作产品也不同。对于大多数系统而言，工作产品包括：

要求和可行性说明
系统或产品范围的界限说明
参与需求获取的客户、用户和其他利益相关者的名单
系统技术环境的说明
需求列表(最好按照功能加以组织)以及每个需求使用领域的限制
一系列使用场景，有助于深入了解系统或产品在不同运行环境下的使用
任何能够更好地定义需求的原型

所有参与需求获取的人员需要评审以上每一个工作产品。

3 细化 #

细化任务的核心是开发一个精确的需求模型，用以说明软件的功能、特征和信息的各个方面。细化是在获取过程中由一系列用户场景建模和求精任务驱动的。这些场景描述了如何让最终用户和其他参与者与系统进行交互。解析每个用户场景以便提取分析类-最终用户可见的业务域实体。应该定义每个分析类的属性，确定每个类需要的服务，确定类之间的关联和协作关系。

细化固然是一件好事，但是需要知道什么时候停止细化。细化的关键在于为如何设计建立牢固的基础，一旦能够清楚描述这个问题，就可以停止细化。不要迷恋不必要的细节。

3.1 开发用例 #

用例讲述了有固定风格的故事：最终用户(扮演多种可能角色中的一个)如何在特定环境下与系统交互。这个故事可以是叙述性的文本(用户故事)、任务或交互的概要、基于模版的说明或图形表示。不管形式如何，用例都是从最终用户的角度描述了软件或系统。

撰写用例的第一步是确定故事中包含的"参与者"。
- 参与者是在将要说明的功能和行为环境内使用系统或产品的各类人员(或设备)。
- 参与者代表了系统运行时人(或设备)所扮演的角色，更为正式的定义是：参与者是任何与系统或产品通信的事物，且对系统本身而言参与者是外部的。
- 在使用系统时，每个参与者都有一个或多个目标。
- 参与者和最终用户并非一回事。典型的用户可能在使用系统时扮演了不同的角色，而参与者表示了一类外部实体(经常时人员，但并不总是如此)，在用例中他们仅扮演一种角色。
- 需求获取是一个逐步演化的活动，在第一次迭代中并不能确认所有的参与者。
- 在第一次迭代中有可能识别主要的参与者，对系统有了更多了解之后，才能识别出次要的参与者。
- 次要参与者为系统提供支持，以便主要参与者能够完成他们的工作。
一旦确认了参与者，就可以开发用例了。通过用例可以回答以下问题：
- 主要参与者和次要参与者分别是谁？
- 参与者的目标是什么？
- 故事开始前有什么前提条件？
- 参与者完成的主要工作或功能是什么？
- 按照故事所描述的还需要考虑什么异常？
- 参与者的交互中可能有什么变化？
- 参与者将获得、产生或改变哪些系统信息？
- 参与者必须通知系统外部环境的改变吗？
- 参与者希望从系统获取什么信息？
- 参与者希望得知意料之外的变更吗？

3.2 构建分析模型 #

分析模型的作用是为基于计算机的系统提供必要的信息、功能和行为域的说明。随着软件工程师更多地了解将要实现的系统以及其他相关利益者更多地了解他们到底需要什么，模型应能够动态变更。因此分析模型是任意时刻的需求快照，我们对这种变更应有思想准备。

随着分析模型的演化，某些元素将变得相对稳定，为后续设计任务提供稳固的基础。但是，有些模型元素可能不是稳定的，这表明利益相关者仍然没有完全理解系统的需求。如果发现在项目设计和构建时没有使用分析模型的元素，那么这些元素不应该被创建，并且不应该随着当前项目需求的变化而得到维护。

有很多不同的方法可用来考察基于计算机的系统需求：

有些软件人员坚持最好选择一个表达模式(如用例)并排斥其他的模式；
有些专业人士则相信使用许多不同的表达模式来描述分析模型是值得的，不同的表达模式会促使软件团队从不同的角度考虑需求 - 只用一种方法更有可能造成需求遗漏、不一致性和歧义性；
最好的办法是让利益相关者都参与进来，让每个人都创建用于描述软件的用例图

有一些普遍的元素对大多数分析模型来说是通用的，这些分析模型的元素如下：

基于场景的元素：对于需求模型来说，基于场景的元素永远是模型中最先被开发的部分，这些元素能够从用户的观点去描述系统。同样，它们也作为创建其他建模元素时的输入。最好的办法是让利益相关者都参与进来，让他们每个人都写出用于描述软件的用例图。
基于类的元素：每个使用场景都意味着当一个参与者和系统交互时所操作的一组对象。这些对象被分成类 - 具有相似属性和共同行为的事物集合。
- UML类图是一种表现方式。
行为元素：基于计算机的系统行为能够对所选择的设计和所采用的实现方法产生深远的影响。因此，需求分析模型必须提供描述行为的建模。
- 状态图是一种表现系统行为的方法，改方法描绘系统状态以及导致系统改表状态的事件；
- 状态是任何可以观察到的行为模式；
- 状态图还指明了在某个事件发生后采取什么动作(例如过程激活)；
- 外部刺激(事件)会导致状态间的转换。

任何有一些软件项目需求工程经验的人都会注意到，在特定的应用领域内，某些问题会在所有项目中重复发生。 分析模式在特定应用领域内提供一些解决方案(如类、功能、行为)，在为许多应用项目建模时可以重复使用他们。通过引用模式名称可以把分析模式整合到分析模型中，同时，这些分析模式还将存储在仓库中，以便需求工程师能够通过搜索工具发现并应用它们。TODO：分析模式的链接

4 协商 #

在一个理想的需求工程情境中，需求工程任务(起始、获取和细化)能确保得到足够详细的客户需求，以开展后续的软件工程活动。遗憾的是，这几乎不可能发生。

业务资源有限，而客户和用户却提出了过高的要求，这是常有的事。另一个相当场景的现象是，不同客户或用户提出了相互冲突的需求，并坚持“我们的特殊要求是至关重要的”。

这些冲突都必须通过协商来解决。应该让客户、用户和其他利益相关者对各自的需求排序，然后按优先级讨论冲突。要让利益相关者以成本和产品投放市场的时间为背景，权衡功能、性能和其他的产品或系统特性。有效的协商不存在赢家也不存在输家。结果应该是双赢的，因为双方都可以接受的“交易”得到了巩固。应使用迭代的方法给需求排序，评估每项需求的成本和风险，处理内部冲突，通过这种方式来删除、组合或修改需求，以便参与各方均能达到一定的满意度。

“协商”过程的目的是保证所开发的项目计划在满足利益相关者要求的同时反映软件团队所处真实世界的限制(如时间、人员、预算)。 最好的协商是取得“双赢”的结果：

利益相关者的“赢”在于获得能满足客户大多数需要的系统或产品；
而作为软件团队一员，“赢”在于按照实际情况、在可实现的预算和时间期限内完成工作。

4.1 方法：“握手"的双向沟通 #

Fricker[Fri10] 建议不再采用传统的需求规格说明书方式，而是采用“握手”的双向沟通过程。握手可能是一种实现“双赢”的方式。在握手的过程中：

软件团队提出需求解决方案、描述它们的影响、与客户代表沟通他们的意图；
客户代表审核提议的解决方案，关注丢失的特性并需求新需求的清晰化；
如果客户接受提议的解决方案，则说明需求是足够好的。

从“握手”的双向沟通方法来看，核心思路就是软件团队以最终方案向客户(利益相关者)确认，客户(接受已满足的)修订最终方案中不满足的内容，直致达成一致。

握手方法有助于多样需求的识别、分析和多样选择，并可促进以双赢为目标的协商。

5 需求规格说明 #

在基于计算机的系统(和软件)环境下，术语规格说明对不同的人有不同的含义。规格说明可以是一份写好的文档、一套图形化的模型、一个形式化的数学模型、一组使用场景、一个原型或上述各项的任意组合。

有人建议应该开发一个“标准模版”并将之用于规格说明，认为这样将促进以一致的、更易于理解的方式来表示需求。然而，在开发规则说明时，保持灵活性有时时必要的。规格说明的形式和格式随着要构造的软件的大小和复杂性而变化。对大型系统而言，文档最好采用自然语言描述和图形化模型来编写。

6 需求确认 #

在确认阶段将对需求工程的工作产品进行质量评估。这个阶段最关心的是各个产品的一致性。可以使用分析模型来确保需求产品的一致性。需求确认要检查规格说明，以保证无歧义地说明了所有的系统需求；已检测出不一致性、疏忽和错误，并予以纠正；工作产品符合为过程、项目和产品建立的标准。

正式的技术评审是主要的需求确认机制。确认需求的评审小组包括软件工程师、客户、用户和其他利益相关者，他们检查系统的规格说明，查找内容或解释上的错误，以及需要进一步澄清的地方、丢失的信息、不一致性(这是构建大型产品或系统时遇到的主要问题)、冲突的需求或不可实现(不能达到的)需求。

6.1 需求模型评审 #

当需求模型的每个元素都创建完成之后，需要检查一致性、是否遗漏以及是否有歧义。这一点也适用于以用户故事或者测试用例表达需求的敏捷过程模型。模型所表现的需求由利益相关者划分优先级并组合成一个整体，该需求整体将以软件增量形式逐步实现。

需求模型的评审将解决如下问题：

每项需求都与系统或产品的整体目标一致吗？
所有需求都已经在相应的抽象层上说明了吗？换句话说，是否有一些需求是在技术细节过多的层次上提出的，并不适合当前的阶段？
需求时真正必需的，还是另外加上去的？有可能不是系统目标必需的特性吗？
每项需求都有界定且无歧义吗？
每项需求都有归属吗？换句话说，是否每项需求都标记了来源(通常是明确的个人)？
是否有一些需求和其他需求相冲突？
在系统或产品所处的技术环境下，每个需求都能够实现吗？
一旦实现后，每个需求是可测试的吗？
需求模型恰当地反映了将要构建系统的信息、功能和行为吗？
需求模型是否已经使用合适的方式“分割”，能够逐步揭示详细的系统信息？
已经使用需求模式简化需求模型了吗？已经恰当地确认了所有的模式吗？所有模式都与客户的需求一致吗？

应当提出以上问题和其他一些问题，并回答问题，以确保需求模型能精确地反映利益相关者的需求并为设计奠定坚实的基础。

7 需求管理 #

对于基于计算机的系统，其需求会变更，而且变更的要求贯穿系统的整个生命周期。需求管理者是帮助项目组在项目进程中标识、控制和跟踪需求以及需求变更的一组活动。

7.1 需求监控 #

当今常见的软件项目是增量开发项目。这意味着需要扩展用例，针对每次新的软件增量开发新的测试用例，并在整个项目过程中进行源代码的不断集成。在实现增量开发时，需求监控显得尤为有益。

需求监控包括5项任务：

分布式调试，用于发现错误并找到出错的原因；
运行验证，确认软件与规格说明是否匹配；
运行确认，评估逐步扩展的软件是否满足用户目标；
商业活动监控，评估系统是否满足商业目标；
演化与协同设计，为系统演化过程中的利益相关者提供信息。

增量开发意味着增量确认的要求。需求监控支持持续确认，通过分析用户目标模型使之符合所使用的系统。例如，监控系统可能会持续评估用户满意度，并使用反馈信息来指导软件的逐步改进。

8 总结 #

需求工程的任务是为设计和构建活动建立一个可靠且坚固的基础。

需求工程发生在为通用软件过程定义的沟通活动和建模活动中。

软件团队成员和产品的利益相关者要完成7个不同的需求工程任务：起始、获取、细化、协商、规格说明、确认和管理。

在项目起始阶段，利益相关者建立基本的问题需求，定义重要的项目约束并陈述主要的特性和功能，必须让系统表写出这些特性和功能以满足其目标。
该信息在获取阶段得到提炼和延伸，在此阶段中利用有主持人的会议、用户场景(用户故事)的开发进行需求收集活动。
细化阶段进一步把需求扩展为分析模型 - 基于场景、基于活动、基于类和行为元素的集合。模型可以参考分析模式 - 在不同应用系统中重复出现的问题或特征。
在确定需求和创建需求分析模型时，软件团队和其他利益相关者协商优先级、可用性和每项需求的相对成本。协商的目标是制定一个现实可行的项目计划。
此外，将按照客户需求确认每项需求和整个需求模型，以确保将要构建的系统对于客户的要求是正确的。

参考资料 #

《软件工程 - 实践者的研究方法》