Today, for the development of most enterprise software, an analyst will be assigned to do requirements gathering from stakeholders. Our opinion is that despite much study and research in this area, the requirements gathering and analysis process used by most IT vendors today is still imperfect. Miscommunication frequently happen between stakeholders and analysts, and between analysts and developers. Besides, the total man-hours needed by all the parties involved is quite substantial. A 1992 report written by Christel and Kang https://bit.ly/2yr8pHd about problems in the requirements gathering process is still valid today.
We believe times are changing. Having formal IT education is becoming more and more prevalent in today’s workforce, and even those without formal IT education are becoming more and more IT-savvy. Hence, stakeholders are now in a position to play a bigger part in requirements engineering. Besides, stakeholders understand their own needs better than analysts and developers.
We attempt to innovate by inventing a technique of empowering stakeholders (i.e. all those who will use or be affected by the software), so that they can play a bigger part in requirements engineering. This movement of empowering stakeholders can be relevant across many types of enterprise software, but we first focus on workflow software. Workflow software automates, to at least some degree, a process or processes within an enterprise. An example of a process that can be automated using workflow software is a purchase order that moves through various departments for authorizations and eventual purchase.
We invent the Workflow Canvas to empower stakeholders to play a bigger part in requirements engineering of their workflow software. The Workflow Canvas is a shared language between stakeholders and analysts for conceptualizing and describing software. UML diagrams are a shared language between analysts and developers, but what about a shared language between stakeholders and analysts?
Before the introduction of the Workflow Canvas, there was a void in the marketplace of a technique for stakeholders to brainstorm, discuss, design, conceptualize and describe their software needs. You can think of the Workflow Canvas as a mind map technique for workflow software. Compared to the conventional methods used to describe requirements, using the Workflow Canvas is better and easier, without needing sentences or UML diagrams.
For some simple workflow software, there are companies who currently provide software tools for business users and stakeholders to design their workflow software without the help of consultants or analysts. However, the problem with these software tools is that they require effort from business users to learn to use. This is in contrast to using the Workflow Canvas, which just require pen and paper. Using the Workflow Canvas does not require any skill in using software, and business users and stakeholders do not need to learn to use any drag and drop, form designer and so on which are typically associated with software tools. Furthermore, many of these software skills (e.g. a particular way in which drag and drop works) are specific to one company’s product, hence reducing the value in learning these skills.
Besides creating a shared language for conceptualizing and describing software, we aim to introduce another innovation, which is a low-cost way to translate information obtained from the Workflow Canvas into usable software. We have developed a platform called Fetias, which can cater to a wide number of different workflows with minimum additional coding. The development of Fetias is based on many years of observation and study to gain a better understanding of the workflows that can be automated in enterprises. We did some abstractions in use cases and features, and introduced some significant technical innovations (describing these innovations is beyond the scope of this article).
For us, innovation in creating the Workflow Canvas led to innovation in the Fetias platform. The Workflow Canvas is elegant because from the information on a piece of paper, an analyst will be able to configure the Fetias platform to create usable software without much time and effort. This is because the Fetias platform is designed based on the information obtainable from the Workflow Canvas.
The innovations we introduce reduce the cost of workflow software, and many of the ideas mentioned in this article are applicable to other types of enterprise software. An economist will tell you that when the price of something falls, we use more of it. Hence, we are likely to see more widespread use of enterprise software and new use cases throughout organizations. CEOs, department heads and knowledge workers will spend more time tinkering and experimenting with software to make themselves and their organisations more efficient and productive.
Note: This article was originally published at LinkedIn.