[架构之路-246]：目标系统 - 设计方法 - 软件工程 - 需求工程- 需求开发：获取、分析、定义、验证

前言：

架构师为什么需要了解需求分析

一、需求工程概述

1.1 概述

1.2 需求工程的两大部分

（1）需求开发：系统工程师的职责、目标系统开发角度

（2）需求管理：项目管理者的职责、项目管理的角度

二、需求开发的步骤

2.1 需求获取

2.1.1 需求收获的方法

2.1.2 需求的分类方法1：按分层分类

2.1.3 需求的分类方法2：按类型分类

2.1.4 需求的分类方法3：按期望分类

2.2 需求分析与图形化展示

2.2.1 结构化方法的需求分析

（1）概述

（2）数据模型：E-R图/实体关系图

（3）功能模型：数据流图DFD

（4）行为模型：状态转化图

2.2.2 面对对象方法的需求分析

（1）概述

（2）用例模型与用例图

2.3 需求规格化（需求规格说明书）

2.4 需求验证

2.4.1 需求评审

2.4.2 需求验证

前言：

需求开发从立项和项目可行性研究报告之后就开始了
需求开发属于问题领域的定义阶段，即属于问题领域，不属于软件开发阶段，属于实现领域。
需求是软件系统的愿景、目标
软件系统从需求阶段开始就可以建模，如UML图形，也就是说，描述需求，可以通过文字，也可以通过UML图形，通常是两者的结合。

架构师为什么需要了解需求分析

架构师在系统设计过程中扮演着关键的角色，需要了解用户需求分析，以便为系统设计提供指导和依据。

以下是架构师需要了解需求分析的理由：

确保系统满足用户需求：架构师的主要责任是设计一个满足用户需求的系统结构。因此，需要了解具体的用户需求，才能针对这些需求来设计系统结构，以确保系统能够在满足用户需求的前提下进行高效的运行。
与业务分析师和开发团队紧密合作：架构师需要与业务分析师以及整个开发团队紧密合作，以了解项目目标和细节。对于复杂的项目，需要架构师与业务分析师合作制定更为复杂的需求文档，并评估对应的技术方案，以保证各项技术决策是基于正确且完整的需求分析结果。
减少设计修改的成本：架构师需要确保系统设计可以一次性满足用户需求，以避免因为需求变更而进行不必要的设计修改。这需要架构师通过对用户需求的深入了解，规划并设计严密的系统结构，从而减少系统设计修改的成本。
评估和选择技术方案：架构师需要根据用户需求来评估和选择可能的技术方案。根据具体需求分析结果对系统结构进行深入考虑并选择适当的技术方案，以缩短开发时间并满足用户需求。
确保系统可扩展性和可维护性：最后，了解用户需求分析有助于架构师设计出可扩展性和可维护性更强的系统。通过选择适当的技术架构，架构师可以预测到系统的未来发展需求，从而确保系统可以无缝地扩展。

因此，了解需求分析是架构师工作的重要内容之一，它有助于架构师了解项目的目标和细节，设计一个关键的且能够满足用户需求的系统架构。

备注：

本文介绍的是需求开发的一般性方法，在实际产品的需求开发中，只解决了需求分析的“形式”问题，并不能解决需求开发的“内容”问题。因此，需求开发，除了一般性方法，还需要深厚的业务背景知识，如果没有业务背景知识，要做需求开发，只能是徒有其表！！！这是很多没有技术背景的管理者或跨行业专业技术人士，在做需求分析是面临的困难。

一、需求工程概述

1.1 概述

需求工程是软件工程的一个重要分支，它主要关注如何从用户、利益相关者以及其他相关方面获取和分析需求，以实现最终软件产品。需求工程常涉及以下活动：

需求获取：采用各种技术和方法从利益相关者获取需求，例如面谈、问卷、焦点小组、原型设计等。
需求分析：对需求进行细化和精化，以帮助确保需求的正确性和完整性，例如建模、需求测试、业务流程图等。
需求规格说明：将需求描述为明确的完整的、不矛盾的需求规格，以便于开发人员理解。
需求验证：确保需求的正确性和满足性，包括需求审查、测试、模拟等。

