When are your requirements ready?

A very common failing in all sorts of projects is being stuck with inadequate requirements. I don’t like requirements as a matter of principle – in fact they are one of the main reasons I started looking at Agile, and for reasons I dwell on at length here, a discussion of requirements doesn’t really belong on any site dedicated to Agile. But if you are stuck with requirements anyway – and many supposedly Agile teams are still forced to work this way – here are a few thoughts about when requirements are ready.

The fact is, most organisations are pretty bad at explaining exactly what it is they want a project to accomplish. There are lots of good reasons for this – the situation at the start of a project is often fluid or unclear, there are too many options to be precise, it’s hard to define a truly innovative idea in detail until you have tried it out, conditions and priorities change as the project proceeds, better ideas surface, and so on.

But that’s not the same as simply being bad at requirements. The above issues relate mainly to the content of requirements, which is very hard to nail down definitively; what I am talking about here is their quality – a different issue. Badly defined requirements are a major cause of problems for projects and businesses alike, causing the routine delivery of the wrong thing and lots of unhappy stakeholders. Fortunately there are ways of ensuring that the requirements – such as they are – are at least defined well enough for the project to proceed reasonably comfortably.

The issue I have in mind is the requirements review process – how requirements get signed off. There are lots of things you can do to make this fairly robust, but one technique I have seldom seem defined clearly enough is that of asking the requirements’ principle users to confirm that they are fit for purpose.

There are three key groups of people who have an interest in how well requirements are stated:

  • the analysts who will have to translate the requirements into a functional solution.
  • the (user and operational) acceptance testers who will have to check that the requirements have been met.
  • the operations personnel who will have to convert the requirements into SLAs and OLAs.

These people are not generally very interested in the requirements contents. But give them poor quality requirements – too vague, imprecise, unanalysed, inconsistent, with key areas missing, and so on – and they simply won’t be able to do their job. Which means that the solution the project delivers is all but bound to leave everyone with a nasty taste in their mouths.

All I am advocating here is that requirements be signed off by these groups. As far as I am aware, although many organisations ask their analysts to approve requirements, most don’t ask testers or operations staff, and this may be a major cause for project failure. It’s not hard to arrange, and it should certainly be welcomed by the groups in question. If, on the other hand, you cannot get their approval, maybe you should be looking to the users to define what they want a little more clearly – and so avoid storing up trouble for the future.

Of course, there’s also a case for weak requirements. Well, not exactly weak, but at least requirements that recognise that they may not be the last word. Organisations and businesses change. So do markets and so does good practise and the opportunity the requirement was originally designed to address. So if you’re embarking on an 18-month project to deliver x, it’s probably not too smart to try to nail down your definition of x too soon. But that is not to say that you should not try to meet the above test from the start – it’s just that your project should also make a strong allowance for change. That could mean a large tolerance, but it should also mean setting the right expectations from the start. For example, the business and users should expect to have to re-validate their initial requirements at regular intervals, you might want to prioritise items that are pretty safe from future fluctuations (e.g., stable regulatory requirements or generic interface components), design for flexibility (loose coupling, modularity, etc.) and so on.

This is the case for agile, of course – but of that more than enough has already been said by anyone and everyone, including me!

By |2018-01-18T15:08:26+00:00Thursday, May 26 2011|Categories: Agile, All, Business and IT, Process and method, Quality, Requirements, Stakeholders|0 Comments

About the Author:

Chief Architect, Agile201.com.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?             
error: Agile201 is wholly copyright and copy-protected.