17 Running with Use-Case Lite

In this chapter, we will see why and how Smith’s team started applying use cases in their development.  The Use Case practice is a requirements analysis technique that has been widely used in modern software engineering since its introduction by Ivar Jacobson in 1987 (ref). In fact, Ivar Jacobson introduced a larger practice, Use-Case Driven Development (UCDD) that extends the Use Case practice beyond requirements analysis to driving design, implementation and testing. Since its introduction, the Use Case practice has been widely adopted in basically all industries and inspired the User Story practice we presented in the previous chapter. In fact, the use case idea has become so widespread that the term use case has become a normal English word used to understand the usages of virtually anything. The Use Case practice has evolved since 1987 and in its turn become inspired by the lightness of the User Story practice making it practical to use in all kinds of endeavors and in particular in agile endeavors [20][21]. Similar to what we did with Scrum and User Stories, in this chapter we will describe a simplified version of the Use Case practice, which we refer to as Use-Case Lite.  It is designed for this book only and to be exchangeable with the User Story practice; the better way to do use cases is provided by the UCDD practice.

Smith’s team had already been working with product backlog items as part of their Scrum explicit practice previously described. These product backlog items frequently had relationships between them that were not evident from the simple product backlog list.  For example, some product backlog items provided basic functionality, while other product backlog items provided additional extended functionality. By “basic functionality” we mean high-level requirements that do not include details.  Use cases can help teams understand the bigger picture and how product backlog items are related.

17.1 Use Cases Explained

A use case is all the ways of using a system to achieve a particular goal for a particular user. Use cases [18] help teams understand how user needs and requirements affect the behavior of the system. Often, at the start of a software endeavor, development teams are given a requirements specification which is essentially a narrative that supposedly captures the requirements for the system to be built. As we discussed in a previous chapter, user stories can help flesh out missing requirements by encouraging informal discussion between developers and users. However, often these informal discussions lead to user stories that are fragmented – there are too many of them, it is not clear how these user stories make up something more complete - and they lack structure. This can become a significant problem especially on large complex systems. One approach that has been used to help address this problem is developing larger stories first which are referred to as epics. This is an area where use cases may be more helpful to teams. Use cases give requirements a structure, or a systematic way to organize requirements. This structure makes it easier for teams to conduct analysis, user interface (UI) design, service design, implementation, tests and so on.

In the Unified Modeling Language [19] the relationships between users and use cases are represented in what is referred to as a Use-Case Model – a model of the use cases of a system. Since users are not always human but can also be other systems, we use a more general term than users and speak about actors.

Recall that TravelEssence was a leading travel service provider that targeted both leisure and business travellers. One of their customer facing systems, a travel portal, has the following use case shown in Figure 110.  (The system has other use cases as well, but right now we pay our attention to only this one.)

Figure 110     Use-Case Model example: Make Travel Plans

The stick figure is the UML symbol for an actor and the ellipse is the UML symbol for a use case. Usually there are many actors and many use cases in a use-case model. The model provides a visual representation of the system, which is a very useful way for brainstorming the overall scope of a software system. What we show in Figure 110 is a use-case model with one actor and one use case. In real systems, there are many actors and use cases. Figure 111 shows the actors and use cases for the development endeavor they had just embarked upon with the following requirement items implemented:

  1. Req-item #1: System generates recommendations for a traveller.
  2. Req-item #2: Mobile plug-in to display recommendations.
  3. Req-item #3: Handle user’s selection to view or discard recommendations.
  4. Req-item #4: System tracks recommendation success rate.

Figure 111     Use-Case Model for TravelEssence providing travel recommendations

Use cases are not just about diagrams. Use cases include the actual functionality and behavior of the system.  Each use case is described in a Use-Case Narrative. A use case narrative provides a textual description of the sequence of interactions between the actor and the system. It also describes what the system does as a response to each message from the actor. This response includes internal actions as well as the sending of messages back to the actor or to other actors, which could be other systems. Figure 112 shows an example use-case narrative for the Make Travel Plans use case. The use-case narrative is usually separated into two parts referred to as the basic flow and the alternate flows. The basic flow describes a normal or a “basic” use of the described use case often called the “happy day scenario”.  In our TravelEssence case this would be making a travel plan. The basic flow is worded in a way you would test and verify the behavior of the functionality. It is a sequence of steps you would expect when using or testing the system.

