There are at least three good reasons to map software requirements to process flows. In this post, you’ll learn why I’ve mapped requirements to process flows in order to:
- Elicit more requirements, for completeness.
- Ensure traceability.
- Demonstrate completeness.
We produce models to derive and support our requirements. To demonstrate that we’ve captured the software requirements within our scope, we map them to process flows. If you read our earlier blog post about the Requirements Mapping Matrix, you know we like this for traceability and the ability to demonstrate completeness.
This is especially helpful when you’re working on a gigantic product. For example, a project where I was assigned involved launching a new business unit for a company: a commercial credit card. There were about 30 branches in our feature tree with countless sub-branches. Each branch was a feature (for example, “Statements”) and sub-branches were sub-features of the main one (for example, electronic delivery of statements). We split each branch into its own requirements area in order to make requirements elicitation and documentation manageable.
For the most part, the scope was clearly defined for each branch; however, there were a couple of instances where the scope of one could easily bleed into another. So within each area, we produced process flows to understand the process and what needs to happen, leveraging any existing processes within the company. Because we had the process flows, we were able to derive requirements from them, mapping requirements to flows, showing from where the requirement came.
During the mapping process, I found some requirements that didn’t map to any flows. For these, I made a new flow which uncovered other requirements and provided another focus area for the SMEs, which allowed for additional requirements specification. Without mapping software requirements to flows, it’s possible these requirements would have either been lost or taken much more effort to find, both of which would have cost the company a significant amount of money.
Although it might be considered a tedious task, requirements mapping to process flows is always a good idea, no matter how large or small a project. It was incredibly helpful for me due to the large scale of the project discussed above; even on smaller projects, where there is only a single (or a just few) flows, you’ll quickly see benefits.
