Scenarios

Techniques in describing Scenarios

Identifying scenario beginning and end

A scenario flow starts with an initiating event (usually from another party), and concludes with a handover deliverable. A number of different things may also be produced along the way in addition to the handover deliverable.

Whilst the end deliverable is implicit from the flow steps (see later), restating it again emphasises that this is the deliverable that the owner is obliged to produce as per the terms of the process and ownership document they signed off on.

Triggered by: Event and dependency [Follows from: <<cross reference prior BPF sub-process>>]
	<= The steps required to reach end point =>

Completed by: Action and deliverable [Leads to: <<cross reference next BPF sub-process>>]

Describing each step

Steps are the procedures how in which a (sub)process will be executed. Each and every step must describe: who performs, what (and how) is performed, where information is contained, any embedded application control.

To provide clarity in these areas each step is to be structured in the following manner:

	User/role perform action
	Action
	Things on which actions are performed on
	Technology/functions by which action is performed

So generically each step will look the following:

User does something to something utilising specific technology

Keeping the style consistent to the above, will make the steps much more robust.

As part of the QA process, each of these elements should be able to be identified in each line. If not then the step is not perspective enough.

“User” component of step

To promote that these procedures are “instructions”, each step in the procedure must begin with the user role responsible for executing the procedure. Some notes as to describing the user:

	The user should only be expected to perform one action per line in the procedure (unless these actions are logically part of the same thing)
	To emphasise the user, use the bold font whenever a user is referenced. The user must always begin each line of the procedures
	If the user is giving something to another user, put the giving and receiving as separate procedural lines, since the first user has the responsibility to give something, and the second user has the separate responsibility of receiving (one is not necessarily guaranteed to follow the other – they are two separate things!)

“Action” component of step

Always make role that has responsibility clear – do this by starting each step with the user performing action.

Use active style, i.e. have verb as second item. The verb will be subject to control (unless it is an explanatory step). The object (typically a noun) is the something performed on, and is subject to audit or evidence based investigation. This noun could be explained further in the data model, exception business rules etc.

Try and keep only one verb per step.

Avoid using terms that imply conditionality where there is none. Terms such should, will or must can be omitted.

e.g.

Business User should check whether the files are OK

Becomes…

Business User checks whether the files are OK

Use of SOX significant steps for action

SOX/Audit mandates the identification of certain steps that are key from a risk and control perspective, and succinctly and sufficiently describe how they influence the flow of transactions. Such verbs are:

	Initialise
	Authorise
	Records
	Processes
	Reports

Where the step implies one of these action, then for consistency the active verb in the flow should be replaced with one of the above. This gives the work flow steps a more control-centric emphasis.

Example of use of SOX significant steps:

Rather than:

Once the Business Users have completed the activities in 1.1. Data Preparation, the Business Users will produce the automatic files.

Have…

Business Users initialises the production of the Automatic Files by entering into the create function of the framework

The exception to this is “Processes” which is too generic to be of any use – so instead of using this term, use the specific term that describes the nature of the processing e.g.

	Validates (try and use instead of other similar terms such as checks or reviews)
	Reconciles
	Views
	etc

“Object” component of step

Each object (normally a noun) in the step is typically some for of intermediate deliverable in its own right, the specification of which must be detailed within the supplementary specification part document (but not in the flow itself).

For example the supplementary specification will cover the following:

	If it is a report – then the fields that make up the report should be described.
	If it is a table – then the key attributes should be described
	If it is a notification – the mechanism of notification, SLA and the recipient.
	Controls will also need to be similarly described and designed.

To emphasise that these are formal parts of the process, it is recommended that these deliverables have an initial capital letter and are underlined.

It is important to note that unless the deliverable of the step is very trivial, do not try and fully describe it as part of the step itself, as this may make the step difficult to read, and dilute its prime purpose of defining a procedure.

For example if a user has to set up 20 attributes as part of a step, do not list them all (if its just a few, then fine) in the step itself. Rather, state something along the lines that the user fully populates all required attributes along the guidelines shown in the specific section of the supplementary specification.

“Function/Technology” component of step

Given this delivery is the process design; they must tell the user how to perform the step utilising technology available to them.

