摘要：要开发出用户满意的软件并不是件容易的事，软件架构师必须全面把握各种各样的需求、权衡需求之间有可能的矛盾之处，分门别类地将不同需求一一满足。本文从理解需求种类的复杂性谈起，通过具体案例的分析，展示了如何通过RUP的4+1视图方法，针对不同需求进行架构设计，从而确保重要的需求一一被满足。
呼唤架构设计的多重视图方法
灵感一闪，就想出了把大象放进冰箱的办法，这自然好。但希望每个架构设计策略都依靠灵感是不现实的——我们需要系统方法的指导。
需要架构设计的多重视图方法，从根本上来说是因为需求种类的复杂性所致。以工程领域的例子开道吧。比如设计一座跨江大桥：我们会考虑“连接南北的公路交通”这个“功能需求”，从而初步设计出理想化的桥墩支撑的公路桥方案；然后还要考虑造桥要面临的“约束条件”，这个约束条件可能是“不能影响万吨轮从桥下通过”，于是细化设计方案，规定桥墩的高度和桥墩之间的间距；另外还要顾及“大桥的使用期质量属性”，比如为了“能在湍急的江流中保持稳固”，可以把大桥桥墩深深地建在岩石层之上，和大地浑然一体；其实，“建造期间的质量属性”也很值得考虑，比如在大桥的设计过程中考虑“施工方便性”的一些措施。
和工程领域的功能需求、约束条件、使用期质量属性、建造期间的质量属性等类似，软件系统的需求种类也相当复杂，具体分类如图1所示。
软件需求
功能需求
非功能需求
约束
质量属性
运行期质量属性
开发期质量属性
超市系统案例：理解需求种类的复杂性
例子是最好的老师。为了更好地理解软件需求种类的复杂性，我们来分析一个实际的例子。在表1中，我们列举了一个典型的超市系统的需求子集，从这个例子中可以清晰地看到需求可以分为两大类：功能需求和非功能需求。
|
非功能需求 |
功能需求 |
|
约束 |
运行期质量属性 |
开发期质量属性 |
|
项目预算有限
用户的平均电脑操作水平偏低
要求能在Linux上运行
开发人员分散在不同地点
…… |
高性能
易用性
…… |
易理解性
模块间松散耦合
…… |
提高收银效率
任意商品项可单独取消
通过收银终端的按键组合，可以使收银过程从“逐项录入状态”进入“选择取消状态”
…… |
表1 超市系统案例：理解需求种类的复杂性
简单而言，功能需求就是“软件有什么用，软件需要做什么”。同时，注意把握功能需求的层次性是软件需求的最佳实践。以该超市系统为例：
超市老板希望通过软件来“提高收银效率”。
那么，你可能需要为收银员提供一系列功能来促成这个目的，比如供收银员使用的“任意商品项可单独取消”功能有利于提供收银效率（笔者曾在超市有过被迫整单取消然后一车商品重新扫描收费的痛苦经历）。
而具体到这个超市系统，系统分析员可能会决定要提供的具体功能为：通过收银终端的按键组合，可以使收银过程从“逐项录入状态”进入“选择取消状态”，从而取消某项商品。
从上面的例子中我们还惊讶地发现，非功能需求——人们最经常忽视的一大类需求——包括的内容非常宽、并且极其重要。非功能需求又可以分为如下三类：
约束。要开发出用户满意的软件并不是件容易的事，而全面理解要设计的软件系统所面临的约束可以使你向成功迈进一步。约束性需求既包括企业级的商业考虑（例如“项目预算有限”），也包括最终用户级的实际情况（例如“用户的平均电脑操作水平偏低”）；既可能包括具体技术的明确要求（例如“要求能在Linux上运行”），又可能需要考虑开发团队的
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
