Use Cases of Mass Destruction

In This Issue:
--Use Cases of Mass Destruction
--Use Case A: Informal Version
--Use Case B: Narrative Style
--News and Views from the AM Mailing List
--Hot Links

Dear Software Development reader:

Now is a very interesting time for developers. First the bubble burst, then the economy fell, and now IT jobs are sailing to foreign shores. All through these changes, we've been watching salary, skill and job satisfaction ratings among experienced developers and managers. I'm anxious to see what this year's stats tell us.

We're closing the data collection period for our annual developer salary survey on Friday, August 22. This year, the response has been phenomenal. We're very close to surpassing 5,000 respondents, in fact, which is why I'm making one last call to our readership. If you haven't already, I urge you to take a few minutes to fill out the SD salary survey.

If you have already completed the survey, feel free to forward this email to colleagues. Note that the survey only looks at U.S. residents (citizens, legal aliens and visa-holders) who are employed in IT -- we do not collect data from students, consultants, part-time employees or unemployed workers.

The 26-question survey takes about eight minutes to complete, and can be found at http://www.cicresearch.com/Proj03792/

Please be assured that all responses are completely confidential. This is used exclusively as editorial research for an article to be published in the November 2003 issue. Only aggregate results will be used, and we will not disclose or use your e-mail address for any other purpose than to alert you to next year's survey.

Sincerely,

Alexandra Weber Morales
Editor in Chief
Software Development
CMP Media LLC
600 Harrison Street
San Francisco, California 94107
[email protected]

Use cases are the primary requirements artifact for several Software Development methodologies -- including ICONIX, the Rational Unified Process (RUP) and the Enterprise Unified Process (EUP) -- and for many developers they're synonymous with the concept of requirements. It's high time someone examined the effectiveness of use cases; therefore, I have two fundamental observations to share with you:

1. Use cases, when used properly, can be an effective form of requirements.

2. From an industry perspective, use cases may have a negative impact on overall productivity.

