04 requirements

5/17/2018 04 Requirements

1/58

310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 1/67

SYSTEM REQUIREMENTS CAPTURESYSTEM REQUIREMENTS CAPTURE


310414310414SOFTWARE ENGINEERINGSOFTWARE ENGINEERING

310414310414SOFTWARE ENGINEERINGSOFTWARE ENGINEERING


2/58


SYSTEM REQUIREMENTS CAPTURE OUTLINESYSTEM REQUIREMENTS CAPTURE OUTLINE

System Requirements Capture Unified Process Overview

Importance & Difficulty

Capturing & Documenting Requirements

Life Cycle Role

System Requirements Capture Unified Process Activities

Domain Modeling

Use-Case Modeling

User-interface Specification & Prototyping

System Requirements Validation

4


3/58



requirement

afeaturethat the system must have or aconstraintthat it must satisfy

to beacceptedby the customer

requirements capture (gathering, elicitation, ...)

learningabout the problem that needs a solution

specifying(in detail)therequired features/constraints of the systemin a

way that thecustomer/user understandsand canapprove

CHALLENGE:CHALLENGE:How to bridge this gap?How to bridge this gap?

CHALLENGE:CHALLENGE:How to bridge this gap?How to bridge this gap?

requires thecollaborationof

several groupsof participantswithdifferent backgrounds

KnowledgeKnowledge

GAPGAP

4


4/58


Reasons for failure of/problems with software development:

incomplete requirements 13.1%

lack of user involvement 12.4%

lack of resources 10.6%

unrealistic expectations 9.9%

lack of executive support 9.3%

changing requirements and specifications 8.7%

lack of planning 8.1%

system no longer needed 7.5%

Reasons for failure of/problems with software development:

incomplete requirements 13.1%

lack of user involvement 12.4%

lack of resources 10.6%

unrealistic expectations 9.9%

lack of executive support 9.3%

changing requirements and specifications 8.7%

lack of planning 8.1%

system no longer needed 7.5%

IMPORTANCE OF REQUIREMENTS CAPTURE 1IMPORTANCE OF REQUIREMENTS CAPTURE 1

Requirements capture is involved in a majority of cases

> 50%

4.1


5/58


IMPORTANCE OF REQUIREMENTS CAPTURE 2IMPORTANCE OF REQUIREMENTS CAPTURE 2

cost to findand fix a defect

logscale

1

10

100

Reqmts

0.75

Design

1.00

Code

1.50

Test

3.00

Systemtest

10.00

Fielduse

60-100

BUT, requirements capture isVERY DIFFICULT!


6/58


WHY REQUIREMENTS CAPTURE IS DIFFICULTWHY REQUIREMENTS CAPTURE IS DIFFICULT

Our aim is to build therightsystem

a system that meets the users needs

but, users often do not know what they need!

many types of users (only know their own work and needs)

may not see the big picture (do not know entire flow of work)

may not know which aspects of their work can be computerized

for the software engineer, requirements capture is often adiscovery and learning process

need to get users tounderstandwhat we havecaptured and toapprovethat it meets their needs

users need to be able to understand our specifications

but, user is usually not a computer specialist!

Major

challenges


7/58310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 7/67

REQUIREMENTS CAPTURE PROCESS OVERVIEWREQUIREMENTS CAPTURE PROCESS OVERVIEW

Identify and understand user needs

define thegoalsof the system compile list ofsystem constraints

compile list ofcandidate requirements definedevelopment effort scope

Determine feasibility

economicfeasibility operationalfeasibility

technicalfeasibility organizational impact

Understand, capture and document system requirements

static(persistent data) dynamic(processing + constraints)(domain model + specifications) (use-case model + specifications)

Validate the system requirements

criteriaforuser acceptanceof the completed system (acceptance tests)

every software project is uniqueevery software project is unique>>need to adapt our processneed to adapt our processevery software project is uniqueevery software project is unique>>need to adapt our processneed to adapt our process



USER NEEDS IDENTIFICATIONUSER NEEDS IDENTIFICATION

