Chapter 2

Business Process
Modelling

Following on from business concept models, we still need to hang

around the world of business before we go into the software side of
things. For those students who are asking, ‘why are we doing this?’
I thought I should write a few lines of explanation. The goal of many
systems is to help improve a business function or purpose. We looked
at how businesses function in terms of structure in the previous chapter
but to recap here. That function could be how a department operates by
introducing some new software tool to use in, for instance, increasing
efficiency in filing, retrieving and editing customer orders. A structural
diagram works well but it doesn't give us enough detail to say what hap-
pens first, second, third and so on. So, it's a good idea to draw a picture
of how that process is currently working, then change the picture to
make it look like how you would want it to work with the new software
tool. That new picture is called a ‘to-be’ process model – if you produce
a process model. You could use a rich picture from Peter Checkland's
Soft Systems Methodology,1 which is ‘old’ but still valid. You could draw
a flow chart. Or a workflow model. A workflow is a bit of a process
model explained in a lot more detail. I like rich pictures but those of
us who do are receding in number as we get older and more tech-
facing modelling tools emerge. BPMN, the Business Process Modelling
Notation,2 is current, popular and suited to the task. I like to use tools
that are suited to the task. My advice is to look at the tools you have

DOI: 10.1201/9781003168119-2 19
20 ◾ Business Analysis, Requirements, and Project Management

good working knowledge of and think of them as tools residing in your

toolbox. When you need to fix or make something around the house,
you look for the appropriate tool; a hammer is good for bashing and
even breaking stuff, but not the best for sawing a block of wood in two.
When there is an opportunity to describe how a current process
in a business works, or how a new version might work, in relation to
software – and sometimes not – then select BPMN out of your toolbox.
You could pick Role Activity Diagrams (RADs),3 which are excellent but
not as popular as they used to be, or UML's Activity Diagrams,4 which
might be popular but not so easy to understand or draw. These choices
are fine but your audience may not get it so readily with UML or your
developers may not know of RADs. Something in between easy to fol-
low and well known is the Business Process Modelling Notation (BPMN
from now on).
BPMN was designed with systems in mind, in fact with automation
in mind. Hence, you can get into BPEL, which is an executable language
for processes used especially for service-oriented architecture. But we
won't go there and we won't be discussed BPEL at all in this book. There
is a slight kickback though in that the focus on executable processes has
led to an explosion in diagram elements. There are a great many BPMN
modelling elements to choose from. This is beneficial in that almost
every conceivable scenario can be modelled. But the drawback is that
it's more likely that you only need a small sub-set of the notation and
picking the right elements from a long list can lead to mistakes. If you
want evidence of how many elements there are, just look at the three
BPMN stencils (at time of writing) in the excellent diagrams.net, the free
drawing tool I used to draw the BPMN models in this chapter. There are
over 175 different modelling elements available! This, in my view, is a
little excessive for business process modelling but in terms of modelling
how code might work (BPEL) then I think it makes sense. However, for
our purposes, we don't need such an extensive knowledge. All we need
is to understand a subset of the BPMN notation.

BPMN: A Very Useful Subset for Whilst at University

This section presents the most important modelling elements you will
need to know about whilst studying. You may wish to learn more about
BPMN and expand your horizons beyond what is presented here. Also,
depending on where you end up in practice, as a business process ana-
lyst or programmer, you will need to add to your repertoire. But there
are too many elements to cover in this introduction and the differences
between them will be confusing at first. So, for now, let's look at what
 Business Process Modelling ◾ 21

I consider a very useful subset of BPMN diagram elements. After this,

I will present a BPMN model for our case study.

Activities and Pools/Swimlanes – What Happens Where

