Use case

From Wikipedia, the free encyclopedia

Jump to: navigation, search

A use case in software engineering and systems engineering is a description of a potential

series of interactions between a software module and an external agent, which lead the
agent towards something useful.[1] Uses cases are used as a software modeling technique
that helps developers determine which features to implement, and determine how to
gracefully resolve errors.[2]

Within systems 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.

(Note that the "use" in "use case" is pronounced as the English noun /ˈjuːs/, not the English
verb /ˈjuːz/. Rephrased: this is a case of its use, not a case of using it.)

Contents
[hide]

 1 History
 2 Use cases and the development process
 3 Use case focus
 4 Degree of detail
 5 Actors
 6 Business vs. System Use Cases
 7 Use case notation
 8 Limitations
 9 See also
 10 References
 11 Further reading
 12 External links
 13 Requirement Management Tools

[edit] History
In 1986, Ivar Jacobson, later an important contributor to both the Unified Modeling
Language (UML) and the Rational Unified Process (RUP), first formulated the textual,
structural and visual modeling techniques for specifying use cases. The use case technique
became popular through Jacobson's 1992 book Object-Oriented Software Engineering - A
Use Case Driven Approach, co-authored with Magnus Christerson, Patrik Jonsson and
Gunnar Overgaard. Originally he used the terms usage scenarios and usage case, which
were the more correct translations of the Swedish word "användningsfall" he used, but
found that neither of these terms sounded natural in English, and eventually he settled on
the term use case.[3] Since Jacobson originated use case modeling many others have
contributed to improving this technique, including Kurt Bittner, Ian Spence, Alistair
Cockburn, Gunnar Overgaard, Karin Palmquist, Patrik Jonsson, Magnus Christerson 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.

[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[which?], a
brief use case survey is all that is required. In other development methodologies[which?], use
cases evolve in complexity and change in character as the development process proceeds.
Use cases can be a valuable source of usage information and usage testing ideas. [4] 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] Use case focus

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

Use cases should not be confused with the features of the system. One or more features
(a.k.a. "system requirements") describe the functionality needed to meet a stakeholder
request or user need (a.k.a. "user requirement"). Each feature can be analyzed into one or
more use cases, which detail cases where an actor uses the system. Each use case should be
traceable to its originating feature, which in turn should be traceable to its originating
stakeholder/user request.

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 making assumptions about how the functionality will be accomplished.

A use case should:

 Describe what the system shall do for the actor to achieve a particular goal.
  Include 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, which references the use case and its business rules.

[edit] Degree of detail

Alistair Cockburn, in Writing Effective Use Cases, identified three levels of detail in
writing use cases:[5]

 Brief use case -- consists of a few sentences summarizing the use case. It can be
easily inserted in a spreadsheet cell, and allows the other columns in the spreadsheet
to record priority, duration, a method of estimating duration, technical complexity,
release number, and so on.
 Casual use case -- consists of a few paragraphs of text, summarizing the use case.
 Fully dressed use case -- a formal document based on a detailed template with fields
for various sections; and it is the most common understanding of the meaning of a
use case. Fully dressed use cases are discussed in detail in the next section on use
case templates.

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
even 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.

The 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] Actors
A use case defines the interactions between external actors and the system under
consideration to accomplish a goal. An actor specifies a role played by a person or thing
when interacting with the system.[6] The same person using the system may be represented
as different actors because they are playing different roles. For example, user "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.
[edit] Business vs. System Use Cases
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.

 A business use case is described in technology-free terminology which treats

system as a black box and describes the business process that is used by its business
actors (people or systems external to the process) 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. Business Process Mapping is another
method for this level of business description.
 A system use case describes a system that automates a business use case or process.
