软件架构---确定关键需求

确定关键需求，架构师具体要做什么呢？
· 一方面，不同质量属性之间往往具有相互制约性，于是我们自然应该权衡哪一部分质量属性是架构设计的重点目标。
· 另一方面，功能需求数量众多，应该控制架构设计时需要详细分析的功能（或用例）的个数。

1 确定关键质量
　　为了确定对架构设计关键的质量属性需求，需要做如下三方面的工作：
　　· 考虑为了提高要开发的软件系统受认可的程度，应着重提高哪些方面的质量属性要求；
　　· 接下来，充分考虑这些质量属性的相互制约或相互促进关系，以调整不同质量属性的要求标准——例如，你可能会决定高性能要求最最重要，而可扩展性也比较重要；
　　· 同时，必须满足各种约束性需求。
　　确定关键质量时考虑质量属性之间的矛盾关系，例如，“互操作性”需求往往给“安全性”需求造成威胁，而为了满足“高性能”需求，往往需要使用特定平台的非标准能力，这势必影响了系统的“可移植性”，……，不一而足。于是，我们自然应该权衡哪一部分质量属性是架构设计的重点目标。

2 确定关键功能
　　功能需求是大家最熟悉的一种需求。Karl E. Wiegers在《软件需求（第2版）》中这样描述它：

　　　　功能需求（Functional Requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（Behavioral Requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。

　　而所谓对软件架构关键的功能需求，就是它涉及（或串起）的模块最多、协作方式最有代表性的功能需求。
　　　　任何功能需求，都是由一条特定的“模块协作链”完成的。控制权在模块协作链中来回传递，而功能需求就相当于串起不同模块的线索
　　如何确定关键功能需求呢？可通过如下4条启发规则，确定关键功能子集：
　　　　· 核心功能。
　　　　· 必做功能。
　　　　· 高风险功能。
　　　　· 独特功能（覆盖了上述3类功能没有涉及的职责）。

　　核心功能。识别“核心功能”，有个标志：业务层的接口要反映这些功能。例如，项目管理系统中，项目信息查看、添加项目任务等都是核心功能。

　　必做功能。识别“必须实现的功能”主要依据客户方的背景。架构师不应忽视系统的《愿景与范围文档》，这份文档描述了项目立项的真正源起，文档“项目愿景的解决方案”中“主要特征”往往应作为“必做功能”的备选项。另外，对于业务系统而言，一般支持“运营”的功能比支持“管理”的功能优先级要高。

　　高风险功能。基于务实考虑，还应该把“风险高的功能”选入关键功能子集。

　　　　例如，你在设计一个网上书店系统，书籍的全库搜索功能就需要特别关注：
　　　　· 从用户角度讲，极慢的搜索速度、甚至直接收到“系统忙，请稍后再试”的提示，都是令人不满的；
　　　　· 从架构设计角度讲，此功能对书籍数据库进行“面状、只读”式的使用，和增加书籍、修改书籍信息等功能“点状、写入”式的数据库使用特点完全不同……尽早将全库搜索功能选入“高风险功能”之列，利于有针对性地进行架构设计。

　　独特功能。最后，看看还是否覆盖了“上述3类功能没有涉及的职责”的功能。例如，如果你设计类似“搜狗拼音”这样的输入法软件，“词库在线更新”功能就必然是对架构关键的功能，因为忽略了它就很难发现架构中负责和服务器交互的“互操作模块”。显然，“特殊功能”是相对上述3类功能而言的。

另外，架构师在确定关键功能子集时，还必须注意两点。
　　第一，“关键功能子集”的确定并不存在“标准答案”。只要能较好地覆盖组成架构的不同职责模块，并体现职责模块之间协作关系的特点（有经验的架构师不会放过后者），那么“关键功能子集”的价值也就体现了。
　　第二，值得专门说明的还有“关键功能所占比例”的问题。有些专家认为比例大致是固定的，例如，Per Kroll和Philippe Kruchten在《Rational统一过程：实践者指南》中写道：
　　　　在初始阶段，应该确定出一些（大概占总数的20%至30%）对系统起关键作用的用例。这些用例通常对创建架构具有重要影响。

 参考：温昱《软件架构设计》