我们将需求工程划分为两个主要部分：需求开发 1和需求管理。
需求开发： 这部分涵盖了从软件项目中识别、理解并明确客户需求的全过程，包括收集需求（获取）、仔细研究这些需求以确保其合理有效（分析）、将需求清晰详尽地写入文档（规格说明），以及确认它们准确无误（验证）。在这一阶段结束时，通常会产生一系列关键文档，如项目概述与范围说明书、使用场景文档和详细的软件需求规格书，同时可能还包括一些辅助分析模型。一旦这些文档经过评审 2并获得批准，它们就构成了“需求基线”，这是客户和开发团队对产品功能需求和非功能需求共同认可的一个基准。尽管工程项目中还涉及其他方面的约定，例如交付物要求、约束条件、时间安排、预算限制以及合同条款等，但这些不在本文探讨之列。
需求管理： 作为需求开发之后的关键环节，需求管理更像是维护需求稳定性和精确性的桥梁。它涵盖了所有确保需求约定在整个工程周期内保持同步更新和控制的活动，如下所示：
- 控制需求变更：对已确立的需求基线 3进行严格的变更控制。
- 保证计划与需求相符：确保项目计划始终与当前需求保持一致。
- 版本控制：对单个需求及其相关文档实行有效的版本管理。
- 依赖关系管理：理顺需求之间或需求与其它项目产出物之间的关联和依赖关系。
- 追踪需求状态：实时跟踪需求基线中各项需求的状态变化。
本文着重介绍了需求管理的基本原则及其实践方法。
1 需求管理和过程能力成熟度模型
过程能力成熟度模型（CMM）对于提升需求管理的质量和效率是一个非常实用的指导工具。这一概念最初由美国宾夕法尼亚州匹兹堡市卡内基梅隆大学下属的软件工程研究所提出。CMM模型在软件开发行业中被广泛应用，旨在指导各类组织进行过程改进。
CMM将软件处理能力分为五个逐步递进的成熟级别。处于一级的组织往往采用非正式的方式管理项目进度，依赖于个别天才从业者或英雄式的管理者个人努力来获得成功。而在更高级别的成熟度上，组织则会结合富有创新精神且训练有素的员工，以及规范化的软件工程和项目管理过程，以实现持续稳定的成功。
要达到CMM的第二级，一个组织必须证明其在软件开发与管理的六个关键过程域中能够达到预设目标。其中，需求管理是不可或缺的一部分，它主要有两个核心目标：
- 建立需求基线：为软件工程和管理工作创建一套明确、可参照的需求基准。
- 保持一致性：确保软件计划、产品特性和所有活动都与软件需求保持紧密的一致性。
无论组织是否了解或关注过程成熟度模型，大多数软件开发团队都能从实现上述这两个目标中获益。CMM模型明确了达成这些目标所需的前提条件和技术策略，但它并不规定具体的需求管理过程，而是为组织提供一种持续改进的方法论框架。 需求管理的核心流程并不涵盖收集和分析项目需求的阶段，而是假设软件需求已经由上级系统或前期工作收集并确定。一旦需求被获取并整理成文档后，软件开发团队以及相关的质量保证、测试团队就需要对这些文档进行评审。如果发现问题，应及时与客户或其他需求提供方协商解决，并确保软件开发计划是基于已确认无误的需求制定的。
在向客户、市场部门或管理人员作出任何承诺之前，开发团队应先确认需求的可行性和相关约束条件（如进度限制、风险、不确定性因素及假设条件）。尽管可能因技术局限或时间压力而不得不应对一些看似难以实现的需求，但切勿做出明知无法兑现的承诺。
关键处理领域还强调了通过版本控制和变更控制来管理需求文档 4的重要性。版本控制确保任何时候都能明确了解当前开发和计划工作中所依据的需求版本；而变更控制则提供了一套标准化流程，根据业务和技术因素来审查和决定是否接受建议的变更。当需求发生变化时（包括修改、新增或删除），软件开发计划应当同步更新以保持与最新需求的一致性。不反映实际情况的计划是没有价值的。
若接受了某项需求变更提案，可能会发现它对项目进度或质量造成影响。此时，应积极与其他经理、开发者及相关组织沟通协商，采取以下策略来适应新的或变更过的需求：
- 优先级 5排序：暂时搁置相对次要的需求。
- 人力资源调配：获取额外的人力资源支持。
- 加班赶工：短期内安排有偿加班处理变更任务。
- 进度调整：将新功能纳入整体进度安排中。
- 权衡取舍：为确保按时交付，在必要时允许质量标准受到一定影响。
由于每个项目在功能特性、进度安排、人员配置、预算限制和质量标准等方面存在差异，因此，并不存在一个适用于所有情况的固定模板或方法。在项目的早期规划阶段，应根据项目风险承担者确定的优先级来选择合适的策略和方案。
无论面对变更的需求还是变化的项目环境，适时调整约定和计划是一种良好的工作习惯。这样做总比盲目地期待所有新增需求能在原定交付日期前奇迹般地实现，同时还不影响其他方面要实际得多。
即使你的团队目前并未采用CMM（能力成熟度模型）作为软件过程改进的指导框架，上述关于需求管理关键过程领域的原则和策略始终具有普遍适用的价值。任何开发组织都能够从这些方法的有效应用中获得好处。
2 需求管理步骤
开发组织应该明确界定项目团队管理需求的具体步骤，并将这些步骤文档化，以便所有成员能够持续高效地进行必要的项目活动。在定义这些步骤时，请考虑以下要点：
版本控制工具与实践：选择用于管理各种需求文档和单个需求版本的工具、技术和最佳做法。
需求沟通与协商流程：设计提出、处理、讨论并通知相关功能域关于新需求和变更的方法。
建立需求基线：详细说明如何制定和维护需求基线。
需求变更权限与状态记录：明确记录当前的需求状态以及由谁来批准需求变更。
需求状态跟踪与报告机制：描述如何实施需求状态跟踪及定期生成报告的过程。
变更影响分析步骤：列出分析已建议变动可能带来的影响应遵循的步骤。
需求变更对项目计划和约定的影响：阐述在何种情况下需求变更将会如何影响项目的进度安排和既定约定。
你可以把这些信息整合到一个综合文档中，或者根据主题不同分别撰写专题文档，例如独立描述变更控制过程、影响分析过程以及状态跟踪过程等。这些通用过程对于多个项目都具有参考价值，因为它们反映了每个项目在管理需求过程中应遵循的基本功 6能要求。
3 需求规格说明的版本控制
在最近的一次项目周会上，莎莉兴奋地宣布：“我刚刚完成了库存报告中重新排序功能的开发。”然而，项目经理回应道：“实际上，用户两周前就撤销了这个需求。你没查看更新后的软件需求规格说明书吗？”
这样的对话场景揭示了一个常见问题：为已废弃的需求付出努力会导致团队成员感到沮丧和浪费时间。例如，有一个开发团队在将改进的软件版本提交测试后，收到了大量的错误报告。原来，测试人员依据的是一个旧版的需求文档，这导致了一系列本可以避免的问题。最终，该团队不得不耗费大量时间排查问题，并按照最新版需求规格说明重复进行回归测试。
为了避免这类困扰和提高效率，对需求文档进行严格的版本控制至关重要。每个需求文档的版本都应当被明确标识和统一管理。团队每位成员都应能获取到当前有效的版本，同时，任何变更都应当记录清晰、形成文档，并及时传达给所有相关项目参与者。为了减少混淆、冲突与信息错漏，只应授权特定人员对需求进行更新。
每一份发布的需求文档版本内部，都应该包含修订历史记录，具体包括修改的内容详情、改动日期、执行变更的人员姓名以及变更理由。建议采用标准的编辑标记符号，如使用删除线表示内容删除，下划线代表新增内容，并利用页边空白处的竖线指示每一处变动的具体位置。尽管这些符号可能会影响文档的直观性，但现代支持修订模式的办公软件能够方便地预览和打印出带有或不带修订痕迹的文档版本。此外，还应为每个需求指定版本号，每次需求更改后，版本号随之递增。
## 需求版本控制的重要性
**对话实例**：
- 莎莉 : 我成功实现了库存报告重排序功能的开发！
- 项目经理: 不过，注意一下，这个功能两周前已被用户取消。你检查过最新的软件需求规格说明书吗？
**案例分析**：
某开发团队因未同步更新需求而陷入困境。他们在向测试阶段交付改进版本时，由于测试者参考的是过时的需求文档，导致接收到大量误报的错误。团队不得不投入大量时间来定位问题并根据最新规格说明书重新测试。
**版本控制策略**：
1. **明确版本标识**：确保每一个需求文档版本都有统一且明确的标识。
2. **实时获取与沟通**：团队成员必须能获取到最新版本的需求，并清楚记录变更，及时通知项目相关人员。
3. **权限控制**：仅允许特定人员负责需求更新，以降低混乱、冲突及信息传递错误。
**版本历史记录**：
每个公开发布的文档版本需附带详细的修订历史：
- 修改内容详情
- 变更日期
- 执行人姓名
- 变更原因
**修订符号规范**：
- 使用`~~删除的内容~~`表示移除部分
- 使用`**新增的内容**`表示增加部分
- 利用页面空白边缘的竖线（*例：|*）标示具体修改位置
**技术辅助**：
借助支持修订功能的字处理工具，可轻松预览和打印显示/隐藏修订痕迹的文档版本。
**需求版本编号**：
为每个需求打上版本号，每当需求有变更发生时，版本号即升级。版本控制的简单方式是手动按照标准规范为软件需求规格说明书的每次改动进行标记。由于依赖修改日期或印刷日期区分不同版本容易出错，所以不推荐这种做法。采用手工方法时，新文档的第一版应标记为“1.0草稿”，后续修订依次递增，例如“1.1草稿”、“1.2草稿”等，直至文档被接受为基线并标记为“1.0正式版”。小幅度修订可标识为“1.1正式版”，较大变动则升级为主版本，如“2.0草稿1”。这种方式虽能明确区分草案与正式版，但需要人工操作。
更高级别的版本控制可通过使用版本控制工具来实现，比如使用登录和检出机制管理源代码的配置管理工具（有许多商业选项）。以一个实际项目为例，他们使用Microsoft Word这样的工具管理数百份使用实例文档，每个成员都能查看到文档的历史版本，并通过日志记录每一次变更。在此项目中，需求分析人员拥有读写权限，而其他团队成员只能查阅文档。这个工具在该项目的版本控制系统中发挥了良好作用。
最强大的版本控制手段则是利用商业需求管理工具将需求存储于数据库中。这类工具能够跟踪并报告每个需求的完整变更历史，这对于未来可能需要恢复早期需求的情况非常有用。每当添加、修改、删除或拒绝某个需求时，附上变更理由的注释，在未来讨论时会提供宝贵参考信息。
4 需求属性
在定义功能需求时，除了文本描述外，每个需求还应关联一些关键信息或属性，以构建需求的完整上下文和背景环境。这些属性可以记录在纸质文档上，也可以存储于数据库或专门的需求管理工具中。商业级需求管理工具不仅自动生成一些标准属性，也支持用户自定义多种数据类型的属性。通过这类工具，您可以方便地对需求进行过滤、排序及查询操作，从而快速查看按照特定属性筛选出的需求集合。
对于大型复杂的项目，详尽丰富的属性类别至关重要。在编制每一个需求文档时，请务必考虑包含以下属性：
- 创建时间：记录该需求被创建的具体日期和时间。
- 版本号：标识需求当前所处的修订版本。
- 作者：明确指出创建该需求的人员姓名或ID。
- 批准人：负责认可并接受该需求的相关责任人。
- 需求状态：如“已批准”、“待讨论”、“已实现”等状态标签。
- 需求依据：阐述提出该需求的原因或背后的业务背景。
- 涉及子系统：列出该需求与之相关的具体子系统名称。
- 产品版本：指出该需求对应的产品版本号。
- 验证方法/测试标准：说明将采用何种方法验证该需求，或遵循何种测试标准来验收。
- 优先级/重要程度：可使用高、中、低等级别，或者根 收益、损失、成本、风险等维度自行定义相关属性。
- 需求稳定性：作为未来需求可能变更的指示器，不稳定的需求意味着需要更多关注，因为这可能涉及到不可预测、混乱或无法重复的业务流程。
定义和更新需求属性值是整个需求管理成本的一部分，但通过精心选择最相关且必要的属性子集，可以降低管理复杂性并提高效率。如果某些属性信息已经在项目开发跟踪系统或其他地方得到了妥善记录和同步，那么在需求数据库中就不必重复存储。
在整个软件开发生命周期中，持续监控和更新每个需求的状态是需求管理的核心任务之一。定期报告各个状态类别下需求的占比，有助于管理层了解项目的整体进展，并据此做出决策。为了确保需求状态变更的有效性和准确性，必须建立明确的规则，比如规定哪些人员有权修改状态信息，以及每次状态变更需要满足的条件。利用专业的需求管理工具，能够自动追踪每次状态变化的时间戳，极大地提高了管理效率。
建议的需求状态：
- 已建议：需求已被具备提出权限的人员正式提议。
- 已批准：需求经过了分析评估，考虑了其对项目其余部分的影响，并被分配到一个特定的产品版本或创建编号所对应的基线中；软件开发团队同意实现该需求。
- 已实现：已完成需求对应代码的设计、编写和单元测试阶段。
- 已验证：采用选定的方法（如测试）验证了已实现的需求，确认其符合预期并完成了相应的测试用例；此时，该需求被认为是已完成的。
- 已删除：原计划的需求从基线中移除，但保留了删除原因及其决策者的记录，以备后续追溯和审计之需。
5 度量需求管理的效果
在项目的工作分解结构中，需求管理活动应当明确为分配有资源的任务。评估当前项目中的需求管理成本是规划未来工作投入和预算的最佳方式。
对于从未量化过工程任何环节的组织来说，开始记录耗时工作可能会显得困难重重。但这需要文化上的转变和日常记录习惯的养成。实际上，计量工作量并不会消耗过多时间；了解团队成员在各个任务上实际花费的时间，将为您提供宝贵的信息。请注意，工作量计算并不直接与日历时间成比例，因为任务进度可能因中断、客户协商等因素而延误。每个任务的工作量以累计工时表示，这一数据不受外界因素直接影响，但总体上可能比预期计划要长。
跟踪需求管理的实际执行情况有助于判断团队是否采取有效措施进行需求管理。若需求管理执行不力，可能导致变更失控、范围蔓延和遗漏需求等问题，从而增加项目风险。考虑以下需求管理活动的效果：
- 提交需求变更及新需求建议
- 评估提出的变更及其影响分析
- 变更控制委员会相关活动
- 更新需求文档或数据库
- 沟通需求变更至相关人员或团队
- 跟踪并报告需求状态
- 定义与更新需求跟踪属性
尽管疏忽和效率低下难以完全避免，但通过有效管理项目需求，可以确保您在需求收集、归档和分析上的投入物有所值。高效的需求管理策略能让项目参与者在整个开发过程中及时获取需求的最新状态信息，从而缩小各方对需求理解的差距。
6 实践:
选择并使用合适的状态来描述功能需求在项目中的不同阶段。在软件需求规格书中明确标注每个需求的当前状态，并随着开发进度不断更新。
制定一个需求文档版本控制方案，将其详细写入文档，并作为需求管理流程的一部分执行。
记录下组织管理每个项目需求的具体步骤。让几位分析员共同参与起草、审查、试验并最终确定这些过程活动，确保它们切实可行、符合实际且对项目有积极促进作用。