Use Case Diagram

Use Case Diagrams can be used to help visualise the story described in a Use Case. A Use Case Diagram consists of 3 components:

1. Actor – represented by a stick figure
2. Use Case Name – represented by an ellipse
3. Association – represented by a straight line that links an Actor with a Use Case Name

Example:

Conventions followed when creating a Use Case Diagram:

• The Use Case Name starts with a verb and (optionally) followed by a noun.
• The main / primary actor is usually drawn on the left and the supporting / secondary actor (if there is one) on the right.

Exercise

Course Registration

Task

Analyse the ‘Course Registration’ requirements above and represent them as a Use Case Diagram.

Example answer

Textual Use Case

A textual Use Case typically include:

• Use Case ID
• Use Case Name
• Actors (or Users)
• Description
• Pre-conditions
• Post-conditions
• Trigger
• Primary Flow
• Alternative Flows
• Exception Flows

The Primary Flow is usually quite simple and shows what normally occur in the most common scenario and when nothing out of the ordinary happens. Any possible variations to the normal story are then presented as Alternative Flows, while the Exception Flows describe what can go wrong and how the Use Case will handle it.

Example textual Use Case for ‘Register for Courses’:

Further Learning

In Use Case Diagrams, apart from the simple association there can also be other relationships between an Actor and a Use Case that you can show, such as Extend, Include and Generalisation.

In textual Use Cases, there can also be more complex requirements, possible alternatives and exceptions.

Learn further about Use Cases and more, by attending one of the following IRM Training’s hands-on courses:

• Business Analysis
• Writing Better Requirements

The post How to Create Use Cases appeared first on IRM Training.

While user stories do a great job of expressing functional (and often non-functional) requirements in words that business users can understand, that’s not the case for developers. Remember that a business analyst is the communicator between the business AND the developer. There just isn’t enough information in a user story for a developer to do their job.

So how do you get round this? For a really interesting discussion on this topic have a look at the following article Why I still use Use Cases by Alistair Cockburn. Alistair was one of the original signatories of the Agile Manifesto and his article includes observations on some of the key issues faced by organisations using agile methods.

WHY I STILL USE USE CASES

XP pretty much banned use cases, replacing them with the similar sounding “user stories” and as a result agile zealots have been happy to dump use cases in the trash (along with their project managers, estimates, plans, and architectures). Scrum did similar, using the “product backlog” instead of user stories. Yet as I go around projects, I keep running across organizations suffering from three particular, real, painful, and expensive problems:

1)   User stories and backlog items don’t give the designers a context to work from – when is the user doing this, and what is the context of their operation, what is their larger goal at this moment?

2)   User stories and backlog items don’t give the project team any sense of “completeness” – what I keep finding is that the development team bids/estimates the projects at (e.g.) 270 story points, and then as soon as they start working, that number keeps increasing, seemingly without bound. The developers are depressed and the sponsors are equally depressed by this. How big is this project, really?

3)   Related to completeness, user stories and backlog items don’t provide a good-enough mechanism for looking ahead at the difficulty of upcoming work (In principle they could, just in practice they don’t) – I keep hearing this complaint, “We asked our customer (product owner) a question and she/he took 2 weeks to get us an answer. We must have the wrong person in this role.” No, they don’t have the wrong person, they have a broken process – certain types of questions take a long time to research, as the various departments and user groups work out what is the correct, balanced answer for the whole lot of them. Staring at the set of extension conditions in a use case lets the analysts suss out which ones will be easy and which will be difficult, and to stage their research accordingly. User stories and backlog items are not set out in that granularity early enough on for that assessment – the extension conditions are usually detected mid-sprint, when it is too late.

Use cases are, indeed, heavier and more difficult than either user stories or backlog items, but they bring value for that extra weight. As not-Einstein said: “Make things as simple as possible, but no simpler.” (The attribution to Einstein has been debunked, it seems.)

In particular, use cases fix those three problems.

I’ve been testing this out for the last 3 years – I walk in and ask, “On your agile project(s), do you by any chance suffer from any of these three things?” … and then list the three … Much stronger than even I expect, there hasn’t been a single organization I asked these of that hasn’t said, “Oh, Yes, and How!”

In other words, naïve use of user stories and backlog items is causing very real, very expensive damage to companies. Expensive is bad.

The most recent was an executive who was telling about having “delivered” a Scrum project, but it was discovered at acceptance time that there were a whole series of recipients of the system whose needs hadn’t been identified at all. This company is now faced with writing what may amount to a fixed-price contract because the recipients aren’t sure they trust the company to deliver complete and useful software.

Very expensive, very bad. The time spent writing the use cases and doing a more thorough requirements investigation would have paid off handsomely, in this case.

Here 5 reasons why I still write use cases:

1)   The list of goal names provides executives with the shortest summary of what the system will contribute to the business and the users. It also provides a project planning skeleton, to be used to build initial priorities, estimates, team allocation and timing. It is the first part of the completeness question.

2)   The main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do, also, sometimes more importantly, what it will not do. It provides the context for each specific line item requirement, a context that is very hard to get anywhere else.

3)   The extension conditions of each use case provide the requirements analysts a framework for investigating all the little, niggling things that somehow take up 80% of the development time and budget. It provides a look ahead mechanism, so the customer / product owner / business analyst can spot issues that are likely to take a long time to get answers for. These issues can and should then be put ahead of the schedule, so that the answers can be ready when the development team gets around to working on them. The use case extension conditions are the second part of the completeness question.

