需求结构化与分析约束影响
第4章需求结构化与分析约束影响
心念不同，判断力自然不同。
--严定暹，《格局决定结局》
全面认识需求，是生产出高质量软件所必须的"第一项修炼"。
--温昱，《软件架构设计》
ADMEMS方法的Pre-architecture阶段包括4个步骤，本章讲解前两步：
第1步，需求结构化。
第2步，分析约束影响。
4.1 为什么必须进行需求结构化
需求是有结构的。
许多实践者不懂得这一点，更不知如何"主动运用"这一点。在他们眼中，架构设计要应对的需求往往是又多又乱的，而且遗漏了关键需求也发现不了……
相反，有经验的架构师懂得运用需求的结构。他们能够将复杂的需求集合梳理得井井有条，为进一步分析不同需求之间的联系（作为权衡折衷的依据）、识别遗漏的重要需求打下坚实基础。
Pre-architecture阶段要求进行需求结构化，这代表着ADMEMS方法更贴近一线架构设计的真实实践。通过ADMEMS矩阵这种思维工具，可以全面理解需求的各个层次、各个方面，更为分析需求之间关系、识别遗漏需求、发现延伸需求奠定基础。通过形象的"物体归类"隐喻（如图4-1所示）可以加深对需求结构化工作的理解。
 |
|
|
-----------------------------------------------------------------------------------------------------------------------------------------
4.2 用ADMEMS矩阵方法进行需求结构化
那么，需求结构化要怎么做呢？
第一，绝对不能认为《软件需求规格说明书》就是需求的全部。
第二，运用ADMEMS矩阵方法。
4.2.1 范围：超越《软件需求规格说明书》
首先，需求文档常常不够全面，所有有经验的架构师都重视需求文档，但不应该"唯需求文档是瞻"。
其次，需求变更经常发生，"依赖且仅依赖需求文档"不够聪明，使架构设计工作非常被动。
既然架构师必须"对需求进行理性的、有针对性地权衡、取舍、补充"，那么"作为架构设计驱动力的需求因素"和"供甲方确认的《软件需求规格说明书》"之间就必然不能"划等号"。
所以，架构师要通过需求结构化真正全面地"鸟瞰"需求大局，就必须超越《软件需求规格说明书》。
还有一个重大意义在于，只有摆脱对《软件需求规格说明书》提交时间、文档质量、内容变更的"呆板依赖"，才有可能尽早开始架构设计（请参考第3章中"尽早开始架构设计"一节）。
4.2.2 工具：ADMEMS矩阵
矩阵，是很多著名方法的核心。例如，制定公司层战略的方法之一是"波士顿矩阵"，"波士顿矩阵"又称"市场增长率-相对市场份额矩阵"。
本书推荐的核心工具之一就是"ADMEMS矩阵"，它又称为"需求层次-需求方面矩阵"。如表4-1所示。
表4-1 ADMEMS矩阵（需求层次-需求方面矩阵）
|
|
广义功能 |
质量 |
约束 |
|
| 业务级需求 |
业务目标 |
快、好、省 |
技术性约束 |
|
| 法规性约束 |
|
|||
| 技术趋势 |
|
|||
| 竞争因素与竞争对手 |
||||
| 遗留系统集成 |
||||
| 标准性约束 |
||||
| 分批实施 |
||||
| 用户级需求 |
用户需求 |
运行期质量 |
用户群特点 用户水平 多国语言 |
|
| 开发级需求 |
行为需求 |
开发期质量 |
开发团队技术水平 开发团队磨合程度 开发团队分布情况 开发团队业务知识 管理：保密要求 管理：产品规划 安装 维护 |
|
首先，需求是分层次的。
业务级需求：包含客户或出资者要达到的业务目标、预期投资、工期要求，以及要符合哪些标准、对哪些遗留系统进行整合等约束条件。
用户级需求：用户使用系统来辅助完成哪些工作？对质量有何要求？用户群及所处的使用环境方面有何特殊要求？
开发级需求：开发人员需要实现什么？开发期间、维护期间有何质量考虑？开发团队的哪些情况会反过来影响架构？
可以看出，需求的三个层次，是站在"不同层次的涉众提出需求所站的立场不同"的角度，将需求划分为三种类型。其次，需求还必须从不同方面进行考虑。例如，一个网上书店系统的功能需求可能包括"浏览书目"、"下订单"、"跟踪订单状态"、"为书籍打分"等，质量属性需求包括"互操作性"和"安全性"等，而"必须运行于Linux平台之上"属于约束性需求之列。实践一再表明，忽视质量属性和约束性需求，常常导致架构设计最终失败。
于是，从"需求定义了直接目标还是间接限制"的角度，把需求划分为3种类型，这就是需求的3个方面：
功能需求：更多体现各级直接目标要求。
质量属性：运行期质量 + 开发期质量。
约束需求：业务环境因素 + 使用环境因素 + 构建环境因素 + 技术环境因素。
一句话，需求是有结构的。而且，需求的结构绝对不是"List"，而应该是"二维数组"。
用ADMEMS矩阵方法进行需求结构化，非常直观。作为一种思维工具，ADMEMS矩阵背后的原理是"二维需求观"，这是"需求列表"这种"一维需求观"所不及的。这就好比程序设计选择了不合适的数据结构，那么功能的实现就要多费周折--既然List、Tree、Graph等数据结构大家都了解，用此作为类比再合适不过了。
结构化是控制复杂性的好办法。例如一个会计师，如果他的办公桌上凌乱地堆满了曲别针、铅笔、硬币……他会因为"东西多"而怎么也找不到某样东西。相反，将不同物品梳脉理络、分门别类地进行"摆放"，就不会丢东忘西（如图4-2所示）。
 |