Activities show what happens in a process. I tend to think of what
before who so I suggest you start what actions occur in a process. You
can then add context such as companies, departments, individuals, sys-
tems described in pools and swimlanes. Activities are what happens in
a process but there needs to an indication of where the process starts
and finishes. These start/stop actions are drawn as circles. Between
circles are the activities, drawn as rounded rectangles. Figure 2.1 gives
an example.
The start circle is on the left and the process is drawn left to right.
There are two activities: Select products to order, followed by Submit
order with payment details, and then the Stop circle, which is a thicker
line than the start. All of this is wrapped up inside a pool box called
Customer. The pool is the role or party responsible for the actions in the
process. Figure 2.1 presents a pool – a single role that is separate from
others. If there are several roles working in unison, for instance, differ-
ent departments within the same company fulfilling a process, then you
add swimlanes within the pool. Each swimlane represents a role within
the collective pool.
Before we look at how we can communicate among swimlanes
and pools, how a process may operate together to succeed – called
orchestration – there is something about the activities we can add as
extra information. This is called assigning a type to an activity. The first
activity in Figure 2.1 could be done manually by the Customer flipping
through a catalogue or in a store looking at items on a shelf. Or it could
be done electronically via a web browser. These activities, which we
can call tasks, can have a label attached to them to give us a better idea
how that specific task is fulfilled. Figure 2.2 presents the types that are
most common.

Figure 2.1 The customer process.

22 ◾ Business Analysis, Requirements, and Project Management

Type Explanation
Task None-specific action
User At the interface of system
Manual Purely physical action with no computer
Business Rule Action must implement agreed business rule
Service Function provided by a system
Script Run specific code segment
Send Message to external role (out of pool)
Sub-process Abstract-out complexity (and need to describe it
elsewhere)
Loop Repeat this step a stated amount of times
Loop sub-process Repeat this set of steps several amounts of times. Note
that a loop should have a text note attached to explain
what happens here.

Figure 2.2 Task types (as defined in the table).

 Business Process Modelling ◾ 23

To elaborate upon the task types, where there is no symbol in the top
left corner, this simply means we haven't allocated a type because we
either don't know or it doesn't matter. Where there is a person (user) this
implies anyone using a computer to fulfil their task. The hand means an
entirely manual activity, such as taking a package in a warehouse and
placing it ex-factory (outside the warehouse storage area) ready for col-
lection and delivery elsewhere. A business rule is a requirement for a
specific industry or company – we addressed these in Chapter 1. In our
warehouse example, the task has to meet a business rule. For instance,
the placing of the package to ex-factory may trigger a business rule to
order new components to make another five products if there are now
less than ten left in stock.
Figure 2.3 provides contextual examples. The top example shows
a manual process (hand symbol) where the Customer selects products

Figure 2.3 Examples of task types.

24 ◾ Business Analysis, Requirements, and Project Management

to order, for instance at a supermarket. The process continues with the

Customer potentially checking out via a self-service till.
The second pool shows the first process as a user process. The
Customer is likely selecting products online. The second task shows a
cog-wheel indicating a service provided by a website, in this case the
Customer places their order with payment. This process might be driven
by a Customer that orders products via an online supermarket.
The third pool is the same except it contains a loop arrow in the first
task. The loop indicates that the Customer completes this task several
times before moving on to the next task. For example, a Customer could
be selecting different books to purchase. Each one is added to the shop-
ping cart, one by one.
The final pool in Figure 2.3 shows the sub-process ‘cross’. The
use of the sub-process symbol indicates that there are several steps
that need performing in fine-grained detail and because of the loop,
several times. For instance, the Customer in the sub-process might (1)
Search for a book, (2) Read the reviews of the book. (3) Add the book
to the basket. These three steps should be performed as many times
as number of books are required. Loops should have a note attached
to them to give the reader an explanation of how many loops are
needed and whether there is a loop breaker to allow the next task to
proceed.
Once you get to grips with these task types, you will understand that
they are quite valuable in understanding where technology engages in a
process. Not all processes will have tech in them but might want to have
them. You can create a process model that explains the current situation
which might be all or mostly manual and then another will show where
potential changes occur where specific tasks are user-driven at the inter-
face or are software services the new technology will provide. I tend to
avoid the script type because it can be too close to the final software
solution for the analyst to be concerned with it.
I will get to the important send and receive task types next but
before that, I wanted to go over a basic core diagram element in process
modelling: decisions and multi-threads. BPMN has an enormous amount
of options for modelling decisions but for our purposes what matters is
really two types: OR and AND. OR and AND gates are like logic gates.
OR is simply a choice, for example, do ‘a’ or do ‘b’ depending upon the
condition the process is currently in. AND is do both ‘a’ and ‘b’ asynchro-
nously or in parallel. The ‘condition’ decision is known as a gateway in
BPMN-parlance. This is a good term because in a process you will arrive
at a gateway and subject to the type, you will go through the gate onto
one path, the other or both. Figure 2.4 presents examples of both types
of gateway discussed.
 Business Process Modelling ◾ 25