需求工程的目标是确保软件开发团队明确了用户的需求，以便于设计、开发和实施其软件产品。

1.2 需求工程的两大部分

（1）需求开发：系统工程师的职责、目标系统开发角度

需求开发是指从需求收集到需求规格化的过程，主要包括以下几个阶段：

需求识别：在需求收集的阶段，与用户、利益相关者沟通，了解他们的需求和期望。这可以通过面谈、问卷调查、访谈等方式进行。收集到的需求可能是明确的、模糊的或冲突的。
需求分析和整理：对收集到的需求进行分析和整理。这包括识别和消除需求之间的冲突，将模糊的需求转化为明确的需求，并对需求进行分类和排序，以便于后续的规格化和设计。
需求规格化：将需求转化为可被开发团队理解和实现的规格化文档或模型。常用的规格化方式包括用例图、需求规格书、用户故事等。规格化的需求应该包括功能需求、非功能需求（如性能、安全性要求）、界面设计等。
需求验证：对规格化的需求进行验证，确认其正确性和满足性。这可以通过需求审查、原型验证、用户测试等方式进行。验证的目的是确保需求的一致性、完整性和可行性，避免在后续的开发阶段出现问题。

需求开发的目标是清晰、准确地识别和规格化用户需求，为后续的系统设计和开发提供基础。它是软件开发过程中至关重要的一个环节，需要与用户和利益相关者密切合作，确保最终开发出符合用户期望的软件产品。

（2）需求管理：项目管理者的职责、项目管理的角度

需求管理涉及多个方面，其中与版本控制、变更控制、需求跟踪和需求状态跟踪相关的内容如下：

版本控制：在需求管理中，版本控制是指管理和控制需求文档的不同版本和变更历史记录的过程。通过版本控制系统，可以追踪需求文档的变更、记录每个版本的修改内容，并提供回滚到先前版本的能力。这样可以确保在软件开发过程中，对需求变更进行可追溯和可控制的管理。

变更控制：变更控制是在需求管理过程中控制需求变更的流程。它包括收集需求变更请求、评估变更影响、决策是否接受变更、协调变更实施，并确保变更能够正确地影响需求规格和后续的开发活动。变更控制的目的是保持需求的稳定性和一致性，防止无计划的变更对项目造成负面影响。

需求跟踪：需求跟踪是在需求管理中追踪和管理需求的状态和实现情况。通过需求跟踪系统，可以确保每个需求都有一个唯一的标识，并记录需求的相关信息，包括需求的状态、实现情况、测试结果等。需求跟踪的目的是帮助团队了解每个需求的进展情况，对于测试、验证和追溯需求的实现结果非常有用。

需求状态跟踪：需求状态跟踪是指监控和更新需求的状态的过程。需求状态可以包括多个维度，如需求的进展状态（待分析、已分析、待开发、已完成等）、需求的评审状态（待评审、已评审、通过、拒绝等）等。通过需求状态跟踪，可以清晰地了解每个需求的当前状态，帮助团队更好地安排和管理需求相关的工作。

综上所述，在需求管理过程中，版本控制、变更控制、需求跟踪和需求状态跟踪是重要的工具和方法，可以帮助团队有效地管理需求的变更、状态和实施情况，确保软件开发项目按计划和质量要求进行顺利进行。

二、需求开发的步骤

2.1 需求获取

2.1.1 需求收获的方法

需求收集是软件开发中至关重要的一个环节，它的质量直接影响到后续开发活动的成功。

以下是一些常见的需求收集方法：

