1
Bridging the Gap from Business Analysis to Systems Analysis
We are all striving to identify how our businesses can deliver more value and reduce
costs. But how easy is it to turn those ideas into reality?
Benefits analysis is only one half of Cost-Benefit Analysis and predicting the cost side
of the equation can be notoriously unreliable.
The ability to establish systems development scope reliably and estimate
development costs and timescales realistically is fundamental to delivering business
benefits.
In this talk we will show you how to relate functional system requirements simply and
directly to business needs and prioritise development for incremental realisation of
benefits, using Business Process Models and Use Cases.
Chris Moran is a Principal Consultant with Karona Consulting specialising in software
development process, project team mentoring and training in analysis techniques.
Chris has over 20 years experience in corporate IT, including Prudential Assurance,
Sainsbury’s, Tesco, Deutsche Bank, John Lewis and Waitrose.
Karona have recently completed a major programme to define and roll out a new
software development process across the John Lewis Partnership, centred on UML and
Component Based Development, which will be the subject of a talk by Gill Holehouse.
The techniques described here have been tested and proven on dozens of projects at
John Lewis Partnership.
2
The job of business analysis is essentially to determine the best way to organise and
run a business. Inevitably business administration on even a modest scale nowadays
means computerisation, so we need to be able to map an IT solution onto the
business operation. The two go together hand in glove. And yet, too often, there is a
disjoint in the thinking and in the project process, resulting in:
•Poor scope identification and subsequent “scope creep”
•Poor alignment of systems to business needs
•Cost overruns on system projects
•A tendency to “start again” when the project moves into the Systems team.
Having defined a business problem or requirement, we should be able to validate the
fit of a proposed system, and to be able to size and prioritise the work before we
commence development. To do this we need a map or a “model” of the system. The
System Model needs to be concise and manageable and have a rigorous
correspondence to the implemented system.
In this presentation we will look at why it is useful to have separate Business and
System Models, why we use a different notation to model these different aspects,
and how to make the two work together effectively.
3
Why do we do a Business Process Model?
If the aim of our business analysis is to plan and run our business more effectively, we ought
to establish clearly and unambiguously what our understanding of the business is.
Documenting the business allows us to check our understanding with other people and leave
a record of what we have learnt that will be invaluable to later projects. However, it is
essential that any documentation we produce is concise, easy-to-read and clearly structured.
A diagrammatic approach is generally the most effective way to achieve this.
But another reason for doing business analysis is that it is an essential prerequisite to
systems development.
To commence system development without understanding the business drivers, the business
stakeholders and the business scope would be to invite trouble later.
In a world where there is always pressure to achieve more in less time, with less cost and
fewer people, it is also essential that we can link system functionality clearly and directly to
business benefit – so that we can prioritise effectively.
We need to know that the system is going to deliver the key benefits that the business
sponsor expects and that depends as much on understanding the users and what they are
trying to achieve as it does on understanding the technology.
Before we can design a system, we need to understand the business we are trying to
automate: as it will be when the system goes in – not as it is today. So we need to identify
the “to be” business processes and get buy-in from the business owners.
We often find that the initial statement of project objectives needs to be reviewed again in
the light of the business analysis, to firm up what we are really trying to achieve and resolve
the tensions that often occur within a set of objectives (e.g. increase product availability but
not increase overall stock holdings).
4
This diagram shows a business process for an imaginary company which sells bespoke
fireplace surrounds. The business analyst has drawn up a first cut diagram to explore
how the selling process works.
Key features of this approach to Business Process Modelling are:
•Keep the notation simple so that the business specialists can engage with the model
•View the process end-to-end so that we keep in view what the process is trying to
achieve and we don’t miss important dependencies
•A sequential / chronological representation is natural and easy to follow and it
encourages us to ask what-if questions
•Drive out business issues and project opportunities to realise business benefits
•Annotate the diagram with commentary, issues and queries
•Manage the granularity of the detail otherwise the modelling task becomes too
time-consuming
In our approach, we constrain our level of granularity (with rare exceptions) to the
level of a logical task or Elementary Business Process (“one person, one place, one
time”). This gives us a happy correspondence to the granularity of our Use Case
Model, where one Use Case is one logical task that a user can perform using the
system.
A meaningful understanding of the underlying business processes is the most
important key to defining the scope of a proposed system development.
In a complex project we will typically need to produce both an “as is” and a “to be”
business process model. This highlights business change and the “to be” becomes
the basis for creating the Use Case Model.
5
In order to plan and execute our system development we need to be able to describe
the functional requirements of the system:
•what the system does and the steps that it goes through to achieve it
•the size and scope of a system
•alternative options – which can be set before the business
•how it depends on other systems – which will usually imply the involvement of
other systems teams for integration and link testing.
We also want a way of breaking the system description up, into convenient units of
delivery, which can be used to estimate the development effort and track
development progress.
The testers need this functional specification for creating their test scripts.
We also need a reference point for constructing training materials.
We may also want to use the specification as a statement of the business
requirement against which to evaluate the suitability of existing software (e.g.
packages).
To be effective, the system model must also be concise, easy to read and understand,
easy to navigate, easy to manipulate, easy to relate to the business analysis and a
suitable as a primary specification that the system can be developed from and
validated against.
A Use Case Model meets all these criteria, especially, as we shall see, when
developed alongside complementary views of the system.
6
A Use Case is a logical task that can be performed using the system.
This Use Case diagram shows how we have identified the Use Cases from the
Business Process Model.
The stick men (called “Actors”) represent the user roles associated with the system.
These can usually be worked out simply from the swimlanes on the Business Process
Model.
We look at each EBP in the Business Process Model and decide whether the system
needs to provide a Use Case to support that logical task.
Some EBPs have a Use Case that corresponds directly (e.g. “Browse Products”).
Some EBPs have a Use Case that partially implements a task that also has manual
elements (e.g. “Prepare Order For Customer” becomes “Select Order for
Preparation”).
Some EBP’s are fully manual and /or are not supported within our system (e.g.
“Receive Ordered Goods”).
The set of Use Cases identified in this way is a useful step in identifying the system
scope of the project (but see later slide on other sources of Use Cases).
We are now in a position to:
•Further describe the Use Cases, using a Use Case Description template
•Prioritise the Use Cases
7
Identifying Use Cases from the Business Process Model
EBPs (Elementary Business Processes) suggest Use Cases. An EBP is a task that the
business needs to perform. If an EBP is fully manual, there will be no corresponding
Use Case. If, however, there is some system support required for the EBP, then there
will be a Use Case, in one system or another.
The scope of the Use Case is not always the same as the EBP. For example, we may
have an EBP to “Call Customer” when their Order is ready. But the Use Case may be
“List Orders Ready For Delivery”.
Other times, there may be two or more EBPs that can be satisfied by one Use Case,
e.g. “Update Order” and “Cancel Order” may become one Use Case.
From the Class Model
CRUD stands for Create/Read/Update/Delete. A CRUD Matrix is a matrix which maps
Use Cases to the Types of data.
The CRUD matrix shows us whether there are any Types that have missing Use Cases.
This approach is good for finding infrequent Use Cases, which may not have shown up
in the Business Process Threads (e.g. “Create New Product”).
Other
We also need to consider Use Cases for ensuring system security (login, logout,
administer user rights), operational reporting and auditing and Use Cases which
extract data for downstream feeds, such as MIS (Data Warehouse) or Financial
reporting. Typically we won’t know much about these Use Cases at this stage but it is
wise to create “placeholders” that will prompt us to allow time to revisit these areas
later.
8
We have already seen that the Business Process Model and the Use Case Model serve
different purposes. Here are some more reasons why it is good to differentiate them.
Overloading any model with too much meaning makes it hard to read and hard to
keep up-to-date.
The Business Process Model is a model which helps us to understand how the
business works – it is therefore necessarily a “wide” model, so it is good not to go too
deep.
The Use Case Model specifies the system behaviour. It needs to go into a lot of detail,
so it is good to work in small units. Each Use Case tells the whole story about one
logical task, so it has integrity and consistency within its own boundary.
Different audiences engage with the business model and system model in different
ways and at different times. The separation helps us to deal with this.
The transition of the model also corresponds to a shift in our thinking. We should be
able to provide a reasonably stable definition of the business operation and its needs.
The system requirements are then negotiated around that, taking into account
benefits, priorities, timescales, availability of resources and costs.
Constraining the Business Process Model to the level of granularity of the EBP
prevents us from getting bogged down and losing project momentum. The fine grain
detail can be drawn out in the Use Cases – if and when it is needed. (Finer grained
understanding of the manual business processes is the domain of business procedure
manuals and if these are needed they will normally be the specific responsibility of
another specialist team).
9
Use Cases are not just a convenient way of recording the functional specification of
the system.
Each Use Case represents one logical task that a User can perform using the system*.
This structural constraint means that each Use Case can stand on its own merit as an
atomic unit of system functionality. This is an essential property when it comes to
managing delivery of the project.
The Use Cases are the tradable units for estimating development cost, prioritisation,
and planning increments (both development and deployment).
As we refine the Use Case Model we become more confident about the estimates
and we narrow the confidence range of the estimates.
In addition the structure of the Use Case description makes it easy to understand,
describe and validate all the paths through the functionality. This in turn makes it
easy to identify all the test cases that are required to test the Use Case.
The good thing about a model is that it can be done before development starts
allowing us to take control of the systems project from the outset.
* Setting aside complexities about «includes» and «extends» relationships for the time being.
10
This diagram shows how we can visualise the prioritisation of the Use Cases and group them
into increments – for development and deployment. We can use this picture to facilitate
discussions about priorities and scope.
Developing incrementally has many benefits:
•Demonstrate real progress in terms of working code at regular intervals (thus improving
confidence in the project within and outside the development team)
•Establish patterns of working within the team and optimise them over a number of cycles
•Review various aspects of the development quality early and at regular intervals (look and
feel, user acceptance, productivity, defect rates)
•Where applicable deploy an early release of the system and start realising business benefits
earlier
When we define development increments in terms of Use Cases, each increment delivers
something usable and meaningful (not just a screen).
This gives the project, and the business, high level control over delivery - not just control of
the low level requirements.
Within the increments we can still make choices about the style of development: test driven
development, waterfall, package, etc.
Note that we have also excluded some of the functionality from the scope and we have made
this explicit to avoid any ambiguity or recriminations later.
Notice also that in this example we have stripped out the payment element from the “Check
Order” Use Case. This reflects a refinement of our understanding of the Use Case and
choices about cost and priority.
11
Of course a Use Case Model on its own is not a sufficient specification for a system.
Big Use Case documents (running to tens of pages) are a sure sign that the technique
is not being used effectively.
We use a set of complementary UML diagrams and supporting documents to create a
complete model, which allows us to validate the system specification for the “3 Cs”:
Correct, Complete, Consistent.
Alongside the Use Case descriptions we develop User Interface storyboards and User
Interface specifications, which help the users validate the system design and then
serve as a specification for UI development.
We take a component based approach, so our Class Model is data centric not object
oriented, which makes life simpler. We then divide the Class Model into a set of
discrete, data-centric components.
We use State Charts to understand system behaviour which is dependent on the state
of the business data.
We use UML sequence diagrams to model interactions between components and
define component services.
We use further Class Models to create free-standing component specifications.
We then take these logical specifications and create models of the physical
implementation, applying proven design patterns, to ensure a robust and consistent
implementation of the system.
But our approach is simple and flexible, so you can easily choose the level of rigour
and precision you want to go to in the system specification to suit your development
approach and the skill set of your teams.
12
When creating models it is important to think about what you’re using them for and how you’re organising the
information. This is the simplified view of the model organisation we use at Karona.
The Business Model (Problem Definition) –a description of how the business works. The emphasis is on what
processes the business runs, without considering in detail how the steps are carried out or which systems support
these processes. It is essentially a technology-independent description. It helps us understand the needs of the
business, decide where the benefits will be achieved and highlight any issues that need to be resolved.
During business modelling we are focussing on the business operation and what makes it tick. We are building up
our understanding of the problem, so that we can make intelligent judgements about the nature of the solution.
Re-playing what we have learnt about the business to the domain experts in a diagrammatic form helps to build
confidence that we have understood the problem and builds up trust.
The main element is the Business Process Model but there should also be a Glossary of business terms and usually
a Business Type Model – these are not described in this presentation.
The Solution Model (Solution Specification) –a model of the system: its functionality, its data and how it is put
together. In this presentation we are focussing on the Use Case Model.
Use Case Model – describes the functionality of the system from the users’ point of view. It defines the
functional scope of the system. Each Use Case is a logical task that a user can carry out using the system. Each Use
Case has a detailed description, detailing how the system behaves.
Class Model – There are a number of sub-models here. The primary one is the “System Type Model” which
describes the logical data structures required by the system. This helps us create a consistent description of the
data used by all the Use Cases.
Interaction Model – Again there are a number of sub-models here. The first is the set of “Use Case Realisations”
through which the analyst creates a more detailed description of which Use Cases use which data. This is a
powerful mechanism for validating the Use Case Model and System Type Model.
State Charts – a supporting technique that allows us to look at the lifecycle of a single item of business data, such
as a Product, as it is tracked by the system through its life. Most projects will only generate two or three state
charts.
User Interface Specification (UI Spec) – records user navigation and shows the screen layouts, detailing all the
data elements displayed and the behaviour associated with buttons, hyperlinks, etc. It is developed concurrently
with the Use Case Model, to help the users visualise their system as we build up the system specification.
From these deliverables we can create a physical design for the system and from that, individual program
specifications, the database schema and test scripts at unit and system level.
13
If we intend to develop and deploy an application in increments, we still need to know in advance
what the proposed system is for, its business benefits, its architectural fit, its scope (function and
data), how long it will take to build and how much it will cost. We also need to be able to
determine the business priorities and map out the content of the increments (early ones more
precisely than later ones).
To do this effectively we need first of all to understand the business scope of the problem, then
determine the scope of the system or systems impacted (or proposed). We therefore need to be
able to develop a description, firstly of the business and then of the system, which starts as a
coarse-grained description and becomes increasingly fine-grained. How do we do that? If we use
text-based descriptions it is practically impossible to manage. With a model-based approach,
however, we can do it. Firstly we define business processes, constrained to a minimum
granularity of the “Elementary Business Process” as described earlier. Then we progress to Use
Cases: firstly identifying them and giving them only a name and an “intent”; secondly describing
the basic flow (or “happy day scenario”); and finally describing all the alternative flows. After that,
depending on our method, we can produce an Interaction Model, for example using Sequence
Diagrams, and defining the black box specification of each interaction with the system data.
This approach gives us a very clear and systematic approach to the granularity or precision of the
system description at each stage of the project.
An experienced analyst will use their judgement to focus more closely on areas that present
higher project risk and less on non-contentious aspects of the system.
We find that defining the development increments in terms of the Use Cases to be delivered is
straightforward and easy-to-manage. Each Use Case is a natural unit of useful functionality from
the user’s perspective. It is fine-grained enough to give the project manager control over the
development stage but not so fine-grained that we create a whole industry around prioritising
and re-prioritising the user requirements.
14
The Business Process Model is a great way to understand the scope of the problem
but we’ve found that it doesn’t throw out all the functional requirements. That’s
because:
1) Processes that change the “reference data” (i.e. data, such as User, Branch,
Product, that is not changed by the operational processes under consideration)
often get put to one side or de-prioritised because those processes occur
infrequently and are secondary to the problem under consideration.
2) There are management and supervisory processes that sit above the operational
processes that we tend not to model.
3) The business model is system-independent so it overlooks the issue of system
access and security.
We find that a CRUD (Create/Read/Update/Delete) analysis, mapping Use Cases to
the data, throws out missing functions. For example if we haven’t got a Use Case to
Create or Update Product, then we have to ask where we get Product data from. This
may require a new Use Case or it may point to the need to provide integration with
another, existing system. In this way we find the “upstream” (incoming) integration
requirements.
The CRUD analysis will also highlight the need for housekeeping or archiving
processes.
“Downstream” data feeds are hard to spot from the business end; they tend to be
identified by looking at the system topology / system architecture of the existing
systems.
We then look at requirements for operational reports and system security.
15
Models are a way of documenting clearly and concisely what we know, firstly about
the business and then about the system solution.
The process of producing the models helps us to be systematic in our analysis, driving
out questions that we might otherwise have overlooked.
Models are easy to read (when done well).
Models allow us to communicate what we know unambiguously to all project
stakeholders and thereby to validate our understanding.
Models allow us to trace system functionality back to business benefits.
Models allow us to plan, estimate and control delivery of the system.
Models allow us to validate that the delivered system meets our documented
requirements.
Models are an invaluable form of system documentation to take into the
maintenance phase of the system. Remember 80% of the system cost occurs after it
goes live!
16
There is a lot more information about our development process on our website
www.karonaconsulting.com
17
18