requirements specification with use cases * these notes are a combination of materials from rational...
Post on 26-Dec-2015
219 Views
Preview:
TRANSCRIPT
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. 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
View Report Card
Register for Courses
Login
A Scenario Is a Use-Case Instance
Scenario 1Log on to system.Approve log on.Enter subject in search.Get course list.Display course list.Select courses.Confirm availability.Display final schedule.
Scenario 2Log 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.
StudentCourse Catalog
System
Register for Courses
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…
4
A scenario is an instance of a use caseThe normal basic flow called the “Happy Day” caseA use case may have several alternative flows
Regular variants Exceptional flowshandling error situations
Copyright © 2000 Rational Software, all rights reserved
Use Case Model +
SupplementarySpecification
Glossary
Use-Case Specifications
...
Use-Case Model
Actors
Use Cases
Object Oriented Analysis and Design Using the UML v2000Copyright © 2000 Rational Software, all rights reserved
SupplementarySpecification
Glossary and Supplementary Specification
(FURPS model) Functionality* Usability Reliability Performance Supportability
Design constraints…etc.
Glossary
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.
2.1 Course: A class offered by the university.
2.2 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.3 Course Catalog: The unabridged catalog of all courses offered by the university.
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
<<Actor>>Another Actor
AnActor
“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
Notation: Use Case
ReceiveCallManagePhonebook
“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
Notation: Communicates-Association
A channel of communication between an actor and a use case.
A line is used to represent a communicates-association.
An arrowhead indicates who initiates each interaction.
No arrowhead indicates either end can initiate each interaction.
Actor 1
Actor 2 Actor 3
Use Case
Use Case Template Example
11
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>>
VariationsVariation 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 VariationsVariation 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>>
Avoid Functional Decomposition
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: 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
Functional Decomposition Example
Enter PIN
Insert Card
Select “From” Account
Enter Amount
Select Withdraw Cash
Customer
Select Account Balance
Select Transfer Funds
Select “To” Account
Bank Consortium
Process Transaction
Functional Decomposition Example
Withdraw Cash
Transfer Funds
Deposit Funds
CustomerBankConsort
ium
A Corrected Example
How to do it:
Step 1. Identify and Describe the ActorsIdentify 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)
20
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: Preview ExamActor: Professor1. Login2. Go to gradebook3. Select exam4. Review scores5. View questions6. Blah blah…
UC2: Take ExamActor: Student1. Login2. Answer questions3. Submit4. Review score5. View questions6. Blah blah…
UC3: Take PretestActor: Student1. Login2. Answer questions3. Submit4. Review score5. View questions6. Receive remediation7. Blah blah…
UC1
UC2
UC3
Login
Reviewscores
<<i>>
<<e>>
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’sdesigners with some architectural guidance so they can efficiently breakdown 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”
<<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”
Notation: Use Case Relationships
Student
GraduateStudent
How would you read this diagram?
Course Catalog
View Report Card
Register for Courses
Submit Grades
Select Courses to Teach
Student
Professor
Billing System
Maintain Student Information
Maintain Professor Information
Login
Close Registration
Registrar
View Grades
<<extends>>
Maintain PersonInformation
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
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
Packages define a naming context for elements Modeling elements with same name can exist in the
model (use at own risk)
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.
Online Registration
SystemCourse
Management System
SIS
Student
Registrar
Registers with
Gains access to
Administers Writes info to
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
top related