Process flows are the workhorses of the RML® models that we employ here at ArgonDigital. They can be easily understood by even the least technical stakeholders but are equally useful for the development team. They can be applied to many different circumstances and provide tons of value. We use them on almost every project, and in lots of different ways. In fact, as I was brainstorming ideas for this post, I realized that we use process flows at every stage of the requirements phase, from the meetings we hold to elicit requirements at the beginning of a project to the finalized business requirements documents that we deliver to the rest of the team.
1. Using process flows during elicitation sessions – Even at the very beginning of projects, before I have met with stakeholders, I try to create incredibly simple, high-level process flows using any background information I have, past experience working on similar projects, or even some outside research that I’ve done on the topic. The point is NOT to show up to the first meeting and impress everyone with a complete set of 100% accurate process flows (if you can do that, great! But chances are that won’t be possible). Rather, the idea is to get the conversation started by putting material in front of your stakeholders and having them tell you all of the reasons why it’s wrong.
We call these types of models “strawman models,” since they’re really easy to rip apart…but that’s the whole idea! Instead of simply saying to your stakeholders, “OK, tell me about this process,” we’ve found that people provide much more useful information when they have something to look at as a starting point, even if it’s wrong. Of course, strawman process flows are only useful to get the conversation started. After they provide the information it’s up to you to use that information to create more accurate flows and repeat the review process until you have captured the information accurately.
2. Using process flows to write requirements – After you have revised your process flows during elicitation sessions with your stakeholders, it’s time to write your requirements. Process flows can be very helpful in this stage of the project as well because you can use process flows to uncover requirements that you may have missed otherwise. As I write requirements for a given area of the project, I always have process flows nearby to serve as a trigger for asking questions.
For a given step in a process, I might ask: “what does the system need to be able to do to accomplish this step?” or, “how does the process move from the previous step to the next step?” Or maybe, “What user interactions with the system will be part of this process step, and how should that interaction be accomplished?” If there is a decision involved, there may be some business logic that you need to work out. How will this decision be made? Is the system making this decision, or is the user? The answers to all of these questions should be documented somewhere in the requirements because as we all know, the answers will need to be decided sooner or later!
3. Mapping requirements to process flow steps – After you have gone through and written requirements based on the process flows that you’ve created, a helpful exercise is then to map the requirements you’ve gathered to a particular step in a process flow. By identifying which step in a process flow a particular requirement relates to, you can better check yourself to make sure that your requirements cover everything.
If you find a process flow step without a requirement that traces to it, you may be missing some requirements! Alternatively, sometimes we find requirements that don’t map back to a process flow step. In that case, it may be that the requirement is unnecessary. Get rid of it and save your development team some time and money. If it is NOT unnecessary, then maybe there is another process that you haven’t documented adequately and it’s worth investigating. Either way, because you mapped your requirements back to process flows, you will eventually be left with a set of necessary, but complete requirements!
4. Presenting information using process flows – After you’ve finished documenting everything, ensured that you’ve covered all of the important areas, and hacked away all of the unnecessary requirements, it’s time to present your work to your stakeholders for review and signoff. Here, too, I’ve found that process flows can be a very useful tool. I like to organize my requirements documents by process flow. First, I show the process flow with a brief blurb about what it’s describing, then I display the requirements that relate to the process flow underneath. Looking at the process flow provides context to the requirements that you will be discussing.
Assuming that you have high-level process flows that break out into lower level process flows, and you have included the mappings of requirements to process flow steps, your reviewers will be able to see how a certain requirement relates back to a process flow, and how that process flow fits in to the larger features of the project. It also provides a convenient way to organize requirements into manageable, easily reviewable chunks. By breaking requirements into groups of 10 or so–rather than a big long list–people are less likely to fall asleep and MORE likely to give you useful input!
These are the some of the main ways that we use process flows here at ArgonDigital. How about you? Do you have any novel, ingenious, or exciting uses for process flows?
