需求改进过程
在实践应用需求工程中的好方法是改进软件过程的核心。改进过程包括使用更多有效的方法避免使用过去使用过的令人头痛的方法。然而，改进之路是从失败、错误开始，还要历经那些受影响人的抵制及因任务时间紧迫导致搁置改进这样的挫折。
软件开发过程的改进有两个主要目标：解决以前项目中或目前项目中遇到的问题，以及防止和避免将来可能遇到的问题。即使你目前采用的方法很有效，也应该知道其他一些很有价值也颇有效的需求工程方法，并把它们加入到你的软件工程中。
本文介绍了需求与其它主要的项目过程和风险承担者之间的联系，推荐了一种经改进的生存期，并列出了一些重要的需求“过程精华”。此外，本文还介绍了实施改进需求工程实践的一个流程蓝图，供参考使用。
1 需求与其它项目过程的联系
需求在软件项目中占据核心地位，它是整个项目生命周期中的基石，影响着从项目计划、开发、测试直至交付的各个环节：
制定项目计划：需求分析的结果直接影响项目计划的制定。通过对最终产品的深刻理解，项目团队能够准确估计开发资源和时间安排。在有限的资源和时间内，可能无法实现所有设想的功能，因此需要根据需求优先级 1确定项目范围，或者采用迭代或版本计划来选择实现哪些功能特性。
项目跟踪与控制：需求的状态监控是项目跟踪和控制的重要组成部分。项目经理通过监测需求实现情况，可以及时发现设计和验证是否达到预期标准。如果出现问题，会启动变更控制流程，对项目范围 2进行适当调整。
变更控制：一旦需求文档 3化并设立基线，后续的所有变更必须通过既定的变更控制过程进行管理。这一过程确保：
- 变更产生的影响在可接受范围内；
- 所有受影响的干系人均已知晓并理解变更；
- 变更由适当的决策者批准；
- 根据变更调整资源分配；
- 保持需求文档始终处于最新且准确的状态。
系统测试：用户需求和功能需求是系统测试的关键依据。测试团队根据清晰的需求说明来设计测试用例，以验证产品在不同条件下的预期行为。反过来，系统测试也可验证需求是否已按预期得以实现，并确保用户任务能够顺利完成。
用户文档编制：高质量的需求文档对编写用户手册和技术文档至关重要。需求不清晰或延迟会导致技术写作者在编写用户文档时面临巨大困难。需求文档为用户界面及性能的最终版本提供了基准，使得用户文档能够准确反映产品的实际功能。
软件构建：虽然软件项目的最终产出是可执行的软件，但需求文档是所有设计和实现工作的起点。设计团队依据功能需求来划分设计模块，模块设计则指导代码编写。通过设计评审 4确保设计正确反映了需求，并通过单元测试来验证代码是否满足设计规格要求及关联需求。在整个过程中，要跟踪每项需求与其对应的设计、代码模块之间的关系，确保软件产品的构建与需求相符。
2 软件需求对其它项目风险承担者的影响
在软件开发团队改变其需求管理过程时，与其他项目利益相关方的沟通接口也随之发生变化。这些接口对于项目内外部协作至关重要，涉及市场部门、管理层、系统工程部以及其他跨职能团队。为了确保接口操作顺畅，开发团队应主动与这些伙伴进行沟通，解释改进思路和计划，并强调新过程的优点，如减少问题、提高效率等。在寻求合作时，要诚恳地表达变更的原因，以及对所有人的潜在益处，以消除因未知引发的担忧和抵触。
在与各个功能领域的人员沟通时，明确指出需要他们提供的信息和支持，这对于产品开发的整体成功至关重要。遵循开发团队与其他团队之间标准化的交流接口规范，例如系统需求规格说明、市场需求文档等，并确保这些文档不仅符合严格的编写标准，还能传达客户真正关心的信息。
同时，也要询问其他团队需要从开发团队获取哪些信息和帮助，以便他们更好地履行职责。例如，了解技术可行性信息如何帮助市场部门制定更精准的产品计划，什么样的需求状态报告能让管理层更准确地掌握项目进度，以及与系统工程部如何协作以确保系统需求在软硬件之间的合理分配等。
在推行需求过程变更时，难免会遇到来自团队内部或外部的抵触和阻力。面对这种情况，首先要理解并尊重反对意见，通过充分沟通和解释来化解。例如：
针对变更控制过程可能被视为阻碍变更的看法，要阐明其实质是一个有序且结构化的变更途径，有助于决策者做出更明智的选择。确保新的变更过程确实有效，否则团队可能会寻找变通方法避开它。
针对开发人员将撰写和审查需求文档视为繁文缛节，耽误编程时间的看法，要强调前期扎实的需求工作可以大大减少后期因需求不明确导致代码重构的巨大成本。
如果客户支持成本并未与开发过程挂钩，开发团队可能缺乏改进的动力，因为他们不会直接承受产品质量低劣带来的财务损失。若改进需求过程的目标是通过打造高质量产品减少技术支持费用，提供技术支持的管理者可能会感到威胁，因为这可能会影响到他们所在的部门规模和重要性。在这种情况下，应明确指出高质量产品可以提升整体业务表现，长远来看对所有人都是有利的。
3 软件过程改进的基础
本文鼓励你在需求工程中进行持续不断的改进，遵循以下四个基本原则以提升软件开发的质量和效率（Wiegers 1996a）：
循序渐进和持续改进：改进过程应是逐步、深入且持续的，不应急于一次性彻底变革整个流程。首次尝试改变时，可能无法做到尽善尽美，因此应从某一两个关键过程着手，积累经验后再逐步调整方法。要接受并适应改进过程中的不完美，逐步完善。
激励驱动的变革：人们和组织通常在感受到强烈激励时才会接受变革，而痛苦的经历往往是最大的激励来源。这里的痛苦并不是指刻意制造的压力，而是指过去项目中因需求问题导致的真实困难。例如，项目延期、开发后期发现需求 5误解导致返工、系统测试无效、虽功能完备但用户体验差、高昂的维护费用源于需求遗漏、以及交付不符合客户期望的产品导致声誉受损等。这些痛点可以作为改进需求过程的强大动力。
目标导向的改进：在采用更高级别的过程之前，明确改进的目标至关重要。这可能包括减少因需求问题导致的返工、更好地管理需求变更 6、确保不遗漏任何需求等。拥有一份明确的实施路线图有助于在改进过程中取得成功。
将改进作为小项目来管理：很多改进活动之所以未能成功，常常是因为缺乏规划或者未能获得必要的资源支持。为了避免此类问题，应将每个改进活动视为一个小项目，将其所需的资源和任务纳入整体工程项目的计划中。制定改进活动的执行计划，进行跟踪、度量和报告，并在软件开发项目中合理安排改进工作，使之规模适中。为每个需要改进的过程领域编写活动计划，并密切关注风险承担者执行计划的情况，确保获得预期资源投入，同时了解改进过程的实际成本。
4 过程改进周期
在活动前知道自己处于哪个阶段的重要性,为改进活动制定计划的必要性以及从自己经验中所学到的作为持续地过程改进的重要性。
4.1 评估当前采用的方法
在进行任何过程改进之前，首要任务是对当前组织中所采用的方法进行全面评估，识别其优点与不足。评估本身虽不能直接带来改进，但却为后续决策提供了有价值的信息，为选择适宜的改进措施打下了基础。
评估当前过程的方式可以灵活多样。设计一套系统化的自我评价问卷也是一个低成本且有效的方法，能够系统性地评估当前的需求工程流程。
另外，还可以聘请外部顾问进行更为严谨和客观的评估。这类正式评估应当基于公认的、如软件工程研究所（CMU/SEI）开发的软件能力成熟度模型（CMM）等过程改进框架。评估者不仅会关注需求活动，还将考察整体的软件开发和管理过程。选择何种评估方法应根据组织希望通过过程改进实现的具体业务目标，而不是单纯追求符合CMM或其他特定模型的要求。
准备一份用于评估当前需求方法的自我评估问卷，可用于组织对自身当前需求工程方法的审视。通过自我评估，可以明确识别出需求过程中最亟待改进的环节。然而，单凭某个问题得分低并不能作为立即进行改进的唯一依据，应当重点关注那些可能对项目成功率产生重大影响的风险和难点。摩托罗拉公司也曾开发过一套名为“软件需求质量 7模型”的工具，用以评估软件需求过程。
正式评估将提供关于现行方法优缺点的详尽说明，以及针对改进机会的建设性意见。非正式评估手段，如自我评估问卷，则有助于理解并确定改进的方向。在考虑每一项改进举措时，务必对其进行分析，确保在可接受的成本范围内实施，并优先选择那些预期能够带来显著投资回报的改进活动。
4.2 制定改进活动计划
遵循将过程改进活动视为项目管理的原则，在完成评估之后，你需要制定一个详细的活动计划。这个计划可以分为战略 8计划和战术行动计划两部分，如同你在收集需求时采用的系统化方法，分别描述组织整体软件过程改进的宏观路径和具体行动步骤。每项战术行动计划都应明确指出改进目标、负责人以及必须执行的活动内容，因为缺乏计划往往会遗漏关键任务，而计划的存在则提供了跟踪和监控活动进度的有效手段。
以下是一个过程改进活动计划模板的示例。为了确保计划易于执行并能迅速取得成效，建议每个活动计划中不超过10个条目。例如，在一个针对需求管理改进的活动计划中，可能包括以下活动条目：
- 初步制定需求变更控制过程文档。
- 组织内部评审并修订变更控制过程草案。
- 在项目A中试行变更控制过程以检验其实效性。
- 根据试行反馈修订和完善变更控制过程。
- 对比评估不同问题跟踪工具，选择一款最适合支持变更控制过程的工具。
- 购买选定的问题跟踪工具并进行定制配置以满足变更控制过程需求。
- 在整个组织内推广并实施新的变更控制过程和配套工具。
确保每项活动都有专人负责，避免让整个团队共同负责一项任务，因为明确的个人责任将更有利于任务的执行和完成。
如果需要的活动条目超过了10个，首先应关注那些至关重要的条目，随后再逐步处理剩余的事项。请注意，过程改进是一个循环往复的过程，不断迭代优化。在后续的内容中，我们将进一步探讨如何将多个改进活动整合成为一个全面的软件开发过程改进计划。
需求过程改进活动计划模板
项目：软件开发过程改进
日期：[具体日期]
目标：通过改进需求管理过程，提高需求的准确性和及时性，减少需求变更的次数。
成功度量标准：通过需求评审 9会议的满意度、需求变更的频率以及需求实现与预期的一致性来衡量改进效果。
组织受影响范围：整个软件开发团队。
人员和风险承担者：项目经理负责制定和执行计划，开发团队成员参与需求分析和评审。
跟踪和报告过程：每周召开需求评审会议，记录会议内容并向团队成员发送会议纪要。
依赖、风险和限制：可能会受到需求来源方的影响，如需求变更频繁或不清晰。
估计所有活动的完成日期：预计在 6 个月内完成。
活动条目：
- 召开需求评审会议（负责人：项目经理；截止日期：每周五下午 2 点；目标：评估上周的需求进展情况；活动描述：讨论已收集的需求，确定是否满足业务需求 10；结果：记录需求变更建议；所需资源：会议室、白板、笔）
- 更新需求文档（负责人：开发团队成员；截止日期：每周一上午 10 点；目标：将评审后的需求整理成文档；活动描述：检查需求文档的准确性和完整性，补充遗漏的信息；结果：更新后的需求文档；所需资源：电脑、文档编辑软件）
- 培训开发团队关于需求管理的最佳实践（负责人：项目经理；截止日期：下周一下午 3 点；目标：提高开发团队对需求管理的认识；活动描述：介绍需求管理的基本概念和方法，分享案例；结果：团队成员掌握了新知识；所需资源：投影仪、演示文稿）
4.3 建立、实验和实施新的过程
目前已对需求方法进行评估，并起草了一份活动计划，指出了可能带来收获的过程领域。现在进入较困难的一步：实施计划。许多过程改进在试图由计划付诸实践时，一开始便夭折了。
实施一项活动计划意味着开发新的、更好的方法，并且要相信它能提供一个比目前过程更好的结果。然而，并非第一次就能使新过程完美无缺。许多看起来很不错的方法付诸实施后会变得既不实用而又低效。因此，要为你建立的新过程或文档模板计划一个“实验”。运用在实验中获取的经验来调整新技术，这样当将它运用于整个目标群体时，改进活动会更有效果。请铭记下面这些关于引导实验的建议：
- 选择实验参与者(participant),他们将尝试新方法并提供反馈信息，这些参与者可以是新手也可以是老手，但他们应该对过程改进没有强烈的反对意见。
- 确定用于评估实验的标准，使得到的结果易于解释。
- 通知那些需要知道实验是什么以及为什么要实施的工程风险承担者。
- 考虑在不同的项目中实验新过程的不同部分。用这个方式可使更多的人尝试新方法，因此能提高意识，增加反馈信息。
- 作为评估的一部分工作，询问实验参与者，如果他们不得不回头采用他们原有的工作方法，他们觉得如何。
即便是很有激励与善于理解的团队，他们接纳变更的能力也是有限的。所以不要一次给予项目或团队太多的期望。编写出一整套实施计划，明确你将怎样把新方法运用于整个项目团队以及你能提供的训练和支持；同时也要考虑管理者如何阐明他们对新过程的期望。一份正式的关于需求工程和需求管理的文件通常要阐述清楚管理人员的任务和期望。
4.4 评估结果
过程改进周期的最后一步是评估已实施的活动和取得的成果，这有助于您在未来的改进活动中做得更好。评估实验工作进行得如何，新过程解决问题是否有效，以及是否需要在下次管理过程实验中稍作变更。同时，还要考虑整个新过程在团队中的执行情况，是否能让每个人都明白新过程或模板的好处，参与者是否理解并成功地应用了新过程，以及是否需要在下次工作中进行调整。
关键的一步是评估新实施的过程是否带来了期望的结果。虽然有些新技术和管理方法可以带来明显的改进，但更多的需要时间来证明其全部的价值。例如，如果您实施一种新过程来处理需求变更，您会很快看到项目变更以更规范的方式进行。然而，一个新的软件需求规格说明模板需要一段时间来证明其价值，因为分析人员和客户已经习惯了一种需求文档的格式。给予新方法足够的运行时间，并选择能说明每项过程变更成功的衡量标准。
要接受学习曲线的事实。当从业者花费时间去吸收新方法时，生产率会降低，这是组织进行过程改进的一部分投入。如果您不理解这一点，您可能在得到回报之前就放弃，白白损失了投入而没有回报。对您的管理人员和同事进行有关学习曲线的教育，并让他们明白：采用高级的需求过程将获得更广泛的项目和业务回报。
5 需求过程的积累材料
为了确保项目不断取得满意的结果，需要有效地执行需求工程的各个过程。这些过程包括信息获取、分析、编写规格说明、验证以及管理。为了促进执行这些步骤，应该收集过程中积累的材料，这些材料包括已完成的活动和可交付的产品。
在需求工程中，可以收集以下几种类型的文档来帮助团队成员有效地执行过程：
- 检查清单：列出各项活动、交付的结果和其他应注意或验证的条目，有助于确保忙碌中的工作人员不会忽略重要细节。
- 实例：一种特定类型工作产品的代表，积累起能在组织中运用的更好的实例。
- 计划：概括说明怎样完成目标以及完成时需要什么样的文档。
- 方针：确立活动期望、产品期望和交付产品期望的指导原则，所有过程都应遵从的方针。
- 过程：描述完成某个活动的任务顺序或步骤，说明要执行的任务及其在项目中所扮演的角色 11。
- 过程描述：一组完成某些目的活动文档的定义，包括过程目标、里程碑、参与者、执行任务的合适时间、交流步骤、期望结果以及与过程相关的输入和输出数据。
- 模板：一种完成整个工作产品的指导方式，提醒你检查是否遗漏了什么。一个结构很好的模板提供了许多捕获和组织信息的栏目。
对于需求开发 12过程，可以收集以下积累材料：
- 项目视图与范围模板
- 需求开发过程
- 需求分配过程
- 使用实例模板
- 软件需求规格说明模板
- 需求优先级 13确定过程
- SRS 和使用实例审查清单
对于需求管理过程，可以收集以下积累材料：
- 变更控制过程
- 变更控制委员会过程
- 需求变更影响分析检查清单和模板
- 需求状态跟踪过程
- 需求跟踪能力矩阵模板
5.1 需求开发过程的材料
- 项目视图与范围模板：明确项目概念性功能，确定需求优先级和变更的参考。
- 需求开发过程：介绍如何确定客户及从客户那里获取需求的技术，以及各种需求文档和分析模型的创建方法。
- 需求分配过程：将高层产品需求分成特定子系统，确保功能分配到合适的系统组件中。
- 使用实例模板：提供一种标准方法编写每项用户希望使用软件系统完成的任务文档。
- 软件需求规格说明模板：组织功能需求和非功能需求的结构化方法，有助于创建统一且高质量的需求文档。
- 需求优先级确定过程：确定哪些性能、使用实例或功能需求的优先级最低，以便在任何阶段适当缩减范围。
- SRS 和使用实例审查清单：对需求文档进行正式审查的重要措施，审查清单可帮助发现错误并集中注意力。
5.2 需求管理过程的积累材料
您好！需求变更控制过程是指在项目开发过程中，对需求进行管理的过程。它包括以下几个步骤：明确问题、书面申请、影响分析、决策和通知。变更控制委员会(CCB)是由风险承担者的主要成员组成的，对提出的需求变更决定执行哪一项，拒绝哪一项，以及在各产品发行版本中包括哪些变更。CCB 的主要活动是对提出的变更进行影响分析，为每项变更作出决定，并且告知那些将受到影响的人。
需求变更影响分析清单和模板可以帮助您估计提出的需求变更的成本费用和影响是决定是否执行变更的重要步骤。影响分析能帮助 CCB 作出正确的决定。一张参与人员工作表可以作为估计任务工作量的简单方法，从这里就能明白确认变更的复杂性。
需求状态跟踪过程是指监控和报告每项功能需求的状态和状态改变的条件。您需要一个数据库或一种商业需求管理工具来跟踪一个复杂系统中大量的需求状态。此过程还描述了当您随时查看收集到的需求状态时输出的报告格式。
最后，需求跟踪能力矩阵模板列出了 SRS 中的所有功能需求及相应的设计模块、源文件和实施需求的过程，还有验证需求实施正确性的测试用例。跟踪能力矩阵应该也可以指出对应的上一层用户需求或系统需求。
6 需求过程改进路线图
改进组织的需求工程过程需要制定一个路线图，以确保改进活动的成功实施。这个路线图应该包括软件开发过程改进战略计划的一部分，并描述了改进活动的前后次序和期望的业务结果。主要的改进活动应该从左到右依次实施，每组改进活动都有一些中间的里程碑来指明取得的期望业务目标。一旦建立类似的路线图，可以指定一个人负责一个里程碑活动，并制定相应的活动计划和行动方案。在需求工程中，软件评审、简化的系统测量、采用标准和使用实例等都是重要的改进活动。同时，建立CCB并跟踪需求变更也是必要的步骤。改进后的项目应该进行状态管理和影响分析。
首先，需要更好地管理项目时间表，以确保所有需求都按时交付。 其次，需要更好地与客户沟通，以确保他们的需求得到充分理解和满足。 最后，需要更好地管理需求变更，以避免延误项目进度。