简单介绍一些这个领域的相关工作。
注：这种其实都是罗列了点文献而已，并没有什么深度。
Garlan等[1]视体系结构假设条件为导致体系结构不匹配的一个重要因素。他们建议应提供体系结构假设条件归档的指南（例如如何将体系结构假设条件归档集成至体系结构归档中）。他们进一步建议了数个用于支持体系结构假设条件归档的方法（如体系结构视图和描述语言）和技术（如XML）。
Lago和van Vliet[2]定义体系结构假设条件为基于个人经验和知识而接受的制定体系结构设计决策的原理。Lago和van Vliet指出涉众会制定关于开发中哪些会改变或不会改变的假设条件，而这些假设条件可关联到系统的可变性和不可变性。Lago和van Vliet提出体系结构假设条件归档的元模型，并将体系结构假设条件分为三类：（1）管理的体系结构假设条件；（2）组织的体系结构假设条件；（3）技术的体系结构假设条件。
Roeller等[3]将体系结构假设条件分为四类：（1）隐式且未归档的体系结构假设条件（即架构师未意识到制定的体系结构假设条件或该体系结构假设条件是关于隐式的知识）；（2）显式但未归档的体系结构假设条件（即架构师基于特定原因制定假设条件及其决策）；（3）显式且有意未归档的体系结构假设条件（即原因被隐藏）；（4）显式且归档的体系结构假设条件（即最佳情况，但并不经常发生）。Roeller等还提出了软件开发中体系结构假设条件的恢复方法（即RAAM – Recovering Architectural Assumption Method）。
Van Landuyt等[4]聚焦于基于场景的需求中早期的体系结构假设条件，并定义体系结构假设条件为：关于期望体系结构初始元素的假设条件（如系统模块）。该定义有别于Lago和van Vliet[2]提出的定义。此外，Van Landuyt等强调在软件开发早期阶段（如需求工程和体系结构设计）显式地和精确地建模体系结构假设条件的必要性。在他们的后续工作中，Van Landuyt和Joosen[5]提出在基于场景的需求中建模早期体系结构假设条件的一组方法（如一个系统的元模型和面向方面的需求语言）。
Ordibehesht[6]认为隐式的和无效的体系结构假设条件是导致系统错误和低性能的关键因素。Ordibehesht基于体系结构分析和描述语言提出了体系结构假设条件的归档方法。
Mamun和Hansson[7]设计并执行了体系结构假设条件在软件开发中的文献综述。Mamun和Hansson识别出体系结构假设条件管理的问题（如体系结构的不匹配）、挑战（如如何区分体系结构假设条件和其他类型的制品）、方法（如体系结构假设条件的描述语言）。在他们的后续工作中，Mamun等[8]提出在软件开发中使用Alloy语言归档体系结构假设条件。
Ostacchini和Wermelinger [9]强调在敏捷开发中，大部分假设条件均为隐式，而显式地归档假设条件极为重要。 Ostacchini和Wermelinger提出在敏捷开发中管理体系结构假设条件的轻量级方法，并从文献中总结出体系结构假设条件的四个管理活动：（1）描述新的体系结构假设条件；（2）定期地监视体系结构假设条件；（3）检索体系结构假设条件；（4）恢复以往的体系结构假设条件。Ostacchini和Wermelinger使用Lago和van Vliet[2]提出的对体系结构假设条件的分类。此外，Ostacchini和Wermelinger提出在敏捷开发中归档假设条件的方法，并总结出数条管理假设条件的经验。
Tang等[10]定义假设条件为：制定设计决策环境（如制定决策的原因）的不确定性以及期望，并指出在基于原理的体系结构模型中，假设条件是一种重要的体系结构元素。
Heyman等[11]使用Alloy（一种建模语言）描述体系结构假设条件，并通过专用工具（Alloy Analyzer ）将其实现。Heyman等将该用具用于体系结构假设条件评价。
Manteuffel等[12]为体系结构设计决策归档开发了专用工具。然而在该工具中，体系结构假设条件可被归档为体系结构设计决策的一种属性。
Habli和Kelly[13]提出了派生类比的方法以回顾体系结构设计。在该方法中，体系结构假设条件被归档为一类的设计知识。
Hesse和Paech[14]提出了一个用于体系结构设计决策归档的模型。该模型中包括对体系结构假设条件的归档。
参考文献：
[1] D. Garlan, R. Allen, and J. Ockerbloom. Architectural mismatch: Why reuse is still so hard. IEEE Software, 26(4): 66-69, 2009.
[2] P. Lago and H. van Vliet. Explicit assumptions enrich architectural models. In: Proceedings of the 27th International Conference on Software Engineering (ICSE). St Louis, Missouri, USA, pp. 206-214, 2005.
[3] R. Roeller, P. Lago, and H. van Vliet. Recovering architectural assumptions. Journal of Systems and Software, 79(4): 552-573, 2006.
[4] D. Van Landuyt, E. Truyen, and W. Joosen. Documenting early architectural assumptions in scenario-based requirements. In: Proceeding of the Joint Working IEEE/IFIP Conference on Software Architecture (WICSA) and European Conference on Software Architecture (ECSA), Helsinki, Finland, pp. 329-333, 2012.
[5] D. Van Landuyt and W. Joosen. Modularizing early architectural assumptions in scenario-based requirements. In: Proceedings of the 17th International Conference on Fundamental Approaches to Software Engineering (FASE), Grenoble, France, pp. 170-184, 2014.
[6] H. Ordibehesht. Explicating critical assumptions in software architectures using AADL. Master Thesis, University of Gothenburg, 2010.
[7] M.A.A. Mamun and J. Hansson. Review and challenges of assumptions in software development. In: Proceedings of the 2nd Analytic Virtual Integration of Cyber-Physical Systems Workshop (AVICPS), Vienna, Austria, Article No. 7, 2011.
[8] M.A.A. Mamun, M. Tichy, and J. Hansson. Towards Formalizing Assumptions on Architectural Level: A Proof-of-Concept. Research Report, University of Gothenburg, 2012.
[9] I. Ostacchini and M. Wermelinger. Managing assumptions during agile development. In: Proceedings of the 4th Workshop on SHAring and reusing architectural Knowledge (SHARK), Vancouver, Canada, pp. 9-16, 2009.
[10] A. Tang, Y. Jin, and J. Han. A rationale-based architecture model for design traceability and reasoning. Journal of Systems and Software, 80(6): 918-934, 2007.
[11] T. Heyman, R. Scandariato, and W. Joosen. Security in context: analysis and refinement of software architectures. In: Proceedings of the 34th Annual IEEE Computer Software and Applications Conference (COMPSAC). Seoul, South Korea: pp. 161-170, 2010.
[12] C. Manteuffel, D. Tofan, P. Avgeriou, H. Koziolek, and T. Goldschmidt. Decision architect–A decision documentation tool for industry. Journal of Systems and Software, 112(2): 181–198, 2016.
[13] I. Habli and T. Kelly. Capturing and replaying architectural knowledge through derivational analogy. In: Proceedings of the 2nd Workshop on SHAring and Reusing architectural Knowledge Architecture, Rationale, and Design Intent (SHARK-ADI). Minneapolis, MN, USA: Article No. 4, 2007.
[14] T.M. Hesse and B. Paech. Supporting the collaborative development of requirements and architecture documentation. In: Proceedings of the 3rd International Workshop on the Twin Peaks of Requirements and Architecture (TwinPeaks), Rio de Janeiro, Brazil, pp. 22-26, 2013.