Contractual Safety of Model-Based Requirements

Abstract

This report describes recent research in support of acquisition programs using requirements as contractual mechanisms. Requirements form the backbone of contracting in acquisition programs. Requirements define the problem boundaries within which contractors try to find acceptable solutions (design systems). At the same time, requirements are the criteria by which a customer measures the extent that their contract has been fulfilled by the supplier. Therefore, requirements are instrumental in the success of acquisition programs. In this context, the quality of a requirement set is determined by the level of contractual safety that it yields. From a technical perspective, contractual safety is driven by the accuracy, precision, and level of completeness of the requirement set. Achieving accuracy is necessary to guarantee that the requirements capture the real needs of the customer. Achieving precision is necessary to guarantee that the supplier interprets the requirements exactly as the customer intended when writing them. Achieving completeness is necessary to avoid gaps in the problem formulation. If requirements are missing, a supplier may reach contractually acceptable solutions that do not fulfill the needs of the customer. Unfortunately, textual requirements do not provide acceptable levels of contractual safety, as they remain a major source of problems in acquisition programs. This is partly caused by the inherent limitations of natural language to statically capture written statements with precision and accuracy. In addition, natural language is difficult (often impossible) to parse into consistent logical or mathematical statements, which limits the use of systematic and/or automated tools to explore completeness. Model-based requirements have been proposed as an alternative to textual requirements, with the promise of enabling higher accuracy, precision, and completeness when eliciting requirements. However, this promise has not been demonstrated yet.