We talked about best practices for gathering business requirements in class, and I thought I would expand upon what we discussed.
Source Quality
It is important to point out that we should take some time to think about exactly whom to gather requirements from, because depending on the source, the answers we get may have varying degrees of value to us. For example, in some cases, the marketing department's input may be more helpful, while in others, the accounting department may provide more valuable information for our BI/DW work.
Key Techniques
There are specific ways via which we can gather requirements, and we may get different results at different degrees of quality and specificity. If there are no clearly defined questions, a brainstorming section, which allows free exchange (i.e., anything goes), may be the most helpful. If there are specific questions you are ready to ask, then one-on-one interviews may be better. If you are unable to find a time that both you and your clients can meet, perhaps a questionnaire is the way to go. Finally, in the case of system upgrades especially, studying the existing system may be a good starting point, because you can gather a lot of the same requirements that way without having to talk to the clients.
Selecting a Technique
You may wonder how we can select the best technique to gather requirements. Below is an interesting framework that may provide some guidance:
Based on where your individual situation is in the graph above, you can select the right technique as follows:
Source Quality
It is important to point out that we should take some time to think about exactly whom to gather requirements from, because depending on the source, the answers we get may have varying degrees of value to us. For example, in some cases, the marketing department's input may be more helpful, while in others, the accounting department may provide more valuable information for our BI/DW work.
Key Techniques
There are specific ways via which we can gather requirements, and we may get different results at different degrees of quality and specificity. If there are no clearly defined questions, a brainstorming section, which allows free exchange (i.e., anything goes), may be the most helpful. If there are specific questions you are ready to ask, then one-on-one interviews may be better. If you are unable to find a time that both you and your clients can meet, perhaps a questionnaire is the way to go. Finally, in the case of system upgrades especially, studying the existing system may be a good starting point, because you can gather a lot of the same requirements that way without having to talk to the clients.
Selecting a Technique
You may wonder how we can select the best technique to gather requirements. Below is an interesting framework that may provide some guidance:
Based on where your individual situation is in the graph above, you can select the right technique as follows:
- Catch-up: Interviews, work in target environment
- Fuzzy: Brainstorming, workshops
- Mature: Questionnaires, workshops, prototypes
- Selling/Teaching: prototypes
I hope that helped in shaping how you approach the critical requirement gathering process in BI/DW design!
Reference: http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/guidelines/req_gathering_techniques_8CB8E44C.html
No comments:
Post a Comment