软件工程/规划/需求简介

需求分析是系统工程和软件开发流程的第一个阶段。

需求分析 在系统工程和软件工程中，包括确定新产品或更改产品的需求或条件所需的任务，同时考虑到各种利益相关者（如受益者或用户）之间可能相互冲突的需求。

需求分析对开发项目的成功至关重要。 需求必须有文档记录、可操作、可衡量、可测试、与已识别的业务需求或机会相关，并且定义到足以进行系统设计的细节级别。需求可以是架构性的、结构性的、行为的、功能性的和非功能性的。

概述

从概念上讲，需求分析包括三种类型的活动

• 需求收集：与客户和用户沟通以确定他们的需求的任务。这有时也称为需求收集。
• 需求分析：确定所述需求是否不清楚、不完整、模棱两可或矛盾，然后解决这些问题。
• 记录需求：需求可以以各种形式记录，例如自然语言文档、用例、用户故事或流程规范。

需求分析可能是一个漫长而艰巨的过程，在此过程中会涉及许多微妙的心理技巧。新系统会改变人们之间环境和关系，因此必须识别所有利益相关者，考虑到他们的所有需求，并确保他们了解新系统的含义。分析师可以使用多种技术从客户那里获取需求。从历史上看，这包括进行访谈或进行焦点小组（在这个语境中更恰当地称为需求研讨会）以及创建需求清单。更现代的技术包括原型设计和用例。在必要时，分析师将使用这些方法的组合来确定利益相关者的确切需求，以便生产出满足业务需求的系统。

需求工程

系统需求分析也称为需求工程。 有时它被松散地称为需求收集、需求捕获或需求规范。术语需求分析也可以专门用于分析本身，而不是需求的收集或记录，例如。需求工程可以分为离散的时间步骤

• 需求收集，
• 需求分析和协商，
• 需求规范，
• 系统建模，
• 需求验证，
• 需求管理。

Laplante (2007) 认为需求工程是“系统工程和软件工程的一个分支，它关注确定硬件和软件系统的目标、功能和约束”。 在某些生命周期模型中，需求工程过程从可行性研究活动开始，该活动会导致可行性报告。如果可行性研究表明应开发该产品，则可以开始需求分析。如果需求分析先于可行性研究，这可能会促进跳出框框的思考，那么在最终确定需求之前，应确定可行性。

需求分析主题

利益相关者识别

请参阅利益相关者分析，了解业务用途。利益相关者 (SH) 是对系统有合法利益的人或组织（如公司、标准机构等法律实体）。他们可能会直接或间接地受到系统的影响。1990 年代的主要新重点是关注利益相关者的识别。人们越来越认识到，利益相关者不仅限于雇用分析师的组织。其他利益相关者将包括

• 任何操作系统的人员（正常操作员和维护操作员）
• 任何从系统中受益的人员（功能性、政治性、财务性和社会性受益者）
• 任何参与购买或采购系统的人员。在大众市场产品组织中，产品管理、营销和有时销售部门充当替代消费者（大众市场客户）来指导产品开发
• 监管系统各个方面的组织（财务监管机构、安全监管机构和其他监管机构）
• 反对系统的人或组织（负面利益相关者；另请参见误用案例）
• 负责与正在设计的系统进行接口的系统组织
• 与分析师为其设计系统的组织进行水平整合的组织

利益相关者访谈

利益相关者访谈是需求分析中常用的技术。尽管它们通常本质上是特异性的，并且专注于利益相关者的观点和感知需求，但通常没有更大的企业或系统背景，但这种视角缺陷通常具有获得更深入了解利益相关者独特业务流程、与决策相关的业务规则和感知需求的优势。因此，该技术可以作为一种手段来获取通常不会在联合需求开发会议中获得的集中知识，在这些会议中，利益相关者的注意力被迫承担更多跨职能的背景。此外，访谈的面对面性质提供了一个更轻松的环境，可以详细探讨思路。

联合需求开发 (JRD) 会议

需求通常具有跨职能的影响，这些影响是单个利益相关者不知道的，并且在利益相关者访谈期间经常被遗漏或定义不完整。这些跨职能的影响可以通过在受控环境中进行 JRD 会议来引出，由训练有素的协调员主持，利益相关者参与讨论以引出需求，分析其细节并发现跨职能的影响。应有专门的记录员和业务分析师在场记录讨论。利用训练有素的协调员的技能来指导讨论，使业务分析师能够专注于需求定义过程。

JRD 会议类似于联合应用设计会议。前者，会议收集指导设计的要求，而后者收集满足收集到的需求的特定设计功能。

合同式需求清单

记录需求的一种传统方法是合同式需求清单。在复杂的系统中，此类需求清单可能长达数百页。

一个合适的比喻是一个非常长的购物清单。这些清单在现代分析中非常不受欢迎；因为它们在实现其目标方面非常失败；但它们至今仍被视为。

优势

• 提供需求清单。
• 为项目发起人（人）和开发人员提供一份合同。
• 对于大型系统，可以提供高级别的描述。

劣势

