Supplementary Specification
Home Business Change Analysis & Design Agile Testing Templates About us

Introduction
Overview
Modelling
Scenarios
Supplimentary
Back

Supplementary specification

Deliverable and dependency specification

Generic artefact attributes required

Every deliverable and dependency (unless described in another document) will need to be specified in this section.

These artefacts can be identified as the objects in the process design. The purpose of the scenarios is to show procedure, responsibility and interaction, so to specify these artefacts as part of the scenario would dilute this purpose. Instead they are specified here.

It can be generally assumed that all these artefacts will undergo some for of audit scrutiny, so formalising them in one place will pre-empt many of the questions that will later be asked.

Clearly it is important to keep the name/term used in the scenario, consistent with the one used in this section.

These artefacts can be

bullet

Reports

bullet

Mapping tables

bullet

Nofications

bullet

Reconciliations

bullet

Data

bullet

Exception resolution business rules

bullet

Queries 

The following information is common to all of these deliverables:

bullet

Primary Owner: The role and designated contact who is responsible for producing it, reacting to information in it or maintaining it.

bullet

Purpose: What is this deliverable for?

bullet

Control: What controls are in place to satisfy and key risk (e.g. access, authorisation etc)

bullet

Evidence Basis: How is this artefact evidenced? Is there an audit trail for the item? Is it printed and filed? Note this may be judged “N/A” in many cases.

bullet

SLA: What criteria will this be judged by

bullet

Nature/Location: What type of output is it? Where is it kept/stored/recorded?

bullet

Technology: In particular if this is tactical report that needs to be productionised, or an existing report that requires a change of platform, this must be made clear here. See also next point….

bullet

Maturity: Is this deliverable already agreed by all parties or is it speculative/process reengineering? What actions are required to formalise the adoption of this deliverable.

The remaining information is specific to the specific to type of artefact, as described in the following sections.

Reports (general)

There must be a clear description of what the report is for, who will look at it, and logically what the information will contain. Much of this is covered in the generic artefact attributes, but in addition to the common information discussed in the last section the following is required:

bullet

Columns

bullet

Sources of data

bullet

Aggregations or summary information

bullet

Relevant data ranges

bullet

Relevant data restrictions (e.g. specific products)

Reports should be segregated by the key reporting types of:

bullet

Reconciliations

bullet

Validation

bullet

Quality

Reconciliations Reports

This can be treated as a specific report type, and will thus share its characteristics. In addition it must clearly show

bullet

Source

bullet

data category

bullet

how to reconcile

Validation Reports

This is a specific report type. It must clearly show:

bullet

What is being validated, and should be cross-referenced by any business rules or exceptions referenced elsewhere in the document.

Quality Reports

This is a specific report type, in addition to above it must clearly show:

bullet

SLA (Quality measure and metric) it is tracking, and how this measure is to be interpreted.

Notification

Notifications can be considered a special type of report, so in addition to the generic report attributes the following needs to be described:

bullet

The mechanism of notification,

bullet

The recipient.

Data (general)

This a generic term to cover any requirements to describe business information, tables, attributes.

bullet

Tables and key attributes

bullet

Where more than one table is described then relationships to be shown, either in

An entity relationship model (3rd normal form) where the data is relating to de-normalised data in tables, or…

A star schema (fact tables and dimensions) where the data is relating to information held in data marts or warehouses

·         The SLA here will be primarily interested in defining integrity, availability requirements

Mapping tables

This is a specific category of data, in addition to above it must show:

bullet

System

bullet

Mapping tables

bullet

Attributes derived in platform

bullet

Key values

Queries

This is a specific category of data. The specific SQL should not be shown, but it must cover enough information regarding what it is a function of:

bullet

Parameters

bullet

Source of information

bullet

Output

Exception Resolution Business rules

It there are standard instruction to follow to resolve exceptions these should be described here. The following should be described:

bullet

Condition

bullet

Response

Exception specification

The ability to identify and manage exceptions are a key part of any business process. Whilst the scenarios do reference and distinguish the exceptions in summary, further detail is required to allow parties to effectively manage them:

bullet

Reason exception occurs: What triggers the exception

bullet

Prime responsible party: Who is responsible for managing the exception to completion? Note this person is not necessarily involved in “fixing” the exception directly and may require the assistance of other parties. It is vital that each exception has one designated coordination role.

bullet

Supporting parties: Who is required to assist the above in expediting the exception.

bullet

Possible corrective actions: How are the ways in which the exception can be resolved? This should reference the exception resolution business rules.

bullet

SLA: How quickly does the exception need to be resolved?

bullet

Impact if not corrected: What happens if the exception is not resolved in the SLA timeframe.

bullet

Escalation path: If exception is not resolved who does the exception need to be passed to and what further action needs to be taken.

Control specification

Internal controls identified in the process and owner document, together with those identified by the scenarios must be described in this section

bullet

A link between the control objective and the local control

bullet

A description of the local control which clearly describes how the local control prevents the associated key risk from occurring or detecting it if it does (i.e. achieving the control objective)

bullet

A description of how the local control is to be applied, who is responsible for performing the control, how frequently the control is performed, and where it is evidenced

For an internal control to be properly designed, it needs to have an appropriate answer to each of the following qualitative questions:

bullet

Control Type: What is the control being performed?

bullet

Control Objective: Which control objective/risk category is being satisfied?

bullet

Control Owner: Who performs the control?

bullet

Control Frequency: When is the control performed?

bullet

Control Evidence: Where is the control evidenced?

bullet

Control Procedures: How is the control performed? Note these procedures don’t need to be restated if covered in enough detail in the scenarios. A cross reference to the scenario steps is adequate here.

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