In IT there is usually a big gap between theory and practice; in what customers want and what they receive. Almost 20% of the development projects are never completed and customers only get an average of 54% of the functions they had initially requested. This is mainly attributed to the fact that user requirements have changed on paper but outdated tools and methodologies prevent an effective requirements management in practice. Only 5% of the IT projects practice consistent, systematic requirements management. So, can we borrow methodologies from other more mature engineering disciplines? It is a well-known fact that requirements are the backbone of the Software Development Lifecycle (SDLC), so it only makes sense that a list of requirements actually exists before the development starts. Since the costs of the development need to be predicted early in the lifecycle, do the requirements have a role in estimating them? Can we build models where requirements have no ambiguities and there is only one interpretation to each requirement?

Before starting to test the requirements, any ambiguities will need to be purged. The reason for removing ambiguities is to minimise cost and rework to rectify the mistakes and build a model where the ‘testable requirements’ can be measured and therefore size the cost to build the software with accuracy no matter how complex it is.

It is roughly estimated that customers are paying an additional 20% of the original contract value for change requests. This shows that an effective and standardised requirements management secures the success and cost efficiency of a project. The cost of testing Our method of requirement specification yields itself well to leverage complex metrics. After finishing with the implementation costs, one needs to also consider the testing costs to gain a full picture of total cost projections. To calculate the testing cost of each path we need to calculate the number of paths (test cases). How do we manage change? If requirements change, how does the cost change? How can you automatically identify which tests to run when requirements change?