Newsletter105

Home Resources Newsletter Archive Newsletter105

Cookie policy

Number 105

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

A Small Success

Since the last Newsletter, I have taken part in the Pharmalink Maidenhead Half Marathon and can report a small success. I completed the 13.1-mile flat course in 2 seconds more than 2 hours.

This is both a success and a disappointment to me. The success is that I completed the course at all and in a remarkable time for me. The disappointment is that, having run better that I ever expected, I failed to break the 2-hour barrier by just 2 seconds.

The lesson learned from the experience are that targets are achievable and sometimes exceeded when they are realistic. In addition, preparation and planning go a long way to achieving those realistic targets.

The same holds for IT systems realisation.

The problem with targets is establishing an understanding of what the target is. Business software is notoriously difficult to define, mainly because it is insubstantial. The processes and procedures a business needs is a mental picture, often based on what exists now.

Elements of Requirements

Having talked last month about the ideal properties of IT requirements, I though it worth while to cover our view of how to construct such requirements this month.

We conclude that there are four basic parameters, namely, data, process, event and business rule.

I want to explain the reason for each of these parameters briefly this month.

Data

All the numbers, product descriptions and prices, names and places that a business deals with in its operation constitute data. There are generally many instances of each type of data, many customers, each with one or more addresses, for example.

Data must be organised for it to be useful to the business. Keeping customer records as marks against the customer’s name in a telephone directory is not a well organised set of data.

Also, data must be storable and then accessible for the business to realise its value. A set of rules must be applied to the data in order to organise it for use by an IT system.

Process

Processes are the actions taken to store, access and manipulate data. Some actions result from user activity and others are responses to incoming messages from outside the system or used to generate outgoing messages automatically.

What always surprises me about business systems is the small number of instances where processes change or calculate data. For example, in an order entry system for ordering widgets, very little calculation is performed beyond item extended price, total price and VAT calculation. You could add stock quantity adjustment when the stock is picked, but that’s about it.

Event

An event is a trigger that causes a process to activate.

For example, an event is created whenever a user makes an entry. This is the initiation action that causes a process to start, which in turn handles the associated data values. You may consider events and processes to be synonymous, but they are not. A single event may activate a chain of processes that perform a long series of operations in a defined way.

Looking again at the order entry system for widgets, the completion event for the order would most probably generate an order confirmation document for the customer, derive a picking list for the warehouse, book transport for the completed order, inform the accounting system of the sale details, etc.

One originating event is responsible for this set of outcomes and each outcome may be the result of performing several process steps.

Business Rules

Here is the part that brings the whole together. Many businesses do not record their business rules, which are the conditions imposed on the business activities that constrain the order of handling events. For example in the order entry system, it is usual to establish the name of the customer making the order before taking the order details. This rule allows for the creation of new customer records where necessary.

All the rules are embedded in the business operation. Go and ask an employee what they do, then ask where they get their information from. You will soon discover business rules about the order of performing tasks and dependencies of one task upon another. For an IT system to support the business effectively, these rules must be discovered and incorporated into the IT system.

We often find that recording and analysing business rules uncovers possible inefficiencies or duplication in the business process.

And Finally…

These four elements of requirements combine to provide an unambiguous specification for business information systems.

Such specifications can be played back to the user to ensure their correctness, checked for consistency and, if necessary, proved to possess certain properties.

Further tools allow direct system code generation without human coding, producing systems in about half the time and at about half the cost of conventional development approaches.

For further information, visit Precision Design Technology or the SPECIFY4IT tool-set pages or contact us.

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.