This is the first of a five part series on system design, relying on my own experiences and knowledge from working both in the public and private sector.

I have broken down my thoughts on system design into five distinct pieces: user requirements (this article); development standards; usability, code-cutting, and testing and go-live.

What is the system for?

This is the first and most crucial question that needs to be asked at the starting point of any development. What is the system for. Note that this is subtly different from “what is the system expected to do”.

Here the emphasis should not be on what should the system do, as generally if you are replacing an existing system, the users will assume that the new system should work in the same manner, with some nicer colours and bug-fixes thrown in.

However, asking what the system is actually for — in other words which tasks do the users want to accomplish — will enable whoever is assessing the requirements to compare their knowledge of what can technically be accomplished with the tasks that the users need to carry out and possibly suggest new and improved business practices.

For example, let’s take an imaginary set of user requirements:

The users want a system that will handle various types of financial transaction, and want the system to produce a report that will identify transactions on a weekly basis that have satisfied certain criteria.

You could simply produce this report.

Alternatively, if you’d asked what this report was for, you may have found out extra information, for instance the report may be passed to someone who is externally auditing the financial systems, or for someone who is checking against fraud.

Once you’ve got this additional information, there may be other options available that would be more beneficial to the user — if you create the auditor a read-only account that allows them to run these sorts of reports and check the transactions for themselves, then not only do the auditors get more control over the information that they are looking at, but it doesn’t need to be a task that the standard users have to carry out any more.

This fictional example is just to illustrate the importance of knowing why. It is therefore critical that whoever is sent to discuss the system with the user is capable not only of understanding the technical possibilities but of determining and understanding not only the users’ business practices but also business reasons behind them.

Who is the system for, and how secure should it be?

If the system is used by everyone in Department X to monitor the amount of fuel being used by the company’s vehicles, then this only really needs to be placed in some sort of location where only Department X can access it, such as a place on your corporate network.

If on the other hand it was being used to keep track of disciplinary action taken against various employees and/or information relating to ongoing disciplinary cases, and it was required to be published on the internet so that suspended employees and their union representatives could access their own data then it would need to be considerably more secure; you would not want anyone to be able to access this data unless they were a specifically authorised user (this would not only be required for data security, but in a system of this nature it would additionally be required by the Data Protection Act).

You therefore need to choose an appropriate platform and security structure for the system depending upon the importance of the data, the sensitivity of the data, and the potential for harm if the system is compromised. It is theoretically possible to apply the maximum security level to every system, but this would generally not be desirable because you are adding unnecessary development costs in each case.

It is important to decide between the system owners and the system developers what form of security is appropriate and develop to this standard.

For a system of critical importance, where data is particularly sensitive, or where it is most exposed (e.g. applications published on the internet), you may also wish to look at incorporating penetration testing into your plan.

Noting who your users are is of importance too. If your users include the general public, or people who don’t use many other IT systems, then you’ll have to pay particular importance to ease-of-use because the likelihood is that you may be dealing with at least some people who are not particularly computer literate, and if you want your system to be successful, it needs to be (at least relatively) easy to use for everyone.

Write It Down

Once you’ve discussed the requirements with the users, and you’ve come up with a proposal, document it. Write down what you think the system needs to do, write it down, and send it back to the users for confirmation.

It won’t stop arguments (sorry, “discussions”) about the original intentions later on, but it will reduce them — anything you’ve got down in this document, once it has been confirmed, has been agreed.

Depending upon the client/developer relationship this may or may not make a difference to your procedures should the client request changes, but at least you’ve got something to refer back to, and this document can be crucial for the developer who shouldn’t make any decisions that moves the system away from what is agreed in this document without specific authorisation.

From this document, you should be able to produce your Acceptance Critieria before you’ve even carried out any development. The acceptance criteria document is simple: it basically says that if the system does this, this and this, doesn’t need this or that, doesn’t do that, that or that, and that you can run this, that or the other report from it, then the system will be acceptable. If it doesn’t meet these criteria, the system won’t be acceptable.

If you and the users have done your respective jobs properly at this stage, the users will be happy with any system that meets the requirements described in the Acceptance Criteria, and the developers will understand how to produce a system that will meet the users’ needs.

Summary

It sounds simple — and indeed it is — but it brings a great deal of practical benefit to your projects throughout the project lifecycle if you can:

• Understand the business requirements and the business processes
• Understand who will be using your system
• Understand any complications arising from the sort of data being held (business critical, sensitive, personal etc)
• Write it down and get the users to agree acceptance criteria