Introduction

Requirements and user stories are a core part of the Agile DSDM Process. These capture what the new system must be able to do for it to be suitable for replacement and improvement of the current way of working. This blog shows how to define requirements and user stories from process maps. Find out more about process mapping in this blog “Process Mapping In Visio Vs Engage Process”.

What is a requirement?

A requirement is a service, function or feature that a user needs. Therefore, a process map may have several requirements that can be drawn from the steps required to get to the end of the process.  A requirement should capture tangible features, but not solutions.

Below is an example process map about collecting missed bins, built using the Engage Process Modeler. Described by GetApp as Engage Process Suite is a business process management (BPM) tool that allows businesses to create custom processes using a visual editor and data mapping tools. The all-in-one process creation and optimization platform aims to help users to visualize their processes, collaborate as a team, assess process effectiveness, and identify areas for improvement.

Each of these steps could have an associated requirement, Step 5 “Customer contacts take details” needs a place to record customer details and functionality to call the customer. Step 6 “Check if within time limit” needs a calculation to see if the current time is past a set cut off time, and so on. A process map is an easy and effective way for gathering and defining this information from the service area. Instead of asking everything a computer system needs to do, a process map walks logically through their way of working.

What is a user story?

A user story captures a requirement from the perspective of a user. This usually helps to capture the reasoning behind requirements and makes the requirements less tech-based, so therefore easier for the users to read and understand, so that when they are asked for input they can give a reasoned opinion.

User stories are commonly broken down into three stages;

• As a [Role]
• I need [Requirement]
• So that [Business purpose]

For example, a user story for step 5 above “Customer contacts take details” might be;

• As a Customer Service Agent
• I need to be able to securely capture customer details
• So that I can keep the customer informed of the status of their case

How both works together

Now that requirements and user stores have been gathered, the next common step is to prioritise them. In agile projects, this is usually done through MoSCoW prioritisation.

Projects have to balance the Time, Cost, Quality and Features delivered, somewhere there has to be a variable. In a traditional project, the cost and time is the variable. Therefore, the project will likely be over time and over budget as all features have to be developed, leading to inconsistent quality. In contrast, an Agile project keeps the time, cost and quality fixed while having the features variable. This leads to high-quality features delivered in time and to budget, but not all features will be developed. To achieve this, the requirements for the project are prioritised into the categories of; Must have,

Should have,

Could have,

Won’t this time.

As a general rule, the Must have requirements shouldn’t take over 60% of the available time and effort in a project or timebox.

More information about MoSCow and timeboxing can be found in this blog.

Conclusion

In conclusion, it is effective to use process maps to help define Requirements and User Stories as it logically lays out the steps in a processes and helps identify which are requirements that would need to be developed. User stories give the background reasoning to requirements, which may have an impact when prioritising the requirements through MoSCoW prioritisation.