软件架构---从需求明确架构设计驱动力

 

　软件通常是因需求才进行设计开发，由用户方从解决业务问题的角度提出，均以专业的术语或事务性的语言描述。高质量、清晰准确的需求描述，可有效约束软件系统的结构设计和功能定位。边缘清晰、描述规范的要求，会在一定程度上降低软件设计和开发的成本，提高软件质量和开发效率。但是，需求的成长和变化，往往伴随软件的整个开发过程，这种现状使得软件设计的难度不断增加，程序开发也从传统的开发方法向敏捷编程转化。

　　用户基于一定的业务需要提出需求，通常不能直接指导软件的开发，只有经过软件设计者的分析提取，通过规范的技术语言描述，形成面向软件开发者的需求规格说明，才能指导软件的研制。抽取需求是软件设计师必须完成的工作，传统的需求抽取方法一般包括面谈、问卷、观察和业务文档研究等，这些方法简单、成本低，对业务逻辑清晰、封闭性较好的需求比较适合，而对复杂且很难封闭的需求，采用传统的抽取方法，则风险很大。

 

　　软件行业处在不断的发展变化之中，软件需求分类发就是一例。当前业界影响最为广泛的需求分类法将需求分为3个层次

　　

 　　需求分类法最大的好处是明确了不同层次需求之间的跟踪关系——业务需求-->用户需求-->行为需求(功能需求)——从而建立了需求分析的主要脉络。但对架构师来说，需求分类发中的”约束条件“太过狭隘，没有反应”架构设计必须面对来自业务环境、使用环境、构建环境、技术环境的4大类约束“这一现实情况

　　不懂不同需求如何影响架构，就难以进行理性的架构设计。

　　需求决定架构是已知的事实，但是需求如何决定架构呢？下图给了一个较为详细的总结

　

在软件中涉及到不同部分之间的相互配合，系统控制权在不同部分之间来回传递，从而形成了一条职责协作链，来完成非常复杂的功能

质量是完善架构设计的驱动力，（必须）基于当前的架构设计中间成功，进一步考虑具体质量要求，质量与功能共同影响架构设计

约束则以不同的具体方式来影响架构设计：

　　直接制约设计决策

　　转化为功能需求约束

　　转化为质量属性需求的约束

关键需求决定架构，其余需求验证架构

　　功能需求做减法，在所有功能中挑选一个”关键功能子集“，作为”架构设计驱动力“的第一部分

　　质量需求做减法，根据系统所在领域特点及系统规模等因素，确定架构重点属性（因为质量属性本就不可能全部完美实现）作为”架构设计驱动力“的第2部分

　　约束性需求做加法。需要充分考虑需求方及业务环境因素、用户群及使用环境、开发方及构建环境因素、业界当前技术环境因素等”4类约束“，将至作为”架构设计驱动力“的第三部分。并分析约束影响、识别约束背后的衍生需求

 

参考：温昱《一线架构师实践指南》