collect data on application domain (may include existing system)

investigationexisting documentationobservationwork practicesinterviewsquestionnaires, personalprototypinginterface, functions

challenge customers/users model of reality

elicit problems, not solutionsdistinguishneedsfromwants; rate importance of needs

refine system goals, list of requirements, list of constraints ,

system scope, etc.

proposescope of project(what isincluded, what isexcluded)

document requirementssystem requirements specification

serves as acontractbetween the customer and developer!

4.5.1



FEASIBILITY DETERMINATIONFEASIBILITY DETERMINATION

Can we/should we build the system?

economic feasibilitycosts(development, operation) versusbenefits

tangibleversusintangible

technical feasibility

availability of technologyrisk of new technology?maintenance required

operational feasibilityavailability of skills to operate the system

fit with current work practices (redesign work practices?)

organizational feasibilitypolitics; training; user acceptance; . . .

legal feasibilityliability; copyright; patent; . . .



CAPTURE AND DOCUMENT SYSTEM REQUIREMENTSCAPTURE AND DOCUMENT SYSTEM REQUIREMENTS

static requirements(persistent data)domain model

describes the important concepts of the application domain as classes allows the development of a glossary of terms(data dictionary) for

communicating among everyone on the project

dynamic requirements(processing+constraints)use-case model

functional requirements- describe the interactions between the systemand its environment independent of its implementation

nonfunctional requirements- describe user-visible aspects of the systemthat are not directly related with the functional behaviour of the system e.g., response time, throughput, security, etc.

pseudo requirements- describe restrictions on the implementation of the

system imposed by the customer e.g., implementation language, platform, etc.

Requirements shouldonlystatewhat is needednothow it is done



Inception Elaboration Construction Transition

REQUIREMENTS CAPTURE LIFE CYCLE ROLEREQUIREMENTS CAPTURE LIFE CYCLE ROLE

PhasesCore Workflows

Requirements

Analysis

Design

Implementation

Testing

iter.

#1

iter.

#2

iter.

#n-1

iter.

#n

Increments

Iteratio

n



ARTIFACTS & WORKERSARTIFACTS & WORKERS

Use-CaseSpecifier

Use-CaseSpecification

responsible

for

User-InterfaceDesigner

User-interfaceSpecification &

Prototyping

responsible

for

Architect

ArchitectureDescription

responsible

for

DomainAnalyst

responsiblefor

DomainSpecification

SystemAnalyst

DomainModel

Actors GlossaryUse-Case

Model

responsible for



UP SYSTEM REQUIREMENTS CAPTURE PROCESSUP SYSTEM REQUIREMENTS CAPTURE PROCESS

Architect

SystemAnalyst

Use-CaseSpecifier

Find Classesand Associations

PrioritizeUse Cases

PrototypeUser-Interface

DetailUse Cases

Structure theUse-Case Model

User-Interface

Designer

Find Actors andUse Cases

Domain

Analyst

Detail Classes

and Associations


14/58


DOMAIN MODELINGDOMAIN MODELING

captures the most importantclassesand theirassociationsin the

context of the system

things that existorevents that occurin thesystems environment

found from high-level problem statement

lower-level requirements

domain experts (users)

imperative that this bedone wellso as to establish asolid foundationand toallow reuseby other systems

classes can be: business objects(e.g., orders, accounts, etc.)

real-world objects and concepts(e.g., suppliers, customers, etc.)

events(e.g., aircraft arrival/departure, sales, reservations, etc.)

described in aclass diagram static system structure


15/58


IDENTIFYING CLASSES & ASSOCIATIONSIDENTIFYING CLASSES & ASSOCIATIONS

naturally occurring thingsorconceptsin the application domain

classesoften appear asnouns/noun phrasesin application

domain terminology

associationsoften appear asverbs/verb phrasesin applicationdomain terminology

circleorhighlightin problem description put all terms intosingular form/active voice

decompositiondecompositionof a problem into classes and associationsof a problem into classes and associationsdependsdependsononjudgementjudgementandandexperienceexperienceand theand thenature of the problemnature of the problem