Figure 2.4 Example OR and AND gateways.

The OR gateway is the diamond with a cross in it. You don't need to
include a diagonal cross i.e. the diamond can be blank but you do need
to attach a conditional question to the figure. You can still include it with
the cross. The AND gateway in the lower part of Figure 2.4 is depicted
as a horizontal-vertical cross or ‘plus sign’. It means both pathways are
trodden at a similar time, if not entirely synchronously. We can do both
Add to Basket and Select Quantity, whichever comes first. When an OR
or AND gateway opens, it usually needs to close back to a single thread.
We need to repeat the same gateway symbol and have both threads con-
nect to it. Out of the ‘join’ gateway comes a single thread as we proceed
along our process pathway. Sometimes you don't need to join back – it
depends upon the process chunk being modelled.

Sending Messages
There are some very basic rules about how to communicate among
swimlanes and pools that I have to question the realistic nature of.
Namely, if you are in a pool of several swimlanes, you cannot send a
message from one swimlane to another. So this means you cannot send
an order for parts from a production line to the procurement depart-
ment. Or at least you cannot use the message sending notation that
26 ◾ Business Analysis, Requirements, and Project Management

is the obvious tool of choice. This often confuses students because it

would be the clear choice of notation to indicate something important
is being sent, like an attached parts order document in an email. But
BPMN has a different take on messages and these are: you can only
use the message symbol (task type) when sending a message out of
one pool to another pool. Also, the receiving pool does not have to be
modelled – and often we don't know how a different organisation func-
tions so we cannot model it as it is – so the message arrow just has to
go to the receiving pool edge. Figure 2.5 shows how messages can also
trigger a process.
There are two pools depicted, both of one swimlane: the Customer
and the Book Seller. The Customer selects books to order (a subpro-
cess is indicated by the + sign thus taking more than one step). This is
a looped subprocess also meaning it can be repeated many times. We
don't need to describe it here. The Customer then submits the order –
let's say it is an online form, like you may find on worldofbooks.com.
The ‘send’ message is indicated by the dark envelope task type. A special
message arrow is used: a dotted line with a triangular, white head. The
Book Seller receives the message directly into a double circle start state,
with a clear envelope in it. This start state symbolises that a process is
now triggered by the incoming message. In other words, the process is
dormant until it receives the trigger message containing the book order.
The Book Seller processes the order on its system; there is an AND
gate post this. The AND (diamond with big + sign) indicates that both
threads are activated. It is asynchronous meaning either one can finish
before the other. We separate the steps because they would be managed
by different departments in the Book Seller company. Prepare Shipment
would be a warehouse or stockroom operation and I've labelled it as
manual because overall it involves a member of staff locating the book(s)
on shelves, placing them in an envelope or package and then placing
that package in the postage area to be shipped. Manage Payment would

Figure 2.5 Messaging example in BPMN.

 Business Process Modelling ◾ 27

be a process for the Accounts Department or equivalent, and the steps

