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


Requirements Engineering requirements elicitation

requirements analysis

requirements specification

requirements validation

requirements validation

requirements elicitation

requirements analysis

requirements specification




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


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




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


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.




Requirements AnalysisCleanroomJoint Application Development (JAD)Rapid Application Development (RAD)Adaptive Loops FrameworkCritical Success Factors Analysis


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




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


RAD

Evolutionary prototyping

CASE tools

Specialists with Advanced Tools (SWAT)

Interactive JAD

Timeboxing




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.


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.




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


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)




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


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




ambiguous

notunderstandable

inconsistentredundant

incomplete

formalize

expand

resolve

condense

expand

addexplanations

There is no Perfect SRS

reduce

© Steve Easterbrook 2000-2002


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




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


SRS using a UML “package” construct




“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


SRS “ilities”Modifiability

Traceability




UML & SRS•Features Drive Use Case Models•Use Cases Interpret Requirements


Requirements Negotiation & Validation

NegotiationBased on draft of document

ValidationBased on (almost) complete document

IssuesScopeDependenciesRisksPriorities




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


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.




specifyingvisualizing

constructingdocumenting

The UML is agraphicallanguage for

the artifacts

of softwaresystems

UML Overview


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




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


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.




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


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




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


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




Use Case Notation

©The Unified Modeling Language User Guide by Grady Booch, Ivar Jacobson, James Rumbaugh Addison-Wesley Pub Co; 1st edition (1998)


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




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


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 ?




Box Office Actors

Clerk KioskSupervisor

TicketSeller

BusinessManager

Accounting System

EventManager

Credit Card Service

consider only direct actors


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




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


“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




Box Office Use Case Diagram

buy tickets

survey sales

make charges

buysubscription

Box Office

TicketSeller

KioskCredit Card

Service

Business Manager

<<include>><<include>>


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.




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.


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?”.




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.


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.




Use Case Dialog Patterns


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.




Identifying Use CasesRole PlayEssential use casesCRC CardsUse Case Cards


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.




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


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:




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.


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




Use Case CardsBiddle, Noble, TemproSimilar to Beck, et al CRC cardsSimpler, less implementation dependent, saves“unnecessary” documentation


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




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


Use Case Descriptions

RUP-style Use Case Descriptions




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


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




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


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




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.


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

08 requirements - computer science education lab, … · 2005-10-03 · cmpsci520/620 08...

Documents