• 此类清单可能长达数百页。实际上不可能通读此类文档并对系统有连贯的理解。
• 此类需求清单抽象了所有需求，因此几乎没有上下文。

• 这种抽象使得无法了解需求如何拟合或协同工作。
• 这种抽象使得难以正确地优先考虑需求；虽然清单确实可以轻松地优先考虑每个单独的项目，但从上下文中删除一个项目可能会使整个用例或业务需求变得毫无用处。
• 这种抽象增加了误解需求的可能性；随着更多人阅读它们，对设想系统的（不同）解释的数量会增加。
• 这种抽象意味着很难确定是否拥有大多数需求。这些文档必然会笼统地描述；但正如人们常说的，细节决定成败。

• 这些清单在利益相关者和开发人员之间创造了一种虚假的相互理解。
• 这些合同风格的清单让利益相关者产生一种错误的安全感，认为开发人员必须实现某些东西。但是，由于这些清单的性质，它们不可避免地会错过在流程后期发现的关键需求。开发人员可以使用这些发现的需求来重新协商对他们有利的条款和条件。
• 这些需求清单对系统设计没有任何帮助，因为它们不适合应用。

需求清单的替代方案

作为大型预定义需求清单的替代方案，敏捷软件开发使用用户故事以日常语言来定义需求。

可衡量的目标

最佳实践将编制的需求清单仅仅视为线索，并反复询问“为什么？”直到发现实际的业务目的。利益相关者和开发人员然后可以设计测试来衡量到目前为止每个目标的实现程度。此类目标的变化速度比一长串具体但未衡量的需求慢得多。一旦建立了一小组关键的可衡量目标，就可以进行快速原型设计和短迭代开发阶段，从而在项目完成一半之前就交付实际的利益相关者价值。

原型

在 1980 年代中期，原型被认为是解决需求分析问题的最佳解决方案。原型是应用程序的模型。模型允许用户可视化尚未构建的应用程序。原型帮助用户了解系统的外观，并使用户更容易做出设计决策，而无需等待系统构建。随着原型的引入，用户和开发人员之间通信的重大改进经常被看到。对应用程序的早期观点导致后期更改较少，因此大大降低了总体成本。

然而，在接下来的十年中，虽然证明是一种有用的技术，但原型并没有解决需求问题。

• 管理者一旦看到原型，可能很难理解最终设计不会在一段时间内完成。
• 设计师经常感到被迫在实际系统中使用拼凑的原型代码，因为他们害怕“浪费时间”重新开始。
• 原型主要帮助做出设计决策和用户界面设计。但是，它们无法告诉你最初的需求是什么。
• 设计师和最终用户可能过于关注用户界面设计，而对生产服务于业务流程的系统关注不足。
• 原型适用于用户界面、屏幕布局和屏幕流程，但对于可能涉及复杂数据库更新和/或计算的批处理或异步流程，则不太有用。

原型可以是平面图（通常称为线框）或使用合成功能的工作应用程序。线框是在各种图形设计文档中制作的，并且通常从设计中删除所有颜色（即使用灰度调色板），在最终软件预计会应用图形设计的情况下。这有助于避免对应用程序的最终视觉外观和感觉产生混淆。

用例

用例是一种用于记录新系统或软件更改的潜在需求的技术。每个用例都提供一个或多个场景，这些场景传达了系统应该如何与最终用户或其他系统交互以实现特定业务目标。用例通常避免使用技术术语，而是偏向于使用最终用户或领域专家的语言。用例通常由需求工程师和利益相关者共同撰写。

用例是用于描述软件或系统行为的看似简单的工具。用例包含对所有用户可以与软件或系统交互的方式的文本描述。用例不描述系统的任何内部工作原理，也不解释该系统将如何实现。它们只是展示了用户执行任务所遵循的步骤。所有用户与系统交互的方式都可以用这种方式描述。

软件需求规格说明

软件需求规格说明 (SRS) 是对要开发系统的行为的完整描述。它包括一组用例，这些用例描述了用户将与软件进行的所有交互。用例也称为功能需求。除了用例之外，SRS 还包含非功能性 (或补充) 需求。非功能性需求是规定设计或实现约束 (例如性能需求、质量标准或设计约束) 的需求。

IEEE 830-1998 描述了软件需求规格说明的推荐方法。该标准描述了软件需求规格说明的可能结构、理想内容和质量。

⇔== 需求类型 == 需求以多种方式进行分类。以下是与技术管理相关的常见需求分类：

客户需求

事实和假设的陈述，这些事实和假设根据任务目标、环境、约束以及效力和适用性衡量标准 (MOE/MOS) 来定义对系统的期望。客户是执行系统工程八个主要功能的人，特别强调操作员作为关键客户。操作需求将定义基本需求，至少会回答以下清单中提出的问题：

• 操作分配或部署：系统将在哪里使用？
• 任务概况或场景：系统将如何完成其任务目标？
• 性能和相关参数：完成任务的关键系统参数是什么？
• 使用环境：各种系统组件将如何使用？
• 效力要求：系统在执行任务时必须有多有效或高效？
• 操作生命周期：系统将被用户使用多长时间？
• 环境：系统将在哪些环境中有效地运行？

