Use case

From Wikipedia, the free encyclopedia

You have new messages (last change).

In software engineering and system engineering, a use case is a technique for capturing functional requirements of systems and systems-of-systems. According to Bittner and Spence, "Use cases, stated simply, allow description of sequences of events that, taken together, lead to a system doing something useful" [1]. Each use case provides one or more scenarios that convey how the system should interact with the users called actors to achieve a specific business goal or function. Use case actors may be end users or other systems. 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. Use cases are separate and distinct from UML use case diagrams, which allow one to abstractly work with groups of use cases.

Within system engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. The detailed requirements may then be captured in SysML requirement diagrams or similar mechanisms.

Contents

[edit] History

In 1986, Ivar Jacobson, later an important contributor to the Unified Modeling Language (UML) and Rational Unified Process, first codified the visual modeling technique for specifying use cases. Originally he used the terms usage scenarios and usage case, but found that neither of these terms sounded natural in English, and eventually he settled on the term use case[2]. Since Jacobson originated use case modeling many others have contributed to improving this technique, including Kurt Bittner, Alistair Cockburn, Gunnar Overgaard, and Geri Schneider.

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 oriented in nature.


Each use case focuses on describing how to achieve a goal or task. For most software projects this means that multiple, perhaps dozens, of use cases are needed to embrace the scope of 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.

Use cases should not be confused with the features of the system under consideration. A use case may be related to one or more features, a feature may be related to one or more use cases.

A use case defines the interactions between external actors and the system under consideration to accomplish a goal. An actor is a role that a person or thing plays when interacting with the system. The same person using the system may be represented as two different actors because they are playing different roles. For example, "Joe" could be playing the role of a Customer when using an Automated Teller Machine to Withdraw Cash, or playing the role of a Bank Teller when using the system to Restock the Cash Drawer.

Use cases treat the system as a black box, and the interactions with the system, including system responses, are perceived as from outside the system. This is a deliberate policy, because it forces the author to focus on what the system must do, not how it is to be done, and avoids the trap of making assumptions about how this functionality will be accomplished.

Use cases may be described at the abstract level (business use case, sometimes called essential use case), or at the system level (system use case). The differences between these is the scope.

  • The business use case is described in technology free terminology which treats the business process as a black box and describes the business process that is used by its business actors (people or systems) to achieve their goals (e.g., manual payment processing, expense report approval, manage corporate real estate.) The business use case will describe a process that provides value to the business actor, and it describes what the process does.
  • The system use cases are normally described at the sub process level (for example, create voucher) and specify the data input and the expected data response. The system use case will describe how the actor and the system interact. For this reason it is recommended that a system use case specification begin with a verb (e.g., create voucher, select payments, exclude payment, cancel voucher.)

A use case should:

  • describe how the system shall be used by an actor to achieve a particular goal.
  • have no implementation-specific language.
  • be at the appropriate level of detail.
  • Not include detail regarding user interfaces and screens. This is done in user-interface design.

[edit] Writing a use case

[edit] Degree of detail

Alistair Cockburn in Writing Effective Use Cases identifies three levels of detail in writing use cases:

[edit] 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 ..

[edit] 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.

[edit] 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.

[edit] Appropriate detail

Some software development processes do not require anything more than a simple use case to define requirements. However, some other development processes require detailed use cases to define requirements. The larger and more complex the project, the more likely that 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 summarize the business requirement from the point of view of users. However, later in the process, software developers need far more specific and detailed guidance.

Rational Unified Process invites developers to write a brief use case description in the use case diagram, with a casual description as comments and a detailed description of the flow of events in a textual analysis. All those can usually be input into the use case tool (e.g., a UML Tool, SysML Tool), or can be written separately in a text editor.

[edit] Use case templates

