As a Business Analyst, a critical success factor is to ensure that all requirements are efficiently captured for the development team to use. Curious about what other business groups’ best practices are, I attended the webinar presented by IAG on "Inside Effective Business Requirements Documentation".
After all, since IAG's been around for 10 years, completed over 1000 requirement projects and trains over 1200 BAs annually, I am bound to learn a thing or two.
The one hour presentation was great and allowed me draw a parallel between my experience in the field and what was presented.
Here are the main key points which I see lack most in documentation:
Use of Context Diagram – Understand the bigger picture
Common reasons to skip it:
1. As systems are often broken into different components, people have a tendency to focus on their own system, turning into tunnel vision. After all, a picture is a worth a thousand words.
2. The context diagram is difficult to create as it requires thinking outside the box.
3. For an enhancement project, the absence of a previous context diagram makes it difficult to gather information to represent the existing data (lack of players, SME) before modification
1. A visual context diagram will speak to all actors on a project: from the least technical to the most.
2. A context diagram helps understand all dependencies between systems. From a requirement perspective, this in turn allows to understand who the key players that need to be involved are.
3. A context diagram will help understand how other systems may be impacted and all possible ripple effects.
Scope – Determine what the scope is
A same project has different meanings to different actors. A project manager's perspective on a project is different from a business analyst or corporate.
It is therefore important for the documenter to determine what his scope and contain the document to the scope defined.
Information – Keep what you need vs. what you don't need
Once the scope and the audience are determined, it is important to limit the document to what is needed vs. what is not. A great example provided in the presentation: if the solution has alternatives, don't start discussing the alternatives further (I already cringe when I hear talking about solution anyway).
Documentation – Don't document in buckets, but more with regards to the process
Many companies use templates which are usually outdated. On top of that, although creating a website or a new datamart are two IT activities, the requirements are certainly much different.
A great perspective is to not limit to a template but adapt the document to the actual process.
Good stuff as per usual, thanks. I do hope this kind of thing gets more exposure.
I think the point about scope is different for every member that is involved. Really an important thing to remember when you are managing scope. Speak in the listeners terms.