需求分析，也称为需求工程，是定义用户对正在构建或修改的新软件的期望的过程。在软件工程中，有时用会用需求收集或需求捕获之类的名称来指代它。需求分析包括确定新产品或项目需要满足其需求或条件的任务，其中要考虑到各个需求相关人员可能的冲突需求，分析、记录、验证和管理软件或系统需求。这是在软件项目的早期阶段执行需求分析的目标：

从是什么到怎么做：软件工程任务弥合了系统需求工程和软件设计之间的鸿沟。

3个常规视图：为软件设计人员提供以下模型：

系统信息（静态视图）

功能（功能视图）

行为（动态视图）

软件架构：模型可以转换为数据，架构和组件级设计。

迭代和增量过程：希望在分析过程中进行一些设计，在设计过程中进行一些分析。

什么是需求？

软件需求是用户解决问题或实现目标所需要的一种能力。换句话说，需求是系统或系统组件必须满足或拥有的软件功能，才能满足合同，标准，规范或其他正式施加的文档要求。最终，我们要实现的目标是开发高质量的软件，以在预算内按时满足客户的实际需求。

软件开发人员可能面临的最大挑战是与客户共享最终产品的愿景。项目中的所有利益相关者-开发人员，最终用户，软件经理，客户经理-必须对产品的用途和目的达成共识，否则当产品交付时会有人感到意外，软件中的意外几乎从来都不是好消息。

因此，在指定软件产品要求时，我们需要一些方法来准确地捕获，解释和表示客户的声音。

需求分析活动

需求分析对于系统或软件项目的成功或失败至关重要。需求应被记录，可操作，可测量，可测试，可追溯，与已确定的业务需求或机会相关，并定义为足以进行系统设计的详细程度。从概念上讲，需求分析包括四种类型的活动：

提出需求：与客户和用户进行沟通以确定他们的要求是什么的任务。有时也称为需求收集。

分析需求：确定所陈述的需求是否不清楚，不完整，模棱两可或矛盾，然后解决这些问题。

需求建模：需求可以以各种形式记录下来，例如自然语言文档，用例，用户案例或流程规范。

评审和回顾：团队成员对迭代中发生的事情进行反思，并确定未来的改进措施。

需求分析是团队的一项工作，需要硬件，软件和人为因素的工程专业知识以及与人打交道的技能的结合。以下是需求分析中涉及的主要活动：

识别客户的需求。

评估系统的可行性。

进行经济和技术分析。

将功能分配给系统元素。

建立时间表和约束条件。

创建系统定义。

需求分析技术

需求分析可帮助组织确定利益相关者的实际需求。同时，它使开发团队可以使用他们理解的语言（例如图表，模型，流程图）而不是文本页面与利益相关者进行沟通。

收集需求后，收集需求后，我们会在软件需求规范（SRS）文档，用例或用户案例中记录需求，与利益相关者共享以供确认。这个文档对于普通用户和开发人员都很容易理解。需求的任何变更也要记录在案，并通过变更控制程序并在批准后最终确定。

业务需求与软件需求

业务计划或项目需要各种需求，以帮助定义目标并确定将要开展的工作的范围。需求还提供了衡量进展和成功的上下文和客观方法。一旦建立了业务需求，就可以定义和开发软件需求，以推进项目。

业务需求

业务需求与业务目标，愿景和目标有关。它们还提供了需要通过特定活动或项目解决的业务需求或问题的范围。例如，如果某个行业协会的目标是促进其成员提供的服务，那么项目的业务需求可能包括创建一个成员目录，以提高成员的认知度。良好的业务要求必须是：

清晰，通常在一个非常高的级别定义。

提供足够的信息和指导，以帮助确保项目满足已确定的需求。

了解组织的任务，目的或目标，特定的业务需求或正在解决的问题

在制定业务需求之前应明确定义和理解。

需求或问题可以与组织或企业总体相关，也可以关注于利益相关者群体，如客户，客户，供应商，员工或其他人群。

软件需求

软件需求细分了满足业务需求的步骤。业务需求说明了项目的“原因”，而软件需求则概述了“内容”。

例如，如果业务要求是为行业协会创建会员目录，那么软件需求将概述谁有权访问该目录，成员如何在该目录中注册，谁将拥有数据的所有权，哪种车辆或车辆将要使用。将使用什么车辆（例如网站或纸）质目录）等等

发现业务需求的技术

根据业务改进和软件开发过程，可以使用各种需求分析技术。下面列出了其中一些技术。

使用BPMN或ArchiMate进行差距分析

差距通常被称为“您所在的位置和您想要的位置之间的空间”。差距分析是基准业务情景与目标业务情景之间的比较过程。换句话说，差距分析是对企业当前正在做的事情以及未来方向的研究，并且被认为是弥合它们之间的空间的一种手段。差距分析的目的是找出优化性能方面的差距。这为企业提供了对潜在改进的洞察力。它回答诸如项目当前状态是什么的问题？我们要在哪里？等等。

ArchiMate-差距分析