There is no standard template for documenting detailed use cases. There are a number of competing schemes, and individuals are encouraged to use templates that work for them or the project they are on. Standardization within each project is more important than the detail of a specific template. There is, however, considerable agreement about the core sections; beneath differing terminologies and orderings 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
  • Notes
  • Author and date

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

[edit] Use case name

The use case name provides a unique identifier for the use case. It should be written in verb-noun format (e.g., Borrow Books, Withdraw Cash), should describe a completable goal (e.g., Register User is better than Registering User) 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. Two to three words is the optimum length. If more than four words are proposed for the name, there is usually a shorter more specific name that could be used.

[edit] Iteration

Often an iteration section is needed to inform the reader of the stage a use case has reached. The initial use case developed for business analysis and scoping may well be very different from the 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.

[edit] Summary

The summary section is used to capture the essence of the use case 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. Ideally a summary is just a few sentences or a paragraph in length and includes the goal and principal actor.

[edit] 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. Where one or more preconditions are not met, the behavior of the use case should be considered indeterminate.

[edit] Triggers

The Triggers section describes the starting condition(s) which cause a use case to be initiated. This can be external, temporal or internal.

[edit] 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:

  1. The system prompts the user to log on.
  2. The user enters his name and password.
  3. The system verifies the login information.
  4. The system logs user on to system.


...and so on.

[edit] 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 alternative path would be:

  1. The system recognizes cookie on users machine.
  2. Go to step 4 (Main path)

An example of an exception path would be:

3. The system does not recognize user's logon information
4. Go to step 1 (Main path)

According to Anthony J H Simons and Ian Graham, alternate paths were not originally part of use cases. Instead, each use case represented a single user's interaction with the system. Or in other words, each use case represented one possible path through the system. Multiple use cases would be needed before designs based on them could be made. In this sense, use cases are for exploration, not documentation.

[edit] Postconditions

The post-conditions section summarizes the state of affairs after the scenario is complete. A scenario guarantees that its post-conditions are true at the end of the scenario.

[edit] 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, or across the entire business.

[edit] 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.

[edit] 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.

[edit] Use case notation

The relationship between use cases and actors are diagrammed using use case diagrams, a Unified Modeling Language-standardized notation originally based upon Ivar Jacobson's Objectory notation. SysML, a UML profile, uses the same notation at the system block level.

[edit] 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 proceeds. In some methodologies, they may begin as brief business use cases, evolve into more detailed system use cases, and then eventually develop into highly detailed and exhaustive test cases.

[edit] Benefits of use cases

Use cases are a mature model to capture 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 case modeling (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
  • Test Cases (System, User Acceptance and Functional) can be directly derived from the use cases
  • Use cases are critical for the effective execution of Performance Engineering

[edit] Limitations of use cases

Use cases have limitations:

  • Use case flows are not well suited to easily capturing non-interaction based requirements of a system (such as algorithm or mathematical requirements) or non-functional requirements (such as platform, performance, timing, or safety-critical aspects) These are better specified declaratively elsewhere.
  • Use cases templates do not automatically ensure clarity. Clarity depends on the skill of the writer(s).
  • There is a learning curve involved in interpreting Use Cases correctly, for both end users and programmers. Since there are no fully standard definitions of use cases, each group must gradually evolve its own interpretation.
  • Proponents of Extreme Programming often consider use cases too needlessly document-centric, preferring to use the simpler approach of a User story.
  • 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.
  • Use cases can be over-emphasized. In Object Oriented Software Construction (2nd edition), Bertrand Meyer discusses issues such as driving the system design too literally from use cases and using use cases to the exclusion of other potentially valuable requirements analysis techniques.

[edit] Software

See the list of UML tools.

[edit] References

  1. ^ Kurt Bittner, Ian Spence (2002). Use Case Modeling. Addison Wesley Professional, 2-3. 
  2. ^ Alistair Cockburn, "Use cases, ten years later"

[edit] See also

[edit] External links

Retrieved from "http://en.wikipedia.org../../../u/s/e/Use_case.html"