Declan Chellar

In Part 5, we documented the high level system requirements of our customer’s change control process.

Now we use the HLSRs and To Be process model to build our workflow model. If you have not already read the series of posts on drawing workflows, then I suggest you do so before continuing.

Click here to see the workflow diagram. Notice that not all the details from the low level To Be process model made it into the workflow diagram. In fact, the workflow diagram more closely resembles the high level version of the To Be model.

If you find your workflow diagram looks more like the low level version, then you have probably included details that best sit within the individual use cases. Keep an eye out for future posts in which I shall give examples of what those use cases might look like.

You will notice I have used colour in the workflow diagram in order to make it easier to follow (I hope). The blue use cases and the blue lines highlight the primary path. I have also introduced a new shape which looks like a shield. I use this shape to indicate that all the tasks coming out of the right of the shield must complete before the flow can continue out the bottom of the shield. I have painted those tasks the same pale blue as the shield in order to make it even clearer which ones I am referring to. I chose this shape arbitrarily, but that’s fine, as long as it is included in the key, which it is.

The purpose of this series of posts has been to give you an idea of how to take an As Is process through to the workflow diagram.

Part 1: we modelled the As Is change control process in order to understand the current business model.

Part 2: we reminded ourselves to be sensitive to the fact that the customer owns the process.

Part 3: we documented the customer’s strategic goals and interviewed the stakeholders to understand each perspective on the As Is process.

Part 4: we used the information gleaned in the previous parts to draw both high level and low level versions of the To Be model.

Part 5: we took our understanding of the strategic objectives and the To Be process to produce a set of high level system requirements. In the real world, this stage is often not executed by the same people who produced the To Be process model. What is more, production of the HLSRs sits outside the system development lifecycle, because they are used as the basis for choosing the technology and the solution provider.

Part 6: we have produced a workflow diagram that sets the context for any lower level requirements analysis (e.g., detailed use cases, business rules, etc).

Of course, this series of posts makes sense to me because I can do it already. If you are trying to learn and any of my points are not clear, please let me know. It is not up to you to get my point, it is up to me to make it.

And if you can think of ways of improving my drawing technique, then definitely let me know!

Kind regards,

Declan Chellar

If you want to see only the posts in this series, select the category Process Exercise.