310313 requirements capture 1 system requirements capture 310313 software engineering 310313...

310313310313 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE1

SYSTEM REQUIREMENTS CAPTURESYSTEM REQUIREMENTS CAPTURESYSTEM REQUIREMENTS CAPTURESYSTEM REQUIREMENTS CAPTURE

310313310313SOFTWARE ENGINEERINGSOFTWARE ENGINEERING

310313310313SOFTWARE ENGINEERINGSOFTWARE ENGINEERING


LEARNING OBJECTIVES

1 Understand the rrrr rrr rr rrrrrrrr of requirements capture in

the software development process

2 Knowt he major act ivit ies rrrr rrrr rrrrr rrrrrr rrrrrrrr rrrr capture

3 Under st and t hat t he maj or i t y of syst emr equi r ement s can be

captured by building two models domain model rrr rrr-rrrr model

4 Learn how to capt ur e rrr model rrr rrrr r equi r ement s rrr rrr

pr ocessi ng requirements r rrrrrr r

5 Learn how to design accept ance t est s to validate the system

requirements 6 Know the characterist ics of people rrrr rrrrr rrrrr rrr rrrrrrrr

should understand to build effect ive user interfaces


SYSTEM REQUIREMENTS CAPTURE OUTLINESYSTEM REQUIREMENTS CAPTURE OUTLINE

System Requirements Capture mdash Unified Process Overviewndash Importance amp Difficulty

ndash Capturing amp Documenting Requirements

ndash Life Cycle Role

System Requirements Capture mdash Unified Process Activitiesndash Domain Modeling

ndash Use-Case Modeling

ndash User-interface Specification amp Prototyping

ndash System Requirements Validation

4



SYSTEM REQUIREMENTS CAPTURELIFE CYCLE ROLE System requirements capture constructs two main models

ndash domain model describes the systemrsquo s static (data) requirements

ndash - use case model describes the systemrsquo s dynamic (processing)

requirements - The domain model and use case model are developed over several dev

elopment incrementsmdashgoing first breadth then depth (mainly during the inception and elaboration phases)

ndash inception phase identify most domain model elements and use cases in ord er to delimit the system and scope the project (detail th most critical use cas es ndash less than 10)

ndash elaboration phase capture most (80) of the remaining

requirements so we can estimate the size of the development effort

ndash construction phase capture remaining requirements and implement

the system

ndash transition phase no requirements capture unless there are changing requirements

requirements capture is

in focus here


ARTIFACTS amp WORKERSARTIFACTS amp WORKERS

Use-CaseSpecifier

Use-CaseSpecification

responsiblefor

User-InterfaceDesigner

User-interfaceSpecification amp

Prototyping

responsiblefor

Architect

ArchitectureDescription

responsiblefor

DomainAnalyst

responsiblefor

DomainSpecification

SystemAnalyst

DomainModel Actors GlossaryUse-Case

Model

responsible for


SYSTEM REQUIIREMENTS CAPTURE WORKRS

The system analyst is responsible for the whole set of

requirements He delimits the system and finds classes

associations actors and use cases

T he domain analyst assists the system analyst in specifying

detailed descriptions of one or more classes and their

associations

The - use case specifier assists the system analyst in specifying

detailed descriptions of one or more use cases He works

closely with users of use case(s)

The - user interface designer visually shapes the user interface

The architect describes the architectural view of the -use case

model and selects architecturally significant use cases


SYSTEM REQUIIREMENTS CAPTURE ARTIIFACTS

The domain model is a model of the persistent classes and their associations in the context of the system It captures data requirements

The - use case model is a model of the system containing actors and use cases a nd their relationships It captures functional requirements

The actors are users of the system outside the system that collaborate with the system They represent the external environment of the system

The glossary defines important and common terms used by analysts and otherdevelopers

The domain specification is a description of the classes and associations in the domain model

The use case specification is a description of some functionality that the syste m offers for an actor It is abstraction of a set of scenarios

The - user interface specification amp prototyping helps in understanding and sp ecifying the interactions between human actors and the system

The architecture description depicts the architecturally significant use cases (5- 10) Those that describe some important and critical functionality or that involv

e some important requirement that must be developed early in the systems life c ycle It is used as input when use cases are prioritized for development


SYSTEM REQUIREMENTS CAPTURESYSTEM REQUIREMENTS CAPTURE

requirement

a feature that the system must have or a constraint that it must satisfy to be accepted by the customer

requirements capture (gathering elicitation ) learning about the problem that needs a solution specifying (in detail) the required featuresconstraints of the system in

a way that the customeruser understands and can approve

The results of requirements capture also help in project planningThe results of requirements capture also help in project planning

requires the collaboration ofseveral groups of participants with different backgrounds

KnowledgeKnowledgeGAPGAP


4


Reasons for failure ofproblems with software development

incomplete requirements 131

lack of user involvement 124

lack of resources 106

unrealistic expectations 99

lack of executive support 93

changing requirements and specifications 87

lack of planning 81

system no longer needed 75








lack of planning 81


IMPORTANCE OF REQUIREMENTS CAPTURE mdash 1IMPORTANCE OF REQUIREMENTS CAPTURE mdash 1

Requirements capture is involved in a majority of cases

gt 50

41


IMPORTANCE OF REQUIREMENTS CAPTURE mdash 2IMPORTANCE OF REQUIREMENTS CAPTURE mdash 2cost to findand fix a defect

logscale

1

10

100

Reqmts

075

Design

100

Code

150

Test

300

Systemtest

1000

Fielduse

60-100

BUT requirements capture is VERY DIFFICULT


WHY REQUIREMENTS CAPTURE IS DIFFICULTWHY REQUIREMENTS CAPTURE IS DIFFICULT

Our aim is to build the right system

a system that meets the usersrsquo needs

but users often do not know what they needndash many types of users (only know their own work and needs)

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

ndash may not know which aspects of their work can be computerized