First and foremost, use cases can be quite valuable. I've worked on many projects in which use cases were vital tools for discovering usage-based requirements, and I have no doubt that most of you have been on projects that benefited from the application of use cases had similar experiences. There are many helpful books and Web pages on the subject, and a good starting point is Alistair Cockburn's site ( http://members.aol.com/acockburn ).

Unfortunately, you need only to spend some time on modeling- related mailing lists to discover that many organizations are struggling with use cases: a challenge that's relatively easy to overcome. A more insidious problem is process-related -- the bureaucrats often want you to make your use cases more complex and wordy than they need to be. For example, I've included two examples following this article (scroll down for details) -- Use Case A: Informal Version presents an agile use case, whereas Use Case B: Narrative Style presents a much wordier, more traditional version of a use case. See the difference? Imagine how easy it would be to write the agile version -- and then compare it to the traditional version. Is the greater investment of resources worth it? I'm not so sure.

Although the agile alternative achieves the same fundamental goal as its heavyweight counterpart, bureaucrats will rarely allow you to go lean in this way. Not realizing that developers are intelligent beings who don't require extensive documentation, they insist that you write "nearly perfect" use cases to ensure that you understand the requirements. The bureaucrats also want to review the use cases to ensure that they're correct, comprehensive and compliant with the bureaucrats' onerous standards. These reviews also justify the dubious necessity of additional bureaucrats nosing into your quality assurance group -- after all, paper doesn't push itself.

I believe that this process is the crux of the use-case problem. In many organizations, "well-intentioned" bureaucrats have turned a potentially simple and effective model into an onerous, unnecessarily complex rigmarole. It's simple to teach developers to write agile use cases like the informal version of "Enroll in Seminar" (Use Case A), but it's not so easy to teach them how to write use cases in the formal narrative style presented in Use Case B.

Do agile use cases really work? Yes, for the vast majority of projects, if the team is allowed to succeed. Agile developers understand that models don't need to be perfect; just barely good enough. Use Case A is just barely good enough, while Use Case B is bureaucratic overkill. Is your primary goal to build working software that meets the needs of your stakeholders -- or to justify the bureaucrats' existence?

Another common use-case challenge is the literal acceptance of "use case-driven" marketing rhetoric. Use cases are one of many modeling techniques: They're very good for exploring usage requirements, but not so good for exploring user-interface or data requirements, business rules, or constraints (to name just a few examples). Instead of adopting several modeling techniques and using each when appropriate, some people assume that use cases must include all requirements. This approach produces large use cases that are difficult to understand and manage, decreasing your development flexibility.

Use-case modeling specialists are also part of the problem: When someone's job is to write use cases, chances are good that they'll write use cases -- whether you need them or not. They'll also write overly complex use cases, whether you need them or not, because they need to look busy. They'll actively lobby to ensure that use cases are a critical part of anything you do, whether it's appropriate or not.

My advice? Chill out and understand that use cases don't need to be perfect and that they're only one of several modeling artifacts. You should also promote the concept of generalizing specialists within your organization: People who have one or two specialties and a general understanding of Software Development are better able to understand the role of use cases (and any other development artifact, for that matter) in your project, and accurately judge how much effort should be invested in them. Specialists are too narrowly focused to make this type of decision.

It's possible to employ use cases effectively, but you must choose to do so. I've seen several projects in which use cases have added value, but many others were complete disasters. I don't have any hard figures, but my gut tells me that use cases have had a negative impact on our overall productivity across the IT industry. I see too many people arguing about formatting issues, content issues, traceability issues and so on, and suspect that the "use case thrash" more than outweighs the benefits we've achieved to date; in fact, someone in the research community should investigate this issue.

USE CASE A
Informal version of the "Enroll in Seminar" system use case.

Name: Enroll in Seminar

Identifier: UC 17

Basic Course of Action:

-- Student inputs her name and student number
-- System verifies the student is eligible to enroll in
seminars. If not eligible, student informed and use case ends.
-- System displays list of available seminars.
-- Student chooses a seminar or decides not to enroll at all.
-- System validates the student is eligible to enroll in the chosen seminar. If not eligible, student is asked to choose another.
-- System validates the seminar fits student's schedule.
-- System calculates and displays fees.
-- Student verifies the cost and indicates she wants to enroll or not.
-- System enrolls the student in the seminar and bills her for it.
-- The system prints enrollment receipt.

USE CASE B
"Enroll in Seminar" written in formal narrative style.

Name: Enroll in Seminar

Identifier: UC 17

Description:
Enroll an existing student in a seminar for which she is eligible.

Preconditions:
The Student is registered at the University.

Postconditions:
The Student will be enrolled in the course she wants if she is eligible and room is available.

Basic Course of Action:

1. The use case begins when a student wants to enroll in a seminar.

2. The student inputs her name and student number into the system via UI23 Security Login Screen.

3. The system verifies the student is eligible to enroll in seminars at the university according to business rule BR129 Determine Eligibility to Enroll. [Alt Course A]

4. The system displays UI32 Seminar Selection Screen, which indicates the list of available seminars.

5. The student indicates the seminar in which she wants to enroll. [Alt Course B: The Student Decides Not to Enroll]

6. The system validates the student is eligible to enroll in the seminar according to the business rule BR130 Determine Student Eligibility to Enroll in a Seminar. [Alt Course C]

7. The system validates the seminar fits into the existing schedule of the student according to the business rule BR143 Validate Student Seminar Schedule.

8. The system calculates the fees for the seminar based on the fee published in the course catalog, applicable student fees and applicable taxes. Apply business rules BR 180 Calculate Student Fees and BR45 Calculate Taxes for Seminar.

9. The system displays the fees via UI33 Display Seminar Fees Screen.

10. The system asks the student if she still wants to enroll in the seminar.

11. The student indicates she wants to enroll in the seminar.

12. The system enrolls the student in the seminar.

13. The system informs the student the enrollment was successful via UI88 Seminar Enrollment Summary Screen. 14. The system bills the student for the seminar, according to business rule BR100 Bill Student for Seminar.

15. The system asks the student if she wants a printed statement of the enrollment.

16. The student indicates she wants a printed statement.

17. The system prints the enrollment statement UI89 Enrollment Summary Report.

18. The use case ends when the student takes the printed statement.

Alternate Course A: The Student Is Not Eligible to Enroll in Seminars.

A.3. The registrar determines the student is not eligible to enroll in seminars.

A.4. The registrar informs the student she is not eligible to enroll.

A.5. The use case ends.

Alternate Course B: The Student Decides Not to Enroll in an Available Seminar

B.5. The student views the list of seminars and does not see one in which she wants to enroll.

B.6. The use case ends.

Alternate Course C: The Student Does Not Have the Prerequisites

C.6. The registrar determines the student is not eligible to enroll in the seminar she chose.

C.7. The registrar informs the student she does not have the prerequisites.

C.8. The registrar informs the student of the prerequisites she needs.

C.9. The use case continues at Step 4 in the basic course of action.

Note: Use Case A and B were modified from the forthcoming book, The Object Primer 3rd Edition: Agile Model Driven Development with UML 2. For more information, go to http://www.ambysoft.com/theObjectPrimer.html

NEWS AND VIEWS
Recently on the Agile Modeling Mailing List

>>Focus on Value, Not on Upsetting the UML Police This thread spilled over from a conversation about use cases on the RUP forum and motivated me to write this newsletter. The original poster and his team were struggling with the proper way to write use cases. Fundamentally, as the subject line suggests, they needed to focus on creating use cases that added value.

>>UML 2 Component and Deployment Diagrams
I've been posting overviews of a wide range of models at the Agile Models Distilled page for a while now. Two of the more recent pages described UML 2 Component Diagrams and UML 2 Deployment Diagrams, which I tend to use for architectural modeling. Various modeling techniques were discussed, as well as the uses for each diagram.

>>Modeling vs. Specifying
This conversation dealt with the challenges of people focusing on writing documentation instead of on modeling. Models and documents are orthogonal concepts -- models aren't necessarily documents, and documents aren't necessarily models. Although some documentation is required, too many people focus on creating documents instead of modeling and as a result forgo the benefits of modeling and eventually become embittered with the entire concept. I suspect that more developers would be interested in modeling if they were allowed to remain agile.

HOT LINKS
Recommended Online Resources

The Agile Alliance home page is the best starting point for anyone interested in learning more about agile software development.
http://www.agilealliance.org

Sign up for the Agile Modeling Mailing List at
http://www.agilemodeling.com/feedback.htm

Find agile modeling training resources at
http://www.agilemodeling.com/training.htm

Read Agile Models Distilled at
http://www.agilemodeling.com/artifacts/index.htm

Alistair Cockburn's home page is a great place to learn effective use-case writing techniques.
http://members.aol.com/acockburn

Enterprise Unified Process home page is the primary source for information about EUP and extensions to RUP.
http://www.enterpriseunifiedprocess.info

My article "Essential Use Cases Overview" provides a description of how to write technology-independent (a.k.a. essential) use cases.
http://www.agilemodeling.com/artifacts/essentialUseCase.htm

"Generalizing Specialists" argues that narrowly focused specialists are ineffective; instead, you should have one or two specialties, as well as general knowledge of software development.
http://www.agilemodeling.com/essays/generalizingSpecialists.htm

The ICONIX home page is the primary source for information about the ICONIX methodology, a lightweight, use case-driven software process.
http://www.iconixsw.com

Find RUP products at the Rational Unified Process home page.
http://www.rational.com/products/rup/index.jsp

Find a description of how to write system use cases at
http://www.agilemodeling.com/artifacts/systemUseCase.htm

A brief description about how to create UML 2 use-case diagrams is located at
http://www.agilemodeling.com/artifacts/useCaseDiagram.htm

Find a collection of style guidelines and standards for use-case diagrams at
http://www.modelingstyle.info/useCaseDiagram.html