Why write requirements?
Why is it that some businesses seem to have a Linux infrastructure that just works, with users able to do the tasks they want to be doing without distractions, whereas other businesses always seem to have just one more niggling issue to sort out before ‘everything will be fine’?
The difference is often that the former have taken the time to define their requirements, whereas 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, and, on the whole, IT becomes a ‘solved problem’ for them, meeting the evolving needs of the business and freeing staff to do the work they want to be doing.
What is a Requirements Document?
A key aspect of a successful Requirements Document is that it focuses on what must be achieved and completely ignores how it may be achieved. One common mistake is muddying the waters with implementation details. It’s all too easy to couch the requirements such that they lead towards a (possibly unconsciously chosen) specific solution.
A real-world example: ‘Two servers will be needed for redundancy’.
What is the 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’, and keep doing that until you unearth the real requirement:
‘Two servers will be needed for redundancy.’
‘Why?’
‘Because we don’t want a single point of failure.’
‘Why?’
‘Because for every minute the server is down, we lose £1,000.’
‘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…’
Benefits of defined requirements
The Requirements Document serves a number of purposes:
- It clarifies thought. Just 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. Over time, requirements change. Identifying the change within your Requirements Document makes it easier to determine what needs to change within the infrastructure.
- It brings consensus. Agreeing requirements means that everyone involved, both within the business and externally, is aiming for the same result.
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.
- Users. One would like to think that users’ requirements would be similar to those of the business managers, but often the users will see a greater level of detail. Their requirements will commonly stem from perceived shortcomings in existing or previous systems they have used. in existing or previous systems they have used. ‘I don’t want to have to copy data from one system to another to do my job’ 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, and it’s helpful for those who will be supporting it to understand its purpose too.
The level of detail needed for each group will be different, but 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.
The starting point for the Requirements Document is a single paragraph at the beginning that summarises the overall 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 manage code development, including debugging, validation testing and documentation, for the new range of audio processing chips being developed
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 with some of our clients at Tiger Computing 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 department head wants one thing and the research scientists want another, the time to resolve that conflict is before any buying decisions are made.
What’s next?
If you’d like to know more about how to effectively define requirements, book a no-obligation call and let’s talk.
Photo: Glenn Carstens-Peters