decompositiondecompositionof a problem into classes and associationsof a problem into classes and associationsdependsdependsononjudgementjudgementandandexperienceexperienceand theand thenature of the problemnature of the problem

identify onlyrelevant classesthose that are essential

throughout the systems life cycle

leads to astable system


16/58


DOMAIN MODEL KEEPING THE RIGHTDOMAIN MODEL KEEPING THE RIGHT

CLASSESCLASSES

Are any classes redundant?

Are any classes irrelevant to the application domain?

Are any classes vague (ill-defined)?

Should any classes really be attributes?

Do any classes describe an operation?

Do any class names describe a role?

Do any classes describe implementation constructs?


17/58



ASSOCIATIONSASSOCIATIONS

Are there any associations between eliminated classes?

Are any associations irrelevant to the application domain?

Do any associations describe an operation?

Can ternary associations be decomposed into binary associations?

Are any associations derived associations?

Are any associations named with how or why names?

Are role names required for any associations?

Should any associations be qualified?

Are multiplicity, ordering specifications missing?

Do any associations describe implementation constructs?


18/58



ATTRIBUTESATTRIBUTES Are attributes closely related to the class they are in?

Should any attributes really be classes?

Should any attributes be qualifiers?

Have object identifiers been included as attributes?

Should any attributes be in an association class?


19/58


DOMAIN MODEL DETAIL ATTRIBUTESDOMAIN MODEL DETAIL ATTRIBUTES

meaningful name

itemPrice not itpr

allowable values

continuous- a range of values

price: $0 to $10,000

need to note: rangetypical valuesexception handling

discrete- only allow certain values

marital-status: single, married,widowed, divorced

need to note: values and meaningof each (if coded)

short description

payment - a transaction to record aremittance

deposit - the initial amount paid y thecompany on a purchase order

aliases

synonyms- same meaning, butdifferent namecustomer ! client

acronyms- shortened namere"uisition#umer ! re"uis#um, re"#o

length as found in the real world number of digits or letters

encoding- physical representationof the value

only if no choice allowed in designphase

supplementary- other informationrelevant to use of the attribute


20/58


DOMAIN MODEL DETAIL CLASSES &DOMAIN MODEL DETAIL CLASSES &

ASSOCIATIONSASSOCIATIONS for eachclasswe can add anyoperationsthat we are aware of

at this stage

most operations will be added during analysis & design

for eachassociationwe need to specify (if known):a name (optional)

role names (as necessary)

multiplicity

association class (if necessary)

Place all domain model terms and their definitions in aglossary of terms/data dictionary


21/58


DOMAIN MODEL DETAIL GENERALIZATIONDOMAIN MODEL DETAIL GENERALIZATION

classify classes according tosimilarityofattributesand

operations

look forkind-of statementsthat are true in the real world

do not nest too deeply

2-3 levelsOK

4-6 levelsmaybe

10 levelstoo deep!

Goal:Goal:simplicity of representation and modeling clarity

Need to decide how to handle associations

in which subclasses participate


22/58


District

*

11

*

LivesInLivesIn


(contd)(contd)

Person

StudentProfessor

District* 1LivesIn


23/58


*

1

LivesIn


(contd)(contd)

1

*

*

11

*

LivesInLivesIn

Person

StudentProfessor

District

StudiesIn


24/58


USE-CASE MODELING EXAMPLEUSE-CASE MODELING EXAMPLE

A video sales and rental shop would like to computerize its management of sales and

rental of its movie videos. As well, it would like to establish a presence on the Web andallow its customers to rent and buy videos via the Web. Below are the high-levelrequirements for a system that will manage the sale and rental of videos for the videoshop:

The system must be able to keep track of which movie videos have beenbought/rented and by whom. For videos bought, the system must record thequantity bought; for videos rented, the system must record which copy of thevideo has been rented and when it is due back.

The system must keep track of overdue rental videos and allow notices to be sentto customers who have videos overdue.