for the software engineer requirements capture is often aldquodiscovery and learningrdquo process

need to get users to understand what we havecaptured and to approve that it meets their needs

users need to be able to understand our specifications

but user is usually not a computer specialist

Majorchallenges


REQUIREMENTS CAPTURE PROCESS mdash REQUIREMENTS CAPTURE PROCESS mdash OVERVIEWOVERVIEW

Identify and understand user needsndash define the goals of the system ndash compile list of system constraints

ndash compile list of candidate requirements ndash define development effort scope

Determine feasibilityndash economic feasibility ndash operational feasibility

ndash technical feasibility ndash organizational impact

Understand capture and document system requirementsndash static (persistent data) ndash dynamic (processing + constraints)

(domain model + specifications) (use-case model + specifications)

Validate the system requirementsndash criteria for user acceptance of the completed system (acceptance tests)

System Requirements Specification (SRS) documents requirements (Serves as a contract between the client and developer)



USER NEEDS mdash IDENTIFICATIONUSER NEEDS mdash IDENTIFICATION

collect data on application domain (may include existing system)

investigation existing documentationobservation work practicesinterviews questionnaires personalprototyping interface functions

ndash In doing so it is important to elicit problems not solutions distinguish needs (critical) from

wants (nice to have) prioritize needs challenge clientrsquosusersrsquo model of the world

Define the scope of the development effort

ndash What is insideoutside the system Who decides

Define the systemrsquos design goals

ndash What ldquoqualitiesrdquo do we want the system to have

451

Effective communication skills needed to gatherrequirements


FEASIBILITY DETERMINATIONFEASIBILITY DETERMINATION

Can weshould we build the system

economic feasibilityndash costs (development operation) versus benefitsndash tangible versus intangible

technical feasibilityndash availability of technology risk of new technologyndash maintenance required

operational feasibilityndash availability of skills to operate the systemndash fit with current work practices (redesign work practices)

organizational feasibilityndash politics training user acceptance

legal feasibilityndash liability copyright patent


CAPTURE AND DOCUMENT SYSTEM REQUIREMENTSCAPTURE AND DOCUMENT SYSTEM REQUIREMENTS

static requirements (persistent data) domain modeldescribes 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 modelfunctional requirements - describe the interactions between the system

and its environment independent of its implementationnonfunctional requirements - describe user-visible aspects of the system

that are not directly related with the functional behaviour of the system eg response time throughput security etc

pseudo requirements - describe restrictions on the implementation of the system imposed by the customer

eg implementation language platform etc

Requirements should only statewhat is needed not how it is done


UP mdash SYSTEM REQUIREMENTS CAPTURE PROCESSUP mdash SYSTEM REQUIREMENTS CAPTURE PROCESS

Architect

SystemAnalyst

Use-CaseSpecifier

Find Classesand Associations

PrioritizeUse Cases

PrototypeUser-Interface

DetailUse Cases

Structure theUse-Case Model


Find Actors andUse Cases

DomainAnalyst

Detail Classesand Associations


DOMAIN MODELINGDOMAIN MODELING

Domain modeling captures the most important classes and their associations in the context of the system

things that exist or events that occur in the systemrsquos environment

The class and association are found fromndash high-level problem statement --a specification of user needsndash domain experts (users) -- by collecting data amp identifying user

needs

It is imperative that this be done well so as to establish a solid foundation and to allow reuse by other systems

The classes can bendash business objects (eg orders accounts etc)ndash real-world objects and concepts (eg suppliers customers etc)ndash events (eg aircraft arrivaldeparture sales reservations etc)

described in a class diagram static system structure


IDENTIFYING CLASSES amp ASSOCIATIONSIDENTIFYING CLASSES amp ASSOCIATIONS

Naturally occurring things or concepts in the application domainndash classes often appear as nounsnoun phrases in application

domain terminology

ndash associations often appear as verbsverb phrases in application domain terminology

Circle or highlight in problem description

Put all terms into singular formactive voice

decompositiondecomposition of a problem into classes and associations of a problem into classes and associations dependsdepends on on judgementjudgement and and experienceexperience and the and the nature of the problemnature of the problem


identify only relevant classes those that are essential throughout the systemrsquos life cycle

leads to a stable system


ASU mdash COURSE REGISTRATION PROBLEM STATEMENTASU mdash COURSE REGISTRATION PROBLEM STATEMENT

At the beginning of each semester students may request a course catalog containing a list of course offerings needed for the semester Information about each course 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 coming semester In addition each student will indicate two alternative choices in case a course offering becomes filled or is canceled No course offering will have more than forty students or fewer than ten students A course offering with fewer than ten students 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 be billed for the semester

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 their schedule Students must be able to access the system during this time to add or drop courses


ASU POSSIBLE CLASSES

At the beginning of each semester students may request a course catalog containing a list of course offerings needed for the semester

Information about each course 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 coming semester

In addition each student will indicate two alternative choices in case a course offering becomes filled or is canceled



No course offering will have more than forty students or fewer than ten students

A course offering with fewer than three students 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 be billed for the semester




For each semester there is a period of time that students can change their schedule

Students must be able to access the system during this time to add or drop courses


ASU POSSIBLE ASSOCIATIONS


















DOMAIN MODEL mdash DOMAIN MODEL mdash KEEPING THE RIGHT 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


DOMAIN MODELmdash DOMAIN MODELmdash KEEPING THE RIGHT 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

Do any associations describe implementation constructs


IDENTIFYING ATTRIBUTESIDENTIFYING ATTRIBUTES

Usually correspond to nouns followed by possessive phrases

ndash eg password of the student studentrsquo s address

Adj ect i ves usually represent specific enumerated values

ndash eg Fall semester PhD degree

Attributes are likely to be fully specified in the problem statement

Draw on knowledge of the application domain and real world

Onl y speci f y at t ributes that direct ly relate to the application

domain Most attributes will not be given in a problem statement and will have to be obtained from domain experts or application documentation


