Use Cases

Use Case 2.0 – Slices and Relationships: Extension

Since the introduction of Use-Case 2.0 we have received a number of questions about use-case slices and in particular how they relate to the concepts on include, extend and generalization. In this blog we will look at the impact of the extend relationship on use-case slicing.

What’s the Problem?

An extend relationship can be used to factor out optional behaviour from a use-case narrative. It is particularly useful in the following situations:

  1. Where the optional behaviour will be part of a separately purchased extension
  2. Where different customers require different variations of the same behaviour
  3. Where already implemented use cases need to be extended
  4. Where additions need to be made to previously frozen or signed off use cases

Consider a hotel management system with which customers can make online room reservations. As shown in figure 1, the primary use cases would be “Reserve Room”, “Check In Customer” and “Check Out Customer”.

Use Case 2.0 – Slices and Relationships: Extension

Figure 1 – Hotel Management System Use Cases

Now let’s consider what happens if the hotel management system being built is to be a modular commercial product with an optional waiting list feature. This feature allows a customer to be put on a waiting list in the case where the room they like is already booked. The customer will then be informed when the room becomes available or can have the room reserved automatically within a given timeframe. This feature could easily be captured within use case “Reserve Room” but since it is an optional feature, it is factored out into an extension use case.

Use Case 2.0 – Slices and Relationships: Extension

Figure 2 – The re-factored Reserve Room Use Case

Now, to provide a little more context, let’s first have a look at the use-case narrative of the original Reserve Room use-case.

Use Case 2.0 – Slices and Relationships: Extension

Figure 3 – Reserve Room use-case narrative

Without the extending use case we would have had only one use case to slice up - Reserve Room.  Consider the following example Reserve Room use-case slices.

Use Case 2.0 – Slices and Relationships: Extension

Figure 4 - Use-case slices for the Reserve Room use case

The question now is what will happen to these slices when we make use of extension:

  • Does an extending use case have its own use-case slices?
  • Does using extend change the number of use-case slices?
  • Does using extend have an impact on any existing use-case slices?

Does an extending use case have its own use-case slices?
The answer is yes. Using extend means that we move behaviour from one use case to another; we start by literally cutting and pasting text between the two use-case narratives. More specifically we take out one or more alternative flows and place them in a use case of their own. In this case the Alternative Flows AF16, 17, 18 and 19, which are all about the waiting list, would be moved to the new Handle Waiting List use case.

We could have left all the behaviour related to handling a waiting list in the Reserve Room use case. By using extend we have made optional behaviour explicit. In the case of extension the extending use case is performed in the context of the original use case but without the original use case’s knowledge. This means that any use-case slice that requires behaviour of the extension use case must belong to the extension use case. So, extension use cases do have their own use-case slices

Does extension change the number of use-case slices?
Before refactoring we had one use case with its set of use-case slices. The question is what will happen to this set when we factor out the optional behaviour using the extension. Most likely the total number of use-case slices will remain the same because any alternative flow significant enough to get moved to an extension use-case would probably have got its own slice or slices.

Does extension have an impact on the use-case slices?
Yes and no. Yes, because in the use-case slices we must refer to the right flows of the right use cases;   the original use case or the extension use case. No, because the stories and test conditions remain the same independent of the use case they belong to.

Some Examples

Let’s first have a look at the refined narrative of the Reserve Room use case and the narrative of the Handle Waiting List use case

Use Case 2.0 – Slices and Relationships: Extension

Figure 5 – Updated use-case narrative

And below you will find use-case slices from the extending Handle Waiting List use case

Use Case 2.0 – Slices and Relationships: Extension

Figure 6 - Use-case slices of the Handle Waiting List use case

Notice that in the example use-case slice above:

  1. The basic flow of the Reserve Room is always required because the Handle Waiting List (extension) use case cannot be performed without it.
  2. Alternative Flow 16 of the original Reserve Room use case has become the basic flow of the  Handle Waiting List (extension) use case.
  3. Alternative Flow 17, 18 and 19 of the original Reserve Room use case have become Alternative Flow 1, 2 and 3 respectively of the Handle Waiting List (extension) use case.

Final words

So, as you can see use-case slices are as effective for use cases and use-case models that use the extension mechanism as those that don’t.  In the next blog in this series we will examine the effect of the generalize relationship on the slicing of the use cases.

This post was co-authored with Ian Spence.

Useful links:

Use Case 2.0 Training Classes

Use Case 2.0 – Slices and Relationships: Inclusion

Since the introduction of Use-Case 2.0 we have received a number of questions about use-case slices and in particular how they relate to the concepts of include, extend and generalization.

In this blog we will look at the impact of the include relationship on use-case slicing.

What’s the Problem?

An include relationship is used when two or more use cases share common behaviour. This is then factored out into a separate use case.

