业务分析师的需求收集

卓越的用户体验在于让最终用户能够实现他们的目标，无论是网站、软件系统还是产品。为了满足他们的需求，我们需要了解他们的工作和工作环境。软件开发生命周期的第一个基本阶段是需求收集。它提供了清晰、简洁且经过一致同意的客户需求集，软件应该满足这些需求。业务分析师和主题专家负责需求收集过程。

业务客户往往期望软件团队能够洞察他们的想法，并根据未说出口或未知的需求交付解决方案。因此，所有需求都需要正式记录在一个庞大的文档中。

需求收集流程

征求和收集业务需求是每个项目的重要第一步。为了弥合业务需求和技术需求之间的差距，业务分析师必须充分理解给定环境中的业务需求，将这些需求与业务目标相协调，并适当地向利益相关者和开发团队传达这些需求。为此，他们需要确保需求使用双方都能理解的语言编写。

此阶段旨在定义每个项目都应理解和定义的业务目标，以便可以根据项目为业务带来的价值来确定所有工作的优先级。

以下是此阶段将进行的活动。

在此阶段，提取适当的信息以准备编写需求文档。有很多不同的业务分析技术可以用来收集需求及其优先级，包括研讨会、辅助访谈、观察或原型（可在单独的文章中讨论）。

此处将识别利益相关者类别，即想要构建产品的客户、将为此付费的客户、最终用户以及将受到影响的其他利益相关者。然后，将利益相关者类别映射到业务目标。确定所需输入以及每个已识别利益相关者类别的参与程度和影响力。必须确定利益相关者代表和决策者。

在此阶段，将验证和确认规则是否不清楚、不完整、含糊不清或自相矛盾。必须确定需求的类别（功能性或非功能性）并确定其优先级。

收集、编写和发布利益相关者的需求。建立命名约定和定义。将需求追溯到来源。记录事实和假设。

与利益相关者一起验证需求的生命周期，从其起源，到其开发和规范，再到其后续部署和使用。它确保由于遗漏的需求而在已开发的系统中没有任何范围“漏洞”。此活动还确保所有需求在内部彼此一致。

这是利益相关者对需求的安全接受。此步骤是用户实际的“签字确认”，并为配置工作启动奠定了基础。

**需求**是对拟议系统必须做什么或充分做什么才能解决客户问题的预期陈述。在利益相关者提出需求后，业务分析师的角色是进一步定义、分析、验证和确定需求陈述的优先级。

作为整体的需求集代表利益相关者之间达成的协议。需求的集合是需求文档。为了有效地实施和衡量需求，它们必须具体、明确且清晰。

**业务需求——**企业需求、目标和目标的高级陈述。它们确认项目的范围并识别利益相关者。它们通常描述系统或解决方案应该做什么。业务需求应始终从客户的角度编写。尽管它们是高级的广泛需求，但应详细说明组织的需求“是什么”以及为什么应该满足这些需求。

**利益相关者需求——**这些陈述描述了利益相关者为实施解决方案而需要的东西或遇到的问题，无论这些问题与组织或运营问题有关。利益相关者需求充当业务需求与其他类别解决方案需求之间的连接器。它将用户置于关注的中心，并使用流程图、用例图、用例场景和其他流程模型进行描述。

**解决方案需求——**它们描述了利益相关者希望如何实施业务和利益相关者需求的解决方案。它们通常细分为子类别

**功能需求——**功能需求描述了开发人员必须构建到产品中的产品的范围、功能、行为以及与其他系统的连接。它们精确地描述了软件必须执行的任务。它们还定义了系统必须符合的业务规则。

业务分析师将通过开发用例（如下所述）来捕获和验证功能需求。

**非功能需求——**非功能需求定义了系统的质量特性、约束或标准，系统必须具备或符合这些标准。它们将描述系统的外观和感觉。它们决定系统的视觉属性、可用性和性能要求——大小、速度等。它们还包括产品的预期运行环境、可维护性、可移植性、可靠性、安全性等。
**过渡需求——**临时功能，用于过渡到新系统。它们本质上总是临时的，因为只有在定义了现有解决方案和新解决方案之后才能开发它们。

用例描述了计算机软件系统的行为和功能需求。它们为所有人提供了一种简单的格式，以便快速掌握系统的功能。现有系统——在使用现有系统时，可以使用它来快速激发想法。

它们描述了用户为了完成给定任务而执行的一系列典型操作。用例模型由以下部分组成——一组用例——可选描述或图表，指示它们之间的关系。

使用用例图，用例之间的关系是显而易见的。在下图中，参与者表示为简笔画，每个用例表示为椭圆形。箭头显示参与者与用例之间以及各种用例之间的关系。

需求收集是一个相当冗长且详细的过程。毋庸置疑，系统越大，流程就越复杂。需求管理流程将有助于控制成本、避免需求蔓延并确保端到端的可追溯性。其优势在于，此流程将帮助您在预设计阶段收集大部分需求，定义和确定其优先级，避免重复并设置标准以衡量已实施的程度。

塞缪尔·萨姆

更新于：2020年7月14日

4K+ 次浏览

通过完成课程获得认证