defining the needs for human activity systems, publishing new perspectives on a variety of topics, consulting, training, and special projects.

News Flash

Three books published - available from Amazon and any good bookstore:
Business Process Analysis
Emotional Abuse in the Classroom
Nuclear Weapons and International Law
Enterprise and Information Sample curriculum is now available on the website.
On-site (on premises arranged by you for your people) courses about Business Process Analysis, Meta Meta Modelling, Safeguarding Update, and Legal position of Nuclear Weapons are available for booking. Plan your training now!

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.