Linux for Bioscience: defining requirements

The need for requirements

Some businesses seem to have a Linux infrastructure that works. Users are able to do the tasks they want to be doing without distractions. Other businesses always seem to have a few niggling issue to sort out before ‘everything will be fine’.

The difference is often that the former have taken the time to define their Linux requirements. The latter are sure they know what they are doing but they don’t have time to document it.

Why bother?

A Requirements Document defines what you are trying to achieve. Businesses that don’t have defined, written Requirements Documents find that:

• they spend too much time bending their Linux infrastructure to meet their (undefined) needs
• systems are unreliable and are used inefficiently
• storage space is not available where it is needed
• too many people are involved in day-to-day IT drudge work
• unexpected expenses occur too often.

By contrast, businesses that do have defined, written Requirements Documents make good use of their IT resources. For them, on the whole IT becomes a ‘solved problem’. It meets the evolving needs of the business and frees staff to do the work they want to be doing.

Requirements are not technical

A key aspect of a successful Requirements Document is that it must focus on what must be achieved and completely ignore how it may be achieved. The most common mistake is to muddy the waters with implementation details. It’s all too easy to couch the requirements such that they lead towards a specific solution.

A real-world example is, ‘We need two servers for redundancy’. What is the real requirement here? It is almost certainly not that two servers be used, regardless. This requirement says nothing about the relationship between the two servers (will one be kept in a box on the shelf ‘just in case’?). Question the requirements with ‘why’. Keep doing that until you unearth the real requirement:

‘We need two servers for redundancy.’

‘Why?’

‘Because we don’t want a single point of failure.’

‘Why?’

‘Because for every hour the server is down, our project slips.’

‘So is the requirement, “Better than 99.99% availability”?’

‘Oh. Yes.’

‘Is that availability of the server, or of the service it provides?’

‘Ah. Good question…’

The Requirements Document must be in writing. It doesn’t need to be a huge document, but putting things in writing increases clarity and reduces ambiguity, both enviable attributes.

Benefits of defined requirements

The Requirements Document serves many purposes:

• It brings clarity. Thinking through the points will lead to a more refined, more appropriate infrastructure.
• It gives consistency. By defining all the requirements at the outset, you can ensure that they do not conflict with one another. Far easier to resolve such conflicts before we start implementing.
• It becomes a checklist. Once your Linux infrastructure is up and running, reviewing the requirements will show whether you really do have everything in place.
• It allows your infrastructure to evolve in a controlled manner. Over time, requirements change. Document the changes in the Requirements Document, then reflect them in the infrastructure.
• It brings consensus. Everyone involved, both within the business and externally, is aiming for the same result.

Audience

There are multiple potential audiences for your Requirements Document. They will include:

• Business Managers. They are (usually) responsible for ensuring that the business is profitable, or that research grants are use appropriately. The Linux infrastructure is a business asset. It has a cost associated, and it should deliver some benefit that outweighs the cost. It’s appropriate that the business managers agree what that infrastructure should deliver.
• Scientists. The scientists’ requirements will often be similar to those of the business managers, but often the scientists will see a greater level of detail. They use the systems daily and will know what works and what doesn’t work. ‘I don’t want to have stop research work to investigate a Linux issue” is a reasonable requirement, but the business managers may not even know that that’s going on.
• Technical Staff. Those who will be designing your infrastructure will naturally need to understand the goals of the system. It’s helpful for those who will be supporting it to understand its purpose too.

Having one definitive place to go to find out what the business is trying to achieve is helpful for everyone.

Scope

The Requirements Document may refer to or encompass other documents. In particular, there may be a separate Security Policy and an Acceptable Use Policy, both of which we’ll discuss in a later article.

The starting point for the Requirements Document is a single paragraph that summarises the purpose of the Linux infrastructure. This isn’t about detail; rather, it’s there to give someone who is unfamiliar with your business some context to start from. For example:

The purpose of the Linux infrastructure is to run analyses and store data related to drug discovery.

Summary

• The Requirements Document brings clarity, consistency and consensus
• It must focus on what is to be achieved, not how it will be achieved
• It should be agreed by all parties before implementation begins

Over the past fifteen-plus years, the biggest single mistake we’ve seen our clients make has been the lack of defined requirements. It leads to wasted money and wasted time, and the irony is that at some point the requirements have to be defined anyway, even if only by trial and error.

When the research head wants one thing and the research scientists want another, resolve that conflict before any buying decisions are made.

The difference that having a Requirements Document makes is huge, but writing an effective one is deceptively hard. It feels as if it should be simple, straightforward, obvious even; but, like the onion, there are multiple layers and there’s more to it than initially meets the eye.

Who am I?

I’m Keith Edmunds, the founder of Linux for Bioscience. We’ve been building and supporting Linux solutions since 2002.

We specialize in Linux solutions for the bioscience industry, and have worked with leading BioScience companies including eTherapeutics plc, Synpromics and Oxford Gene Technology, and health providers such as the NHS.

We work only with Linux. We work with it all day, every day, and we understand how to get the best from it.

If you enjoyed the article, please SHARE it or LIKE it or COMMENT on it or TWEET it.