软件工程中的需求工程

引言

需求工程 (RE) 是软件工程设计过程中识别、记录和管理需求的系统化过程。它指的是一套允许检测、分析、定义、确认需求和利益相关者期望，以及监控和控制需求的过程和程序。这些需求在满足最终产品的预期用途和用户的需求方面起着至关重要的作用。

正如理论所证明的，需求工程是一个核心组成部分，无论如何强调都不为过。它是项目所有其他阶段的基础，如分析、设计、实现、测试和支持项目。如果需求工程得到妥善实施，RE 可以降低项目风险、控制范围、降低成本，并实现项目商定的愿景。当项目需求工程未得到妥善定义时，项目将面临困难，最终导致失败，这意味着资源已被投入，但需求尚未满足。

目标和宗旨

• 识别和捕获需求：从客户/用户及其监管者那里识别和捕获需求。
• 确保需求清晰易懂：确保所有参与需求的人都了解这些需求，并确保它们被准确地传达、细化，且不包含任何歧义。
• 优先排序需求：根据需求的重要性和紧急程度对其进行优先排序。
• 验证需求：确保已指定的需求可以实现、验证，并满足项目的需求以及活动的限制。
• 管理需求变更：在整个项目生命周期中引入和实施需求变更管理程序，以确保所有变更都得到记录和审查。

历史视角和演变

历史上，需求记录的方式非常随意，主要通过口头交流进行，这很快导致了严重的误解和系统项目灾难。当系统变得稍微复杂时，人们就认识到了制定更好的系统的必要性。

• 20 世纪 60 年代和 70 年代：这两个十年，主要关注的是软件本身，需求充其量也只是补充。软件开发生命周期 (SDLC) 模型 的出现表明，在需求方面需要结构。
• 20 世纪 80 年代：正式方法的常规使用也得到了引入，需求工程被确立为一门学科。诸如结构化分析和设计技术 (SADT) 和瀑布模型等方法非常关注用户或客户对系统的期望或需求。
• 20 世纪 90 年代：此时，面向对象的分析和设计 (OOAD) 与统一建模语言 (UML) 一起出现，为需求文档提供了更传统的方法。Rational Unified Process (RUP) 也采用了迭代开发方法和需求的持续改进。
• 21 世纪 00 年代：敏捷方法的实施导致了处理需求方式的重大转变。这些框架的做法包括 Scrum 和 XP，它们侧重于迭代、与客户协作以及应对变化的能力。因此，用户故事和待办事项列表取代了格式和文档，成为捕获和管理需求的主要方式。
• 如今：目前，需求工程是经典和当代阶段的混合体，利用新技术来控制系统的复杂性。诸如基于模型的 需求工程、需求可追溯性 以及在需求分析中集成人工智能或机器学习算法等方法正在不断增加。重点放在工作进度的升级、利益相关者的参与以及将 RE 融入通用项目管理环境。

需求类型

图 1. 需求类型

1. 功能需求

功能需求描述了系统必须执行的操作。它们是需要设计为系统功能的特性以及需要跟踪的特性。这些需求涵盖了系统与其环境之间的关系，包括输入、活动和输出。

• 用户身份验证：系统必须能够捕获用户的登录凭据，即用户名和密码。
• 订单处理：系统必须允许下订单、修改订单和取消订单。
• 报表生成：系统必须每月生成销售报表。
• 数据录入：系统应允许用户输入客户数据，如姓名、地址和联系信息。
• 电子邮件通知：系统必须向用户提供注册完成的提醒。

在系统设计中的作用

结构化需求也是定义系统设计的关键特性。

• 定义范围：应明确系统能做什么，不能做什么。
• 指导开发：为开发人员提供一个工作清单，确保所有要点都已纳入设计。
• 促进测试：在开发测试用例时使用此功能，以确认系统正在执行预期操作。
• 改善沟通：支持修改利益相关者对系统工作原理的认知，以实现最佳的相互理解并避免可能的误解。

2. 非功能性需求

它们规定了系统如何执行某个功能，而不是它期望做什么。它们侧重于系统的效率、灵活性、可靠性和安全性等方面。

• 性能：系统内的交易时间不得超过 2 秒。
• 可用性：用户应能通过最少的培训完成所需操作。
• 可靠性：系统每月可用性应达到 99.9%。
• 安全性：任何关键信息在传输或存储过程中都必须保持安全。
• 可伸缩性：系统负载必须能够同时容纳至少一万用户，同时仍能保持其效率。

在系统性能中的重要性

这些功能性需求之所以重要，是因为它们能够让系统在用户使用期望的范围内得到控制，而不受条件影响。