很奇妙，进行需求结构化之后，架构师会感觉"需求变少了"--其实，需求没有变少，但复杂性却得到了控制。"需求变少了"的最大好处是，架构师可以比原来轻易得多地发现遗漏需求。
上述方法的运用，请参考本章第7节"大型B2C网站案例：需求结构化与分析约束影响"。
=---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
4.3 为什么必须分析约束影响
风险有个恼人的特点：一旦你忘了它，它就会找上门来制造麻烦。
对于架构设计而言，来自方方面面的约束性需求中潜藏了大量风险因素。所以，有经验的架构师都懂得主动分析约束影响，识别架构影响因素，以便在架构设计中引入相应决策予以应对。
同样，Pre-architecture阶段明确要求必须分析约束影响。背鳍下面是不是一条鲨鱼？约束性需求中，是不是潜藏了风险因素？如图4-3所示的隐喻，点明了分析约束影响的要义：尽早识别风险。
 |
----------------------------------------------------------------------------------------------------------------
Big Picture：架构师应该这样理解约束
另外，还有一个重要的基础问题：太多架构师对约束的理解都过于零散，影响了系统化思维。为此，本节介绍架构师理解约束的"Big Picture"，如图4-4所示。
 |
一句话：约束是架构设计的上下文。
没有全局观念就不可能成为架构师，"约束是架构设计要解决的问题的上下文"是一个犀利的理解，揭示了"软件需求 = 功能需求 + 质量属性 + 约束"背后更深层次的规律。
如你所知，忽视了上下文对架构设计方案的限制，最终的架构设计就是不合理的，甚至是不可行的。举个生活当中的例子吧--设计大桥。如图4-5所示，建筑师必须关注以下4类约束的影响，合理规划大桥的设计方案：
考虑商业环境因素。以促进两岸城市间的经济交往为主（这会影响大桥的选址），同时决策层也希望大桥的建设在一定程度上起到提升城市形象的作用。
考虑使用环境因素。水上交通繁忙，而且常有大吨位船只通过，大桥建成投入使用期间不能对此造成影响。
考虑构建环境因素。这是一条很大的河流，水深江阔，为造桥而断流几个月是绝对不可行的。
考虑技术环境因素。斜拉桥因其跨度大等优点，当前广为流行，并且技术也相当成熟了……
 |