The alternate flows (there may be multiple alternate flows) are variations of the basic flow to deal with more specific cases. These variations can be enhancements, special cases, etc. You have three alternative paths A1-A3 (see Figure 112).  You should have their steps listed, but for brevity, we did not show them in the referenced figure.

Use Case Narrative: Make Travel Plans

Basic Flow:

  1. Traveller provides travel details (travel dates and destination)
  2. System searches and displays hotels for the travel dates and destination.
  3. Traveller selects a hotel and room type.
  4. System computes and display.
  5. System makes a tentative reservation for the traveler on the selected hotel.

Alternate Flows:

A1. Travel plan with multiple destinations

A2. Travel plan having a single destination but non-consecutive dates

A3. Travel plan with non-consecutive dates and multiple destinations

Figure 112     Use-Case Narrative example: Make Travel Plan

The use case narrative for “Provide Travel Recommendations” is depicted in Figure 113. The basic flow enumerates the sequence of interactions between the software system and the user to provide travel recommendations to the user (i.e. the traveller).

Use Case Narrative: Provide Travel Recommendations

Basic Flow:

  1. Traveller verifies travel details (travel dates and destination)
  2. Traveller requests recommendations
  3. System provides list of recommendations
  4. Traveller browse recommendations
  5. Traveller selects and view recommendation.

Alternate Flows:

A1. Recommendations of different entities

  1. Hotel
  2. Place of Interest

A2. Recommendations

  1. Recommendations based on popularity rating
  2. Recommendations based on pricing
  3. Weighting function (preference indicator) for the above parameters

A3. Recommendation request trigger

  1. User initiated
  2. System triggered

A4. Sorting of recommendations

  1. Sorting based on prices

Figure 113     Use Case Narrative:  Provide Travel Recommendations

When trying to understand requirements, or anything, we start by understanding the heart of the matter, before diving into details. Use cases are structured to help with this kind of thinking. This same idea works when you are implementing a system; you start building the skeleton before fleshing out the details. The basic flow acts as the skeleton. If you compare the use case approach to capturing requirements with that of user stories introduced in the previous chapter, it should be clear that the use case approach provides more structure through the separation of basic and alternate flows. This structure also makes the requirements easier to understand, especially on endeavors that are large and complex. 

This is one of the advantages of use cases over user stories. Another advantage is that use cases help you see the big picture through the use-case model. Keep in mind that what we described above on use cases is just a brief introduction to the use case approach. Also, keep in mind that it is not our intention in this book to explain why one practice, like use cases, is better than other practices, like user stories. However, it is of course important to point out factual differences, such as those we have discussed here. All of the practices we present in this book are example practices.  We want the reader to understand how they can be represented in an essentialized form and what value essentialization brings to comparing practices helping you make the best decision given your own situation. If you are interested in learning more about use cases we recommend you to study this approach in more detail (the ebook on use case 2.0).

17.1.1 Use-Case Lite

Use-case Lite can help solve one of the key problems with incremental development that many teams face. That is the fact that the functionality of the entire software system can become fragmented into product backlog items scattered across all the iterations throughout the evolution of the software system. As our TravelEssence case increased in scope this was one of the challenges the team faced with user stories.  As such it is often challenging to understand what the system can do at any point in time, or answer questions about the impact of a new product backlog item on the current software system. Use cases provide an approach for putting all these product backlog-items into context from the user’s point of view. A use case often contains too much functionality to be developed in a single iteration, such as a single sprint when using Scrum. That is why a use case is split up into a number of smaller parts that are referred to as use-case slices.  These use-case slices taken together represent the whole use case and when all the use-case slices are described, the whole use case is described. Each use-case slice should provide some value to its users so they should typically include a sequence of activities and not just represent user interface part or a business rule.

