Difference between revisions of "Use case approach"

Latest revision as of 21:19, 14 November 2013

In software engineering, a use case is a technique for capturing the potential requirements of a new system or software change. Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. Use cases are often co-authored by Business Analysts and end users.

In 1986, Ivar Jacobson, an important contributor to the UML and the Unified process, originated the concept of the use case. Jacobson's idea was influential and seminal. Numerous contributions have been made to the subject since then, but the most significant, influential and comprehensive, in terms of defining what use cases are and how to write them effectively, was provided by Alistair Cockburn, in his 2000 book Writing Effective Use Cases.

During the 1990s use cases became one of the most common practices for capturing functional requirements. This is especially the case within the object-oriented community where they originated, but their applicability is not restricted to object-oriented systems, because use cases are not object orientated in nature.

Scope and goals of a use case

Each use case focuses on describing how to achieve a single business goal or task. From a traditional software engineering perspective a use case describes just one feature of the system. For most software projects this means that multiple, perhaps dozens, of use cases are needed to fully specify the new system. The degree of formality of a particular software project and the stage of the project will influence the level of detail required in each use case.

A use case defines the interactions between external actors and the system under consideration to accomplish a business goal. Actors are parties outside the system that interact with the system; an actor can be a class of users, roles users can play, or other systems.

Use cases treat the system as a "black box", and the interactions with system, including system responses, are as perceived from outside the system. This is deliberate policy, because it simplifies the description of requirements, and avoids the trap of making assumptions about how this functionality will be accomplished.

A use case should:

describe a business task to serve a business goal
use no implementation-specific language
be at the appropriate level of detail
be short enough to implement by one software developer in a single release.

Writing a use case

Degree of detail

Alistair Cockburn in Writing Effective Use Cases identifies three degrees of detail in writing use cases.

Brief

A brief use case consists of a few sentences summarizing the use case. It is highly suitable to use a spreadsheet for planning software development. A brief use case can be easily inserted in a spreadsheet cell, and allows the other columns in the spreadsheet to record business priority, technical complexity, release number, etc

Casual

A casual use case consists of a few paragraphs of text, covering the items mentioned above, elaborating the use case in the form of a summary or story.

Detailed

A detailed or complex use case is a formal document based on a long template with fields for various sections; and it is the most common understanding of the meaning of a use case. Detailed use cases are discussed in detail in the next section on use case templates.

Appropriate detail

Some software development methodologies do not require anything more than a simple use case to define requirements. However, some other development methodologies require detailed use cases to define requirements. The larger and more complex the project, the more likely it will be necessary to use detailed use cases.

The level of detail in a use case often differs according to the progress of the project. The initial use cases may be brief; but as the development process unfolds the use cases become ever more detailed. This reflects the different requirements of the use case. Initially they need only be brief; because they are used to summarise the business requirement from the point of view of users. However, later in the process, software developers need far more specific and detailed guidance.

Use case templates

There is no agreed template for documenting detailed use cases. There is a number of competing schemes and individuals are encouraged to use templates that work for them or the project they are on. Standardization for each project is more important than the detail of a specific template. However, there is considerable agreement about the core sections; and so beneath different terminology and order there is an underlying similarity between most use cases.

Typical sections include:

Use Case Name
Iteration
Summary
Preconditions
Triggers
Basic course of events
Alternative paths
Postconditions
Business rules
Author and date

Different templates often have additional sections, e.g. assumptions, exceptions, recommendations, technical requirements. There may also be industry specific sections.

Use case name

The use case name provides a unique identifier for the use case. It should be written in the verb/noun format and should be sufficient for the end user to understand what the use case is about. Goal-driven use case analysis will name the use cases according to the Actor's goals thus ensuring use cases are strongly user centric.

Iteration

Often an iteration section is needed to inform the reader the stage a use case has reached. The initial use case developed for business analysis and scoping may well be very different to evolved version of that use case when the software is being developed. Older versions of the use case may still be current documents, because they may be valuable to different user groups. However, this can lead to discrepancies between versions, which is likely to create confusion.

Summary

The summary section is used to capture the essence of the scenario before the main body is complete. It provides a quick overview which is intended to save the reader from having to read the full contents of a use case to understand what the use case is about.

Preconditions

A preconditions section is used to convey any conditions that must be true when a user initiates a use case. They are not however the triggers that initiate a use case.

Triggers

The Triggers section describe the starting condition(s) which cause a use case to be initiated.

Basic course of events

At a minimum, each use case should convey a primary scenario, or the typical course of events. The main basic course of events is often conveyed as a set of usually numbered steps, for example:

The system prompts the user to logon.
The user enters his name and password.
The system verifies the login information.
The system logs user on to system.
...

Alternative paths

Use cases may contain secondary paths, or alternative scenarios which are variations on the main theme. Exceptions, or what happens when things go wrong, may also be described, either within the alternative paths section or in a section on their own. The alternative paths make use of the numbering of the basic course of events to show at which point they differ from the basic scenario, and if appropriate where they rejoin. The intention is to avoid repeating information unnecessarily.

An example of an exception path would be:

3. The system does not recognize users logon information

4. Go to step 1 (Main path)

Postconditions

The post-conditions section summarizes the state of affairs after the scenario is complete.

Business rules

Business rules are written or unwritten rules that determine how an organization conducts its business with regard to a use case. Business rules are a special kind of assumption. Business rules may be specific to a use case or apply across all the use cases.

Notes

Experience has shown that whatever template is used, analysts discover there is always important information that doesn't fit the structure of the template. Therefore each template usually includes a section for such seemingly inevitable information.

Author and date

This section should list when this version of the use case was created and who documented it. It should also list and date any versions of the use case from an earlier stage in the development which are still current documents. The author is traditionally listed at the bottom, because it is not considered to be essential information; use cases are intended to be collaborative endeavors and they should be jointly owned.

Use cases and the development process

The specific way use cases are used within the development process will depend on which development methodology is being used. In certain development methodologies a brief use case survey is all that is required. In other development methodologies the use cases evolve in complexity and change in character as the development process proceeeds. In some methodologies they may begin as brief business use cases evolve in more detailed system use cases and then eventually develop into highly detailed and exhaustive test cases.

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 cases have proved to be easily understandable by business users, and so have proven an excellent bridge between software developers and end users.
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 are traceable.
Use cases can also serve as the basis for the estimating, scheduling, and validating effort.
Use cases discourage premature design.
Use cases don't use a special language.
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 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 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 alternative paths capture additional behaviour that can improve system robustness.

Limitations of Use Cases

Use cases are not without their limitations:

Use cases may be excellent for capturing the functional requirements of a system, but they are not so suited to easily capturing the non-functional requirements. Despite the overenthusiastic claims of some use case proponents, other methods are required to capture non-functional requirements.
Use cases templates do not automatically ensure clarity. Clarity depends on the skill of the writer.
Use cases are not as easy to understand as proponents suggest. There is a learning curve involved in learning to interpret them correctly for end users and programmers alike.
Proponents of extreme programming often consider use cases too needlessly document centric, preferring to use the simpler approach of user stories.
Use cases have been criticized by usability designers for introducing user interface design too early in the process. Given that use cases describe the interaction between a user and the system, there is obviously overlap with user interface design. Poorly written use cases can encode overly detailed and arbitrary user interface design in their descriptions of interactions, even though one of the principles of use cases is that implementation specific information should not be added.

Use Case Approach Process

The Use-Case Driven Approach to requirements Engineering can be described as a process consisting of two main phases: the Inception phase, where all the requirements are gathered from the client and various other stakeholders, and the elaboration phase, where the elicited requirements are analyzed and a model of the problem is developed using UML diagrams. For certain kinds of simple projects, the elaboration phase can be extended to specifications by providing sufficient details in the UML diagrams.

Inception Phase

Project description agreement: Writing of a general and simple project description agreement, describing the problem to be solved, and the key features of the system. Identification of the main problem and its root causes. This description hould not describe solutions, but only the problem to be solved. The size of this description can range from a paragraph to a couple of pages for a complex project. Every stakeholder has to agree on the project description, because this will give very important directions for the whole system development.

Project risks: Risks are factors influencing the complexity or size of the system, and whose magnitude is unknown. To identify risks, it is very important to look at the system from many different viewpoints. These viewpoints can be other systems that have to interact with the new system, marketing, technology constraints, users, managers. The main goal of this activity is to identify things that can go wrong, e.g. user resistance, inexperienced developers, system dependencies, etc.

Context of the project: Definition of what is inside the system, or system functionalities. These are represented as use cases in the UML. Also, a definition what is outside the system and interacts with the system. These are represented as actors in the UML. Actors can either be external systems, or system users.

Scope of the project: Estimation of what could realistically be implemented considering factors such as the time frame or budgetary envelope available; physical resources available. Some of these constraints can come into conflict with the system description and risk analysis. Care has to be taken to resolve these conflicts, because it is normally where there are conflicts that most problems emerge.

Elaboration Phase

Define use cases as textual scenarios: A use case a coherent unit of externally visible functionality provided by a system unit. it is used to define a behavior without revealing the internal details. A use case describes what the system does, not how it does it. Each use case is described in details using scenarios, i.e. a flow of events describing how a use case is realized. Each use case has a primary scenario, and eventually also has a set of alternate scenarios for all possible events, user actions or situations diverging from the primary scenario. Pre-conditions and post-conditions of the use case can also be stated to provide more detailed use case specifications and applicability.

Refine use cases description using the UML: Complex scenarios are better expressed using diagrams. The UML provides three kinds of diagrams:

Activity diagram: For a high-level description of scenarios using abstract objects collaborating to solve the problem represented by the use- case.
Sequence diagrams: For more in-depth analysis describing the timely interaction of the system with its environment.
Use case diagrams: A high level diagram showing use cases and their relationships with actors and other use cases. Use case diagrams have two main roles: (1) to model the context of the system, by defining what are the actors and how they interact with the system and (2) to depict the functional requirements of the system, i.e. to define what the system should do from an external point of view.

Software

References

Wikipedia:Use case