It is normally described at the system functionality level (for example, "create
voucher") and specifies the function or the service that the system provides for the
actor. The system use case details what the system will do in response to an actor's
actions. For this reason it is recommended that system use case specification begin
with a verb (e.g., create voucher, select payments, exclude payment, cancel
voucher). An actor can be a human user or another system/subsystem interacting
with the system being defined.

[edit] Use case notation

In Unified Modeling Language, the relationships between all (or a set of) the use cases and
actors are represented in a use case diagram or diagrams, originally based upon Ivar
Jacobson's Objectory notation. SysML, a UML profile, uses the same notation at the system
block level.

[edit] Limitations
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 case 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 developers. As there are no fully standard definitions of use cases, each
group must gradually evolve its own interpretation. Some of the relations, such as
extends, are ambiguous in interpretation and can be difficult for stakeholders to
understand.
  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 a use case. While use case theory suggests that
UI not be reflected in use cases, it can be awkward to abstract out this aspect of
design, as it makes the use cases difficult to visualize. Within software engineering,
this difficulty is resolved by applying requirements traceability through the use of a
traceability matrix.
 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.
 Use cases have received some interest as a starting point for test design.[7] Some use
case literature, however, states that use case pre- and postconditions should apply to
all scenarios of a use case (i.e., to all possible paths through a use case) which is
limiting from a test design standpoint. If the postconditions of a use case are so
general as to be valid for all possible use case scenarios, they are likely not to be
useful as a basis for specifying expected behavior in test design. For example, the
outputs and final state of a failed attempt to withdraw cash from an ATM are not the
same as a successful withdrawal: if the postconditions reflect this, they too will
differ; if the postconditions don’t reflect this, then they can’t be used to specify the
expected behavior of tests. An alternative perspective on use case pre- and
postconditions more suitable for test design based on model-based specification is
discussed in.[8]
 Some systems are better described in an information/data-driven approach than in a
the functionality-driven approach of use cases. A good example of this kind of
system is data-mining systems used for Business Intelligence. If you were to
describe this kind of system in a use case model, it would be quite small and
uninteresting (there are not many different functions here) but the set of data that the
system handles may nevertheless be large and rich in details.

[edit] See also

Software Testing portal

 Business case
 List of UML tools
 User story
 Use case diagram
 Misuse case

[edit] References
 1. ^ Bittner, Kurt & Spence, Ian (2003). Use case modeling. Addison-Wesley. p. xvi.
ISBN 9780201709131. http://books.google.com/books?id=bD0VNcVjIp0C&pg=PR16.
2. ^ Adolph, Steve et al. (2002). Patterns for effective use cases. Addison-Wesley. p. 2.
ISBN 9780201721843. http://books.google.com/books?id=FGdXBs5uCxMC&pg=PA2.
3. ^ Alistair Cockburn, "Use cases, ten years later"
4. ^ Gelperin, David. "Precise Use Cases".
http://www.methodsandtools.com/archive/archive.php?id=8. Retrieved 8 February 2011.
5. ^ A. Cockburn (2001). Writing Effective Use Cases. Boston, MA, USA: Addison-Wesley
Longman Publishing Co., Inc. ISBN 0-201-70225-8.
6. ^ http://www.omg.org/docs/formal/07-02-03.pdf §16.3.1
7. ^ Frank Armour and Granville Miller (2000). Advanced Use Case Modeling: Software
Systems. Addison-Wesley Professional. ISBN 0201615924.
8. ^ Richard Denney (2005). Succeeding with Use Cases: Working Smart to Deliver Quality.
Addison-Wesley Professional. ISBN 0321316436.

[edit] Further reading

 Jacobson I., Christerson M., Jonsson P., Overgaard G., Object-Oriented Software
Engineering - A Use Case Driven Approach, Addison-Wesley, 1992.
 Alexander I., Maiden N. Scenarios, Stories, Use Cases. Wiley 2004. ISBN
0470861940.
 Aurum A. Cox, K. and Jeffery. An experiment in inspecting the quality of usecase
descriptions. Journal of Research and Practice in Information Technology,
36(4):211–229, 2004.
 Phalp K. Cox, K. and M. Shepperd. Comparing use-case writing guidelines. roc.
Workshop on Requirements Engineering: Foundation of Software Quality
(REFSQ’01), pages 101–112, 2001.
 Colom J.M. Ezpeleta, J. and J. Martinez. Comparing use-case writing guidelines. A
Petri net based deadlock prevention policy for flexible manufacturing systems,
11(2):173–184, 1995.
 E. B. Fernandez and J. C. Hawkins. Determining role rights from use cases. In
RBAC ’97: Proceedings of the second ACM workshop on Role-based access
control, pages 121–125, New York, NY, USA, 1997. ACM Press.
 R. Hurlbut. A survey of approaches for describing and formalizing use-cases.
Technical Report 97– 03, Department of Computer Science, Illinois Institute of
Technology, USA., 1997.
 Woo Jin Lee, Sung Deok Cha, and Yong Rae Kwon. Integration and analysis of use
cases using modular petri nets in requirements engineering. IEEE Trans. Softw.
Eng., 24(12):1115–1130, 1998.
 F. Torner, M. Ivarsson, F. Pettersson, and P. Ohman. Defects in automotive use
cases. In ISESE ’06: Proceedings of the 2006 ACM/IEEE international symposium
on International symposium on empirical software engineering, pages 115–123,
New York, NY, USA, 2006. ACM Presss.