For example, the Make Travel Plans use case has a basic flow and three alternate flows.  So, you might implement the basic flow first as one use-case slice, before implementing the alternate flows as subsequent use-case slices. Recall earlier in chapter 16 on user stories, we discussed an example for splitting user stories. With Use Cases, the way a use-case narrative is expressed (partitioned in basic and alternate flows) facilitates splitting up the use case into smaller use-case slices.  These use-case slices can then be placed into the backlog for development (see [20][21]).

A use-case slice is a slice through a use case that is meaningful to describe, design, implement and test in one go. It doesn’t need to by itself give value to a user, but together with all other slices of the same use case, the value is achieved.  For example, the basic flow of a use case is a good candidate to become an early use-case slice. Additional slices can then be added to complete the whole use case later. The slicing mechanism is very flexible enabling you to create slices as big or small as you need to drive your development. The use-case slices include more than just the requirements. They also slice through all the other aspects of the system (e.g. user experience (user interface), architecture, design, code, test) and its documentation. Thinking about and developing a software system through slices in this way helps you develop the right system. They provide a way to link the requirements to the parts of the system that implement them, the tests used to verify that the requirements have been implemented successfully, and the release and endeavor plans that direct the development work.

The Use-Case Lite practice that we discuss below provides a scalable, agile practice that uses use cases to capture the functionality of a software system and test them to ensure the system fulfills them.  

17.2 Making the Use-Case Lite Practice Explicit Using Essence

We have just introduced the concepts and the purpose of use cases and use-case slices, which are essential parts of our Use-Case Lite practice. We will now look at how to describe this practice using Essence. The first questions we always ask when essentializing a practice are:

  • What are the things you need to work with?
  • What are the activities you do?

Figure 114 expresses the elements of our Use-Case Lite practice using the Essence language.

   

Figure 114     Use-Case Lite practice expressed in the Essence Language

The Use-Case Lite practice decomposes Requirements into Use Cases, which in turn are broken down into Use-Case Slices. Therefore Requirements, Use Cases and Use-Case Slices are all important things we need to work with and progress. They are therefore alphas in our essentialized representation of the Use-Case Lite Practice. The Requirements are described using a Use-Case Model. A Use-Case Model is also something we work with, but it is a different kind of element than the alphas we just discussed.  A Use-Case Model is a tangible description of the Requirements and therefore it is a work product. Each use case within our Use-Case Lite practice has two related work products:  1) Use-Case Narrative, 2) Use-Case Slice Test Case. The latter exists in many instances, but the former is a singleton per use case.

We have described earlier what a use-case narrative looks like. We will give examples later describing what use-case slice test cases look like.

The bottom of Figure 114 shows four activities in our Use-Case Lite practice, namely:

  1. Find Actors and Use Cases to gain an overall understanding of what the system is about.
  2. Slice the Use Cases to break them up into a number of intelligently selected smaller slices that each fit within a single sprint.  Such a slice is a Use-Case Slice.
  3. Prepare a Use-Case Slice by enhancing the narrative and test cases to clearly define what it means to successfully implement the slice.
  4. Test a Use-Case Slice to verify it is done and ready for inclusion in a release.

The three first activities reside in the Understand the Requirements activity space and the fourth resides in the Test the System activity space

Use-case slices are identified by working through the use case to identify paths, scenarios or as we say the stories that build up the use case.  Typically, a story is any path that you may want to follow going through the use case its basic flow or its alternative flows.  Concrete examples of stories in the use case Make Travel Plans are:

  1. the basic flow,
  2. the basic flow complemented with alternative flow 1,
  3. the basic flow complemented with alternative flow 2,
  4. etc.

The story idea is similar to the user story idea in the User Story practice and is very important to find good use-case slices. A use-case slice typically includes one or more stories.

Note that this practice does not provide any patterns. This illustrates that it is up to the author of a practice to dictate the scope of the practice. Normally, the more there is in a practice, the more specific it is. The less it has, the more generic it is, and others can supply more specific information, such as patterns, when necessary.