--------------------------------------------------------------------------------
4.7 大型B2C网站案例：需求结构化与分析约束影响
像Amazon这样大型的B2C网站，架构的起步阶段应如何规划呢？下面看ADMEMS方法的"表现"。
4.7.1 需求结构化
通过ADMEMS矩阵（需求层次-需求方面矩阵），有助于高屋建瓴地把握复杂系统的需求大局。如表4-3所示，先来梳理业务级的需求。
表4-3 梳理业务级的需求
|
|
功能 |
质量 |
约束 |
| 业务级需求 |
业务目标及业务愿景 Ÿ 网站定位：B2C零售 Ÿ 当前经营：图书 Ÿ 未来经营：图书、软件、音乐制品、电子产品、玩具、婴儿用品、化妆品、宠物、艺术品、杂货 |
商业质量 Ÿ 新功能上线快，随需应变 |
商业约束 Ÿ 投资2000万用于初期开发、运营、市场，之前须取得一定成功并融资成功 集成约束 Ÿ 物流、银行、海关、实体店、各类提供商（包括工厂等生产企业，以及代理商等经销企业） |
| 用户级需求 |
|
|
|
| 开发级需求 |
|
|
|
用户级需求，要特别注意挖掘来自"用户及使用环境"的约束。如表4-4所示，也勿忘开发方因素。
表4-4 重点的用户级需求
|
|
功能 |
质量 |
约束 |
| 业务级需求 |
|
|
|
| 用户级需求 |
用户 Ÿ 终端用户 Ÿ 各种员工角色 |
运行期质量 Ÿ 易用性：最便捷的选择方式 |
用户级约束 Ÿ 便捷的购物流程 Ÿ 客户群大：多国语言 Ÿ 客户群大：关注范围差异，须个性化 Ÿ 消费心理：营造集市效应，“别人也买了”、“别人还买了” |
| 开发级需求 |
|
|
开发方约束 Ÿ 新组建的团队 |
-----------------------------------------------------------------------------------------------
4.7.2 分析约束影响（推导法则应用）
接下来分析约束影响。
基于ADMEMS矩阵应用推导法则时规律十分明显：隐含需求（或遗漏需求）是通过从"上到下"或"从右到左"的脉络被发现的。如表4-5所示，考虑到公司的中远期发展（B2C业务从图书扩展到各类商品），以及近期商业策略（投入资金2000万）的限制，必须制定"网站发展路线图"--而这对于架构而言属于"开发级约束"。
表4-5 推导法则应用
|
|
功能 |
质量 |
约束 |
| 业务级需求 |
业务目标及业务愿景 Ÿ 网站定位：B2C零售 Ÿ 当前经营：图书 Ÿ 未来经营：图书、软件、音乐制品、电子产品、玩具、婴儿用品、化妆品、宠物、艺术品、杂货 |
商业质量 Ÿ 新功能上线快，随需应变 |
商业约束 Ÿ 投资2000万用于初期开发、运营、市场，之前须取得一定成功并融资成功 集成约束 Ÿ 物流、银行、海关、实体店、各类提供商（包括工厂等生产企业，以及代理商等经销企业） |
| 用户级需求 |
|
|
|
| 开发级需求 |
|
|
开发方约束 Ÿ 网站发展路线图 |
表4-6和表4-7也是类似思维的体现。如此分析对架构师有一个额外的好处：理解了不同需求之间的联系，不再觉得需求是"一盘散沙"。
表4-6 推导法则应用（续）
|
|
功能 |
质量 |
约束 |
| 业务级需求 |
业务目标及业务愿景 Ÿ 网站定位：B2C零售 Ÿ 当前经营：图书 Ÿ 未来经营：图书、软件、音乐制品、电子产品、玩具、婴儿用品、化妆品、宠物、艺术品、杂货 |
商业质量 Ÿ 新功能上线快，随需应变 |
商业约束 Ÿ 投资2000万用于初期开发、运营、市场，之前须取得一定成功并融资成功 集成约束 Ÿ 物流、银行、海关、实体店、各类提供商（包括工厂等生产企业，以及代理商等经销企业） |
| 用户级需求 |
用户 Ÿ 终端用户 Ÿ 各种员工角色 管理员功能 Ÿ 灵活的打折设置 Ÿ 频率极高的新货上架 |
|
|
| 开发级需求 |
|
开发期质量 Ÿ 可扩展性 |
|
表4-7 推导法则应用（续）
|
|
功能 |
质量 |
约束 |
||
| 业务级需求 |
|
|
|
||
| 用户级需求 |
用户 Ÿ 终端用户 Ÿ 各种员工角色 终端用户功能 Ÿ 最快的全库搜索 Ÿ 评价功能（Web2.0） Ÿ 多角度关联信息 管理员功能 Ÿ 灵活的打折设置 Ÿ 频率极高的新货上架 |
|
用户级约束 Ÿ 便捷的购物流程 Ÿ 客户群大：多国语言 Ÿ 客户群大：关注范围差异，须个性化 Ÿ 消费心理：营造集市效应，“别人也买了”、“别人还买了” |
||
| 开发级需求 |
|
|
|
||
-----------------------------------------------------------------------
4.7.3 分析约束影响（查漏法则应用）
另外，还要主动运用查漏法则。例如，我们发现至今对质量的重视还不够（实践一线经常出现此情况），于是开始"查漏"：方方面面的约束背后藏着哪些必须强调的质量属性要求呢？如表4-8所示，如此多的集成要求，就必然要提高系统的互操作性……
表4-8 还要主动运用查漏法则
|
|
功能 |
质量 |
约束 |
||
| 业务级需求 |
业务目标、愿景 Ÿ 网站定位：B2C零售 Ÿ 当前经营：图书 Ÿ 未来经营：…… |
商业质量 Ÿ 新功能上线快，随需应变 |
商业约束 Ÿ 投资2000万…… 集成约束 Ÿ 物流、银行、海关、实体店、各类提供商（包括工厂等生产企业，以及代理商等经销企业） |
||
| 用户级需求 |
|
运行期质量 Ÿ 可伸缩性：几乎没有上限 Ÿ 性能：即强调速度，又强调吞吐量 Ÿ 安全性：数据安全 Ÿ 持续可用性：不停机 Ÿ 互操作性：含公司各系统间互操作 |
|||
| 开发级需求 |
|
开发期质量 Ÿ 可扩展性 |
|
||