Newsletter104

Home Resources Newsletter Archive Newsletter104

Cookie policy

Number 104

Welcome to the September 2011 issue of Precision Matters - the Precision Design Technology (PDT) Newsletter.

Testing Times For Many

Hard on the heels of the July mayhem in Norway, we have been seeing the tragedies and suffering in the eastern states of the USA this last week as hurricane Irene has travelled slowly up the eastern seaboard. New York braced itself for trouble, but so far the damage seems to have been slight. Maryland, New Jersey and the other states south of Washington DC took the hardest hits. New England suffered more from rivers bursting their banks and carrying away bridges, homes, highways and businesses as a result of the rain, rather than the hurricane, by then downgraded to a tropical storm.

Friends in Massachusetts report trees down and power cuts, but thankfully, no serious damage.

Testing times for many.

I have a test of my own happening this coming Sunday, 4th. September. I plan to take part in the first Maidenhead Half Marathon, running 13.1 miles in what I hope will be less than 2 hours and 15 minutes. This is a first for me. Although I've been running for some years, I have only once before attempted a race. That was over 10 km and ten years ago.

I have been learning about training plans and pace plans for the race itself. Also, gathering views about what to eat and what to drink - and when. I didn't realise endurance running was so complicated!

Somebody should write a specification for it! Which reminds me... I thought you might find this month's article interesting as an alternate view of requirements specification.

Creating Requirements

Creating IT solutions relies on two-way communication between the parties. The customer (the business) must be able to articulate its need to the provider (the IT supplier) and, crucially, the provider must be able to express the proposed solution back to the customer. The requirements object, generally being a written document, should deliver this, but most times fails.

Sadly, the requirements rarely fulfil their objectives for a number of reasons. It may be incomplete or inconsistent or both; it will almost certainly be ambiguous; it may describe the wrong requirements. It may well fail to communicate one party’s ideas or needs to the other.

While there are a number of other reasons for project failure, for me the requirements are key to success, regardless of any other mode of failure.

The is a need for a requirements object that really does express what the customer wants and what the provider is offering as a solution, clearly and unambiguously. Written documents are not the solution for a number of reasons.

Requirements should be formalised. That is to say, they should be created using a formal framework. With such a framework, it is possible to test the requirements for consistency using rule-based logic. It is possible to exhibit the meaning of the requirements to the customer, again using rules, so that the proposed system is animated – brought to life – before creating any code. The customer is able to scrutinise the requirements in detail to ensure they are the correct requirements.

Once you have a set of requirements that is consistent and correct, it is possible to build the system by rule, avoiding all the mistakes, changes, ambiguities and bugs introduced during conventional system development.

Formal requirements are:
Unambiguous;
Internally consistent; and

they may be:
            Tested for consistency;
            Demonstrated for correctness by animation;
            Used to create the required system by rule; and
            Proved to have defined properties.

Systems that the customer knows will meet the need are delivered quicker, cheaper, better and right using this approach.

Want to reproduce this article?

Yes you can, so long as you accredit it to Robin Oldman, Precision Design Technology Ltd. and attach the following biography to the article at the bottom:

Precision Design Technology, (PDT), the IT systems experts, provides world-class consultancy and solutions for IT information systems to help its customers develop affordable, high integrity software for business. Normally high-integrity software is prohibitively expensive - PDT provides a solution at a price business can afford.

EUR ING Robin Oldman, COO at PDT, writes and blogs on behalf of the company. Robin also manages the development of the user interface for the SPECIFY4IT tool-set that bridges the gap between the client user and the system supplier. The SPECIFY4IT tool-set is capable of delivering high-integrity business software faster and more cheaply than conventional development methods.