[架构之路-211]- 需求
目录
前言：
一、什么是ADMES:
首先，需求是分层次的：
其次，需求是有结构的，有维度的
再次，不同层次需求、不同维度需求之间可以相互转化（难点、经验积累）
最终，标准化的需求矩阵
二、软架构前的需求理解
1. 目标
2. 时机
3. 四个步骤
三、最佳实践过程
第一步：获取业务功能需求
第二步-1：获取质量属性
1. 开发期质量
2. 运行期质量
第二步-2：分析约束影响
第三步：确定关键性需求（对架构设计影响较大的需求）
1. 确定关键功能启发规则，可以借鉴四象限法，下面是4个启发规则：
2. 确定关键约束
3. 确定关键质量（影响架构设计的质量需求）
第四步：将约束衍生为质量属性及功能、将质量属性衍生为功能需要
第五步：将关键约束衍生为功能
第六步：根据功能提炼出非功能性需求
第七步：最后：输出结构化需求矩阵
前言：
在架构架构设计之前，架构师首先要弄清楚目标系统功能需求、非功能需求和约束条件，这些都会影响最终的架构设计。系统软件或硬件需求规格说明书是系统需求的承载体，当然，需要分析并非是架构师的主要职责，需求规格说明书是产品经理或系统工程师或系统分析师的主要职责。
本文就是讨论，如何通过方法论，使用结构化和层次化的需求矩阵来表达不同层次、不同维度的需求！！！
一、什么是ADMES:
： has been to ，是一种架构设计的方法论，该方法论原本是用于架构设计的，但需求是架构的输入，为了更好进行标准化架构设计，该方法论对输入的需求也进行了标准化、结构化和层次化。UML不同的是，UML是一种建模语言，可以为需求建模，也可以为涉及建模，而是一种方法论，因此该方法论对需求定义提供的一种方法和框架，不涉及需求的表达方式。
首先，需求是分层次的：
可以看出，需求的三个层次，是站在“不同层次的利益相关者提出需求所处的立场不同”的角度
业务级需求：包含用户或者出资人要达到的业务目标、预期投资、工期要求，以及要符合哪些标准、对哪些遗留系统进行整合等约束条件
用户级需求：用户使用系统来辅助完成哪些工作？对质量有何要求？用户群及所处的使用环境方面有何特殊要求？
开发级需求：开发人员需要实现什么？开发期间、维护期间有何质量考虑？开发团队的哪些情况会反过来影响架构？
其次，需求是有结构的，有维度的
其次，，将需求划分为三种类型或三个维度：
功能需求：建设的目标是什么？
质量属性：运行期质量+开发期质量
约束需求：业务环境因素+使用环境因素+构建环境因素+技术环境因素
从3个层次到3个类型这就是需求的转化过程。
再次，不同层次需求、不同维度需求之间可以相互转化（难点、经验积累）
层次间转化：业务需求 =》 用户级需求 =》 开发级需求
维度间转化：约束条件 =》 质量需求 =》 功能需求
维度间转化：功能需求 =》 质量需求
最终，标准化的需求矩阵
如下就是ADMES标准化、结构化、层次化需求矩阵的形态：
二、软架构前的需求理解 1. 目标 2. 时机 3. 四个步骤
三、最佳实践过程
第一步：获取业务功能需求
根据客户需求，整理出功能需求列表(一级模块、二级模块)。常用的工具电子表格或者思维导图。
第二步-1：获取质量属性 1. 开发期质量
2. 运行期质量
第二步-2：分析约束影响
主要从业务环境、使用环境、构建环境和技术环境方面考虑，采用推导法则和查漏法则进行。
上面我们系统化的梳理了系统的业务功能、质量属性及约束内容，下面我们采取需求层次-需求类型二维矩阵来找出关键功能、关键质量属性及关键约束。
用户：关心的是运行期间的质量
开发者：关心的是开发期的质量
第三步：确定关键性需求（对架构设计影响较大的需求）
采用二维矩阵，依次确定三个层次的功能、质量和约束
1. 确定关键功能启发规则，可以借鉴四象限法，下面是4个启发规则： 核心功能必做功能高风险功能独特功能 2. 确定关键约束
3. 确定关键质量（影响架构设计的质量需求）
第四步：将约束衍生为质量属性及功能、将质量属性衍生为功能需要
约束条件 =》质量属性、质量需求 =》 功能需求
约束条件 =》 功能需求
约束条件，最终要体现到软件的实现上。
第五步：将关键约束衍生为功能
比如，终端客户的人员的计算机水平参差不齐 =》 操作简单的需求、文字简化、尽可能可视化等功能需求！！！
第六步：根据功能提炼出非功能性需求
约束条件和功能需求，背后都会隐藏了一下质量需求！！如性能要求。
第七步：最后：输出结构化需求矩阵
通过上述的几个环节，我们把不同类型的约束转化为质量属性及功能需求，最终我们形成了最终的需求二维矩阵，这将为我们的架构指明方向，后续我们再做架构的设计及规划的时候就能够做到有的放矢，不会走错方向。
矩阵把零乱的需求转换成了有序的、结构化的需求。