DOMAIN MODEL mdash DOMAIN MODEL mdash KEEPING THE RIGHT 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


DOMAIN MODEL DETAILmdash DOMAIN MODEL DETAILmdash CLASSES amp CLASSES amp ASSOCIATIONSASSOCIATIONS For each class we can add any operations that we are aware

of at this stage

most operations will be added during analysis amp design

For each association we need to specify (if known)ndash a name (optional)--gtshould sayrdquowhatrdquo not ldquohowrdquo or ldquowhyrdquo

ndash role names (as necessary)

ndash Multiplicity (If Known)

ndash association class (if necessary)

Place all domain model terms and their definitions in a

glossary of termsdata dictionary


DOMAIN MODEL DETAILmdash ATTRIBUTESDOMAIN MODEL DETAILmdash ATTRIBUTES

Meaningful name

itemPrice not itpr

Allowable values continuous - a range of values

price $0 to $10000need to note range

typical valuesexception

handling discrete - only allow certain values

marital-status single married widowed divorced

need to note values and meaning of each (if coded)

Short descriptionpayment - a transaction to record a

remittancedeposit - the initial amount paid by the

company on a purchase order

Aliases synonyms - same meaning but

different namecustomer = client

acronyms - shortened namerequisitionNumber = requisNum reqNo

Length ndash as found in the real world need to notenumber of digits or

letters

Encoding - physical representation of the value

only if no choice allowed in design phase

Supplementary - other information relevant to use of the attribute


DOMAIN MODEL DETAIL mdash GENERALIZATIONDOMAIN MODEL DETAIL mdash GENERALIZATION

Classify classes according to similarity of attributes and operations

look for ldquokind-ofrdquo statements that are true in the real world

Do not nest too deeplyndash 2-3 levels OK

ndash 4-6 levels maybe

ndash 10 levels too deep

GoalGoal simplicity of representation and modeling clarity


District

11

LivesInLivesIn

DOMAIN MODEL DETAIL mdash GENERALIZATION DOMAIN MODEL DETAIL mdash GENERALIZATION (contrsquod)(contrsquod)

Person

StudentProfessor

District 1LivesIn


1

LivesIn


1

11

LivesInLivesIn

Person

StudentProfessor

District

StudiesIn


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 and allow its customers to rent and buy videos via the Web Below are the high-level requirements for a system that will manage the sale and rental of videos for the video shopndash The system must be able to keep track of which movie videos have been

boughtrented and by whom For videos bought the system must record the quantity bought for videos rented the system must record which copy of the video has been rented and when it is due back

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

ndash 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

ndash Members should be able to make reservations for movie video rentals either in person at the store by telephone or via the Web

ndash A member can reserve at most five movie videos at any one time but there is no limit on how many movie videos a member or nonmember can rent at any one time

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


USE-CASE MODELING EXAMPLE (contrsquod)USE-CASE MODELING EXAMPLE (contrsquod)

and a rating (from 1 lowest to 5 highest) of movies they have rented These reviews should be anonymous if the customer so wishes (ie the customer can specify whether or not he wants his name to be made known when other customers browse the reviews)

ndash 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 membership number by the video shop when they become members and a password which allows them to access the members-only area of the video shops web site including accessing and changing their personal information

ndash Using the Web customers should be able to buy and rent videos and browse the reviews entered by other customers

ndash Managers must be able to generate various reports on salesrentals of videosndash Staff must be able to sellrent videos from the storersquos inventory and return rented

videos to the stores inventoryndash When selling or renting videos staff must be able to look up customer information

and determine whether the customer is a memberndash An employee must be able to enter the basic information about a movie video

(ie title leading actor(s) director producer genre synopsis release year running time selling price and rental price)


DOMAIN MODELING EXAMPLE mdash DOMAIN MODELING EXAMPLE mdash ANALYSISANALYSIS

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

ndash The system must be able to keep track of which movie videos have been boughtrented and by whom

ndash For videos bought the system must record the quantity bought for videos rented the system must record which copy of the video has been rented and when it is due back









ndash 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

ndash These reviews should be anonymous if the customer so wishes (ie the customer can specify whether or not he wants his name to be made known when other customers browse the reviews)

ndash The video shop maintains the following information about all customers (members or nonmembers) name address phone number fax number age sex and

email address



ndash In addition members are assigned a membership number by the video shop when they become members and a password which allows them to access the members only area of the video shops web site including accessing and changing their personal information


ndash Managers must be able to generate various reports on salesrentals of videos

ndash Staff must be able to sellrent videos from the storersquos inventory and return rented videos to the stores inventory



ndash When selling or renting videos staff must be able to look up customer information and determine whether the customer is a member

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


UP mdash UP mdash SYSTEM REQUIREMENTS CAPTURE ACTIVITIESSYSTEM REQUIREMENTS CAPTURE ACTIVITIES

Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst



USE-CASE MODELINGUSE-CASE MODELING

Captures the system behavior from the usersrsquo point of view

Developed in cooperation with the domain model

Helps inndash capturing data and functional requirements

ndash planning iterations of development

ndash validating the system

The dynamic model gets started with use-case analysis Use cases drives the entire development effort

The use-case model is developed incrementally

221 241

All required functionality is described in the use cases


An An actoractor represents something represents something outsideoutside the system that the system that interacts interacts directlydirectly with it with it

USE CASE MODEL mdash ACTORSUSE CASE MODEL mdash ACTORS

actor name

Actors are the source for discovering use cases

441

Can be people or other systems

Provides input to or takes output from the system

A role a user can play multiple roles per user multiple users per role

An actor is a stereotype of class

an actor is a classifier a specific user is an instance


IDENTIFYING ACTORSIDENTIFYING ACTORS

Who or what uses the system What roles do they play in the interaction Who gets and provides information to the system Who installs starts and shuts down or maintains the system What other systems interact with this system Does anything happen at a fixed time

Input output devices are not actors

It is common to have both a domain model classand an actor that represent the same thing