The elements of the Use-Case Lite practice are summarized in Table 10.

Table 10        Elements of the Use-Case Lite practice

Element

Type

Description

Use Case

Alpha

All the ways of using a system to achieve a particular goal for a particular user.

Use-Case Narrative

Work Product

Tells the story of how the system and its actors work together to achieve a particular goal.

Use-Case Slice

Alpha

One or more stories selected from a use case to form a work item that is of clear value to the customer.

Use Case Model

Work Product

A model that captures and visualizes all of the useful ways to use a system.

Use-Case Slice Test Case

Work Product

Defines inputs and expected results to help evaluate whether a system works correctly.

There can be one or more Test Cases to verify each Use-Case Slice.

Find Actors and Use Cases

Activity

Agree on the goals and value of the system by identifying ways of using and testing it.

Slice the Use-Cases

Activity

Break use case up into a number of intelligently selected smaller parts for development.

Prepare a Use-Case Slice

Activity

Enhance the narrative and test cases to clearly define what it means to successfully implement the slice

Test a Use-Case Slice

Activity

Verify the slice is done and ready for inclusion in a release

This practice is primarily a solution area of concern practice because it focuses on requirements and the software system. Like the User Story Lite practice, it provides no explicit guidance in the endeavor area of concern, and is therefore well complemented by the Scrum Lite practice.

17.3 Use Case Lite Alphas

The Use Case Lite practice involves the following alphas shown in Figure 115, namely Requirements (from the kernel), Use Case and Use-Case Slice. The content on the cards provides the states of each alpha. 

Figure 115     Things to work with (Alphas)

17.3.1 Progressing Use Cases

The Use-Case Lite practice provides an effective way to progress requirements. As mentioned, a use case is all the ways of using a system to achieve a particular goal for a particular user. As such, the use case starts off with a goal, and along with all the ways, or what we call stories, for achieving the goal. Through the use case narrative, the stories are organized with a structure that is understandable by the customer representative, which in this case is Angela, and the development team, which in this case is Smith’s team. A team would then fulfill the simplest story and incrementally fulfill other stories until all stories are fulfilled.

Figure 116     Use Case Alpha state cards

Thus, the Use Case alpha has the following states of progression and health:

  • Goal Established – The scope of a use case is defined by the goal of the use case, what the actor wants to achieve.
  • Story Structure Understood – One of the key benefits of use cases is that it provides a structure. Rather than a heap of requirement-items or user stories, use cases provide a structure.
  • Simplest Story Fulfilled –The simplest or the most basic flow through the use case drives the code skeleton. Once this code skeleton is formed and stabilized, it becomes easy to implement the rest of the stories.
  • Sufficient Stories Fulfilled – Once sufficient stories are fulfilled, the use case can be evaluated if it achieves the use case goal well.
  • All Stories Fulfilled – Finally, the entire use case is completed.

17.3.2 Progressing Use Case Slices

It will take several sprints even releases to fulfill all the stories in a use case. In each sprint, teams fulfill a slice of a use case, which we call a use case slice.

Figure 117     Use-Case Slice Alpha State cards

Working with a use case slice is quite similar to that of a user story. The Use-Case Slice alpha has the following states:

  • Scoped – At this state, the use case slice has been identified and its scope clarified.
  • Prepared – At this state, the information the development team needs to implement the use case slice are available, including priorities relative other slices, estimates of cost to implement, dependencies to other use-case slices, etc.
  • Analyzed – At this state, the development team has a common agreement on how the use-case slice will be implemented. This includes agreeing on things like user interfaces (i.e. how information should be presented on the screen, how the user would interact with the system), persistence (e.g. updating the database), and so on.
  • Implemented – At this state, the use-case slice is implemented. This involves writing actual code.
  • Verified – At this state, product owners like Angela verifies the use-case slice does what it is expected.

17.4 Use Case Lite Work Products

The work products in this practice are depicted below in Figure 118. The content of the cards provides guidance on level of detail for the work product cards (Use-Case Model, Use-Case Narrative, Test Case). The following words in italics are taken from the Use Case 2.0 ebook [20][21]. 

