The problem of last week (BAM Projects get corrupted) has given me extra time to think about the rest of the blog series. In doing so, I came to the conclusion that I had not yet taken the functional requirements as a subject. But without these requirements the upcoming blogs are hard to follow, so in this post I first will mention the functional requirements, from a technical point of view (and briefly describe them). I have translated a drawn dashboard image into the following requirements.
- Click through to humantask. Link to a rule action. Add ability to click through to the related humantask, to view it or act on it as assigned rep.
- Change View type at runtime. Possibility to switch from view of e.g. a line chart to a bar chart or a list view.
- Click through to case details via the used hierarchical organization structure (Judicial System, Department, Team and Employee).
- Summary of tasks. Showing number of open tasks, newly opened tasks and recently closed tasks. Increase/decrease in percentage of number of tasks.
- Starting a related system. Link to a view action. E.g. start the worklist application or a specific website.
- Filter of displayed data in multiple views at once. E.g. all views in which a department is shown, and where it is possible to filter on the department, display information of the same department(s).
- Showing tasks and deadline’s. Indicate how many urgent tasks there are on the basis of urgency.
- Change parameters at runtime such as the degree of urgency. Urgency is the number of days for due before it is urgent.
- Updating views without pressing the refresh button. Use active data so that the view is dynamically updated.
- Dynamic displaying images. Depending on the selected data a different picture is shown.
This were all requirements that I had to investigate at part of the POC. For this blog series I added a few additional requirements.
- Make resulting risks visually insightful. For example, because there are many open tasks, the treatment time gets under pressure.
- link actions to detected risk. E.g. send an email to the department head.
And an overall question: How much freedom is there in the graphical representation of views on a dashboard?
In the coming blogs I will regularly refer to these requirements. At each object (e.g. a Business View) I will refer to the requirement it contributes.