Home >Resources > Use Case Management

WHAT IS REQUIREMENTS MANAGEMENT

Requirements define capabilities that the system must deliver, and conformance or lack of conformance to a set of requirements often determines the success or failure of projects. It makes sense therefore to find out what the requirements are, write them down, organize them, and track them in the event that they change. Stated another way we'll define requirements mgmt as a systematic approach to eliciting, organizing, and documenting the requirements of a system.

STAKEHOLDER NEEDS

It is also our responsibility to understand the needs of users and other stakeholders whose lives will be affected by our solution. As we elicit those needs, we'll stack them in a little pile called stakeholder needs, which we represent as a pyramid.

FEATURES OF THE SYSTEM

Features should be stated as simple descriptions in the user's language that we will use as labels to communicate with the user how the system addresses the problem. These labels will become part of our everyday language, and much energy will be spent defining them. So the full definition of a feature is a service that the system provides to fulfill one more more of the stakeholder needs.

WHAT ARE SOFTWARE REQUIREMENTS

Once we have established the feature set and have gained agreement with the customer, we can move on to defining the more specific requirements that we will need to impose on the solution. If we build a system that conforms to those requirements, we can be certain that the system we develop will deliver the features we promised. In turn, since the features address one or more of the stakeholder needs, we will have addressed those needs directly in the solution.

These more specific requirements are the software requirements.

WHAT ARE ACTORS AND USE CASES?

Actors are basically users of the system. They are actually user types or categories. Actors are external entities (people or other systems) who interact with the system to achieve a desired goal. The use case diagram in Figure 1 provides an example of an UML use case diagram. Use case diagrams depict: Use cases. A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse. Actors. An actor is a person, organization, or external system that plays a role in one or more interactions with your system. Actors are drawn as stick figures. Associations. Associations between actors and use cases are indicated in use case diagrams by solid lines. An association exists whenever an actor is involved with an interaction described by a use case.

Creating Use Case Diagrams
I like to start by identifying as many actors as possible. You should ask how the actors interact with the system to identify an initial set of use cases. Then, on the diagram, you connect the actors with the use cases with which they are involved. If an actor supplies information, initiates the use case, or receives any information as a result of the use case, then there should be an association between them. I generally don’t include arrowheads on the association lines because my experience is that people confuse them for indications of information flow, not initial invocation. As I begin to notice similarities between use cases, or between actors, I start modeling the appropriate relationships between them (see the Reuse Opportunities section).

The preceding paragraph describes my general use case modeling style, an “actors first” approach. Others like to start by identifying one actor and the use cases that they’re involved with first and then evolve the model from there. Both approaches work. The important point is that different people take different approaches so you need to be flexible when you’re following AM’s practice of Model With Others.

Reuse Opportunities
Figure 4 shows the three types of relationships between use cases -- extends, includes, and inheritance -- as well as inheritance between actors. I like to think of extend relationships as the equivalent of a "hardware interrupt" because you don't know when or if the extending use case will be invoked (perhaps a better way to look at this is extending use cases are conditional). Include relationships as the equivalent of a procedure call. Inheritance is applied in the same way as you would on UML class diagrams -- to model specialization of use cases or actors in this case. The essay Reuse in Use Case Models describes these relationships in greater detail.

Staying Agile
So how can you keep use case modeling agile? First, focus on keeping it as simple as possible. Use simple, flexible tools to model with. I’ll typically create use case diagrams on a whiteboard, as you see in Figure 5 which is an example of an initial diagram that I would draw with my project stakeholders. AM tells us that Content is More Important Than Representation so it isn’t a big issue that the diagram is hand drawn, it’s just barely good enough and that’s all that we need. It’s also perfectly okay that the diagram isn’t complete, there’s clearly more to a university than what is depicted, because we can always modify the diagram as we need to.

Abstract
Use cases are wonderful but confusing. People, when asked to write them, do not know what to include or how to structure them. There is no published theory for them. This paper introduces a theory based on a small model of communication, distinguishing "goals" as a key element of use cases. The result is an easily used, scaleable, recursive model that provides benefits outside requirements gathering: goals and goal failures can be explicitly discussed and tracked; the goals structure is useful for project management, project tracking, staffing, and business process reengineering. The model and techniques described here have been applied and evaluated on a relatively large (50 work-year, 200 use-case) project.

USE CASE EXAMPLES, PLEASE!!!?!?!

Lets face it, reading definitions and definitions isn't going to make anyone an expert unless you truely understand the benefits and are able to apply it to the real world. What I'd like to get across is that there are REALLY ENORMOUS benefits to applying use cases to requirements management. The best way to understand use cases is to walk through a simple example and watch how it can be leveraged to something complex.

In the following sections, I'm going to walk you through a use case example of the Ebay site. Most of us know and love Ebay, so if you don't know Ebay, go to http://www.ebay.com and navigate through the site and come back to our example.

BENEFITS OF USE CASES

Use cases are a newer, more agile format for capturing software requirements. They are often contrasted to large, monolithic documents that attempt but fail to completely convey all possible requirements before construction of a new system begins.

Use cases have a number of advantages:

• Use case modelling (including the writing of use case specifications) is generally regarded as an excellent technique for capturing the functional requirements of a system.
• Use cases discourage premature design.
• Use cases are traceable.
• Use cases can serve as the basis for the estimating, scheduling, and validating effort.
• Use cases are reusable within a project. The use case can evolve at each iteration from a method of capturing requirements, to development guidelines to programmers, to a test case and finally into user documentation.
• Use case alternative paths capture additional behaviour that can improve system robustness.
• Use cases are useful for scoping. Use cases make it easy to take a staged delivery approach to projects; they can be relatively easily added and removed from a software project as priorities change.
• Use cases have proved to be easily understandable by business users, and so have proven an excellent bridge between software developers and end users.
• Use case specifications don't use a special language. They can be written in a variety of styles to suit the particular needs of the project.
• Use cases allow us to tell stories. It is very easy to describe a use case in a concrete way by turning it into a story or scenario.
• Use cases are concerned with the interactions between the user and the system. They make it possible for user interface designers to become involved in the development process either before or in parallel with software developers.
• Use cases put requirements in context, they are clearly described in relationship to business tasks.
• Use case diagrams help stakeholders to understand the nature and scope of the business area or the system under development.
• Use case diagrams can be recorded using the UML and maintained within widely available CASE tools
• Use cases and use case diagrams can be fully integrated with other analysis and design deliverables created using a CASE tool to produce a complete requirements, design and implementation repository

LIMITATIONS OF USE CASES

Use cases are not without their limitations:

• Use cases are not well suited to easily capturing non-functional requirements of a system.
• Use cases templates do not automatically ensure clarity. Clarity depends on the skill of the writer(s).
• Use cases are not well suited to safety critical and real time systems where a greater degree of precision is required.
• Use cases have a learning curve involved in interpreting them correctly, for both end users and programmers.
• Proponents of Extreme Programming often consider use cases too needlessly document centric, preferring to use the simpler approach of user stories.
• Use case developers often find it difficult to determine the level of user interface(UI) dependency to incorporate in the use case. While use case theory suggests that UI not be reflected in use cases, many find it awkward to abstract out this aspect of design as it makes the use cases difficult to visualize.