立项文件和商业计划书（需求开发从立项和项目可行性研究报告之后）：该类文件通常描述项目的商业目标、市场分析、可行性研究和项目范围等，这些信息有助于确定项目的背景和前景，并收集相关需求信息。
面谈：与用户或利益相关者进行面对面的交流，了解他们的需求和期望。这种方法可以快速、直接地了解用户需求，但需要考虑时间和空间上的限制。
问卷调查：通过书面调查的方式收集需求。此种方法适用于样本较大的企业或用户，并且需要在制作调查问卷时仔细设计问题，以确保能准确收集需求信息。
需求研讨会：这是一种面对面的会议，旨在了解有关项目的详细信息，并确保其满足利益相关者的期望。通过研讨会议可以收集各方的需求和意见，并推进需求分析的进程。
观察和记录：通过对用户和利益相关者的观察和记录来了解他们的需求。观察记录有助于收集用户体验和使用情况方面的重要信息。
用户故事：这是敏捷开发中一种重要的需求收集方式。用户故事描述了用户进行特定操作所需的功能，通过编写用户故事可以快速获取用户需求并及时进行调整。
竞品分析：竞品分析是指针对一个产品或服务，在市场上已经存在的同类产品或服务进行分析和比较，以获取对该产品或服务的深入理解，并据此提出自己的需求规范。
市场调研报告：市场调研报告是一份关于特定市场的详细分析和评估的报告。它提供了有关市场潜力、竞争态势、目标用户和市场趋势的信息，以帮助企业做出战略决策和市场定位。

需要指出的是，不同的需求收集方法各有优劣，应根据项目的具体情况选择合适的方式。同时，需求收集的过程应当与用户和利益相关者紧密合作，确保收集到的需求准确、完整、合理，最终设计出令用户满意的系统。

2.1.2 需求的分类方法1：按分层分类

根据分层分类的方法，可以将需求分为以下几个层次：

业务需求、商业需求（公司管理层的职责）：需求从商业价值开始，这一层次的需求关注的是客户或用户的业务目标和需求，即需要解决的业务问题和提供的业务价值。它是最高层次的需求，描述了系统或软件产品应该做什么，与业务流程和业务规则密切相关。
用户需求/最终使用者（产品经理的职责）：用户需求是从最终用户的角度出发，描述了用户对系统或软件产品的期望、期望的功能、可用性、用户体验等方面的要求。它是将业务需求转化为用户可理解和期望的形式，为设计和开发团队提供指导。
系统需求（系统工程师的职责，是信息系统开发的难点）：系统需求是用户需求的具体化，涉及到信息系统的功能、性能、安全性、可靠性、可维护性等方面的要求。它是软件开发过程中，从用户需求到详细设计和实施的中间层次，以系统的角度描述了应该如何实现用户需求。
组件需求：组件需求是系统需求的具体化，将系统需求分解成系统组成部分的需求。它描述了各个组件或模块的功能、接口、性能、数据存储等方面的要求，为组件的设计和实现提供依据。

通过分层分类方法，可以将需求从高层次到低层次逐步细化和具体化，确保在需求定义和开发过程中的连贯性和一致性。这种分类方法使得需求的管理和跟踪更加清晰和有序，有助于实现需求的全面覆盖和有效实现。在实际应用中，可以根据项目的特点和需求分析的需要，合理地划分和管理不同层次的需求。

用户需求是从最终用户的角度描述的，重点在于描述所需功能和期望的行为，因此为设计团队提供了明确的方向和基础。然而，仅凭用户需求难以确保软件系统能够被正确地设计、实现和交付。

系统需求，又称为信息系统需求，作为在用户需求基础上进行进一步描述和扩展的补充，帮助开发团队澄清信息系统的工作原理、结构和接口要求，明确产品设计和开发目标。它包括详细的软件系统的功能、性能、可靠性、安全性、可维护性、可测试性和其他技术指标，如接口、数据、资源、约束和限制等。系统需求通常是由开发团队中的系统分析和设计人员编写，并在整个软件开发周期中被不断修订和更新。用户的需求，必须转化成软件系统的需求，才能被软件开发人员理解和实现，纯粹的用户需求是无法转化成软件架构和代码的！！！！

总结来说，系统需求的作用主要体现在以下几个方面：