All of the work products are defined with a number of levels of detail. The first level of detail defines the bare essentials, the minimal amount of information that is required for the practice to work. Further levels of detail help the team cope with any special circumstances they might encounter. For example, this allows small, collaborative teams to have very lightweight use-case narratives defined on simple index cards and large distributed teams to have more detailed use-case narratives presented as documents. The teams can then grow the narratives as needed to help with communication, or thoroughly define the important or safety critical requirements. It is up to the team to decide whether or not they need to go beyond the essentials, adding detail in a natural fashion as they encounter problems that the bare essentials cannot cope with.

The lightest level of detail is shown at the top of each work product card. The amount of detail in the work product increases as you go down.  For example, in Figure 118, Value Established is the lightest level of detail for the Use-Case Model, while Structured provides the greatest detail.  For the Use-Case Narrative, Briefly Described is the lightest level of detail, whereas Fully Described is the deepest level. You always start with the lightest level. The team can then decide how much more detail they need based on their own situation. These levels of details will be described in the next section, when we elaborate each work product.

Figure 118     Things to work with (Work Products)

It is to be expected that each use case will evolve over several iterations/sprints by coming back to the activity Slice the Use Cases. More slices may be added to the use case and each use case is improved as we learn more. As such, the alpha states that show progress of a use case could be based on the evolution of the slices.  This is a similar idea as we saw earlier in part 2 where the progress of the Requirement Alpha was based on the progress of Requirements-Items.  This will be more apparent later when we provide a concrete example.

17.4.1 Use-Case Model

A use-case model captures and presents visually all the useful ways to use a system (see Figure 119). We have earlier given an example of a use-case model (see Figure 111).

Figure 119     Use-Case Model work product

A use-case model describes not just one but several use cases and how together they provide value to its users (i.e. actors).  These use cases need to have clearly defined scope. The use-case model has the following levels of detail:

  • Value Established – At this level of detail, the value of the use cases and hence the use-case model is established. Readers of the use-case model have a good understanding of what the use cases are about, what they do and how actors benefit from them.
  • System Boundary Established – At this value of detail, the scope and boundaries of the Requirements are described. The team and stakeholders have a clear understanding of what is within scope and what is out of scope.
  • Structured – At this level of detail, the use-case model is well structured. There is little or no overlap between use cases. The dependencies and relationships between use cases are described clearly.

17.4.2 Use Case Narrative

A use-case narrative describes the story (i.e. sequence of steps) of how the system and the actors work together to achieve a particular goal. The term “story” here is not the “user story” we presented in the previous chapter. Rather, the term “story” is just the normal English word.

Figure 120     Use-Case Narrative work product

A use-case narrative can be described at several levels of detail:

  • Briefly Described – At this level of detail, the use-case narrative only has a brief description of the use-case goal and some words about what it is about.
  • Bulleted Outline – At this level of detail, the story of how the system and actors work together is available. The examples provided in Figure 112 and Figure 113 are at this level of detail.
  • Essential Outline – At this level of detail, the story is full blown. In the context of requirements of the software system, the various alternative usages and exceptions to be handled are clearly described.
  • Fully Described – This is a very detailed description of the use-case. All conversations are clearly spelt out.

17.4.3 Use-Case Slice Test Case

The Use-Case Slice Test Case work product defines the inputs and expected outputs to help evaluate whether a use-case slice is implemented correctly.

Figure 121     Use-Case Slice Test Case

Figure 121 depicts the level of details in a Use-Case Slice Test Case.

  • Scenario Chosen – At this level of detail, the different scenarios required to test the use-case slice are described. This includes the normal way of using the use-case slice and other variations (alternative usages and exception cases). The example, which we will provide later in Table 12 in Section 17.6.2 are at this level of detail.
  • Variables Identified – At this level of detail, the different variables are listed. For example, in the variables for testing the Make Travel Plans (see Figure 112) use case include Traveler identification and destinations.
  • Variables Set – At this level of detail, the actual variables are defined. For example, the Traveler might be Sam, whose identification is 12345678. The destination is Singapore. The popularity rating of the Singapore Zoological Gardens, Shangri-La Hotel are set.
  • Scripted or Automated – At this level of detail, the test cases are clearly described such that a person can run the test case by following a step by step procedure without misinterpretation or a software tool can execute it repeatedly with pass/fail results clearly defined.  