• 确保用户满意度：必须检查与使用直接相关的特性，如可用性和性能。
• 提升系统质量：支持提高系统的整体健壮性、安全性和可靠性。
• 支持未来增长：确保系统能够处理额外的负载，并且当前系统的修改易于实现。
• 降低风险：处理可能威胁安全的问题，并解决影响效率的问题。

3. 领域需求

因此，领域需求是指从系统的预期用途的行业或领域派生的需求。它们包含了系统应运行的专业要求、规范和政策。

• 医疗保健：系统必须能够遵守 HIPAA 标准中有关患者信息隐私和安全的政策。
• 金融：它还必须能够处理多币种操作并符合全球会计准则。
• 教育：系统必须具备学生注册和课程进展的功能，以及一个由评分和出勤记录组成的报告系统。
• 电子商务：必须集成不同的支付模块和支付网关，系统应遵守严格的 PCI-DSS 法规。
• 制造业：系统需要设计成适应已建立的 ERP 系统，并允许库存控制和生产计划。

案例研究和示例

• 医疗保健系统：设计了一个医疗保健管理系统，以有效管理数据，如通过图表、预约计划和计费来管理患者。功能需求包括患者注册、预约调度和 EHR 等任务。基于非功能性需求，数据应安全（符合 HIPAA）、系统必须高度可用（99.9% 可用），并且对医疗保健提供者来说非常易于使用。领域需求确保了遵循了医疗保健指南，并且该发明是与已有的医疗设备和结构兼容的补充。
• 电子商务：开发了一个电子商务平台用于在线交易。一些功能需求是产品目录和购物车，其他是订单处理。执行非功能性需求的要求侧重于性能（页面加载）、安全性（符合 PCI-DSS 的支付处理器）和可伸缩性（在销售活动期间支持高流量的能力）等方面。领域需求解决了行业各种需求，其中一些是集成多个支付网关以及满足消费者保护法的担忧。

需求工程过程

需求工程是定义、记录和管理系统或项目利益相关者需求和期望的过程。它认为，为了使用户满意，最终效用必须达到用户的期望和需求水平，同时还要满足其他利益相关者的期望。需求工程过程分为以下几个步骤。每个步骤对项目的成功都非常重要。这个过程是周期性的，这意味着可能需要围绕同一个过程进行多次迭代，以微调某些需求。

图 2. 需求工程的阶段

需求工程的阶段

1. 需求获取

需求获取是从项目相关人员或用户那里识别项目需求的過程。它是需求工程阶段的第一个过程，分析师在此过程中与利益相关者沟通以了解他们的需求。获取技术包括

• 访谈：与利益相关者进行面对面的个人访谈或焦点小组访谈，以获取定性数据。
• 问卷调查：通过问卷调查的方式从大量人群中获取信息。
• 研讨会：协调共同会议，期间各方可以描述和讨论相关需求。
• 头脑风暴会议：组织头脑风暴会议，以产生大量的想法和需求。
• 观察：让利益相关者身处工作环境中，观察他们的需求和困扰。
• 文档分析：通过查阅已有的文档，可以轻松找到需求。
• 用例和场景：描述实际和可能的应用场景，以确定功能需求。
• 原型设计：主要阶段是探索需求并构建简单的模型以测试和获取反馈。

2. 需求分析

需求分析包括审查已收集的需求，以符合清晰、完整和可行性等既定标准。此阶段对于识别任何矛盾、中立化或重复的需求至关重要。需求分析的关键活动包括

• 需求优先级排序：对需求的关联性和对项目的影响进行初步排序。
• 成本效益分析：考虑每个需求的成本（金钱、时间和精力）及其对公司的优势。
• 风险分析：与需求项相关的风险，这些风险可能成为需求方面的潜在问题。
• 可行性研究：评估跨学科的技术需求和经济性。
• 建模：使用数据流图、实体关系图等模型对需求进行设计。

3. 需求规格说明

文档化是指以简洁、精确和组织良好的方式陈述具体需求的过程。它在项目生命周期的整个过程中作为开发人员和其他相关利益相关者的参考手册。需求规格说明的重要方面包括

• 编写有效需求：保持需求的质量，使其精确，表达单一含义。
• 标准格式和模板：应用标准格式、模板等，使其与其他信息格式和模板高度相似。
• 需求规格说明语言：使用 UML 和 SysML 等语言来陈述需求。
• 最佳实践和常见陷阱：本节涵盖规格说明过程，如何避免降低规格说明质量的陷阱，以及为取得最佳结果应采取的措施。

4. 需求验证

需求验证是指确保已陈述的需求仍然符合用户需求并且能够实现的程序。验证需求的技巧包括

