Skip to main content
Capturing the different perspective during an early stage of innovation development

Capturing the different perspective during an early stage of innovation development

In the previous article related to the Philips pilot in the STAR project; exploring human-machine collaborations for flexible manufacturing, we talked about the importance of exploring flexibility in manufacturing, the different use-cases we are developing within the STAR project, and how the expected results might be leveraged in order to improve flexibility and further develop our current production systems to work towards the factory of the future. In this article, we are diving into one of the first stages of the development of the use-cases where we decided to focus on capturing the different perspective for systems and components to be developed during the project.

To clearly define the different use-cases and to get an insight in the different perspectives of relevant stakeholders, we decided to run a workshop in collaboration with our partners in the STAR project. During this workshop we wanted to involve people that could help us define the use-cases and come up with requirements from different perspectives. Therefore, we chose to involve stakeholders from all different stages in the project’s life cycle. We invited research partners, technology developers, domain experts and end-users to all contribute to defining the different use-cases as formulated in the previous blog.

During this workshop a small introduction into the use-cases were given to all participants by introducing the vision and goals behind the use-case and providing a preliminary visualization by presenting the current processes (as-is scenario) versus the expected future processes (to-be-scenario). Subsequently, by using a collaboration tool all participants were instructed to define user-stories for the different use-cases one at the time.

These user stories are a popular method for representing requirements by using a template such as “As a [role], I want [requirements], so that [benefit of requirement]”[1] and by gathering the user stories created by the invited participants we aimed to gather as much input as possible from the different points-of-view. The participants could create user-stories for every user they could imagine, but in the end, we could categorize the different user as the 5 users defined below.

  • Organizational user, which focused on the company goals and requirements,
  • Technical user, like technical support staff & mechanics,
  • Operational user, like production managers, team leads, and operators,
  • Technology provider, which focused on requirements during development
  • Researcher, which was focused on the requirements from a continuous improvement point-of-view;

By defining user stories for these different users, we ensured that the end user (from a management level to operator) was involved in defining the use-cases and requirements. While also considering the requirements from a developer and researcher point-of-view to create insight and alignment in the different elements needed for the development of the use-cases. After a successful collaboration we defined a lot of (new) user stories as depicted in the figure below.

User stories per Philips use-case

Finally, the different user stories created were categorized and documented in such a way that based on user stories we could define different components/functionalities that we need to develop along the course of the project to provide as much value to the end user as possible. In conclusion, we can say that involvement of different types of users in the development process for our use-cases and exploring their point-of-view proved to be very successful and is deemed as a positive contribution to the development of the use-cases and therefore to the project.

By: Jelle Keizer, Philips

[1] Lucassen, G., Dalpiaz, F., Werf, J. M. E. M. V. D., & Brinkkemper, S. (2016). The Use and Effectiveness of User Stories in Practice. Requirements Engineering: Foundation for Software Quality, 205–222.