架构设计
架构设计需求分析: 主要目的是明确架构要解决当前什么问题， 先调研需求方的诉求。
如果公司的架构部自high，做一些根本没有人使用的框架，组件，系统:
以“晋升”为目的的架构设计都应该拉出去祭天。
脱离业务的架构设计都是耍流氓。
一、架构设计的需求分析从哪来
需求分析的前期工作是愿景描述及愿景分析, 即愿景分析就是需求的前期调研.
从软件过程来看，需求分析是一个承上启下的阶段–“上承”愿景，“下接”设计。需求分析的工作内容包含如下三方面：
需求捕获: 理解沟通
需求分析:做什么,有哪些问题
三者不是独立无关的阶段，而是相互伴随、交叉进行的。
需求捕获: 从各个方面收集需求, 并理解需求.典型的需求捕获是使用“需求采集卡”：需求描述、需求提出者、需求记录者、需求类型等。
需求分析:需求捕获得到的是“原始需求”，而需求分析则对各方面收集到的需求进行分析、整理、归纳、论证形成明确的需求。比如, 产品经理说,现在系统不稳定, 需要重构架构保证系统稳定. 这只是一个愿景, 我们需要把这个需求形成一个明确的需求: 可行性99.99%, 要完成这个指标,需要做哪些工作.
二、需求分类:需求结构化
收集需求是多而杂, 我们需要理解并整理, 通过二维需求观，将“需求=列表”的传统观念，一下子拓宽了维度。有了视野和思维上的提升。
二维需求观:
首先，需求是分层次的:
1、有组织级的需求
2、用户级的需求
3、开发级的需求。
其次，需求还必须从不同方面考虑。 需求可分类为三类：
1）功能需求：更多体现各级直接目标要求,系统具体要做什么. 有哪些功能点.
2）质量需求：运行期质量 + 设计质量+用户质量+系统质量.
3）约束需求：业务环境因素 + 使用环境因素 + 构建环境因素 + 技术环境因素.
ADMEMS矩阵，可作为需求梳理和需求评审的工具:
三、从需求向设计转化的关键
不同需求（及功能、质量、约束）影响架构的不同原理，是从需求向设计转化的密码。
功能需求、质量属性、以及约束共同决定了架构，对这三类需求的把握是否到位、设计决策是否合理，可以说是架构设计成败的关键所在。
功能：体现的是职责协作链.系统有哪些功能点, 这些功能点之间如何协作.
质量：是完善架构的驱动力
约束：说明了设计并不自由
质量属性和约束，同属非功能需求，都是重要的“架构决定因素”。质量属性是软件系统的整体质量品质——所谓整体品质，就是它往往和大多数功能都有关，而不是仅仅表现在某个功能“内部”。
至于约束性需求，它们要么是架构设计中必须遵循的限制，要么经过约束分析、转化为质量属性需求或者功能需求。但是，约束分析没有受到架构师的普遍重视，于是约束背后的“衍生需求”变成了“遗漏需求”，造成了架构设计的偏离甚至失败。
四、需求优先排序
架构设计的本质目的是为了解决业务，架构设计也并不是面面俱到，而是识别问题有针对性的解决, 所以要先了解系统最需要解决的是什么。
例如系统的复杂度来源于业务逻辑复杂，功能耦合度严重，架构师设计TPS达到50000/s的高性能架构没有意义。
出现问题主要为了满足“高可用”“高性能”“可扩展”三个方面，就算老板拍脑袋要求同时满足三高,也要分优先级。
比如线上运行的系统可能存在的问题:
运行效率低下，升级复杂，容易出错。
开发效率低下。
小问题不断，不好定位。
二真缺解决做法：
列出主要的复杂度问题
根据业务、技术、团队等情况进行排序
优先解决最主要的复杂度问题.
参考《软件架构设计：程序员向架构师转型必备(第二版)》
相关阅读
一、数据性能平台支持不低于400个在建工地的数据汇集和分析计算，系统应满足如下技术指标：1. 数据类型支持系统除支持一般结构性事务
本项目设计书为笔者软件工程课的作业，由于时间有限较为粗糙，不合理之处还望指出并改正。 互联网+废品回收项目可行性分析报告 互联
上篇文章讲了怎么定义产品需求，通过学习我们发现，每一个用户端的需求，到了用产品方案来实现的时候，往往对应着多个产品需求，用户需求越
目录 开发过程模型： 软件需求分析的任务： 需求分析步骤： 需求分析方法： 分析建模： 分析模型： 建立分析模型的方法： 结构化分析： 软件需
从事需求分析已经两年了，从物流的需求分析到金融行业的需求分析，我对这两年的需求分析工作做一个反思和总结。目前国内并没有专门针