Subject: Taking Software Requirements from Hearsay to Analysis

Large software systems are too often late, costly and unreliable. Too often the requirements are not well understood or wrong. A new software system impacts the business environment and creates new business needs that, in turn, drive the emergence of new requirements. Furthermore, during the time it takes to create a new system the business itself changes. These changes can make the baselined requirements outdated. Only 40% of the functions a software system provides will be known at the time the customer and the developer agree to the software requirements. Understanding and bounding the requirements is essential if we are to solve this uncertainty in requirements problem. As early as 1970 Royce pointed at that unvalidated requirements leads to unmanageable projects. In particular, emerging requirements non-linearly increases the effort and time needed to build software intensive systems. Requirements management is critical. When requirements are left to grow unfettered they tend to become complicated and generalized. Effort is needed to keep them simple. One successful technique is to create or enhance prototypes, models or simulation environments for the anticipated systems so that software engineers can understand the complexity of the emerging requirements and access the likelihood of producing a workable system. Often business feasibility studies for major systems require the use of models or simulations. Here is an opportunity to capitalize on these investments. Another approach is to use Model- Driven Software Realization to gain this understanding. By combining functional and performance simulations with sizing and effort estimation efforts the software engineer can attain a holistic understanding of feature, form, cost, schedule and trustworthiness. The Lambda Protocol described in this paper is a way of gaining this insight.