In my previous life/positions, there had always been this split between functional teams and developers, especially on the ECC side. Functional teams gather requirements, build functional specifications, and turn them over to the developers. The developers then build the application, perform unit tests, and turn them back over to the functional to test.
For some reason, our program manager at the time did not think this was necessary for Business Intelligence development work. Our program manager felt BI developers should gather requirements and develop the application as well.
From various customers I would hear this: “Build me a dashboard”; this was my only known requirement. Fortunately, at the time I was enrolled in the Unversity of Virginia course “How to Collect Requirements” where I learned about use cases as a way to gather requirements.
What is a use case? As I presented this at an ASUG presentation, here is a definition:
Then I started to analyze various scenarios of how the various “actors” would interact with the system and develop use cases. Here is an example of a use case description:
Then I would use prototype the proposed solution with the user/actors, to see if it met their needs. It is a springboard to start brainstorming ideas with the end user on how they would interact with the system. I would develop more detailed use case templates with diagrams once the user approved the initial concept (see page 6 of use case template.)
In Alistair Cockburn’s book, “Writing Effective Use Cases”, he correctly points out that this is only captures part of the requirements document – it captures the behaviorial requirements – not performance requirements, etc. More documents are needed, but use case analysis is a way to get the requirements going.
In the past with BI/BW, I always struggled with the old ASAP methodology for BW to “hold a workshop”, strategize, etc. If you are the developer who also has to gather requirements, use case analysis along with rapid prototyping is a great way to get started.