What are requirements?

What is all the fuss about requirements? At their simplest level, they are easy - they are what we want. Of course, the reality is that so often, it is not as simple as that. A requirement may be very simple, and there may be many ways in which a requirement can be met, sometimes with a very simple solution.

However, to repeat a well-known saying, "the devil is in the detail" - and that is so true when it comes to forming statements of requirements.....

In the early days of formulating approaches to requirements modelling, an expression in common use was 'problem statement'. A problem statement is an expression of a 'problem' for which a solution is sought. Requirements are the requirements for a human created solution to the problem that has been stated. In those early days, the focus of discussion and solution was often stated to be an information processing system. In fact, that can often be narrowed even further to the software required as part of a computer-based information processing system. Software requirements are a far cry from system requirements, but so much literatiure about requirements 'engineering' is to do with software. Just keep in mind that this is not necessarily so.

A key principle behind our approach to requirements, is that 'good' requirements are correct, complete, and consistent - the 3 Cs. On this website, you will find a more comprehensive discussion of these 3 Cs. Correctness is the most difficult to check automatically, but there are some tools available which can help with the 'correctness' of requirements. Tools exist for the automated checking of the completeness and consistency of requirements, even if a system requires many thousands of components, or elements in it. Further details are also available here, and related websites.