there probably would mean updating the Customer account to link to
the payment made, as well as processing the payment itself. I've labelled
this a service task type assuming that overall the majority of this would
be automated. Once both actions are complete the process joins back
to a single thread. A message is then sent to the Customer (the outgo-
ing message is a dark envelope task type) and a message arrow leaves
the action and travels to the edge of the Customer pool. I don't need to
show what the Customer does to receive the message as it is not impor-
tant in modelling the process. All we need to know is that the message
has been sent containing the relevant payment receipt and shipping
information. The clear envelope on the message arrow is optional. You
don't need to place it there. But it's fine to do so as it stands out as a
message, be it email, text, instant chat, posted letter or whatever.
There are a great many variations when it comes to message sending
and receiving. You will read about throwing and catching when it comes
to messages and other aspects of BPMN I haven't covered here. This is
programming-speak. Throw and catch are error-handling terminology in
programming. I won't go into the details as it is something we should
not need to think about at the business end of the project. But since one
of the strengths of BPMN is in how it transitions to an executable lan-
guage (BPEL), it is natural for programmers at this level to label things
in programming-speak. I think it is useful for other aspects of modelling
in BPMN but not really for messages. You send and receive a message,
you throw and catch a ball. Irrespective of this, for you, it's fine to know
this terminology and then to not worry about it again. For those who are
interested in executable business process languages, throw and catch
will really help you understand what's going on.

Data and Databases

In discussing programming, we conveniently move on to one more
aspect of BPMN that is useful for us at the business analysis stage of the
project, and that is how to describe data or documents in a process and
where to include explicit references to databases. Figure 2.6 provides
some examples of how to describe databases. Note that we have two
swimlanes, Shipping and Stores, within a Pool labelled Book Seller.
Let's start with the data object ‘Orders’. All we signify when we include
data objects in a model is that there is a document or a record that we
need to be conscious of. The dotted arrows just indicate what it is that
is passed from one action to another. Mostly, we make an assumption
about what passes between actions but we can make it explicit if we so
wish. Datastores or databases are the barrels in the figure here labelled
28 ◾ Business Analysis, Requirements, and Project Management

Figure 2.6 Data and databases.

‘Inventory’ and ‘Customer Orders’. We can include a database within a

swimlane as in the Stores swimlane because this database ‘resides’ in
Stores and relates specifically to what is in stock. By ‘reside’ I am refer-
ring to ownership. Stores own the inventory so the database belongs to
them. Where the server is physically housed does not matter for us in
this context. Other departments would have direct access too, such as
purchasing. The Shipping example is a little different because shipping
updates the Customer record on the Customer Orders database. It is
very likely that this database belongs elsewhere – it isn't the property
of Shipping as the Inventory database is to Stores. It's more likely that
Customer Orders would reside with a customer-facing department. The
dotted arrow means we are accessing the database to update it.

BPMN EXERCISE 1
Answer the following question in producing the BPMN diagram
for the following scenario. You'll find my version of an answer in
Solutions Appendix 1.
 Business Process Modelling ◾ 29

You are a tourist who has booked a holiday to Beijing. As part of

your journey, you book your stay in Hotel Hightech, the world's lead-
ing high technology hotel. Every room has voice activation to open-
close room doors, curtains, switch on lights and the TV. The problem
for you is that the voice activation only recognises Chinese. So you
have to use the new voice feature on Google Translate that takes
your typed in text, translates it and speaks it in your language of
choice. Model your online booking process, your journey (by plane)
and an experience of using voice activation in Hotel Hightech.

When I was really investigating business process modelling with a more

commercial hat on, over 15 years ago now, with BPMN in its infancy,
there were something like 200 business process standards in usage or
proposed. It was a world of confusion. But in terms of industry, it was a
rapidly growing area of importance for tool developers as increased auto-
mation and data management began to be viewed as business growth
key factors. I was not too keen to move on to BPMN at the time because
for me it appeared to be a modelling language that programmers liked; it
was not designed with business in mind. BPMN was designed as a tool to
aid process automation. As such, I kept to RADs because they were very
business-focussed, they worked, they were easy to use and easy for cli-
ents to read, with a key supplied. Also, I just liked their flexibility. Lots of
work had occurred at the University of Southampton to ‘enact’ the nota-
tion, meaning that it was possible to step through the process decisions
and threads via an automated tool. Though this enaction was useful, it
could not replace the models themselves. Enaction was a necessary step
towards automation. I thought RADs had huge opportunities but, in the
end, BPMN took over. Something was needed to rationalise the business
process modelling, enaction and automation world, and BPMN was it.
BPMN has gone through some significant revisions and I won't bore
you with the details. But I think it has become much more accessible at
a business level than initially it appeared. I have grown to like it. BPMN
does have some really curious aspects such as the hundreds of diagram-
ming elements it contains in the specification – much of this is because
of its automation origins.

