The use case terminates when the Network Element terminates the session

Use Case 2-1 Use Case Horror: Provision a Cross-Connect (ENGINEERING CENTRIC VERSION

However, this use case is confusing because it contains fragments of TL1 code, which is a special language for interacting with telecommunication equipment. Most software developers would find this use case perfectly acceptable, especially if they didn’t know TL1, because it would tell them how to provision the device. Unfortunately, it leaves those stakeholders who don’t understand TL1 in the dark. Worse, the use case is only valid for TL1 implementations, and isn’t general enough if you suddenly have to use other protocols. The following version is much more general and easier to understand:

USE CASE 1: Provision a Cross-Connect (USER FRIENDLY VERSION)

Primary Actor: Network Administrator: Person provisioning Network Elements.

Secondary Actor: Network Element Device being provisioned.

Level: User Goal

Preconditions: Network Element is accessible and user has a valid account on it.

Success Guarantee: Cross-Connect is provisioned and viable.

Main Course: 1) The use case begins when the Network Administrator logs on to the Network Element.

2) The Network Element verifies the user and begins a session.

3) The Network Administrator determines the size of the cross-connection, and sets up the endpoints accordingly.

4) The Network Element establishes the endpoints.

5) The Network Administrator defines the cross-connection.

6) The Network Element establishes the cross-connection.

7) The user logs off of the Network Element.

8) The use case terminates when the Network Element terminates the session.

Use Case 2-2 Provision a Cross-Connect (USER FRIENDLY VERSION)

This version is better because it is easier to read, and supports multiple protocols. You could still include the TL1 samples for the implementers, but as Adornments(147) (Chapter 5) at the end of the use case, or in a separate document.

2.5 Tradeoffs and Collaborations

Using small balanced writing teams and controlling audience participation is an easy way to improve the quality of your use cases. While not difficult, organizing such teams does require forethought and balancing several competing forces involving team size, audience involvement, and skills. There is no one perfect mix that always works and it is up to each development organization to balance these patterns to determine what team arrangements will work best with their particular circumstances.

We cannot say enough about the importance of involving your customers in the use case development process. One of the most significant benefits of use cases is that they model how the system delivers measurable value to its users. Being unable to talk to the customer, whatever the reason, increases your risk, so you should find some other way to gather this information. Larry Constantine offers excellent advice on dealing with these kinds of circumstances in his book “Software for Use” [CON1999].

While these three patterns complement each other well (see Figure 2-1), they do create some tension with ParticipatingAudience(50) and BalancedTeam(54) trying to enlarge the group and SmallWritingTeam(47) trying to shrink it. However, the intention behind SmallWritingTeam(47) is to keep the process manageable. ParticipatingAudience(50) provides a mechanism for many other people to contribute to the use case process without overwhelming it and therefore avoids the problems of excessively large teams. ParticipatingAudience(50) also helps a group become a BalancedTeam(54) by involving people with different backgrounds and viewpoints to influence the use cases without increasing the development team’s size. The diversity these two patterns provide helps steer the teams towards using a common vocabulary, rather than a discipline specific one.

Team Organiation

ParticipatingAudience BalancedTeams

SmallWritingTeam

Process

TwoTierReview

Figure 2-1

To illustrate these points, consider what kinds of teams would be best suited for writing use cases for a project involving pharmaceutical manufacturing. These kinds of systems must meet exacting standards for purity and precision, as well as rigorous legal and accounting requirements. A pharmaceutical company manufacturing controlled substances must be able to account for 100% of the controlled substances they use, or they face unwanted visits from the Drug Enforcement Agency.

First, you would want to set up SmallWritingTeam(47)s, because you want the writers to exercise tight control over their use cases, and write with a high degree of precision. But, you also need a high degree of ParticipatingAudience(50), probably more than usual, to verify that the resulting product meets all required standards and complies with the law. In this case, BalancedTeam(54) has the greatest impact on the results because of the complexity of the problem and the number of technologies involved. Most likely, you would want to staff your teams with combinations of software developers, pharmacists, biochemists, and even lawyers, depending on the needs of the various use cases.

The biggest benefit of using BalancedTeam(54) in this instance is that it forces the writers to use a common, understandable terminology in their use cases. Commonality is especially important in this situation because each of the disciplines involved in developing this product has its own exclusive and highly specialized vocabulary. ParticipatingAudience(50) helps counter-balance this problem to some degree, but even then one audience will likely have trouble with another’s terminology, which is often incomprehensible to those outside of the profession. Software developers talk about stacks, queues, XML, Bridges and Visitors, while the pharmacists would describe chemical reactions such as “de-hydro-halogenation” and use complicated chemical formulas. Lawyers also have a reputation for obtuse writing; imagine reading use cases like “the Line Supervisor actor shall henceforth be know as the party of the third part”, etc.

While important, team organization is only a small part of the picture. A team also needs to follow a good process to be able to identify and write quality use cases, which is the subject of the next chapter.