Time can be an actor

For each actor briefly the describe role it playswhen interacting with the system


USE CASE MODEL mdash USE CASEUSE CASE MODEL mdash USE CASE

A A use caseuse case is a specific way of using the system by is a specific way of using the system by performingperforming some part of its some part of its functionalityfunctionalityuse-case name

Initially we are only concerned with the normal or usual sequence of eventsactions

Ignore exceptions alternate ways of doing things

241 443

Specifies the interaction that takes place between an actor and the system considered from the userrsquos viewpoint

Constitutes a complete sequence of eventsactions initiated by an actor

A use case is a stereotype of UML class

use case is a classifier scenario is an instance


USE-CASE MODEL mdash SCENARIOUSE-CASE MODEL mdash SCENARIO

A A scenarioscenario is a is a concreteconcrete focusedfocused informal descriptioninformal description of a of a single use of the systemsingle use of the system from the from the viewpoint of a single actorviewpoint of a single actor


It is an actual attempt to carry out a use case

Note There are two viewpoints of use-case modeling

1 top-down start with use cases refine with scenario

2 Bottom-up start with scenarios abstract use cases

ndash In reality the use-case specfier uses both viewpoints

241 442

BUT scenarios are mostly used to describe errors and alternate flows


IDENTIFYING USE CASES AND SCENARIOSIDENTIFYING USE CASES AND SCENARIOS What are the tasks that an actor wants the system to

perform What information does an actor access (create store

change remove or read) in the system Which external changes does an actor need to inform the

system about Which events does an actor need to be informed about by

the system How will the system be supported and maintained

State a use case name should be stated from the perspective of the user as a present-tense verb phrase in active voice

Provide a description of the purpose of the use caseand a high-level definition of its functionality

use application domain terms in descriptions


ASU mdash USE CASESASU mdash USE CASES







No course offering will have more than ten students or fewer than three students A course offering with fewer than three students will be canceled








USE CASE DETAIL mdash USE CASE SPECIFICATIONUSE CASE DETAIL mdash USE CASE SPECIFICATION

use case name (present-tense verb phase in active voice)

participating actors (invoked by communicates with )

preconditions (usually on the system state relevant to this use case)ndash Things that must be true before the use case can execute

flow of eventsndash the required order of actions the normal sequence of eventsndash what interaction the use case has with the actorsndash what data is needed by the use case

postconditions (usually on the system state relevant to this use case)ndash things that must be true at the end of the use case execution

special requirements (if any)

alternate or exceptional flows (if any)


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

A A preciseprecise but but easy to readeasy to read description of the description of the sequence sequence of actionsof actions needed to needed to accomplish a scenariouse caseaccomplish a scenariouse case


What the system and the actor should do to perform the actions(not how it is done ignore use case interactions)

Basic path shows one complete normal path from start to end mdash no errors no exceptions (always required)

Alternate paths show exceptional conditions or errors

Start with basic path then add alternate paths as needed

(So as to specify everything the user might do)

Narrative should be event-response oriented (ie The system does X The user does Y etc)


USE CASE DETAIL mdash FLOW OF EVENTS USE CASE DETAIL mdash FLOW OF EVENTS SPECIFICATIONSPECIFICATION

branchingn If boolean-expression

n1 declarative-statementn2 declarative-statementn3 hellip

n+1

repetition Forn For iteration-expression


n+1

repetition Whilen While boolean-expression


n+1

sequence of short steps that are numbered declarative and time-ordered

n The something some-action (eg 3 The user enters a login id)

radic repetition should be used sparingly

radic use-case specification should be kept as simple as possible

This is a suggested format only


USE-CASE MODEL DETAIL mdash GENERALIZATIONUSE-CASE MODEL DETAIL mdash GENERALIZATION

Since actors and use cases are Since actors and use cases are classifiers they can be generalizedclassifiers they can be generalized


ManagerSales clerk

The uses of generization represents a design decision

EmployeeValidate user

Check password Retinal scan

241


USE-CASE DETAIL mdash INCLUDEUSE-CASE DETAIL mdash INCLUDE

many use cases may share pieces of the same functionality

we can factor out this functionality place it in a separate use case and relate it to all use cases that need to use it by an ltltincludegtgt relationship

Validate user

ltltincludegtgt

Register for courses Select courses to teach Request enrollment list

ltltincludegtgtltltincludegtgt

The use of an ltltincludegtgt relationshiprepresents a design decision

include use case(usually not invokeddirectly by user)

main use cases(invoked directlyby user)

241 445


It models conditional additionsto a use casersquos sequence of actions

It is used to showndash optional behavior

ndash behavior that is executed only under certain conditions

ndash several different subflows that are executed based on the selection of a particular actor

USE-CASE DETAIL mdash USE-CASE DETAIL mdash EXTENDEXTEND

Specifies how a use case description may be inserted into and thus extend an existing use case

ltltextendgtgt(semester invalid)

Select courses to teach

extenduse case

main use case

Invalid semester

The use of an ltltextendgtgt represents a design decision

extensionpoint label

241 445


USE-CASE DETAILUSE-CASE DETAIL mdash mdash EXTENDEXTEND(contrsquorsquod)(contrsquorsquod)

1 The laquoextendraquo relationship includes both a rrrrrrrrr rrr rrr rrrrrrrrr rrr r reference to an extension point rr rrr r rrr rrr

2 The main use case must be a complete flow of events in itself

rrrrr rr rr rrrrrrrrrrr rrr rrrrrr( )ndash We describe the main use case totally independent of any extended fu

nctionality

3 The main use case pays no attention to any flow of events that

might be inserted

ndash We can add new extensions without (functionally) changing the descri ption of the main use case

4 We can view an extension as rr rrrrrrrrr in the main use case

rrr rrrrrrrr rrr rrrr rr rr rr rrrrrrrrrlaquo raquo


USE CASES THROUGH THE DEVELOPMENTUSE CASES THROUGH THE DEVELOPMENT

