收集支持 ML 的系统的要求
收集支持 ML 的系统的要求
这篇文章涵盖了我们生产中的机器学习课程的“需求和风险”讲座中的一些内容。其他章节见 表中的内容 .
大部分软件工程通常都专注于让工程师在开始编码之前进行一些思考和计划，以避免投入大量精力来构建不起作用或无法解决正确问题的东西。在机器学习中，与传统的软件工程没有什么不同，我们经常被闪亮的技术和有趣的想法所激励，但可能无法退后一步来理解我们可能解决的实际问题、用户将如何与产品交互以及我们可能遇到的问题可以预见到产品可能会导致的结果。因此，我们经常在没有太多计划的情况下构建软件，最终得到的产品并不能真正满足用户的需求。
需求工程符合这一主题，即鼓励对实际问题是什么、用户真正需要什么以及可能出现的复杂情况进行一些前期思考。无论我们是否在软件系统中使用机器学习，事实证明，用户需求可能与开发人员最初认为的完全不同。开发人员经常做出在生产系统中根本不成立的假设。其中，开发人员经常低估某些品质对用户的重要性，例如响应时间短、用户界面直观或在使用系统时有某种代理感。在考虑需求方面进行一些前期投资可以避免以后出现许多通常代价高昂的问题。
在验证了机器学习是否能很好地解决问题并理解了最后两章的整体系统目标之后，我们现在概述了获取和记录需求的基础知识。这将为后续章节探索如何预测和减少错误、如何设计 ML 和非 ML 组件以满足系统需求以及如何负责任地构建安全、公平和可靠的系统提供基础.
诚然，需求工程在软件开发人员中的声誉通常很差。传统方法通常被视为乏味和官僚主义。但是，需求工程并不是遵循特定规则的全有或全无的方法
Excerpt from the project cartoon illustrating the challenges and many misunderstandings during requirements engineering (CC 3.0-BY 项目卡通网站 ).
运行示例：跌倒检测
对于老年人来说，跌倒可能对他们的健康构成严重威胁，他们可能无法自行起床。在过去 个人应急响应系统 已被部署为用户在跌倒后可以用来请求帮助的设备，但佩戴此类设备通常与耻辱有关。最近，许多公司提出了更多可以检测跌倒并采取自动化行动的分立设备，包括智能手表和壁挂式传感器。让我们考虑一个智能手表的软件组件，它可以根据手表的陀螺仪检测跌倒，并可以通过连接的手机联系紧急服务。
解开需求
软件开发人员通常对逻辑、抽象和模型的思考感到自在，但忽略了软件开发过程中出现的许多挑战 与现实世界互动 — 通过用户界面、传感器和执行器。软件几乎总是为了影响现实世界而构建的。不幸的是，现实世界并不总是像软件开发人员希望的那样运行——在我们的跌倒检测场景中，软件可能会显示一条消息，询问用户是否还好，但用户可能会忽略它；软件可以通过机器学习识别摔倒的人，但有时也可以将拍苍蝇等手势识别为摔倒；软件可能会发送命令联系紧急救援人员，但没有人出现，因为恶劣的天气中断了电话服务。
世界与机器
为了解决这些问题，仔细考虑哪些陈述与现实世界（“世界”）有关，哪些陈述与软件（“机器”）有关，以及它们之间的关系是有用的。在软件工程中，这种区别经常在标签下讨论 《世界与机器》 在一篇具有此标题的有影响力的论文之后。用这种区别解开需求讨论可以带来很多清晰度。
从根本上说，软件目标和用户需求是 关于现实世界的陈述 ——我们希望通过软件在现实世界中实现的目标。因此，目标和要求 系统的 表示为世界中的期望状态：例如，我们可能想要销售更多智能手表或帮助人类在跌倒后获得帮助，所有这些都会影响现实世界。创建软件，无论是否有机器学习，都是为了解释世界的某些部分并将世界操纵到所需的状态，或者直接使用传感器和执行器，或者通过人类行为间接介导。
有点明显但容易被忽视的关键问题是 软件 它本身不能直接推理现实世界。软件获取输入数据，对其进行处理并生成输出数据。输入数据通常与现实世界中的事物相关，但它总是必须通过传感器或人类输入数据进行调解。例如，软件无法直接了解人类是否跌倒或智能手表如何在物理空间中移动，它必须依赖人类按下按钮（或多或少可靠）或传感器感应运动（或多或少准确）。同样，输出数据不会立即影响现实世界，但只有当它被人类解释并采取行动或控制执行器时才会影响。在我们的跌倒检测场景中，执行器可以自动激活灯光或声音，或者可以拨打电话，然后人类可以采取行动帮助跌倒的人。重要的是，软件只能在现实世界的现象或多或少可靠地转化为输入的情况下对世界进行推理，并且只有在输出数据以预期方式作用时才能影响现实世界。
Software can only interact with the real world mediated through input and output devices. Software cannot reason directly about the world, but only about input data that may be derived from observations about the world made by sensors. Software cannot directly influence the world, but only indirectly by presenting output data to humans or controlling phenomena in the world through actuators.
因此，为了在现实世界中实现所需的系统行为，我们不仅需要考虑软件如何从输入计算输出，还要考虑这些输入的含义以及输出的解释方式。这通常涉及各种 假设 例如，智能手表中的陀螺仪传感器能够可靠地捕捉手表在物理空间中的运动，或者拨打紧急联系人的电话将为跌倒的人带来帮助。为了实现可靠的系统，重要的是要批判性地质疑假设并考虑如何设计软件之外的世界，例如，在设备中安装什么硬件以及如何培训应急响应人员。需求工程研究员迈克尔杰克逊在他讨论世界和机器区别的原始文章中，因此得出以下结论 许多开发问题的解决方案不仅涉及工程 ** 在** 世界，也是工程 ** 的** 世界。” 也就是说，仅仅了解和设计软件是不够的，我们还需要了解和设计软件如何与世界交互，这可能涉及到软件外部世界的变化。
要求、假设和规范
重要的是，清楚地思考世界和机器，以及机器如何只能通过传感器和执行器与世界交互，让我们能够区分：
- 系统要求 (REQ) 描述如何 系统 应该运作，完全用世界上的概念来表达。例如，智能手表应在佩戴者跌倒时呼叫紧急救援人员。系统需求捕捉现实世界中应该发生的事情，而不是软件应该如何处理数据。
- 规格 (SPEC) 用输入数据和输出数据描述软件组件的预期行为。例如，如果传感器输入与之前提供的训练数据相似，我们希望模型报告“检测到跌倒”作为输出；或者控制器组件应在从模型接收到“检测到跌倒”输入后 30 秒输出“呼叫紧急响应者”输出，除非其他输入数据表明用户已按下“我很好”按钮。规范仅指软件世界中的概念，如输入和输出数据，而不是现实世界中的概念。规格有时也称为 软件要求 或者 组件要求 将它们与系统要求进行对比。
- 假设（ASM） 表达现实世界概念与软件输入和输出的关系。例如，我们假设陀螺仪传感器正确地代表了智能手表的运动，GPS 坐标代表了跌倒的位置，手动输入的紧急救援人员的联系地址正确地代表了用户的意图，紧急救援人员实际响应了呼叫。假设是将系统需求中的现实世界概念与规范中的软件概念联系起来的东西。
- 实现（IMPL） 提供应该符合规范 (SPEC) 的软件系统的实际行为，通常使用一些代码或可执行模型给出。检测到的实现和规范之间的不匹配被认为是 漏洞 .例如，控制器中的缓冲区溢出使系统崩溃，因此如果表示陀螺仪传感器读数的输入值超过某个值（例如，由于异常严重的跌倒），则不会产生“呼叫紧急响应者”输出命令（输出）。
从逻辑上讲，我们期望假设和软件规范一起确保现实世界中所需的系统行为（ASM ∧ SPEC ⊨ REQ）并且规范正确实施（IMPL ⊨ SPEC）。但是，当…
- …系统要求（REQ）完全错误。例如，我们忘记捕捉到如果在家外检测到跌倒，智能手表不应呼叫紧急响应人员到用户家中。
- …假设 (ASM) 不正确、不切实际、不断变化或缺失。例如，我们（隐含地）假设 GPS 传感器在建筑物内是可靠的，并且用户始终正确输入紧急响应者的联系信息，但后来发现情况并非总是如此。因此，即使实现完全符合规范，系统也可能无法满足其系统要求。
- …软件规范（SPEC）是错误的。例如，如果检测到表示该用户按下取消按钮的输入，则规范忘记指出不应产生“呼叫紧急响应者”输出。同样，实现可能完全符合规范，但再次导致不满足系统要求的行为。
- …这些部分中的任何一个在内部不一致或与其他部分不一致。例如，如果指定的何时发出调用的逻辑 (SPEC) 不考虑重试机制或冗余通信通道，则软件规范 (SPEC) 和假设 (ASM) 不足以保证系统要求 (REQ)可能的通信问题 (ASM)，以确保实际联系到应急响应人员 (REQ)。
- …系统执行不正确（IMPL），与指定行为（SPEC）不同，例如缓冲区溢出或控制逻辑中的不正确表达式，例如实际等待 120 秒而不是指定的 30 秒。
这些部分中的任何一个都可能导致问题，从而导致现实世界中的错误行为（即违反系统要求）。在实践中，软件工程师通常将大部分注意力集中在发现最后一类问题上，即实施错误，对此有很多测试工具。但在实践中，在几乎所有围绕安全、安保、公平和反馈循环的讨论中，无论有无机器学习，错误假设似乎都是一个更加紧迫的问题。
汉莎航空 2904 跑道坠毁
不正确的假设 (ASM) 如何导致灾难的经典（非 ML）示例是 汉莎航空 2904 号班机 在飞行员着陆后无法及时使用反推力装置后，它在跑道上空坠毁在华沙。
飞机的软件旨在达到一个简单的安全要求 (REQ)：如果飞机在空中，不要使用反推力装置。这样做会非常危险，因此软件应确保只有在飞机降落在跑道上后才使用推力反向器来破坏飞机。
在典型的世界与机器方式中，关键问题是安全要求是根据现实世界的现象（“飞机在空中”）编写的，但软件根本无法知道飞机是否在空中，必须依靠传感器输入来理解世界。为此，飞机上的空中客车软件会感应起落架上的重量以及飞机轮子转动的速度。这个想法——假设（ASM）——是如果每个起落架上至少有 6.3 吨的重量或轮子的转动速度超过 72 节，飞机就在地面上。两者似乎都是关于如何根据可用的传感器输入来理解世界的安全赌注，甚至提供了一些冗余，以便对如何解释世界状态充满信心。软件的规范（SPEC）然后只是简单地输出一个命令来阻止推力反向器，除非这些条件中的任何一个保持感测值。
Illustration of the plane landing sideways due to wind and water on the runway, by 任何人 (CC BY-SA 3.0)
不幸的是，在 1993 年致命的一天，由于下雨和强风，汉莎航空 2904 航班降落在华沙后的几秒钟内，这两个条件都没有得到满足。着陆后，由于打滑，机轮转得不够快，而且由于风，只有一个起落架装载了重量。将现实世界中的状态与传感器输入相匹配的假设根本不正确。因此，软件根据其输入确定飞机仍在空中，因此（完全按照规定）指示不得使用推力反向器。在这里，现实世界和软件对现实世界的假设根本不匹配。此外，该系统旨在信任软件的输出（对执行器的假设），因此不允许飞行员覆盖软件。
总之，系统要求（REQ）很好——飞机在空中确实不应该使用反推力装置。实现（IMPL）与规范（SPEC）正确匹配——系统为给定的输入产生了预期的输出。问题在于假设（ASM），即系统如何解释现实世界——无论它是否认为飞机在空中。
质疑机器学习中的假设
与所有其他软件系统一样，具有机器学习组件的系统也与现实世界交互。训练数据是通过代表现实世界的某种传感器输入（用户输入、用户操作日志、相机图片、GPS 位置等）派生的输入数据，并且预测形式的输出在现实世界中用于某些手动或自动决策.重要的是不仅要质疑关于运行系统的输入和输出的假设，还要质疑关于用于训练系统机器学习组件的训练数据的假设。通过及早识别、记录和检查这些假设，可以预测和缓解许多潜在问题。另请注意，随着世界的变化，使用的假设（尤其是在机器学习环境中）可能不一定是稳定的。世界甚至可能会因我们的系统而改变。尽管如此，有可能随着时间的推移监控假设，以检测它们何时仍然有效并需要调整我们的规范（通常是用新的训练数据更新模型）或根据需要调整软件外部的流程。
在我们的跌倒检测场景中，我们可能能够预测一些不同的有问题的假设：
- 不可靠的人工反馈： 跌倒检测系统的用户可能会在跌倒时感到尴尬，并决定在跌倒后不求救。为此，用户可能会指出他们没有摔倒，这可能会使系统将预测解释为误报，进而可能导致模型未来迭代的训练数据被错误标记。理解了这个假设，我们可以例如澄清用户界面以区分“我没有摔倒”和“我现在不需要帮助”，或者在将其用于训练之前更仔细地查看生产数据。
- 数据漂移： 训练数据是在很长一段时间内从一个老年家庭网络中的跌倒中收集的。我们假设这些地方代表了未来的客户群，但我们注意到其他地方（例如，在家）的用户可能拥有导致不同加速模式的毛绒地毯。检查关于哪些训练数据代表目标分布的假设是机器学习项目中的一个常见挑战。
- 反馈回路： 我们假设用户普遍佩戴智能手表进行跌倒检测。然而，一系列误报，甚至可能与不必要地呼叫看护人或紧急响应者的成本或压力有关，用户可能在某些情况下不愿佩戴手表，例如在园艺时。因此，在这种情况下，我们可能拥有更不可靠的训练数据和更多的误报，从而导致更多的用户丢弃他们的手表。我们可以重新审视我们的假设，以更好地了解用户何时以及为何停止佩戴手表。
- 攻击： 也许有些牵强，但恶意用户可以人为地摇动另一个用户床头柜上的智能手表，以在该用户睡觉时触发跌倒检测。根据我们对此类情况的担忧程度，我们可能希望重新审视我们的假设，即手表的所有运动都发生在手表佩戴时，并使用额外的传感器来识别用户并检测跌倒发生在手表实际佩戴时正确用户的手腕。
在所有情况下，我们都可以质疑我们的假设是否现实，以及我们是否应该通过额外的传感器输入来加强系统或削弱系统要求以降低野心和更现实。
为了更加强调这一点，让我们考虑一下在线商店中产品推荐的第二种情况，其中系统要求可能是对许多现实世界客户喜欢的产品进行高度排名：
- 攻击： 在构建推荐系统时，我们可能（隐含地）假设过去的评论反映了过去客户的诚实意见，并且过去的评论对应于过去客户的代表性或随机样本。即使只是明确地写下这些假设也可能表明它们可能存在问题，并且有可能通过恶意污染输入（例如，虚假评论、评论轰炸）故意影响系统，从而在高评价产品实际上可能没有的情况下违反系统要求与现实世界中许多客户喜欢的产品相关。考虑到这些假设，我们可以考虑系统中的其他设计决策，例如只接受过去客户的评论、评价来自撰写许多评论的客户的评论的信誉系统，
- 概念漂移： 我们可能意识到，我们不应该假设 2 年前的评论一定反映了今天的客户偏好，而应该相应地调整我们的模型以考虑评论的年龄。再次，我们修改我们的假设并调整规范，以使系统仍然满足系统要求。
- 反馈回路： 我们可能会意识到我们可能会引入反馈循环，因为我们假设推荐会影响购买行为，而推荐也是基于购买行为。也就是说，我们可以塑造系统，使早期排名靠前的产品仍然排名靠前，因为它们被购买和评价最多。无意的反馈循环通常是由于错误或缺失的假设不能正确反映现实世界中的过程而发生的。
反思假设揭示了问题并鼓励对系统设计进行修订。最后，我们可能会决定，按平均客户偏好对产品进行排名的系统要求在这种普遍性上可能是不现实的，我们需要将要求弱化为更容易测量的属性或加强软件规范——这样做会更诚实地说明什么该系统可以实现并迫使我们考虑缓解各种可能的问题。在所有这些情况下，我们批判性地反映假设以及所述要求是否实际上可以实现，可能会退回到更弱和更现实的要求或更复杂的规范，以避免简单的捷径。
行为要求和质量要求
作为解开需求的最终维度，系统需求和软件规范通常分为行为需求和质量需求（也通常称为功能需求与非功能需求）。虽然对于某些需求的区别可能会变得模糊，但行为需求通常描述了软件应该做什么，而质量需求与软件应该如何做或应该如何构建有关。例如，在跌倒检测场景中，行为系统规范是“跌倒后呼叫紧急服务”，行为软件规范可能包括“如果接收到'跌倒检测'输入，则在 30 秒后激活'呼叫紧急响应者'输出”；质量系统要求可能是“系统的运营成本应低于每月 50 美元”，质量软件规范可能是“跌倒检测器的延迟应低于 100 毫秒”。对于所有的质量要求，定义明确的措施来设定特定的期望是很重要的，就像讨论目标一样（见第 设定和衡量目标 了解如何定义和评估措施）。
有许多可能的质量要求。常见的是安全性、安全性、可靠性和公平性等品质，与执行性能相关的品质，如延迟、吞吐量和成本，与用户交互相关的品质，如可用性和便利性，以及与开发过程相关的品质，如开发成本、开发软件的持续时间、可维护性和可扩展性。所有这些品质都可以针对整个系统以及单个软件组件进行讨论，我们可能需要考虑与它们相关的假设。设计师和客户通常关注特定的质量要求，但在早期阶段忽略其他要求，但如果系统错过了一些重要的品质，如可用性或运营效率，通常会在部署后迅速引起注意。我们将在本章中回到各种特性，特别是机器学习组件 ML 组件的质量属性 .
引出要求
了解一个系统的需求是出了名的困难。
- 客户经常对他们想要什么提供模糊的描述，只是后来抱怨“不，不像那样”。例如，当我们询问跌倒检测智能手表的潜在用户时，他们可能会说他们更喜欢完全自动化呼叫紧急响应者，但一旦他们体验到系统有时会错误地将手势检测为跌倒，他们就会修改这一说法。此外，客户倾向于关注现状的具体问题，而不是更广泛地思考一个好的解决方案应该是什么样子。例如，客户最初可能专注于隐藏智能手表中的跌倒检测功能，以避免当前解决方案的污名，但不必担心任何进一步的功能。
- 很难广泛地捕捉需求，也很容易忽略特定的关注点。我们可能会建立一个让直接客户满意的系统，但与该系统交互的其他所有人都会抱怨。例如，智能手表的设计吸引了购买手表的老年用户，但它却因设计不佳的通知而惹恼了应急响应人员。特别是少数群体的担忧或监管机构的担忧（例如，隐私、安全、公平）如果不是由客户提出，很容易被忽视。
- 工程师可能会接受模糊的需求，假设他们已经了解需要什么并且可以填补空白。例如，工程师可能会假设他们自己对在呼叫紧急响应者之前等待确认跌倒确认多长时间有很好的直觉，而不是真正调查问题，例如通过用户研究。
- 工程师喜欢专注于技术解决方案。当技术娴熟的人（包括软件工程师和数据科学家）考虑需求时，他们往往会立即关注软件解决方案和技术可能性，而偏向于过去的解决方案，而不是全面了解更大的系统需求。例如，他们可能专注于哪些信息可用并且可以在通知中显示，而不是确定紧急响应者实际需要哪些信息。
- 工程师更喜欢优雅的抽象。提供忽略现实世界混乱的通用且简单的解决方案是很有诱惑力的。例如，帕金森氏病的震颤可能会使陀螺仪传感器读数出现问题，但由于不适合系统的总体设计，因此可能会被视为不方便的特殊情况而被丢弃。
作为对所有这些困难的回应，需求工程领域已经开发了几种技术和策略来更系统和全面地引出需求。
识别利益相关者
在引出目标和要求时，我们通常倾向于从系统所有者和潜在的未来用户开始，询问他们想要什么。然而，重要的是要认识到可能有许多
在软件工程和更一般的项目管理中，术语 利益相关者 用于指对项目感兴趣或可能受项目影响的所有个人和实体。这种利益相关者的概念故意非常广泛。它包括开发项目的组织（例如，开发和销售跌倒检测设备的公司）、参与开发项目的所有人员（例如，经理、软件工程师、数据科学家、操作员、从事外包组件的公司）、所有客户和项目的用户（例如，老年人、他们的看护人、养老院），以及间接受到正面或负面影响的人（例如，应急响应人员、竞争对手、关注责任或隐私的监管机构、出售设备的公司的投资者）。在项目决策中，不同利益相关者的偏好当然不会具有同等的权重，但识别各种利益相关者及其目标有助于了解项目中的不同关注点并有意识地设定目标。
通常值得在项目早期进行头脑风暴会议，以确定项目中的潜在利益相关者。一旦我们有了初步的利益相关者名单，我们就可以开始考虑如何确定他们的需求或关注点。在许多情况下，我们可能会尝试与每组利益相关者的代表成员交谈，但我们也可能会从间接方法中识别他们的担忧，例如背景阅读或角色。
需求获取技术
大多数需求由 说 向各种利益相关者了解他们在现状中面临的问题以及他们希望从系统中得到什么发展。
尤其 采访 与利益相关者是一种常见的形式来获取需求。我们可以向利益相关者询问他们希望通过系统解决的问题，我们可以询问他们对解决方案的设想，以及他们对解决方案的期望质量（例如，价格、响应时间）。面试的好处是我们可以深入了解事情的发展方式 真的 在实践中进行，我们可以从不同的利益相关者那里征求广泛的想法和对解决方案的偏好。我们还可以明确询问权衡，例如更准确的解决方案是否值得额外成本。在我们的跌倒检测场景中，我们可以询问潜在的未来用户、我们希望替换的现有系统的用户、护理人员、应急响应人员以及系统操作员他们的偏好、想法、顾虑或限制。
如果辅以视觉效果、故事板或原型，访谈通常会更有成效。我们当然可以谈论要替换的旧系统的具体问题。通过交互式原型，我们还可以观察潜在用户如何与设想的系统进行交互。在机器学习环境中，特别是 绿野仙踪实验 在人类手动执行尚未开发的机器学习组件的任务的情况下很常见——例如，人类操作员可以观看测试用户的实时视频，以在早期原型中向紧急响应者发起呼叫跌倒检测智能手表。这样，我们可以快速创建人们可以与之交互的原型，而无需先解决机器学习问题。
通常，采访是在一些背景研究之后进行的，以使采访者能够提出有意义的问题。这可能涉及了解组织和问题域以及研究要替换的现有系统。我们可以尝试重用过去设计中的知识，例如关于重要的质量权衡。例如，我们可以阅读有关现有跌倒检测和应急响应系统的学术研究，阅读现有产品的公开产品评论以识别痛点，并尝试各种竞争对手的产品以了解他们的设计选择和挑战。我们也可以阅读法律或就相关规定咨询律师。
除了访谈和文件分析之外，还有许多其他方法，每种方法都专注于不同的方面。典型的方法包括：
- 调查 可用于回答更狭窄的问题，可能会征求大量人群的意见。 小组会议 和 研讨会 与利益相关者团体的多个成员讨论问题和解决方案也很常见。
- 人物角色 如果我们无法直接访问该子组的成员，则已成功用于从特定用户子组的角度思考问题。角色是对具有某些特征的潜在用户的具体描述，可帮助设计人员从该用户的角度思考解决方案。
- 民族志研究 可用于获得对问题的详细了解，其中体验问题可能比解释问题更容易：这里的需求工程师要么被动地观察潜在用户的任务和问题，可能要求他们在工作时用语言表达，或者他们积极参与他们的任务。例如，跌倒检测系统的需求工程师可能会在养老院中观察人们，或者在看护人员建议使用现有的个人应急响应系统期间进行观察。
- 需求分类和清单 可以跨项目使用，以确保至少考虑到共同需求。这有助于确保对响应时间、能耗、可用性、安全性、隐私和公平性等问题的特别质量要求予以考虑，即使这些要求在任何采访中都没有被有机地提出。
协商要求
在最初的需求获取阶段（例如文档分析和访谈）之后，开发团队通常会听说系统应该解决的大量问题以及系统应该如何解决的许多想法或请求。他们现在需要决定要解决哪些具体问题，以及如何在解决方案中优先考虑各种质量。
需求工程和设计教科书可以提供一些具体的指导和方法，如 卡片分类 , 亲和图 ， 和 重要性-难度矩阵 ，但通常目标是对相关数据进行分组，识别相互冲突的关注点和替代选项，并最终就优先事项和冲突解决方案做出决定。例如，接受采访的不同潜在用户可能对紧急响应者在检测到跌倒后是否全自动呼叫有不同的看法——系统设计人员可以决定是选择单一选项（例如，完全自动化）还是妥协（例如，在检测到跌倒后呼叫） 30 秒，除非用户按下“我很好”按钮），或者将此作为配置选项留给用户。
在许多情况下，不同利益相关者的偏好之间会出现冲突，例如，当用户的愿望与开发人员和运营商的愿望发生冲突时（例如，频繁的廉价更新与低系统复杂性），当客户的愿望与其他受影响的人的愿望发生冲突时各方（例如，最终用户的隐私偏好与紧急响应者的信息需求），或者当产品所有者的目标与社会趋势或政府政策目标发生冲突时（例如，最大化收入与更强的隐私权和降低医疗保险费）。冲突偏好很常见，开发人员需要不断地驾驭冲突和权衡。在少数情况下，法律法规可能会提供难以忽视的外部约束，但在许多其他情况下，系统设计人员将不得不进行一些工程或业务判断。最终的决定通常不能平等地满足所有利益相关者，但必然需要优先考虑某些利益相关者的偏好。决策过程可以是迭代的，探索多个设计选项，并从各个利益相关者那里收集关于这些选项的额外反馈。最后，项目的所有者通常有权做出最终决定，然后可以记录下来并说明理由。这在很大程度上反映了在单个组件级别导航技术设计决策的技术过程，我们将在本章中讨论 机器学习组件的质量属性 .
记录要求
一旦团队确定了需求，最好将它们写下来，这样它们就可以用于其余的开发过程。需求通常以文本形式捕获为“ 将” 关于系统或软件组件应该做什么、不应该做什么或它们应该具有什么品质的陈述。此类文档还应包含系统非软件部分的假设和责任。记录的要求反映了协商冲突偏好的结果。
当一方与另一方签订合同来构建软件时，正式的需求文档可以用作合同的基础。除此之外，明确记录的需求对于导出测试用例、规划和估计工作以及创建最终用户文档也很有用。
请注意，经典的需求文档在许多开发人员中的名声很差，因为它冗长、墨守成规、乏味且过于死板。传统的正式需求文档（软件需求规范，SRS）包含数百页的要点和文本并不少见。虽然这在正式的合同环境中很有用，但许多项目采用了更轻量级和敏捷的方法，试图通过文本文件、问题跟踪器或 wiki 中的简短注释仅捕获基本信息和部分需求。通常，随着项目风险的增加，更严格的需求文件变得更加重要。
需求评估
可以评估和审核文档化的需求，类似于代码审查。需求文档可以显示给系统中的不同利益相关者，以询问他们是否同意需求以及是否发现任何遗漏。通常，基于已识别需求的简单原型可以引发有用的反馈，利益相关者会立即注意到他们以前没有考虑过的问题。
检查表可以确保涵盖所有重要的质量要求（例如，是否考虑了隐私和功率效率）。此外，我们可以系统地评估需求文档的清晰度和内部一致性：例如，我们可以检查文档中的质量度量是否都明确指定并且在实践中可以实际测量，系统需求和软件规范是否明确分离，陈述了假设，所有陈述都没有歧义，并且文档本身结构良好，并确定了所有需求的来源。
要求领域专家查看需求对于检查假设 (ASM) 是否现实和完整（例如，紧急响应者是否需要合同协议来响应自动呼叫）特别有用。假设也可以通过实验和原型进行验证（例如，从陀螺传感器数据中准确检测跌倒是否可行，测量应急团队的典型响应时间）。在具有机器学习组件的项目中，AI 素养在需求工程阶段对于捕捉不切实际的需求（例如，“不允许误报”）和不切实际的假设（例如，“训练数据无偏见且具有代表性”）至关重要。
请注意，所有这些评估都可以在系统完全构建之前完成。这样，可以在开发过程的早期检测到许多问题，此时重新设计系统仍有更大的灵活性。
多少需求工程以及何时？
正如我们将在章节中讨论的那样 数据科学和软件工程过程模型 ，不同的项目受益于不同的流程和不同程度的形式。预先确定确定的要求有助于建立合同，并可以减少以后的更改次数，并且可以为设计实际满足质量要求的系统提供坚实的基础。然而，在完成重大探索之前，需求通常很模糊或不清楚——尤其是在机器学习项目中，需要通过实验来了解技术能力。因此，对需求的大量早期投资可以被视为减慢项目速度的不必要负担。
在实践中，很少会预先完全建立需求然后保持稳定。实际上，需求与设计和实现之间经常存在共同的交互。例如，当软件架构师发现某些质量目标对于计划的硬件资源来说是不现实的，或者当开发人员试图实现一些需求并意识到一些想法是不可行的（例如，在原型中）时，团队可能会重新审视需求，甚至可能改变或削弱整个系统的目标。同样，客户和利益相关者只有在看到系统运行时才可能发现问题或新想法，无论是作为早期原型还是部署的接近最终产品。但重要的是，需求可能发生变化这一事实并不是不引出或分析需求的理由。事实上，仔细考虑需求通常有助于及早发现问题并减少以后的更改。通常，考虑需求对于负责任的系统开发很重要，但需求很少被视为绝对给定的，项目应提供足够的灵活性以应对变化。
许多低风险项目将摆脱非常轻量级和非正式的需求工程流程，其中开发人员在构建系统时逐步考虑需求，向早期用户展示最少的可行产品以接收反馈，并且只做最少的笔记。然而，我们认为许多带有机器学习组件的软件项目都非常雄心勃勃，并且有很大的潜在危害——因此我们强烈建议具有机器学习组件的风险更大的项目认真对待需求工程，并清楚地考虑需求、假设和规格。当从概念验证原型过渡到实际产品时，将与需求的更深入参与延迟到项目后期可能完全没问题。但是，如果错误和有偏见的预测可能会造成伤害，或者如果恶意行为者可能有攻击系统的动机，那么最终更仔细地参与需求将有助于在部署有缺陷或有害的系统设计之前预测和缓解许多问题产品走向世界。
概括
需求工程对于在深入构建之前及早考虑问题和解决方案非常重要。许多软件问题源于糟糕的需求而不是错误的实现，包括安全性、公平性和安全性问题——这类需求问题以后很难修复。
为了理解需求，明确地考虑现实世界中的系统需求与技术解决方案的软件规范不同，以及确保系统需求与软件行为所需的假设是有用的。有和没有机器学习的软件系统中的许多问题都来自有问题的假设，对需求工程的投资可以帮助及早识别和缓解这些问题。
引出需求的过程很容易理解，通常涉及与各种利益相关者的访谈，然后是最终需求的综合和谈判。然后可以记录和评估由此产生的需求。
机器学习对于需求工程整体而言并没有太大变化。我们可能关心额外的品质，设定更雄心勃勃的目标，期待更多的风险，并面临更多不切实际的假设，但一般需求工程过程仍然相似。随着机器学习的野心和风险的增加，对于具有机器学习组件的软件项目而言，对需求工程的投资可能比对于没有机器学习组件的普通软件项目更为重要。
延伸阅读
- 关于需求工程的优秀标准教科书，比我们在这里可以做的更深入： Van Lamsweerde，Axel。 需求工程：从系统目标到 UML 模型再到软件 .约翰威利父子公司，2009 年。
- 关于需求工程挑战的开创性软件工程论文，特别是没有清楚地区分世界现象和机器现象： Jackson，Michael。 “ 世界与机器 。”在国际软件工程会议论文集上。 IEEE，1995 年。
- 论文强烈主张在使用 ML 组件构建软件时需求工程的重要性，包括讨论应考虑的各种附加质量，例如数据质量、出处和监控： Vogelsang、Andreas 和 Markus Borg。 “ 机器学习的需求工程：数据科学家的观点 。”在过程中。 2019 年第六届需求工程人工智能国际研讨会 (AIRE)。
- 论文概述了需求工程如何有助于更好地理解问题的领域和上下文，以及这如何有助于更好地管理用于模型训练和评估的高质量数据集： Rahimi、Mona、Jin LC Guo，萨哈尔·科卡利和玛莎·切奇克。 “ 迈向机器学习组件的需求规范 。” 2019 年 IEEE 第 27 届国际需求工程会议研讨会 (REW)，第 241-244 页。 IEEE，2019。
- 机器学习论文明确考虑了世界与机器之间的差异，以及如何将公平视为系统问题，而不仅仅是模型问题： Kulynych、Bogdan、Rebekah Overdorf、Carmela Troncoso 和 Seda Gürses。 “ POT：保护优化技术 。”在 2020 年公平、问责和透明度会议记录中，第 177-188 页。 2020 年。
- 立场文件主张需求工程的重要性，并在医疗保健环境中构建支持机器学习的产品时考虑许多不同的利益相关者： Wiens、Jenna、Suchi Saria、Mark Sendak、Marzyeh Ghassemi、Vincent X. Liu、Finale Doshi-Velez , 肯尼斯·荣格等人。 “不要伤害：负责任的机器学习用于医疗保健的路线图。”自然医学 25，没有。 9 (2019): 1337–1340。
- 一篇论文说明了在考虑机器学习的公平性时在系统级别参与需求工程以及协商不同利益相关者的偏好的重要性： Bietti，Elettra。 “ 从伦理洗礼到伦理抨击：从道德哲学看科技伦理 。”在 2020 年公平、问责和透明度会议记录中，第 210-219 页。 2020 年。
- 使用角色从另一个人的角度推理需求的示例： Guizani、Mariam、Lara Letaw、Margaret Burnett 和 Anita Sarma。 “ 作为质量要求的性别包容性：实践和陷阱 。” IEEE 软件 37，没有。 6（2020）。
与所有章节一样，本文在知识共享 4.0 BY-SA 许可下发布。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
