软件需求
软件需求是指用户对目标软件系统在功能、性能、质量等方面的期望，以及对目标软件系统在运行环境、资源消耗等方面的约束。通常将用户需求分为两大类：
(1) 功能性需求：用户对软件系统能够完成何种功能，以及在某些场景下软件系统能够展现的何种外部可见行为或效果的期望，包括对外部行为效果的业务规则约束。
(2) 非功能性需求：用户对软件质量属性、运行环境、资源约束、外部接口等方面的要求或期望，包括：
(2.1) 性能需求：用户在软件响应速度、结果精度、运行时资源消耗量等方面的要求。
(2.2) 可靠性需求：用户在软件失效的频率、严重程度、易恢复性，以及故障可预测性等方面的要求。
(2.3) 易用性需求：用户在界面的易用性、美观性，以及对面向用户的文档和培训资料等方面的要求。
(2.4) 安全性需求：用户在身份认证、授权控制、私密性等方面的要求。
(2.4) 运行环境约束：用户对软件系统运行环境的要求。
(2.5) 外部接口：用户对待开发软件系统与其他软件系统或硬件设备之间的接口的要求。
(2.6) 可保障性（supportable）需求：用户在软件可配置性、可扩展性、可维护性、可移植性等方面的要求。
需求工程的目标是获取精确化、一致化、完全化的软件需求。精确化是指，需求正确地反映用户的期望和约束，需求的表述无歧义，并且需求可通过客观的手段予以验证；一致化是指，各需求项之间无逻辑冲突；完全化是指，需求的表述无遗漏。
软件需求是后续的软件开发活动（包括设计、实现和测试）的重要依据。如果需求偏离了用户的期望或约束，那么任何优秀的设计和实现都无济于事，软件项目势必归于失败。尽管需求的获取和分析是软件开发过程中最为关键的阶段，尽管学术界和产业界在需求工程领域倾注了大量心力，遗憾的是，需求获取、分析的方法与技术仍不成熟，需求工程师仍须直面诸多不确定因素甚至风险因素。造成此种需求工程困局的主要原因有：
(1) 沟通障碍。用户可能熟悉其业务领域，但对计算机软件所知有限；软件分析师可能对软件技术如数家珍，但对目标软件所处的业务领域的理解仅止于皮毛。二者在知识背景和关注点方面的差异导致交流困难，误解丛生。此外，用户往往认为软件需求获取工作不属于其职责范围，或者由于业务工作繁忙而轻忽软件需求的提取和评审工作，这种由于用户不予配合而导致的虚假需求、残缺需求使需求工程师面临的困境雪上加霜。
(2) 深藏不露。不能奢望用户能够完整地表述其所有需求。在软件系统木已成舟后用户要求添加或更改需求的情形已是屡见不鲜的现象。如何挖掘潜在的、未来有价值的用户需求是需求工程师面临的主要挑战之一。
(3) 各有所好。不同层面、不同岗位的用户对目标软件系统的视角不一样，期望自然也不一样。不同用户、甚至同一用户在不同时间提出的需求可能出现逻辑冲突，如何从大量的需求条目中发现冲突、消解冲突，殊非易事。
(4) 边界含混。某条用户需求是否应当由软件系统来实现，取决于诸多复杂因素，包括人与计算机之间的合理分工、软件项目的成本及时间约束、合同条款等。因此，如何确定目标软件系统的边界，同样是需求工程师必须面临的棘手难题。
(5) 变更频仍。在软件系统交付使用之前，用户往往勿需为其提出的需求变更付出任何代价。因此，无论是在需求的获取、分析阶段，还是后续的软件设计、实现、测试阶段，软件开发人员都必须处理由需求变更导致的一系列难题：影响范围分析、需求质量属性（精确性、一致性、完全性等）的保持、软件配置项更新等。
本章试图系统地阐述需求工程的过程、方法和技术，它们可望部分地解决上述问题，为需求工程师摆脱困局、达成目标提供方法学指导。
1 需求工程的过程模型
对于中、大型软件项目而言，如果不遵循严谨的需求工程过程模型，成功地获取高质量的软件需求是不可想象的。软件需求的确立不可能一蹴而就，必须经历一系列的步骤（或称阶段、子过程），在每个步骤中均须展开一些活动。这些活动的定义、参与活动的角色及其职责、活动之间及子过程之间的衔接方式构成了需求工程过程模型的主要内容。本节依次介绍这种过程模型的要素（活动）、过程模型（活动的组织方法、参与活动的角色及其职责）、过程模型的裁剪方法。
1.1 需求工程中的活动
一般而言，一个完整的需求工程过程包含以下活动：
(1) 策划。确定本次子过程的目标、资源约束条件、计划、参与者各自的承诺、结果认可准则，并确保所有利益相关者（stakeholders）在这些方面达成一致。需求工程中的利益相关者包括需求工程师、项目软件经理、用户、系统工程师、测试工程师，以及项目经理、软件质量保证（SQA）工程师、软件配置管理（SCM）工程师。前五种角色的参与程度较深。这些角色的职责将在§2至§6展开讨论过程模型中的各项活动时再予阐述。对于纯软件项目，没有系统工程师的角色，并且项目软件经理即为项目经理。
(2) 需求获取。按照策划活动中确定的计划获取并理解业务领域中的概念、事实及用户的需求，必要时还要说明将这些用户需求作为待建的目标软件系统的侯选需求的理由。如果本次子过程是某个迭代过程中的一个步骤，该活动可能还包括对需求变更或缺陷报告的理解以及由此导致的需求获取动作。需求获取的结果是对软件需求的描述。UML中的用例机制是支持需求获取活动、描述需求获取结果的适用工具之一。
(3) 需求分析。在需求获取成果的基础上，采用比自然语言更加结构化、更加清晰直观的方式（例如UML交互图、类图、状态图、活动图等）对软件需求建模，以期获得对用户需求的更深入的理解，将软件需求精确化、一致化、完全化，并便于设计人员理解用户需求、设计软件结构、构思问题求解方案。
(4) 需求规范化。基于需求分析的结果给出正式的需求规格说明并对其形成一致的理解。需求模型是需求规格说明中最主要、最关键的内容。除此之外，需求规格说明还可以包括需求来源的描述，例如，如果软件只是整个系统的一部分，那么应说明软件需求条目与系统需求条目之间的追踪关系；对于纯软件项目，也可说明一个软件需求条目出自何种用户、何种业务运作场景或其他来源。必要时，在需求规格说明中还可针对部分需求条目说明其作为正式需求的理由。
(5) 需求验证。对需求规格说明进行评审和必要的修改，确保其满足精确化、一致化、完全化的质量要求。在软件项目的整个需求工程阶段临结束时，需求规格说明作为此活动的结果应该置入软件项目的基线库。
(6) 总结。对本次子过程的活动及结果进行总结、评价，为所有利益相关者提供需求工程过程和中间产品的状态的直观描述，根据策划活动中确定的结果认可准则决定后续行动计划（启动下一需求工程子过程或进入软件设计阶段）。
(7) 需求管理。对需求开发、需求实现和需求变更过程进行监督和控制，以便提高软件需求准确、全面地反映用户期望的程度，确保后续软件开发计划、活动及工作产品与软件需求保持一致，降低甚至消除需求变更对软件质量和开发效率的损害。这里，需求开发是前述(2)～(5)项活动的统称；需求实现包括基于需求的软件设计、构造、测试活动。所以，需求管理是一项跨越多个软件开发阶段的活动。
以上前6项活动按次序构成需求工程中单次子过程的工作流，见图1。需求管理与需求开发活动之间的关系将在“7 需求管理”中论述。
图1 用UML活动图表示的需求工程中单个子过程的工作流
在一次子过程中，如果在进行某个活动的过程中发现了需要立即更正的缺陷或需要澄清的问题，则要对缺陷或问题追根溯源，并导致相关活动的返工。例如，图2表示，在需求验证活动中发现的缺陷来源于需求分析活动并与需求规范化活动有关，因此，这两个活动必须针对该缺陷进行（部分）返工，以彻底消除缺陷。
图2 单次子过程中的缺陷追踪及返工
1.2 迭代式的过程模型
需求工程的过程模型是指需求工程活动的组织方式，包括活动的进入、完成条件，活动的输入、输出，参与活动的角色及其职责，活动之间的衔接方式等。本书推荐迭代式的过程模型，见图3。对于简单的软件项目，迭代进行一次可能就足以获取高质量的软件需求；但对中、大型软件项目，迭代往往需进行多次。
图3 迭代式的需求工程过程模型
针对每次迭代：
(1) 参与者：单次迭代的参与者集合是其中所有活动的参与者集合（§2至§6将阐述）的并集。这些参与者包括前述的需求工程中的利益相关者。
(2) 进入条件：在首次迭代完成后进入后续迭代的条件是，所有参与者对新需求的获取或已有需求的变更的必要性达成共识。
(3) 输入：首次迭代时，输入为有关项目目标、范围的陈述性文档；后续迭代时，输入文档还可以包括缺陷描述、待新增需求项的概略性描述文档，或者需求变更申请书（见“7.3 需求变更管理”）。
(4) 输出：经用户认可的需求规格说明。
(5) 完成条件：用户认可作为输出文档的需求规格说明已符合本次迭代的认可准则，并且所有利益相关者均同意进入下次迭代或终结整个需求工程过程。
针对图3中的每个需求工程活动，还可以进一步用过程模型给出其中的子活动及其组织方式，详见2至6节。
1.3 过程模型的裁剪
在实际的软件项目中，针对1.2节所述的迭代式过程模型可以进行因地制宜的裁剪或具体化。本小节通过三种典型的应用场景说明需求工程过程模型的裁剪和具体化方法。
(1) 应用场景1：对于小型软件项目或软件需求容易确立的项目，迭代仅需进行一次。因此，其需求工程的过程模型可简化为图2所示的形式。例如，针对案例1，采用单次迭代即可完成需求的获取、分析和规范化工作。
(2) 应用场景2：如果一个软件能够分解成多个子系统，那么，针对各子系统的需求工程活动可以并行地在各自的迭代子过程中进行，但此前必须通过至少一个迭代子过程给出整个软件的概略性需求并确定分解结构；此后必须通过至少一个迭代子过程对各部分的需求进行整合并给出完整的软件需求规格说明。因此，此种应用场景下的需求工程过程模型可示意为图4。此类应用场景下的过程模型清楚地表明了图3所示的迭代式过程模型能够很好地支持需求工程参与者并行工作。除此之外，§2至§6还将分别阐述参与需求工程的各种角色在单次迭代中的每个阶段从事各自的子活动时的可并行性。
整体策划 概略需求获取 概略需求分析、子系统划分及集成策略设计 概略需求表述 概略需求验证及系统划分的合理性评审、子系统集成策略评审 总结
子系统1 子系统n
需求整合策划 需求整合分析（冗余消除、冲突消解、完整性分析） 整体需求规范化 整体需求验证 总结
图4 系统分解后针对子系统并行迭代的需求工程过程模型
例如，针对案例2，可以将机票预订管理系统划分为面向客户的机票查询、订票及退票子系统，面向机票预订服务提供商的统计分析子系统。可以安排两轮迭代分别针对这两个子系统进行需求获取，最终整合为机票预订管理系统的需求规格说明。
(3) 应用场景3：在本次迭代的需求验证阶段，如果发现了缺陷，或认为某些需求条目需要新增或变更，可以形成缺陷分析报告或需求变更申请报告，以此为输入启动下次迭代。此种应用场景下的需求工程的过程模型如图5所示。由此可见，在迭代式过程模型中，缺陷更正和需求变更可以很自然地在后续迭代过程中实现。
图5 通过迭代支持缺陷更正和需求变更的需求工程过程模型
2 需求工程策划
策划活动的主要目的是就本次迭代的以下事项在所有利益相关者之间达成共识：
(1) 需要完成哪些事项；
(2) 何人应做何事；
(3) 每项工作应于何时完成；
(4) 以何种标准验收工作结果。
2.1 策划活动的参与者
策划活动的参与者包括本次迭代的所有其他活动的参与者，即：需求工程师、项目软件经理、用户、系统工程师、测试工程师，以及项目经理、软件质量保证（SQA）工程师、软件配置管理（SCM）工程师。策划活动的主要完成者一般是需求工程师及项目软件经理或其授权代理人，他们在策划过程中必须与用户反复沟通协商。其他参与者的主要职责是评审策划活动的中间或最终输出制品，并对与其相关的任务、进度约定做出承诺。
2.2 策划活动的进入准则
策划活动的进入准则是：项目软件经理确认有必要启动新一轮迭代来获取新的需求或调整原有需求。
2.3 策划活动的输入制品
策划活动的输入制品包括有关项目目标、范围及价值的概述性文档。对于非首次迭代，输入制品还应包括缺陷描述、待新增需求的概略性描述文档或需求变更申请书（见“7.3 需求变更管理”），以及前次迭代获得的需求规格说明书、前次迭代中需求验证活动产生的需求验证报告（见“6 需求验证”）。
2.4 策划活动的步骤
策划活动的大致步骤如下：
(1) 标识本次迭代中的所有利益相关者。这些利益相关者不仅包括活动的参与者，也包括为活动提供帮助的人员或组织。对于利益相关组织，必须确定其联系人。对于抽象的利益相关者，必须确定其代表。对于利益相关人或利益相关组织的联系人，应确立有效的联系管道，例如电话号码、电子邮件地址等。例如，针对案例1，利益相关者中的用户包括教务管理人员、学生、任课教师的代表至少各一名。
(2) 确定本次迭代的目标和验收准则。软件质量保证工程师应参与此活动。例如，针对案例1，本次迭代的目标确定为：获取完整的用户需求并完成《课程注册管理系统软件需求规格说明书》，验收准则是：所有用户代表均确认并签署了《课程注册管理系统软件需求规格说明书》。
(3) 评估项目风险并研究在本次迭代中可采取的降低或消除风险的行动计划。项目风险包括跨越多个开发阶段的全局性风险，以及在需求工程过程中可能出现的风险。针对原先已标识的风险，应在原风险管理计划的基础上研究本次迭代中应实施哪些行为降低或消除风险（参见例1）；此外，还须仔细考虑在本次迭代中有关本次迭代目标的局部风险、引入新需求或需求变更可能导致的全局性风险以及相应的管理措施。延伸至本次迭代之外的新的风险项及其管理措施应加入至项目风险管理计划；局部于本次迭代的风险项及其管理措施应出现在本次迭代的工作计划中。此外，计划在本次迭代中采取的针对全局性风险的应对措施也应一并体现在本次迭代的工作计划中。
(4) 制订本次迭代的工作计划，必要时还需调整软件项目计划。工作计划包括以下内容：每项活动的日程安排、负责人及参与者、所需的资源及负责提供资源或确保资源按时可用的利益相关者、活动要求的输入制品、活动生成的输出制品；风险管理计划；本次迭代的里程碑。在制订工作计划之前，必须先理解组织的需求管理方针，以使计划符合此方针的要求。见例2。
(5) 评审工作计划。所有利益相关者对工作计划进行评审。与本次迭代中的活动相关的小组（受影响组）由其代表参加评审即可。计划评审一经通过，则认为所有评审者均对其负责的活动的日程安排、提供的资源或输入制品做出了明确的承诺。一旦项目经理签署了本次迭代的工作计划，则视同他承诺对计划中要求的人力、经费及其他资源在组织领导层面提供保障。
2.5 策划活动的输出制品
策划活动的输出制品为经评审通过的本次迭代的工作计划、（修改后的）项目风险管理计划。
2.6 策划活动的出口准则
策划活动的出口准则为：
(1) 前述的需求策划目标已达到。
(2) 参与本次迭代的人员（经过必要的培训）已具备必需的技术及管理技能。
(3) 本次迭代需要的资源已经完全标识并已预作分配。
(4) 本次迭代的所有技术性及管理性工作事项的职责已明确到人。
(5) 工作计划已通过评审并且所有利益相关者均已知晓并同意该计划的全部内容。
2.7 策划活动小结
参与需求工程策划活动的角色及职责如表4所示。
表4 参与需求工程策划活动的角色及职责
| 角色 | 职责 |
| 需求工程师
| (1) 标识所有利益相关者； (2) 与项目软件经理共同确定本次迭代的目标和验收准则； (3) 制订本次迭代的工作计划。 |
| 项目软件经理 项目经理 | (1) 与需求工程师共同确定本次迭代的目标和验收准则； (2) 与需求工程师共同评估项目风险并研究在本次迭代中可采取的降低或消除风险的行动计划； (3) 评审本次迭代的工作计划。 |
| 用户 系统工程师 测试工程师 软件质量保证工程师 软件配置管理工程师 | (1) 评审本次迭代的工作计划； (2) 对与自身相关的任务、进度约定做出承诺。 |
需求策划活动中的步骤可按次序组织为需求策划工作流，见图7。
图7 需求策划工作流
一旦工作计划确定，后续的工作就是按部就班地执行该计划。计划中最主要的事项依次是需求获取、需求分析、需求规范化、需求验证和本次迭代总结。下面各节依次介绍完成这些事项的方法及工作流。
3 需求获取
需求获取的目标是，从用户的角度，完整地收集并以用户容易理解的业务语言阐述软件需求，形成文档。
需求工程是后续软件开发活动（包括设计、实现、测试、维护等）的基础，需求获取又是需求工程中后续活动（分析、规范化、验证等）的基础。由此可见需求获取活动的重要性。
3.1 获取活动的参与者
需求获取活动的主要参与者包括：来自软件开发方的需求工程师，来自委托方或投资方的客户，以及来自使用方的用户。当软件产品是专门为特定的使用方度身定制、使用方即是投资方时，客户与用户合一。当待开发的软件是更大系统的一部分时，系统工程师也应参与软件需求获取。需求获取活动的其他参与者包括项目软件经理、测试工程师、质量保证工程师等。所有这些参与者的职责将在稍后描述。
3.2 获取活动的进入准则
需求获取活动的进入准则与前述需求策划活动的出口准则相同。
3.3 获取活动的输入制品
需求获取活动的输入制品包括：有关项目目标、范围及价值的概述性文档，经评审通过的本次迭代的工作计划。
3.4 获取活动的预备知识
用户（包括客户）是软件需求的主要来源，需求获取阶段的主要工作就是通过与用户的交流沟通建立初步的需求模型，因此，如何与用户交流是需求工程师必须掌握的基本技能之一。此外，在展开讨论用例驱动的需求获取活动中的每个步骤之前，有必要对用例与需求之间的关系、用例的范围、用例的目标层次稍加阐释。
3.1与用户的交流技巧
只有赢得用户的信任，才有可能在需求工程甚至整个软件工程各阶段获得用户的积极配合。因此，需求工程师必须明确地表述软件产品将给用户带来的好处，并且设身处地为用户的利益着想。
由于用户往往希望在最短的时间内以最低的价格获得功能完善、性能卓越的软件，而开发方必须争取合理的开发时间、合理的价格、切实可行的功能范围和性能指标，用户的利益和开发方的利益难免发生冲突。此时，需求工程师必须合理权衡开发方的短期利益和长期利益。例如，通过保持与用户的长期合作关系来弥补当前项目的损失，或者，通过晓之以理、动之以情的方式说服用户适度缩小功能范围、降低性能要求，等。为了不使软件系统的范围随意扩大，要求分析人员必须学会有技巧地拒绝用户的不合理要求，并且不致使用户难堪。
由于知识背景、关注焦点的差异，需求工程师与用户的沟通往往存在相互理解方面的障碍。为克服这种障碍，需求工程师必须在与用户交流前充分准备，学习相关的业务术语和业务处理流程，驱除自以为是、闭门造车式的用户需求。需求工程师在交流过程中必须善于倾听，善于从用户的叙述中发现新的问题、挖掘深层次的需求。此外，可考虑采用直观的图形，以及简洁的、结构化的自然语言作为交流工具。图形化的交流工具包括描述业务处理流程的UML活动图，描述软件部署及设备连接的网络拓扑图，等。
3.2 用例与软件需求之间的关系
正如“2.1.1 执行者和用例”所述，用例表示执行者为达成一项相对独立、完整的业务目标而要求软件系统完成的功能。因此，用例是功能性软件需求的主体部分。在用例驱动的需求工程中，用例描述将占据需求规格说明书的大部分篇幅。但用例毕竟不是软件需求的全部，甚至也不是功能性软件需求的全部。全局性的业务规则、大部分非功能性的软件需求并不适于在用例中描述。不过，某些仅作用于单个或少数用例的业务规则可以直接在用例描述中出现（见§3.5.2中例10“制订选课计划”用例）。同样，仅约束单个或少数用例的非功能性需求也可通过UML的构造型作用于用例（见图13）。
3.3 用例的范围
为讨论用例的范围，需要对“2.1.1执行者和用例”给出的“执行者”和“用例”两个概念稍作拓广：用例可泛指执行者与系统（不仅限于软件系统）之间的一系列交互，执行者则泛指位于系统边界之外且与系统存在交互的外部实体。如此说来，在许多应用场景中，用例的范围从外至内、由大到小依次是：组织机构、信息化系统、软件系统、软件子系统，见图8。组织机构级的用例通常用来表示，机构希望在待开发的软件系统的帮助下为机构的客户或业务关联单位提供的功能；信息化系统级的用例表示，在引入待开发的软件系统后，机构希望信息化系统为达成机构的全局性业务目标而提供的功能。较小范围的用例是对其所在的较大范围的用例的细化。
3.4 用例的目标层次
用例的目标层次自顶至下依次是：概要层、用户目标层、子目标层。其中，处于用户目标层的用例直接服务于执行者的单项业务目标，它是需求获取阶段软件需求的主体部分；概要层用例服务于执行者的多项业务目标，往往用来说明多个用户目标层用例的运行语境，刻画它们之间的执行次序；子目标层的用例服务于执行者的单项业务目标中的一个子目标，往往用来细化规模较大的用户目标层用例。
3.5 获取活动的步骤
用例是软件工程界公认的迄今为止最恰当的初始软件需求表达方式［1］。用例驱动的需求获取活动的主要步骤如下：
(1) 业务分析。理解问题及背景，标识待开发软件产品的用户（及客户），理解业务领域中的术语及流程，定义软件产品的目标、范围，明确其业务价值。
(2) 创建框架性用例。框架性用例是指宏观功能已基本明确但内容尚不完整的用例。此步骤试图通过框架性用例尽可能完整地覆盖用户需求面。
(3) 填充框架性用例。对框架性用例填充内容使其成为完整的用例，必要时还可分解框架性用例，然后再作填充。此步骤还包括开发用例的典型应用场景，以便向用户解释用例的含义，并为用例的评审和测试奠定部分基础。
(4) 精化用例。将前面获得的用例汇聚在一起，系统地研究各种优化方案的可能性并实施优化。例如，将业务上相关或者功能上相似的多个用例通过参数化的方式合并为一个用例，通过用例之间的包含关系合并多个用例中的公共子过程，等等。此步骤将生成可供评审的用例模型，并基于该模型重新审视项目的风险。
(5) 评审。对于以用例模型为主体的需求获取结果进行评审。
在需求获取过程中，系统工程师与客户扮演的角色比较类似。为简洁见，本小节对二者不予明确区分，请读者自行推断系统工程师的职责。
3.5.1 业务分析
本步骤的目标是：获得对软件产品要解决的主要业务问题及其业务背景的初步理解，尽量消除需求工程师与用户之间的交流障碍；明确待开发的软件产品的目标、范围及业务价值；。
本步骤的主要参与者是：需求工程师（团队）、用户和客户。
本步骤的进入准则与§3.2所述的需求获取活动的进入准则相同。
理解问题及背景的主要子步骤如下：
STEP1：标识客户、用户
标识客户、用户，并确定他们各自在需求获取、需求验证、软件系统验收等技术活动中，以及在项目决策、资源供给等管理活动中的角色和作用。有两种情形需要考虑：
(1) 当软件产品是专门为特定的使用方度身定制、使用方即是投资方时。建议需求工程师索取用户的完整组织机构图。基于组织机构考虑以下几种用户：
¨ 用户机构中的第一负责人或其授权的信息化主管，以及软件系统所处理的业务的相应部门负责人。他们在项目决策、资源供给、需求验证、系统验收等活动中握有生杀大权，是需求获取阶段应予最多关注的用户。同时，他们也是软件产品的目标、范围、价值的主要信息来源，并且又是经营管理型、决策支持型软件需求（例如，统计分析类功能需求）的主要来源。有时他们还可能是非功能性软件需求的主要来源之一。
¨ 软件系统所处理的业务的相关部门中的业务操作员工。他们虽不如前一类用户重要，但他们在软件应用过程中的抱怨或抵制也将使软件项目功败垂成。此类用户是功能性软件需求的主要来源，同时也可能是非功能性软件需求的主要来源之一。
¨ 软件应用过程中负责系统配置、基本维护和技术支援的用户（往往是用户组织机构中信息中心之类的部门）。他们在项目决策、资源供给、需求验证、系统验收活动中为其领导提供咨询、建议，并且往往是后两种活动的实际执行者，同时也是软件配置、部署、维护型功能需求和非功能性需求的主要来源。
(2) 如果软件产品面向目前尚不能具体确定的用户（群），开发完成后交由软件项目的投资方进行市场推广，建议考虑以下几种客户/用户：
¨ 投资方中为本项目提供资源的负责人。其角色和作用类似于（1.1）中第一种用户。
¨ 投资方中负责策划、构思本软件产品的人员。其作用和角色类似于（1.1）中第二、三种用户的总和。
¨ 投资方中负责推广、销售本软件产品的市场营销人员。他们是确立软件产品的定位、特色的主要信息源。
¨ 如果软件产品的最终用户是个体，则应考虑邀请有代表性的用户参与需求获取活动，向其征询各类用户需求并请其参与需求验证；如果软件产品的最终用户是组织机构，则应考虑邀请有代表性的组织机构中如（1.1）所述的三类用户代表参与需求获取、需求验证。
STEP2：理解业务背景
本步骤的目标是，获得与用户有效沟通所必备的业务知识，并理解与用户需求相关的业务术语，尽量消除需求工程师与用户之间的交流障碍，从而提高后续的需求获取、分析活动的效率。达成此目标的方法有：
(1) 从相关用户处获取有价值的业务文档并对这些文档进行研究。有价值的业务文档是指对需求工程师理解业务背景、业务术语、用户需求有所帮助的文档，例如相关的管理制度、业务操作规范、遗留应用系统的用户文档（例如用户手册、需求规格说明）等。
(2) 观察并研究用户目前（尚未使用计算机支持时）完成相关业务处理的人工操作流程；在系统工程师的帮助下研究软件与系统中其他部件的协同处理流程。
(3) 关注业务领域中与待开发的软件系统相似或相关的现成软件产品，通过实际操作或文档研读了解其功能、使用方法。思考以下问题：现成软件产品可否在当前软件项目中直接使用？如何在当前软件项目的需求工程和软件设计阶段借鉴该软件产品？
(4) 建议需求工程师在实施上述步骤的过程中，采用UML的类图表示业务术语及其关系（又称领域概念模型），采用UML活动图表示业务处理流程，并将业务术语的定义汇集成术语词典，见例6。因为目前尚处于需求获取的早期阶段，领域概念模型图和业务流程图都不必过于精细，只要有助于需求工程师理解业务、有利于用户确认这种理解的正确性即可。
STEP3：策划需求调查
为理解软件问题及业务背景，确定软件产品的目标、范围和价值，个别访谈、会议是不可或缺的。因此，必须事先策划这些访谈和会议。策划工作的内容包括：预设目标，预定主题、问题清单、主持人和记录人，根据用户的角色和作用安排恰当的用户参与，与用户协商时间安排，等。策划的结果以访谈及会议计划的形式通知所有相关者。
需求工程师向用户提出的问题可分为封闭性和开放性两类，前者要求确定的答案，后者则要求用户自由发挥。例如，“每门课程设置最多容纳多少学生”属于封闭性问题，“除课程总时数外，对学生选课还有什么限制”则属于开放性问题。必须避免以封闭性提问误导用户或影响用户答案的真实性。
策划访谈和会议时必须留出足够的时间以供用户针对开放性问题畅所欲言，并充分讨论由事先准备的问题导出的后续问题，但需求工程师应掌控议题和进程，确保讨论和问答不至严重偏离需求获取的目标。
根据实际情况，对于一些规模不大的项目，可能没有必要针对“理解问题及背景”和“创建框架性用例”两个步骤分别制订访谈/会议计划，也没有必要分两次进行访谈，它们可以合二为一，见例8。
除访谈和会议外，如果需求工程师希望了解用户单位中许多人对某些问题的看法、在某些业务方面的需求，可考虑采用需求调查表。需求调查表中的问题清单、版面布局也必须经过仔细的策划，以减少用户填写需求调查表的工作量，使尽可能多的用户能够客观、精确地回答问题，使需求工程师在汇整调查表时能够判断用户的倾向性意见。
STEP4：实施需求调查
通过访谈、会议、需求调查表等手段达到以下目的：澄清需求工程师在理解软件问题及业务背景过程中遇到的疑难问题；请求用户确认需求工程师对软件问题和业务知识的理解；确定软件产品的初步定义（软件产品的目标、范围和价值）。在需求调查过程中，通过提出以下问题，或者与用户共同探讨以下问题，并结合STEP2的工作成果，确定或修改软件产品的定义：
¨ 软件产品应解决何种业务问题？在软件产品涉及的业务领域，有哪些改进能够为用户提高效益或创造价值？软件产品能够为这些改进做出何种贡献？这些问题的答案部分对应于软件产品的目标。
¨ 目前，与上述问题相关的业务是如何运作的？引入软件产品后，这些业务的运作应有哪些改进？对这些问题的分析有助于软件产品目标和范围的明晰化。
¨ 引入软件产品解决上述问题后，会带来哪些业务方面的好处？能够为用户创造何种价值？如何度量或客观地评估这种价值？这些问题的答案对应于软件产品的业务价值。
“理解问题及背景”活动的输出制品为：领域概念模型、业务流程及术语字典；软件产品定义。
参与“理解问题及背景”活动的角色及职责如表7所示。
表7 参与“理解问题及背景”活动的角色及职责
| 角色 | 职责 |
| 需求工程师 | (1) 标识用户（客户）； (2) 创建领域概念模型、业务流程及术语字典； (3) 确定软件产品的初步定义（目标、范围和价值）。 |
| 用户（含客户） | (1) 为需求工程师完成其职责提供有价值的信息； (2) 评审输出制品。 |
3.5.2 创建框架性用例
本步骤的目标是：提取框架性用例，并通过框架性用例完整地覆盖用户需求面。
本步骤的主要参与者是：需求工程师（团队）、客户和用户，其中前者负责框架性用例的创立，客户和用户负责提供相关的信息源。参与者中至少应有一人能够扮演业务领域专家的角色。所有参与者均参加本步骤工作成果的评审。
本步骤的进入准则是：用户（客户）已标识；需求工程师对软件问题和业务背景已有初步理解；软件产品定义已初步成形。
软件需求可以来源于系统需求或者业务需求，也可以来源于用户组织中的机构或个人，还可以来源于政策法规、行业标准、软件运行环境约束等。
创建框架性用例的主要子步骤如下：
STEP1：策划访谈和会议
此步骤的工作内容与“3.5.1 理解问题及背景”中的同名步骤一样，但此处访谈和会议的目标有所不同，必须围绕用例调查来展开。
STEP2：实施访谈并整理访谈结果
在访谈过程中，进行以下工作：
(1) 初步用例调查：基于事先准备的问题清单，或围绕预定的访谈主题和目标，需求工程师采用提问、探讨、追问、质疑等方式与访谈对象共同标识、理解用户需求，采用UML的用例和用例图记录并整理调查结果，见例9。在整理过程中注意以下事项：
¨ 从用户的视角而非软件开发者的视角，采用用户熟悉的业务术语描述用例的名称、目标、参与执行者、大致的交互动作序列。
¨ 尽可能完整地标识每个用例的所有利益相关者。采用执行者名称标识用例的参与者（利益相关者），不能使用用户的职务头衔，更不能使用用户的个体名称来标识用例参与者。
¨ 用例目标描述主要参与执行者使用此用例希望达成的业务目标，但同时也应考虑其他利益相关者的需求。
¨ 对交互动作序列的描述不必细化，甚至可以暂时忽略交互动作序列，更勿需考虑非典型的应用场景或异常处理。
¨ 明确各用例的范围和目标层次，据此确定多个用例之间在范围和目标层次意义上可能存在的从属关系。同时，在此阶段，应避免过早地陷入软件子系统级的用例和子目标层次的用例。
(1) 业务规则调查：业务规则是指人或软件系统在业务处理过程中必须遵守的约定或限制，见例10。在需求获取过程中，不仅要关注用例，也要关注与软件系统相关的业务领域中的规则。仅作用于单个用例的规则可以在用例描述中说明，全局性的规则宜在需求规格说明书中以专门的章（或节）的形式出现。
(2) 非功能性需求调查。基于一张比较完整的非功能性需求清单（参见表10），收集用户对软件产品在性能、可靠性、可用性、运行环境、外部接口、可保障性等方面的需求，见例11。在需求调查过程中应酌情增补用户提出的、在清单之外的非功能性需求，使清单不断完善。
STEP3：综合业务分析和访谈的成果
预估实现用例和非功能性需求的软件风险，并研究化解风险的方法和计划。例如，在访谈过程中，如果需求获取人员发现学籍管理系统尚在开发过程中，那么，可考虑在例1所示的风险管理计划中添加例12所述的内容。
STEP4：风险分析
预估实现用例和非功能性需求的软件风险，并研究化解风险的方法和计划。例如，在访谈过程中，如果需求获取人员发现学籍管理系统尚在开发过程中，那么，可考虑在例1所示的风险管理计划中添加例12所述的内容。
STEP5：非正式评审框架性用例
需求工程师、用户和项目软件经理一起（或许还包括业务专家）非正式地评审软件产品描述和框架性用例。评审的主要关注点是框架性用例集合的覆盖完全性。在评审过程中，需求工程师通过UML用例图、用例描述、用户界面情景板甚至界面原型向用户解释本步骤的工作成果－－框架性用例。用户界面情景板是指，在一张虚拟白板上，用一系列有序的用户界面样例表示，为了实现某种业务目标，用户与待开发软件产品之间的交互。有关界面原型的构造方法，请见“9 构建快速原型”。在评审过程中设法使用户理解软件产品描述和框架性用例并获得用户对二者的认可是至关重要的。考虑到此时真正的用户界面尚未成形，情景板上的界面可以是想象或虚构的。情景板仅示出关键的交互点、关键的交互信息或其轮廓，不必精确，也不求完整。
“创建框架性用例”活动的输出制品包括：框架性用例（用例图及用例描述），业务规则，非功能性需求描述，风险管理计划。
参与“创建框架性用例”活动的角色及其职责见表9。
表9 参与“创建框架性用例”活动的角色及职责
| 角色 | 职责 |
| 需求工程师 | (1) 创建框架性用例； (2) 标识业务规则； (3) 标识非功能性需求； (4) 创建界面情景板或界面原型； (4) 标识与需求实现相关的风险并制订风险管理计划。 |
| 用户（含客户） | (1) 为需求工程师完成其职责提供有价值的信息； (2) 评审输出制品。 |
| 项目软件经理 | 评审输出制品。 |
| 业务专家 | 评审输出制品。 |
3.5.3 填充框架性用例
本步骤的目标是：将框架性用例精化为严谨、完全的用例，在此过程中根据需要适当补充新的业务规则。
本步骤的主要参与者是：需求工程师（团队）、客户和用户、软件架构师，其中前者负责填充框架性用例、识别新的业务规则，客户和用户负责在需求工程师提出请求时提供补充信息或者澄清原有信息，软件架构师负责检查用例粒度的合理性及用例的易理解性。参与者中至少应有一人能够扮演业务领域专家的角色。所有参与者均参加本步骤工作成果的评审。
填充框架性用例的主要子步骤如下：
STEP1：审查用例粒度并进行必要的分解或合并
用例粒度是指用例对应的功能范围相对于整个软件产品的功能而言的规模比。用例粒度越小，整个系统的用例数量就越多。不可能有绝对的用例粒度标准，但本书建议需求工程师在判断用例粒度是否适当、是否需要分解用例时，采用以下准则：
(1) 范围大于待开发的软件系统，以及目标层次高于用户目标层的用例应分别分解至软件系统级、用户目标层；仅当粒度过大时，才考虑分解位于软件系统级和用户目标层的用例。
(2) 一个软件系统的用例总数一般应控制在20以内，最多不超过30。对于特别大型的软件系统，需要先将其切分为一些子系统，然后针对每个子系统分别考虑用例的粒度。在进行系统切分时，可借助UML包图来表示系统的划分，并将用例指派到包中。
(3) 用例的粒度应确保合理规模的软件开发团队能够在合理的时间周期内实现该用例。此处的“合理”也是相对于整体软件规模而言的。例如，对于案例1和案例2，软件开发团队的合理规模可分别设为2~3、3~5人，单次迭代的合理时间周期可分别设为1~2周、1~3周。对于非常大型的软件系统，单个用例的实现工作量应控制在10人月以内。
(4) 用例的分解应导致用户和软件开发人员能够更容易地理解被分解的用例以及分解后得到的子用例，而不是相反。
(5) 对用例的分解不能破坏现有用例在功能性需求方面的覆盖完全完全性。
下面再以CRUD（对同一种业务对象进行创建、检索、修改、删除操作）型用例为例来探讨用例的粒度问题。这种用例在应用中普遍存在。从理论上讲，CRUD四种动作对应四个相对独立的用户目标，将它们表示为4个用例是可以理解的。但是，在大型系统中，这样的用例粒度会造成用例数量太多。因此，本书建议将它们合并为一个用例，除非合并后的用例过于复杂。但合并会带来新问题：有些执行者只使用CRUD中的部分而非全部功能。例如，在课程注册管理系统中，教务管理员会用到针对课程的CRUD全部功能，但学生和教师仅用到其中的查询功能。此时，可考虑将查询功能从原CRUD型用例中独立出来，并让原用例包含（include）查询用例。
STEP2：构建完整用例
具体工作如下：
(1) 重新研究用例目标的表述、用例名称，标识所有的参与者。用例名称应该采用业务术语，反映参与执行者的主要业务目标。如果有多个参与执行者，难以在用例名称中涵盖所有参与者的业务目标，则应以主要参与执行者的主要业务目标为准。
(2) 标识触发条件。触发条件是指激励用例开始执行的动作或事件。一个用例可以有多个触发条件。应该采用业务术语而非软件界面动作来描述触发条件。例如：学生要求制订或修改选课计划（见例13中的“制订选课计划”用例）；客户通过网络或电话要求预订机票（见例25中的“订票”用例）。当不言自明时，触发条件往往可以省略。
(3) 标识前置条件。前置条件是指用例即将执行之前本用例的外部环境必须具有的状态。在许多情况下，前置条件的成立是因为前面某些用例执行的结果。例如，在例13中，用例“制订选课计划”的前置条件“课表已发布”由用例“制订课表”直接导出。此时，可以采用更大范围或更高目标层次的用例来说明用例之间的时序要求，见例9中的用例“课程注册管理”。前置条件与触发条件之间的关联是：当触发动作或事件发生，并且前提条件成立时，用例开始运作。它们之间的差异是：触发条件是用例启动的推动力；前置条件是决定是否阻截此推动力的过滤器。
(4) 描述或精化原有的基本交互动作序列。用例中的交互动作序列表示，为达成用例目标，用例的参与者（执行者）与软件系统之间的一系列交互事件，这种交互体现了二者之间的分工、协作。基本交互动作序列是指，在不考虑任何例外的情况下，最简单、最直接的交互动作序列。需求工程师可以从下述方面提炼基本交互动作序列：
¨ 观察现有的业务处理过程，思考在引进新的软件系统后如何优化该过程。
¨ 通过访谈深入了解用户（客户）希望软件系统在帮助用户完成业务目标的过程中发挥何种作用、完成何种功能。
¨ 研究软件系统如何更好地帮助用户。
¨ 研究执行者和软件系统在协同工作的过程中各自应在何种时机、向对方提供何种交互信息。
(5) 标识并描述扩展的交互动作序列。“扩展”是指，在基本交互动作序列的基础上，因为特殊情形的出现而导致动作序列出现分支。一般而言，扩展源自两种情况，一是存在不同于基本交互动作序列的非典型应用场景，二是执行者或外部环境在交互过程中给系统造成了基本交互动作序列无法处理的异常情况。具体的扩展交互动作序列的表示形式见例13。严格分离基本和扩展的交互动作序列，一方面是为了避免需求工程师过早陷入用例中的处理细节，另一方面也是为了保持用例描述的简洁性，使用例的业务目标不致湮灭于特殊情况的处理细节之中。
出现扩展的交互动作序列的原因在于，某些情况的出现导致基本交互动作序列无法处理，这些情况也就成为扩展动作序列的执行条件。因此，标识扩展交互动作序列的关键在于标识扩展条件，扩展条件下的处理动作序列的描述方式与基本动作序列类似。在探究用例的扩展条件时，最好集中列出所有可能导致分支和异常的条件，然后用“系统必须能够检测到该条件”、“系统必须能够处理该条件导致的情形”两条标准来筛选出真正的扩展条件，并考虑合并处理动作完全相同的扩展条件。例如，“用户忘记密码”会导致“系统验证用户密码”动作无法进行，但此条件却是系统检测不到的，应改写为“密码输入超时”。又例如，“银行卡已过期”、“银行卡持卡人姓名不符”、“银行卡可用额度不足”的处理动作相同，可合并为“银行卡无效或可用额度不足”。
在考虑用例的扩展处理时，需求工程师可能面临如下困惑：扩展的动作序列是否应在另一个单独的用例中出现？对此问题的回答实际上取决于需求工程师对用例粒度的把握和扩展的复杂程度。如果扩展相当复杂，使得原用例难于理解，应针对扩展创建新的用例，并在UML用例图中用扩展关系（<<extends>>）连接扩展用例和原用例。
本小节稍后将详细论述基本和扩展的交互动作序列的描述方法。
(6) 描述用户与软件系统交互过程中传递的信息项的主要内容。尽管不需要对所有此类信息项给出内容描述，但是，如果信息项中包含的内容比较丰富，并且读者无法仅仅从信息项的名称推导出其中的所有内容，则需要显式说明这些内容。例如，在案例2中，必须说明机票销售的统计分析报表中的内容。显式说明信息项内涵的方式有两种：在使用信息项的动作步骤中说明；对信息项命名，在交互动作描述中引用此名称，在用例描述中增加与“用例名称”、“基本交互动作序列”平行的条目“信息项”，在此条目下说明各信息项的内容。如果信息项在多处使用，必须采用第二种说明方式。
STEP3：补充业务规则
在填充框架性用例的过程中发现的新业务规则应加入至“创建框架性用例”阶段所标识出的业务规则集合中。当然，也可以根据需求获取的不断深入修改原先获得的业务规则。
STEP4：评审细化后的用例
需求工程师和用户一起非正式地评审细化后的用例和业务规则。评审方法与“创建框架性用例”阶段的评审方法类似，但主要关注点要从用例对软件需求的覆盖完整性转移至用例描述在业务层面上的精确性。
以上前3个步骤之间不存在严格的时序关系。
“填充框架性用例”活动的输出制品是对在“创建框架性用例”活动删除制品的精化和扩充，具体包括：填充后的框架性用例（包括较详尽的用例描述及修改后的用例图），修改后的业务规则。
参与“填充框架性用例”活动的角色及其职责见表11。
表11 参与“填充框架性用例”活动的角色及职责
| 角色 | 职责 |
| 需求工程师 | (1) 填充框架性用例； (2) 补充业务规则。 |
| 用户（含客户） | (1) 为需求工程师完成其职责提供有价值的信息； (2) 评审输出制品。 |
用例中扩展交互动作序列的文字表述方法
用例中扩展的动作序列的表示方法是：标识可能出现特别情形的基本交互动作序列中的动作的编号，说明扩展分支的条件、处理动作序列、扩展处理完成后与基本动作序列的汇合点。
一般用基本动作序列中的动作编号加英文字母来标引扩展条件，它表示在基本动作序列中的相应步骤可能出现条件所示的情形。相应的扩展动作序列则以条件标号再加动作序号来表示。例如，“2a系统发现任课教师、上课时间、教室有冲突”表示在基本动作序列的第2个步骤可能出现冲突。“2a1 ……”表示冲突出现时的第1个处理动作。为保持版面清晰，扩展动作序列应基于扩展条件向右缩进。如果在基本动作序列的同一步骤会出现多个分支条件，则条件标号的字母依字母表的顺序向后延伸，但这种延伸并不隐含时序关系方面的意义。如果在基本动作序列中的多个步骤会出现同一分支条件，且相应的扩展处理动作序列也基本相同，则用动作编号序列加字母作为条件标号，例如“3，4，5a”或更简洁的“3－5a”标识在基本动作序列中的第3、4、5三个步骤可能出现的条件。最后，如果在扩展动作序列中再出现分支条件，那么可综合采用上述条件标号规则、扩展动作序列编号规则和版面编排规则，直接在一个扩展动作序列中嵌套地表示另一子扩展条件及其动作序列，见例13中的用例“用户登录”。扩展的嵌套不宜过深。如果确有需要，建议分离出单独的扩展用例以减少扩展嵌套深度。
此外，如果一个用例M包含子用例S，并且S中多种扩展条件导致的异常在M中的处理动作相同，则在M中应将它们归并为单个扩展条件，这是在高层用例中避免扩展条件爆炸的有效方法。例如，例13中用例“制订课表”包含了子用例“检查课程设置冲突”，后者的扩展条件“任课教师在同一时间有其他课程设置”，“同一教室在同一时间安排了不同的课程设置”在用例“制订课表”中应归并为单个扩展条件：“课程设置有冲突”。
3.5.4 精化用例
本步骤的目标是：清除不必要的用户需求，清理不一致的用户需求，优化用例模型。
本步骤的主要参与者是：需求工程师（团队）、客户和用户、软件架构设计人员，其中前者负责精化用例，客户和用户负责在需求工程师提出请求时提供补充信息或者澄清原有信息，软件架构设计人员负责检查用例的易理解性及用例模型的合理性。参与者中至少应有一人能够扮演业务领域专家的角色。所有参与者均参加本步骤工作成果的评审。
3.5.5 评审需求获取结果
需求工程师、用户、项目软件经理和业务专家一起正式地评审迄今为止需求获取阶段的所有工作成果，包括软件产品定义、领域概念模型，以及精化后的用例模型、非功能性需求、业务规则、测试场景、风险管理计划，其中用例模型是被评审的主体对象。评审方法与“创建框架性用例”阶段的评审方法类似，但主要关注点更为全面，必须覆盖需求模型的一致性、精确性和完全性。
3.6 获取活动的输出制品
需求获取活动的输出制品包括：经评审通过的软件产品定义、领域概念模型、用例模型、非功能性需求、用户界面情景板或界面原型、业务规则、测试场景、风险管理计划等，其中用例模型是输出制品的主体部分。如果对本次迭代的工作计划有所调整，那么输出制品还包括新版的工作计划。
3.7 获取活动的出口准则
需求获取活动的出口准则是：“3 需求获取”开篇所述的需求获取的目标已达到，并且输出制品已经用户认可并签署。
3.8 获取活动小结
需求获取活动的五大步骤（理解问题及背景、创建框架性用例、填充框架性用例、精化用例、评审需求获取结果）基本上应依序施行，但在后面的步骤中可针对特定的用例返工至前面的步骤，见图14。此外，在规模较小的软件项目中，可考虑合并第3、4步，甚至合并第2至4步。
在用例驱动的需求获取阶段，建立用例模型是其主要技术活动。除此之外，软件质量保证工程师应当并行地检查、评审需求获取的技术过程和输出制品，以便及时发现过程与输出制品中可能存在的质量缺陷。
综上，需求获取活动可以表示为图14所示的工作流。
图14 需求获取工作流
4 需求分析
需求分析的目标是，在需求获取的输出制品的基础上，获得对用户需求的更深入的理解，并且将（部分）用户需求表示为面向软件设计人员并且易于修改、维护的需求模型。需求分析的主要手段是，采用一种比自然语言更加结构化、更加清晰直观的方式（例如UML交互图、类图、状态图、活动图等）来表示需求获取的（部分）结果，并在此过程中进行必要的精化和调整。建立需求模型是分析活动的焦点，因为模型能够以一种简洁、准确、结构清晰的方式系统地描述用户需求，使需求臻于完善，从而便于分析人员剔除需求描述中的模糊性、不一致性、不完整性，便于设计人员理解需求、设计结构、构思算法。因此，分析过程实质上是需求模型的建造和不断完善的过程。
需求分析的输出制品既是需求规格说明书的主要内容，也是软件设计和实现活动的基础。
1 分析活动的参与者
需求分析活动的主要参与者包括：需求工程师、软件设计师、项目软件经理、用户（客户）、系统工程师、测试工程师、质量保证工程师等。所有这些参与者的职责描述见“7 分析活动小结”。
2 分析活动的进入准则
需求分析活动的进入准则是：
(1) 领域概念模型和用例模型已经基本确定。
(2) 参与分析活动的人员（经过必要的培训）已具备必需的技术及管理技能。
(3) 所有技术性及管理性工作事项的职责已明确到人。
3 分析活动的输入制品
需求分析活动是在需求获取活动的工作成果的基础上展开的，其输入制品与获取活动的输出制品相同。在所有这些输入制品中，领域概念模型和用例模型最重要。
4 分析活动的步骤
基于用例模型进行需求分析的主要步骤如下：
(1) 分析需求的质量属性。
(2) 确定各需求条目的优先级，选取优先分析的用例。
(3) 精化领域概念模型。
(4) 用例分析。针对每个待分析用例，依次进行以下工作：
(1) 提取分析类。
(2) 利用UML交互图表示用例的交互动作序列。
(3) 基于领域概念模型和交互图构造分析类图。
重复步骤(3)~(4)，直至本次迭代规划的所有待分析用例均分析完毕。
(5) 构造状态图、活动图。
(6) 构建快速原型。
(7) 评审分析模型。
步骤(6)与步骤(1)~(5)之间不存在严格的时序关系，这就意味着，可以在需求分析过程中的任意时刻开发快速原型，以便厘清某些疑难问题、方便用户对需求分析的阶段成果进行评价、纠错和确认。
步骤(3)~(5)依次构造分析模型的各成分，在此过程中必须记录这些成分与需求获取阶段得到的各需求项之间的追踪关系。至于这些需求项的标识，建议对非功能性需求项，直接采用需求获取阶段给出的标识（见表10）；对功能性需求项，则采用用例名和包名构成的层次化名称，在没有分包的情况下，直接使用用例名。例如，功能性需求标识“pack1.subPack11.useCaseA”表示包“pack1”的子包“subPack11”中的用例“useCaseA”；功能性需求标识“useCaseXXX”表示不属于任何包的用例“useCaseXXX”。
在整个分析过程中，需要采用许多分析决策，例如需求项质量属性的判定、优先级的划分、分析类的设置、消息序列的构思、状态的设定等。有些分析决策是显而易见的，但也有部分决策颇费思量。因此，有必要采用正规的分析决策表（见表13）记录后一类分析决策及其依据或理由，以便从事后续设计和实现活动的软件工程师更好地理解分析模型，同时也可以为其他项目的需求分析活动提供借鉴。
表13 分析决策表（样表）
| 序号 | 决策描述 | 决策依据 | 决策的影响 | 其他说明 |
| 1 | [描述问题及采取的解决方法] | [描述采取此决策的依据或理由] | [描述受此决策影响的需求模型中的元素、图形或文档位置] |
|
| 2 | …… | …… | …… | …… |
1 分析需求的质量属性
需求的质量属性因项目的具体情况而异，需求工程师可基于下述典型质量属性列表进行裁减或扩充：
(1) 正确性：每个需求项正确地、真实地反映用户需求的程度。
(2) 一致性：需求项内部、需求项之间没有逻辑冲突。
(3) 精确性：需求项的表述不至引起二义甚至多义理解。
(4) 完全性：所有需求项构成的全集完整地覆盖所有必须在待开发软件产品中实现的用户需求，尤其不能遗漏重要或者紧迫的用户需求。
(5) 无冗余：每项用户需求在需求模型中仅出现一次。
(6) 可行性：在实际资源约束条件下，软件项目组能够完整实现某项需求的可能性。
(7) 稳定性：每项需求能够在软件开发周期、软件生命周期内保持不变的可能性。
(8) 可测试性：在验收测试阶段，开发方能否通过呈现测试结果，客观地、无争议地向用户表明某项需求已经被完整实现。
(9) 可修改性：需求项发生变化时对整个软件系统的结构、质量及项目计划的影响程度。
(10) 用户价值：需求项对于用户完成业务目标的重要性。
(11) 实现风险：在实现需求项的过程中可能存在的风险因素及其应对措施。
如果发现某项需求的质量属性有缺陷，那么需求工程师应重新进行需求调查，或者再次与相关用户沟通。例如，针对可行性，需求工程师必须综合考虑需求项（尤其是非功能性需求项）与项目可用资源约束，进行合理权衡。对于明显不可行的需求项，需求工程师应与用户友好协商，适当降低指标或功能要求。针对所有非功能性需求，均应采用精确、严谨的表述方式，确保其可测试性、可验证性，尽可能使开发方在验收测试阶段能够以客观的、有说服力的方式向用户表明该项非功能性需求已经完整实现。
2 确定需求优先级
此步骤在前一步骤工作成果的基础上完成三项任务：为每个需求项确定优先级；安排待分析用例的优先次序；根据优先级分析结论调整工作计划。
STEP1：确定需求优先级
由于交付时间、人力资源、预算成本等方面的限制，软件项目可能难于一次性、高质量地完成所有的用户需求。在此情况下，有必要分析并确定各需求项的优先级，以便软件工程师和项目管理者在后续的开发过程中有重点地投放资源，确保最紧迫、最有价值的用户需求项早于其他次要需求项得以实现，同时也确保重要需求项的实现质量至少不逊于次要需求项的实现质量。
对需求优先级的含义，有三种不同的诠释方法[3]：
(1) 基于实现紧迫度的优先级：高优先级表示在当前软件版本中必须实现的需求项；中优先级表示最终必须实现的需求项，但在资源紧张时可以延至下一软件版本再实现；低优先级表示“锦上添花”式的需求项，在资源充分时其实现会使软件产品更完美。
(2) 基于产品可接受度的优先级：基本需求项表示软件产品为用户接受所必需的需求项；条件需求项表示可以增强用户满意度的需求项，但是，如果不实现这些需求项，软件产品仍是用户可接受的；可选需求项类似于条件需求项，其对软件产品的用户可接受性的影响更弱。
(3) 基于需求实现度的优先级：高优先级表示在当前软件版本中必须完整并尽可能完美实现的需求项；中优先级表示在资源紧张时可以有小部分不予实现的需求项，实现中允许出现无关紧要的瑕疵；低优先级表示可以有部分甚至完全不予实现的需求项，实现中允许出现缺陷。
一般而言，需求优先级取决于三个因素的综合作用：需求项为用户提供的价值、需求项的实现成本及实现过程中的风险。可以将这些因素量化为若干级别，然后采用某种计算公式获得需求优先级排序，再结合项目可用资源约束，按照前述定义划分需求项的优先类别。优先级计算公式举例如下：
优先级 ＝ 价值 / ( 成本 × 成本权值 ＋ 风险 ×风险权值)。
读者可根据实际项目的具体情况，在定义优先级时选用上述诠释方法之一，或者综合采用多种方法。也可以对需求优先级的决定因素进行裁剪或变通，例如：仅考虑价值和成本因素；在价值、成本和风险因素的基础上增加对开发时间因素的考量；等。
STEP2：编排用例分析的优先顺序
在后续的分析过程中，试图一次性全面分析所有的用例会导致注意力的分散、针对类似问题重复求解等低效现象，用例分析的次序安排不当还会造成不必要返工。所以，需求工程师应按以下原则精心挑选单次迭代中待分析用例，合理编排用例分析的优先次序：
(1) 对系统架构影响较大的用例优先。
(2) 对用户需求的实现贡献较大的用例优先。
(3) 在迭代式开发过程中，能够较多地覆盖风险面的一组用例优先。
STEP3：调整工作计划
根据前述的需求项优先级分析结论、待分析的用例优先次序安排，适当调整本次迭代的工作计划、需求工程阶段的工作计划，乃至整个软件项目的工作计划。
3 精化领域概念模型
本步骤的目标是：提取跨越多个用例的全局性、关键性公共概念，表达这些概念的内涵及其相互关系，为后续分析活动奠定公共的概念基础。
执行本步骤的方法是：
(1) 在需求获取活动得到的领域概念模型的基础上，结合用例描述和业务术语字典，提取多个用例中相同或相似的概念，统一命名，标识其中蕴藏的属性，研究它们之间是否存在继承关系、关联关系，将精化后的领域概念模型表示为UML类图（见图15）。
(2) 必要时，记录用例模型与此类图之间的追踪关系。具体的记录方法是：
¨ 将用例模型中所有用例构成的集合划分为若干可以重叠的子集，每个子集中的各个用例可追踪至类图中相同的类的集合。
¨ 在追踪表的每行，依次记录子集中的用例标识的列表、相关的类的列表，见表15。如果有某个类不在此表中出现，说明它对于用例的实现无价值，应该从类图中删除。
本步骤的关键在于确保各用例使用统一定义的业务概念，精细化和完整性不是重点。此时可暂不考虑概念类中的操作，属性列表不必完整，也勿需在概念之间标识除继承和关联之外的其他关系，因为类图的精化将贯穿分析和设计的全过程。
4 提取分析类
分析类是指直接服务于用户功能性需求的概念层面的类。分析类与待开发软件系统的具体实现技术无关。从功能需求的角度看，业务逻辑处理主要由三种分析类协同完成：
(1) 边界类：负责目标软件系统与外部执行者之间的交互，包括：
¨ 界面控制：包括输入数据的格式及内容转换，输出结果的呈现，软件运行过程中界面的变化与切换等。
¨ 外部接口：实现目标软件系统与外部系统或外部设备之间的信息交流和互操作。主要关注跨越目标软件系统边界的通信协议。
¨ 环境隔离：将目标软件系统与操作系统、数据库管理系统、应用服务器中间件等环境软件进行交互的功能与特性封装于边界类之中，使目标软件系统的其余部分尽可能地独立于环境软件。
(2) 控制类：作为完成用例任务的责任承担者，负责协调、控制其他类共同完成用例规定的功能或行为。对于比较复杂的用例，控制类通常并不处理具体的任务细节，但是它应知道如何分解任务，如何将子任务分派给其他类，如何协调这些类的工作。
(3) 实体类负责保存目标软件系统中具有持久意义的信息项并向其他类提供信息访问的操作。实体类的操作具有“内向收敛”特征，它们仅向目标软件系统的其余部分提供读、写信息项内容的必要的操作接口，一般不涉及业务逻辑处理。
在UML中，边界类、控制类和实体类的构造型依次为<<boundary>>、<<controller>>和<<entity>>。
在讨论了边界类、控制类和实体类的基本概念之后，下面介绍如何从分析模型中的用例描述和（精化后的）领域概念模型出发获取这些分析类。
通常情况下，执行者与用例之间的一种通信连接对应一个边界类。但是，如果两个以上的用例与同一执行者交互，并且这些交互具有共同的行为、完成相同或类似的任务，就可以考虑用同一边界类实现多个用例与执行者之间的交互。这就意味着边界类的作用范围可以超越单个用例。
一般而言，一个用例通常对应一个控制类。如果不同用例的任务有较多类似之处，也可以考虑在多个用例的实现方案中共享同一控制类。不过，此种情况应审慎对待，因为，对于不同的用例，其业务处理逻辑的结构鲜有雷同，它们所需要的控制、协调行为往往会有差异。如果一个用例非常复杂，可以针对它设置多个控制类，每个类负责该用例中的某项子功能。另一方面，对于非常简单的用例，可以将控制类与边界类合并，直接在边界类中设置控制、协调功能，边界类在实体类的帮助下完成用例要求的功能及行为。
实体类主要来源于领域概念模型和用例描述中具有持久意义的信息项。实体类一般与用例中特定的业务逻辑关系不大，因此其作用范围往往超越单个用例而被多个用例共享。如果参与用例的执行者的属性需要持久保存，也可以建立相应的实体类。假设一个实体类A仅仅被系统中的另一个类B引用，并且系统勿需关心A的行为特征，那么，为了简化设计模型，应将A中信息项直接作为B的属性。反之，如果A被系统中的多个类引用，或者A具有不容忽略的行为特征，那么应将A作为独立的实体类。
5 构造交互图
在标识边界类、控制类和实体类之后，接下来的任务是，将用例模型中的用例描述转化成UML交互图，以交互图作为用例的更精确、更直观、更结构化的表示形式。构造交互图的关键在于将用例的各项功能分解并分派至合适的分析类，并研究分析类之间如何通过消息传递来协同地完成各项功能。交互图有助于需求工程师更深入地理解、分析用户需求，剔除用例描述中的模糊性、不一致性、不完整性，同时也为后续的软件设计奠定基础。
如前所述，用例描述中已包含事件流说明。用例中发生在执行者与系统之间的交互事件直接对应于交互图中执行者与边界类之间的消息，用例描述中事件间的先后关系体现为交互图中的时序。典型的用例功能的完成过程基本上遵循如下过程框架：
(1) 主动执行者向边界类发出命令。
(2) 边界类仅仅完成必要的输入信息解析工作，将命令以控制类可识别的内部表示形式传向控制类。
(3) 控制类为了完成命令所要求的业务逻辑处理，可能向实体类发送消息以获取必要的信息项，也可能向实体类发送消息以持久保存业务逻辑处理的部分结果。
(4) 控制类将业务逻辑处理的部分结果通知边界类。
(5) 边界类针对处理结果进行必要的从内部表示形式向外部表示形式的变换，再传递给被动执行者。
根据上述过程框架，需求工程师应可针对用例描述推导出在三种分析类之间传递的消息及其时序。但是，必须指出，需求工程师在分析用例模型时必须基于此过程框架进行灵活变通，变通的依据是其对用例描述的理解。例如，步骤(3)可能没有必要；步骤(2)和(5)中的边界类可能是同一个类；步骤(2)中的边界类可能没有必要，主动执行者直接向控制类发出命令；等。
按照上述过程框架，在UML顺序图中，用例的主动执行者应位于最左侧，紧邻其右的类是作为用户界面或外部接口的边界类，再往右是控制类。控制类的右侧应放置实体类，它们的右侧是作为外部接口和环境隔离层的边界类，最右侧是位于目标软件系统的边界之外的被动执行者。如此布局之后，在顺序图中不应该出现穿越控制类生命线的消息，也即，用例实现方案中的前端处理、核心业务逻辑、后端处理已经被适当隔离。按照上述布局规则绘制的典型的顺序图如图16所示。
图16 典型布局规则下的顺序图
由于顺序图能够非常直观地表达消息（事件）的时序，所以它比通信图更多地用于描述用例模型的分析结果。但是，当需要强调分析类之间的联系或连接时，就需要绘制通信图。通信图的布局规则是：控制类位于中心；主动执行者和作为用户界面或外部接口的边界类位于左上方，主动执行者位于此种边界类的左面；被动执行者和作为外部接口和环境隔离层的边界类位于右上方，被动执行者位于此种边界类的右面；实体类位于控制类的下方。按照此布局规则绘制的典型的通信图如图17所示。顺序图和通信图互为派生视图，所以，对同一用例，不需要同时绘制顺序图和通信图，二者择一即可。
图17 典型布局规则下的通信图
有时，为了简化交互图，可以省略位于系统边界之外的被动执行者（这些执行者与边界类之间传递的消息当然也一并省略），甚至也可以省略位于系统边界之外的主动执行者。此外，在交互图中，可以借助文字注解阐述一些难以用UML图形设施表达的语义。文字注解包括指向消息的注解和面向时间段的注解，见图16。
如何利用交互图表示用例描述中的扩展交互动作序列？如果扩展交互动作序列比较简单，可以直接在交互图中合并表示基本与扩展的交互动作序列。否则，应采用单独的交互图来表示扩展交互动作序列，其中不应重复基本交互图中的消息，而应借用UML交互图的结构化机制（见“2.4 交互图”），直接引用基本交互图中的消息序列，见图18。
交互图与用例模型之间的追踪关系非常简单：对于动作序列比较简单的用例，一张交互图直接对应一个用例。但是，对于较复杂的用例，单张交互图难以清晰地表示其所有动作序列，此时，需要为此用例绘制多张交互图，每张交互图表示用例的一个相对简单的子动作序列。无论哪种情形，交互图与用例之间的追踪关系都是相当直接的，所以没有必要单独构造此种追踪关系表。
6 构造分析类图
通过“提取分析类”和“构造交互图”两个步骤，已经将用例描述中以自然语言表达的事件流转化为更精确、更直观、更结构化的消息及其时序。本步骤进一步将消息转化为分析类的职责，从而推动分析模型的精化，持续迈向软件设计和编程实现。
按照需求牵引的观点，分析类的职责源于其必须响应、处理的消息，即，对消息的响应构成作为消息接收者的分析类的职责。这种职责在后续的设计活动中将被确立为“设计元素”（见“第五章 软件设计”）的功能或方法。从用例描述中的事件，到交互图中的消息，再到分析类的职责，最后演变为设计元素的功能或方法，这个进化过程是面向对象分析与设计的关键所在。
用例描述中的事件和交互图中的消息具有明显的动态特征，它们对应于分析类的实例；职责和方法则处于静态特征的范畴，它们分别属于分析类和设计元素。消息之间的时序体现了业务逻辑处理过程中各子动作之间的先后次序；职责和方法之间虽然无所谓时序，但它们在执行过程中却必须遵守交互图所规定的时序，设计元素中实现相关功能或方法的函数体必须维持这种时序。
构造分析类图的具体方法（步骤）如下：
(1) 比较并研究领域概念模型和交互图，以领域概念模型为基础初创分析类图。如果交互图中出现了某个对象，其所属的分析类未在领域概念模型中出现，则应在分析类图中添加此分析类；反之，针对领域概念模型中的类，如果其对象未在任何交互图中出现，则需求工程师必须判断该类是否对用户需求的实现有所贡献。如果该类作为交互图中某条消息的参数类型或返回值类型，或者该类的对象包含消息响应函数所必需的信息，那么答案应该是肯定的，该类应该在分析类图中出现。如果领域概念模型中的类与用户需求的实现无关，那么该类在分析类图中应予忽略。
(2) 根据消息确定分析类的职责。原则上，对每个分析类都应该安排一项职责来响应交互图中指向其对象的那条消息。但是，这并不意味着消息与职责一定会一一对应，因为分析类的一项职责可能具有响应多条消息的能力。至于分析类图中职责的描述方式，既可以严格地采用UML中类的操作的表示（见“2.2.1.2 操作”），也可以仅采用简短的自然语言。无论采用何种描述方式，必要时都应通过UML的注解机制阐明分析类的职责的含义。职责的参数可以暂时忽略，也可以显式示出（此时必须确保职责的参数与交互图中相应消息的参数相一致）。在后续的设计过程中，采用自然语言描述的分析类的职责将进化为符合UML要求的严格的设计元素的操作定义，操作的参数也将补全。
(3) 根据消息传递确定分析类之间的连接。概念上，可以认为交互图中两个对象之间的消息传递有赖于它们分属的两个类之间的“消息传递通道”，正像两座城市之间的货物运输有赖于连接它们的交通线。在UML图类中，关联、聚合和组合关系均可提供消息传递通道，因此，如果交互图中存在从类A的对象到和类B的对象的消息传递，就需要在分析类图中添加从A指向B的关联、聚合或组合关系。当然，如果原领域概念模型中已经存在这三种关系之一，就不需要再添加。针对给定的两个对象，如果在它们之间同向传递的消息有多条，这些消息可以共享分析类图中的相同通道，没有必要针对每条消息建立不同的通道。此外，如果在分析类图中从类A到B之间存在经由其他分析类的路径，那么也不需要在A到B之间再搭接直接的消息传递通道，因为消息已经可以从A的对象到达B的对象。
(4) 根据交互图确立分析类的属性。实体类的属性取决于系统希望在该实体类的名下持久保存哪些数据项，这些数据项可以从领域概念模型、业务术语词典、用例描述中部分地获取。针对一般的分析类（包括实体类），它们完成消息响应的能力来源于两方面的知识，一是类本身具有的信息（数据），二是类能够找到的其他类，通过其他类协助其完成消息响应。在综合考虑这两个因素之后，需求工程师必须思考：分析类职责中的哪些子任务可通过消息传递路径委托给其他类完成，哪些子任务必须由自身完成。为了分派前一种子任务，分析类可能需要一些信息以寻找最恰当的受托类；为了完成后一种子任务，分析类自身更应具备相应的知识（信息或数据）。基于上述考虑，再结合领域和业务知识，需求工程师即可推导出分析类必须具有的属性。类似于职责在分析类图中的表示，属性既可以严格地采用UML中类的属性的表示（见“2.2.1.1 属性”），也可以仅采用简短的自然语言的名词或名词短语。在目前阶段，需求工程师没有必要过分担心分析类的属性列表的完全性，只需将分析类为完成职责所必需的信息列入其属性表即可，后续的设计过程将进一步精化类的属性定义，见“5.8 类设计”。
(5) 整理分析类图。迄今为止已经获得了覆盖多个交互图的分析类图，由于这些交互图可能来自不同的包，所以这些分析类图也应该分属不同的包。原则上，一个包仅包含一张分析类图，当然也不排除一个规模非常大的包可能包含多张分析类图。在分析、设计工作继续推进之前，需求工程师有必要全局地研究所有的分析类图，视实际情况对它们进行必要的调整：
¨ 尽可能复用分析类的职责和属性。
ü 如果两个分析类A和B具有相同或相近的职责，区分两种情形：A将此职责委托给B，A自身并不实际完成此职责；A和B均实际完成此职责。在第一种情形下，A和B勿需调整，但必须存在一条从A指向B的通道以便传递“委托”消息；第二种情形必须调整为第一种情形，或者，在不损害用户需求的完整实现的前提下，将此职责从A、B二者之一中剔除。
ü 利用面向对象中的继承和代理机制实现多个分析类之间对职责和属性的共享。详见“1.3 面向对象的复用”。
¨ 调整分析类的归属包。
ü 如果一个包中的分析类很多，单张分析类图复杂得难于理解，可以考虑进一步将此包划分为多个子包，针对每个子包绘制分析类图。
ü 如果多个包中存在职责、属性相同或相近的分析类，可以考虑将它们合并为一个分析类，将其置入新设的公共服务包之中。如果合并行不通，也可以考虑将公共的职责、属性抽取至新设的服务类，原分析类利用继承或代理机制共享新的服务类；同样，新的服务类也应位于新设的公共服务包。
ü 基于强内聚、松耦合原则，调整分析类所属的包。
在分析类图构造完成后，应记录类图中各个类与用例模型的追踪关系，追踪关系的记录和表示方法见“3精化领域概念模型”。这里应注意的是：
(1) 在领域概念模型的追踪关系表的基础上，进行精化，形成分析类图的追踪关系表。
(2) 在分析类图中，如果类的某项职责来源于交互图中的某条消息，则该类应该追踪至对应于此交互图的用例。
(3) 在分析类图中，如果从类A到B之间存在直接的消息传递通道，则A应该追踪至导出该通道的交互图所对应的用例。
(4) 同理，在一个类所能追踪到的用例集合中，应该包含作为其属性的需求来源的用例。
7 构造状态图
一般并不强制要求需求工程师在分析活动中创建状态图。状态图的创建可以推迟至软件设计阶段。但是，如果状态图有助于明确某种实体的状态转换行为或“状态－事件－响应”行为，以状态图显式刻画这些行为有助于需求工程师厘清问题、分析需求，剔除需求描述中的模糊性、不一致性、不完整性，那么在需求分析阶段针对关键性的实体绘制状态图就有其必要性。需要特别指出，针对实时系统和嵌入式系统的软件开发，状态图是需求分析的有效手段。
有关状态图的具体构造方法，请见“2.5 状态图”，这里不再赘述。
为了讨论状态图与用例模型之间的追踪关系，有必要回顾“2.5 状态图”中阐述的作为状态图描述对象的四种实体：类的典型对象，软构件，软件系统（子系统），以软件为部件的系统。如果以UCS表示某状态图可追踪的用例集合，那么，在第一种情况下，UCS等于相应类可追踪到的用例集合；在第二、三种情况下，UCS分别等于在软构件、软件子系统中包含的每个类可追踪到的用例集合的并集；在第四种情况下，UCS等于用例模型中所有用例的集合。在实际应用中，需求工程师可以视实际情况对此规则给出的UCS进行适当的调整，例如，从UCS中删除确与状态、状态变迁无关的用例。
8 构造活动图
与前述的“构造状态图”一样，仅当活动图有益于需求分析时，此步骤才有必要。在构造活动图的过程中，需求工程师必须避免过早陷入业务逻辑处理和实现的细节，只要借助活动图使需求得以明确表述即可，进一步的细化应该留待设计和实现阶段再予考虑。
有关活动图的具体构造方法，请见“2.6 活动图”，这里不再赘述。
需求分析阶段的活动图主要用于描述：软件系统与外部实体共同参与的业务处理流程；多对象（或多个子系统、多个构件）协同的单个用例中的处理流程，或者多个用例联合起来形成的处理流程。如果以UCS表示某活动图可追踪的用例集合，那么，在第一种情况下，UCS等于作为业务流程中动作的来源的用例构成的集合；在第二、三种情况下，UCS等于活动图对应的用例构成的集合。
9 构建快速原型
简单地说，原型是待开发目标软件系统的一个可操作模型，它实现了目标软件系统的某些重要方面。在软件开发过程中，原型为管理人员、开发人员和用户交流信息、讨论问题以及进行技术决策提供了可操作的模型。
为精确地理解问题域、确定用户需求并发掘潜在的用户需求，分析人员可以生成探索性原型。这类原型是问题域中某些子系统或用户需求的某些子部分的可操作模型，它不涉及软件的具体实现方法。其主要作用是澄清应用领域和用户需求的某些疑难问题，并方便用户对开发人员的需求分析工作进行评价、纠错和确认。为简化问题以便快速生成原型，在分析复杂软件项目的用户需求时，可考虑针对不同的疑点生成多个原型，不要试图用一个复杂的原型来解决所有的需求分析问题。
对于重要的用户目标，分析人员可以生成实验性原型以验证问题求解方案的可行性，比较各种方案的优劣，并征询用户对这些方案的功能和性能的意见。显然，最终被用户和分析人员共同选中的求解方案的原型实现可以进化为目标软件系统的一部分。与探索性原型类似，开发人员可以针对各个用户目标分别生成原型进行试验。
如果原型不仅用来理解问题、试验求解方案，而且用作目标软件系统的基础，并在后续开发过程中逐步进化为最终的软件产品，这类原型称为进化性原型。与探索性和实验性原型相比，进化性原型的设计需要更周密、更长远的技术考虑，其软件结构应该具有更好的可扩充性，从而为后续的进化提供方便。在基于进化性原型的软件项目中，对原型的不断改进和丰富构成软件开发的核心过程。此时，用户对原型的评价意见和改进要求对后续的原型进化起着决定性的作用。开发人员应该与用户密切配合，充分尊重用户的合理意见，满足用户不断变化的需求，从而最终生成令用户满意的软件产品。
以上按照原型在软件开发过程中的不同作用划分为探索性、实验性和进化性三类原型。这种划分为开发人员针对不同的软件开发目标如何选用快速原型方法提供了指导性建议。具体的快速原型构造过程大致如下：
STEP1：分析与规划
当初次建立原型时，利用本章介绍的需求获取与分析方法，生成一个简化的需求规格说明；当针对已有原型构造新的更为丰富和完善的原型时，必须将用户对已有原型的评价意见、改进建议以及对新原型的需求进行分析，生成新的需求规格说明。在此分析过程中，可以借助用户界面情景板和已有的原型来理解应用领域、提高用户参与程度、剔除用户需求中的片面性、模糊性和不一致性。尤为重要的是，在构造快速原型的需求工程阶段，开发人员必须善于区分用户目前较为急迫的需求和对将来软件系统的希望，并将注意力集中于重要的、紧迫的需求，其他的用户期望则留待以后的进化阶段处理。这就是说，不要指望一次进化就能使原型从“婴儿期”迈入“成年期”，而应区分轻重缓急，逐步进行。
在本次原型创建或进化的软件需求基本明确以后，开发人员要着手设计原型的总体结构，进行任务划分、进度安排，并初步规划新原型的进一步进化。需要强调的是，进化性原型的总体结构应该具有尽可能好的可扩充性，未列入本次进化目标的用户需求应安排在后续的进化阶段予以实现，当前阶段应为后续进化提供便利。
STEP2：设计与实现
针对前面得到的软件需求进行软件设计、编码、调试和测试。本书介绍的所有软件工程技术和管理方法都可以在这里使用。快速原型的实现过程特别强调CASE工具的使用，以便尽快实现原型。
在原型实现过程中，对代码效率不宜有苛刻要求，除非当前原型将作为最终软件产品。软件设计方案和源程序的可读性与可扩充性应该成为原型实现阶段的重要目标。
STEP3：检查与评审
检查原型是否实现了分析和规划阶段提出的目标，邀请用户实际操作该原型，要求用户进行评估，提出改进意见和进一步的需求。典型地，如果用户评价说“我不喜欢这种操作方式”，那么开发人员应该追问“您不喜欢这种操作方式中的哪些部分，为什么？什么样的操作方式最好？”。又如，开发人员可以通过用户对下述问题的回答来收集改进意见：“如果将该原型投入应用，还要添加哪些功能?哪些方面尚需进一步加强？”，等。
STEP4：改进
快速原型方法不仅要求软件原型不断改进和完善，也要求开发人员在原型进化的过程中不断积累有关应用领域的知识，提高对用户需求的理解程度，改进专业技能。同时，还要求用户利用原型逐步理解目标软件系统的运作方式。在每一进化阶段的末尾，开发人员应该认真反思所有重要的决策过程，评价自己采用的技术和方法，根据前面检查阶段得出的结论总结经验教训。这样不仅有利于后续的原型进化，而且也有利于开发人员将来可能参与的其他软件开发项目。
如果要对原型进一步改进，那么开发人员携带检查阶段形成的文档（用户提出的改进意见及进一步需求）和经本次进化获得的经验教训进入下次原型进化的分析与规划阶段。
10 评审分析模型
需求工程师、软件设计师、项目软件经理、用户和业务专家一起正式地评审迄今为止需求分析阶段的所有工作成果，包括基于UML的分析模型（含分析类图、交互图、状态图、活动图），需求追踪表，以及需求优先级、可行性分析结论，其中分析模型是被评审的主体对象。评审方法与需求获取阶段的评审方法虽然类似，但两种评审也有一些差异：
(1) 分析模型评审的主要关注点除模型的一致性、精确性和完全性外，还应包括分析模型相对于用例模型的一致性，以及分析模型面向软件设计师的可理解性、详略恰当性。
(2) 相对于用例模型，基于分析模型更易构造可实际运行的快速原型。所以，分析模型评审更适于采用快速原型法。
(3) 在分析模型评审过程中应充分利用分析过程中记录的分析决策，判断这些决策的合理性，基于这些决策理解、评审分析模型。
(4) 用户和业务专家在分析模型评审中的作用相对弱化，因为他们可能难于理解分析模型中的技术性内容。但是，在解惑、仲裁、预期实现效果评价等环节，他们仍可发挥重要作用。此外，如果采用快速原型法进行分析模型评审，用户和业务专家也可以基于原型所演示的分析模型的外在效果更深入地参与评审。
5 分析活动的输出制品
需求分析活动的输出制品包括：分析模型，需求追踪表，需求优先级、可行性分析结论，分析决策，新版的工作计划。如果在分析阶段构造了快速原型，那么输出制品还包括此原型。因为原型不仅可用于需求分析，也可作为后续的设计、实现活动的有益参考，甚至有可能以此原型为基础开发出最终软件产品。
6 分析活动的出口准则
需求分析活动的出口准则是：“4 需求分析”开篇所述的的需求分析的目标已达到，并且输出制品已经通过评审。
7 分析活动小结
需求分析的主要技术工作是基于用例模型构建以分析类图、交互图、状态图和活动图为主体的分析模型，建立需求追踪表，并完成需求项的优先级分析和可行性分析。相比于需求获取阶段获得的用例模型，分析模型为软件设计和实现奠定了更好的基础，提供了更多的支持。
除技术活动外，在需求分析过程中，软件质量保证工程师应当并行地检查、评审需求分析的过程和输出制品，以便及时发现过程与输出制品中可能存在的质量缺陷。
参与需求分析活动的角色及其职责见表16。
表16 参与需求分析活动的角色及职责
| 角色 | 职责 |
| 需求工程师 | (1) 分析需求的质量属性； (2) 确定需求优先级； (3) 建立分析模型； (4) 构建快速原型； (5) 参与评审分析模型。 |
| 软件设计师 | 参与评审分析模型。 |
| 项目软件经理 | (1) 在需求工程师进行分析决策时提供指导或做出最终决定； (2) 主持分析模型的评审。 |
| 用户（客户） | (1) 在需求工程师进行分析决策时提供咨询； (2) 评估快速原型。 |
| 系统工程师 | (1) 在需求工程师进行分析决策时提供咨询； (2) 评估快速原型。 |
| 质量保证工程师 | (1) 检查需求分析的过程； (2) 参与评审分析模型。 |
需求分析活动可以表示为图29所示的工作流。
图29 需求分析工作流
5 需求规范化
需求规范化的目标是，在需求分析的输出制品的基础上，按照项目事先选定的需求规格说明书的模板，形成正式的需求规格说明。需求规格说明必须面向所有利益相关者，清晰地呈现待开发的目标软件产品的预期功能和非功能性约束。
需求规格说明书的主要内容包括：
(1) 系统概述
(1.1) 文档概览：文档的结构、每部分的内容简介；文档的读者对象及阅读顺序导引。
(1.2) 术语定义：本文档中使用的所有术语、缩写、标识符的完整定义。
(1.3) 系统简述：对目标软件产品所处的系统的概要描述。如果产品的独立性很强，此节可以省略。
(1.4) 软件产品描述：软件产品的目标、范围、业务价值；产品与其所处的系统之间的关系；产品对运行环境的要求。
(1.5) 用户特征：预期使用本软件产品、验收本软件产品的所有用户（客户）的分类及每类用户的特征描述。
(1.6) 设计和实现约束：用户要求中影响本软件产品的设计和实现的约束条件，例如，用户要求必须采用J2EE[6]中间件平台，软件设计和实现过程中必须采用的技术规范或标准，硬件资源限制，等。
(1.7) 假设与依赖：在需求获取、分析过程中采信的、经过用户确认的所有假设，以及本项目与其他项目或者外购产品之间的依赖关系的描述。
(1.8) 参考文献：本文档引用的标准、相关的本项目的其他技术文档、参考文献。
(2) 功能性需求：以用户易理解的方式组织软件产品的功能描述，包括每项功能的标识、描述、优先级、使用场景等。用例模型和分析模型是功能性需求的主要内容，它们可以直接出现在需求规格说明的功能性需求描述部分，但是，出于篇幅上的考虑，也可以将它们置为需求规格说明中的附录，从功能性需求描述部分引用附录中的模型。
(3) 非功能性需求：用户在性能、可靠性、易用性、安全性、可保障性等方面的需求描述，详见本章的开篇部分。
(4) 界面需求：用户界面情景板或界面原型的描述。
(5) 接口定义：本软件产品与其他软件、运行环境、外部系统之间的接口定义。
(6) 需求验收方法：定义本文档所列的所有需求项的验收方法。
(7) 需求来源表：每项功能性、非功能性需求的来源的描述。
需求规范化活动的主要参与者包括：文档支持工程师、需求工程师、测试工程师、质量保证工程师、配置管理工程师。其进入准则是：
(1) 需求获取及分析活动的输出制品已就绪。
(2) 需求规格说明书的文档模板已就绪。
(3) 文档支持工程师（经过必要的培训）已具备撰写需求规格说明书所必需的技术及写作技能。
需求规范化活动是在需求获取和分析活动的工作成果的基础上展开的，其输入制品是获取活动和分析活动的输出制品的并集。在所有这些输入制品中，用例模型和分析模型最重要。
需求规范化的主要工作是整理需求获取和分析活动的工作成果，形成正式的需求规格说明书。其主要工作步骤如下：
(1) 按照需求规格说明书模板撰写需求规格说明。在此过程中可以根据项目的实际情况对模板进行适当的裁剪或扩充。
(2) 整理需求追踪关系。基于需求分析活动给出的需求项标识，指明每项需求在需求规格说明书中的对应位置。必要时可适当调整需求分析活动给出的需求项标识和需求追踪表。
(3) 将需求规格说明书置于配置管理的控制之下。
除技术活动外，在需求规范化过程中，软件质量保证工程师应当对需求规格说明书模板的采用、裁剪、扩充进行认可，同时，并行地检查、评审需求规格说明书，以便及时发现过程与输出制品中可能存在的质量缺陷。
需求规范化活动的输出制品为需求规格说明书。在提交给软件设计活动之前，需求验证活动将对需求规格说明进行评审、调整。经过验证后的需求规格说明将成为软件设计、实现和测试活动的主要依据。
需求规范化活动的出口准则是：
(1) 需求规格说明书已撰写完成，并且通过了参与需求获取、分析活动的所有需求工程师的审核；
(2) 需求规格说明书已经置于配置管理的控制之下。
参与需求规范化活动的角色及其职责见表17。
表17 参与需求规范化活动的角色及职责
| 角色 | 职责 |
| 文档支持工程师 | 撰写需求规格说明书。 |
| 需求工程师 | (1) 指导文档支持工程师的工作； (2) 审核需求规格说明书。 |
| 测试工程师 | (1) 指导文档支持工程师撰写需求规格说明书中有关需求的测试、验证的部分； (2) 审核上述部分。 |
| 质量保证工程师 | (1) 认可需求规格说明书模板； (2) 审核需求规格说明书。 |
| 配置管理工程师 | 对需求规格说明书进行配置管理。 |
需求规范化活动可以表示为图30所示的工作流。
图30 需求规范化工作流
6 需求验证
需求验证的目标是，确保需求规格说明书真实、准确、全面地反映了用户的所有需求。为达成此目标，软件项目的利益相关者必须参与需求验证活动，通过文档评审检查需求描述的一致性、完全性、精确性、可行性、可测试性等质量属性（参见“1 分析需求的质量属性”），并在所有利益相关者之间就软件需求达成一致。
需求验证活动的主要参与者包括：用户（客户）、项目经理、项目软件经理、质量保证工程师、系统工程师、软件设计师、测试工程师、配置管理工程师、需求工程师。其进入准则是：待验证的需求规格说明已经置于配置管理之下。
需求验证活动的输入制品是来自配置库的需求规格说明书。
需求验证的主要步骤如下：
(1) 需求评审。首先提出评审申请，规划评审的参与者、评审组织方式（会议评审、会签评审等）、时间安排等。为避免评审流于形式，评审组织者应该提前一段时间将评审通知、评审要求、需求规格说明书等通知所有参与者。需求评审的主要关注点包括：
¨ 需求的质量属性（详见“1 分析需求的质量属性”）；
¨ 需求项实现的风险评估；
¨ 需求优先级的设定是否合理；
¨ 是否存在无来源的需求项，需求项的来源是否得到用户或系统工程师的认可。
(2) 问题整理。记录需求评审过程中发现的所有问题（缺陷）并文档化，将此文档置于配置管理的控制之下。
(3) 问题求解。针对每一问题安排责任人和改正时间，责任人实际修改需求规格说明书。
(4) 达成一致。所有利益相关者，尤其是用户（客户）与软件开发方之间，就是否通过（修改后的）需求规格说明书的评审达成一致意见。通过评审的需求规格说明书将成为客户与软件开发方之间契约的一部分。
(5) 建立基线。将（修改后的）需求规格说明书置于基线管理控制之下。
需求验证活动的输出制品是通过评审的需求规格说明书。它是整个需求工程阶段的最终输出，将成为软件设计、实现和测试活动的主要依据。
需求验证活动的出口准则是：需求规格说明书已通过评审，评审过程中发现的所有问题均已解决，并且需求基线已经建立。
参与需求验证活动的角色及其职责见表18。
表18 参与需求验证活动的角色及职责
| 角色 | 职责 |
| 用户（客户） | 评审需求规格说明书。 |
| 项目经理 | 评审需求规格说明书。 |
| 项目软件经理 | (1) 主持需求规格说明书的评审； (2) 必要时，针对评审中发现的部分问题，管理其解决方案的实施。 |
| 质量保证工程师 | (1) 审查需求评审申请； (2) 评审需求规格说明书； (3) 跟踪评审中发现的所有问题直至解决。 |
| 系统工程师 | 评审需求规格说明书，重点关注系统分配至软件的需求是否在说明书得到恰当的体现。 |
| 软件设计师 | 评审需求规格说明书，重点关注说明书的可理解性、一致性、精确性、可行性。 |
| 测试工程师 | 评审需求规格说明书，重点关注说明书的可测试性和其中的测试场景。 |
| 配置管理工程师 | 对需求规格说明书进行配置管理，建立需求基线。 |
| 需求工程师 | (1) 参与评审需求规格说明书，在评审过程中进行必要的解释或说明； (2) 解决评审中发现的所有问题。 |
需求验证活动可以表示为图31所示的工作流。
图31 需求验证工作流
7 需求管理
需求管理是指对需求开发、需求实现和需求变更过程进行监督和控制的一系列活动和过程，其目标是：
(1) 在用户和软件项目组之间建立对软件需求的共同理解；
(2) 软件需求成为后续的软件开发和管理活动的基本依据，即，项目计划、活动和工作产品应该与软件需求协调一致；
(3) 需求变更受到管理和控制，即，需求变更必须按照事先定义的变更控制规程进行影响分析、评审或审批，需求变更必须获得所有利益相关者的认可，受影响的计划、活动和工作产品必须相应调整。
7.1 管理活动的参与者
需求管理活动的主要参与者包括：项目软件经理，需求工程师，配置管理工程师，质量保证工程师，以及所有受到需求变更影响的利益相关者。其中项目软件经理是需求管理职责的主要承担者。所有参与者的职责描述详见“7.7 管理活动小结”。
7.2 管理活动的进入准则
需求管理与需求策划活动同步启动，因此其进入准则与需求策划相同。
7.3 管理活动的输入制品
如前所述，需求管理活动包括需求工程管理、需求实现管理和需求变更管理三个方面。需求工程管理活动的主要输入制品包括需求策划活动得出的工作计划、需求获取活动得出的用例模型、需求分析活动得出的分析模型、需求规范化活动得出的需求规格说明书。需求实现管理活动覆盖软件设计、构造、测试等阶段，其主要输入制品包括需求规格说明书和这些阶段的主要工作成果，例如设计规格说明书、程序代码结构、测试报告等。需求变更管理的主要输入制品为需求变更申请书。当然，需求管理活动并不要求这些输入制品在活动启动前就绪，只要在需求管理过程中及时提供即可。
7.4 需求管理的任务与方法
为便于需求管理，软件需求不应该是铁板一块式的长篇大论，而应该表示为一种以需求项为节点的结构，需求项之间可以存在关联或包含关系。需求项代表软件需求中某项相对独立的用户期望或约束。需求项包括功能性需求项和非功能性需求项，前者直接对应于用例，后者的内容一般不会太复杂，以简练的自然语言进行描述即可，见表10。需求工程师负责提取、定义软件需求项及其属性。软件需求项的完整属性清单见表19。软件需求项是需求管理的主要对象，因此，可以考虑采用某种软件工具统一管理软件项目的所有软件需求项及其属性，以便更高效地展开需求管理工作。
表19 软件需求项的属性
| 属性名称 | 说明 |
| 名称* | 以简洁的名字描述软件需求项的内涵。例如，对功能性需求项，往往采用用例名作为对应的需求项的名称。 |
| 标识 | 以分层编码的形式在整个软件项目的范围内唯一地标识本项需求。例如，“2.6”表示顶层第2项需求的第6项子需求。 |
| 来源* | 本项需求的来源。 |
| 优先级 | 参见“2 确定需求优先级”。 |
| 稳定性 | 本项需求保持不变的可能性。 |
| 风险 | 在实现本项需求的过程中可能存在的风险因素及其应对措施。 |
| 状态* | 本项需求的当前状态。参见图32。 |
| 父需求项 | 包含本项需求的粒度更大的需求项。利用此属性，可以将一个软件项目的需求项组织为类树形结构。 |
| 相关需求项 | 与本项需求处于相同层级，与本项需求具有强相关性的需求项列表。 |
| 验收准则 | 验证本项需求已实现的方式和标准。 |
| 变更历史* | 本项需求的内容发生变更时，必须记录变更的日期、原因、内容及影响分析结论。参见“7.3 需求变更管理”。 |
| 版本号* | 当需求项的内容发生变更时，必须按照某种规则递增版本号。可以考虑将“标识”属性与“版本号”属性合并。 |
| 提出人 | 提出本项需求的需求工程师。 |
| 负责人 | 对本项需求的实现负有主要责任的人员。 |
| 决策人 | 批准本项需求的内容或状态发生变化的需求管理者。 |
说明：所有需求项均须具备带“*”的属性，其他属性可酌情取舍。
本小节的后续部分按需求工程管理、需求实现管理和需求变更管理的次序分别介绍需求管理的任务和完成这些任务的大致方法。
7.1 需求工程管理
需求工程管理的主要任务包括：
(1) 需求工程计划执行的跟踪与监督。需求管理者必须定期检查需求工程策划阶段生成的工作计划（见“2 需求工程策划”），对于进度滞后超过预设阈值的需求工程活动，必须深究其原因，针对原因采取纠偏措施，并督促措施的落实。
(2) 需求来源的确认。针对每个软件需求项，需求管理者负责核对其来源，并评价来源的合理性、稳定性。软件需求项的来源主要有：用户（客户），系统需求项，当前及未来改进的业务处理流程，来自用户的规章制度、业务规范、行业标准等。需求管理应尽量确保不存在无来源的软件需求项，也不存在来源未经核对、未经确认的软件需求项。
(3) 需求评审的监管。需求管理的重要任务之一便是防止需求评审流于形式。为此，需求管理者必须检查评审组是否足以代表所有重要的利益相关者（见“2 需求工程策划”），必须查验需求评审流程的合理性、需求评审检查单（checklist）的合理性和完整性、本次需求评审与组织规定的流程之间的符合性等。软件质量保证工程师必须对评审中发现的所有问题进行跟踪，直至问题得到彻底的解决。
(4) 需求追踪。针对需求获取阶段得到的所有需求项，需求管理者负责标识其来源及其与分析模型中某些元素（例如分析类、交互图、状态图、活动图等）之间的追踪关系。前者（从需求项到来源之间的追踪）称为逆向追踪关系，后者（从需求项到分析模型）称为正向追踪关系。它们通常表示为需求追踪表，参见表15。
7.2 需求实现管理
软件需求的实现是指，以可运行的程序代码来满足软件需求在功能、性能或其他约束条件等方面的要求。它通常必须经历软件设计、软件构造和测试等环节。因此，需求实现管理实质上是指在需求工程之后的软件开发过程中对软件需求的遵循性管理，其主要任务如下：
(1) 需求基线管理。如“6 需求验证”所述，通过评审的需求规格说明书（以及其中包含的所有软件需求项）应该置于基线管理控制之下，即，在需求实现的过程中，必须以需求基线确定的软件需求为基础和依归，对需求内涵的变更必须遵循严格的基线变更控制规程（见“3.9软件配置管理”和“7.3 需求变更管理”）。
(2) 需求状态管理。随着软件开发过程的展开，软件需求项的状态是不断变更的。需求项的状态包括“提出”、“已接受”、“已设计”、“已实现”、“已测试”、“已交付”，以及“已拒绝”、“已取消”。这些状态之间的变迁关系见图32。在需求实现的过程中，应该定期或事件驱动地（在某些重要阶段结束或需求项目状态变更时）汇总需求项状态信息，以此作为进度监控、风险评估等软件项目管理活动的重要依据。
(3) 需求追踪。虽然与需求工程管理中的需求追踪关系的表示方式相同，但是，这里的需求追踪关注软件需求项与设计元素、软件代码块、测试用例之间的追踪关系。这种追踪可以在相邻两个软件开发阶段之间逐级展开，也可以越级展开。后者可以由前者复合推导而出。例如，可以由需求项A追踪至分析类M和N，再由M追踪至设计类X，N追踪至设计类Y和Z，从而推导出由A可追踪至X、Y和Z。必须指出，直接标示需求项与软件设计/实现要素之间的关系可以强化需求的指导作用，避免在软件开发过程中出现无效劳动（开发没有任何需求依据的软件元素）和错误劳动（开发明显偏离需求的软件元素）。
图32 需求项状态及其变迁关系
7.3 需求变更管理
需求变更受到管理和控制是需求管理的主要目标，因此，变更管理在需求管理中占有十分重要的地位。其主要任务如下：
(1) 预先建立需求变更控制规程。该规程至少应包括需求变更申请、变更影响分析、变更评审、变更执行等环节。规程应明确参与这些环节的执行者的职责。允许结合项目和需求变更的具体情况对该规程进行适当的裁剪，例如，针对轻微的需求变更，参与人数可以减少，审批权限可以下放，但是基本环节不宜删减。
(2) 需求变更申请。说明需求变更的内容、理由，并对需求变更的影响波及范围进行分析，包括对已有及未来的软件工作产品的影响，对工作计划、项目进度、成本的影响等，在此基础上预估需求变更引起的工作量。
(3) 需求变更影响分析。在需求管理者的主持下，以需求变更申请单为输入，需求变更的受影响者或其代表共同对需求变更的影响波及范围进行更系统、更深入的分析，对需求变更引起的工作量和成本增加进行更精细的预估，形成一致的分析结论。该结论不仅是需求变更评审的基础，更是软件项目管理者在决定是否批准需求变更时的主要依据。需求变更的典型影响波及点包括：对用户的承诺，软件设计模型及设计规格说明，测试计划及测试用例，程序代码，内部及外部接口，用户手册、帮助文档、用户培训教程；项目开发计划（含任务安排和进度安排），质量保证计划，配置管理计划，风险分析及应对方案等。由此可见，需求追踪是需求变更影响分析的重要基础。
(4) 需求变更评审。核查需求变更的技术可行性、影响分析的全面性，决定是否同意实施需求变更。如果需求变更影响到软件项目的对外承诺（例如，导致合同条款的变化），必须要由软件开发组织中拥有足够权限的管理者正式批准后，才能开始执行需求变更。
(5) 需求变更执行。修改需求规格说明（及其包含的需求模型），修改需求变更影响波及范围中的各种软件工作产品，调整软件开发计划以为需求变更安排适当的资源（包括时间资源）。
7.5 需求管理活动的输出制品
需求管理活动的输出制品包括需求项状态表、需求追踪表，以及需求变更过程中产生的需求变更申请及评审表（其中包括影响分析结论、评审结论、批准人、执行人等信息）。前两张表在需求实现的过程中是不断变化的。
7.6 管理活动的出口准则
策划活动的出口准则为：
(1) 所有需求项的状态为“已交付”、“已拒绝”或“已取消”。
(2) 所有需求变更已执行完毕，并且没有进一步的需求变更要求。
7.7 需求管理活动小结
参与需求管理活动的角色及职责如表20所示。
表20 参与需求管理活动的角色及职责
| 角色 | 职责 |
| 需求工程师
| (1) 需求来源的确认； (2) 需求追踪； (3) 需求状态管理； (4) 需求变更申请； (5) 需求变更影响分析； (6) 需求变更执行。 |
| 项目软件经理 | (4) 需求工程计划执行的跟踪与监督； (5) 需求评审的监管； (6) 建立需求变更控制规程； (7) 需求变更评审。 |
| 软件开发组织的相关领导 | 批准影响对外承诺的需求变更。 |
| 软件配置管理工程师 | 需求基线管理。 |
| 用户 系统工程师 软件质量保证工程师 | 参与需求变更评审。
|
| 测试工程师 软件设计师 软件实现工程师 | (1) 参与需求变更评审； (2) 需求变更执行。 |
