[架构之路-95]：《软件架构设计：程序员向架构师转型必备》-5-需求分析之需求列表（功能需求、质量需求、约束条件）

前言：

在愿景分析+商业分析之后，就是用户需求开发，然后就是需求分析。

在业务需求分析领域，主要完成三个输出：

• 需求列表：功能需求、质量需求、约束条件 =》 第5章

• 用例图 =》 第6章

• 领域建模 =》 第7章

上述工作，通常是由需求分析工程师或系统工程师SE完成，也可以由架构师完成。

第5章 需求分析

架构师要想知道需求是如何影响架构，首先要懂得如何进行需求分析，或者说，需要懂得需求分析的主要行为动作与主要的输出结果，这些输出结果，是架构设计的输入。

需求开发的上半场：业务愿景分析 + 商业缝隙

需求开发的下半场：需求分析=》用户需求：功能列表 + 用例图

领域建模=》用户需求：领域模型（是对用例图的进一步建模：流程图、活动图、时序图、状态图）

系统分析=》产品需求：软件需求、系统需求规格

5.1 需求开发（上）—— 愿景分析 =》愿景与范围文档/市场需求文档/产品需求文档/项目立项建议书/可行性研究报告/项目立项书

5.1.1 从概念化阶段说起

5.1.2 愿景：环境？背景？好处？目的？为什么要做？

备注：

项目型公司与产品型公司的区别

• 项目型公司：使用市面上成熟的产品、原配件做方案和系统集成，赚取的方案集成的利润

• 产品型公司：研发自己的产品，用自己的产品提供解决方案，赚取的是产品研发的利润和方案利润

• 混合型：研发自己的产品、同时为用户提供解决方案（可以是自己的产品，也可以是第三发产品）

5.1.3 Context上下文图

上下文图把目标系统看成是一个黑盒子，阐述目标系统与外部系统的交互以及目标系统呈现的外部功能行为。

5.1.3.1 与物理架构视图的比较

5.1.3.2 与逻辑架构图的比较

5.1.3.3 Context上下文图与用例图的比较

Context上下文图：关注的外部环境。

用例图：关注为外部不同用户提供的不同功能。

5.1.4 愿景分析实践要领（如何描述业务愿景）

业务目标：简短的文字描述目标系统的业务目标、好处、原因。

feature：功能特征

范围：明确目标系统的边界，哪些是目标系统的职责，哪些不是目标系统的职责。

上下文图：明确目标系统边界外的环境，即上下文。

5.1.5 愿景分析的输出

5.2 需求开发（下）—— 需求分析 =》 需求列表

5.2.1 需求捕获vs.需求分析vs.系统分析

需求捕获=》各方需求捕获=》需求列表

需求分析=》用户需求分析 =》获得用户需求规格 =》用例（用例图和用例规格）

系统分析=》系统需求分析 =》软件系统需求规格 =》需求建模

上述不是两个阶段，而是两个活动，是同一个阶段持续迭代的两个活动。

需求分析和系统分析，相同点都是分析，但分析的对象不同，导致结果不同。

所谓分析：就是先解构，然后再综合的过程，称为分析。

需求分析，分析的是用户的需求，属于做“什么“的问题。对用户的需求进行解构，然后结构化，结果输出是用例（用例图+用例规格）

系统分析，分析的待实现的软件系统，属于”怎么做“的问题。对软件系统进行结构，然后结构化。结果输出是（领域建模）

5.2.2 需求捕获及成果 =》用户原始需求列表以及说明

5.2.3 需求分析及成果 =》 需求建模 =》SRS和用例图+用例规约

用例图和需求规格说明书SRS，都是对用户的需求进行解构和综合的结果。

5.2.4 系统分析及成果 =》

《面向对象的编程》：用面对对象的方法进行软件编程

《面向对象的分析》：设计范畴，把现实领域转换成对象的方法。

系统分析的本质就是根据用户的需求进行初步的架构设计。

5.3 掌握的需求全不全 =》 架构师需要全面了解各种层面、各个维度的需求

5.3.1 二维需求观与ADMEMS矩阵

为了确保需求的完备性，需要从如下的矩阵模型中收集需求。

5.3.2 功能性需求（最常见的需求）

5.3.3 质量性需求

软件的质量，取决于如下的因素：

• 软件质量属性的需求收集与需求分析

• 软件架构设计

• 软件程序设计

• 程序员的编码能力

• 程序的态度

• 公司的软件开发流程

• 项目管理

• 业务部门的管理

所有上述这些因素共同决定了软件的质量属性。

