I second Gysbert's suggestion of user stories as a way to state requirements. If your team has taken the Designer & Developer training, they will have seen the two business/project plans presented there. I think those are decent templates for generating specifications for development. Specifically, the identification of audience, Dimensions and KPIs.
Any QV App will present data to people.
These people will then make decisions / do things based on the data they have seen, such things may include :
- Adjust resources [money, time, staff, etc...] allocated to a task
- Make / receive payments if SLA's [Service Level Agreements] are reached
- Foresee a potential problem and avert it
- Phone you and tell you it looks pretty
This to me is the crux, defining the End Game in non QV / non data terms and making all team members aware of it.
Once everyone knows what this End Game is, then specifying the details needed to achieve it is easier to define and understand.
Things to add to Gysbert's comment above are:
1- Communication, it should be 3 ways. Business Analyst to Developer and back to Business as in Users (Very important, it's never too much)
2- In depth documentation
3- Business logic should be full documented
4- Diagram to explain data sources
As a developer the most important requirements to me are the dimensions and the metrics being utilized in the application.
- Having the dimensions and metrics gives me a good starting point, but the requirement phase should be an ongoing communication between the business owner and the team. Very rarely, a business owner knows exactly everything they want by the first POC session.
- Having the current reports the business owner is producing as a reference will also help tremendously. In the end it's up to us to take that existing report and turn it into a Qlikview application that blows the current report out of the water.
- It's important to be agile throughout the development because the application will go through several different changes based on the business owners feedback. Involving the business owner in the QA phase will most certainly prompt changes from the original requirements.