Deliverable Overview
Home Business Change Analysis & Design Agile Testing Templates About us


Parts of template

This section gives an overview to the parts of the deliverable, and gives guidance as to how to complete it. It is important that each part of the process design complements and references each of the others.

The template that drives this deliverable is essentially broken into three sections:


Context: Gives background to what and who plays a role in the stage of the process being considered. Includes a range of models to help define this scope.


Scenarios: The main part of the document – gives the impacted participants instruction as to the best (and most controlled) way to fulfil their responsibilities.


Supplementary specification: Descriptions of all terms (such as reports) referenced by the above scenarios

Describing the Context

As well as establishing the goals and purposes of the (sub)process in more detail, this section summarises the:


key ways things are performed in the (sub)process,


different ways in which they are performed, and


range of roles required to both perform and support them, and


responsibilities to service them.

It is important that the summary section is described in a manner that allows a third party to read and understand them (at least to the degree of assessing the relevance of the sub-process to them).

What are the goals?

There should be a brief (entirely work based) description of the process. The focus on this section are its main outputs are and why.

What are scenarios?

The main aim of (sub)process design is to describe in detail, how to produce a set of deliverables in the most effective manner.

There is typically not one “correct” path in which to produce these deliverables, as there could be differences in the steps to cover situation where exceptions occur and differences in how to react to information from different source systems.

Trying to embed this complexity into a single “script” would result in something that looks like a computer program – clearly something that would fail the requirements to be clear and concise!

Instead of doing this in one hit, a number of scenarios are defined for each sub-process, each describing a specific and stated case.

How many scenarios do you need to describe?

Each sub-process will have a number of business scenarios to describe it. At minimum there will always be two, but typically there will be more:

bulletOne for each output where the steps to produce the output are different (if several outputs are produced by the same set of steps then it is fine to have just one scenario).
bulletOne for each divergence as to how the outputs are produced depending on the input, pre-conditions or some other external factor.
bulletOne for each exception where the steps to produce the exception is different. If no exceptions are possible, still have scenario, but put N/A or something like that.

Remember, this is process design so it is fine to have pedantic detail. If the steps are only slightly different (perhaps on different data, or the same processing but with a different responsible user role) then this still warrants more than one scenario.

Why, if there is significant divergence between the steps, keep them in the same (sub)process document? Consider that if these scenarios share the same goals, have the same (or similar) intermediary and end-deliverables, same (or similar) control points then keeping them in one document keeps repetition to a minimum, and promotes process conformity.

Summarising scenarios

Given that there will be a number of scenarios, it is important to give the reader a summary explanation of what these different scenarios do, so as to help him/her navigate through the document.

This summary should cover for each scenario in the sub-process:


The goals of each scenario


Key differences between them (such as different steps, deliverables or actors)


Key similarities/commonalities and how they relate to one another.

Responsibility summary

If the scenario summary is seen as giving an overview of what is done, responsibility addresses the question of by whom.

Whilst the different areas of responsibility can be inferred from the scenarios themselves, it is useful to summarise all the different areas of responsibilities in one place. Whilst this does mean that this same information is described twice in the document, there is a different emphasis: the scenario’s purpose is to describe things in a dynamic manner (it is after all a process description) whereas this responsibility summary can be considered a “static snapshot” of all the things the users will be expected to do broken down by user role.

Parties reviewing the document for business impact or to asses audit issues can thus see this information in one place, without having to search through the scenarios.

Thus, what the template covers is:


 User role


Relevance to Process: This can be either external[1] or participant. See following section on description of actors and participants in use cases as to what this means.


Designated contact


Summary of each responsibility, broken down by source system differences (if applicable)


Core deliverables

Document dependency

Given that process design involves re-engineering, business and architectural change, then it is important to describe any dependency on which any new part of the process is based on. In addition, if there are assumptions based on future changes in underlying technology (e.g. decommissioning of a specific system), these must also be considered.

For both such cases acceptance of the document is wholly dependent on the dependency being accepted by the process owner. Therefore these document dependencies must be described in the process design document, and should cover:


New area in question


Dependent on what


Area of document impacted

For example: If a new report is introduced as part of the process design documents, it may be dependent on its acceptance by the business or delivery by third-party.

By emphasising such assertions, the document can be easily modified should they change over time, or the document’s signoff can be made conditional upon them.

[1] “External” is actually the “Actor” of the business use case using UML terminology, but is used in preference to that term as it is more likely to be understood by those without UML skills.


Back Next

© 2002-2007 Codel Services Ltd

This paper has been prepared by Codel Services Ltd to illustrate how structured business modelling can help your organisation. Codel Services Ltd is an IT Consultancy specialising in business modelling. If you would like further information, please contact us at: Deryck Brailsford, Codel Services Ltd, Dale Hill Cottage, Kirby-Le-Soken, Essex CO13 0EN,United Kingdom. Telephone: +44 (0)1255 862354/Mobile: + 44 (0)7710 435227/e-mail: