Transcript Requirements Specification with Use Cases

Requirements Specification with Use Cases
* These notes are a combination of materials from Rational Software Corp., Alistair Cockburn,
Dr. Harry Koehnemann, and my annotations
What is a Use Case?
System behavior is how a system acts and reacts
 The outwardly visible & testable activity of a system
System behavior is captured in use cases.
View Report
Card
 Use cases describe the system, its environment,
and the relationship between the system and its
environment.
The Use Case Model
 A model that describes a system’s functional reqs
in terms of use cases
 A model of the system’s intended functionality (use
cases) and its environment (actors)
 Each use case is a container for one or more
related scenarios describing system usage.
DEFINITION (p. 149):
“A use case describes sequences of
eventsbetween an actor and a system that
yield a result of value to the actor”
Student
Register for
Courses
Login
A Scenario Is a Use-Case Instance
Student
Scenario 1
Log on to system.
Approve log on.
Enter subject in search.
Get course list.
Display course list.
Select courses.
Confirm availability.
Display final schedule.
Register for
Courses
Course Catalog
System
Scenario 2
Log on to system.
Approve log on.
Enter subject in search.
Invalid subject.
Re-enter subject.
Get course list.
Display course list.
Select courses.
Confirm availability.
Display final schedule.
Use Case Scenarios and Specifications
Specification: A structured natural language narrative that identifies:
 Objective: Every use case must have a goal the Primary Actor is trying to
achieve
 Primary Actor: one who performs the trigger event
 Trigger Event: an event that causes the system to respond
 Secondary Actor(s): participate in interactions in the use case; often a system
 Business Rules / Constraints: as they apply; often promoted to the
Supplementary Specification
 Pre/Post Conditions: predicates that must exist before/after the Happy Day case
 One or more scenarios…
A scenario is an instance of a use case
The normal basic flow called the “Happy Day” case
A use case may have several alternative flows
 Regular variants
 Exceptional flowshandling error situations
Copyright © 2000 Rational Software, all rights reserved
4
Use Case Model +
Use-Case Model
Glossary
Actors
Use Cases
...
Supplementary
Specification
Use-Case Specifications
Object Oriented Analysis and Design Using the UML v2000
Copyright © 2000 Rational Software, all rights reserved
Glossary and Supplementary Specification
Course Registration System Glossary
1.
Introduction
This document is used to define terminology specific to the problem domain, explaining terms, which
may be unfamiliar to the reader of the use-case descriptions or other project documents. Often, this
document can be used as an informal data dictionary, capturing data definitions so that use-case
descriptions and other project documents can focus on what the system must do with the information.
2.
Definitions
The glossary contains the working definitions for the key concepts in the Course Registration System.
Glossary
2.1
Course:
A class offered by the university.
Course Offering: A specific delivery of the course for a specific semester – you could run the
same course in parallel sessions in the semester. Includes the days of the week and times it is offered.
2.2
2.3
Course Catalog: The unabridged catalog of all courses offered by the university.
(FURPS model)





Supplementary
Specification
Functionality*
Usability
Reliability
Performance
Supportability
Design constraints…etc.
Since the focus is on the what
(functionality), you can use use cases
even if you are not doing OO
The Use Case Model
A Use Case Model Consists of:
1. Use Case Diagram: Actors, Use Cases, Use Case Relationships
2. Use Case Specification: A textual description of the use cases
A use case diagram:
 A use case diagram uses use cases, actors and use case
relationships to define a system's behavior
 Defines what a system (subsystem, class, or interface) does.
 Defines system communication with its environment, as
represented by actors.
 Does NOT define how a system operates or imply sequence.
Use Case Notation: Actor
“An actor defines a coherent set of roles that users of an
entity can play when interacting with the entity” – UML
 Representing something outside the system that interacts with it
Represented as a “stick man” figure
 By definition, an actor is a stereotyped class where the stick man
icon is used for graphical representation
<<Actor>>
Another Actor
AnActor
Notation: Use Case
“A coherent unit of functionality provided by a system, a subsystem, or
a class as manifested by sequences of messages exchanged
among the system (subsystem, class) and one or [actors] together
with actions performed by the system (subsystem, class)” -- UML
Represented as an ellipse containing the use case name
 Optional:
• Extension points
• [As a classifier] Compartments for attributes and operations
ReceiveCall
ManagePhonebook
Notation: Communicates-Association
A channel of communication between an
actor and a use case.
Actor 1
A line is used to represent a
communicates-association.
Use Case
Actor 2
Actor 3
 An arrowhead indicates who initiates each
interaction.
 No arrowhead indicates either end can
initiate each interaction.
Use Case Template Example
USE CASE <<Enter Use Case Number>>: <<Use Case Title>>
Objective:<<Enter the goal of the use case>>
Primary Actor:<<Enter ID and Name of Actor causing the Trigger event>>
Trigger: <<Action performed by the Primary Actors>>
Secondary Actors:<<actors affected by the outcome or secondary participants (not causing the Trigger)>>
Preconditions:<<The state of the environment required in order to activate this use case.>>
Post Condition(s):<<Enter the expected resulting state from the Main Success Scenario.>>
MAIN SUCCESS SCENARIO
<<Enter a numbered list of interactions needed to achieve the objective of the use case>>
Extension Points:<<Often identified inline; alternatively may be catalogued in its own subsection>>
Variations
Variation ID:<<Enter variation ID, should be UC-ID plus a VAR-XX suffix>>
<<Enter numbered list of variations to the steps in the main process above. Indicate whether the variation is an addition,
replacement, or removal of interactions from main flow>>
<<If the variation requires different preconditions or affects changes in the postconditions, be sure to note the changes here.
Typically neither is required for a non-failure variation, though sometimes there are additional pre/postconditions.>>
Failure Variations
Variation ID:<<Enter variation ID, should be UC-ID plus a VAR-XX-F suffix>>
<<Enter bulleted list of possible variations to the steps in the main process above>>
<<Indicate the postconditions associated with this negative outcome, and whether the use case is reentrant (you can repeat
subflows or main success scenario or some alternate action as recovery)>>
Business rules
<<Enter Business Rules. If they are applied across more than 1 use case then they are moved to the catalog area.>>
Notes:<<free form text here. Note this must not have requirements, but is usually more explanatory>>
11
Avoid Functional Decomposition
Functional Decomposition: Breaking down a problem into small, isolated
parts. The parts work together to provide the functionality of the system.
• Often do not make sense in isolation.
Use cases are NOT functional decomposition.
• Keep functionality together to describe a complete use of the system.
• Provide context.
• FOCUS ON THE USER’S GOAL
Symptoms
 Very small use cases
 Too many use cases
 Uses cases with no result of
value
 Names with low-level
operations
• “Operation” + “object”
• “Function” + “data”
• Example: “Insert Card”
 Difficulty understanding the
overall model
Corrective Actions
 Search for larger context
“Why are you building this system?”
 Put yourself in user’s role
“What does the user want to achieve?”
“Whose goal does this use case
satisfy?”
“What value does this use case add?”
“What is the story behind this use
case?”
Functional Decomposition Example
Insert Card
Process Transaction
Bank
Consortium
Enter PIN
Select Transfer Funds
Select “To” Account
Customer
Enter Amount
Select “From” Account
Select Withdraw Cash
Select Account Balance
Functional Decomposition Example
A Corrected Example
Withdraw Cash
Transfer Funds
BankConsort
ium
Customer
Deposit Funds
How to do it:
Step 1. Identify and Describe the Actors
Identify actors and their needs
 What computers, subsystems and people will drive our system?
• An “actor” is anything that interacts with the system.
 Result: a list of actors
Step 2. Identify the Use Cases and write a brief description
 What does each actor need our system to do?
• Each need shows up as a result in our system.
• You are still breadth-oriented for now
 Important to have a name and a description of each use case, but
nothing more (yet)
 At this point you can have high-level “bubble diagram”
 RESULT: Catalog of current use cases
Combined from Leffingwell & Widrig 2nd ed. And Humans and Technology, Alistair Cockburn
How to do it:
Step 3. Identify Actor to Use Case relationships
 Use cases may involve multiple actors
 Use cases may affect multiple actors (indirectly)
 RESULT: Catalog with full scope identified
Step 4. Outline the Individual Use Cases
For each use case, write the simple case: goal delivers.
 The main success scenario, the “happy day” case.
• Easiest to read and understand.
• Everything else is a complication on this.
 Capture each actor’s intent & responsibility, from trigger to
completion
• Say what information passes between them.
• Number each line.
 Result: readable description of system’s functions.
Combined from Leffingwell & Widrig 2nd ed. And Humans and Technology, Alistair Cockburn
How to do it:
Step 5. Refine the Use Cases
 Identify alternate scenarios
• Alternate success scenarios
– Scenarios that may not be common but are not unexpected
• Failure scenarios
– Usually, each step can fail.
– Also need to consider what happens if a precondition does not hold
• Result: list of alternate scenarios per use case.
Step 6. Verify & Validate the Use Cases (not in text)
 Did you get all of the use case?
 Are they (especially the highest priority ones) all correct?
 RESULT: A complete set of Use Cases with customer, user, all
stakeholder buy-in.
Combined from Leffingwell & Widrig 2nd ed. And Humans and Technology, Alistair Cockburn
Use Case Guidelines
Use Case Development is an iterative process
 Steps 1-3 in particular focus on the breadth of the catalog
 Steps 4-5 focus on depth of prioritized use cases in the catalog
 Note: Other parallel activities can and should be going on:
• UI prototyping
• Architecture document drafts and initial interface code
• Resource planning, scheduling, etc.
A well-structured use case diagram:
 Communicates a single aspect of a system's use case view.
 Contains only use cases and actors essential to understanding that
aspect of the systems behaviour that the diagram is modelling.
 Is consistent in its level of abstraction.
 Is not so minimalistic as to misinform the reader
• this is NOT just for developers)
Dr. Gary’s Use Case Tips
Use Case No-No’s
 Use cases are not “flowcharts”!
 Do not use in isolation!
Do your Use Cases in “phases”
 The 6 steps from before – “lather, rinse, repeat”
 After identifying a full catalog of refined use cases, you can start to
“factor” your use cases
Factoring use cases
 Use cases so far are independent
• Document use case as a statement of user need
• Have not yet discussed how they relate to each other
 Use case “analysis”
• Considers how use cases relate to each other
• Begins to partition the problem space
 I suggest 2 use case models, one after elicitation (SRS), then
another at the start of analysis (Architecture doc)
Use Case Process: Moving to Analysis
Use cases so far are independent
 Document use case as a statement of user need
 Have not yet discussed how they relate to each other
 Use caseanalysis:considers how use cases relate to each other
• Begins to partition the problem space
 I suggest 2 use case models, one after elicitation, then another at
the start of analysis
So where are we going?
 UCs have so far been developed independently
 We need to start identifying how these UCs overlap
UC1
UC1: Preview Exam
UC2: Take Exam
UC3: Take Pretest
Actor: Professor
Actor: Student
Actor: Student
1.
2.
3.
4.
5.
6.
1.
2.
3.
4.
5.
6.
1.
2.
3.
4.
5.
6.
7.
Login
Go to gradebook
Select exam
Review scores
View questions
Blah blah…
20
Login
Answer questions
Submit
Review score
View questions
Blah blah…
Login
Answer questions
Submit
Review score
View questions
Receive remediation
Blah blah…
<<e>>
Review
scores
UC2
<<i>>
UC3
Login
Use Case Relationships
You may find:
 Some use cases share common subsets of behavior
 Some use cases have several modes or special cases
 Some use cases have multiple flows (extensions or variants) you
would like to show in the use case diagram
 Some actors are specializations of other actors
What do you do?
 Identify and factor these behaviors into use cases that are related to
one another
 Create actor specializations/generalizations
“The purpose of use case relationships is to provide your system’s
designers with some architectural guidance so they can efficiently break
down the system’s concerns into manageable pieces” - Learning UML 2.0
Notation: Use Case Relationships
Use Case relationships
 Dependency
• plus stereotypes <<includes>> and <<extends>>
 Generalization
Dependency
 General UML notation
 A change in the specification of one model element may imply a
change in another model element
Notation: Use Case Relationships
<<include>>
 A stereotype of a dependency
 the behavior of B is included into A
 the included use case is necessary to ensure the functionality of the
base use case.
 typically there are multiple use cases that include B
 B does not require a Primary Actor, but it does require a triggering
event.
 Ex: “Authentication processes must include fingerprint verification”
Notation: Use Case Relationships
<<extend>>
 A stereotype of a dependency
 behavior of B may be incorporated into A