17.5 Kick Starting Use Cases to Solve a Problem our team is facing

Tom raised a question, “Our endeavor is getting more complex and it is difficult to see the big picture when looking at our product backlog.  I have heard that use cases could help us with this problem. But if we migrate to use cases, do we need to re-write all our old product backlog items into use cases?” 

Smith replied, “Kick starting use cases for an endeavor starts with identifying users and use cases to produce a skeletal use case model, and skeletal use case narratives. By skeletal, I mean it is not necessary to have detailed descriptions of all use cases of the system.  So, we don’t need to re-write all our old product backlog items. We just need to make a use case model and map the already done old backlog items to use case slices of the use cases in this model. The new backlog items will of course be use case slices not yet implemented”.

The activities to apply Use-Case Lite are Find Actors and Use Cases, Slice the Use Cases, Prepare a Use Case Slice and Test a Use-Case Slice, which we will discuss in subsequent sections.

17.5.1 Find Actors and Use Cases

The Find Actors and Use Cases activity is about agreeing on the goals and value of the Software System by identifying the different ways of using it. As a corollary of finding the ways of using it we also find the different ways of testing it (see Figure 122).

On the Find Actors and Use Case card, we see that the Stakeholder Representation and Analysis competencies are needed. We also see that this activity contributes to achieving the Requirements Conceived state, Bounded state and Coherent state. 

The card also indicates that the use case model needs at a minimum to achieve the Value Established level of detail and the use case narrative at a minimum must be Briefly Described.  The use case alpha needs to achieve the Goal Established state.

Figure 122     Find Actors and Use Cases

Smith had already worked with the team to create a skeletal use case model for the system as developed so far (see Figure 111 for the use case model). This can be said represent release 1 of the TravelEssence system.

Smith then went on and created a new use-case model for the new release of the system – release 2 - they were now working on (see Figure 123). He added a new actor, Digital Officer, responsible for overseeing all new product releases. He also added two new use cases, Manage Release and Analyse Recommendation Results. The Manage Release use case provided features to review upcoming planned releases, and the Analyze Recommendation Results use case provided features to examine recommendations provided by the system and provide feedback.

Figure 123     Use-Case Model for the next release of TravelEssence

Moreover, after a successful rollout to internal users Angela collected a number of feedback comments, which Smith also wanted to act upon for the next release of TravelEssence.  Some of the feedback comments related to usability enhancements, while others related to new functionality requests, such as:

  1. Recommendations by Advertisements - “We have revenue from advertisers. If these advertisers are within the vicinity of the traveler’s destination, they should be in the recommendations. However, we need to come up with a fair approach for prioritizing recommendations.”
  2. Sorting by Vicinity - “The list of recommendations is rather long, it should be sorted according to how close the advertisers are to the traveler.”
  3. Handling Favorites - “Sometimes, the traveler might want to remember the recommendation for future trips through some kind of ‘favorites’. Favorites should appear in future recommendations.”

From the above list of suggested improvements, Smith made the following updates to the Provide Travel Recommendation use case narrative (see Figure 124). Updated lines are marked with the hash tag “#Updated” and new lines are marked with the “#New”.

 

Use Case: Provide Travel Recommendations

Basic Flow:

  1. Traveller provides travel details (travel dates and destination)
  2. Traveller requests recommendations
  3. System provides list of recommendations
  4. Traveller browse recommendations
  5. Traveller selects and view recommendation.

