Chapter 13. Collecting User Requirements
When all the software has been installed, when all the cable has been laid, the servers have been slid into their racks, and the switch is flipped for your BI solution, one group above all will determine the success of failure of your project: the users. And if they haven't been involved from the get-go, more often than not the project will end in failure.
The users are what it's all about. Whether your business intelligence tools are designed for corner-office folks who haven't flown on a commercial flight in years, or whether it's clerks in the accounting or shipping department, their satisfaction with how well the tools work is going to define the outcome.
For that reason, the user community has to be involved in the development process. Now, of course the accounting clerk or CFO who logs in to work with your BI tools may not be able to tell you one thing about whether to use a service-oriented architecture or how often to refresh the metadata. But what they can tell you is how things are supposed to work, what features would make their life easier, and how the BI tools fit into their daily processes.
Users tell designers what they need the software to do, and how it needs to look to support their activities. This role can't be thrown out for the sake of convenience. When developers or database administrators are left to divine how the applications are supposed to perform, they are more likely than not to get it wrong. That's why gathering ...
Get Business Intelligence For Dummies® now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.