When a business analyst needs to make a decision regarding which elicitation techniques to employ in an endeavor, there are many different aspects they may want to consider. The BABOK lists the following three but each workplace situation could have factors that add to this list.
• techniques commonly used in similar initiatives,
• techniques specifically suited to the situation, and
• the tasks needed to prepare, execute, and complete each technique
ABOUT: techniques commonly used in similar initiatives
I'm not a big fan of this option for many reasons but the big one is the assumption that one initiative is similar to another. If you are basically doing the same thing as the last time, the value proposition the business analyst brings to the table is greatly diminished. Similarity is a slippery slope assumption that can lead to all kinds of issues such as missed requirements, unnecessary requirements and more. I believe you should factor similarity into your decision but it shouldn't be the primary one.
ABOUT: the tasks needed to prepare, execute, and complete each technique
I feel this is more about what techniques to EXCLUDE and less about what to INCLUDE. It is true that knowing what you are NOT going to do really helps in the decision making process about what you are going to do. However, we still have an assumption risk. You may assume that you cannot do a collection of stakeholder workshops because of the project deadline. Deadlines move all the time and you may have more time available than you thought.
So you may adapt your approach to "lighter" versions of heavy techniques. I have found this to be helpful when I suspect a deadline or similar constraint is likely to become less relevant overall.
ABOUT: techniques specifically suited to the situation
This one can fall into " the chicken or the egg came first" situation. How can you know what is “best suited” until after you have started elicitation on the situation itself? Here you can see that you don't have to be locked into a technique or be linear in your approach. If a project can have pilot releases, then the business analyst can certainly have pilot elicitation activities. This allows the business analyst to learn know more about the situation AND ”draw forth" some requirements. Immediately thereafter you analyze the elicitation results, add the requirements you found to your gathered requirements repository and pivot your elicitation approach if necessary.
© 2017 Dwayne Wright