Stakeholders

There are two groups of stakeholders, firstly there are users of the program, and then there are the developers. The user group contains, embedded system engineers, embedded system students and lastly, clients of those engineers. The second group, includes both me, as the initial developer, as well as any future developers that might work on this project by contributing to the program. A complete list of all the addressed stakeholders in this section:

● Embedded System / Software Engineers ● Embedded System Students

● Clients of Embedded System Engineers ● Developers

5.1.1. Embedded System / Software Engineers

Various dataflow models exist that embedded system/software engineers can work with to model dataflow, such as task computational graphs [10] and SDF graphs. SDF graphs are more expressive, and can efficiently model and analyse multiprocessor applications, like MPEG-4 and MP3 decoders. Currently the people who work with SDF have often devised their own tools. These tools are often not very matured and most of the time only text-based. For visualisations these people usually rely on manually drawn graphs on either whiteboards or in computer software.

The envisioned program will offer a more polished visual toolset to work with. This can help with the analysis and comprehension of the SDF graphs these engineers are working with. Furthermore, they can automate the generation of visualisations of these schedules to a large extent, instead of having to do this manually. Also it will save them the investment of time and skill of having to devise their own tools.

An engineer can use the tool by generating a SDF schedules with their prefered allocation strategy for any SDF graph. After this is completed the schedule has to conform with the format that can be loaded into the program. If successful, the engineer can load the schedule into the program and observe different visualisations of the loaded schedule. The desired functionality for this user can be described as follows:

● Rapid visualisations of the generated schedules

● Visualisations should be clear and conform with standards of SDF schedule visualisations

32

5.1.2. Embedded System Students

An embedded system student has to get familiar with various dataflow models, since it is a powerful tool for the analysis of streaming applications. After completing their studies this group can turn into an embedded system/software engineer. However this group is here considered as a separate entity since the needs of these students differs from working engineers in the aspect that this group focuses on learning, whereas engineers focus on analysis of SDF. When students have to study SDF the tool could provide student with an interactive visual support next to the existing learning methods. This would create a more ‘hands on’ approach as indicated in one of the user interviews. For the tool to be useful this groups needs to be able to access the tool in educational institutions, but perhaps also on personal machines. The desired functionality for this user can be described as follows:

● The tool should provide insight into SDF schedules, so this user can study them

● The tool should be easy to use, so students do not have to invest in learning the tool too ● Visualisations should be clear and easy to understand.

5.1.3. Clients of Embedded System Engineers

The tool could provide value not only to the engineers who directly work with SDF but also to clients of these engineers. This group hires embedded software engineers to develop a certain application, which might have certain design requirements. The engineer could use SDF to model and analyse the behaviour of the application, and could conclude that the requirements are not feasible. Since the clients often do not have a deep understanding of these techniques it can be difficult to explain why the requirements cannot be met. The visualisations in the tool could be used to showcase the analysis and models. Which can make it easier to communicate to clients why the requirements are not met. It is important to note that these visualisations are of a different nature, since they showcase and explain. Opposed to the visualisations an engineer is interested in, which aim to convey as much data as accurately as possible. The desired functionality for this user can be described as follows:

● Aesthetically pleasing visualisations

● Easy to understand, even if the user does not have any knowledge on SDF

5.1.4. Developers

This group includes anyone who contributed to visualisation tool itself. This can be done by either adding new functionality, or expanding upon existing functionality. Developers invest time and skill into the tool to accomplish this. There are various reasons one could do this, e.g. financial reward, fame but one can also do this to tailor the program to their own needs. A person in this group can, or is likely, also part of one of the user stakeholders which are previously mentioned. The desired functionality for this user can be described as follows:

● Needs to be able to modify the tool, preferable from the source

33