Qlik Community

QlikView Management

Discussion Board for collaboration on QlikView Management.

Not applicable

Requirements Capture

Hi all, I am a project manager working a healthcare organisation deploy QlikView. We have one consultant and a few staff members that have just attended the Designer and Developer courses but have no real-world QlikView experience.

As part of my duties, I am meeting our various services and capturing their requirements. However, I am struggling to find a satisfactory way to communicate the requirements to the team members. At the moment I am just letting them know where the data is coming from and what are the main axes that the clients are interested in.

My questions to the more experienced developers are: what do you want to hear when you are first asked to develop a QlikView app? What is essential to you? What mistakes have you seen done in the requirements capture phase?

Many thanks,


6 Replies

Re: Requirements Capture

Perhaps user stories are a good method: User story - Wikipedia

talk is cheap, supply exceeds demand

Re: Requirements Capture

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.

Re: Requirements Capture

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.


Valued Contributor II

Re: Requirements Capture


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

Best Regards


Valued Contributor

Re: Requirements Capture

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.
Not applicable

Re: Requirements Capture

Thank you everybody!

This is very useful, you have all given me some good food for thought.

I look forward to digging a bit deeper in your answers and start applying your advice.

Community Browser