需求工程的推荐方法
在十年前，我热衷于研究软件的开发方法论，尝试将各种模型和技术用于解决项目难题。然而，现在我更注重应用“最佳方法”。这种方法强调将软件工具包拆分成多个子包以分别应用于不同的问题，而并不是去设计或购买一整套的解决方案。即使你采用了一套商业上的方法，你也应当从中提取出好的技术，将它有效地应用于实践。
“最佳方法”这个词值得我们深入讨论：谁能确定什么是“最佳”的呢？而且，得到这个结论的依据又是什么？一种可能的方案是把这方面的专家召集起来分析众多不同组织中成功和失败的项目。专家们将那些成功项目中提供高效的方法以及失败项目中导致低效甚至无效的方法都归纳出来。这样，专家们就能找到公认的能收到实效的关键方法。这些方法即是“最佳方法”，其本质就是有助于项目成功的有效方法。
以下是关于需求工程的推荐方法：
0.1 知识技能
0.2 需求管理
- 确定变更控制过程：制定明确的流程，以管理和控制需求的变更。
- 建立变更控制委员会：设立一个专门的团队，负责审查和批准所有的变更请求。
- 进行变更影响分析：评估每个变更对项目的影响，包括成本、时间和质量。
- 跟踪影响工作产品的每项变更：记录每个变更及其结果，以便在未来参考。
- 编写需求文档 3的基准版本和控制版本：使用版本控制系统来管理需求文档的变化。
- 维护变更历史记录：保持对所有需求变更的历史记录，以便审计和问题追踪。
- 跟踪需求状态：定期更新和维护需求的状态，如未开始、进行中、已完成等。
- 衡量需求稳定性：通过跟踪需求的生命周期和使用频率来衡量其稳定性。
- 使用需求管理工具：利用工具来自动化一些常见的需求管理任务，如变更请求的处理和跟踪。
0.3 项目管理
- 选择合适的生存期：根据项目的特性和环境选择最合适的生存期。
- 确定需求的基本计划：为满足需求设定明确的目标和里程碑。
- 协商约定：与客户或利益相关者 4协商需求的交付方式和时间表。
- 管理需求风险：识别和管理可能影响需求实现 5的风险。
- 跟踪需求工作：监控需求的实施进度，确保其按计划进行。
需求开发 6和分析是软件开发过程中至关重要的步骤，它确保了产品满足用户的需求和期望。下面是对您提供的需求开发步骤的解释和建议：
- 获取：
- 编写项目视图与范围：定义项目的高层概述和边界。
- 确定需求开发过程：选择适合项目的需求收集和分析方法。
- 用户群分类：识别不同的用户类型，以便了解他们的需求。
- 选择产品代表：选择能够代表不同用户群体的人员。
- 建立核心队伍：组建一个跨职能的团队，负责需求开发。
- 确定使用实例：描述用户如何与系统交互。
- 召开应用程序开发联系会议：与所有相关方进行沟通，确保需求理解一致。
- 分析用户工作流程：了解用户在系统中的工作流程。
- 确定质量属性 7：定义系统应具备的质量标准。
- 检查问题报告：审查已有的问题报告，以发现潜在需求。
- 需求重用：考虑是否有现有需求可以适用于新项目。
- 分析：
- 编写规格说明书：
- 采用软件需求规格说明模版：使用标准化模板来记录需求。
- 指明需求来源：记录需求的出处和原始请求者。
- 为每项需求注上标号：给每个需求分配唯一的标识符。
- 记录业务规范：详细描述业务规则和逻辑。
- 创建需求跟踪能力矩阵：确保能够追踪每个需求的实现状态。
- 验证：
- 审查需求文档：确保需求完整、一致且无歧义。
- 依据需求编写测试用例：创建测试用例来验证需求是否得到满足。
- 编写用户手册：为用户提供如何使用系统的指导。
- 确定合格的标准：定义什么构成需求的接受标准 10。
这些步骤中，有些可能是您的项目所必需的，而有些可能不那么关键。建议您根据项目的实际情况和资源，优先实施那些对项目影响最大且相对容易实施的方法。随着项目的进展，您可以逐步引入更复杂或更深入的技术和方法。
在实施需求工程时，没有必要采用所有可能的方法。相反，应该根据项目的具体情况、团队的经验和资源来选择合适的方法。以下是一些建议，可以帮助你评估和选择适合自己项目的需求工程方法，并设计一个实施步骤图来改进需求过程：
- 评估当前状况:
- 审查当前项目的需求工程实践。
- 识别存在的问题和挑战。
- 收集反馈，包括团队成员和利益相关者的意见。
- 确定改进目标:
- 根据评估结果，确定希望达到的改进目标。
- 设定可量化的目标，例如减少需求变更次数、提高需求满意度等。
- 选择适合的方法:
- 根据项目类型、规模、复杂性和团队经验选择方法。
- 考虑项目的发展阶段，如启动阶段可能需要更多的需求获取和分析，而后期可能需要更多的验证和管理工作。
- 设计实施步骤图:
- 创建一个流程图，展示从需求获取到验证的整个过程。
- 在步骤图中标明所选方法的应用阶段。
- 确保步骤图清晰、易于理解，并且可以被团队成员有效执行。
- 实施和培训:
- 根据步骤图开始实施新的方法。
- 如果需要，为团队成员提供相关培训。
- 从小范围开始，逐步扩大到整个项目。
- 监控和调整:
- 监控实施效果，与预期目标进行比较。
- 收集反馈，并根据反馈调整方法和步骤图。
- 确保持续改进，适应项目的变化。
- 记录和分享经验:
- 记录实施过程中的经验教训 11。
- 分享成功案例和学习点，以便其他项目或团队可以借鉴。
在选择具体的需求工程方法时，可以考虑以下方面：
- 变更管理: 对于经常变更的项目，强化变更管理流程是关键。
- 需求获取: 对于新项目，确保彻底理解用户需求是非常重要的。
- 用户参与: 如果项目的用户群体非常关键，那么增加用户的参与度，例如通过原型设计 12会议或用户体验测试。
- 优先级排序: 当资源有限时，能够有效地对需求进行优先级排序是必要的。
- 需求跟踪: 对于大型或长期项目，需求跟踪可以帮助确保所有需求都得到满足。
最后，记得需求工程是一个持续的过程，需要根据项目的发展和变化不断地进行调整和优化。
1 知识技能
软件开发团队成员中，并非所有人都系统地学习过高效需求工程所需的专业技能。然而，在实际工作中，许多开发者在项目生命周期的不同时期会参与到需求分析的过程中，与客户紧密合作，共同进行需求的收集、分析和文档编制工作。尽管一些人可能具有良好的沟通“天分”，但依赖于个人天赋并不足以确保高质量的需求管理。因此，通过专门的培训来提升团队成员在需求工程方面的能力是至关重要的。
鉴于需求定义对项目成功起着决定性作用，所有关键项目干系人都应该认识到需求工程的重要性、合理性和实施方法的基础知识。组织为期一天的需求工程流程简介研讨会 13，邀请包括开发人员、市场营销人员、客户代表、测试人员和管理人员在内的所有利益相关者参与，可以有效促进团队间的协作理解。这样的活动能使每个参与者意识到各自面临的挑战以及为了团队整体成功需要承担的责任。
对于直接负责收集、记录和解析用户需求的开发人员来说，应接受更为深入的需求工程基础培训，甚至是一周或更长时间的专项训练。资深需求分析师则应当通过充分的信息交流和应用领域的深入了解，熟练掌握并运用成熟的需求工程技术。
同时，参与软件开发过程中的用户代表和管理层也应该参加一天左右的需求工程基础知识培训，这包括开发项目经理和客户方管理者。此类培训有助于他们认识到强化需求阶段工作的重要性以及忽视需求管理所带来的潜在风险。不少用户在参加了需求研讨后反馈说，这加深了他们对软件开发人员工作的理解和尊重。
为增强开发人员对业务应用领域的认识，可安排一系列简短的讨论会议，介绍客户的日常运营活动、专业术语和目标等内容。这样可以帮助开发人员建立起对应用领域的基本认知，减少因误解而造成的返工问题。考虑为每位开发人员指定一个用户伙伴，以便在整个项目过程中解释业务相关的术语和概念；产品负责人或业务分析师可以扮演这一角色 14。
最后，为了减少因行业术语和词汇使用导致的沟通歧义，建议编写一份详尽的项目术语汇编，其中明确界定项目应用领域内专用词汇的意义和用法。这份汇编不仅应涵盖有多重含义或多用途的术语，还应包含那些在特定领域和通用语境中有不同释义的词语。
2 需求获取
在项目中，需求的三个层次包括：
- 业务需求：反映组织的战略 15目标和商业目的，是项目的宏观指导。
- 用户需求：描述用户期望系统实现的具体任务和目标。
- 功能需求：详细说明系统必须执行的操作，直接来源于用户需求。
为了有效管理这些需求，需要建立一套流程，涵盖收集、分析、细化和验证步骤，并文档化。项目视图和范围文档定义了业务目标，为功能和用户需求提供框架。将用户分类有助于精准获取需求。每类用户选出代表，确保他们的需求被理解和记录。核心队伍由典型用户组成，提供丰富的现场反馈。
使用实例由用户代表定义，展示如何与系统交互。开发联系会议促进沟通，帮助草拟需求文档。通过分析用户工作流程，可以更深入地了解实际的业务操作，这可能揭示现有流程的改进点。
除了功能性需求，非功能质量属性（如性能、可靠性）也至关重要。问题报告提供了改进的方向和特性增加的想法。考虑需求重用可以提高效率，降低成本。
为了有效地进行需求开发，应制定以下步骤：
- 确定一套完整的需求开发流程，包括收集、分析、细化和验证需求的方法，并将其记录成文档。
- 编写项目视图和范围文档，确保所有参与者对项目的总体目标有共同理解，并用此文档作为后续细化功能需求和非功能需求的基准。
- 分析和归纳不同的用户群体及其特性，选择各类用户的产品代表，并建立典型用户的核心队伍以获取真实而详尽的需求信息。
- 通过召开应用程序开发联系会议及深入研究用户工作流程，捕捉使用实例并转换为功能需求。
- 分析现有问题报告以补充和完善需求，尤其是针对已有系统的改进和增强点。
- 同时考虑跨项目重用需求的可能性，如果新的需求与已存在的解决方案相似，则可评估是否能利用现有组件以提高效率和降低成本。
综上所述，正确且全面地处理这三层需求，并遵循规范的需求开发过程，有助于确保最终开发出的产品既能满足客户业务目标，又能提供优质的用户体验，并达到预期的质量标准。
3 需求分析
需求分析是软件开发生命周期中的关键阶段，它涉及对收集到的需求进行深入的审查、验证和细化。以下是需求分析中的一些核心活动：
提炼与审查：分析员要确保每个需求清晰无误，没有歧义或遗漏，并且所有利益相关者都能理解其含义。这包括对照优秀需求说明的标准检查需求规格说明书。
多视图描述与分析：采用文本、图形等多种形式来表达需求，例如系统上下文示意图（System Context Diagrams），有助于从不同角度揭示潜在问题，促进各方共识。
绘制系统上下文示意图：此步骤用于界定系统的边界，展示系统与外部实体之间的交互关系以及信息流和物质流的方向。
创建用户接口原型：在需求不明确时，通过构建初步的用户界面原型，可以让团队成员和用户直观地理解设计概念和操作流程，从而发现并解决需求文档与实际应用间可能存在的冲突。
需求可行性分析：评估每项需求在成本、性能等约束条件下的实现可能性，识别实施风险，如与其他需求间的冲突、对外部因素的依赖和技术挑战。
确定需求优先级 16：利用分析技术为各项需求设定优先级，以便决定哪些功能将被纳入当前版本开发计划，并根据变更管理策略调整产品迭代内容。
建立需求模型：使用各种图形工具构建需求模型，如数据流图（DFD）、实体关系图（ERD）、状态机图、对话框图、UML类图和序列图 17等，以可视化方式查找和修复错误、不一致性和冗余。
创建数据字典：数据字典是定义项目中所有数据元素和结构的标准文档，保证团队成员对数据的一致理解和使用，尤其是在需求阶段对客户数据项的定义。
运用质量功能展开（QFD）：这是一种量化客户需求的技术，通过对需求分类（期望需求、普通需求和兴奋需求），帮助团队关注那些对客户价值影响最大的特性，优化资源分配，满足用户的隐性需求和显性需求。
综上所述，需求分析阶段的目标是形成准确、全面且可度量的需求文档，以便于后续的项目估算 18、设计、编码和测试工作，最终交付符合甚至超越客户期待的产品。
4 需求规格说明
在软件开发过程中，需求管理是一个严谨且系统化的过程，确保所有需求都能被清晰、一致地记录并保持可追溯性。以下是您所描述的几个关键步骤：
- 统一编写可视文档：
- 业务需求 19应以项目视图和范围文档的形式呈现，概述整个项目的高层次目标和边界。
- 用户需求应该通过标准使用实例模板书写，详细描述用户与系统交互的具体场景。
- 软件需求规格说明书（SRS）则包含功能需求和非功能需求，需遵循组织内定义的标准格式和风格。
- 采用SRS模板：
- 组织应建立一种标准化的SRS模板，该模板结构清晰，便于记录功能需求、约束条件、假设等信息，并可根据具体项目进行适当的调整和扩展。
- IEEE标准830-1998是业界广泛参考的一种规范，为编写高质量的SRS提供了基础框架。
- 需求来源追踪：
- 每个需求都应该能够追溯到其原始来源，如具体的用户故事 20、用例、商业规则、政策法规或行业标准等。
- 这有助于所有项目利益相关者理解每项需求背后的逻辑和必要性。
- 需求编号和标识：
- 制定一套规范的需求编号系统，为SRS中的每项需求分配独立且易于识别的编号，使得需求变更、跟踪和度量变得有序和透明。
- 记录业务规范：
- 在SRS中设立专门的部分来记录业务规则，这些规则指导产品的实际运作，比如角色权限、操作流程等。
- 针对业务规范引出的功能需求应当明确关联到相应的业务规则上，形成可追溯关系。
- 创建需求跟踪能力矩阵：
- 建立一个需求跟踪矩阵（RTM），将每个需求与其对应的设计实现、测试案例以及可能的高层需求和其他相关需求链 21接起来。
- 需求跟踪矩阵在整个开发过程而非仅在项目后期持续维护和更新，确保需求得到全面覆盖，同时也能及时反映需求变更的影响范围。
5 需求验证
在软件开发流程中，需求验证 22是确保产品成功的关键环节，它旨在确认需求规格说明书（SRS）的准确性和完整性，并为后续的设计、实现和系统验证提供可靠的基础。以下是您所提到的需求验证过程中的几个核心步骤：
- 需求文档审查：
- 正式审查：通过组织一个多角色小组（包括但不限于业务分析师、项目经理、设计师、开发人员和客户代表等），对SRS进行深入细致的检查，识别并修正潜在的歧义、遗漏或不一致性。
- 非正式评审 23：在需求开发过程中定期进行非正式的讨论和反馈循环，有助于及时发现并解决问题。
- 基于需求编写测试用例：
- 根据用户需求创建黑盒功能测试用例，这些用例应全面覆盖所有预期的产品功能特性。
- 通过执行测试用例，客户可以验证系统是否按预期运行，并通过追溯测试用例至功能需求来确保无遗漏需求。
- 测试用例同样用于验证需求模型（如对话框图、原型或其他设计文档）的准确性。
- 编制用户手册：
- 在需求分析阶段就着手准备用户手册草稿，它将作为SRS的补充说明，帮助理解用户界面和操作流程。
- 用户手册应以简洁明了的语言描述所有与用户交互的功能，并在SRS中详细记录那些对用户不可见但至关重要的需求，如性能指标、质量属性等。
- 定义验收标准：
- 用户应明确表述什么样的产品状态才符合他们的实际需求和期望，建立基于使用场景或使用实例的验收测试计划。
- 这些验收测试应当围绕着真实的用户情境构建，确保最终产品能够满足用户的操作习惯和业务流程要求。
6 需求管理
处理项目需求变更时，有效的变更管理至关重要。这包括评估变更的潜在影响和可能的成本，并通过变更控制委员会与关键风险承担者协商确定实施哪些变更。跟踪需求状态对于管理过程也是不可或缺的。
配置管理方法对于需求管理至关重要。版本控制等技术不仅适用于代码管理，也可用于需求文档的管理。引入新的管理配置方法可以提升组织的需求管理效率。
建立需求变更控制流程，确保所有变更都经过选择、分析和决策过程。商业化的问题跟踪工具能够支持这一流程。
创建由项目风险承担者组成的变更控制委员会，负责确定、评估和决策哪些需求变更将被实施，以及它们的优先级和计划安排。
进行需求变更影响分析以评估对项目计划和其他需求的影响，明确相关任务及所需工作量，帮助委员会做出更好的决策。
跟踪所有受需求变更影响的工作产品，包括其他需求、设计模板、源代码和测试用例，以确保一致性并减少疏忽。
建立和维护需求基线 24和控制版本文档，使用配置管理工具进行版本控制，保持文档的清晰和组织。
记录需求变更历史，包括变更日期、原因、负责人和新版本号，以便追踪和审计。
建立数据库跟踪每项需求的状态，包括其重要属性和进展状态，这有助于随时获取项目需求的最新情况。
衡量需求稳定性，通过记录基本需求数量和定期的变更数量来评估项目管理的有效性。
使用需求管理工具来存储不同类型的需求、确定属性、跟踪状态，并在需求与其他软件开发工作产品之间建立联系链。
7 项目管理
总之，软件工程管理方法在本质上与项目的需求过程是紧密相关的。为了应对需求变更和项目范围 25扩展，项目计划应允许一定程度的灵活性。组织应根据不同类型的项目和需求说明的不同程度选择几种不同的软件开发方法。在项目开发过程中，随着需求细节的不断清晰和完善，项目开发计划的进度安排也会不断改变。当需求发生变更时，需要协商项目约定并更新风险管理计划。同时，要跟踪需求工程所耗的工作量，以便评估需求活动是否达到预期要求并为将来的项目提供更好的资源计划。
以下是一些可能的障碍和解决方案：
- 专家：如果团队中没有专家，那么可能需要寻找外部的专家资源或者进行培训。例如，如果你正在处理一个复杂的技术问题，你可能需要找到一个在该领域有经验的专家来帮助你。
- 熟练者：如果团队中有熟练的成员，但他们没有足够的时间来处理所有的需求，那么你可能需要重新分配任务，以确保每个人都能专注于他们最擅长的部分。
- 生手或新手：如果团队中有人是新手，那么他们可能需要更多的培训和支持。你可以提供在线教程、研讨会或其他资源来帮助他们提高技能。
- 沟通：有效的沟通是任何项目成功的关键。确保所有团队成员都清楚他们的角色和责任，以及项目的进度和目标。
- 风险管理：需求可能会随着时间的推移而变化，因此需要定期评估和管理风险。这可能包括定期的项目审查，以确保项目仍然符合客户的需求 26。
- 资源管理：确保你有足够的资源（包括时间、人力和资金）来满足所有的需求。这可能需要你重新考虑你的项目计划和预算。
- 质量管理：确保你的产品或服务能满足客户的需求。这可能需要你进行客户满意度调查，或者定期收集反馈来改进你的产品或服务。
8 实践计划
- 摘取本文所推荐的实践方法，分析它们在解决当前问题上的潜在作用。
- 针对每一种推荐的方法，在组织内部进行评估，识别并列出可能阻碍其有效实施的具体障碍因素。
- 将前一阶段认可的有效需求管理方法汇总至一张表格中，以确保系统性地梳理和对比。
在表格中，请为每种方法标注项目团队对应的能力水平，按照以下分类进行评估： - 专家：团队成员对该方法有深厚理解和丰富实践经验 - 熟练者：团队中有人能熟练应用此方法，并取得过良好效果 - 生手：团队具备一定的基础但尚不熟练，需要更多实践提升 - 新手：团队对此方法接触较少或完全陌生
倘若发现团队在任何一种关键方法上未达到熟练程度，则应采取行动： - 安排团队内某一成员专门负责学习该方法的深入知识与技能； - 学成后，要求这位成员将所学内容以培训或其他形式分享给团队其他成员，以提升整个团队在这方面的应用能力。