4)   The use case extension scenario fragments provide answers to the many detailed, often tricky business questions programmers ask: “What are we supposed to do in this case?” (which is normally answered by, “I don’t know, I’ve never thought about that case.”) In other words, it is a thinking / documentation framework that matches the if…then…else statement that helps the programmers think through issues. Except it is done at investigation time, not programming time.

5)   The full use case set shows that the investigators have thought through every user’s needs, every goal they have with respect to the system, and every business variant involved. It is the final part of the completeness question. (And yes, I did indeed sit down and walk through 240 use cases with a client, at the end of which, I turned to her and asked: “And is that everything?” She said, Yes, and we built that, delivered it, got paid for it, and it is still in use ten years later.)

The are several sticky parts for people using use cases as I describe:

*   It is really easy to think all the use cases have to be written up front, when in fact the writing should be staged over the life of the project. The “thinking’ part here is working out how much should be written up front to get the project estimate into a safe place, and which parts can be deferred to just-in-time investigation.

*   These days, iteration/sprint lengths are so short that it is not practical to implement an entire use case in just one of them. That means additional work is needed, to create user stories or backlog items for each use case, track that each one get developed, and ensure that the complete set of user stories or backlog items do indeed deliver the subset of the use cases needed for the particular release.

*   Writing good use cases (or any other requirements) requires thinking, communicating, and thinking again. It is much easier just to write user-story tags on index cards and let the project blow up later.

If you don’t want to think, find a new profession. Software development requires thinking, at all levels.

This article reproduced with kind permission of Alistair Cockburn. To read this and other articles by Alistair go to http://alistair.cockburn.us/Why+I+still+use+use+cases

If you enjoyed this article, you may be also interested in these:

How to Use Use Cases

How to Write Use Cases

The post What Happens After User Stories? appeared first on IRM Training.

A typical business function might contain several unique events each of which we want to end up as a component of a larger software application.

So how do we go from a table containing textual information to a specification which a developer can use?

The first step is to turn each business event into a model – either a use case fragment, a DFD fragment or any modelling language you might be working with.

The following event table describes three typical interactions a customer would have with their bank:

Each of these events can be drawn as a separate use case:

These individual use cases (use case fragments) are only half the picture however. Today developers don’t write individual software programs for each event, particularly when multiple events will have numerous common components e.g. database enquiry, ID validation, etc.

What we do want is to be able to combine use case fragments into a single use case. We do this by identifying and sharing common actors (in this example the customer):

While we still need to write individual descriptions for each use case, we’ve given the developer a concise package of functional requirements, offering them the best opportunity to write efficient and effective code.

For an example of writing formal use cases see the paper How to use Use Cases.

The post Use Case Fragments appeared first on IRM Training.

The How to use Use Cases paper described a relatively simple event – a student registering for a course. Whilst the primary flow had 5 steps, the alternate flow in the formal (fully specified) use case involved 9 steps each comprising 3 or 4 interactions. The line by line description of the alternate flow ran to one full side of A4 paper and quickly became an exercise in concentration! So how else could we write it?

Read the full paper here: How to Write Use Cases

If you liked this paper, you may also enjoy:

Use Case Fragments

User Stories & The Jungle Book

What Happens After User Stories?

The post How to Write Use Cases appeared first on IRM Training.

When producing project documentation, use case diagrams are rarely used on their own. They will generally be accompanied by a textual use case and if they’re complex, may also have a supporting activity diagram to show what’s going on “inside” the use case.

To keep things simple we’ll stick to use case diagrams and textual use cases. Textual use cases can be both formal and informal. Try the following exercises (from IRM’s Modelling Requirements with Use Case & the UML workshop) to test your skills. First we’ll draw a use case diagram from a plain English description, then build on it using textual use cases.

Exercise 1 – Course registration

The following should be textually analysed and a use case diagram created containing several use cases. Identify the actors, use cases and associations.

At the start of each semester a student can request a prospectus containing a course list. Information about a course is provided, such as the tutor, department and pre-requisites.

The new system will allow students to create a schedule, then select four courses. Each student chooses two others in case their first choices become full or are cancelled. No course can have more than 10 students. No course can have less than 3 students or it will be cancelled. This will be the same functionality as available to other internal users of the system.

When registration is complete, the registration system sends a message to the billing system to send out a bill to the student.

Tutors use the system to find which classes they are teaching and who the students are. The registrar will administer the system.

For a period at the beginning of the semester the student can change their schedule. Students must be allowed to access the system during this time to add or delete courses.

Note: If you have some experience with use cases try drawing a suitable diagram. If you’re new to the field, see below for an example answer.

Exercise 1 – Example answer

Actors: Student, Tutor, Billing System, Registrar

Use Cases:

Student

• Register for courses

Tutor

• View teaching roster

Registrar

• Maintain course information
• Maintain student information
• Maintain tutor information
• Maintain curriculum
• Generate prospectus

For the rest of the exercises and PDF, download full paper here: How to use Use Cases

If you liked this paper, you may enjoy:

What Happens After User Stories?

Use Case Fragments

How to Write Use Cases

The post How to use Use Cases (With Examples) appeared first on IRM Training.