The video shop will have a customer membership option for an annual fee, whichwill entitle the member to discounts (10%) on video sales and rentals.

Members should be able to make reservations for movie video rentals either in

person at the store, by telephone or via the Web. A member canreserveat most five movie videos at any one time, but there is nolimit on how many movie videos a member or nonmember can rent at any onetime.

As an added feature, the video shop would like to allow customers (eithermembers or nonmembers) to input, via the Web, mini-reviews (up to 100 words)


25/58


USE-CASE MODELING EXAMPLE (contd)USE-CASE MODELING EXAMPLE (contd)

and a rating (from 1, lowest, to 5, highest) of movies they have rented. These

reviews should be anonymous if the customer so wishes (i.e., the customer canspecify whether or not he wants his name to be made known when othercustomers browse the reviews).

The video shop maintains the following information about all customers (membersor nonmembers): name, address, phone number, fax number, age, sex, and emailaddress. In addition, members are assigned a membership number by the videoshop when they become members and a password, which allows them to accessthe members-only area of the video shop's web site, including accessing andchanging their personal information.

Using the Web, customers should be able to buy and rent videos and browse thereviews entered by other customers.

Managers must be able to generate various reports on sales/rentals of videos. Staff must be able to sell/rent videos from the stores inventory and return rented

videos to the store's inventory. When selling or renting videos, staff must be able to look up customer informationand determine whether the customer is a member.

An employee must be able to enter the basic information about a movie video(i.e., title, leading actor(s), director, producer, genre, synopsis, release year,running time, selling price, and rental price).


26/58


DOMAIN MODELING EXAMPLE ANALYSISDOMAIN MODELING EXAMPLE ANALYSIS

We first analyze the stated domain model requirements and then present the domain

model.

The system must be able to keep track of which movie videos have beenbought/rented and by whom. For videos bought, the system must record thequantity bought; for videos rented, the system must record which copy of thevideo has been rented and when it is due back.

The system must keep track of overdue rental videos and allow notices to be sent

to customers who have videos overdue.



27/58



Members should be able to make reservations for movie video rentals either in person at

the store, by telephone or via the Web.

A member canreserveat most five movie videos at any one time, but there is nolimit on how many movie videos a member or nonmember can rent at any onetime.

As an added feature, the video shop would like to allow customers (eithermembers or nonmembers) to input, via the Web, mini-reviews (up to 100 words)and a rating (from 1, lowest, to 5, highest) of movies they have rented. Thesereviews should be anonymous if the customer so wishes (i.e., the customer canspecify whether or not he wants his name to be made known when othercustomers browse the reviews).


28/58



The video shop maintains the following information about all customers (members or

nonmembers): name, address, phone number, fax number, age, sex, and emailaddress. In addition, members are assigned a membership number by the videoshop when they become members and a password, which allows them to accessthe member's only area of the video shop's web site, including accessing andchanging their personal information.


Managers must be able to generate various reports on sales/rentals of videos.

Staff must be able to sell/rent videos from the stores inventory and return rentedvideos to the store's inventory.


29/58



When selling or renting videos, staff must be able to look up customer information and

determine whether the customer is a member.


2 2 1; 2 4 1


30/58


USE-CASE MODELINGUSE-CASE MODELING

captures thesystem behaviorfrom theusers point of view

developedin cooperationwith the domain model

helps in:

capturing data and functional requirements

planning iterations of development

validating the system

dynamic modelgets started with use-case analysis

drives the entire development effort

allrequired functionalityis described in theuse cases

use-case model is developedincrementally

2.2.1; 2.4.1

4 4 1


31/58


SomethingSomethingoutsideoutsidethe systemthe system

thatthatinteracts directlyinteracts directlywith itwith it

USE CASE MODEL ACTORSUSE CASE MODEL ACTORS

actor name

actors are thesourcefor discovering use cases

4.4.1

can bepeopleor othersystems

providesinput toor takesoutput fromthe system

arolea user can play multiple roles per user;multiple users per role

An actor is astereotype of class

anactoris aclassifier;a specificuseris aninstance