Consider the case where we have two separate use cases Register Birth and Register Change of Address. Even though both use cases are concerned with registration these are separate use cases because  the flow of events and the business rules are quite different. They share however common behaviour. Both include a description of all the ways a case worker can find a citizen when registering births and address changes. As shown in Figure 1, the common behaviour can be re-factored  into a single Find Citizen Use Case that is included in both of the original use cases.

Use Case 2.0   Slices and Relationships: Inclusion

Figure 1 – The re-factored use-cases

Before the re-factoring it was very easy to slice up the original two use cases. The question now is what will happen to the use-case slices when we make use of inclusion:

  • Does an inclusion use case have its own use-case slices?
  • Does inclusion change the number of use-case slices?
  • Does inclusion have an impact on any existing use-case slices?

Does an inclusion use case have its own use-case slices?
Inclusion means that we move behaviour from one use case to another; we literally cut and paste text between the two use-case narratives. However, this does not mean that we move compete stories or use-case slices. This is because an inclusion use case is never performed on its own. In the above example the Register Birth or the Register Change of Address use cases are in control of when the Find Citizen use case is performed. Because an included use case is never performed independently of its including use case it does not have its own slices. This means that all the slices remain in the original use-cases, and that the included use-case does not have use-case slices of its own.

Does inclusion change the number of use-case slices?
Before refactoring we had two use cases and each use case has its own set of use-case slices. So what will happen when we factor out the common behaviour using the inclusion mechanism? Because an included use-case does not have use-case slices of its own, the total number of use-case slices remains the same. Each of the original use-cases keeps its original number of use-case slices.

Does inclusion have an impact on the use-case slices?
The use-case slices of the original use-cases are indeed impacted. Before refactoring the original use-case slices referred to flows contained within one use case. After refactoring the use-case slices of the base use-case refer to flows in two use cases: 1) the original use-case and 2) the included use-case.

Note: if new flows are added to the included use cases then new slices will be needed in all of the original use cases.

Some Examples

Use Case 2.0   Slices and Relationships: Inclusion

Figure 2 – Example Basic Flow use-case slices

Before inclusion all required behaviour for slice #1 of the use case Register Birth and slice #1 of the use case Register Moving House was contained in their respective basic flows.  After inclusion these slices reference the basic flow of their original use case and the basic flow of the Find Citizen use case. This is indicated in the slice by stating the name of the use case in front of the flow, in this case Find Citizen.BF.

Use Case 2.0   Slices and Relationships: Inclusion

Figure 3 – Example Alternative Flow use-case slices

Before inclusion all required behaviour for slice #2 of use case Register Birth and slice 2# of use case Register Change of Address was contained in their respective basic and alternative flows. The goal of the alternative flows is to handle finding citizens that are residents of different municipalities. After inclusion these slices required require the basic flow of their original use case, the basic flow of the Find Citizen use case and alternative flow 1 of the Find Citizen use case.

If it doesn’t affect the number of slices why both with includes?
The benefits of re-factoring a use-case model to use includes are not changed by the use of use-case slices. They can still make the model easier to understand and maintain, and provide clues to the developers that the included behaviour will be re-used in different circumstances.

Final words
So as you can see use-case slices are as effective for use cases and use-case models that use the inclusion mechanism as those that don’t.  In the next blog in this series we will examine the effect of the extends relationship on the slicing of the use cases.

This post was co-authored with Ian Spence.

Holiday Greetings from Ivar Jacobson by Ivar Jacobson

Season's Greetings

Year after year I feel fortunate that we as a company can report so many new technology advances – advances which help our customers build better software, faster and with happier users and clients.  A number of new practices have been developed to help our customers scale agile beyond small teams to whole organizations.  Our practices for scaling agile and for setting up coaching communities have, with our experienced mentors, helped many organizations to not just become successful with small projects but changed organizations in their entirety.  Several case studies confirm these successes.

Most important in 2011 is our release of Use-Case 2.0.  After having refined the way we work with agile use cases over many years, we have now put together all our experience in an ebook.  Our customers have already used this around the world, China, UK, Sweden, US; but now we have streamlined it close to perfection.  Use-Case 2.0 supports backlog-driven development with Scrum or Kanban making it as lean as it can be.  Many of our colleagues and friends are awaiting this new release ready to start using it.

Lean development has been a long term goal for our company.  Our approach, starting lean with a kernel of the most essential elements in software engineering and staying lean as more detailed practices are added on top of the kernel, is getting wide acceptance in the world.  During 2012, we will see standards being adopted, the academic world embracing it, new tools being available, the industry getting some governance of their ways of working, and developers systematically growing their competence in software development.  Most importantly, success stories will speak for themselves: agile and lean will be achievable targets for every organization developing software.

Welcome to the future, but don't forget to enjoy the holidays.
--Ivar Jacobson

An Evening for Sharing Ideas with Friends

On the evening of November 14th, Ivar Jacobson International hosted an evening of camaraderie for our friends: staff, former colleagues, customers and partners at our office in Kista, Sweden.

It was an evening to share our experiences and update our guests on IJI’s recent activities and developments.

