What do you require from KTracks?

In a series of articles we illustrate the user centered design process from scratch, based on a still missing application in the KDE world: KTracks, an endurance activity tracker. In this part #2 we talk about requirements.


In the last posting we presented the vision of KTracks, the KDE tool to track GPS based activities, and discussed personas (the target users) and scenarios in which it is applied. Now we want to go into detail and collect the functional requirements based on users’ needs. The presentation follows the SCRUM principle with <Who> wants <What> because of <Why>.

User Stories

User stories are used to describe the functions a system must provide. By capturing the ‘who’, ‘what’ and ‘why’ of a requirement in a simple, concise way, it offer a quick way of handling customer needs.

  • Susan wants to read out data from her device to manage it on the computer.
  • Susan wants to get artifacts automatically removed to have valid results.
  • Susan wants to view a particular activity including a map and diagrams to review it.
  • Susan wants to mark sections in one graph (e.g. high heart rate) to see dependencies in the other (e.g. ascent on map).
  • Susan wants to summarize activities to find trends in data.
  • Susan wants to share results on social media platforms to compare with friends.
  • Matt wants to import data from other tools to have all activities at one place.
  • Matt wants to export activities for use in other tools.
  • Matt wants to run own calculations to analyze the hell out of his data.
  • Matt wants to cross analyze data from different types of activities for advanced comparisons.
  • Matt wants to anonymize properties before sharing for privacy purpose.
  • Matt wants to sort and filter activities to easily find and compare those with the highest effort or maximum distance.


  • Susan wants to handle as well data without GPS information, e.g. heart rate monitor at the gym.
  • Matt wants to prepare workouts and upload them to her device to have all features in one hand.

Technical requirements

Besides the functionality there are probably some technical requirements. This refers to

  • the way data are stored (database),
  • how tracks are shown on a map (via Marble perhaps),
  • the plug-in system that offers the opportunity to extend the tool for new hardware,
  • a way to enter self-defined formulas both easy to use and with a high flexibility (Python),
  • what is needed to draw a very flexible diagrams

That discussion should be done by programmers.

As a good starting point we have the program Workout, an (unfortunately abandoned) KDE application to read GPS data from a N900 device and show it in Marble, and the open-source program Goldencheetah which is basically designed for cyclists.

Your Feedback

Do you have special needs beyond those from Susan and Matt?  Please join the discussion.  Your input will be picked up for the mockup that is being prepared for the next posting.

0) { foreach ($sd_categories as $category) { array_push ($sd_result,$category->term_id);//<-- gendert von name zu term_id anpassungen ntig!! } } ?>