《一线架构师实践指南》读后感(四)

《一线架构师实践指南》读后感(四)

什么是Pre-architecture

• Pre-architecture就是架构设计的最前期阶段，其工作目标包括：理解需求、建立需求大局观、确定架构设计方向等

实际意义

需求理解的大局观

• 有效处理互相矛盾的需求目标
• 识别重大需求、特色需求、高风险需求
• 相对短的时间内设计架构

降低架构失败风险

• 架构师在需求的理解、权衡、取舍和补充这些方面能力严重不足。

尽早开始架构设计
Pre-architecture阶段的好处：能够在需求没有“全面完成”的情况下开始架构设计。
为了尽早开始架构设计，需要做好：让架构师参与需求分析工作；不能被动地等待完善的《软件需求规则说明书》出现的那一刻。
只要满足下面3个条件就可以开始架构设计工作：
1.有了明确的业务需求：必须保证甲、乙双方就建设系统的目标达成共识，《愿景文档》经过正式评审，并且明确了投资、工期标准、整合等约束条件；
2.了解全面的用户需求：系统能帮助用户干什么、不能干什么已经非常明确。如果采用用例技术，表现为“用例图”比较完善，没明显遗漏；
3.有了典型的行为需求；如果采用用例技术，表现为核心功能的《用例约束》已经定义；

明确架构设计的“驱动力”
除了需要关注《软件需求规格说明书》之外，必须关注其他很多因素，最终理性地确定真正的架构设计“驱动力”。

实践要领

不同需求影响架构的不同原理，才是架构设计思维的基础

“需求决定架构”是对的，但不同需求影响架构的不同原理，才是架构设计思维的基础。
不同需求是如何以不同原理影响架构设计：

二维需求观与ADMEMS矩阵方法

ADMEM方法提倡的“二维需求观

观念是行为的向导，有怎样的观念存在，就有怎样的行为方式产生。

关键需求决定架构，其余需求验证架构
关键需求决定架构：功能需求做减法；质量属性需求做加饭；约束性需求做加法；

需求结构化
需求结构化可以将复杂的需求集合梳理得井井有条，为进一步分析不同需求之间的联系、识别遗漏的重要需求打下坚实的基础。

需求如何结构化

• 1.超越《软件需求规则说明书》
  需求文档往往不够全面；
  需求经常变更，仅依赖需求文档往往使架构设计工作非常被动；
  架构师通过需求结构化真正全面地“鸟瞰”需求大局，就必须超越《软件需求规则说明书》；
  能够摆脱对《软件需求规则说明书》提交时间、文档质量、内容变更的“呆板依赖”；

• 2.ADMEMS矩阵

  业务级需求：包含客户或出资者要达到的业务目标、预期投资、工期要求，以及要符合哪些标准、对哪些遗留系统进行整合等约束条件。
  用户级需求：用户使用系统来辅助完成哪些工作？对质量有何要求？用户群及所处的使用环境方面有何特殊要求？
  开发级需求：开发人员需要实现什么？开发期间、维护期间有何质量考虑？开发团队的哪些情况会反过来影响架构？

  需求还要从下面3个方面考虑：
  功能需求：更多体现各级直接目标要求。
  质量属性：运行期质量 + 开发期质量。
  约束需求：业务环境因素 + 使用环境因素 + 构建环境因素 + 技术环境因素