Errors and Cancellations

One of the issues that business process modelling has had is capturing
enough realism to go beyond the idealism that everything really works
according to the diagram. To explain, an example:
30 ◾ Business Analysis, Requirements, and Project Management

You are in the middle of booking a holiday with a travel agent

at the agent's office. You get to the point of selecting a hotel –
having booked your flight already – and have gone through the
process of confirming the hotel. At the point of which the agent
has clicked ‘Book’, having already entered your credit card
details, notices another hotel, with a better view and higher
quality for the same price, has a room available. In fact, this
was the hotel the customer had originally wanted to book. But
the agent had made a mistake as the hotel names and location
are near identical. An error has been made on the part of the
agent and he has to undo some of the process. It may even be
necessary to cancel the booking immediately (wait more than
24 hours and a cancellation cost will be imposed) and rebook
the customer's original hotel correctly.

BPMN deals with such an example with its ‘error’ and ‘cancel’ events
notation. I also think this fits with modelling use case extension points
brilliantly but this is not for now. I will get to use cases later. But for
now, let's take a quick look at the way BPMN models these. Figure 2.7
shows my attempt to model the scenario as if it works perfectly:
I haven't included a pool/swimlane in Figure 2.7 because I just
wanted to clarify the core steps: (1) Find holiday; (2) Book flight (air
ticket); (3) Book hotel. Assuming the customer is happy, then this pro-
cess is fine. I've labelled find holiday a user task because I am assum-
ing a travel agent is working at their computer to find the holiday. The
bookings are services provided by the booking systems, so I've used the
two cogs symbol task type.
Let's now look at error handling as BPMN does it. Figure 2.8 presents
the idea of trying to reverse a hotel booking from the perspective of the
agent. You will see that this is a little more complicated than the ideal
process. I kept the ideal process really basic just to give you the idea.
Each activity has a subprocess button so clearly there is much more to
it, which is what we would expect. Anyway, back to the ‘error’ process.
Let's talk our way through it.
First, we will start with the Agent pool. It is the travel agent who
works through the process on his computer. The Agent has the customer

Figure 2.7 Ideal booking process.

 Business Process Modelling ◾ 31

Figure 2.8 Modelling with error symbol. Note Figure 2.8 is a variation of the
figure on page 212 of Kenneth J. Sherry's brilliant book on BPMN, Complete
BPMN Pocket Reference, Admaks Publishing, 2015.

order (for the flight and hotel) and this triggers the subprocess above
it. The subprocess commences with the hotel payment and then we
find an OR gate. The upper choice is ‘Wrong hotel’ – the agent realises
the mistake and then the action is to ‘Undo booking and payment.’ I've
labelled this a user task since it was a human error that caused it. I have
not labelled this with a subprocess ‘+’ but I could have. Now once that
action is done we move to the sideways ‘Z’ signifying the error and its
correction have been addressed. The other choice is ‘Else’ which means
in all other circumstances, we end the subprocess here. The outcome of
the Else and finish of the subprocess (black line circle with dark enve-
lope in it) means we have completed the Booking, which is sent to the
Agent. So, the booking is sent to the Agent in the event that everything
runs fine with the process and the hotel is booked successfully.
In the circumstance that the Wrong hotel has been selected and the
undo has been enacted by the Agent, then we have what is called the
‘Error boundary interrupting’ symbol, the sideways ‘Z’ in the double-
lined circle sitting on the border of the subprocess box. This is called
into play in the event of the wrong hotel selection and the undo, as
32 ◾ Business Analysis, Requirements, and Project Management

I previously said. The result of the error boundary interruption is a