• 评审和检查：应进行正式的需求文档评估和审计。
• 原型设计：通过用户进行原型设计来确认需求。
• 模型验证：评估和验证分析阶段开发的模型，并与需求进行比较。
• 测试用例：从需求中导出测试用例，以检查其符合性和完备性。

5. 需求管理

需求管理涵盖了在项目需求整个生命周期中管理变更。需求管理证明任何变更都将被评估、授权，并在需要时实施。需求管理的关键方面包括

• 版本控制和可追溯性：记录需求的历史和来源。
• 变更管理：最后的最佳实践是强制执行适当的变更控制程序，该程序侧重于需求的变更。
• 影响分析：评估任何变更对项目工作范围、时间表和成本的影响。
• 沟通：告知所有相关利益相关者正在发生的变更及其影响。
• 需求管理工具：使用工具来处理需求和变更，可以提高处理效率。

需求工程中的挑战

1. 模糊的需求

• 这意味着需求可能含糊不清或具有多种含义。这反过来会导致混乱和错误的实现。
• 一个模糊需求的例子是“系统应用户友好”，因为“用户友好”这个词对不同的用户可能有不同的含义。

2. 不完整的需求

• 可能开发出未能涵盖系统所有方面的需求，实现这些需求可能会在功能上留下空白，并在开发过程中产生问题。
• 在交易处理系统中缺乏错误处理需求可能会导致系统或数据丢失。

3. 需求变更

• 利益相关者可以根据业务需求、市场变化或偏好频繁要求变更需求。这通常会导致时间问题并引起开发范围的变动。
• 在某些情况下，为桌面应用程序开发的项目由于市场趋势需要转移到移动平台。

4. 冲突的需求

• 每个利益相关者可能都有不同的需求，这使得确定和实现功能变得具有挑战性。
• 这会导致一种情况，即一个利益相关者可能希望拥有一个增强报告的功能。而其他利益相关者可能希望获得高系统性能，这导致资源分配不一致。

5. 利益相关者沟通问题

• 两个关键参与者之间缺乏适当的沟通极大地导致了利益相关者和开发团队之间期望的误解和计算错误。
• 利益相关者以某种方式说话，并倾向于使用开发团队不完全理解的某些术语。

6. 技术约束

• 组织约束，例如技术限制（如固定设备、硬件和旧系统），可能会阻碍已识别需求的实施。
• 投资新功能的组件可能需要新的数据处理能力，而旧的数据库系统无法支持。

克服挑战的策略

1. 清晰详细的文档

• 确保所有要满足的需求都得到准确和详细的描述；选择的词语应具体，以消除误解或混淆的可能性。
• 使用标准格式的文本，并用不同的模板和格式来说明需求，同时提供示例和图表。

2. 定期与利益相关者互动

• 持续与利益相关者联系，获取他们的反馈并与他们和谐合作。
• 组织定期会议，使用一些相关的技巧，并确保利益相关者参与评审和验证过程。

3. 变更管理流程

• 这些变更必须伴随着正式的程序来控制所谓的范围蔓延，并系统地评估变更。
• 这包括变更请求表，变更将产生的开销，根据其重要性对这些变更进行优先级排序，以及如何完成它们。

4. 冲突解决机制

• 应这样做以避免因不同利益相关者的需求而产生的冲突需求。
• 借助引导式研讨会、谈判技巧和决策模型来达成共识。

5. 有效的沟通技巧

• 因此，提高不同利益相关者群体成员与开发团队之间的互动至关重要，以避免误解。
• 确保客户在合作过程中不产生误解。使用模型和原型来避免沟通不畅。

6. 借助现代工具和技术建立合作

• 在需求工程中采用现代工具，以确保新工具能够管理和跟踪需求。
• 使用 JIRA、Trello 或更专业的工具来创建、跟踪和管理需求。

结论

需求工程是软件开发生命周期中最关键的阶段之一，以保证最终产品的可靠性。它包括正确地发现、记录和控制需求的过程。然而，需求工程并非没有挑战，包括需求模糊、不完整和易变性，与利益相关者之间以及利益相关者内部的沟通问题，以及技术障碍。应对这些挑战并采取精确的文档、持续的利益相关者沟通、适当的沟通方法和有效的变更管理至关重要。通过现代工具、资源管理和持续实践，可以进一步改进需求工程过程。如果克服了这些障碍，组织将能够产生更精确的需求，从而实现有效的项目和有效的系统。为了满足当前和未来的业务需求和机遇，并受益于新技术创新，持续改进需求工程流程也是必要的，以实现项目的持续成功和最终用户的满意。