So as well as stating the “how” it is also the “…on what”. Thus it will need to instruct the user as to the functional part of the toolset that is to be used to correctly/efficiently fulfil step.

Whilst enough detail should be given to provide unambiguous guidance as to what specific part of the tool to use – the instructions are not a “dummies guide”– i.e. it assumes some knowledge and training in the use of tools, and for this reason screen shots are not recommended.

An example of describing the how.

Rather than:

Account Clerk initialises the reconciliation

Have…

Account Clerk initialises the reconciliation by adding an entry with the reconciliation tools create reconciliation function

Conditionality as part of a step

As each scenario states a specific case, try and express conditionality by using active rather than passive language.

If there are large divergence in step logic, consider a separate scenario covering a separate specific case.

An example of passive conditionality.

Rather than:

“If there is a problem with the data in the Platform, Business Users will investigate and correct the problem before they send the file to Platform operations”

Have…

“Business Uses investigate and corrects any data problems with in the Platform, prior to sending the file to Platform operations”

It is fine to state these checks as part of the “happy day” scenario, as these checks are part and parcel of what a successful flow is. If however you are describing conditionality based on the consequence of a previous step being unsuccessful then you are probably describing this in the wrong place.

In the following example the second step tries to explain how the consequences of the implicit conditionality of the previous step are to be resolved.

An example of embedded conditionality

Rather than:

If there is a problem with the data in the Platform, Business Users will investigate and correct the problem before they send the file to Platform operations

If there is a problem with the data in the Platform, Business Users will investigate and correct the problem before they send the file to Platform Operations

Have the first line (rephrased) in the original scenario (as shown earlier)…

Scenario: Processing without exceptions

Business Uses investigate and corrects any data problems with in the Platform, prior to sending the file to Platform operations

And the second line moved to a different exception scenario….

Scenario: Platform exceptions encountered

Business Users investigate and correct problem by interrogating data using the tool and applying exception remediation business rules

Not that for exception scenarios the steps should highlight the investigation and corrective measures implied in the above text in somewhat more detail (detailing who, what, how etc).

If there is a list of things that a user will check then consider a list of bullet points as the way to present it.

Whilst this may appear a minor cosmetic issue, the above example is fairly trivial, for more complex cases managing passive and embedded conditionality by using active language and separate scenario will make the process design easier to follow.

Note also that complex business rules as to resolve an exception should be described in the supplementary specification section, but simply referenced by the step. This promotes the readability of each step. For example:

Business Users investigate and correct problem by applying the Platform Exception Business Rules

See: 3.2 Supplementary Specification

Identifying controls, outputs and process divergence in a step

Whilst control points and auditable deliverables (intermediary or otherwise) can be implicit from the text, it is better to define these explicitly as this aids in their later identification, and helps promote the quality and completeness of the document (remember that all these need to be specified in the document). As a side note, it is probably best assumed that any deliverable on which some decision is made, or has some bearing on the progress of the sub-process, will be audited at some stage.

The above example thus becomes:

Step	Flow	Internal Control	Output	Links to
1.1	Business Uses investigate and corrects any data problems with in the Platform, prior to sending the file to Platform operations	File problems all corrected prior to submission to platform operations (see 3.3)	Exposure File (see section 3.2)	Exception Scen 1.2: Data Problems in Platform

	Output: A list of all deliverables (end or intermediary to step) produced by this step. These will typically be subject to audit, and will require some evidence basis. This latter point is important so try and describe each output as to how it is to be evidenced to have occurred. Where the output is described in the supplementary specification, the section reference should be parenthesised.
	Control: Controls must reference to those identified in ownership document. As more detail is uncovered in the process design it is OK for additional internal controls to be identified. In the above example this is actually a control point since we are constraining the flow by this activity (as evidenced by “..prior to sending”). Rather than leaving this to be discovered by the auditor, give this control a name in the control column.
	Links to: Can have a number of purposes: If the scenario can branch into another (e.g. where there is an exception), the scenario should be referenced. If the scenario rejoins another one (e.g. after exception is corrected, the scenario and step must be shown. If there is some object referenced by the flow (e.g. a reference to a set of business rules or query), that is described in the supplementary specification; these must be listed here (together with the section in the supplementary specification).

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: info@codel-services.com