Eric Lopes Cardozo avatar

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.

Shop Floor Agility Resistance

Agile software development can be an answer to over-prescriptive, over-documented and command & control style development. Agility is by no means anti-methodology, anti-documentation or anti-control. The idea is to restore balance and put people first.

In my experience most people think that, foremost, customers and management have to be convinced that adopting agile practices will lead to better, faster, cheaper and/or happier software development. And they also assume that transitioning to agile practices on the shop floor is a piece of cake. It is about more freedom, craftsmanship and collaboration, so who will object to that?

Well, in reality there are lots of reasons why analysts, developers, testers and people in roles alike object against agile. For example, there are people that object against teamwork because it threatens their knowledge based status.  Or what about team members that consistently refuse to update their tasks preventing them from having an up-to-date sprint burn chart. Another example is team members that just cannot focus on one of two user stories, always do work outside the scope of the sprint and never finish their tasks. Normal project or people management you say? What about team members that tell you that they do not have the required discipline nor are willing to try. Or what about staff who get violent when they are asked to move to another office space in order to create a co-located environment? Read More

MoSCoW Anxiety

According to Wikipedia MoSCoW is a prioritization technique and a core aspect of agile software development. Its purpose is to focus a team on the most important requirements, for example to meet a deadline.

I know of many project teams that struggle using this technique because their stakeholders are unwilling to do the prioritization or accept the technique itself. If you have participated on a project where all requirements were classified as must have, I am sure you know what I mean.

What can you do when this happens to you? Well, valid options that might come to mind are run and hide and performing a coup for a decent Product Owner. However, before you go to extremes you might want to try another option first.

Basically what we have here is a kind of anxiety, MoSCoW anxiety if you will.  Anxiety? Yes!  In my experience many stakeholders simply become afraid they will not get what they have asked for when they are asked to classify requirements below the must have level. This makes perfect sense when you reckon that many projects deliver only a (small) part of the promised functionality and a lot of stakeholders have felt let down by IT at least a number of times. Read More

More accurate requirements: Who framed Roger Rabbit?

Last June at Innovate 2010 in Florida Kurt Bittner envisioned the new role and responsibilities of the next generation business analyst. If you were not able to attend, his presentation is available online so you can check it out: Transforming the role of the Business Analyst. The need for a different role and responsibilities is to provide solutions for ongoing problems a lot of companies are faced with. These are common problems like:

  • Users expecting  functionality they did not initially ask for
  • Users demanding functionality they will never use
  • Contradictory of conflicting requirements

In order to be more successful, a number of changes are to be made and lessons are to be learned. One of them is that business analysts need to be more focused on desired outcomes rather than features. And another is that business analysts need to probe into root causes rather than being satisfied with just identifying the wants. Being focused on outcomes and unraveling root causes can be hard work and sometimes it is easy to mix them up or to get stuck. A smarter way it is to be more aware of the language that is used for questioning and context frames . Read More

Dutch post: Meer heldere requirements: Kies de juiste verpakking

Mijn collega Kurt Bittner heeft afgelopen juni  tijdens IBM Innovate 2010 (Florida) zijn visie gegeven op de nieuwe rol en verantwoordelijkheden van de nieuwe generatie informatieanalisten. Wanneer je geen kans hebt gezien om zijn presentatie bij te wonen, bekijk die dan via Slideshare: Transforming the role of the Business Analyst. Hieronder volgende enkele observaties of veel voorkomende problemen die hebben geleid tot zijn visie:

  • Gebruikers verwachten andere  functionaliteit dan waar ze oorspronkelijk om hebben gevraagd.
  • Gebruikers eisen functionaliteit die ze nooit zullen gebruiken
  • Gebruikers geven tegenstrijdige of conflicterende requirements Read More

Dutch post: Meer heldere requirements: vermomde processen

De laatste paar dagen hebben verschillende mensen mij dezelfde vraag gesteld: “Hoe kunnen we meer heldere requirements krijgen”. Hoewel ik het eens ben dat het niet netjes is om een vraag met een vraag te beantwoorden, is het in mijn visie beter om in dit geval soepel om te gaan met die etiquette. En wel  omdat deze vraag eigenlijk niet zo eenvoudig te beantwoorden is. Bijvoorbeeld, waarom is dit nodig en welk probleem lost het op? Of, wat bedoel je precies met helder? En heb je heldere requirements en wil je er meer? En in dat geval, meer dan wat? Of heb je requirements die niet helder zijn en die je beter wilt kunnen communiceren. En zo ja, hoeveel beter?

Je zou kunnen zeggen dat dit gewoon spelen met woorden is. En dat klopt! Maar is het formuleren en communiceren van requirements niet feitelijk hetzelfde? Voor meer heldere requirements zijn een tal van zaken benodigd. Er is echter een belangrijk element dat vaak over het hoofd wordt gezien, namelijk inzicht in de structuur van taal en de wijze waarop taal wordt geïnterpreteerd. Read More

More accurate requirements: when process is lost

More accurate requirements: when process is lostOver the last few days a number of people have asked me the same question: “How can we get more accurate requirements?” While I agree it is not nice to answer a question with a question, in this case you might bend etiquette a bit because in reality this question can be hard to answer. For example, why is it necessary and which problem does it solve? Or, what exactly do you mean with accurate?  And do you have accurate requirements and you want more of those? And in that case, more than what? Or do you have inaccurate requirements which you want to become more accurate? And if so, how much more?

You might say: “Hey, that’s just playing with words”. Well, that’s right and so is writing and communicating requirements. In order to get accurate requirements you need a number of things. However, an often overlooked element to writing accurate requirements is understanding the structure of language and how language is perceived. Read More

De wereld van Practices – Wat is een Practice?

De wereld van Practices   Wat is een Practice?Bij IJI staan we een practice-gedreven aanpak voor. Zoals met veel concepten en principes geldt ook hier dat een goed begrip van wat ermee wordt bedoeld essentieel is om er echt de vruchten van te plukken. Een manier om daar invulling aan te geven is om te kijken naar criteria waaraan je een goede practice kunt herkennen. Maar voor we dat doen, is het goed om eerst te kijken naar de definitie en kenmerken van een practice en een practice-gedreven aanpak.

Onder een practice-gedreven aanpak verstaan we onder meer “het samenstellen van een effectieve manier van werken op basis van relevante procescomponenten”. In plaats van moeizaam te proberen een procesraamwerk toe te snijden op een specifiek project draaien we het om; we selecteren alleen relevante procescomponenten en assembleren die tot een consistent proces. En zo’n procescomponent noemen we dan een practice. Use Cases, User Stories en Iteratief ontwikkelen zijn enkele voorbeelden van practices. Andere voorbeelden zijn Operationaliseren Systeem en Datamigratie. In deze context is het ultieme doel van een practice-gedreven aanpak “betere resultaten boeken met softwareontwikkeling”. Hierbij kun je dan denken aan betere software, goedkoper, sneller en een prettigere manier van werken. Read More