message sent to the agent signifying the booking has been cancelled.
Ironically, though this is labelled an error, it is in fact a success: the
booking has successfully been cancelled. The error symbolism is more
suited to programming than it is to a business process and I think that
the symbol would be well-employed in this circumstance.
As I said, there is another option: cancel. It would also be possible to
model this process with a cancel symbol and this may appear to make
more sense. You replace the ‘Z’ in the error symbols with an ‘X’ to mean
‘cancel’. Now this sort of makes sense to use: the agent wishes to can-
cel the transaction so the cancel symbol works. The process is exactly
the same as in Figure 2.8. Make one change and that is to swap out the
error ‘Z’ symbol for the ‘X’ cancel symbol. The question we need to ask
is, does the cancel ‘X’ wipe out the process at this point and close down
any other threads in the pipeline?
Probably it doesn't. When I speak the words ‘cancel booking’ then I
think the ‘X’ works. Yet, I want to point out the mistake made and that
it may be possible to resolve the mistake. So, in the end, I think the
error ‘Z’ works best. However, it should be noted these symbols had
the ease of programming in mind so error handling, in a programming
sense, would seem the right choice. What I suggest for you is to think
about the process in terms of its operation. Is it more strategic or more
shop floor?
There is one more thing to mention – the clock symbol. This is a timer
and it works as a constraint: the cancellation must complete within 24
hours of the original booking. The text is vital to explain the inclusion
of a timer. There is a business rule for the travel agency industry and
that is, if any booking is cancelled within 24 hours of booking, then no
fines or cancellation fees are imposed. Please don't think this applies to
the real travel agency industry. I am referring to the example only and
I do so just to illustrate the clock event. The two-pronged text box
next to the clock is a BPMN standard for placing text or notes on the
diagram.
As I have said, to include all the notations and variations here would
mean I need to write a whole book but there are books already out
there that do this. All I want to show you is what I feel are the most use-
ful business process elements of BPMN when you are studying for your
computing degree. Before we move on to the next chapter, on prob-
lem frames, we need to explore whether there is any linkage between
business concept models (Chapter 1) and business processes. In other
words, are there things in a business concept model that might help us
in determining what to put into a process model?
 Business Process Modelling ◾ 33

From Concept to Process

Ron Ross makes it very clear in his work on business knowledge blue-
prints that a concept model diagram is not a process model, that you
cannot effectively ‘click’ it and a process will enact. I agree with him that
models should really only be read one way and only mean one thing.
The purpose of the business concept model is to provide a structure for
business understanding. The purpose of a business process model is
to document repeatable actions across a business structure to provide
understanding for how a wider transaction or business operation will
work. Hence, we have the term ‘enact’. My view is the same as Ross but
on the other hand, I would like to know more about how I can get the
business to work according to the business rules and the concept model
diagram. That knowledge could be termed business process knowledge.
So, though I agree that clicking a concept model element should not
deliver you a process, you should still be able to reason about the con-
cept diagram and infer aspects in it that could relate to a process. If we
accept this as useful then there are a number of things to consider:

1. What things do we really need to know about in a process model?

2. Are these things in a concept model diagram?
3. Is a thing in a process model really the same as the thing (semanti-
cally, i.e. in meaning, not just in nomenclature) in the concept
model diagram?

Let's answer these now. I will present answers in Table 2.1 and add any
required explanation as needed.
I won't continue the table because you may see from the rationale
that the business concept model and the business process model really
are different things. The concept model I have which links the busi-
ness process and concept diagram together is really all in my head.
This is as Ron Ross explains with concept models – it's all in your head!
The diagram, business rules and definitions are there to make some
sense of what's in my head, or your head, as you look at these things.
So, when I look at a concept model, I begin to fathom how a process
model might work in parts of it. But explicitly describing what element
matches another is very difficult.

Case Study: Fizzit in BPMN

