上一篇博文简单讲了点体系结构假设条件的相关工作，这篇讲讲其他类型假设条件的相关工作。
注：这种其实都是罗列了点文献而已，并没有什么深度。
Lewis等[1]识别出数个由项目中未归档的假设条件所导致的问题。例如，若假设条件为隐式，涉众可能无法意识到这些假设条件随时间的演化。Lewis等提出用于软件开发中管理假设条件的原型系统。此系统可从代码中抽取假设条件，并将其归档到库中以便管理。Lewis等还将软件开发中的假设条件分成了五类：（1）控制的假设条件（期望的控制流）；（2）环境的假设条件（期待的环境因素）；（3）数据的假设条件（期待的输入和输出数据）；（4）使用的假设条件（期待的使用场景）；（5）约定俗成的假设条件（遵从开发中的标准或潜规则）。
Tirumala等[2]关注构件假设条件，并强调软件构件间不匹配的假设条件是导致实时系统出现错误的关键因素，且大部分构件假设条件都为隐式。Tirumala等提出在实时系统中明确构件假设条件的框架以及相关的专用工具（使用XML）。
Zschaler和Rashid[3]聚焦于面向方面软件开发中方面的假设条件，并将其分为两个大类以及六个小类。该分类可帮助改善代码以及促进面向方面代码中假设条件的抽取和验证。Zschaler和Rashid采用具有四个元素：名称、描述、例子、讨论的模板归档方面的假设条件。
Haley等[4]关注可信假设条件，并指出可信假设条件（包括显式的和隐式的可信假设条件）可能影响实现一个系统功能的方式以及需求分析范围。这些研究者提出了由六个元素构成的模型以表示可信假设条件。
Steingruebl和Peterson[5]为归档软件开发中不同类型的假设条件介绍了数种特定的方法和技术。例如Steingruebl和Peterson建议涉众使用需求文档、数据流图、威胁建模以归档设计假设条件，而使用代码注释和协议语言（如Eiffel）以归档实现假设条件。
Miranskyy等[6]追溯假设条件至需求，并设计了一个定量的、数学的模型以归档软件开发中和需求关联的假设条件。
Uchitel和Yankelevich[7]描述构件假设条件可能出现的问题以及如何使用现有体系结构描述语言以归档构件假设条件的指南。例如，Uchitel和Yankelevich强调构件假设条件应形成独立文档，而不是混合在其他文档中。
Lehman和Ramil[8]讨论实现假设条件的角色以及此类假设条件可能出现的问题。例如，Lehman和Ramil认为无效的假设条件可能导致不确定或不可接受的程序行为，而对其归档则是解决该问题的方案。此外，Lehman和Ramil总结出数条假设条件管理的经验（如假设条件应在开发的早期阶段迭代地归档）。
Seater等[9]在需求工程中关注领域行为的假设条件。与Heyman等[85]类似，Seater等也使用Alloy以表达假设条件。
Welsh等[10]关注设计中的假设条件，且将其与需求关联。Welsh等提出相应的假设条件归档方法：REAssuRE（即REcording of Assumptions in RE）。
Faily和Fléchais[11]同样关注设计中的假设条件，并提出了假Assumption Personas方法。该方法描述与典型用户行为关联的假设条件。
多位研究者聚焦于assume-guarantee reasoning的相关方法，并将其应用于不同的领域或场景。例如Nam等[12]解释了assume-guarantee reasoning的过程：（1）将系统S分解为构件M1、M2、…、Mn；（2）为每个构件识别一个假设条件Ai（i = 1、2、…、 n）；（3）验证这些假设条件是否可用于证明系统S满足某属性。
参考文献
[1] G.A. Lewis, T. Mahatham, and L. Wrage. Assumptions Management in Software Development. Technical Report, CMU/SEI-2004-TN-021, 2004.
[2] A. Tirumala, T. Crenshaw, L. Sha, G. Baliga, S. Kowshik, C. Robinson, and W. Witthawaskul. Prevention of failures due to assumptions made by software components in real-time systems. ACM SIGBED Review, 2(3): 36-39, 2005.
[3] S. Zschaler and A. Rashid. Aspect assumptions: a retrospective study of AspectJ developers' assumptions about aspect usage. In: Proceedings of the 10th International Conference on Aspect-Oriented Software Development (AOSD), Porto de Galinhas, Brazil, pp. 93-104, 2011.
[4] C.B. Haley, R.C. Laney, J.D. Moffett, and B. Nuseibeh. Using trust assumptions with security requirements. Requirements Engineering, 11(2): 138-151, 2006.
[5] A. Steingruebl and G. Peterson. Software assumptions lead to preventable errors. IEEE Security & Privacy, 7(4): 84-87, 2009.
[6] A. Miranskyy, N. Madhavji, M. Davison, and M. Reesor. Modelling assumptions and requirements in the context of project risk. In: Proceedings of the 13th IEEE International Conference on Requirements Engineering (RE), Paris, France, pp. 471 – 472, 2005.
[7] S. Uchitel and D. Yankelevich. Enhancing architectural mismatch detection with assumptions. In: Proceedings of the 7th IEEE International Conference and Workshop on the Engineering of Computer Based Systems (ECBS), Edinburgh, UK, pp. 138-146, 2000.
[8] M.M. Lehman and J.F. Ramil. Rules and tools for software evolution planning and management. Annals of Software Engineering, 11(1): 15-44, 2001.
[9] R. Seater, D. Jackson, and R. Gheyi. Requirement progression in problem frames: Deriving specifications from requirements. Requirements Engineering, 12(2): 77-102, 2007.
[10] K. Welsh, P. Sawyer, and N. Bencomo. Towards requirements aware systems: Run-time resolution of design-time assumptions. In: Proceedings of the 26th IEEE/ACM International Conference on Automated Software Engineering (ASE). Lawrence, KS, USA: pp. 560-563, 2011.
[11] S. Faily and I. Fléchais. The secret lives of assumptions: Developing and refining assumption personas for secure system design. In: Proceedings of the 3rd International Conference on Human-Centred Software Engineering (HCSE). Reykjavik, Iceland: pp. 111-118, 2010.
[12] W. Nam, P. Madhusudan, and R. Alur. Automatic symbolic compositional verification by learning assumptions. Formal Methods in System Design, 32(3): 207-234, 2008.