ArchiMate是一种开放且独立的企业体系结构建模语言，可以以明确的方式支持在业务域内和跨业务域的体系结构的描述，分析和可视化。这是一个完美的建模工具，并且符合执行差距分析的要求。

BPMN-现状和未来分析

原有流程

我们将要演示的示例是关于销售商品的在线商店的当前状况（即流程）。该过程开始于销售代表从客户那里收到采购订单，然后继续检查库存水平。如果手头有足够的库存来应付订单，销售代表会把它们打包。这一过程结束时将它们与发票一起运输。如果库存不足，销售代表将建议客户修改采购订单。

待定程序

假设我们的业务发展得非常快，以至于我们现在有一个仓库来储存我们的存货。因此，我们正在寻找改进现有流程的方法，以更好地分配新资源。此外，我们将在下面的流程图中显示对增强的功能进行建模的示例。

业务动机模型

如果企业为其业务活动规定某种方法，么它应该能够说明该方法想要实现的原因和结果。业务动机模型(BMM)是一种OMG建模符号，用于支持关于如何对变化的世界作出反应的业务决策。企业将通过获取BMM建模工具，然后创建自己的BMM-用特定于企业的业务信息填充模型。有两个主要目的：

捕获关于对变化的反应的决策和做出决策的基本原理，以目的是使决策具有可分享性，提高清晰度并通过汲取经验教训来改进决策。

参考决策结果对运营业务的影响（例如，对业务流程和组织职责的更改），提供从影响者到运营更改的可追溯性。

结束-定义企业想要成为的-它想要进入的状态。

方式-定义企业决定实现目标所需要做的事情。

影响者-企业决定可能会影响它的事物。

评估-当影响者引起重大变化时，企业将对其影响进行评估，识别风险和潜在回报。可能会有多个评估，可能来自不同的利益相关者。

客户旅程图

客户旅程图是一种强大的技术，可以帮助你了解客户的动机——他们的需求是什么，他们的犹豫和担忧是什么。尽管大多数组织都很擅长收集关于客户的数据，但是数据本身并不能传达客户所经历的挫折和经历。故事可以做到这一点，而业务中最好的故事讲述工具之一就是客户旅程图。

客户旅程图使用讲故事和视觉效果来说明客户在一段时间内与企业的关系。这个故事是从客户的角度讲的，它提供了对客户总经验的洞察力。当客户体验您的产品或服务时，它可以帮助您的团队更好地理解和解决客户的需求和痛点。换句话说，规划客户旅程为您的企业提供了一个机会，使您可以看到您的品牌如何首先吸引潜在客户，然后在整个销售流程的各个接触点之间移动。

最后，团队可以提出针对每个接触点的改进或要采取的措施。这些建议的措施可能是软件需求的潜在来源。

从业务需求中识别软件需求的技术

数据流程图

数据流图（DFD）可以在SDLC（系统开发生命周期）分析阶段的需求获取过程的早期设计，以定义项目范围。DFD通常被用作创建系统概述的初步步骤，而不需要进行详细说明，这些细节可以在以后进行详细阐述。

例如，如果需要在特定过程中显示更多详细信息，则该过程将分解为较低级别DFD中的多个较小的流程。这样，内容图或上下文级别DFD被标记为“级别0 DFD”，而下一个分解级别被标记为“级别1 DFD”，下一个级别被标记为“级别2 DFD”，依此类推。

用例

UML用例图是正在开发的新软件程序的系统/软件需求的主要形式。用例指定预期的行为（是什么），而不是使它发生的确切方法（如何）。用例一旦被指定，就可以用文本和视觉表示（例如UML）表示。用例建模的一个关键概念是，它可以帮助我们从最终用户的角度设计系统。通过指定所有外部可见的系统行为，这是一种以用户的方式传达系统行为的有效技术。

用例图通常很简单。它没有显示用例的细节。

它只总结了用例、参与者和系统之间的一些关系。

它没有显示为实现每个用例的目标而执行步骤的顺序。

用例图的标准形式在统一建模语言中定义，如下面的用例图示例所示：

用户故事

用户故事是一个记录用户在工作中所做或需要做的事情的注释。每个用户故事都由一个简短的描述组成，从用户的角度出发，使用自然语言。与传统的需求捕获不同，与传统的需求捕获不同，用户故事关注的是用户需要什么，而不是系统应该交付什么。这为进一步讨论解决方案和系统结果留出了空间，该系统可以真正适合客户的业务工作流程，解决他们的运营问题，最重要的是为组织增加价值。用户故事与其他敏捷软件开发技术和方法（例如Scrum和极限编程）具有很好的兼容性。

用户故事与用例-相似之处

如果我们考虑这两种方法的关键组成部分：

用户故事包含用户角色、目标和验收标准。

用例包含相同的元素：参与者，事件流和发布条件（详细的用例模板可能包含更多其他元素）。

用户故事与用例-区别

用户故事的细节可能不会被记录到与用例相同的极端情况。

用户故事故意省略了很多重要的细节。用户故事的目的是通过在scrum会议上提问来引出对话。

为了更频繁地获得反馈，需要小幅增量，而不是像用例中那样有更详细的预先需求规范。