Workflow Driven Elicitation

Eliciting a set of user stories can be a challenge when stakeholders are not sure where to begin their description of the solution they require. It is often up to a Requirements Engineer (RE) to guide the stakeholders along in assessing the problem in need of a solution, as well as assessing the best solution for the problem. The RE must further help the stakeholders partition the solution’s description into manageable tasks, and express those tasks as User Stories.

Workflow Driven Elicitation (WDE) is a systematic approach that helps achieve all of the above. At the center of WDE is the concept of a workflow, and the six basic mechanisms that can appear in a workflow. We define a basic workflow as a sequence of tasks that make up a process. Aside from the fundamental mechanism of sequence, common to all workflows, there are five other mechanisms, namely: Selection, Atomic tasking, Parallelization, Conditions, and Iterations. Selection means that a sequential path has more than one option as to where to transition next in the sequence. Atomic tasking is the subdividing of tasks into smaller tasks, until a task cannot be divided further, and thus, is considered functionally atomic. Parallelization refers to concurrent processes that can occur in a workflow. Conditions can prevent or allow transitions between two given tasks. Iterations are a given task’s need to execute more than once.

On the surface, the workflow definition may not seem to be synonymous with requirements. However, functional requirements can often be expressed as a sequence of tasks. Thus, it can be argued that workflows can be used as the basis for expressing a set of requirements. Often times, the stakeholder desires the software implementation (e.g. automation) of a process, be it a tester, an embedded system, or a windows application; that process can often be described as a workflow by the stakeholder, even if only as a high level sequence of tasks.

The WDE approach is implemented as follows: the RE elicits, from the stakeholder(s), a basic workflow that describes the process that requires an automated solution. The initial workflow can be as high level as comfortably expressed by the stakeholder. This means the initial workflow can be strictly sequential; focusing on the major tasks in the general order in which they are to occur. The understanding is that the actual, complete, workflow is likely to be more complex, exhibiting the six mechanisms common to most workflows: Sequence, Selection, Atomic tasking, Parallelization, Conditions, and Iterations. But rather than try to initially conceive the complete workflow, the stakeholder is allowed to focus on the sequential order of the major tasks.

The other five mechanisms are later added using a checklist of questions that are designed to weed out the need for selecting a different path (Selection), subdividing a task into smaller tasks (Atomic Tasking), carrying out a separate process in parallel (Parallelization), conditionally transitioning from one task to another (Conditions), and iterating through a given task several times (Iterations).

The five questions can be applied to the initial workflow in any given order, and in a recursive manner; the goal is to complete the workflow with as much detail as possible. Once the workflow has been completed, the tasks can be elaborated into User Stories. Generally speaking, the WDE approach proceeds from a high level of abstraction (the basic workflow sequence) and progresses toward greater and greater detail, culminating in a set of detailed User Stories. This is similar to how someone might draw a complex, detailed drawing by starting with more abstract, circles and squares. As with most of the elicitation techniques presented, the goal is to raise questions sooner than later.

In the attached PDF file, the first page defines WDE, using graphical representations. The second and third pages show an example of how WDE would be applied to a real-world embedded application.

As always, readers are encouraged to try part or all of the approach presented here; comments and suggestions for how to modify and/or improve WDE are welcomed

Daniel Aceituna

About Daniel Aceituna

Daniel Aceituna has a PhD in Software Engineering and has published several papers in the area of requirements engineering. He is currently a Senior Test Engineer for DISTek Integration, Inc. and has been with the company since 2012.

Share this post with your friends.........
Facebooktwittergoogle_plusredditpinterestlinkedinmail

Follow DISTek......
Facebooktwittergoogle_pluslinkedinyoutube

Leave a Reply

Your email address will not be published. Required fields are marked *