Investigative Analysis
Today I found myself in the position of having to rewrite a stack of use cases, originally written by a business analyst contracted for a project we’re working on. This got me thinking about requirements, about the criteria by which we judge a set of specifications to be usable and about the steps required to craft a quality requirements document.
The key problem with each use case wasn't necessarily the information contained. In one case, the use case's basic flow accurately detailed the actor's essential interaction with the system; what it lacked was context. The use case gave no indication in what situation the actor would use the system; it addressed the "how" but not the "why". The other use cases were less well defined - incorrect data, alternate and exception flows missing, even basic grammatical errors.
For the most part, though, the rework had more to do with asking the right questions of the various subject experts associated with each use case - getting the flows down right, with context, and then thinking through all of the "what if" scenarios to work out the various alternate and exception flows.
When I pointed this out to the BA in question, his response was less than adequate. "I don’t have experience in this particular industry, so I’ve had difficulty understanding the system. But, I’ll try harder in the future." This particular BA is a little green, so despite my frustration I tried to refrain from injecting any vitriol into my response.
The key to writing quality requirements is persistence. Be sure to ask all of the relevant questions around a given subject area, and do not simply accept what the people you interview tell you as fact. Always perform your own investigations to verify that the information that has been given to you is correct.
Regardless of your background in a given subject area, the act of investigating a topic and reporting on it doesn't change - this is the same principle that the media industry is based on, and why a reporter - say, from a newspaper or from TV - can relate a story on completely different topics without necessarily being an expert on those topics. Ask questions and investigate. Repeat until you have the facts.
This is an oversimplified response to a complex problem - obviously, the skill set and mindset needed to draft quality requirements cannot be relayed in a simple blog entry. At the same time, the core concept of chasing the story - again, borrowed from the investigative reporting world - holds true as one of the key underpinnings of requirements gathering, working to form a solid foundation in one’s technique.
Hopefully the message got through to my BA friend today.