Alternate Flows:

  1. Recommendations of different entities
    1. Hotel
    2. Places of Interest
  2. Recommendation computation
    1. Recommendations based on popularity rating
    2. Recommendations based on pricing
    3. #New Recommendations based on advertisements
    4. #New Recommendations based on favorites
    5. #Updated Weighting function for the above parameters (popularity, pricing, etc.)
  3. Recommendation request trigger
    1. User initiated
    2. System triggered
  4. Sorting of recommendations
    1. Sorting based on prices
    2. #New Sorting based on vicinity
  5. #New Recommendation actions
    1. #New Add selected recommendations to favorites.

 

Figure 124     Use Case Narrative:  Provide Travel Recommendations (Updated in the next release)

17.6 Working with Use Cases and Use-Case Slices

Working with use cases and use-case slices is about iteratively updating the use cases. It provides a high-level guide to everyone on the team, not only developers and testers, but also to product owners like Angela. As a software system evolves, the use case model with the use case narratives continually provides an easy to understand overview of what the system does.

17.6.1 Slice the Use Cases

Slice the Use Cases means to break it up into smaller parts to facilitate development (see Figure 125).

Figure 125     Slice the Use Cases

Identifying the use-case slices for simple situations is extremely easy because we don’t need to think about all possible conditions.  Of course, we eventually have to include alternative paths to cover each possible situation, but by handling each separately we keep things simple.   The use case narrative itself is structured in a form amenable for this purpose.

The use-case slices for the subsequent iterations on the team’s endeavor are as follows in Table 11. The three use-case slices in Table 11 correspond to the three requests listed earlier. The key difference is that the use-case slices now have explicit reference to modular and testable changes to the use case narrative.

Table 11        New use-case slices for the use case Provide Travel Recommendations

Use-Case Slice Name

Use-Case Slice Description

Recommendation By

Advertisements

#New Recommendations based on advertisements

#Updated Weighting function for the above parameters

Sorting by Vicinity

#New Sorting based on vicinity

Handle Favorites

#New Add selected recommendations to favorites

#New Recommendations based on favorites

#Updated Weighting function for the above parameters

 

After Smith and Angela had discussed and gained agreement on the modifications to the use case narratives, they started conversing with the team about the changes for the next iteration.

After reviewing the use case narratives that Smith developed, Tom exclaimed “Wow! Now I see how everything fits. This organization of the narratives gives a very good structure to help me understand how new requirement-items will impact our system, the requirements and the tests.” After we implement our chosen slices for each sprint we will need to verify that each one is done and is ready for inclusion in our next release.

As you can see from Figure 124 that the use case narrative is organized such that each of the alternate flows provides a way to group related requirements. For example, recommendations on places of interest to visit or hotels to stay at (alternate flow 1) are grouped together, and recommendations based on attributes such as pricing and popularity are grouped together (alternate flow 2).  This kind of organization can help developers structure their code and test cases in a way that eases the long-term maintainability of the system.

17.6.2 Prepare a Use Case Slice

The Prepare a Use Case Slice activity enhances the use-case narrative and the use-case slice test cases to clearly define what it means to successfully implement the use-case slice.

Figure 126     Prepare a Use Case Slice

For brevity, we will only focus on one use-case slice: Handle Favorites. Favorites are just a list, which the application stores for the user. If a user determines that a recommendation is useful for him/her, he might want to store this recommendation in his favorites list. This favorite list also acts as an input to the recommendation engine. So, the recommendation will behave differently for a new user without any favorites, or an old user that has some favorites.

 It is clear from Table 11 that there are 3 distinct and separate slices, namely:

  1. #New Add selected recommendations to favorites
  2. #New Recommendations based on favorites
  3. #Updated Weighting function for the above parameters

Another important work product output of this activity is the use-case slice test cases. Smith and his team brainstormed the use-case slice test cases for each of these slices. The resulting outlines of these test cases are summarized in Table 12.

Table 12        Test Cases for Handle Favorites

Use-Case Slice

Use-Case Test Cases

#New Add selected recommendations to favorites

  1. New Favorite
  2. Favorite already exists
  3. Maximum number of favorites

#New Recommendations based on favorites

  1. No Favorites
  2. One Favorite within vicinity of traveller destination
  3. One Favorite outside vicinity of traveller destination

