Posted by: Anthony Kesterton | July 6, 2011

How do we get people to rethink the way they work with requirements?

There are a lot of traditional/waterfall projects out there. They continue to be very document-driven. Too much time is spent creating these documents, and they are not used effectively afterwards. They are wasting the time of the people producing and consuming (or not consuming) them.

One approach is to do just enough requirements (for example Stories) but focus on having real stakeholders or their empowered representatives interacting with the rest of the team. This certainly works, but is not the only way.

Another approach is to look at the outputs we are producing – and seriously questioning the value of each artifact. Documents, as something to read and absorb on the train home, are fine, but they must not be the outcome, just a stage in the transition from idea to working code. Having ideas, concepts, pictures, words – having a sea of requirements of one kind or another; and then pulling together different sets of requirements depending on the audience or the need – to me, this seems a lot better.

At the same time, it is high time that people working on requirements plan their work, and make that visible to the project team and beyond. Perhaps if we really understood how much time is wasted, we would do something more useful.

Working with Rational Requirements Composer and Team Concert has made me realize how easy it is to plan my work with requirements, and how I can help other people rethink the way they work with requirements. I hope you get the chance to try this too.



  1. Anthony, I agree with you in that for some areas there are massive improvements that can be made in the way we create/consume/manage requirements, RRC/RTC could help a lot of organisations to trim their processes but actually improve the quality.

    Where it gets difficult is when you are contracting for complex systems of systems, you need something definitive that you can show compliance against. Getting financial and technical owners to agree content of a user story sufficient to contract to is a completely alien concept to some of these industries. Companies want to know specifically what they have to deliver, this reduces risk (the fact that it also creates a lot of extra work, which they charge the customer for is probably more significant!!).

    Until we can change the mode of contracting from originating customers from traditional requirement specifications to something a bit leaner, we are stuck with the process.

  2. Good points Neal. However, progress on contracts is more advanced than you might think. I saw a talk a year or so ago by a contracts lawyer who specializes in Agile-friendly contracts.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: