Use Case Sequence

Chapter 6 introduced ordering steps with the following sequence:

• Think of what you do when you sit down at your computer for the time in the morning, with it turned off. For example, in my case, I…turn it on. Wait, maybe I plug it in (when I am traveling). Then I turn it on and wait for the desktop to come up. I call up my applications I want open. I do my e-mail app first to check e-mail and have available for research. Then I open the word processor so I can write my books. I call up the file manager so I can open various files that may not be in my recent list in the word processor. (I break books into chapters for drafting them, but that is my peculiarity.) What you do may be different, but you get the idea.

Now you will learn how to capture what is described in free text in a more structure approach. Chapter 12 introduced the elements you should include in a use case, based on what Usability.gov provided for us.

• Unique Identifier: Any identifying system, alpha and/or numeric.

• Title: An identifier or name of the use case. It’s highly recommended that it consists of a verb and noun at the very minimum.

• Description: A brief description of the purpose of the use case.

• Actor: Anyone or anything (another system, such as an application or device) that performs a behavior: basically who or what is using the system. This is not limited to one actor.

• Preconditions: What must be true or happen before the use case runs.

• Postconditions: What must be true or happen after the use case runs.

• Triggers: This is the event that causes the use case to be initiated.

• Main success scenarios (aka basic flow): Use case in which nothing goes wrong. (This is also known as Normal Flow/Scenario, Primary Flow/Scenario.)

• Alternative paths (aka alternative flow): These paths are a variation on the main theme. These exceptions are what happen when things go wrong at the system level or an alternate condition causes a change to the basic flow. (This is also known as extensions.)

There are optional fields you might consider:

• Exception flows: Error conditions that happen. This will be discussed more shortly as a variation of alternative flows. Not all use cases may have this.

• Business rules: Rules that influence or affect the use case. Not all use cases may have this (specific examples of these won’t be provided because they do not always happen).

• Special requirements and assumptions: Additional factors that affect the use case. Not all use cases may have this (specific examples of these won’t be provided because they do not always happen).

Here is that earlier example of a use case:

This use case fills in all the data elements of a use case. Additionally, you see the how low level a use case should be. Nothing should be skipped. A developer and a tester would be able to work from this. More importantly, a user and a stakeholder should be able to understand it and either agree with it or correct it. Now you will look at another use case.

Login Use Case

However, look at some other examples. Remember when Chapter 13, in the “Attributes of a User Story” section, talked about the access control? The following is a use case for logging onto the system. You may want to look back at the user stories to see what they cover.

The alternative flow was left blank since what alternate flows exist yet have not been examined. First, consider a “cancel” option because you might inadvertently activate the wrong option.

You will write “cancel” as an alternate flow for the 14-2 use case by writing the specific steps associated with this alternate flow. Choose the “cancel” option first before entering the user ID as an alternative flow. Remember, you may allow cancelation at any point before step 6 in the basic flow, but that also is left to you as an exercise. Therefore, you want to quit the login process, so you have the following alternative flow:

What about having the option to select a previous value user ID entered so you do not have to enter the value every time?

What about when someone enters an incorrect user ID or password into the login process? Say you enter the wrong user ID and/or password, such as transposing two letters. You can handle these situations in one of two ways. The first method is to present them as just alternative flows. Alternatively, some sources recommend a separate box titled “Exception Flow.” Now, look at both methods of presenting them.

Now you have one failure to enter a proper user ID-password combination. You need to see how it looks for a second failure .

Now you have two failures to enter a proper user ID-password combination. You need to examine how it looks for the third and final failure.

Back to alternative path versus exception path: some sources will say that this is an exception path and requires a separate box from alternates. This is not required. That is for you and your organization to decide if you want to include them together or have them separate. Flow will be used in this text for consistency; just know that path will work also. It is a preference only.

Next, put the complete use case together after you have completed writing it.

Next is the complete use case with all alternate flows and exception flows.

As with user stories and shall statements, clarity is important. The structure of a use case does not mean that it instantaneously becomes clear and understandable. You, as the RE, must provide that clarity. Certainly, the structure helps by providing a template, but it still ultimately falls to you.

As a final point, look at that box that has the Basic Flow, Alternate Flow, and Exception Flow fields. That is very good information for helping with the development of test cases and procedures. Look specifically at Exception Flow, specifically the three strikes rule for accessing the system. Where does it indicate what can be wrong? It says a user ID-password combination that is wrong. A tester would need to test all possible combinations. They would need to try three wrong user IDs, three wrong passwords, two wrong user IDs and one wrong password, and one wrong user ID and two wrong passwords. Thus, a use case does not provide every single detail of both the developer and tester needs, but it is better than a user story .

Unit Dosimetry Report Use Case

Now, look at another use case. In this case, go back to the radiation dosimetry example project, for the Dosimeter Archive Laptop introduced in Chapter 1 and discussed Chapters 2, 4, 5, and 8. Specific requirements related to the project include

• Chapter 2 : Requirements 2-21 to 2-32

• Chapter 4 : Requirements 4-38, 4-71, 4-72, and 4-74

• Chapter 5 : Requirements 5-5, 5-8, 5-13, 5-14, 5-23, and 5-42

• Chapter 8 : Requirements 8-9, 8-14, and 8-15

In this case, after data has been collected from a unit after leaving a nuclear fallout area, the medical officer needs a report on the medical readiness of the unit. Therefore, you might have the following use case:

It is possible that additional alternative flows exist depending on if this report defaults to just a listing of each soldier and the exposure each has. For example, there may be options in the report for some summary values such as average exposure (totals mean nothing), people who exceed specific levels, highest exposure, x number of highest exposures, which the user may have available to them, and so on. In that case, you might expand the alternate flows as follows:

Look at those last three alternatives. What happens if the user wants more than one or any combination of the three? Can you rewrite it to be more flexible? Of course. See the following alternative flows.

As before, now look at the complete use case for this radiation dosimetry project.

You can see that a use case is much more detailed than a user story and provides more data than shall statements. One significant advantage use cases have over shall statements is that sequence of steps is addressed well.

In an agile environment, you could do roughed-out use cases and spend more effort completing the detail as the use cases are coming up on the backlog for implementation. Thus, you can use cases with agile.

While you have seen a template to invoke when crafting use cases, there is no industry standard. Therefore, this may be organizationally specific. Do not be surprised in your career that you find them implemented somewhat differently in various organizations. Keep in mind that even within the same company, you might find different implementations. Experience shows that groups, divisions, and offices have different cultures, which can influence how they apply processes, so do not be alarmed about differences. Learn what they do, and if you can learn why they do it, you will understand, and you may be able to influence refinements that might improve processes in the future.

Gap Analysis

How will you know when you have all the use cases you need? That is the same challenge you had with shall statements and user stories. Apply the same techniques. Remember in Chapter 9 when you learned about writing a Business Process Description (BPD) document? Now is one of those times when a BPD will become useful. In fact, if you wrote the BPD document properly, it should go a long way to defining use cases, in that you should write in a logical, process flow manner, just like the users of the system would experience.

In the shall statement analysis, you had to perform gap analysis. That also applies here. How easy is it to ensure that all aspects of every use case are captured? With shall statements, you have detailed statements that address each point. With use cases, there is much more detail, and with the overlap potential between use cases, there is the possibility of small gaps appearing adjacent to these use cases. It may be that you are missing some alternative flows that are not obvious to you. Alternatively, they are just miniscule but separate use cases that are not obvious. It does not mean that you cannot find them, but it may be challenging.

When you are planning to craft your use cases, it is advisable to make a list of all your actors for your system. For example, for your BOSS HR system , you might have the following:

• HR personnel user: Someone who handles all the information about a person in your organization

• HR payroll user: Someone who handles all the payroll information about a person in your organization

• HR retirement user: Someone who handles all the retirement information about a person in your organization

• Employee: Someone who accesses the BOSS HR system to view the information about them

• HR system administrator: Someone who handles all the maintenance of the BOSS HR system

There may be more, but that is dependent on what is included in the system. Also, examine the actors for the BOSS dosimetry system , where you might have the following:

• Soldier: Soldier in the nuclear battlefield who wears a radiation detector

• Radiation data collector: Person who reads the individual radiation detectors

• Medical officer: User who needs to know the immediate and long-term implications of radiation exposure

• Commanders: Unit commander or higher who needs to know the status of his or her soldiers

• Dosimetry equipment maintainer: User who must maintain all the hardware and software for the entire system

You may notice overlap where two apparent different actors perform the same use case or use cases. In this case, you may want to redefine the actors such that the overlap is a new type of actor. The medical officer and commanders both have a need to know the immediate status of soldiers. Only the medical officers need the long-term effect—long-term means years out—say for Veterans Administration purposes, after the soldier leaves service. Therefore, maybe you consider the following redefinement to these two actors:

1. People who need immediate status: Commanders and medical officers who need to know the immediate status of the soldiers

2. People who need long-term status: Medical officers who need to know the long-term effects to the soldiers

Once you have listed each actor, list the potential use cases for each actor, as in Table 14-1 for the HR system and Table 14-2 for the radiation dosimetry system. These tables include likely use cases but may not be exhaustive. Of course, the use cases for your organization will likely be different.

The next step would be to craft the use cases listed. This would follow the normal elicitation techniques you have already learned. It is just that you organize the data somewhat differently from user stories and shall statements. Remember, the biggest benefit to use cases is the stepwise sequencing of steps that shall statements are not as good at capturing. Also, you capture the alternate and exception flows. All this together provides complete interaction that shall statements do not by themselves without significant textual description associated with them.

One other aspect to consider for gap analysis, similar to what you do for user stories, is that you should map existing shall statements to use cases. Not only will this indicate potential shall statements you may have missed, but also, just like in user stories, you may find orphaned requirements that may need use cases.

Next, you will examine the advantages and disadvantages of use cases.

Advantages

A collection of easy-to-read use cases can be much easier to work with than, say, a list of 1,000 shall statements. They also capture the flow that shall statements generally do not. Chapter 6 made a serious attempt to capture this for shall statements. That said, it does not capture the same level of detail as a use case, especially when you consider alternative flows and exceptions that are difficult to capture. Even user stories do not capture these as well.

The use case approach does provide a benefit that user story definition also provides. Not only is it more readable than the shall statements, but it creates and maintains engagement of the users and stakeholders. This is because they have a say in what gets built as well as having a presentation of the requirements in a more understandable format.

The article “Use Cases” on Usability.gov says that this about the benefits of use cases:

Use cases add value because they help explain how the system should behave and in the process, they also help brainstorm what could go wrong. They provide a list of goals and you can use this list to establish the cost and complexity of the system. Project teams can then negotiate which functions become requirements and are built.

Clearly understanding how a system should work is absolutely important. Additionally, knowing what aspects might deviate from the norm or go awry is nearly as important. Actually, the alternate flows and exceptions/error conditions are aspects that are not captured well by shall statements and certainly not by user stories. Alternate flows and exceptions are not always well understood when capturing requirements. In fact, it could be alternate flow and exception conditions needs are not traditionally explored well in business process analysis, requirements definition, and even design. People may spend time considering “what-if” during analysis (something science-fiction writers have been doing for more than 100 years). However, “what-if… else…” has not always been examined. These use cases give the ability to examine every aspect of a potential system, thereby helping in the gap analysis. This use case approach provides more context to the requirements than do user stories and shall statements.

The last two sentences in the Usability.gov benefits statement are not unique to use cases, as they are similar to user stories. If you understand that the “list of goals” is essentially the titles of each use case, you see that it is the same as the names of all the user stories. Alas, shall statements do not have the same type of “goal.” Yes, shall statements can have section headings, but that does not necessarily have the same granularity and scope as either a use case or a user story.

Use cases have a good structure, shown in the “Writing Use Cases” section in this chapter in great detail. This will help not only you to craft a good use case, but also assist the stakeholders in reading and comprehending the use case. Use it and be consistent with it. Don’t change the structure around within a project. Define your structure and stick with it. Of course, if it becomes apparent in a project that changes need to be made, then do it to all use cases for consistency. Otherwise, you will confuse the pe ople who read it.

The “Gap Analysis” subsection discussed how the use case approach assists significantly in identifying gaps as you craft use cases. Not only does the listing of actors and their associated use case titles help with this, but also the alternate and exceptions flows help to mitigate many if not most of the potential gaps in the requirements analysis.