5.3.4 约束

5.4 如何把"需求"转换成“架构设计”：需求决定架构的方式？

需求决定架构，不存在没有软件需求的软件架构！！！

需求层次包括：业务需求、用户需求、产品需求。

需求维度包括：功能需求、非功能需求：质量属性、非功能需求：质量属性（运行期+开发期）

5.4.1 “理性设计”还是“拍脑袋”

备注：这里有一个基本观点，把需求转换成架构设计，不是靠拍脑袋，也不仅仅靠经验，把需求转换成架构设计有方法可循。

5.4.2 功能：职责协作链 =》转化为软件架构中的子系统、模块、组件等

备注：

用户给定的是功能需求，架构师需要为不同的用户功能设计职责协作链，即为了满足某种功能，需要哪些子系统参与，相互协作才能完成才功能，不同子系统的职责是什么？并为子系统的职责定义相关的接口、协作方式。

因此，功能设计相对比较直观，架构师的主要任务：

• 定义子系统的个数、各自的职责

• 把用户的功能需求，进行职责链分解

• 把职责分配到不同的子系统中

• 为子系统的对应的职责定义新的接口

• 为子系统之间交互定义协作方式

5.4.3 质量：完善驱动力 =》转化了软件系统的性能和功能要求

备注：

• 在完成需求的基础之上，进一步完善软件架构，完善质量需求。

• 质量需求是对现有系统不断精进的过程 。

• 质量需要开始于需求分析，构建于架构设计，贯穿于开发流程和项目管理流程的每个环节。

5.4.4 约束：设计并不自由 =》转化成质量要求=》功能要求=》运行环境要求等

导致产品研发失败的大量风险被隐藏在约束条件和质量属性中！！！！

5.5 实际应用（3）——PM Suite贯穿案例之需求分析

5.5.0 基本思路：用三横、三纵替代三纵两纵

三横，即三个层次的需求：业务目标、高层次级需求、用户级需求（用例）

三纵，即三个维度的需求：功能性需求、非功能性需求、约束性需求

5.5.1 PM Suite案例背景介绍

5.5.2 第1步：第一纵第一横(层次)需求：明确系统业务目标

系统业务目标是组织运营服务的。

5.5.3 第2步：第一纵第二横(层次)需求：范围 + Feature + 上下文图

（1）需求范围

备注：

• scope：英语单词，名词、动词，作名词时意为“范围；余地；视野；眼界；导弹射程”.

• 需求范围 requirment scope：就是目标系统特征的大的特征，大的框架。框架内属于需求范围，框架之外需求范围之外。

• 需求范围是可以分层次、分组、分阶段的。

需求框架和架构框架并不是一回事

需求框架：是组织目标系统需求的一种架构化、图形化的方式。

软件架构：是代码实现软件系统需求的一种架构化、图形化的方式。

可以把软件架构设计成与需求框架一致的架构，也可以设计成不一致的架构！！！

（2）需求特征/特性Feature

（3）需求上下文Context图

5.5.4 第3步：第一纵第三横(层次)需求：画用户用例图

用例图：描述的是软件系统的需求，而不是用户需要，因为，因为用例图中的actor不仅仅包括用户，还包括还其他系统，以及内部的定时器 。

5.5.5 第4步：第一纵第三横(层次)需求：写用例User Case/senario）规约

用例User Case/senario）规约是对用户用例图的详细描述，需求文档中需要定义各种大量的User Case/senario以及对应的详细流程描述。

备注：

• 每个用例有包含数据处理流程，用例User Case规约用于描述用例的输入、处理、输出等信息。

• 开发人员用此用例规约实现代码。（类似测试用例或业务场景senario）

• 测试人员用词用例规约验证代码的实现情形（类似测试用例或业务场景senario）

5.5.6 插曲：第一纵（功能性需求迭代）：原型开发、需求启发与需求验证

说明：

在某些领域，用户机界面是产品需求，如互联网产品的用户界面，在这种场合下，产品经理代表用户会严格定义产品的用户界面的布局、内容、美观等需求。

然而，在大多数领域，界面不是需求，产品经理不并关注用户界面的设计，而关注的是界面要包含的内容，甚至内容也不关注，只关注系统完成的功能。在这种场合中，用户界面就是设计，而不是需求！！！

也就是说，用户 界面，有时候是需求，有时候是设计，取决于场合。

5.5.7 插曲：第二纵(非功能性)需求：非功能需求

5.5.8 输出：《需求规格》与基于ADMEMS矩阵的需求评审