Lean Use Cases: Part 4

In Lean Use Cases: Part 2, I promised I would talk about documenting business rules and data items relevant to a use case. Here I am, fulfilling that promise.

Imagine a holiday company requires a system that allows it to, among other things, take bookings for holidays. I have modelled a […]

Lean Use Cases: Part 3

As a follow-on from Lean Use Cases: Part 2, please click on the link below to see a short tutorial on modelling use cases as activity diagrams. It is best viewed in full-screen mode.

Activity diagram tutorial

View more presentations from Declan Chellar

See Lean Use Cases: Part 4 for documenting business rules […]

Lean Use Cases: Part 2

I am fond of System Use Cases as a tool for documenting functional requirements, but I am not a big fan of use case specifications.

I find the textual specifications result in the kind of weighty documents that everyone hates reviewing and I continue to be amazed that so many analysts […]

Software Use Case or Screen Flow?

Recently I was asked to take a look at some Software Use Case (SUC) specifications. What I found was actually a description of a screen flow crowbarred into a SUC specification template.

There are two questions you might be asking.

What’s wrong with that? How does it come about?

April 22nd, 2010 | Tags: , , | Category: Use Cases | Leave a comment

BUCs, SUCs and TUCs! Oh, my!

I have had discussions with colleagues about use cases (and seen discussions on LinkedIn) where it is clear that some people do not understand that there are different types of use case, so I hope the following definitions help.

Business Use Case A technique for describing (in technology-agnostic terms) a repeatable […]


I have found that people, from business SMEs to software developers, often confuse triggers and pre-conditions.

Whether you are producing a business activity model, a process model (business use case) or a software use case, both concepts are relevant and the distinction is important. It is also important to be able […]

Lean Use Cases: Part 1

Use cases are a good mechanism for modelling functional requirements. However, I have met many skilled developers in the BPM world who disdain them and I think I know why.

Use cases were invented for Object Oriented development using an OO programming language and so have certain characteristics that facilitate that […]

A more humane Analyst

I don’t own a car at the moment, mainly because I don’t need one. Combine my lack of need with a lack of interest in cars as accessories and you have someone who uses public transport a lot. Of course, it’s easy for those who live in or around Madrid because public transport […]

Process Exercise: 6/6

Here is a re-cap of my approach to modelling a To Be process:

Part 1: we modelled the As Is change control process in order to understand the current business model.

Part 2: we reminded ourselves to be sensitive to the fact that the customer owns the process.

Process Exercise: 5/6

In Part 4 we drew both high level and low level versions of the To Be model of our customer’s change control process, based on the information we noted in Part 3.

We are now ready to drive out and document high level system requirements (HLSRs). It is […]