04 requirements
DESCRIPTION
04 RequirementsTRANSCRIPT
-
5/17/2018 04 Requirements
1/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 1/67
SYSTEM REQUIREMENTS CAPTURESYSTEM REQUIREMENTS CAPTURE
SYSTEM REQUIREMENTS CAPTURESYSTEM REQUIREMENTS CAPTURE
310414310414SOFTWARE ENGINEERINGSOFTWARE ENGINEERING
310414310414SOFTWARE ENGINEERINGSOFTWARE ENGINEERING
-
5/17/2018 04 Requirements
2/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 2/67
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
-
5/17/2018 04 Requirements
3/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 3/67
SYSTEM REQUIREMENTS CAPTURESYSTEM REQUIREMENTS CAPTURE
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
-
5/17/2018 04 Requirements
4/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 4/67
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/17/2018 04 Requirements
5/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 5/67
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!
-
5/17/2018 04 Requirements
6/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 6/67
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
-
5/17/2018 04 Requirements
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
-
5/17/2018 04 Requirements
8/58310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 8/67
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
-
5/17/2018 04 Requirements
9/58310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 10/67
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; . . .
-
5/17/2018 04 Requirements
10/58310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 11/67
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
-
5/17/2018 04 Requirements
11/58310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 12/67
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
-
5/17/2018 04 Requirements
12/58310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 14/67
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
-
5/17/2018 04 Requirements
13/58310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 17/67
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
-
5/17/2018 04 Requirements
14/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 18/67
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
-
5/17/2018 04 Requirements
15/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 19/67
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
-
5/17/2018 04 Requirements
16/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 21/67
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?
-
5/17/2018 04 Requirements
17/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 22/67
DOMAIN MODEL KEEPING THE RIGHTDOMAIN MODEL KEEPING THE RIGHT
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?
-
5/17/2018 04 Requirements
18/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 23/67
DOMAIN MODEL KEEPING THE RIGHTDOMAIN MODEL KEEPING THE RIGHT
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?
-
5/17/2018 04 Requirements
19/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 24/67
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
-
5/17/2018 04 Requirements
20/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 25/67
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
-
5/17/2018 04 Requirements
21/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 26/67
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
-
5/17/2018 04 Requirements
22/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 27/67
District
*
11
*
LivesInLivesIn
DOMAIN MODEL DETAIL GENERALIZATIONDOMAIN MODEL DETAIL GENERALIZATION
(contd)(contd)
Person
StudentProfessor
District* 1LivesIn
-
5/17/2018 04 Requirements
23/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 28/67
*
1
LivesIn
DOMAIN MODEL DETAIL GENERALIZATIONDOMAIN MODEL DETAIL GENERALIZATION
(contd)(contd)
1
*
*
11
*
LivesInLivesIn
Person
StudentProfessor
District
StudiesIn
-
5/17/2018 04 Requirements
24/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 29/67
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)
-
5/17/2018 04 Requirements
25/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 30/67
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).
-
5/17/2018 04 Requirements
26/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 31/67
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.
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.
-
5/17/2018 04 Requirements
27/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 32/67
DOMAIN MODELING EXAMPLE ANALYSISDOMAIN MODELING EXAMPLE ANALYSIS
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).
-
5/17/2018 04 Requirements
28/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 33/67
DOMAIN MODELING EXAMPLE ANALYSISDOMAIN MODELING EXAMPLE ANALYSIS
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.
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 rentedvideos to the store's inventory.
-
5/17/2018 04 Requirements
29/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 34/67
DOMAIN MODELING EXAMPLE ANALYSISDOMAIN MODELING EXAMPLE ANALYSIS
When selling or renting videos, staff must be able to look up customer information and
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).
2 2 1; 2 4 1
-
5/17/2018 04 Requirements
30/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 36/67
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
-
5/17/2018 04 Requirements
31/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 37/67
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
-
5/17/2018 04 Requirements
32/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 38/67
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
-
5/17/2018 04 Requirements
33/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 40/67
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
-
5/17/2018 04 Requirements
34/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 41/67
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
-
5/17/2018 04 Requirements
35/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 42/67
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.
-
5/17/2018 04 Requirements
36/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 43/67
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
-
5/17/2018 04 Requirements
37/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 44/67
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
-
5/17/2018 04 Requirements
38/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 45/67
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
-
5/17/2018 04 Requirements
39/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 46/67
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
-
5/17/2018 04 Requirements
40/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 48/67
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
-
5/17/2018 04 Requirements
41/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 49/67
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.)
-
5/17/2018 04 Requirements
42/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 50/67
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
-
5/17/2018 04 Requirements
43/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 51/67
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
-
5/17/2018 04 Requirements
44/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 52/67
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
represents adesign decision!
include use case(usually not invoked
directly by user)
main use cases
(invoked directly
by user)
2.4.1; 4.4.5
-
5/17/2018 04 Requirements
45/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 53/67
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
represents adesign decision!
extensionpoint label
4.4.7
-
5/17/2018 04 Requirements
46/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 54/67
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
-
5/17/2018 04 Requirements
47/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 55/67
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
-
5/17/2018 04 Requirements
48/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 56/67
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.
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)
-
5/17/2018 04 Requirements
49/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 57/67
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.
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).
-
5/17/2018 04 Requirements
50/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 58/67
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.
-
5/17/2018 04 Requirements
51/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 59/67
USE-CASE MODELING EXAMPLE ANALYSISUSE-CASE MODELING EXAMPLE ANALYSIS
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.
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.
-
5/17/2018 04 Requirements
52/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 60/67
USE-CASE MODELING EXAMPLE ANALYSISUSE-CASE MODELING EXAMPLE ANALYSIS
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.
-
5/17/2018 04 Requirements
53/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 61/67
USE-CASE MODELING EXAMPLE ANALYSISUSE-CASE MODELING EXAMPLE ANALYSIS
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.
-
5/17/2018 04 Requirements
54/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 62/67
USE-CASE MODELING EXAMPLE ANALYSISUSE-CASE MODELING EXAMPLE ANALYSIS
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
-
5/17/2018 04 Requirements
55/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 64/67
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
-
5/17/2018 04 Requirements
56/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 65/67
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
-
5/17/2018 04 Requirements
57/58
310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE 66/67
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)
-
5/17/2018 04 Requirements
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