#Updated Weighting function for the above parameters

  1. Weightage of favorites set to zero
  2. Weightage of favorites set to 0.5

The level of detail for the use-case slice test cases were just Scenario Chosen.

17.6.3 Test a Use Case Slice

The goal of the Test a Use-Case Slice activity is to verify that the slice is done and ready for inclusion in a release. 

Figure 127     Test a Use Case Slice

The Use-Case Slice test cases choses earlier in Section 17.6.2 are of course an important input to this activity. During testing, these test cases are refined further with additional details to make sure that they are repeatable. 

17.7 Visualizing the Impact of Using Use Cases for the Team

In our story, as the complexity of the endeavor grew, team members recognized that their simple approach to capturing requirements as a collection of user stories was insufficient.  By migrating to use cases the team found they could see the big picture of the system better through their use case diagrams and use case model.

This is made visible by looking at the Use Case Lite’s coverage of the solution activity spaces (see Figure 128).

Figure 128     Use Case Lite practice coverage of kernel solution activity spaces

Compare this with Figure 109 in section 16.8.1, you will see that the activity space “Shape the System” is covered by the “Find Actors and Use Cases” activity. This activity has the dual purpose of understanding requirements and shaping the system. Both the use case model and use case narratives (basic and alternate flows) are tools that help teams organize/structure/shape requirements. They help teams see the “big picture.”

As new requirements came to the team, the team could easily see where these would fit in the overall structure of use cases, use-case slices, and associated work products such as the use case narratives and the use-case slice test cases.  The team members agreed that the overall maintainability of the system had been much improved by their moving to use cases.  This was for multiple reasons. First, because of the structure provided by the organization of the narrative separating basic and multiple alternative flows.  Second because of the big picture provided by the use case model. 

17.8 Progress and Health of Use Case Slices

You have just learned about how to apply our Use Case Lite practice for several use-case slices from a single use case, (i.e. Provide Travel Recommendations). In general, teams work with multiple use-case slices from multiple use cases at any point in time. They complete use-case slices within each sprint, (i.e. drive them to the Use-Case Slice Verified state). While individual use-case slices are completed in each sprint, often it requires multiple sprints to complete a full use case.

Since, on most software endeavors there are a number of Use Cases and Use-Case Slices progressing in parallel, it is important that the team has agreed to a way to monitor their progress and health.  One approach that is popular at the time of writing this book is for team members to have the competency to self monitor their progress and health. The alpha state cards for Use Case and Use-Case Slices (see Figure 116 and Figure 117) provide a tool for this purpose.

Now, recalling that our TravelEssence team has chosen multiple practices, this means that they have a number of alphas to juggle, namely:

  • From the Scrum Lite practice
    • Sprint – focusing on the goals for the Sprint
    • Product Backlog Item – a change to be made to the product in a future release
  • From the Use-Case Lite practice
    • Use-Case Slices – the Use-Case Slices to be Verified by the end of the Sprint
    • Use Cases – they need not be completed for each sprint, but they are useful for determining which use-case slices should be implemented first. As mentioned, they will take several sprints to be completed, (i.e. All Stories Fulfilled). Thus, different use cases will be at different states at the end of each sprint.
  • From the Essence kernel
    • Work – the team needs to maintain the Under Control state as development progresses.
    • Requirements – the Requirements alpha progresses towards Addressed or Fulfilled depending on the goals of the sprint.

Smith’s team found that agreeing on these target states helped them achieve focus at the beginning of each sprint. They are also useful for reviewing progress during their Daily Scrum (see chapter 15).

During one of their Sprint Retrospectives, Tom stated, “I find the checklists for the Use Case alpha states and Use-Case Slice alpha states more useful to me than the Requirements alpha states.”

Smith replied, “Yes, that is reasonable as you are focusing on progressing specific use-case slices for specific use cases. However, from my perspective, I still need to view development progress of the whole endeavor. Thus, I would need to understand the progress and health of the whole endeavor. That would include not just the Requirements or Work alphas, but also the Opportunity, Stakeholders, Team, Way of Working, and Software System alphas.”