• the extending use case is used to add specialized behavior to the base use case.
• The base use case defines where it can be extended through an extension point
 Is often confused with use case generalization
• <<extend>> indicates an optional extension to a use case
• So, it is a bit of a cross between <<include>> and generalization
– Reusable specialization of a use case
 Ex: “An authentication process after 5pm may be logged in the
security logbook”
Notation: Use Case Relationships
Generalization
 B inherits the behavior of A and is allowed to override and extend it.
 B inherits the communication relationships of A.
 Actors may apply Generalization as well
 Ex: “A level 2 authentication process conforms to all constraints of a
level 1 process yet also requires a retinal scan”
Student
Graduate
Student
How would you read this diagram?
View Report Card
<<extends>>
Student
Register for Course s
Course Catal og
Login
Select Courses to Teach
Professor
View Grades
Submit Grades
Registrar
Mai ntain Profe ssor In formatio n
Maintain Person
Information
Mai ntain Student Inform ati on
Close Registration
Bi lli ng Syst em
Dr. Gary’s Tips
When do you use Includes, Extends, Generalization?
• Actors
 A generalization is typically used to specialize a particular subtype
(e.g. Graduate Student is-a Student)
 Remember actors are stereotypes classes, so it is possible to use
Associations of any type
• For example, a member of a group
• Use Case relationships
 <<include>> and <<extend>> are relationships between 2 distinct
use cases (instance-level, not type-level)
 Be careful of their direction - it is not flow!
 Generalization means one use case, which specializes a given use
case’s behavior (type-level, not instance-level)
Use Case Scoping Constructs
Use Case Scope
 We have relationships between use cases but no means by which
to collect related use cases into partitioned modules
 UML provides two constructs: the Use Case Package and the Use
Case Overview (or Context) Diagram
Use Case Packages
 “A packageis a grouping of model elements” – UML
• May contain all kinds of modeling elements, including nested packages
 Package owns the modeling elements they contain
• Package elements may reference elements in other packages
• Modeling elements belong to a single package
 Represented with a folder icon
Packages and Use Cases
Packages define a naming context for elements
 Modeling elements with same name can exist in the
model (use at own risk)
Use Case Packages
 All package-allowed
UML modeling
constructs apply
Useful when you
want to organize a
lot of use cases into
usable/reusable sets
Use Case Overview Diagrams
Show the scope and role (context) of system components in
realizing behavior
 Ironically these have actors but not use case “bubbles”
 Allows the architect to start capturing where system components
might sit (interface) w.r.t. Actors
• Recall the “systems affected” template item I did not like? These
diagrams give a separate place to start introducing where systems sit
and how they interact.
Administers
Online
Registration
System
Registers with
Registrar
Writes info to
Course
Management
System
Gains access to
Student
SIS
Use Case Modeling Process
Step 7: Identify Common Shared Behaviors
 Perform a comprehensive review of your use case catalog, looking for
common subsets of behavior
 If “useful”, factor these into new use cases related to other use cases
(typically through <<include>>)
Step 8: Promote Visibility of Important Extensions
 Behaviors that are complex or important in use case specification extensions
should be made visible in the use case diagram (through <<extends>>)
Step 9: Consider Special Case
 Are these specializations of identified use cases? Are they done by a
specialized actor?
Step 10: Partition the Behaviors into Packages
 Form natural clusters of behaviors that go together
• One way is by Actor
• What common functionality will need to be implemented to satisfy behaviors?
Step 11:Start thinking about Architecture
 Name high-level components that can provide functionality
 Keep this high-level! It is only a “jumping in” point for doing Analysis
Pros & Cons of Use-Case Modeling
Pros:
 Used to communicate with the end users & domain experts
• Provides buy-in at an early stage of system development
• Insures a mutual understanding of the requirements
 Used to identify who interacts with the system and what the
system should do
 Used to verify all requirements have been captured and the
development team understands the requirements
 Used as the basis for the rest of the process lifecycle
• For example, used as the foundation for writing test scripts
Cons:
 Captures only the functional requirements
 Must complement with other techniques to get Customer,
subcontractor, etc. – other requirements perspectives
 Organizing and identifying common functionality a “leap of faith”
 Use case connections to the rest of RUP are kludgy