Planningndash Basis for negotiation with customer

determine which use cases to provide in the first release

Political aspectsndash Demonstrate the system doing something valuable to the most

influential people first use knowledge about how much each user wants their use case

Technical aspectsndash Deliver the highest risk use cases first

use knowledge from risk analysis

System validationndash ldquowalk the use caserdquo to see if it can provide the required functionality




















USE-CASE MODELING EXAMPLE mdash USE-CASE MODELING EXAMPLE mdash ANALYSISANALYSIS

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 are only really interested in those functional requirements that provide something of value for some actor













ndash The video shop maintains the following information about all customers (members or nonmembers) name address phone number fax number age sex and email address



ndash In addition members are assigned a membership number by the video shop when they become members and a password which allows them to access the members-only area of the video shops web site including accessing and changing their personal information






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



WHAT IS A GOOD USE CASEWHAT IS A GOOD USE CASE

A use case typically represents a major piece of functionality that is complete from beginning to end

A use case must deliver something of value to an actor

Consider students in ASU Course Registration Systemndash select coursesndash be added to course offeringsndash be billed

deals with one completesequence of eventsactions

Consider Registrar in ASU Course Registration Systemndash add coursesndash delete coursesndash modify courses

deals with the sameclass of objects

Generally it is better to have Generally it is better to have longerlonger and and more more extensiveextensive use cases than smaller ones use cases than smaller ones



NONFUNCTIONAL REQUIREMENTSNONFUNCTIONAL REQUIREMENTS

Interface ndash specifies requirements on the interface to an external system

or sets constraints on formats timing etc

Physical ndash specifies hardware requirements (eg implementation platform)

Design ndash constrains the design to have certain qualities (eg speed

throughput response time maintainability reliability etc)

Implementation ndash specifies or constrains the coding or construction of the

system (eg standards languages resource limits etc)

Management ndash schedule budget etc

447

Nonfunctional requirements are captured as supplementary requirements on use cases or on the system as a whole

A user-visible system property that cannot be expressed as

a use case but often places constraints on a use case




IDENTIFYING NONFUNCTIONAL REQUIREMENTSIDENTIFYING NONFUNCTIONAL REQUIREMENTS

To help identify nonfunctional requirements some categories to consider and

trigger questions to ask for each category are given below

1 User Interface and Human Factors

ndash What type of user will be using the system

ndash Will more than one type of user be using the system

ndash What sort of training will be required for each type of user

ndash Is it particularly important that the system be easy to learn

ndash Is it particularly important that users be protected from making errors

ndash What sort of inputoutput devices for the human interface are available and

what are their characteristics

2 Documentation

ndash What kind of documentation is required

ndash What audience is to be addressed by each document

3 Hardware Considerations

ndash What hardware is the proposed system to be used on

ndash What are the characteristics of the target hardware including memory size

and auxiliary storage space


IDENTIFYING NONFUNCTIONAL REQUIREMENTSIDENTIFYING NONFUNCTIONAL REQUIREMENTS4 Performance Characteristics

ndash Are there any speed throughput or response time constraints on the

system

ndash Are there size or capacity constraints on data processed by the system

5 Error Handling and Extreme Conditions

ndash How should the system respond to input errors

ndash How should the system respond to extreme conditions

6 System Interfacing

ndash Is input coming from systems outside the proposed system

ndash Is output going to systems outside the proposed system

ndash Are there restrictions on the format or medium that must be used for input

or output

7 Quality Issues

ndash What are the requirements for reliability

ndash Must the system trap faults

ndash Is there a maximum acceptable time for system restart after a failure

ndash What is the acceptable system downtime per 24-hour period

ndash Is it important that the system be portable (able to move to different

hardware or operating system environments)



8 System Modifications

ndash What parts of the system are likely candidates for later modification

ndash What sorts of modifications are expected

9 Physical Environment

ndash Where will the target equipment operate

ndash Will the target equipment be in one or several locations

ndash Will the environmental conditions in any way be out of the ordinary (for

example unusual temperatures vibration magnetic fields)

10 Security Issues

ndash Must access to any data or the system itself be controlled

ndash Is physical security an issue

11 Resources and Management Issues

ndash How often will the system be backed up

ndash Who will be responsible for the back up

ndash Who is responsible for system installation

ndash Who will be responsible for system maintenance

Sourcehttpwwwcseeumbceducoursesundergraduate345spring04mitchellnfrhtml


REQUIREMENTS VALIDATIONREQUIREMENTS VALIDATION

Requirements should be continuously validated with the customer and the user and they should be

correct - represent the customerrsquos view of the system everything in the requirements model accurately represents

an aspect 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 specification two or more

different ways

realistic - the system can be implemented within the constraints

434


VALIDATE REQUIREMENTS mdash VALIDATE REQUIREMENTS mdash ACCEPTANCE TESTSACCEPTANCE TESTS

Functional validity ndash 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 ndash do interfaces perform desired functions (accept desired inputprovide desired output) and follow consistent design standards Show that all required data for course registration can be input

Information content ndash are the data structuresdata bases correct (store the right data in the required format) Show that all required information of a studentrsquos course schedule is shown

Performance ndash 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 will Tests must be specified that will demonstratedemonstrate to the customer that to the customer that all functionsall functions and and constraintsconstraints of a system are of a system are fully operationalfully operational



DERIVING AN ACCEPTANCE TEST PLANDERIVING AN ACCEPTANCE TEST PLAN

Restate written requirements in a concise precise and testable wayndash group related requirements

ndash remove any requirements that cannot be tested

Add any additional requirements gathered from usersndash look at use cases for functional and interface requirements

ndash look at domain model for information content requirements

ndash look at nonfunctional requirements for performance requirements

Construct for each requirement an evaluation scenario that will demonstrate to the customer that the requirement is met

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



Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst



USER INTERFACE (UI) SPECIFICATIONUSER INTERFACE (UI) SPECIFICATION