架构需求

架构需求通过识别系统所需的系统架构来解释必须做什么。

结构需求

结构需求通过识别系统所需的结构来解释必须做什么。

行为需求

行为需求通过识别系统所需的行為来解释必须做什么。

功能需求

功能需求通过识别必须完成的必要任务、动作或活动来解释必须做什么。功能需求分析将用作功能分析的顶层功能。

非功能需求

非功能性需求是指定可用于判断系统操作的标准而不是特定行为的需求。

性能需求

必须执行任务或功能的程度；通常以数量、质量、覆盖范围、及时性或准备情况来衡量。在需求分析过程中，将根据系统生命周期因素在所有确定的功能中交互地开发性能 (执行得有多好) 需求；并以其估计的确定性程度、对系统成功的关键程度及其与其他需求的关系来表征。

设计需求

技术数据包和技术手册中表达的产品“制造到”、“编码到”和“购买到”要求，以及流程的“如何执行”要求。

派生需求

从更高层需求中隐含或转换来的需求。例如，对长距离或高速的需求可能会导致对低重量的设计需求。

分配需求

通过将高层需求划分或分配成多个低层需求而建立的需求。例如：一个 100 磅重的物品由两个子系统组成，可能会导致两个低层物品的重量需求分别为 70 磅和 30 磅。

著名的需求分类模型包括惠普公司开发的 FURPS 和 FURPS+。

需求分析问题

利益相关者问题

史蒂夫·麦康奈尔在他的著作《快速开发》中详细介绍了用户如何妨碍需求收集的几种方法

• 用户不了解他们想要什么，或者用户对他们的需求没有明确的认识
• 用户不会承诺一组书面需求
• 用户在成本和时间表确定后坚持提出新的需求
• 与用户的沟通缓慢
• 用户通常不参与评审，或者无法参与评审
• 用户在技术方面不够成熟
• 用户不了解开发流程
• 用户不了解当前的技术

这可能会导致即使系统或产品开发已经开始，用户需求仍然不断变化。

工程师/开发人员问题

工程师和开发人员在需求分析过程中可能遇到的问题是

• 技术人员和最终用户可能使用不同的词汇。因此，他们可能错误地认为自己完全达成一致，直到最终产品交付。
• 工程师和开发人员可能会尝试使需求适合现有系统或模型，而不是开发一个专门满足客户需求的系统。
• 分析通常由工程师或程序员进行，而不是由具有沟通技巧和领域知识的人员来正确理解客户需求。

尝试的解决方案

解决沟通问题的一种尝试方法是聘用商业或系统分析方面的专家。

20 世纪 90 年代引入的技术，如原型、统一建模语言 (UML)、用例和敏捷软件开发，也旨在解决以前方法遇到的问题。

此外，一类新的应用程序模拟或应用程序定义工具已经进入市场。这些工具旨在弥合业务用户和 IT 组织之间的沟通差距，同时允许应用程序在生产任何代码之前进行“试销”。这些工具中最好的工具提供

• 电子白板，用于绘制应用程序流程并测试替代方案
• 捕获业务逻辑和数据需求的能力
• 生成高保真原型，这些原型密切模拟最终应用程序
• 交互性
• 添加上下文需求和其他注释的能力
• 远程和分布式用户运行和与模拟进行交互的能力

进一步阅读

• Laplante，Phil（2009）。 软件和系统需求工程 （第 1 版）。 华盛顿州雷德蒙德：CRC 出版社。 ISBN 1-42006-467-3.
• 麦康奈尔，史蒂夫（1996）。 快速开发：驯服疯狂的软件时间表 （第 1 版）。 华盛顿州雷德蒙德：微软出版社。 ISBN 1-55615-900-5.
• Wiegers, Karl E. (2003). 软件需求 (第二版). 雷德蒙德，华盛顿州：微软出版社。 ISBN 0-7356-1879-8.
• Andrew Stellman 和 Jennifer Greene (2005). 应用软件项目管理. 剑桥，马萨诸塞州：O'Reilly Media。 ISBN 0-596-00948-8.
• Brian Berenbach，Daniel Paulish，Juergen Katzmeier，Arnold Rudorfer (2009)。 软件和系统需求工程：实践. 纽约：McGraw-Hill 专业出版社。 ISBN 0-07-1605479.{{cite book}}: CS1 maint: 多个姓名：作者列表 (link)
• Walter Sobkiw (2008). 通过创造性系统工程实现可持续发展. 新泽西州：CassBeth。 ISBN 0615216307.

• Walter Sobkiw (2011). 系统实践作为常识. 新泽西州：CassBeth。 ISBN 978-0983253082.

外部链接

• 使用 UML 的软件需求分析 文章由 Dhiraj Shetty 撰写。
• 需求工程流程“好东西”
• 需求工程：路线图 (PDF) 文章由 Bashar Nuseibeh 和 Steve Easterbrook 在 2000 年撰写。