The “Login Use Case” subsection talked about the significant advantage the detail provided in the use case gives the testers. While user stories have acceptance criteria, use cases have much more detail to help in crafting test cases and test procedures. It provides more detail, just not all the detail, as you will see in the next subsection.

Another advantage use cases have over user stories and shall statements is that use cases provide more information that can be used for documentation, such as user manuals and design documents. Just as with the test documentation, use cases provide a foundation upon which to build from, just not all the detail that is needed for these documents .

Disadvantages

As was said before, use cases often are not quite as well understood by users and stakeholders as user stories. You have to decide if educating your user base on the exploitation of use cases is worth the investment in time. Given the advantages discussed, it might be. That said, there are some challenges with using them.

Use cases are not so good for system-centric functions like batch processing, data warehouses, and computationally intensive functions. How would you represent a complex algorithm? Think of the software to control an interplanetary spacecraft, with significant mathematical calculations. Who are the actors—gravity that affects every object in space? The spacecraft itself? Or the controllers back at NASA? What about the equations that represent celestial mechanics or orbital mechanics? They are complex when you talk about sending a spacecraft from the Earth to, say, Mars. How do you show every step of an equation?

In addition, nonfunctional requirements, especially performance, are harder to capture. They have no actors, and they do not have alternate flow readily apparent. Additionally, many users are not comfortable trying to understand this structure.

Wikipedia’s “Use Case” article states that “there is a misconception that a use case is not agile.” That is true if all use cases must be completely written at one time. This use case approach may work better for the waterfall approach, as the use cases are prepared up front, not necessarily just-in-time development. Of course, use cases can be created this way, but there is potential for impact to other use cases. For example, if you have four use cases dealing with using people’s roles and responsibilities to determine what functions they can access and you change one use case, you will need to verify that each use case is not affected by that one change. Again, you have encountered the ripple effect, where one change could ripple through other potentially unsuspecting areas. Thus, the Wikipedia article is correct—use cases are agile.

You should be aware, because of the size of many use cases; they may not be small enough to work in an agile environment. If you need to craft use cases for agile developments, consider breaking the use cases into smaller, more manageable chunks so that they can be accomplished in two- to six-week sprints (organizationally dependent).

Again, the Wikipedia “Use Case” article says, “Use case developers often find it difficult to determine the level of UI dependency to incorporate in a use case.” This is not a statement everyone necessarily agrees with. The statement is that the difficulty of determining the UI dependency is hard. That can be true. From what you have learned, you not should try to capture the UI in the use case. Remember, the tenant of “implementation independence” was emphasized for both shall statements and user stories. Well, it applies to requirement use cases as well. Thus, this challenge goes away for you as an RE. However, that is not to stop developers from writing “design use cases” in which case they may have this challenge of UI dependency. However, this limitation was avoided for you.

The next section will examine using use cases with or without shall statements. Especially in the “without” situation it will be addressed that over-reliance on use cases. You have seen where some aspects of requirements are not captured well by use cases. Keep that in mind.

While use cases provide excellent information for crafting test cases and test procedures, as was talked about in the three strikes rule in the login use case, the use case does not provide all the detail needed for testing, so do not rely on it for that. It is an excellent start point—but it’s the foundation, not everything that is needed.

Earlier we talked about complexity such as algorithms, but there is another aspect to consider—data elements, especially if there are a lot of them. How do you handle, say, several dozen elements? Are you going to write one use case for a form that has all of them? While that might sound good at first blush, consider alternate flows and exceptions. Many items such as country may spawn different fields for Canada versus the Unites States. In the United States, we use states versus provinces and territories in Canada. Do that for two dozen elements and you will have a very large and difficult-to-read use case. It is recommended that you break the data elements into categories with manageable numbers of data elements to make the use case readable and less complex. What is manageable? That is difficult to determine without looking at the elements and the alternate and exception flows.

Time-driven events are not handled well by use cases. Who is the actor here? The passage of time? That does not work well. You might argue that the system itself is the trigger, but it is a combination of the system driven by the passage of time. This gets to the aspect mentioned earlier about forcing everything into a use case, when the methodology does not support it well.

