Requirements

Specification
Use Cases

There are two types of requirements:

1.Functional
In software engineering, a functional
requirement defines a function of a
software system or its component. A function is
described as a set of inputs, the behavior, and
outputs (see also software).
(http://en.wikipedia.org/wiki/Functional_requirement)

2. Non-functional
General system properties.
2

Functional Requirements

Functional requirements may be calculations, technical details, data

manipulation and processing and other specific functionality that define
what a system is supposed to accomplish. Behavioral requirements
describing all the cases where the system uses the functional
requirements are captured in use cases. Functional requirements are
supported by non-functional requirements (also known as quality
requirements), which impose constraints on the design or implementation
(such as performance requirements, security, or reliability). How a system
implements functional requirements is detailed in the system design.
As defined in requirements engineering, functional requirements specify
particular results of a system. This should be contrasted with
non-functional requirements which specify overall characteristics such as
cost and reliability. Functional requirements drive the application
architecture of a system, while non-functional requirements drive the
technical architecture of a system.
Typically, a requirements analyst generates use cases after gathering and
validating a set of functional requirements. Each use case illustrates
behavioral scenarios through one or more functional requirements.

(http://en.wikipedia.org/wiki/Functional_requirement)

Use Cases
What Is A Use Case?
A use case in software engineering and systems
engineering is a description of a systems behavior as
it responds to a request that originates from outside
of that system. In other words, a use case describes
"who" can do "what" with the system in question. The
use case technique is used to capture a system's
behavioral requirements by detailing scenario-driven
threads through the functional requirements.

(http://en.wikipedia.org/wiki/Use_case)

There are two ways of expressing a use case:

1. Use Case Briefs
2. Fully Dressed Use Cases
4

Use Case Briefs

A few sentences that outline the goal
of the use case and the behavior of
the actors and the system needed to
achieve that goal.

Fully Dressed Use cases

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.
(http://en.wikipedia.org/wiki/Use_case)

Typical Use Case Templates

IBM:

The sections of a use case

Name. The name should implicitly express the user's intent or purpose of the use case, such as "Enroll Student in Seminar."

Identifier [Optional]. A unique identifier, such as "UC1701," that can be used in other project artifacts (such as your class model)
to refer to the use case.

Description. Several sentences summarizing the use case.

Actors [Optional]. The list of actors associated with the use case. Although this information is contained in the use case itself, it
helps to increase the understandability of the use case when the diagram is unavailable.

Status [Optional]. An indication of the status of the use case, typically one of: work in progress, ready for review, passed review,
or failed review.

Frequency. How often this use case is invoked by the actor. This is often a free-form answer such as once per each user login or
once per month.

Preconditions. A list of the conditions, if any, that must be met before a use case may be invoked.

Postconditions. A list of the conditions, if any, that will be true after the use case finishes successfully.

Extended use case [Optional]. The use case that this use case extends (if any). An extend association is a generalization
relationship where an extending use case continues the behavior of a base use case. The extending use case accomplishes this by
inserting additional action sequences into the base use-case sequence. This is modeled using a use-case association with the
<<extend>> stereotype.

Included use cases [Optional]. A list of the use cases this one includes. An include association is a generalization relationship
denoting the inclusion of the behavior described by a use case within another use case. This is modeled using a use-case
association with the <<include>> stereotype. Also known as a uses or a has-a relationship.

Assumptions [Optional]. Any important assumptions about the domain that you have made when writing this use case. At some
point you should verify these assumptions and evolve them either into decisions (see below) or simply into parts of the basic
course or alternate courses of action.

Basic course of action. The main path of logic an actor follows through a use case. Often referred to as the happy path or the
main path because it describes how the use case works when everything works as it normally should.

Alternate courses of action. The infrequently used paths of logic in a use case, paths that are the result of an alternate way to
work, an exception, or an error condition.

Change history [Optional]. Details about when the use case was modified, why, and by whom.

Issues [Optional]. A list of issues or action items, if any, that are related to the development of this use case.

Decisions. A list of critical decisions, typically made by your SMEs, pertaining to the content of the use case. It is important to
record these decisions to maintain a group memory.
(http://www.ibm.com/developerworks/webservices/library/ws-tip-docusecase.html)

Typical Use Case Templates

Microsoft:
Version History
Contributors
Approval Signof
Use Case Information
Use Case #
Use Case Name
Purpose
Actor(s)
Assumption(s)
Pre-Condition(s)
Main case (Happy Path)
Alternate Path(s)
Exception Path(s)
Business Rules
Reference
Outstanding Issues
(office.microsoft.com/en-us/templates/TC300046141033.aspx)

Typical Use Case Templates

Wikipedia definition of use case template:
Use case name
Version
Goal
Summary
Actors
Preconditions
Trigger
Basic course of events
Alternative paths
Postconditions
Business rules
Notes
Author and date
(http://en.wikipedia.org/wiki/Use_case)

Use Case Sections

Use case name
A 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 an achievable 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 use cases according to the actor's goals, thus
ensuring use cases are strongly user centric. Two to
three words is the optimum. If more than four words
are proposed for a name, there is usually a shorter
and more specific name that could be used.
(http://en.wikipedia.org/wiki/Use_case)
10

Use Case Sections

Version
Often a version 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.
(http://en.wikipedia.org/wiki/Use_case)
11

Use Case Sections

Goal
Without a goal a use case is useless.
There is no need for a use case when
there is no need for any actor to
achieve a goal. A goal briefly
describes what the user intends to
achieve with this use case.
(http://en.wikipedia.org/wiki/Use_case)
12

Use Case Sections

Summary
A summary section is used to capture the
essence of a 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.
(http://en.wikipedia.org/wiki/Use_case)
13

Use Case Sections

Actors
An actor is someone or something outside the
system that either acts on the system a
primary actor or is acted on by the system a
secondary actor. An actor may be a person, a
device, another system or sub-system, or time.
Actors represent the different roles that
something outside has in its relationship with
the system whose functional requirements are
being specified. An individual in the real world
can be represented by several actors if they
have several different roles and goals in regards
to a system. These interact with system and do
some action on that.
(http://en.wikipedia.org/wiki/Use_case)
14

Use Case Sections

Preconditions
A preconditions section defines all the conditions that must be
true (i.e., describes the state of the system) for the trigger (see
below) to meaningfully cause the initiation of the use case. That
is, if the system is not in the state described in the preconditions,
the behavior of the use case is indeterminate. Note that the
preconditions are not the same thing as the "trigger" (see below):
the mere fact that the preconditions are met does NOT initiate the
use case. However, it is theoretically possible both that a use case
should be initiated whenever condition X is met and that condition
X is the only aspect of the system that defines whether the use
case can meaningfully start. If this is really true, then condition X
is both the precondition and the trigger, and would appear in both
sections. But this is rare, and the analyst should check carefully
that they have not overlooked some preconditions which are part
of the trigger. If the analyst has erred, the module based on this
use case will be triggered when the system is in a state the
developer has not planned for, and the module may fail or behave
unpredictably.
(http://en.wikipedia.org/wiki/Use_case)
15

Use Case Sections

Triggers
A 'triggers' section describes the event that causes the use case to
be initiated. This event can be external, temporal or internal. If the
trigger is not a simple true "event" (e.g., the customer presses a
button), but instead "when a set of conditions are met", there will
need to be a triggering process that continually (or periodically) runs
to test whether the "trigger conditions" are met: the "triggering
event" is a signal from the trigger process that the conditions are
now met. There is varying practice over how to describe what to do
when the trigger occurs but the preconditions are not met.
One way is to handle the "error" within the use case (as an
exception). Strictly, this is illogical, because the "preconditions" are
now not true preconditions at all (because the behavior of the use
case is determined even when the preconditions are not met).
Another way is to put all the preconditions in the trigger (so that the
use case does not run if the preconditions are not met) and create a
different use case to handle the problem. Note that if this is the local
standard, then the use case template theoretically does not need a
preconditions section!
16

Use Case Sections

Basic course of events
At a minimum, each use case should convey a
primary scenario, or typical course of events,
also called "basic flow", "happy flow" and
"happy path". 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 logon information,
4. The system logs user on to system.
(http://en.wikipedia.org/wiki/Use_case)
17

Use Case Sections

Alternative paths
Use cases may contain secondary paths or alternative scenarios, which are
variations on the main theme. Each tested rule may lead to an alternative path and
when there are many rules the permutation of paths increases rapidly, which can
lead to very complex documents. Sometimes it is better to use conditional logic or
activity diagrams to describe use case with many rules and conditions.
Exceptions, or what happens when things go wrong at the system level, may also be
described, not using the alternative paths section but in a section of their own.
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: "The system recognizes cookie on
user's machine", and "Go to step 4 (Main path)". An example of an exception path
would be: "The system does not recognize user's logon information", and "Go to step
1 (Main path)"
According to Anthony J H Simons and Ian Graham (who openly admits he got it
wrong - using 2000 use cases at Swiss Bank), alternative paths were not originally
part of use cases. Instead, each use case represented a single user's interaction with
the system. 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. An
Activity diagram can give an overview of the basic path and alternative path.
(http://en.wikipedia.org/wiki/Use_case)

18

Use Case Sections

Postconditions
The post-conditions section describes
what the change in state of the
system will be after the use case
completes. Post-conditions are
guaranteed to be true when the use
case ends.
(http://en.wikipedia.org/wiki/Use_case)
19

Use Case Sections

Business rules
Business rules are written (or unwritten) rules or
policies that determine how an organization conducts
its business with regard to a use case. Business rules
are a special kind of requirement. Business rules may
be specific to a use case or apply across all the use
cases, or across the entire business. Use cases
should clearly reference business rules that are
applicable and where they are implemented.
Business Rules should be encoded in-line with the
Use Case logic and execution may lead to different
post conditions. E.g. Rule2. that a cash withdraw will
lead to an update of the account and a transaction
log leads to a post condition on successful
withdrawal - but only if Rule1 which says there must
be sufficient funds tests as true.
(http://en.wikipedia.org/wiki/Use_case)
20

Use Case Sections

Notes
Experience has shown that however
well-designed a use case template is,
the analyst will have some important
information that does not fit under a
specific heading. Therefore all good
templates include a section (eg "Notes
to Developers") that allows lessstructured information to be recorded.
(http://en.wikipedia.org/wiki/Use_case)
21

Use Case Sections

Author and date
This section should list when a 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.
(http://en.wikipedia.org/wiki/Use_case)
22

Whats Expected of You

In this course we wont expect your use cases to include all the sections
of a professional fully dressed use case. We will expect, at a
minimum:
Use case name and number/identifier
Risk assessment
Importance assessment
Description/Summary
Actor(s)
Preconditions
Post-conditions/Success Guarantee
Basic Flow
Good to add but not required:
Minimum Guarantee
Goal/Actor Goals
23

Limitations of Use Cases

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 safetycritical aspects). These are better specified
declaratively elsewhere.
Use case templates do not automatically ensure
clarity. Clarity depends on the skill of the writer(s).
(http://en.wikipedia.org/wiki/Use_case)
24

Non-functional
Requirements
Non-functional requirements are general
system properties including:
1.Qualities of the system
2.Constraints on the system
These are often described as those
system properties that do not lend
themselves well to being described in a
use case.
25

Non-functional
Requirements
Non-functional Requirements should
not be specific and not vague
Whenever possible they should be
expressed in terms of a metric.
e.g. The system should have a MTTF of
48 hours.

26

Functional or Non-functional
1.
2.
3.
4.
5.
6.
7.

Response time
Ability to login
System and/or data security
Reliability
Useability
Adding a course
Maintainabitlity
27