最完整的需求管理和可追溯性指南
需求工程
目录
为了生产出优质的产品，从客户那里得到准确的要求是很重要的。 这从需求工程过程开始，可分为五个步骤：收集需求、记录需求、分析和验证需求、管理需求变更和关闭需求阶段。 在这篇博文中，我们将详细讨论每个步骤，并展示它们如何帮助生产高质量的产品。
什么是需求和需求工程？
这里有两个术语，“需求”和“需求工程”。 需求被精确地定义为用户解决问题或实现目标所需的条件或能力。 换句话说，需求是系统必须满足或拥有的条件或能力，以便满足合同、标准、规范和其他正式文档。
需求工程被定义为定义、记录和维护需求的过程。 该学科包括与正在研究的系统相关的用户需求的定义和管理相关的所有技术、方法和程序。
总而言之，需求工程是一组与识别和传达系统或软件的目的以及将使用它的上下文有关的活动。
因此，需求工程充当了受软件或系统影响的用户、客户和其他支持者的实际需求与软件密集型技术所提供的能力和机会之间的桥梁。
需求工程的原理是什么？
需求工程的两个基本原则是需求工程的问题和解决方案。
- 在收集需求时，将问题和解决方案分开是很有用的。
- 这种分离在实际生活中永远无法完全实现。
需求工程是关于构建正确的系统。 基本上，它是关于构建一个适合用户问题的系统。 这是一个面向问题的部分。 它基本上是关于设计、验证、实施和维护所创建的系统，以确保它适合用户的问题。 这是面向解决方案的部分。
需求工程过程
在处理需求时，我们会面临一些活动。 在需求工程周期中，有五个主要活动，即，
- 需求启发 – 这是审查、记录和了解利益相关者和用户需求以及季节限制的过程。 用户需要领域信息、现有系统信息、法规、标准等，我们根据这些信息，引出需求。 在此之后，我们转向需求分析和谈判。
- 需求分析与协商 – 分析是在收集和获取的信息的基础上细化用户需求和约束的过程。 然后，我们转到文档活动。
- 需求文档/规范 – 获得需求规范后，我们进入文档部分。 我们清楚准确地记录用户需求和限制。
- 需求验证 – 最后，在验证活动中，我们插入季节要求是完整、简洁和清晰的。
- 需求管理 – 需求管理是一种在开发阶段收集、分析、提炼和确定所有产品或需求优先级的方法。
当我们最终确定这五项活动时，我们会一次又一次地重复它们，直到我们获得一组经过商定的正式规范的需求文档。
需求启发
正如我们之前所讨论的，需求获取是审查、记录和理解用户需求和季节限制的过程。 用户需要领域信息、现有系统信息、法规、标准等，我们根据这些信息，引出需求。 我们使用“Elicitation”这个词而不是“Gathering”，因为收集解释为只是提取需求并将它们放入文档中。 另一方面，启发是一个更复杂的过程。 您不会像收集时那样容易地获得要求。 它需要额外的努力。
在启发过程中，您询问用户或客户：
- 他们对系统/产品的目标是什么？
- 要完成什么？
- 季节性需求如何适应业务需求？
- 如何定期使用季节性产品/系统？
听起来很简单，但事实并非如此！
根据 Ian Sommerville 和 Pete Sawyer 的说法，需求获取是通过与客户、系统用户和其他参与系统开发的人进行沟通来发现系统需求的过程。 由于“收集”或“捕获”听起来不太准确，因此我们使用“启发”一词。
“我知道你相信你理解了你认为我说的话，但我不确定你是否意识到你听到的不是我的意思”——美国国务院发言人罗伯特·麦克洛斯基。
他所说的意思是有时人们会误解其他人对他们说的话。 有时他们所说的并不是他们所想的。 最终，这整个沟通不畅导致了需求收集的不当行为。
启发过程中的步骤是什么？
步骤1
需求来源：
我们可以从各种来源收集我们的需求。 其中一些包括：
- 利益相关者
- 现有系统
- 现有文件
- 竞争对手和其他类似系统
- 与系统的接口
- 法律和标准
- 公司政策
步骤2
设置项目范围：
可以按照以下步骤设置项目范围：
- 找出项目启动的原因
- 财产定义了通过项目实现的关键目标
- 为项目起草一份工作说明，这将帮助您适当地分解团队成员之间的工作
- 列出项目结束时要交付的项目
- 选择要实现的关键里程碑
- 确定团队在项目开发过程中可能面临的主要约束和限制
- 创建从范围项目列表中排除的项目列表
- 让利益相关者签署范围文件，因为它确认他们了解项目及其内容。
步骤3
启发任务：
规划启发：
- 为什么要实施这一特殊要求以及它将提供什么好处？ – 项目的目标
- 谁将负责创建它？ – 启发工作的专业人员
- 何时是实施的最佳时机？ – 安排估算来源
- 它将如何实施？ – 策略和程序
- 以及风险
在启发期间：
- 确认项目的可行性。 看看这个项目是否真的值得
- 从利益相关者的角度理解问题和问题
- 提取利益相关者陈述的需求的本质
- 找出更好的方法来为用户完成工作
- 创新是制胜的关键
以下引出：
- 分析结果以正确理解收集的信息
- 协商一组利益相关者可接受的连贯要求。 确定优先事项
- 将结果记录在要求的规范中
启发是一个渐进的过程。 您必须根据需要重复此步骤。
现在，为每个需求源选择一组适当的技术。 根据来源、要开发的系统等确定此技术。 请记住，并非所有技术都可以在每种情况下使用。
步骤4
要求的文件 -
启发过程的最后一步是以文档的形式完成所有要求。 本文档主要包含注释和用户要求。 这些要求将是不完整的、不一致的和无组织的。 但这只是起点。 可以不时编辑文档，可以添加或更改内容。
需求分析与协商
需求分析通常是分析、验证和调整在需求获取阶段记录的需求的过程。 换句话说，需求分析是研究和理解利益相关者提出的需求的过程。 需求分析需要与利益相关者和最终用户进行频繁的沟通，以定义期望、解决冲突并最终记录关键需求。 解决方案可能涉及以下问题：
- 公司工作流程的不同设置
- 设置从现在开始使用的新系统等。
要记住的一件事是需求获取和需求分析一起工作。 他们两个互相喂食。 当我们开始收集需求时，我们会同时引出它们并分析它们。
需求分析的目标
- 需求分析的首要目标是了解用户的需求和需求
- 当我们使用不同的来源收集需求时，它们之间可能会出现一些冲突。 需求分析是关于发现用户提出的需求之间的冲突并解决它们。
- 与用户和利益相关者协商需求。 我们的系统不可能完全按照利益相关者和用户解释的方式满足所有要求。
- 我们将不得不协商并优先考虑这些要求。 有些要求对我们来说可能并不大，但它们对最终用户来说可能非常重要。 为了理解它们，我们必须分析利益相关者的要求并确定其优先级。
- 我们必须详细说明用户和系统提出的要求。 这有助于在需求规范中记录需求。 此外，这有助于开发人员更好地开发、设计和测试，因为他们以详细和更好的方式理解需求。
- 我们必须将需求分为各种不同的类别和子类别，并进一步将这些需求分配给不同的子系统。
- 我们还必须评估组织所需的质量要求。
- 最后，我们必须确保不错过任何重要的事情。
需求文档/规范
需求规范，也称为文档，是以文档的形式记下所有系统和用户需求的过程。 这些要求必须清晰、完整、全面和一致。
在捕获活动期间，我们从各种来源收集所有需求。 在分析和谈判活动中，我们分析和理解这些要求。 现在，我们必须准备一份正式文件来解释这些要求。 这就是需求规范。 准确地说，它是以清晰准确的方式记录所有用户和系统需求和约束的过程。
记录需求的方法
耳朵 在这里将是一种有效的方法。 它代表 需求语法的简单方法. 在这种方法中，我们写出清晰、简洁、易懂的语言。 这改进了整个需求工程工作流程，并通过使事情变得非常容易理解来简化工作。
为了实现这一点，这里有一些在编写需求时必须牢记的原则。 它们涉及：
每个要求必须是一个完整的句子形式。 不应使用项目符号、首字母缩略词、缩写词或流行语。 尽量使句子简短、直接和完整。
确保每个要求都有适当的主语、谓语和动词。 主题将是我们正在谈论的用户类型或系统。 谓词将是我们期望的条件或行动或期望的结果。 我们必须用“shall”、“will”和“must”之类的词来表达某种必要性，用“may”之类的词来表达需求中的可选性。
每个需求都必须有效地解释我们希望从系统中得到的最终结果。
此外，要求必须描述我们对系统的期望质量。 当我们衡量最终结果并查看需求是否正确实施时，它会有所帮助。
需求验证
验证是用于检查系统是否达到标准的过程。 验证回答了“我们是否在构建正确的系统？”这个问题。 它是关于测试和验证系统，看看我们构建的系统是否正确，以及它是否满足客户的期望。 用于验证系统的各种方法包括黑盒测试、白盒测试、集成测试和单元测试。 验证总是在验证之后进行。
验证是用于检查系统是否实现其预期目标而没有任何错误或问题的过程。 验证回答了这个问题，“我们是否在构建产品？” 它是关于测试和验证系统是否满足其要求而没有任何问题。 用于验证系统的各种方法包括审查、走查、检查和案头检查。 验证是在验证之前完成的手动过程。
验证技术
有多种技术可用于验证需求。 他们包括：
- 支票 – 在检查需求时，我们会校对需求文档，以确保没有遗漏任何启发注释。 在这些检查期间，我们还会检查所有需求之间的可追溯性级别。 为此，需要创建可追溯性矩阵。 该矩阵确保所有要求都得到认真考虑，并且指定的所有内容都是合理的。 在这些检查期间，我们还会检查要求的格式。 我们看看要求是否清晰且写得好。
- 模型 – 这是一种构建模型或模拟由开发人员构建的系统的方法。 这是利益相关者和用户之间非常流行的需求验证技术，因为它可以帮助他们轻松识别问题。 我们可以联系用户和利益相关者并获得他们的反馈。
- 测试设计 – 在测试设计过程中，我们遵循一个小程序，首先确定测试团队，然后构建一些测试场景。 功能测试可以从需求规范本身派生出来，其中每个需求都有一个关联的测试。 相反，非功能性需求很难测试，因为每个测试都必须追溯到它的需求。 这样做的目的是找出规范中的错误或遗漏的细节。
- 需求审查 – 在需求审查期间，一群知识渊博的人以结构化和详细的方式分析需求并识别潜在问题。 之后，他们聚在一起讨论问题并找出解决问题的方法。 准备了一份由各种标准组成的清单，并且审查者选中这些框以提供正式审查。 之后，完成最终批准签字。
需求管理
根据 Ian Sommerville 的说法，“需求管理是在需求工程过程和系统开发过程中管理不断变化的需求的过程。”
需求管理的主要目的是确保向工程团队提供清晰、简洁和无错误的需求，以便他们能够确保检测系统中的错误并潜在地降低项目成本和风险。
需求管理的主要关注点
需求管理存在一些问题。 他们包括：
- 管理商定要求的变更
- 管理所有需求之间的关系
- 管理在系统工程过程中产生的需求文档之间的依赖关系。
需求类型
大致有两种要求：
- 系统要求 – 系统需求可以称为用户需求的扩展版本。 系统需求是任何新系统设计的起点。 这些要求是系统必须满足的用户要求的详细描述。
- 用户要求 – 用户需求是功能性和非功能性需求的组合。 这些用户需求的设计方式必须使没有任何技术知识的用户易于理解。 因此，它们必须使用简单的表格、表格和图表以自然语言编写。 此外，请确保该文档没有关于系统设计、软件或正式符号的详细信息。
视觉要求 ALM 平台
视觉要求 ALM 平台 是最值得信赖的现代 ALM 平台之一，专门为全球各种规模的组织提供需求管理。
它是构建复杂产品、系统和软件的团队的必备工具，这些产品、系统和软件需要从概念到测试和部署，一直到源代码的端到端可追溯性，以及标准认证合规性。
Visure Requirements 是一种经过验证的灵活且完整的需求工程工具，能够将软件需求流程简化为硬件和机械定义流程的一部分。 Visure 需求通过需求捕获、分析、规范、确认和验证、管理和重用来帮助有效的项目协作并提高软件质量。
Visure Solutions 可以帮助克服产品和嵌入式开发的挑战，
- 提高定义质量是提高软件质量必不可少的第一步
- 重新控制开发和监管流程
- 在整个组织中标准化和实施需求定义
- 支持跨项目团队、产品线和变体的需求的有效重用
- 形成通用的需求规范结构，并在整个生命周期中处理变化
- 完全可追溯 贯穿所有元素，从需求到测试再到执行
- 轻松跟踪开发的所有方面，从风险计算图形到孤立的需求报告
- 从编写更好的需求和确定需求的优先级到改变影响分析能力，在各个层面避免陷阱并降低风险。
使用 Visure Requirements 进行产品和嵌入式开发的好处
- 认证支持 行业标准，如 DO-178B/C、IEC 61508、ISO 26262、IEC 62304、FMEA 和 GAMP5
- 适用于所有与需求相关活动的完整平台
- 通过支持不同流程模型（包括 Automotive SPICE、CMMI、V-model、Agile 和 ad hoc）的灵活解决方案执行流程
- 通过基于角色的功能改进团队沟通和协作
- 支持更优质的产品，并减少软件缺陷。
积极使用 Visure 的公司声称对准时项目交付、项目合规性以及开发成本和周期时间的降低产生了明显的影响。
结论
需求工程是确保我们构建的产品和系统满足客户需求的关键过程。 本文概述的五步过程可以帮助您尽早并经常从利益相关者那里获得反馈并使用该反馈生成清晰简洁的需求，从而使您的项目有一个良好的开端。 如果您正在寻找一种工具来帮助您管理需求工程流程，Visure Requirements ALM Platform 可以提供帮助。 请求您的 免费30日试用版 今天看看我们的平台如何使您的下一个项目取得成功。
不要忘记分享这篇文章！