澄清用户需求：通过对用户需求的进一步拆分和细化，系统需求可以澄清用户需求中总体性比较强、过于抽象或不完整的内容。
确保系统质量：系统需求包括对系统功能、性能和其他技术指标的详细描述和要求，有助于确保系统能够满足用户需求的同时，达到一定的质量要求。
促进系统设计和开发：系统需求为系统设计和开发提供了清晰的软件系统的目标要求，可以引导开发团队设计出更加符合用户需求且可行的系统结构和接口。
简化测试过程：系统需求确定了系统预期表现和成果，可以用来制定测试计划和测试用例，减少测试过程中的错误和漏洞。

综上所述，虽然用户需求是软件开发的核心，但系统需求是确保软件系统能够满足用户需求的关键要素之一。系统需求和用户需求相互补充，共同协作，有助于确保最终软件系统的质量和可用性。

2.1.3 需求的分类方法2：按类型分类

按类型分类是另一种常见的需求分类方法，根据需求的性质、特征或功能来进行分类。以下是按类型分类的一些常见需求类型：

功能需求：描述系统或软件产品应具备的功能或行为。例如，某个系统需要支持用户登录、数据查询、报表生成等功能。
非功能需求：描述系统或软件产品的性能、可靠性、安全性、可用性等方面的要求。例如，系统需要具备高并发处理能力、保证数据的完整性和保密性等。
约束性需求：描述对系统或软件产品实施和开发过程的限制和约束条件。例如，系统需要符合特定的法律法规、遵守标准或符合特定的技术架构。
接口需求：描述系统或软件产品与其他系统、组件或外部设备的交互和接口要求。例如，系统需要提供与第三方支付系统对接的接口。
数据需求：描述对数据的处理、存储、访问等方面的要求。例如，系统需要将数据存储到特定的数据库中，或者需要支持某种数据格式和数据传输方式。
性能需求：描述系统或软件产品在处理速度、响应时间、吞吐量等方面的性能要求。例如，对于高频交易系统，要求每秒能够处理上万笔交易。
安全需求：描述对系统或软件产品的安全保护要求。例如，系统需要具备身份认证、访问控制、数据加密等安全机制。
可维护性需求：描述系统或软件产品的可维护性要求，包括易于修改、易于测试和易于扩展等方面。例如，需要提供易于理解和维护的代码结构和文档。

以上仅是一些常见的需求类型，实际项目中可能会结合具体情况进行更细分的分类。按类型分类的方法有助于对不同类型的需求进行有针对性的管理和处理，使需求分析更加准确和有效。

2.1.4 需求的分类方法3：按期望分类

按期望分类是一种基于需求对用户期望的不同程度进行分类的方法。根据用户对需求的期望程度和优先级进行分类，可以帮助团队更好地理解用户需求的重要性和优先级，以便更好地满足用户的期望。以下是按期望分类的一些常见分类方法：

必备需求/基本需求：这类需求是用户最基本和最核心的需求，是满足用户的基本期望的需求。如果不能满足这类需求，用户将无法使用系统或软件产品。
关键需求/基本需求：这类需求是用户对系统或软件产品的关键期望，但不是必需的。如果不能满足这类需求，用户的使用体验或功能性将受到较大的影响。
期望需求：这类需求是用户对系统或软件产品的期望和愿望，是提高用户满意度和用户体验的需求。满足这类需求能够给用户带来额外的价值，但不影响系统或软件产品的基本功能。
兴奋性需求：是指用户对系统或软件产品特定功能的激动和喜爱程度，也被称作“激励性需求”或“欲望性需求”。这类需求通常不是用户使用系统或软件产品的必备需求，但是用户对此类功能有很高的期望，可以让用户感到特别愉悦或满足。在产品开发中，兴奋性需求可以作为产品差异化和市场竞争的一个重要方面。如果产品能够满足用户的兴奋性需求，用户有更大可能选择使用此产品，从而提高产品的市场份额和销售额。因此，对于开发团队来说，也应该对兴奋性需求进行充分了解，并考虑如何在产品设计和实现中为用户提供这些兴奋性需求，从而提高产品的价值和竞争力。
可选需求/镀金需求：这类需求是用户的额外期望，对系统或软件产品的使用并不关键。这类需求可以增加系统或软件产品的功能或灵活性，但不是必要的。