32/58


IDENTIFYING ACTORSIDENTIFYING ACTORS

Whoorwhatuses the system?

Whatrolesdo they play in the interaction?

Whogets and provides informationto the system?

Whoinstalls,starts and shuts downormaintainsthe system?

Whatother systemsinteract with this system?

Does anythinghappen at a fixed time?

Input devicesare not actors!

It is common to have both adomain model classand anactorthat represent thesame thing.

Timecan be an actor.

For each actor, briefly the describeroleit plays

wheninteractingwith thesystem.

2 4 1; 4 4 3


33/58


USE CASE MODEL USE CASEUSE CASE MODEL USE CASE

A specific way of using the system byA specific way of using the system by

performingperformingsome part of itssome part of itsfunctionalityfunctionalityuse-case name

initially, we are only concerned with thenormalorusualsequence of

events/actions ignoreexceptions,alternate waysof doing things

2.4.1; 4.4.3

specifies theinteractionthat takes placebetweenanactorand thesystemconsidered from the users viewpoint

constitutes acomplete sequence of events/actionsinitiated by an actor

A use case is astereotype of class

use caseis aclassifier;scenariois aninstance


34/58


IDENTIFYING USE CASESIDENTIFYING USE CASES

What are thetasksthat an actor wants the system to perform?

Whatinformationdoes an actoraccess(create, store, change,

remove, or read) in the system?

Whichexternal changesdoes an actor need to inform the system

about?

Whicheventsdoes an actor need to beinformed aboutby thesystem?

How will the system besupportedandmaintained?

use case name should be stated from the perspective of the

user as apresent-tense,verb phraseinactive voice

provide adescription of the purposeof the use case

and ahigh-level definition of its functionality

useapplication domain termsin descriptions


35/58


ASU USE CASESASU USE CASES

At the beginning of each semester, students may request a course catalog

containing a list of course offerings needed for the semester. Information about eachcourse, such as instructor, department, and prerequisites are included to help

students make informed decisions.

The new system will allow students to select four course offerings for the comingsemester. In addition, each student will indicate two alternative choices in case acourse offering becomes filled or is canceled. No course offering will have more thanten students or fewer than three students. A course offering with fewer than threestudents will be canceled. Once the registration process is completed for a student,the registration system sends information to the billing system so the student can bebilled for the semester.


36/58


ASU USE CASESASU USE CASES

Professors must be able to access the online system to indicate which courses they

will be teaching, and to see which students signed up for their course offerings.

For each semester, there is a period of time that students can change theirschedule. Students must be able to access the system during this time to add ordrop courses.

2.4.1; 4.4.2


37/58


USE-CASE MODEL SCENARIOUSE-CASE MODEL SCENARIO

AAconcreteconcrete,,focusedfocused,,informal descriptioninformal descriptionof aof asinglesingleuse of the systemuse of the systemfrom thefrom theviewpoint of a single actorviewpoint of a single actor

AAconcreteconcrete,,focusedfocused,,informal descriptioninformal descriptionof aof asinglesingle

use of the systemuse of the systemfrom thefrom theviewpoint of a single actorviewpoint of a single actor

an attempt to carry out a use case

types of scenarios used in software development

as-is -describes a current situation (used to understand thecurrent system)

visionary -describes a future system

evaluation-describes user tasks to be used to evaluate the system(e.g., acceptance tests)

training -used for introducing new users to the system

2.4.1; 4.4.2

used to gain ashared understandingbetweendevelopers and users of what the system should do


38/58


IDENTIFYING SCENARIOSIDENTIFYING SCENARIOS

Sincescenariosareinstances of use cases, thesame

questionscan be asked as for identifying uses cases.

Note:two viewpoints of use-case modeling

1.top-down:start with use cases, refine with scenarios

2.bottom-up:start with scenarios, abstract use cases

In reality, the use case specifieruses both viewpoints

BUT scenarios mostly used to describe

errorsandalternate flows


39/58


WHAT IS A GOOD USE CASE?WHAT IS A GOOD USE CASE?