The UI establishes a dialog between the system and its userndash This dialog needs to be clear and unambiguous

UI specification determines what information passes between

the actors and the system through the UI and what the UI will

look likendash UI data inputoutput UI layout (look and feel) UI dialog structure

UI prototyping determines how the UI will function from the

userrsquos viewpoint and gathers user feedback to evaluate and

improve the UI

Developing a UI has as much to do with the Developing a UI has as much to do with the study of peoplestudy of people as with technology issuesas with technology issues



FACTORS IMPACTING ON UI DEVELOPMENTFACTORS IMPACTING ON UI DEVELOPMENT

To help ensure a better chance of success of the new system we need to look beyond just the technology


characteristics of the people (users)ndash physiology ndash cognitive abilitiesndash sensorymotor capabilities ndash cultural influences

characteristics of the tasksndash physical objects and events ndash concepts goals and plansndash perceptions and actions ndash purpose and value of the task

characteristics of the usersrsquo environmentndash the physical world ndash language and conceptsndash stimuliaffordances ndash society

An understanding of these factors willhelp us design better user interfaces


UI SPECIFICATION USERSUI SPECIFICATION USERS

Know who your users will beKnow who your users will be

not all users are the samendash different levels of expertise in problem domainndash different levels of knowledge of the systemndash different frequency of using the systemndash different need to use the system

they are not all like the designer

So whatSo what

we need tondash understand the differencesndash understand why the differences existndash design to deal with the differences

either exploit or minimize their effect


UI SPECIFICATION mdash USER TASKSUI SPECIFICATION mdash USER TASKS

We gather information on currentdesired tasks that will help in (re)designing tasks for the new system


top-down ndashgt look at a task as a meaningful unit of workeg register for courses

helps in understanding task goals anddesigning overall flow of steps in the new system use cases

containthis

information

The ultimate focus should be on task goals not task steps

identify breakdowns in current tasks

bottom-up ndashgt look at a task as a sequence of stepsactionseg specify semester and year

specify primary choicesspecify alternate choices etc

helps in understanding userrsquos goals andidentifying objects (data) involved in the task


UI REQUIREMENTS CAPTURE mdash UI ELEMENTSUI REQUIREMENTS CAPTURE mdash UI ELEMENTS

Try to identify breakdowns in current tasksTry to identify breakdowns in current tasks

A breakdown is a situation where the flow of the current task is

awkward or some goal cannot be satisfied due to current system

limitations

ndash These are opportunities for improvements in the new system


UI SPECIFICATION UI ELEMENTSUI SPECIFICATION UI ELEMENTS

Identify what data (attributes) the user will manipulateIdentify what data (attributes) the user will manipulate

Consider the actors that interact with each use case and ask

1 What information does the actor need to supply to the system

2 What information does the system need to supply to the actor

3 Which of the domain model classes are suitable as user-interface elements for the use case

4 What user-interface elements does the actor work with

5 What actions can the actor invoke and what decisions can the actor make

6 What guidance and information does the actor need before invoking each action in the use case


UI SPECIFICATION UI SPECIFICATION UI ELEMENTSUI ELEMENTS

For each UI display (screen) we need to decide what UI elements are needed how the UI elements will be represented

(eg text box menu etc) and where they will be placed



Can use

ndash sketch to get a rough idea of layout and look (eg can use

sticky notes or PowerPoint)

ndash prototype for the most important actors to get their feedback

We also need to verify that each UI display

ndash provides a consistent look and feel and way of working

ndash complies with standards (button size toolbar placement etc)


UI SPECIFICATION DIALOG DESCRIPTIONUI SPECIFICATION DIALOG DESCRIPTION

For each user task we construct a ldquomainlinerdquo dialog

description that describes what the user normally has to do to

complete the task using the UI (ignoring errors)

ndash This is a step-by-step description of how a user and the system

interact via the user interface to accomplish a task (ie a scenario)

A dialog should be described from the perspective of the user not the system

Dialog descriptions are analyzed procedurally to verify that the

steps involved are efficient and accomplish the desired task

ndash Can use sketches mock-ups prototyping etc

GOAL Seamlessness (When an object or function is need)

for a task in progress It is ldquoright thererdquo)


UI SPECIFICATION UI SPECIFICATION DIALOG STRUCTUREDIALOG STRUCTURE

We need to put individual dialogs together into a dialog structure for the systemrsquos user interface

ndash sequencing offlow between individual tasks

ndash optional versus required tasks

ndash dialog style menus forms commands function keys etc

ndash input aspects action language

ndash output aspects presentation language

there are many alternatives from which to choose

UI prototyping tools can help to get user feedbackand evaluate alternative dialog structures


UI SPECIFICATION GENERAL USABILITY UI SPECIFICATION GENERAL USABILITY PRINCIPLESPRINCIPLES Consistency

similar actions in similar situations

Closurendash organize actions so that the user

knows that a task has completed

Error handlingndash minimize usersrsquo opportunity to

make errors (eg keystrokes)

Reversibilityndash actions should be reversible

Controlndash users should always feel in

control of the interaction

Cognitive loadndash the load on the userrsquos short term

memory should be minimized

Accuracy amp completenessndash the information must be as

accurate and as complete when using the system as without it

Speedndash a task should not take longer to

do with the help of the system than without it

shortcuts can help

Feedbackndash there should be informative

feedback for every user action


UI SPECIFICATION UI SPECIFICATION EVALUATIONEVALUATION

We need to assess the usability of the UI and whether it meets

user requirements

This should be part of the normal testing process

We need a set of usability attributes part of design goals

eg learnability speed of operation robustness recoverability etc

Systematic formal evaluation can be expensive and time

consuming

Informal (ie less costly) evaluation techniques include

ndash questionnaires collect users1048577 opinions

ndash observations in person via video ldquothinking aloudrdquo sessions

ndash monitoring code to discover most used facilitiescommon errors