按期望分类的方法可以帮助项目团队更好地理解用户的期望和需求优先级，从而合理分配工作和资源，确保开发出符合用户期望的系统或软件产品。在实践中，可以根据真实项目的需求和用户需求分析结果进行具体的分类和管理。

2.2 需求分析与图形化展示

需求分析结果的图形化展示是一种常用的方式，可以帮助团队更好地理解和交流需求，并帮助他们在系统设计和开发过程中进行指导和决策。不同的需求分析方法，展现需求的图形是不同的。

结构化分析方法：实体关系图、数据流图、状态图

面对对象分析方法：类图、用例图、状态图、时序图等等.....

2.2.1 结构化方法的需求分析

（1）概述

结构化方法的需求分析是指通过一系列严谨而规范的步骤，对系统的需求进行清晰的描述和分析，以确定系统需要满足的功能和性能要求，以及系统与人、物、环境等相关方面之间的交互关系。

（2）数据模型：E-R图/实体关系图

E-R图（Entity-Relationship Diagram），也称为实体关系图，是一种数据建模工具，用于描述现实世界中实体（entity）之间的关系（relationship）。它是一种图形化的表示方法，能够清晰地展示数据模型中各个实体之间的关联和属性。

在E-R图中，实体用矩形框表示，关系用菱形连接实体，属性用椭圆形表示。

以下是E-R图中常用的符号和概念：

实体（Entity）：代表现实世界中具有独立实体性质的对象，例如人、物、地点等。每个实体都有一些属性，用于描述和区分实体之间的差异。
属性（Attribute）：描述实体的特征和性质，例如人的姓名、年龄、身高等。属性可以是简单的，也可以是复杂的，可以包含多个值。
关系（Relationship）：描述实体之间的联系和交互。关系可以是一对一、一对多或多对多的关系。例如，学生和课程之间的关系可以是学习关系，一个学生可以选择多门课程，一门课程可以由多个学生选修。
基本关系类型：包括一对一（1:1）、一对多（1:N）和多对多（M:N）关系。

E-R图提供了一种直观且易于理解的方式来描述数据模型，它是数据库设计和系统分析中常用的工具之一。通过E-R图的绘制和分析，可以帮助设计师和开发人员更好地理解系统的结构和数据流动，从而准确捕捉需求，设计出高质量、合理结构的数据库模型。

（3）功能模型：数据流图DFD

功能模型中的数据流图（Data Flow Diagram，简称DFD）是一种常用的建模工具，用来描述信息系统中的数据流动和处理过程。它通过图形化的方式展示了系统中数据的来源（输入）、去向（输出）、处理和存储等过程，帮助开发人员在系统设计时更好地理解系统中的数据流动。

在DFD中，

数据流用箭头表示，

数据处理用方框表示，

数据存储用平行四边形表示，

源和目标用椭圆形表示。

以下是DFD中常用的符号和概念：

数据流（Data Flow）：代表信息在系统中传递的路径，它可以是从数据源到数据目标的传输，也可以是在系统内部不同处理模块之间的数据传递。
处理（Process）：代表对数据进行处理、计算、转换或转发等操作的模块，它可以是计算机程序、人工处理或自动化的业务流程等。
数据存储（Data Store）：代表系统中数据的存储位置，可以是数据库、文件或其他数据存储设备。
源和目标（Source and Destination）：代表数据流的起点和终点，可以是外部来源或者系统内部的其他模块。
方向箭头：表示数据的流向，从源到目标或从处理模块到数据存储。

通过DFD的绘制和分析，可以帮助设计师和开发人员更好地理解系统中各个部分之间的数据流动，从而更好地分析系统的流程和逻辑。这样可以更准确地捕捉系统需求，设计出更合理的系统架构和流程，提高系统的设计效率和实现质量。

（4）行为模型：状态转化图

状态转换图（State Transition Diagram）是一种描述系统行为的图形化模型。它主要由状态、转移和事件组成，用于表示一个系统在不同状态之间的转换以及触发状态转换的外部事件。

在状态转换图中，状态表示系统所处的特定状态或条件。转移表示状态之间的切换，通常用箭头连接起来，箭头上可以标注触发转换的事件或条件。事件是引起状态转换的外部触发器，例如用户输入、信号到达等。