A use case typically represents a major piece of

functionalitythat iscompletefrom beginning to end.

A use case must deliversomething of valueto an actor.

Consider students in ASU Course Registration System:

select courses

be added to course offerings

be billeddeals with one completesequence of events/actions

Consider Registrar in ASU Course Registration System:

add courses

delete coursesmodify courses

deals with the same

class of objects

Generally, it is better to haveGenerally, it is better to havelongerlongerandandmoremore

extensiveextensiveuse cases than smaller onesuse cases than smaller ones

Generally, it is better to haveGenerally, it is better to havelongerlongerandandmoremore

extensiveextensiveuse cases than smaller onesuse cases than smaller ones


40/58


USE-CASE DETAIL FLOW OF EVENTSUSE-CASE DETAIL FLOW OF EVENTS

AApreciseprecise

, but, but

easy to readeasy to read

, description of the, description of the

sequencesequence

of actionsof actionsneeded toneeded toaccomplish a scenario/use caseaccomplish a scenario/use case

AApreciseprecise, but, buteasy to readeasy to read, description of the, description of thesequencesequence

of actionsof actionsneeded toneeded toaccomplish a scenario/use caseaccomplish a scenario/use case

whatthesystemandtheactorshould do to perform the actions

(not howit is done;ignoreuse caseinteractions)

Basic path:shows one completenormalpath from start to end

no errors, no exceptions (always required).

Alternate paths:showexceptional conditionsorerrors.

start with basic path, then add alternate paths as needed

Goal:Goal:specifyeverythingthe user might do


41/58


USE CASE DETAIL USE CASE SPECIFICATIONUSE CASE DETAIL USE CASE SPECIFICATION

use case name

participating actors

preconditions(usually on thesystem state; relevant to this use case)things that must be truebeforethe use case can execute

flow of events

required order of actionsthe normal sequence of eventswhatinteractionthe use case haswith the actors

whatdataisneededby the use case

postconditions(usually on thesystem state; relevant to this use case)things that must be trueat the endof the use case execution

special requirements(if any) alternate or exceptional flows(if any)

Narrative should beevent-response oriented(i.e., The system does X. The user does Y. etc.)


42/58


USE CASE DETAIL FLOW OF EVENTSUSE CASE DETAIL FLOW OF EVENTS

SPECIFICATIONSPECIFICATION

branching

n.Ifboolean-expressionn.1.declarative-statementn.2.declarative-statementn.3.

n+1.

repetition: For

n.Foriteration-expression

n.1.declarative-statementn.2.declarative-statementn.3.

n+1.

repetition: While

n.Whileboolean-expressionn.1.declarative-statement

n.2.declarative-statementn.3.

n+1.

sequence of short stepsthat arenumbered,declarative, andtime-

orderedn. Thesomethingsome-action. (e.g., 3. The user enters a login id.)

repetition should beusedsparingly!

use-case specification shouldbe kept assimple as possible


43/58


USE-CASE MODEL DETAIL GENERALIZATIONUSE-CASE MODEL DETAIL GENERALIZATION

Since actors and use cases areSince actors and use cases are

classifiers, they can be generalized.classifiers, they can be generalized.

Since actors and use cases areSince actors and use cases are

classifiers, they can be generalized.classifiers, they can be generalized.

ManagerSales clerk

represents adesign decision!

Employee Validate user

Check password Retinal scan

2.4.1

2.4.1; 4.4.5


44/58


USE-CASE DETAIL INCLUDEUSE-CASE DETAIL INCLUDE

many use cases maysharepieces of thesame functionality

we canfactor outthisfunctionality, place it in aseparate use caseand relate it to all use cases that need to use it by an relationship

Validate user

Register for courses Select courses to teach Request enrollment list


include use case(usually not invoked

directly by user)

main use cases

(invoked directly

by user)

2.4.1; 4.4.5


45/58


modelsconditional additionsto a use cases sequence of

actions

used to show:

optional behavior

behavior that is executed only under certain conditions

several different subflows that are executed based on the selection of aparticular actor

