08 Requirements - Computer Science Education Lab, … · 2005-10-03 · CMPSCI520/620 08...
Transcript of 08 Requirements - Computer Science Education Lab, … · 2005-10-03 · CMPSCI520/620 08...
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 1
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
08 RequirementsReadings
IEEE Recommended Practice for Software Requirements Specifications, IEEE Std830-1998, ©Copyright 1998 by The Institute of Electrical and ElectronicsEngineers, Inc. 345 East 47th Street, New York, NY 10017-2394, USA
http://opencmsstruts.sourceforge.net/vision.html [cK99] Cris Kobryn, Co-Chair, “Introduction to UML: Structural and Use Case
Modeling,” UML Revision Task Force Object Modeling with OMG UML TutorialSeries © 1999-2001 OMG and Contributors: Crossmeta, EDS, IBM, Enea Data,Hewlett-Packard, IntelliCorp, Kabira Technologies, Klasse Objecten, RationalSoftware, Telelogic, Unisys http://www.omg.org/technology/uml/uml_tutorial.htm
[OSBB99] Gunnar Övergaard, Bran Selic, Conrad Bock and Morgan Björkande,“Behavioral Modeling,” UML Revision Task Force, Object Modeling with OMGUML Tutorial Series © 1999-2001 OMG and Contributors: Crossmeta, EDS, IBM,Enea Data, Hewlett-Packard, IntelliCorp, Kabira Technologies, Klasse Objecten,Rational Software, Telelogic, Unisyshttp://www.omg.org/technology/uml/uml_tutorial.htm
[cB04] Bock, Conrad, Advanced Analysis and Design with UMLhttp://www.kabira.com/bock/
[rM02] Miller, Randy, “Practical UML: A hands-on introduction for developers,”Copyright © 2002 TogetherSoft, Inc. [now at Borland site]http://bdn.borland.com/article/0,1410,31863,00.html
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Requirements Engineering requirements elicitation
requirements analysis
requirements specification
requirements validation
requirements validation
requirements elicitation
requirements analysis
requirements specification
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 2
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
A General Elicitation Procedure
AskingObserving and inferring.Discussing and formulatingNegotiating with respect to a standard setStudying and identifying problems.Discovering through creative processesPostulating
identify ask analyze confirm synthesize
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Traditional methods Interviewing customers and domain experts
tutorial, focused, structured interview, teachbackavoid: opinionated questions, biased questions, imposingquestions
Questionnairesscenario (system-specific, less mature evaluation),questionnaire (more general, more mature), checklist(domain-specific, more mature)
ObservationPassive, active, for a prolonged period of time, people tend tobehave differently
Study of documents and software systemsUse case requirements ⇒ organizational documents, systemforms and reportsDomain knowledge requirements ⇒ journals and referencebooks, ERPS-s
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 3
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
ScenariosPurpose
Concretize abstract modelsScenarios instead of abstractmodels
Scenario use with prototypesComplexity reductionAgreement and consistencyScenario usage withglossaries
Reflection on static models
When?When abstract modeling failsdue to cost, inherent complexity,team issuesIn conjunction with prototypes:
Develop scenariosDevelop prototypesValidate prototypesRefine scenarios
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Simulations, Prototypes, etcWhy use? simulations
performance models are an exampleof a simulation
prototypingstrategies: throw-away prototype;evolutionary prototype; distinguishthe terms prototype and mock-up, prototype demonstrates behavior of a part
of the desired system, mock-up demonstrates the appearance of
the desired systemeach iteration allows the users tounderstand their requirementsbetter, including understanding theimplications of the requirementsarticulated in previous iterations.
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 4
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Requirements AnalysisCleanroomJoint Application Development (JAD)Rapid Application Development (RAD)Adaptive Loops FrameworkCritical Success Factors Analysis
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Cleanroom method
Customer/UserFeedback
Customer
Complete system
Increment 1• Sign on/off• setup
Increment 2• Sign on/off• Setup• Panel navigation
Increment 3• Sign on/off• Setup• Panel navigation• Primary functions Increment 4
• Sign on/off• Setup• Panel navigation• Primary functions• Secondary functions
Requirements
Top Level Specs
IncrementalDevelopment Plan
NewReusedStubbed
Customer
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 5
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Joint Application Design a technique for promoting cooperation, understanding, and
teamwork among buyers, users, and developers four main tenets of JAD
group dynamics (using facilitated group sessions to enhance thecapabilities of individuals)
the use of visual aids to enhance communication and understandingmaintaining an organized, rational process“what you see is what you get” documentation philosophy (usingstandard document forms that are filled in and endorsed by allparticipants in a session).
customization
session
wrap-up
preparation tasksorganizing the team,tailoring the process
structured and facilitatedmeetingsrequirements/designdeveloped and documented
•convert to final form, such asSRS
JAD/Plan JAD/Design
session leaderanalystexecutive sponsoruser representativesInformation systemsrepresentativesspecialists
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
RAD
Evolutionary prototyping
CASE tools
Specialists with Advanced Tools (SWAT)
Interactive JAD
Timeboxing
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 6
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Adaptive Loops Frameworksimilar in spirit to JAD - uses an adaptive
process of learning cycles or loops.developers are assisted by the users to gain newviewpoints about their requirements, and throughreformulating the requirements, the user learnsmore about themsystem receives pressure for evolution as theusers learn more about how it can be used, andthe system induces that learning on the userssystem evolves by actions of the developers, whoin turn gain enhanced understanding of the systemthrough that evolution.
especially useful when there are requirementsarticulation problems and to overcome thetechnical issues of complex systems.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Critical Success Factors Analysis basic premise = the effectiveness of a system
typically depends on a small set of critical factors six major steps:
understand the operation of the system. identify the factors that are critical for the effectivenessof the system.
identify the strengths and weaknesses of the systemwith respect to each of
these factors. identify areas of problems and opportunities.gather relevant details for enhancing systemperformance relative to these critical success factors.
formulate requirements using these details.
widely used in building information and decisionsupport systems
useful in addressing some of the difficult technicaland cognitive issues of requirements elicitation.
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 7
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
SW Requirements SpecificationHow do we communicate the Requirements to others?It is common practice to capture them in an SRS
But an SRS doesn’t need to be a single paper documentPurpose
Contractual
Baseline
Audience
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
What about RFP/RFB/RFIs?RFP = ‘SRS’ written by the procurer (or by anindependent RE contractor)Selected developer may create a more detailed ‘SRS’developer’s understanding of the customers needsbasis for evaluation of contractual performanceNot typically response to RFP
IEEE Standard recommends SRS jointly developed byprocurer and developer
When to issue RFP/RFB?Early (conceptual stage)Late (detailed specification stage)
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 8
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Appropriate SpecificationConsider two different projects:
Tiny project, 1 programmer, 2 months workProgrammer talks to customer, then writes up a 5-pagememo
Large project, 50 programmers, 2 years workTeam of analysts model the requirements, then documentthem in a 500-page SRS
Project A Project B
Purpose of spec? Crystalizes programmer’sunderstanding; feedback tocustomer
Build-to document; mustcontain enough detail for allthe programmers
Managementview?
Spec is irrelevant; havealready allocatedresources
Will use the spec to estimateresource needs and plan thedevelopment
Readers? Primary: Spec author;Secondary: Customer
Primary: programmers,testers, managers;Secondary: customers
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Hints & Guidelines Validity (or “correctness”)
expresses only the real needs ofthe stakeholders (customers,users,…)
Completeness specifies all the things the system
must do and all the things it mustnot do!
Conceptual Completeness e.g. responses to all classes of input
Structural Completeness e.g. no “to be determined” functions
Consistency not self-contradictory satisfiable all terms used consistently inconsistency can be hard to
detect especially in timing aspectsand business logic
Necessary doesn’t contain anything that isn’t
“required”
Ambiquity every statement can be read in
exactly one way defines confusing terms
e.g. in a glossary
Verifiablility includes a process exists to test
satisfaction of each requirement every requirement is specified
behaviorally Understandablility (Clarity)
e.g. by non-computer specialists technical notations should only be
used as backup (e.g. in anappendix)
Modifiability easy to change and modify good structure and cross-
referencingmust be kept up to date!
see IEEE-STD-830-1993
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 9
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
ambiguous
notunderstandable
inconsistentredundant
incomplete
formalize
expand
resolve
condense
expand
addexplanations
There is no Perfect SRS
reduce
© Steve Easterbrook 2000-2002
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Typical mistakes Noise
text that carries no relevantinformation to any feature of theproblem.
Silence a feature that is not covered by
any text. Over-specification
text that describes a feature of thesolution, rather than the problem.
Contradiction text that defines a single feature
in a number of incompatible ways. Ambiguity
text that can be interpreted in atleast two different ways.
Forward reference text that refers to a terms or
features yet to be defined. Wishful thinking
text that defines a feature thatcannot possibly be validated.
Jigsaw puzzles distributing key information across
a document and then cross-referencing
Duckspeak requirements requirements that are only there
to conform to standards Unnecessary invention of terminology
e.g. ‘user input presentationfunction’
e.g. ‘airplane reservation datavalidation function’
Inconsistent terminology inventing and then changing
terminology Putting the onus on the development
staff i.e. making the reader work hard
to decipher the intent Writing for the hostile reader
fewer of these than friendlyreaders
from Steve Easterbrook © 2000-2002; he adapted from Kovitz, 1999
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 10
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
IEEE std offers different templates External stimulus or external situation
e.g., for an aircraft landing system, eachdifferent type of landing situation: wind gusts,no fuel, short runway, etc
System feature e.g., for a telephone system: call forwarding,
call blocking, conference call, etc System response
e.g., for a payroll system: generate pay-cheques, report costs, print tax info;
External object e.g. for a library information system, organize
by book type User type
e.g. for a project support system: manager,technical staff, administrator, etc.
Mode e.g. for word processor: page layout mode,
outline mode, text editing mode, etc Object
e.g., in a patient monitorng system, objectsinclude patients, sensors, nurses, rooms,physicians, medicines, etc.
1.Introduction• Purpose• Scope• Definitions, acronyms, abbreviations• Reference documents• Overview
2.Overall Description• Product perspective• Product functions• User characteristics• Constraints• Assumptions and Dependencies
3.Specific Requirements Appendices Index
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
SRS using a UML “package” construct
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 11
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
“Combining Software Requirements Specifications with Use-Case Modeling,”Leslee Probasco and Dean Leffingwell
www.spc.ca/downloads/srs_usecase.doc
SRS using UMLSRS
may include a single document, multiple documents,use case specifications and even the graphical usecase model which describes relationships amongst theuse cases.
Stakeholderssystem analystuse-case specifierdesignersimplementersproject managertesters
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
SRS “ilities”Modifiability
Traceability
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 12
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
UML & SRS•Features Drive Use Case Models•Use Cases Interpret Requirements
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Requirements Negotiation & Validation
NegotiationBased on draft of document
ValidationBased on (almost) complete document
IssuesScopeDependenciesRisksPriorities
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 13
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Issues
ScopeDependenciesRisks
TechnicalPerformanceDatabase integrityDevelopment processPolitical LegalVolatility
Maciaszek Requirements Analysis and System Design © Addison Wesley , 2000
Ticket Placement
Outcome
Conversation
Ticket Order
Supporter Details
Campaign Details
OrderProcessing
SupporterDatabase
Supporter
Telemarketing
System scope model
CampaignDatabase
Schedule Phone Conversation
CRUD* Campaignand Supporter DetailsTelemarketer
Enter ConversationOutcome
Supporter
“business” use case model
Requirements dependency matrix
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Copyright © 2002 TogetherSoft, Inc
Model-Driven Developmentunderlying tenet begins with the construction of a model
a model is an abstraction of the underlying problemthe domain is the actual world from which the problemcomes
models consist of objects that interact by sendingeach other messagesobjects have things they know (attributes) and thingsthey can do (behaviors or operations)values of an object's attributes determine its state
classes are the "blueprints" for objectsa class wraps attributes (data) and behaviors (methodsor functions) into a single distinct entity
objects are instances of classes.
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 14
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
specifyingvisualizing
constructingdocumenting
The UML is agraphicallanguage for
the artifacts
of softwaresystems
UML Overview
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
UML Goalsan easy-to-learn butsemantically rich visualmodeling languageunify the Booch, OMT, andObjectory modeling languagesideas from other modelinglanguages + industry bestpracticesenable model interchange anddefine repository interfacesprovide a common vocabularyto talk about object-orientedsoftware design.
Booch, Jacobson, Rumbaugh
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 15
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Unifying Concepts in UMLclassifier-instance dichotomy
e.g., an object is an instance of a class ORa class is the classifier of an object
specification-realization dichotomye.g., an interface is a specification of a class OR a classis a realization of an interface
building blocks:model elements (classes, interfaces, components, usecases, etc.)relationships (associations, generalization,dependencies, etc.)diagrams (class diagrams, use case diagrams,interaction diagrams, etc.)
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Well-formedness rules
Well-formed: indicates that a model or model fragmentadheres to all semantic and syntactic rules that apply to it.
UML specifies rules for: naming, scoping, visibility,integrity & execution (limited)
However, during iterative, incremental development it isexpected that models will be incomplete and inconsistent.
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 16
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
What is use case modeling?use case model
a view of a system that emphasizes the behavior as itappears to outside users. A use case model partitions systemfunctionality into transactions (‘use cases’) that aremeaningful to users (‘actors’)
example: Make Appointmentuse case for the medical clinic
actor is a Patientconnection between actor and use case is a communication
association (or communication for short)
Patient
make appointmentactor
communication
use case
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Use-Case diagramsemphasis is on what a system does rather thanhow
Use case diagrams are closely connected toscenariosa scenario is an example of what happens whensomeone interacts with the system, e.g.,"A patient calls the clinic to make an appointmentfor a yearly checkup. The receptionist finds thenearest empty time slot in the appointment bookand schedules the appointment for that time slot."
a use case is a summary of scenarios for a singletask or goalan actor is who or what initiates the eventsinvolved in that task
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 17
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Use Case Modeling: Core Elements
Construct Description Syntax
use case A sequence of actions, includingvariants, that a system (or otherentity) can perform, interacting withactors of the system.
actor A coherent set of roles that usersof use cases play when interactingwith these use cases.
systemboundary
Represents the boundary betweenthe physical system and the actorswho interact with the physicalsystem.
UseCaseName
ActorName
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Construct Description Syntax
association The participation of an actor in a usecase. i.e., instance of an actor andinstances of a use case communicatewith each other.
generalization A taxonomic relationship between amore general use case and a morespecific use case.
extend A relationship from an extension usecase to a base use case, specifyinghow the behavior for the extensionuse case can be inserted into thebehavior defined for the base usecase.
Use Case Modeling: Core Relationships
<<extend>>
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 18
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Use Case Notation
©The Unified Modeling Language User Guide by Grady Booch, Ivar Jacobson, James Rumbaugh Addison-Wesley Pub Co; 1st edition (1998)
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Uses & Extends
Provide Enrolment Instructions
Student Office
Provide Examination Results
Student
•Pre-enrolment activities•Mail-outs of
•Last semester's examination grades tostudents•Enrolment instructions
<<extend>>
Data Entry Person
Enter Program of Study
Registrar Office
Validate Program of Study
•During enrolment•Accept students'proposed programs ofstudy•Validate
<<include>>
© MACIASZEK, L.A. (2001): Requirements Analysis and System Design. Developing Information Systemswith UML, Addison Wesley Copyright © 2000 by Addison Wesley
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 19
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
This and f ollowing f ew slides are adapted f rom: Biddle, Robert, James Noble, Ewan Tempero“Patterns f or Essential Use Cases”
Use-case modeling strategyWhere to start?⇒Actors
How to determine what the system should do?⇒Candidate Use Cases
How to manage a large number of use cases?⇒Focal Use Cases
How to know when to stop?⇒Use Case Diagram
How to describe the use cases?⇒Use Case Descriptions
How to check that use cases are correct?⇒Use Case Roleplay
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Example - Booking OfficeDesign a program for a booking office of an arts center.There are several theatres, people may reserve seatsat any theatre for any future event, and people maysubscribe to a series of events. People need to be ableto discuss seat availability, where seats are located,and how much they cost. When people make a choice,the program should print the price, record the selection,and print out a ticket
Actors?People?
Other people?
Systems ?
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 20
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Box Office Actors
Clerk KioskSupervisor
TicketSeller
BusinessManager
Accounting System
EventManager
Credit Card Service
consider only direct actors
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Candidate Use CasesTicket Seller:
Find event (dates, times), determine seat availability,determine seat location, determine seat price, reserve andissue ticket, ditto for subscriptions?
Kiosk:Tickets only
Event Manager:Add event, schedule performance, modify performanceinformation, other?
Business Manager:Print report
Accountant:Print sales information
Credit Card ServiceAuthorize charges
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 21
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Box Office
Box Office Use Case Diagram
buy tickets
get seat availability
TicketSeller
get eventdetails
issueticketsreserve
seats
get seat prices
get seat location
unreserveseats
get eventschedule
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
“Focal” Use Cases Issues
Even small systems can have a large number of use cases(~50 for a small system; ~100’s for a medium system)Some central, some notSome will be easy to implement, some difficultDifferent stakeholders will value the use cases differently
StrategyRankingOther elicitation techniques
Example -- Ticket Seller:List event performances, report event details, reportavailability of seats, show location of seats, buy tickets(subscriptions), process payments
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 22
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Box Office Use Case Diagram
buy tickets
survey sales
make charges
buysubscription
Box Office
TicketSeller
KioskCredit Card
Service
Business Manager
<<include>><<include>>
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Questions to ask Is there an actor representing every kind of user who will use
the system? Is there a system actor for every (legacy) system with which
this system needs to communicate?Can each actor do everything they need to do using only the
use cases they are related to?Are any obvious use cases missing?
use case models are often symmetric: if there are use casesfor creating bookings, printing booking receipts, printingperformance receipts, and canceling performances, perhapsthere should also be use cases for canceling bookings andcreating performances.
Unless you are on a small system (if you have not more than15-20 use cases) draw one use case diagram for each actor(or for a few related actors), rather than one diagram for thewhole system.
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 23
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
CRUD analysisCRUD = Create, Read, Update, or DeleteIdentify CRUD classes and check whether any of theother CRUD use cases are needed.
Consider the rest of the classes in the domain modeland check if they should also have CRUD use cases.Rename these uses cases where appropriate
Example: Get Event Details ⇒ Read Eventwe might want: Create Event, Delete Event, and UpdateEvent
Not all of the CRUD use cases are needed for everyconceptso CRUD analysis should not be applied blindly.not all classes in the domain model should have CRUDanalysis applied to them.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Reporting Use Cases Reporting is very important for lots of systems, but
boring for implementers, so they can underestimate the effortrequired to produce reports.boring to modelboring to one of users or stakeholders, while simultaneouslycrucial to the others.
If it’s important to someone, you have to model itWill also ensure you capture all the important casesYou should have at least twenty (?) reporting use cases.
Occupancy Report, Report Monthly Sales, Report SeatAvailability, Occupancy Report by Theatre, OccupancyReport by Event, Occupancy Report by Performance,Occupancy Report by Week, … are all of interest to theBusiness Manager, but may be useful to the Ticket Sellerwhen answering questions of the form “Are the plenty of freeseats for tomorrow’s performance of Dracula?”.
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 24
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Use Case Dialog PatternsAlarm Use Case
How do you have the system inform the user about something?Write a use case that begins with the system taking the responsibilityto warn the user.
If the alarm is important, you may need to include a Confirming StepRequesting Use Case
How do you write a use case when the user needs to knowsomething from the system?
Write a use case where the actor describes the information theyrequire, and then the system presents that information.
Monitoring Use CaseHow do you write a use case where the user often needs to knowabout a relatively small amount of important information from thesystem.
Write a use case where the system presents that information.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Use Case Dialog PatternsCommanding Use Case
How do you have the user get the system to do something?Write a use case where the user provides information on therequest, and the system has the responsibility for performingthe command
Prompting StepHow should you write a use case when the system knowssome information that would help the use make a decision?Give the system the responsibility of offering that informationbefore the user makesthe decision.
Confirming StepHow should you write a use case when it is important thatcorrect information is communicated between the actor andthe system?Require the actor or system to confirm the information.
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 25
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Use Case Dialog Patterns
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Organizing Use CasesHow do you model errors and exceptions in use cases?
Use extending use cases.How do remove commonality between use cases?
Make a new use case containing the common steps, andinclude it in the use cases that have the common steps.
How do you handle more general and more specific usecases that do the same kind of thing?Use specializationPrefer inclusion to specialization.
How do you model use cases than can only operate undercertain circumstances?Use pre- and post-conditions to control when use-cases arepermissible.Prefer extensions to conditions.Pre- and post-conditions should match in a complete model.
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 26
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Identifying Use CasesRole PlayEssential use casesCRC CardsUse Case Cards
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Use Case RoleplayExample: Get Seat Availability
The ticket seller (“user”) is using the “system” to determinewhether the seats requested by the customer for aperformance are in fact available.
Take 1:User: I say which performance I want and the system showsme the performance details.CUT! — it’s the system’s job to say what the system does. This is
often just an error made by the role-player, but can also indicateconfusion as to where the system boundary is.
Take 2:User: I say which performance I want.System: I display the performance details and say whether ornot the seats are available.CUT! — the seats haven’t been specified yet.
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 27
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Use Case RoleplayExample: Get Seat Availability
The ticket seller (“user”) is using the “system” to determinewhether the seats requested by the customer for aperformance are in fact available.
Take 3User: I say which performance I want. User pauses waitingfor a response, then Looks over to the person playing thesystem, who is still looking at the use case card, and doesn’trealize he’s being cued. System?System: You’re supposed to say what seats you want toknow about too. Points at card.User: Oh, right
CUT. The roleplay does not allow anyone to hide — all participantshave to engage with what the use case is about.
Take 4:And so on. . .
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
RoleplayUsing roleplay to assist use case checking is not strictlynecessary, but it does harness several human skills:
But, it is another checking practice that is subject todiminishing returns:
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 28
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Constantine & LockwoodAn essential use case
a structured narrative, expressed in the language of the applicationdomain and of users, comprising a simplified, generalized, abstract,technology-free and implementation independent description of onetask or interaction that is complete, meaningful, and well-definedfrom the point of view of users in some role or roles in relation to asystem and that embodies the purpose or intentions underlying theinteraction.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
CRC Cards
ClassName Collaborators
ResponsibilitiesView Controller
Render the Model
Transform coordinates Controller
View Model
Interpret user inputDistribute control
Model
Maintain problem related info.
Broadcast change notification
•CRC = class name, responsibilities, and collaborators•Example: MVC CRC cards
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 29
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Use Case CardsBiddle, Noble, TemproSimilar to Beck, et al CRC cardsSimpler, less implementation dependent, saves“unnecessary” documentation
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Copyright © 1997 by Rational Software Corporation
Documenting Use CasesA flow of events document is created for each usecasesWritten from an actor point of view
Details what the system must provide to the actor whenthe use cases is executed
Typical contentsHow the use case starts and endsNormal flow of eventsAlternate flow of eventsExceptional flow of events
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 30
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Documenting use casesBrief DescriptionActors involvedPreconditions necessary for the use case to startDetailed Description of flow of events that includes:
Main Flow of events, that can be broken down to show:Subflows of events (subflows can be further divided into smaller
subflows to improve document readability)
Alternative Flows to define exceptional situationsPostconditions that define the state of the system after the
use case ends
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Use Case Descriptions
RUP-style Use Case Descriptions
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 31
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Another example: ESU Universitywants to computerize their registration systemRegistrar sets up the curriculum for a semester
One course may have multiple course offeringsstudents select 4 primary courses and 2 alternate coursesonce a student registers for a semester, the billing system is
notified so the student may be billed for the semesterstudents may use the system to add/drop courses for a
period of time after registrationprofessors use the system to receive their course offering
rostersusers of the registration system are assigned passwords
which are used at logon validation
Registrar Professor Billing SystemStudent
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Copyright © 1997 by Rational Software Corporation
Maintain Curriculum Flow of EventsThis use case begins when the Registrar logs onto the
Registration System and enters his/her password. Thesystem verifies that the password is valid (E-1) and promptsthe Registrar to select the current semester or a futuresemester (E-2). The Registrar enters the desired semester.The system prompts the Registrar to select the desiredactivity: ADD, DELETE, REVIEW, or QUIT.If the activity selected is ADD, the S-1: Add a Coursesubflow is performed.If the activity selected is DELETE, the S-2: Delete aCourse subflow is performed.If the activity selected is REVIEW, the S-3: ReviewCurriculum subflow is performed.If the activity selected is QUIT, the use case ends.
...
RegistrarMaintain Curriculum
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 32
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Narrative use case specification
If the use case was successful, the Registrar hasaccessed the Add a Course function
Postconditions
The Registrar activates the Delete, Review, orQuit functions
Alternative Flows
The system enters the Add a Course subflowMain Flow
Registrar has a valid password (E-1), has selected asemester default or E-2), and has selected the Add (S-1) function at the system prompt
Preconditions
RegistrarActors
This use case allows a Registrar to enter a newcourse. …
Brief Description
Add a course to the curriculumUse Case
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Another Example
©The Unified Modeling Language User Guide by Grady Booch, Ivar Jacobson, James Rumbaugh Addison-Wesley Pub Co; 1st edition (1998)
Place Orderbase use case
SupplyCustomer
Data
<<include>>
OrderProduct
<<include>>
ArrangePayment
<<include>>
inclusion use cases
Request Catalog
<<extend>>
extension use case
parent use case
child use case
Pay Cash ArrangeCredit
CMPSCI520/620 08 Requirements
©Rick Adrion 2005 (except where noted) 33
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
When to model use casesModel user requirements with use cases.Model test scenarios with use cases.If you are using a use-case driven method
start with use cases and derive your structural andbehavioral models from it.
If you are not using a use-case driven methodmake sure that your use cases are consistent with yourstructural and behavioral models.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Use Case Modeling TipsMake sure that each use case describes a significant chunk of
system usage that is understandable by both domain experts andprogrammers
When defining use cases in text, use nouns and verbs accuratelyand consistently to help derive objects and messages forinteraction diagrams (see Lecture 2)
Factor out common usages that are required by multiple use cases If the usage is required use <<include>> If the base use case is complete and the usage may be optional,consider use <<extend>>
A use case diagram shouldcontain only use cases at the same level of abstraction include only actors who are required
Large numbers of use cases should be organized into packages