状态转换图往往用于描述系统的行为流程、状态机、协议或者算法等。它可以帮助开发人员理清系统的状态变化路径，从而更加清晰地分析和设计系统的逻辑。

请注意，行为模型的状态转化图可能因具体应用场景而异，因此，如果您有具体的应用场景，可以向我提供更多细节，我将尽力为您提供更精确的帮助。

2.2.2 面对对象方法的需求分析

（1）概述

在需求分析过程中，使用UML（统一建模语言）图是一种常见的方式来帮助描述、分析和传达系统的需求。

以下是几种常用的 UML 图形，在需求分析中经常用到：

用例图（Use Case Diagram）：用例图主要用于描述系统的功能需求和用户与系统之间的交互。它展示了系统的不同角色（参与者）和与系统交互的各种用例（功能场景），以及它们之间的关系。用例图帮助识别和定义用户需求，理解系统的主要功能和用户使用情景。
类图（Class Diagram）：类图主要用于描述系统的静态结构和对象之间的关系。它展示了系统中的类、属性、方法以及它们之间的关联、继承等关系。类图帮助识别和定义系统的数据模型，明确对象的行为和属性。
活动图（Activity Diagram）：活动图主要用于描述系统的业务流程、操作流程和控制流。它展示了系统中的活动、决策、并行处理等，以及它们之间的关系。活动图帮助澄清和定义系统的操作流程和用户交互。
状态图（State Diagram）：状态图主要用于描述系统的状态和状态之间的转换。它展示了系统的不同状态、状态之间的转换条件，以及状态转换时的行为。状态图帮助识别和定义系统的状态模型和状态转换逻辑。
顺序图（Sequence Diagram）：顺序图主要用于描述系统中对象之间的交互和消息传递顺序。它展示了一系列对象之间的时序关系，以及它们之间的消息发送和响应。顺序图帮助理解系统中不同对象之间的协作和通信。
协作图（Collaboration Diagram）：协作图（也称为通信图）主要用于描述系统中对象之间的协作关系和消息传递。它展示了对象之间的交互、消息传递和协作关系。协作图帮助识别和定义系统中不同对象之间的通信模式和交互情况。

使用这些 UML 图不仅有助于分析和表达系统需求，还可以在需求讨论、验证和文档编写过程中提供清晰的视觉表示。需要根据具体的需求和场景选择合适的 UML 图来支持需求分析工作。

（2）用例模型与用例图

用例模型是一种需求分析方法，用于描述系统的功能需求和用户与系统之间的交互。

而用例图是用例模型的一种图形化表示方式，用于可视化、交流和共享用例模型的信息。

用例模型包括以下几个主要元素：

用例（Use Case）：用例代表了系统的一项具体功能或业务场景，描述了用户和系统之间的交互过程。每个用例表示一个完整的功能，它描述了系统在特定情景下的行为和响应。
参与者（Actor）：参与者代表与系统进行交互的外部实体，可以是人、其他系统或设备。参与者在用例中扮演特定的角色，触发或参与到系统的某项功能中。参与者与用例之间通过交互实现功能。
关联关系（Association）：用例与参与者之间通过关联关系连接，表示参与者与用例之间的关系。一个参与者可以关联多个用例，一个用例也可以被多个参与者关联。
包含关系（Include）：包含关系表示一个用例包含或引用另一个用例的行为。包含关系用于描述通用的行为和流程，避免在多个用例中重复定义相同的步骤。
扩展关系（Extend）：扩展关系表示一个用例在某种情况下可以扩展另一个用例的行为。扩展关系用于描述可选的和可变的功能，可以根据特定条件进行扩展或修改。

用例图是用例模型的图形化表示，通过用例图可以清晰地展示系统的各个用例以及参与者之间的关系。用例图中的参与者通常以图标形式表示，用例以椭圆形式表示，参与者与用例之间通过实线箭头连接。用例图还可以用于描述用例之间的包含关系和扩展关系，通过虚线箭头表示。

