[架构之路-211]- 需求 _架构设计

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