In Chapter 1, we introduced the major case study in this book (though
we recognised also myriad other examples would be used to give 1.
34 ◾ Business Analysis, Requirements, and Project Management

Table 2.1 Relating BPMN with Business Concept Models (BCM)

BPMN BCM Diagram Potential Rationale
Element Equivalent (see Match?
Chapter 1)
Swimlane/ Entity (noun Yes Most boxes in the concept model
pool phrase) relate to value chain elements such
as the drop-off location, TWOO,
Customer and so on. These are clear
candidates for roles in a business
process (modelled as pools and
swimlanes).
Messages Active Yes? The star–sun symbol that sits on
between noun value an association with a noun thing
pools associated attached (as described in Chapter
between 1) represents an active or live
entities connection where the noun box is
the message that is passed in the
BPMN model, either as an email,
phone call, document, product or
voice.
Action within Association Cautious In a concept model, these verb
one pool or between phrase relationships can suggest
swimlane entities movement of e.g. documents
or products but mostly they
show how one thing is related to
another. With caution because a
business concept model is read
both ways from thing to thing but a
process only flows in one direction
or down one (or several) thread(s).
OR gate Condition on Yes? An OR gate will check the
association condition placed on the gate to
decide which thread to follow.
Business concept models can
provide such conditions but they
don't provide, necessarily, an
alternative option if the condition
is not met. They also don't dictate
what happens next when a
condition is true, which is crucial
for us to know in a process.

(Continued)
 Business Process Modelling ◾ 35

Table 2.1 (Continued) Relating BPMN with Business Concept Models (BCM)

BPMN BCM Diagram Potential Rationale

Element Equivalent (see Match?
Chapter 1)
AND gate — None We can speculate that the
condition on an associate in a
concept model may act like an
AND gate. But for which thread?
What happens next? All we see in
a concept model is a connection
between two noun phrases (let's
call them things because noun
phrase is really awkward). But we
don't know much more than this.
— Generalisation- None No element in BPMN even though
specialisation there are subprocesses (and I
presume we call higher abstraction
processes super processes?).

Further clarity and 2. A different perspective). I am going to now pres-

ent a business process model for Fizzit using BPMN. I won’t model the
whole process here, just a piece. The complete BPMN process model for
Fizzit can be found in Appendix 2. If we look back to Chapter 1, you see
I will work with the business rules around conducting a trade and focus
on the first part of the process, the Customer using the Fizzit site to sell
items (books, CDs, DVDs, games).
We can see two pools in Figure 2.9. One is the Customer (on top)
with the Fizzit website below. Should we include a system here? I don't
see why not. I think in this context it makes sense because the Customer
needs to use the Fizzit website to create an account. You'll notice that
there are effectively three separate processes included in the Customer.
One is manual (denoted by the hand signal) and is for the Customer to
organise items to sell. It's floating on its own because it is not certain
when the Customer needs to do this. For instance, the Customer may
have found the Fizzit site, signed up for an account and then organised
books and so on to sell. But it may also be the case that the Customer
did it the other way around. Because it doesn't matter, we have the action
floating. The longer process within Customer contains two subprocesses.
One is to Add items to trade, which has a repeat loop, meaning we do
this subprocess multiple times until the condition is met (repeat until all
36 ◾ Business Analysis, Requirements, and Project Management

Figure 2.9 Fizzit customer trade process.

Figure 2.10 Add item to trade subprocess.

items submitted i.e. have gone through the process of being added to
trade). Then the second subprocess occurs to Complete trade. This does
not have a repeat loop so the whole subprocess should be run once
through. Note that the subprocess can include a repeat loop step within
it. The subprocess for Add Item to Trade can be seen in Figure 2.10.
 Business Process Modelling ◾ 37

There are three pools in this subprocess: Customer, Fizzit Website