SYSTEM REQUIREMENTS CAPTURE SYSTEM REQUIREMENTS CAPTURE RETROSPECTIVERETROSPECTIVEDomain Modeling

Captures the static (database) requirements of an application

class diagram ndash shows classes and the relationships among them

Use-case Modeling

Captures the dynamic (processing) requirements of an application

use-case model ndash shows the use cases that provide the system

functionality and the actors that use the functionality

flow of events ndash describes the sequence of actions that

comprise a use casersquos functionality

Requirements Validation

Demonstrates that the system meets all stated requirements

acceptance test plan ndash details how the client verifies that the

requirements have been met

User Interface Specification and Prototyping

Demonstrates that the user interface meets all stated requirements


SUMMARY mdash SYSTEM REQUIREMENTS CAPTURESUMMARY mdash SYSTEM REQUIREMENTS CAPTURE

Requirements are captured over several iterations by specifyingndash a domain modelndash a use-case modelndash an acceptance test planndash initial user interfaces (and building some user interface prototypes)

These are all documented in theSystem Requirements Specification (SRS)

Use cases drive the subsequent iterationsphases

in subsequent iterationsphases we refine andor transform the requirements by specifyingndash more detail for each of the above artifactsndash matching use-case realizations in analysis modelndash matching use-case realizations in design modelndash a set of test cases in the test model


LEARNING OBJECTIVES

1 Understand the rrrr rrr rr rrrrrrrr of requirements capture in

the software development process

2 Knowt he major act ivit ies rrrr rrrr rrrrr rrrrrr rrrrrrrr rrrr capture

3 Under st and t hat t he maj or i t y of syst emr equi r ement s can be

captured by building two models domain model rrr rrr-rrrr model

4 Learn how to capt ur e rrr model rrr rrrr r equi r ement s rrr rrr

pr ocessi ng requirements r rrrrrr r

5 Learn how to design accept ance t est s to validate the system

requirements 6 Know the characterist ics of people rrrr rrrrr rrrrr rrr rrrrrrrr

should understand to build effect ive user interfaces










4












the system



in focus here



Use-CaseSpecifier


responsiblefor



Prototyping

responsiblefor

Architect


responsiblefor

DomainAnalyst

responsiblefor

DomainSpecification

SystemAnalyst


Model

responsible for








associations




















requirement








4









lack of planning 81









lack of planning 81




gt 50

41



logscale

1

10

100

Reqmts

075

Design

100

Code

150

Test

300

Systemtest

1000

Fielduse

60-100













Majorchallenges






















451






















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst







needs







domain terminology



















































































of at this stage










Meaningful name

itemPrice not itpr














letters













District

11

LivesInLivesIn


Person

StudentProfessor

District 1LivesIn


1

LivesIn


1

11

LivesInLivesIn

Person

StudentProfessor

District

StudiesIn



































email address













Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst











221 241





actor name


441


















241 443














241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling



























4












the system



in focus here



Use-CaseSpecifier


responsiblefor



Prototyping

responsiblefor

Architect


responsiblefor

DomainAnalyst

responsiblefor

DomainSpecification

SystemAnalyst


Model

responsible for








associations




















requirement








4









lack of planning 81









lack of planning 81




gt 50

41



logscale

1

10

100

Reqmts

075

Design

100

Code

150

Test

300

Systemtest

1000

Fielduse

60-100













Majorchallenges






















451






















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst







needs







domain terminology



















































































of at this stage










Meaningful name

itemPrice not itpr














letters













District

11

LivesInLivesIn


Person

StudentProfessor

District 1LivesIn


1

LivesIn


1

11

LivesInLivesIn

Person

StudentProfessor

District

StudiesIn



































email address













Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst











221 241





actor name


441


















241 443














241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling





























the system



in focus here



Use-CaseSpecifier


responsiblefor



Prototyping

responsiblefor

Architect


responsiblefor

DomainAnalyst

responsiblefor

DomainSpecification

SystemAnalyst


Model

responsible for








associations




















requirement








4









lack of planning 81









lack of planning 81




gt 50

41



logscale

1

10

100

Reqmts

075

Design

100

Code

150

Test

300

Systemtest

1000

Fielduse

60-100













Majorchallenges






















451






















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst







needs







domain terminology



















































































of at this stage










Meaningful name

itemPrice not itpr














letters













District

11

LivesInLivesIn


Person

StudentProfessor

District 1LivesIn


1

LivesIn


1

11

LivesInLivesIn

Person

StudentProfessor

District

StudiesIn



































email address













Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst











221 241





actor name


441


















241 443














241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling




















Use-CaseSpecifier


responsiblefor



Prototyping

responsiblefor

Architect


responsiblefor

DomainAnalyst

responsiblefor

DomainSpecification

SystemAnalyst


Model

responsible for








associations




















requirement








4









lack of planning 81









lack of planning 81




gt 50

41



logscale

1

10

100

Reqmts

075

Design

100

Code

150

Test

300

Systemtest

1000

Fielduse

60-100













Majorchallenges






















451






















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst







needs







domain terminology



















































































of at this stage










Meaningful name

itemPrice not itpr














letters













District

11

LivesInLivesIn


Person

StudentProfessor

District 1LivesIn


1

LivesIn


1

11

LivesInLivesIn

Person

StudentProfessor

District

StudiesIn



































email address













Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst











221 241





actor name


441


















241 443














241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling

























associations




















requirement








4









lack of planning 81









lack of planning 81




gt 50

41



logscale

1

10

100

Reqmts

075

Design

100

Code

150

Test

300

Systemtest

1000

Fielduse

60-100













Majorchallenges






















451






















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst







needs







domain terminology



















































































of at this stage










Meaningful name

itemPrice not itpr














letters













District

11

LivesInLivesIn


Person

StudentProfessor

District 1LivesIn


1

LivesIn


1

11

LivesInLivesIn

Person

StudentProfessor

District

StudiesIn



































email address













Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst











221 241





actor name


441


















241 443