USE-CASE DETAIL EXTENDUSE-CASE DETAIL EXTEND

specifies how a use case description may beinserted into, and

thusextend, an existing use case

(semester invalid)

Select courses to teach

extenduse case

mainuse case

Invalid semester


extensionpoint label

4.4.7


46/58


IDENTIFYING NONFUNCTIONAL REQUIREMENTSIDENTIFYING NONFUNCTIONAL REQUIREMENTS

user-visible system properties that cannot be expressed as use

cases, but often placeconstraintson the use cases

performance (time and throughput) requirements

reliability requirements

the environment in which the software is to operate

possible error sources and suitable measures for the prevention ofsuch errors and/or the minimization of their effect

constraints on implementation hardware, quality, etc.

life-cycle considerations schedule, budget, etc.

Captured assupplementary requirementson use cases or on the system as a whole


47/58


USE CASES THROUGH THE DEVELOPMENTUSE CASES THROUGH THE DEVELOPMENT

Planning

Basis for negotiation with customer

determine which use cases to provide in the first release

Political aspects

Demonstrate the system doing something valuable to the most

influential people first

use knowledge about how much each user wants their use case

Technical aspects

Deliver the highest risk use cases first

use knowledge from risk analysis

System validation

walk the use case to see if it can provide the required functionality


48/58


USE-CASE MODELING EXAMPLEUSE-CASE MODELING EXAMPLE

A video sales and rental shop would like to computerize its management of sales and

rental of its movie videos. As well, it would like to establish a presence on the Web andallow its customers to rent and buy videos via the Web. Below are the high-levelrequirements for a system that will manage the sale and rental of videos for the videoshop:

The system must be able to keep track of which movie videos have beenbought/rented and by whom. For videos bought, the system must record thequantity bought; for videos rented, the system must record which copy of the

video has been rented and when it is due back. The system must keep track of overdue rental videos and allow notices to be sentto customers who have videos overdue.



person at the store, by telephone or via the Web. A member canreserveat most five movie videos at any one time, but there is nolimit on how many movie videos a member or nonmember can rent at any onetime.

As an added feature, the video shop would like to allow customers (eithermembers or nonmembers) to input, via the Web, mini-reviews (up to 100 words)


49/58


USE-CASE MODELING EXAMPLE (contd)USE-CASE MODELING EXAMPLE (contd)

and a rating (from 1, lowest, to 5, highest) of movies they have rented. These

reviews should be anonymous if the customer so wishes (i.e., the customer canspecify whether or not he wants his name to be made known when othercustomers browse the reviews).

The video shop maintains the following information about all customers (membersor nonmembers): name, address, phone number, fax number, age, sex, and emailaddress. In addition, members are assigned a membership number by the videoshop when they become members and a password, which allows them to access

the members-only area of the video shop's web site, including accessing andchanging their personal information.


Managers must be able to generate various reports on sales/rentals of videos. Staff must be able to sell/rent videos from the stores inventory and return rented

videos to the store's inventory. When selling or renting videos, staff must be able to look up customer informationand determine whether the customer is a member.



50/58


USE-CASE MODELING EXAMPLE ANALYSISUSE-CASE MODELING EXAMPLE ANALYSIS

We first analyze the functional requirements of the system and then present the use-

case model. Note that for the purposes of producing the use-case model, we areonly really interested in those functional requirements that provide something of

value for some actor.

The system must be able to keep track of which movie videos have beenbought/rented and by whom. For videos bought, the system must record thequantity bought; for videos rented, the system must record which copy of the

video has been rented and when it is due back.

The system must keep track of overdue rental videos and allow notices to besent to customers who have videos overdue.


51/58



The video shop will have a customer membership option for an annual fee, which will

entitle the member to discounts (10%) on video sales and rentals.


person at the store, by telephone or via the Web.

A member canreserveat most five movie videos at any one time, but there is nolimit on how many movie videos a member or nonmember can rent at any onetime.


52/58



