topic Re: Requirements Capture in QlikView

Requirements Capture

Mon, 26 Jan 2026 18:19:17 GMT

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,

David

Re: Requirements Capture

Gysbert_Wassenaar — Mon, 29 Dec 2014 16:36:26 GMT

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

Re: Requirements Capture

Anonymous — Mon, 29 Dec 2014 16:55:41 GMT

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

rwunderlich — Mon, 29 Dec 2014 19:18:55 GMT

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.

-Rob

Re: Requirements Capture

Gabriel — Mon, 29 Dec 2014 19:38:42 GMT

Hi,

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

Gabriel

Re: Requirements Capture

NickHoff — Mon, 29 Dec 2014 20:07:56 GMT

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.

Re: Requirements Capture

Tue, 30 Dec 2014 08:31:36 GMT

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.