肯定关键需求，架构师具体要作什么呢？
· 一方面，不一样质量属性之间每每具备相互制约性，因而咱们天然应该权衡哪一部分质量属性是架构设计的重点目标。
· 另外一方面，功能需求数量众多，应该控制架构设计时须要详细分析的功能（或用例）的个数。数据库
1 肯定关键质量
为了肯定对架构设计关键的质量属性需求，须要作以下三方面的工做：
· 考虑为了提升要开发的软件系统受承认的程度，应着重提升哪些方面的质量属性要求；
· 接下来，充分考虑这些质量属性的相互制约或相互促进关系，以调整不一样质量属性的要求标准——例如，你可能会决定高性能要求最最重要，而可扩展性也比较重要；
· 同时，必须知足各类约束性需求。
肯定关键质量时考虑质量属性之间的矛盾关系，例如，“互操做性”需求每每给“安全性”需求形成威胁，而为了知足“高性能”需求，每每须要使用特定平台的非标准能力，这势必影响了系统的“可移植性”，……，不一而足。因而，咱们天然应该权衡哪一部分质量属性是架构设计的重点目标。安全
2 肯定关键功能
功能需求是你们最熟悉的一种需求。Karl E. Wiegers在《软件需求（第2版）》中这样描述它：服务器
功能需求（Functional Requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，知足业务需求。功能需求有时也被称做行为需求（Behavioral Requirement），由于习惯上老是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预约”。架构
而所谓对软件架构关键的功能需求，就是它涉及（或串起）的模块最多、协做方式最有表明性的功能需求。
任何功能需求，都是由一条特定的“模块协做链”完成的。控制权在模块协做链中来回传递，而功能需求就至关于串起不一样模块的线索
如何肯定关键功能需求呢？可经过以下4条启发规则，肯定关键功能子集：
· 核心功能。
· 必作功能。
· 高风险功能。
· 独特功能（覆盖了上述3类功能没有涉及的职责）。性能
核心功能。识别“核心功能”，有个标志：业务层的接口要反映这些功能。例如，项目管理系统中，项目信息查看、添加项目任务等都是核心功能。ui
必作功能。识别“必须实现的功能”主要依据客户方的背景。架构师不该忽视系统的《愿景与范围文档》，这份文档描述了项目立项的真正源起，文档“项目愿景的解决方案”中“主要特征”每每应做为“必作功能”的备选项。另外，对于业务系统而言，通常支持“运营”的功能比支持“管理”的功能优先级要高。spa
高风险功能。基于务实考虑，还应该把“风险高的功能”选入关键功能子集。架构设计
例如，你在设计一个网上书店系统，书籍的全库搜索功能就须要特别关注：
· 从用户角度讲，极慢的搜索速度、甚至直接收到“系统忙，请稍后再试”的提示，都是使人不满的；
· 从架构设计角度讲，此功能对书籍数据库进行“面状、只读”式的使用，和增长书籍、修改书籍信息等功能“点状、写入”式的数据库使用特色彻底不一样……尽早将全库搜索功能选入“高风险功能”之列，利于有针对性地进行架构设计。设计
独特功能。最后，看看仍是否覆盖了“上述3类功能没有涉及的职责”的功能。例如，若是你设计相似“搜狗拼音”这样的输入法软件，“词库在线更新”功能就必然是对架构关键的功能，由于忽略了它就很难发现架构中负责和服务器交互的“互操做模块”。显然，“特殊功能”是相对上述3类功能而言的。接口
另外，架构师在肯定关键功能子集时，还必须注意两点。
第一，“关键功能子集”的肯定并不存在“标准答案”。只要能较好地覆盖组成架构的不一样职责模块，并体现职责模块之间协做关系的特色（有经验的架构师不会放事后者），那么“关键功能子集”的价值也就体现了。
第二，值得专门说明的还有“关键功能所占比例”的问题。有些专家认为比例大体是固定的，例如，Per Kroll和Philippe Kruchten在《Rational统一过程：实践者指南》中写道：
在初始阶段，应该肯定出一些（大概占总数的20%至30%）对系统起关键做用的用例。这些用例一般对建立架构具备重要影响。
参考：温昱《软件架构设计》