and TWOO. The Customer inputs a barcode or ISBN into the website,
which triggers a message to be sent to TWOO to return a price value.
Note that TWOO does not have any internal process steps defined. This
is because TWOO is a separate business to Fizzit's and how it does its
business is its concern, and out of our scope. Once a price has been
offered, the Customer has to decide what to do with the offer. It can be
rejected and then the process ends. Remember this is a subprocess that
is repeated until all items have gone through it. An alternative outcome
is that the Customer decides not to sell the item – so effectively rejects
the price offered but places the item in a ‘save for later’ area. The idea
is that when the Customer does decide to sell the item, there is no need
to input the barcode again – just retrieve the item from the save for later
space. This is beyond the scope of this subprocess example so we don't
include that description here. The final option is for the Customer to add
the item to the trade. The Fizzit website then adds the item to the pro-
spective trade. The subprocess ends here and will be repeated until no
items are left. Note that if no price is offered – TWOO may not require
the item – then the subprocess ends for this item.
Note the ‘script’ task symbol for Check number of items and value of
trade in Figure 2.11. The script means a function is called in the code
of the system. Normally, you would be expected to provide the code as
well as the model, but given we are interested in the business process,
we'll leave the programming until a later date. It's important to use this

Figure 2.11 Complete trade subprocess.

38 ◾ Business Analysis, Requirements, and Project Management

symbol to flag that some codework has to be done. Beyond that, the busi-
ness subprocess in Figure 2.11 will check that enough items and value
is now reached in order to conduct a trade. If this is not the case, then
the Customer is asked to add more items. We end the process here. If,
however, there are more than ten items and with a value of greater than
£10, then Fizzit (via its website) will ask the Customer whether to trade
or not. The Customer can refuse – there may be more items – in which
case the subprocess ends. Or the Customer may accept and Submit the
trade. Fizzit then logs the trade (using a script) and the process ends.
One thing I haven't done is label anything in the business process
model as ‘website’ or ‘system’. There are reasons why: I want to keep
technology agnostic even though it's pretty obvious the Customer would
need to use the website application to input the barcodes or ISBNs of
their items. I could have used website in the models but then there are
times when the functionality to be expressed might not be a website
but an application. Or it could be an underlying system or backend to
the application. I think the chances of us knowing for certain which
software application or system is going to be used for what action or
activity – remembering we are business analysts and are discovering
how the business would work in accordance with the business concept
model and business rules – is unlikely. I would rather be more generic
and talk about the business of Fizzit rather than the technology it has
yet to build or adapt to new requirements.
Now it is your turn:

BPMN EXERCISE 2
Once you’ve read the Fizzit case examples here, you should begin to
understand how BPMN works and in how it can relate to a business
perspective as in the business concept model. Why don't you try:

Draw a business process modelling notation diagram for

the Fizzit case showing the activities for when the Cus-
tomer takes the items to the drop-off location to when
the items are collected by the Courier.

You can find an answer in the Solutions Appendix 1.

We now move on to problem frames and into the section of the book
that has a requirements analysis focus.
 Business Process Modelling ◾ 39

Notes
1 Peter Checkland (1981), Systems Thinking, Systems Practice, Wiley. Further
works have appeared by Checkland and Jim Scholes, all of which are excel-
lent. I list the original here, still available at time of writing on Amazon. Soft
Systems Methodology is an approach that has stood the test of time.
2 The official and updated specification for BPMN can be found here: http://
www.bpmn.org/
3 Martyn Ould (2005), Business Process Management, British Computer
Society. Ould created Role Activity Diagrams as a way to model processes
from a role-based perspective, arguing correctly from my point of view, that
we need to know who is doing what, not just what is being done. It is a
shame that RADs did not become more popular in practice because they are
the best of all business process modelling approaches I have seen purely
from a business perspective. Ould's material is freely available from his con-
sulting business: http://www.veniceconsulting.co.uk/. There are plenty of
downloads here, including a Visio stencil – which is a bit fiddly to install –
and a full online version of his excellent book.
4 UML Activity Diagrams normally form a chapter in texts on UML (Unified
Modelling Language – a set of modelling tools for describing software, espe-
cially the design of object-oriented systems). Take your pick, there are a lot
of books out there. I still prefer the works by the ‘Three Amgos’: James
Rumbaugh, Ivar Jacobsen and Grady Booch, the original creators of UML.
The official specification for UML can be found here: https://www.uml.org/.