Real-time systems are also not handled well. Think of a nuclear power plant. You have the humans running software that controls the reaction, but you have the nuclear pile itself doing its radioactive decay and nuclear interactions following the laws of quantum mechanics. How would you capture all the parts of this in use cases? If you want a lesson when these things broke down, read up on the meltdown in Three Mile Island in the 1970s. Alarms were blaring and lights were flashing that made it difficult for the operators who were trying to figure out what was going on, yet the operators could not shut off the alarms and lights so they could think.

While it will be mentioned again in the “Replacement for Requirements” section, it is stated here—use cases cannot capture every aspect of a system. This should be evident from the disadvantages in this subsection. To reiterate this, Karl Wiegers said the following in his book More About Software Requirements: Thorny Issues and Practical Advice:

Unfortunately, despite thousands of students I’ve taught in requirements seminars over the years, I have yet to meet a single person who has found this pure use case approach to work!

This could not have been said any better, and this adds a wealth of additional experiences to reinforce the point. So, keep this in mind—use cases cannot satisfactorily address every aspect of a system.

In the next section, you will look at use cases complementing and replacing shall statements and then finish by looking at using use cases, user stories, and shall statements together.

Complement to Requirements

In this section, you will see how shall statements can complement use cases, so in this section, the answer is yes to shall statement with use cases.

Absolutely. The previous subsection discussed some of the disadvantages of use cases, such as the inability to capture nonfunctional requirements effectively, similar to the challenge that user stories have. Well, having use cases complementing shall statements will mitigate that problem. In addition, shall statements are not effective for capturing the full gamut of a set of ordered steps with branches, whereas use cases do this effectively and in fact much better than user stories.

The flip side is that use cases do not capture nonfunctional statements, algorithms, complex manipulations, batch processing, and other topics discussed in the “Disadvantages” section in this chapter, whereas the shall statements do. For example, how would you capture that a system should be available 99 percent of the time as a use case. It would not work as a step, nor any of the other attributes.

Thus, you should capture it as follows:

• 14-1 (4-6) (RQMT) The BOSS system shall be available 99.99% of the time.

You could then have a use case that determines what the value is for a system as follows:

You could add a step that compares the value in step 4 to the value identified in requirement 14-1. Wait, you say, could you not specify the value of 99% in the step? Yes, you could. However, that step does not specify the force that the requirement has as a minimum acceptable value of 99%.

Thus, these two complement each other well.

Replacement for Requirements

Just as was said in the previous section that shall statements complement use cases, this section will talk about how use cases replace shall statements. There are experts who advocate that well-crafted use cases do not require shall statements, because if the stories are captured correctly, you do not need to capture shall statements.

Use cases are written with the user in mind (called user facing by some), which is true that use cases do capture well what the user may need. That said, use cases may never completely replace shall statements. Just as was discussed in the “Advantages and Disadvantages of Use Cases” section in this chapter, use cases do not capture items such as nonfunctional statements, algorithms, and batch processing. Being forced to capture these kinds of requirements purely as use cases will make the complex and difficult to read at best and totally incomprehensible at worst.

Look at the following shall statement:

14-2 (RQMT) The BOSS system shall use the following equation to represent gravity generated on an object by the earth:

g = GM/R²

where g is gravity, G is the gravitational constant, M is the mass of the earth, and R is the distance between the object and the center of the earth.

Capturing that equation and the associated value in a use case would be difficult. For example, what is the actor? Defining the steps is difficult as gravity works all the time. Thus, you cannot easily write a use case for this type of need.

Therefore, it is not recommend that you capture requirements only with use cases.

All Three Together

Can shall statements, user stories, and use cases work together? Unquestionably. This way you take advantage of the benefits of each and help to diminish the disadvantages of them as well. Will you always get the opportunity to do all three? Unlikely. We have seen where use cases are excellent at providing a sequence of steps. If you have situations in your project where you have such sequences, use cases are your best bet. User stories are excellent at providing detail and, most importantly, descriptions of why a certain need is important—none of the others do that. Finally, they can cover what user stories and use cases cannot. For example, nonfunctional requirements do not work well with user stories and use cases, whereas shall statements capture these needs very well.

Exercise 1

Write all the possible alternate flows for canceling the login process for all possible spots in the basic flow.

Exercise 2

Write an example of a use case for signing in with a user ID, password, and domain name. Three strikes and you’re out.