I’ve recently been developing requirements for a number of clients. I’ve always found requirements tricky to define and I’ve been involved with development jobs where requirements have been either non existent, written on the back of a fag packet or biblical in size.
Why are requirements so difficult? Well they aren’t really but I think more often than not we tend to go about understanding them in the wrong way. I’m not sure if there’s a silver bullet, but here is my current thinking about how to go about developing a decent set of requirements:
Understand what the requirements are for
This is always my starting question. Why am I involved and what is the value of these requirements. Who is the target audience and the intended outcome. Invariably requirements end up in the lap of a developer, kind of a blue print, so my target audience tends to be developers. I have never met a developer that gets passed reading page two of a lengthy requirements specification, I’d like to make BA’s eat these sort of documents. Developing requirements is far to often the point that all communication stops between the client/user and the people delivering the solution - criminal.
Get the right people involved and listen
I like to speak to as many people as I can when developing requirements and my main aim is to listen. I like to go in with no preconceptions. It’s difficult to balance out dominant characters as often what they want will seem more important, but in my experience some of the requirements that have appeared insignificant at the outset have become the most important over the life span of a project. Record everything, don’t worry if it will be in or out of scope that’s not part of the requirements process.
Accept people don’t know exactly what they want
I hear this all the time ‘….but they don’t know what they want’! This issue only arises when you expect the client to have done your job for you, when you accept the opposite it’s a refreshing experience. It’s worth remembering here that requirements shouldn’t be the end of the process and if you sign up to the idea that you keep communicating with your client throughout the project you will help them tease out exactly what they do want
Don’t be ‘kind of’ vague
Based on what i’ve just said this shouldn’t matter, however i like to try and avoid adding requirements that are just tooooo vague and i find these invariably stem from the ‘higher order’ of user/client. Its always a worry when i hear things like ‘…….the system needs to integrate all the data in our business systems together’. Oh no, not integration…:(
Avoid the how
This is one of my golden rules when developing requirements. I want to know what the user wants not necessarily how they want it to be delivered. The ‘how’ is very importent, but I prefer to develop this through iterations and ongoing communication. The ‘how’ is less important to the ‘what’. Some people will argue the point here, i.e. ‘the system does not satisfy my requirement if i have to spend several weeks putting bits and pieces together to end up with my requirement satisfied’ - There are often many ways to skin a cat (you shouldn’t skin cats) and you should persuade the client that this is not as important as understaning what is required - i’ve seen so many requirements exercises bogged down in ‘how’ mud.
Personally I like using a bastardisation on the product planning technique within PRINCE2 (put aside what you think about PRINCE2). I use product based planning as a means to organise the requirements, each requirement can be seen as a product. PRINCE uses a product breakdown structure and a product flow diagram. I use the breakdown structure as a visual way to collect my requirements together, and logically group them together, I generally keep the overall goal of the job at the top of the breakdown structure. The flow diagram I like to construct with the client - this helps me gauge where the priorities might lie amongst all the requirements, in PRINCE this flow diagram defines the dependencies, this will be done before this, then that, then this etc etc, however I use the flow diagram as a means to guide developers - the client thinks these are important, but leave the real ordering to them.
Use cases are your friend
I find use cases an effective way to illustrate to a developer an EXAMPLE OF how a requirement might be met. I’m not fixed to use cases, as this breaks my earlier rule on avoiding the how, but use cases are very handy when it comes to translating what might be a high level statement into something much more practical that a developer can hook on to. This recent Assembla post was pretty good on use cases/stories
Screen shots build expectations…
I avoid screenshots, they build expectation and all to often become a sticking point: ‘but it doesn’t look like you said it was going to look’! Again screenshots stray into that ‘how’ mud, its easy to see why they are used as they happen to be handy to illustrate what an end solution may look like, but they do not help a developer. I favour use cases here and a continuing communication as a means to ensure that any UI development doesn’t go to far before an end user has a chance to pass comment.
Just a few things that I have found help guide me when i am collecting requirements