241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling































requirement








4









lack of planning 81









lack of planning 81




gt 50

41



logscale

1

10

100

Reqmts

075

Design

100

Code

150

Test

300

Systemtest

1000

Fielduse

60-100













Majorchallenges






















451






















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst







needs







domain terminology



















































































of at this stage










Meaningful name

itemPrice not itpr














letters













District

11

LivesInLivesIn


Person

StudentProfessor

District 1LivesIn


1

LivesIn


1

11

LivesInLivesIn

Person

StudentProfessor

District

StudiesIn



































email address













Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst











221 241





actor name


441


















241 443














241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling


























lack of planning 81









lack of planning 81




gt 50

41



logscale

1

10

100

Reqmts

075

Design

100

Code

150

Test

300

Systemtest

1000

Fielduse

60-100













Majorchallenges






















451






















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst







needs







domain terminology



















































































of at this stage










Meaningful name

itemPrice not itpr














letters













District

11

LivesInLivesIn


Person

StudentProfessor

District 1LivesIn


1

LivesIn


1

11

LivesInLivesIn

Person

StudentProfessor

District

StudiesIn



































email address













Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst











221 241





actor name


441


















241 443














241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling




















logscale

1

10

100

Reqmts

075

Design

100

Code

150

Test

300

Systemtest

1000

Fielduse

60-100













Majorchallenges






















451






















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst







needs







domain terminology



















































































of at this stage










Meaningful name

itemPrice not itpr














letters













District

11

LivesInLivesIn


Person

StudentProfessor

District 1LivesIn


1

LivesIn


1

11

LivesInLivesIn

Person

StudentProfessor

District

StudiesIn



































email address













Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst











221 241





actor name


441


















241 443














241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling





























Majorchallenges






















451






















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst







needs







domain terminology



















































































of at this stage










Meaningful name

itemPrice not itpr














letters













District

11

LivesInLivesIn


Person

StudentProfessor

District 1LivesIn


1

LivesIn


1

11

LivesInLivesIn

Person

StudentProfessor

District

StudiesIn



































email address













Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst











221 241





actor name


441


















241 443














241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling







































451






















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst







needs







domain terminology



















































































of at this stage










Meaningful name

itemPrice not itpr














letters













District

11

LivesInLivesIn


Person

StudentProfessor

District 1LivesIn


1

LivesIn


1

11

LivesInLivesIn

Person

StudentProfessor

District

StudiesIn



































email address













Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst











221 241





actor name


441


















241 443














241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling






































Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst







needs







domain terminology



















































































of at this stage










Meaningful name

itemPrice not itpr














letters













District

11

LivesInLivesIn


Person

StudentProfessor

District 1LivesIn


1

LivesIn


1

11

LivesInLivesIn

Person

StudentProfessor

District

StudiesIn



































email address













Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst











221 241





actor name


441


















241 443














241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling























needs







domain terminology



















































































of at this stage










Meaningful name

itemPrice not itpr














letters













District

11

LivesInLivesIn


Person

StudentProfessor

District 1LivesIn


1

LivesIn


1

11

LivesInLivesIn

Person

StudentProfessor

District

StudiesIn



































email address













Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst











221 241





actor name


441


















241 443














241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling





















domain terminology



















































































of at this stage










Meaningful name

itemPrice not itpr














letters













District

11

LivesInLivesIn


Person

StudentProfessor

District 1LivesIn


1

LivesIn


1

11

LivesInLivesIn

Person

StudentProfessor

District

StudiesIn



































email address













Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst











221 241





actor name


441


















241 443














241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling





























































































of at this stage










Meaningful name

itemPrice not itpr














letters













District

11

LivesInLivesIn


Person

StudentProfessor

District 1LivesIn


1

LivesIn


1

11

LivesInLivesIn

Person

StudentProfessor

District

StudiesIn



































email address













Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst











221 241





actor name


441


















241 443














241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling




















Meaningful name

itemPrice not itpr














letters













District

11

LivesInLivesIn


Person

StudentProfessor

District 1LivesIn


1

LivesIn


1

11

LivesInLivesIn

Person

StudentProfessor

District

StudiesIn



































email address













Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst











221 241





actor name


441


















241 443














241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling



























District

11

LivesInLivesIn


Person

StudentProfessor

District 1LivesIn


1

LivesIn


1

11

LivesInLivesIn

Person

StudentProfessor

District

StudiesIn



































email address













Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst











221 241





actor name


441


















241 443














241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling



















1

LivesIn


1

11

LivesInLivesIn

Person

StudentProfessor

District

StudiesIn



































email address













Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst











221 241





actor name


441


















241 443














241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling




















































email address













Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst











221 241





actor name


441


















241 443














241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling






























Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst











221 241





actor name


441


















241 443














241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling



























221 241





actor name


441


















241 443














241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling





















actor name


441


















241 443














241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling






























241 443














241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling



























241 442

















































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling

































































n+1



n+1



n+1










ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling






















ManagerSales clerk




241





Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling






















Validate user

ltltincludegtgt






241 445










extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling



























extenduse case

main use case

Invalid semester



241 445






nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling























nctionality


might be inserted













































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling



























































































447


















2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling






























2 Documentation










system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling





















system









or output

7 Quality Issues

















10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling




























10 Security Issues















requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling
























requirements model



different ways


434




















Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling





































Architect

SystemAnalyst

Use-CaseSpecifier


PrioritizeUse Cases


DetailUse Cases




DomainAnalyst










improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling


























improve the UI
















So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling































So whatSo what









containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling
























containthis

information











limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling























limitations


















Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling


































Can use














































shortcuts can help






user requirements





consuming









Use-case Modeling

























































shortcuts can help






user requirements





consuming









Use-case Modeling





















user requirements





consuming









Use-case Modeling






















Use-case Modeling


















310313 requirements capture 1 system requirements capture 310313 software engineering 310313...

Documents