Ivar Jacobson, Svante Lidman, Graham Marsh and I presented IJI at the event and presented topics ranging from Scaling Agile to our new Use-Case 2.0 that our customers are currently using.

Svante Lidman presented an engaging and interesting presentation called “Learning’s from Large Scale Agile Transformation”. Svante discussed how a large client with thousands of developers and a large legacy system who was following a waterfall approach to software development is now making a successful transformation to becoming more agile.

Ivar updated attendees on Use-Case 2.0 (read Ivar’s previous posts for more info on this topic) and also presented Semat and Liberating the Essence from the Burden of the Whole: A Renaissance in Lean Thinking.

If you would like to be on our mailing list to be invited to one of our future events, drop me an .

Use-cases – why successful and popular? by Ivar Jacobson

I am pleased, honored and gratified that use cases are still a popular way of working with requirements.  Googling “use case” yields 6 times more hits than Googling “user story”, but software development should not be driven by popularity.  Instead we should use the most practical way of working.  And, of course we have learnt something from other techniques.  For instance, as I will discuss in my next blog, user stories and aspect-orientation have inspired us to make use cases even better while maintaining their core values.

The popularity of use cases has led to some misunderstandings and some distortions of the original technique.  This is natural, and while it is encouraging to see authors take the original concept and adapt it to solve new problems, some of the misconceptions and distortions have clouded the original vision.

Common misunderstandings

Before further discussing the improved use cases, let’s first discuss common misunderstandings about what we have had since their inception (1986-1992).  Many people believe that:

1) Use cases are for requirements only, which is not true. In fact, from the very beginning, they have also been used to analyze behavior, design software, and drive test identification, just to name a few uses.

2) Use cases are heavyweight; that you need to write fat specifications of each use case, which is also not true.  In fact, use cases can be exceptionally lightweight (a brief description only), to lightweight (just an outline of the flows), to comprehensive (full descriptions of all behavior), and every variation in between.  For most systems an outline can be very valuable and yet still be very lightweight.  Today, we express this in a better way: when describing use cases, focus on the essentials, what can serve as placeholders for conversations.

3) Use cases are a technique for decomposing the behavior of a system, which is also not true.  Some authors have introduced levels of decomposition, and others try to show use cases “calling” other use cases as if they were subroutines.  Neither of these is right.  A use case shows how a system delivers something of value to a stakeholder. Use cases that need to be “composed” in order to provide value are not real use cases.

4) Use cases are complicated.  In fact, using use cases, if done right, makes a system easier to understand.

o It is impossible to understand what a system does from looking at many hundreds of user stories; the equivalent use-case model might express the system’s behavior in a few handfuls of use cases. 

o A user is represented by a stick figure and a use case is represented by an oval.  Their interconnection by a simple line.

o The relationship between a use case and its scenarios are likewise very easy to represent. 

o To solve this problem with user stories, people have started to invent concepts such as themes and epics, making a case that the user story by itself is an incomplete concept. 

o The use-case approach can accommodate a wide range of levels of detail without introducing new and potentially confusing concepts.

5. Use cases are only seen as being good for green field development, which of course is not true.  They are great to explain large legacy systems as with such systems there is often little or no documentation left.  Use case modeling is a technique that is cheap and easy to get started with to capture the usages of the system.

What people like about use cases

The reason use cases have become so widely accepted is that since their introduction they are useful in so many ways in software development. 

1) A use-case model (a picture) already mentioned, which thus allows you to describe even a complex system in an easy to understand way, and which tells in simple terms what the system is going to do for its users. 

2) Use cases give value to a particular user, not to an unidentifiable user community.

3) Use cases are test cases, so when you have specified your use cases, you have also after complementing with test data, specified your test scenarios,

4) Use cases are the starting point to design effective user experiences, for instance for a web site.

5) Use cases ‘drive’ the development through design and code.  Each use case is a number of scenarios; each scenario is implemented and tested separately.

Moving forward
As we refine and improve use cases we are careful to make sure that we don't impact any of these things that are key to their popularity and success.  In my next blog I will describe how we adapted use cases to backlog driven development and managing cross-cutting concerns.

-- Ivar

What Drives Me by Ivar Jacobson

What Drives Me

“The best way to predict the future is to invent it!“ (Alan Kay)

A few days ago, a very simple but thought provoking question was raised to me: “what it is that drives me?” The simple truth is that I do not know. But I do know what it is that does not drive me. It is not about money. Actually, never has it been about money. Neither is it about power. I am happy to step aside and I am happy to delegate both up and down. It is not about popularity – but I do like to be appreciated for what I do.

No, it has to do with helping others improve themselves over and over again. I get a kick out of seeing others become successful because I helped them. It was like that in the late 1960s and the ‘70s when the Ericsson AXE system beat all competition and won every contract thanks to being component-based. Similarly, when Rational was successful because of UML and Objectory. And Telelogic because of SDL. I am happy when people are successful thanks to use cases.

Read More