用例图图形化地表达了系统功能和用户需求的关系，可以帮助团队更好地理解和讨论需求，促进系统设计和开发的沟通和协作。它可以提供一个高层次的系统视图，帮助识别和定义主要的用例和参与者，并构建全面的使用场景。

2.3 需求规格化（需求规格说明书）

2.4 需求验证

2.4.1 需求评审

需求评审是在需求分析之后，对需求规格说明书进行验收和审核的过程。目的是评估需求是否准确、清晰、完整且可实现，是否符合客户的需求和期望，是否能够满足系统的业务目标和约束条件，同时也能够检查是否存在遗漏、矛盾或不一致的需求。评审结果将成为系统开发的基础，对项目进展和开发过程的决策有着重要影响。

以下是几个常见的需求评审方法和技巧：

审查：审查是一种通过人工方法对需求文档进行检查的方式，可以使用多种审查技巧，例如逐字逐句审核、对比需求与业务目标、检查格式和排版等。这种方法具有低成本和高效性的优点，但也容易受到人为因素的影响。
专家判断：专家判断是通过邀请相关领域的专家来评估需求是否合理、准确、完整和可实现。这种方式可以减少某些着眼于形式而不是内容的差错，但评审的精确度和范围也会受到专家的经验和知识水平的影响。
问卷调查：通过设计调查问卷或访谈的方式让用户和其他利益相关者对需求进行评价，进而确定需求的准确性和可行性。这种方法可以收集更广泛的意见和反馈，但结果也容易受到采样误差和回答者的主观偏见的影响。
原型测试：原型测试是通过构建最小可行产品（MVP）或原型来评估需求是否准确、完整、可实现。这种方法可以快速发现和纠正需求中的问题，同时也能够提供更具体、更直观的需求体验。

在进行需求评审时，需要注意以下事项：

把需求评审看作是发现和解决问题的过程，不要把评审当成是检验和批判的过程。
评审团队需要由不同领域的人员组成，包括开发人员、测试人员、用户或客户代表等，以确保全面评估需求的准确性和可行性。
确保评审的措辞明确、准确、可行，并考虑到需求的实际实现难度和约束条件。
记录评审过程中引发的问题和发现的瑕疵，确保这些问题被解决并更新需求文档。

需求评审是确保项目成功和满足客户期望的重要步骤，通过不断评审和反馈，我们可以及早发现并解决问题，确保需求规格说明书的准确性和完整性，从而为后续的系统设计、开发和测试提供更精确的指导。

2.4.2 需求验证

需求验证是在需求分析和规划阶段之后，以确保需求规格说明书中所记录的需求是正确且满足用户期望的过程。验证需求的目的是确认系统是否能够按照需求规格说明书的要求进行设计、开发和实施，并且能够提供预期的功能和价值。

以下是几个常见的需求验证方法和技巧：

验证文档一致性：审查需求规格说明书和其他相关文档，确认需求的描述和说明与其他文档之间的一致性。文档一致性的验证可以避免需求之间的冲突、遗漏或不一致。
验证用户反馈：与用户或客户进行定期的沟通和反馈，以确认系统是否满足了他们的实际需求和期望。用户反馈可以从用户的角度提供宝贵的意见和建议，帮助改善系统的功能和用户体验。
验证技术规格：将需求规格与技术规格进行对比，确认系统是否满足了技术规格中规定的功能、性能和可靠性要求。通过技术规格的验证，可以确保系统能够按照技术要求进行设计和开发。
验证系统可行性：评估所提出的需求是否与系统架构、技术能力和资源可行性相匹配。通过验证系统的可行性，可以避免提出无法实现的需求或超出可接受范围的需求。
验证原型或演示：构建一个最小可行产品（MVP）或原型，并进行演示，以验证系统是否满足了用户的期望和需求。原型验证可以帮助用户更好地理解和评估系统的功能和界面，从而提供及时的反馈和修正。
验证测试用例：设计一组测试用例，并在系统中执行这些测试用例，以验证系统是否能够按照需求规格进行正确操作和输出预期结果。测试用例的验证可以帮助发现功能缺陷、逻辑错误和性能问题。