Requirement Gathering Techniques - Part I - Know the situation
My next set of posts will speak to the different types of techniques that can be employed to gather requirements for a project.
It is important to understand which methods are appropriate (or conversely which ones are not appropriate) for a given situation and to choose accordingly. The selection of an inappropriate tool will hinder your efforts.
I like to think that as I learn and experience more, I am refining my own approaches as well as learning new techniques. This allows me to have a larger repertoire of tools (in my "toolbox") that I can use to tackle future opportunities. At least, that's my personal philosophy on this subject.
One of the first things that you should understand is, "What is the situation?" Usually this is fairly self-evident, however, you should always make sure you are at least pointed in the right direction before you start running.
To understand the situation, criteria that you should consider are:
The nature of the project
- How much is known about the project (i.e., is there already a defined idea or are facilitative efforts needed?)
- Are there user interface requirements?
- Have similar efforts been done before (internally or externally) that can be leveraged?
- In a utopian society, we have lots of time. In the real world, sometimes we are already behind before we even start. Are you in that situation?
- Are there hard deadlines that cannot be moved (i.e., legislative mandates?)
- Is this an investigative or facilitative effort?
- Who are the different people involved?
- What time commitment can the key clients, end-users and subject-matter experts provide?
- Are external resources, such as legal experts, needed?
- Is potentially useful information available on research sites like: Gartner, Forrester, or the Yankee Group?
- Are there user groups or independent communities that can be leveraged?
- How much knowledge does the business analyst have on the subject?
No comments:
Post a Comment