3.1 理解需求
需求工程在设计和构造之间建立起联系的桥梁，它开始于项目的干系人（如项目经理、客户、最终用户，也包括技术团队），定义业务需求，刻画用户场景，描述功能和特性，识别项目约束条件；有人建议从宽泛的系统定义开始，此时软件只是更大的系统范围中的一个构件。但不管起始点在哪里，需求工程允许由软件团队检查将要进行的软件工作的内容，提交设计和构建的特定要求，完成指导工作顺序的优先级定义，并影响随后设计的信息、功能和行为。
需求工程为以下工作提供了良好的机制：理解客户需要什么、分析要求、评估可行性、协商合理的方案、无歧义地详细说明方案、确认规格说明、管理需求，以及将这些需求转化为可运行系统。
3.1.1 建立根基
大多数项目都是当确定了商业要求或发现了潜在的新市场、新服务时才开始。业务领域的干系人（如业务管理人员、市场人员和产品管理人员）定义业务用例，确定市场的宽度和深度，进行粗略的可行性分析，并确定项目范围的工作说明。
在项目起始阶段中，要建立起基本的理解，包括对问题、谁需要解决方案、所期望解决方案的性质，以及项目用户和开发人员之间达成初步交流合作的效果等。
在项目起始阶段，干系人建立基本的问题需求，定义最重要的项目约束，以及陈述主要的特征和功能，必须让系统表现出这些特征和功能以满足其目标。该信息在导出阶段得到提炼和延伸，在此阶段中利用有主持人的会议和使用场景的开发进行需求收集活动。
在理想情况下，干系人和软件工程师在同一个小组中工作（这是敏捷软件开发方法的主要部分）。这时，需求工程就只是和组里熟悉的同事进行有意义的交谈。但实际情况往往不是这样，客户或最终用户可能位于不同的城市或地区，对于想要什么可能仅有模糊的想法，对于将要构建的系统可能存在有冲突的意见，他们的技术知识可能很有限，可能仅有有限的时间与需求工程师沟通。这些事情虽不希望遇到但又十分常见，开发团队经常被迫在这样的环境限制下工作。
1.确认干系人
所谓“干系人”，可以定义为“直接或间接地从正在开发的系统中获益的人”。例如：业务运行人员、产品管理人员、市场销售人员、内部和外部客户、最终用户、顾问、产品工程师、软件工程师、支持和维护工程师，以及其他人员。每个干系人对系统都有不同的考虑，当系统成功开发后所能获得的利益也不相同，同样，当系统开发失败时所面临的风险也是不同的。
在开始阶段，需求工程师应该创建一个人员列表（干系人名册），列出那些有助于导出需求的人员。最初的人员列表将随着接触的干系人人数增多而变化。
2.识别多重观点
因为存在很多方面的干系人，所以需求调研也将从不同的视角开展。例如，市场销售部门关心能激发潜在市场的功能和特点；业务经理关注应该满足已规定的市场限制；最终用户可能希望系统的功能是他们所熟悉的并且易于学习和使用；软件工程师可能关注那些软件基础设施所能够支持的功能和特点；支持工程师可能关注软件的可维护性。
这些参与者中的每一个人都将为需求工程过程贡献信息。当从多个角度收集信息时，所形成的需求可能存在不一致性或相互矛盾。需求工程师要把所有干系人提供的信息（包括不一致或矛盾的需求）进行分类，以便决策者为系统选择一个内部一致的需求集合。
3.协同合作
客户和其他干系人及软件工程人员团结协作，才能成功实现预定的系统。需求工程师的工作是标识公共区域（即所有干系人都同意的需求）和矛盾区域（即某个干系人提出的需求和其他干系人的需求相矛盾）。显然，后一个分类更有挑战性。
在项目需求导出时的提问应该是“与环境无关的”，所提的问题将有助于识别对构建软件感兴趣的干系人。此外，问题还确认了某个成功实现的可度量收益及定制软件开发的可选方案。
3.1.2 导出需求
询问客户、用户和其他人，系统或产品的目标是什么，想要实现什么，系统和产品如何满足业务的要求，最终系统或产品如何用于日常工作。这些问题看似简单，要实现却很困难，其原因包括以下几个。
●范围问题：系统的边界不清楚，或是客户或用户的说明带有不必要的技术细节，这些细节可能会导致混淆系统的整体目标。
●理解问题：客户或用户并不能完全确定需要什么，他们对其计算环境的能力和限制所知甚少，对问题域没有完整的认识，与系统工程师在沟通上存在问题，忽略了一些“明显的”信息，所确定的需求和其他客户或用户的实际需求相冲突，需求说明有歧义或不可测试。
●易变问题：需求随时间变化。为了帮助解决这些问题，需求工程师必须有组织地开展需求收集活动。
导出需求（又称需求收集）是与问题求解、精化、谈判和规格说明等方面的元素结合在一起的。为了鼓励合作，由干系人和开发人员共同组织的团队将完成如下任务：确认问题，为解决方案的要素提供建议，商讨不同的方法并描述初步的需求解决方案。
1.协同收集需求
不同的场景需要采用不同的协同需求收集方法，各种方法都以下面这些原则为基础。
●会议由软件工程师和其他的干系人共同举办和参与。
●制定筹备和参与会议的规则。
●拟定一个会议议程，这个议程既要足够正式，使其涵盖所有的重点，但也不能太正式，以鼓励思想的自由交流。
●由一个“调解人”（可以是客户、开发人员或其他人）控制会议。
●采用“方案论证手段”（可以是工作表、活动挂图、不干胶贴纸或电子公告牌、聊天室或虚拟论坛）。
收集需求的目的是识别问题，提出解决方案的要素，协商不同的方法，以及在有利于完成目标的氛围中确定一套解决需求问题的初步方案。
2.质量功能部署
质量功能部署（Quality Function Deployment，QFD）是一种将客户要求转化成软件技术需求的质量管理技术，其目的是“最大限度地让客户从软件工程过程中感到满意”。为了达到这个目标，QFD强调理解“什么是对客户有价值的”，然后在整个工程活动中部署实现这些价值。
QFD确认以下3类需求。
1）正常需求：这些需求反映了和客户确定的针对某产品或系统的目标。例如所要求的图形显示类型、特定的系统功能，以及已定义的性能级别。
2）期望需求：这些需求隐含在产品或系统中，并且可能是非常基础的，以至于客户没有显式地说明，但是，缺少这些将导致客户不满。例如人机交互的易用性、整体运行的正确性和可靠性，以及软件安装的简易性。
3）令人兴奋的需求：这些需求反映了客户期望之外的特点，如果实现这些特点，将会使客户非常满意。例如，新移动电话的软件来自标准特性，但关联了一些超出期望的能力（如多重触控技术的触摸屏、可视语音邮箱等）。
通过客户访谈和观察、调查，以及检查历史数据（如问题报告），QFD为需求收集活动获取原始数据，然后把这些数据转换成需求表——称为客户意见表，并由客户和干系人评审。接着，使用各种图表、矩阵和评估方法，抽取期望的需求并尽可能导出令人兴奋的需求。
3.用户场景
收集需求时，系统功能和特性的整体愿景开始具体化。但是，在软件团队弄清楚不同类型的最终用户如何使用这些功能和特性之前，很难转移到更技术化的软件工程活动上。为此，开发人员和用户可以创建一系列的场景，用以识别对将要构建系统的使用线索。场景通常称为用例，它提供了将如何使用系统的描述。
4.导出工作产品
根据将要构建的系统或产品的规模不同，需求导出后产生的工作产品也不同。对于大多数系统而言，工作产品包括以下几个。
●要求和可行性陈述。
●系统或产品范围的界限说明。
●参与需求导出的客户、用户和其他干系人的名单。
●系统技术环境的说明。
●需求列表（按照功能加以组织）及每个需求适用的领域限制。
●一系列使用场景，有助于深入了解系统或产品在不同运行环境下的使用。
●任何能够更好地定义需求的原型。所有参与需求导出的人员需要评审以上的工作产品。
3.1.3 开发用例
在起始和导出阶段获得的信息将进行扩展和提炼，该任务集中于开发一个精确的需求模型，用以说明软件的功能、特征和信息的各个方面。
精化是由一系列的用户场景建模和求精任务驱动的。这些用户场景描述了如何让最终用户和其他参与者与系统进行交互。解析每个用户场景以便提取分析类——最终用户可见的业务域实体。应该定义每个分析类的属性，确定每个类所需要的服务，确定类之间的关联和协作关系，并补充完成各种图形。
本质上，用例讲述了能表达主体场景的故事：最终用户如何在一特定环境下和系统交互。这个故事可以是叙述性的文本、任务或交互的概要、基于模板的说明或图形表示。不管其形式如何，用例从最终用户的角度描述了软件或系统。
撰写用例的第一步是确定故事中所包含的“参与者”，即在将要说明的功能和行为环境内使用系统或产品的各类人员（或设备），代表了系统运行时人（或设备）所扮演的角色。更为正式的定义是：参与者是任何与系统或产品通信的事物，且对系统本身而言参与者是外部的。当使用系统时，每个参与者都有一个或多个目标。
需要注意的是，参与者和最终用户并非一回事。典型的用户可能在使用系统时扮演了多种角色，而参与者作为外部实体（人员），在用例中仅扮演一种角色。例如，考虑一个机床操作员（一个用户），他和生产车间（其中装有许多机器人和数控机床）内的某个控制计算机交互。在仔细考察需求后，控制计算机的软件需要4种交互模式（角色）：编程模式、测试模式、监测模式和故障检查模式。因此，4个参与者可定义为程序员、测试员、监控员和故障检修员。有些情况下，机床操作员可以扮演所有这些角色，而有些情况下，每个参与者的角色可能由不同的人员扮演。
需求导出是一个逐步演化的活动，因此在第一次迭代中有可能识别主要的参与者，但并不能确认所有的参与者。对系统了解更多之后，才能识别出次要的参与者。主要参与者直接且经常使用软件获取所需的系统功能并从系统得到预期收益。次要参与者支持系统，以便主要参与者能够完成他们的工作。
3.1.4 构建需求模型
精化阶段进一步把需求扩展为分析模型——基于场景、类、行为和面向数据流的模型元素的集合。模型可能对分析模式和在不同的应用系统中重复出现分析问题的解决方案加以注解。
分析模型的目的是为基于计算机的系统提供必要的信息、功能和行为域的说明。随着软件工程师更多地了解将要实现的系统，以及其他干系人更多地了解他们到底需要什么，模型将动态地变更。
1.需求模型的元素
有很多方法来考察计算机系统的需求，不同的表达模式将促使软件团队从不同的角度考虑需求。但是，一些普遍的元素对大多数分析模型来说都是通用的。
1）基于场景的元素：使用基于场景的方法可以从用户的视角描述系统。例如，基本的用例及其相应的用例图演化成更精细的基于模板的用例。需求模型基于场景的元素通常是正在开发模型的第一部分。同样，它们也作为创建其他建模元素时的输入。图3-1描绘了一张使用用例引发的需求，并表达了它们的UML活动图，给出了最终基于场景表示的三层详细表达。
图3-1 导出需求的UML活动图
2）基于类的元素：每个使用场景都暗示着当一个参与者和系统交互时所操作的一组对象，这些对象被分成类——具有相似属性和共同行为的事物集合。例如，SafeHome是某个正在研发的家庭安全管理产品，可以用UML类图描绘SafeHome安全功能的传感器Sensor类，如图3-2所示。注意，UML类图列出了传感器的属性（如name、type）和可以用于修改这些属性的操作（如identify、enable等）。除了类图，其他分析建模元素描绘了类之间的协作，以及类之间的关联和交互。
3）行为元素：基于计算机系统的行为能够对所选择的设计和所采用的实现方法产生深远的影响。因此，需求分析模型必须提供描述行为的建模元素。
状态是任何可以观察到的行为模式，而状态图是一种表现系统行为的方法，该方法描绘了系统状态及导致系统状态改变的事件。此外，还指明了在某个特殊事件后采取的动作。
为了更好地说明状态图的使用，考虑将软件嵌入到SafeHome的控制面板，负责读取用户的输入信息。简化的UML状态图如图3-3所示，SafeHome的控制面板如图3-4所示。另外，作为一个整体的系统行为表达也能够基于各个类的行为建模。
图3-2 SafeHome传感器的类图
图3-3 UML状态图表示
图3-4 SafeHome控制面板
4）面向数据流的元素：信息在基于计算机的系统中流动时会被转换，系统接受多种形式的输入，使用函数将其转换，生成多种形式的输出。输入可以是操作人员输入的数字，也可以是网络上传送的信息包或从备份存储器取回的庞大数据文件。转换可能由单一的逻辑比较、复杂的数值算法或专家系统的规则推理方法构成。输出可能是点亮一个发光二极管或生成一份200页的报告。
2.分析模式
分析模式即来自概念性业务模型的模式。有需求工程经验的人会注意到，在特定的应用领域内，某些事情会在不同的项目甚至是不同的应用领域中重复发生。例如用户接口的特点和功能都是共有的。这些分析模式在特定应用领域内提供了一些解决方案（如类、功能和行为），在为许多应用项目建模时可以重复使用。
使用分析模式有两个优点。首先，通过提供可重复使用的分析模型捕获具体问题的主要需求，例如关于优点和约束的说明，从而提高了抽象分析模型的开发速度。其次，通过建议的设计模式和可靠的通用问题解决方案，有利于把分析模型转变到设计模式。
通过参照模式名把分析模式整合到分析模型中，同时存储在数据库中以便需求工程师能通过搜索工具发现并应用。在标准模板中会提供关于分析模式（和其他类型模式）的信息。
3.1.5 协商需求
虽然只给予了有限的业务资源，而客户和用户却提出了过高的要求，或者，不同的客户或用户提出了相互冲突的需求并坚持其重要性，这些都是常有的事。需求工程师必须通过协商过程来调解这些冲突。应该让客户、用户和其他干系人对各自的需求排序，然后按优先级讨论冲突。使用迭代的方法给需求排序，评估每项需求对项目产生的成本和风险，表述内部冲突，删除、组合和（或）修改需求，以便参与各方均能达到一定的满意度。
在确定需求并且创建分析模型时，软件团队和其他项目干系人协商优先级、可用性和每个需求的相对成本。协商的目标是开发一个现实可行的项目计划。此外，将按照客户需求确认每个需求和整个需求模型，以确认将要构建的系统对于客户的要求是正确的。
在一个理想的需求工程情境中，起始、导出和精化工作能确保得到足够详细的客户需求，以开展后续的软件工程步骤。而实际上，在多数情况下要让干系人以成本和产品投放市场的时间为背景，平衡功能、性能和其他的产品或系统特性。其目的是保证所开发的项目计划，在满足干系人要求的同时反映软件团队所处真实世界的限制（如时间、人员和预算）。
最好的协商是争取“双赢”的结果，即干系人“赢”在获得满足客户大多数需要的系统或产品，而软件团队“赢”在按照实际情况、在可实现的预算和时间期限内完成工作。
3.1.6 确认需求
软件需求规格说明（SRS）是在项目商业化之前必须建立的详细描述软件各个方面的文档。当软件由第三方开发时，当缺少规格说明导致严重业务问题时，或是当系统非常复杂或涉及十分重要的业务时，需求规格说明是非常必要的。
在编制规格说明时必须保持其灵活性。对大型系统而言，文档最好采用自然语言描述和图形化模型来编写。而对于技术环节明确的较小产品或系统，使用场景可能就足够了。
下面这一套提纲模板可以为建立完整的需求规格说明书提供指导。
在这一步将对需求工程的工作产品进行质量评估，保证已无歧义地说明了所有的系统需求，已检测出不一致性、疏忽和错误并得到纠正，工作产品符合为过程、项目和产品建立的标准。正式的技术评审是最主要的需求确认机制。确认需求的评审小组包括软件工程师、客户、用户和其他干系人。
基于计算机系统的需求变更要求贯穿于系统的整个生存期。需求管理是用于帮助项目组在项目进展中标识、控制和跟踪需求及需求变更的一组活动。