As an added feature, the video shop would like to allow customers (either members

or nonmembers) to input, via the Web, mini-reviews (up to 100 words) and a rating(from 1, lowest, to 5, highest) of movies they have rented. These reviews should beanonymous if the customer so wishes (i.e., the customer can specify whether ornot he wants his name to be made known when other customers browse thereviews).

The video shop maintains the following information about all customers(members or nonmembers): name, address, phone number, fax number, age,sex, and email address. In addition, members are assigned a membershipnumber by the video shop when they become members and a password, whichallows them to access the members-only area of the video shop's web site,including accessing and changing their personal information.


53/58



Using the Web, customers should be able to buy and rent videos and browse the

reviews entered by other customers.

Managers must be able to generate various reports on sales/rentals of videos.

Staff must be able to sell/rent videos from the stores inventory and return rentedvideos to the store's inventory.

When selling or renting videos, staff must be able to look up customerinformation and determine whether the customer is a member or not.


54/58



An employee must be able to enter the basic information about a movie video

(i.e., title, leading actor(s), director, producer, genre, synopsis, release year,running time, selling price, and rental price).

4.3.4


55/58


VALIDATE SYSTEM REQUIREMENTSVALIDATE SYSTEM REQUIREMENTS

requirements should becontinuously validatedwith thecustomer

and theuserand they should be:correct- represent the customers view of the system

everything in the requirements model accurately represents anaspect of the system

complete- all possible scenarios through the system are described,

including exceptional behaviour all aspects of the system are represented in the

requirements model

consistent- do not contradict themselves

unambiguous- exactly one system is defined

it is not possible to interpret the specication two or moredierent ways

realistic- the system can be implemented within the constraints


56/58


VALIDATE REQUIREMENTS ACCEPTANCE TESTSVALIDATE REQUIREMENTS ACCEPTANCE TESTS

Functional validity does the system provide the required functionality

and obey the required constraints?

Show that a professor can select a course offering to teach.

Show that a student cannot register for more than four courses.

Interface validity do interfaces perform desired functions (acceptdesired input/provide desired output) and follow consistent designstandards?

Show that all required data for course registration can be input.

Information content are the data structures/data bases correct (storethe right data in the required format)?

Show that all required information of a students course schedule is shown.

Performance does the system meet specified performance criteria?

Show the response time to register for a course is less than 1 second.

Tests must be specified that willTests must be specified that willdemonstratedemonstrateto the customer thatto the customer that

all functionsall functionsandandconstraintsconstraintsof a system areof a system arefully operationalfully operational

Tests must be specified that willTests must be specified that willdemonstratedemonstrateto the customer thatto the customer that

all functionsall functionsandandconstraintsconstraintsof a system areof a system arefully operationalfully operational


57/58


DERIVING AN ACCEPTANCE TEST PLANDERIVING AN ACCEPTANCE TEST PLAN

restatewritten requirements in aconcise,preciseandtestable

waygroup related requirements

remove any requirements that cannot be tested

addany additional requirements gathered from userslook atuse casesforfunctional and interface requirements

look atdomain modelforinformation content requirements

look atnonfunctional requirementsforperformance requirements

construct, for each requirement, anevaluation scenariothatwill demonstrate to the customer that the requirement is met

(since most evaluation scenarios depend on the user interface,they can not be completed until the user interface is designed)


58/58

SUMMARY SYSTEM REQUIREMENTS CAPTURESUMMARY SYSTEM REQUIREMENTS CAPTURE

requirements are captured over several iterations by specifying:

a domain modela use-case model

initial user interfaces (and building some user interface prototypes)

an acceptance test plan

These are all documented in the

System Requirements Specification (SRS)

Use casesdrivethe subsequent iterations/phases

in subsequent iterations/phases we refine and/or transform the

requirements by specifying:more detail for each of the above artifacts

matching use-case realizations in analysis model

matching use-case realizations in design model

a set of test cases in the test model

04 requirements

Documents

incomplete requirements

customerrequirements

lack of resources

lack of planning

lack of user involvement

lack of executive support

needs users

users tounderstandwhat