310414 requirements capture 1/67 system requirements capture 310414 software engineering 310414...

310414310414 REQUIREMENTS CAPTUREREQUIREMENTS CAPTURE1/67

SYSTEM REQUIREMENTS CAPTURESYSTEM REQUIREMENTS CAPTURESYSTEM REQUIREMENTS CAPTURESYSTEM REQUIREMENTS CAPTURE

310414310414SOFTWARE ENGINEERINGSOFTWARE ENGINEERING

310414310414SOFTWARE ENGINEERINGSOFTWARE ENGINEERING


SYSTEM REQUIREMENTS CAPTURE OUTLINESYSTEM REQUIREMENTS CAPTURE OUTLINE

System Requirements Capture — Unified Process Overview– Importance & Difficulty

– Capturing & Documenting Requirements

– Life Cycle Role

System Requirements Capture — Unified Process Activities– Domain Modeling

– Use-Case Modeling

– User-interface Specification & Prototyping

– System Requirements Validation

4


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 features/constraints of the system in

a way that the customer/user understands and can approve

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

requires the collaboration ofseveral groups of participants with different backgrounds

KnowledgeKnowledgeGAPGAP

KnowledgeKnowledgeGAPGAP

4


Reasons for failure of/problems with software development:

incomplete requirements 13.1%

lack of user involvement 12.4%

lack of resources 10.6%

unrealistic expectations 9.9%

lack of executive support 9.3%

changing requirements and specifications 8.7%

lack of planning 8.1%

system no longer needed 7.5%

Reasons for failure of/problems with software development:

incomplete requirements 13.1%

lack of user involvement 12.4%

lack of resources 10.6%

unrealistic expectations 9.9%

lack of executive support 9.3%

changing requirements and specifications 8.7%

lack of planning 8.1%

system no longer needed 7.5%

IMPORTANCE OF REQUIREMENTS CAPTURE — 1IMPORTANCE OF REQUIREMENTS CAPTURE — 1

Requirements capture is involved in a majority of cases

> 50%

4.1


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

logscale

1

10

100

Reqmts

0.75

Design

1.00

Code

1.50

Test

3.00

Systemtest

10.00

Fielduse

60-100

BUT, requirements capture 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 users’ needs

but, users often do not know what they need!– many types of users (only know their own work and needs)

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

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

for the software engineer, requirements capture is often a“discovery and learning” 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 — OVERVIEWREQUIREMENTS CAPTURE PROCESS — OVERVIEW

Identify and understand user needs– define the goals of the system – compile list of system constraints

– compile list of candidate requirements – define development effort scope

Determine feasibility– economic feasibility – operational feasibility

– technical feasibility – organizational impact

Understand, capture and document system requirements– static (persistent data) – dynamic (processing + constraints)

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

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

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


USER NEEDS — IDENTIFICATIONUSER NEEDS — IDENTIFICATION

collect data on application domain (may include existing system)

investigation existing documentationobservation work practicesinterviews questionnaires, personalprototyping interface, functions

– challenge customer’s/user’s model of reality– elicit problems, not solutions– distinguish needs from wants; rate importance of needs

refine system goals, list of requirements, list of constraints , system scope, etc.

propose scope of project (what is included, what is excluded)

document requirements system requirements specification serves as a contract between the customer and developer!

4.5.1


FEASIBILITY DETERMINATIONFEASIBILITY DETERMINATION

Can we/should we build the system?

economic feasibility– costs (development, operation) versus benefits– tangible versus intangible

technical feasibility– availability of technology risk of new technology?– maintenance required

operational feasibility– availability of skills to operate the system– fit with current work practices (redesign work practices?)

organizational feasibility– politics; training; user acceptance; . . .

legal feasibility– 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 e.g., response time, throughput, security, etc.

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

e.g., implementation language, platform, etc.

Requirements should only statewhat is needed not how it is done


Inception Elaboration Construction Transition

REQUIREMENTS CAPTURE — LIFE CYCLE ROLEREQUIREMENTS CAPTURE — LIFE CYCLE ROLE

PhasesCore Workflows

Requirements

Analysis

Design

Implementation

Testing

iter.#1

iter.#2

— — — — —iter.#n-1

iter.#n

Increments

Iter

atio

n


ARTIFACTS & WORKERSARTIFACTS & WORKERS

Use-CaseSpecifier

Use-CaseSpecification

responsiblefor

User-InterfaceDesigner

User-interfaceSpecification &

Prototyping

responsiblefor

Architect

ArchitectureDescription

responsiblefor

DomainAnalyst

responsiblefor

DomainSpecification

SystemAnalyst

DomainModel Actors GlossaryUse-Case

Model

responsible for


UP — SYSTEM REQUIREMENTS CAPTURE PROCESSUP — SYSTEM REQUIREMENTS CAPTURE PROCESS

Architect

SystemAnalyst

Use-CaseSpecifier

Find Classesand Associations

PrioritizeUse Cases

PrototypeUser-Interface

DetailUse Cases

Structure theUse-Case Model

User-InterfaceDesigner

Find Actors andUse Cases

DomainAnalyst

Detail Classesand Associations


DOMAIN MODELINGDOMAIN MODELING

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

things that exist or events that occur in the system’s environment

found from– high-level problem statement– lower-level requirements– domain experts (users)

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

classes can be:– business objects (e.g., orders, accounts, etc.)– real-world objects and concepts (e.g., suppliers, customers, etc.)– events (e.g., aircraft arrival/departure, sales, reservations, etc.)

described in a class diagram static system structure


IDENTIFYING CLASSES & ASSOCIATIONSIDENTIFYING CLASSES & ASSOCIATIONS

naturally occurring things or concepts in the application domain– classes often appear as nouns/noun phrases in application

domain terminology

– associations often appear as verbs/verb phrases in application domain terminology

circle or highlight in problem description

put all terms into singular form/active 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

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 system’s life cycle

leads to a stable system


DOMAIN MODEL — KEEPING THE RIGHT DOMAIN MODEL — KEEPING THE RIGHT CLASSESCLASSES

Are any classes redundant?

Are any classes irrelevant to the application domain?

Are any classes vague (ill-defined)?

Should any classes really be attributes?

Do any classes describe an operation?

Do any class names describe a role?

Do any classes describe implementation constructs?


DOMAIN MODEL— KEEPING THE RIGHT DOMAIN MODEL— KEEPING THE RIGHT ASSOCIATIONSASSOCIATIONS

Are there any associations between eliminated classes?

Are any associations irrelevant to the application domain?

Do any associations describe an operation?

Can ternary associations be decomposed into binary associations?

Are any associations derived associations?

Are any associations named with “how” or “why” names?

Are role names required for any associations?

Should any associations be qualified?

Are multiplicity, ordering specifications missing?

Do any associations describe implementation constructs?


DOMAIN MODEL — KEEPING THE RIGHT DOMAIN MODEL — KEEPING THE RIGHT ATTRIBUTESATTRIBUTES Are attributes closely related to the class they are in?

Should any attributes really be classes?

Should any attributes be qualifiers?

Have object identifiers been included as attributes?

Should any attributes be in an association class?


DOMAIN MODEL DETAIL— ATTRIBUTESDOMAIN MODEL DETAIL— ATTRIBUTES

meaningful name

itemPrice not itpr

allowable values continuous - a range of values

price: $0 to $10,000need 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 – as found in the real world number 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— CLASSES & DOMAIN MODEL DETAIL— CLASSES & ASSOCIATIONSASSOCIATIONS for each class we can add any operations that we are aware of

at this stage

most operations will be added during analysis & design

for each association we need to specify (if known):– a name (optional)

– role names (as necessary)

– multiplicity

– association class (if necessary)

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


DOMAIN MODEL DETAIL — GENERALIZATIONDOMAIN MODEL DETAIL — GENERALIZATION

classify classes according to similarity of attributes and operations

look for “kind-of” statements that are true in the real world

do not nest too deeply– 2-3 levels OK

– 4-6 levels maybe

– 10 levels too deep!

Goal:Goal: simplicity of representation and modeling clarity

Need to decide how to handle associationsin which subclasses participate


District

*

11

*

LivesInLivesIn

DOMAIN MODEL DETAIL — GENERALIZATION DOMAIN MODEL DETAIL — GENERALIZATION (cont’d)(cont’d)

Person

StudentProfessor

District* 1LivesIn


*

1

LivesIn

DOMAIN MODEL DETAIL — GENERALIZATION DOMAIN MODEL DETAIL — GENERALIZATION (cont’d)(cont’d)

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 shop:– The system must be able to keep track of which movie videos have been

bought/rented 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.

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

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

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

– A member 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.

– 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 (cont’d)USE-CASE MODELING EXAMPLE (cont’d)

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

– 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 shop's web site, including accessing and changing their personal information.

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

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

videos to the store's inventory.– When selling or renting videos, staff must be able to look up customer information

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

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


DOMAIN MODELING EXAMPLE — ANALYSISDOMAIN MODELING EXAMPLE — ANALYSIS

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

– The system must be able to keep track of which movie videos have been bought/rented 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.







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



– 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 member's only area of the video shop's web site, including accessing and changing their personal information.


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

– Staff must be able to sell/rent videos from the store’s inventory and return rented videos to the store's inventory.



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

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


USE-CASE MODELINGUSE-CASE MODELING

captures the system behavior from the users’ point of view

developed in cooperation with the domain model

helps in:– capturing data and functional requirements

– planning iterations of development

– validating the system

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

all required functionality is described in the use cases

use-case model is developed incrementally

2.2.1; 2.4.1


Something Something outsideoutside the system the system that that interacts directlyinteracts directly with it with it

USE CASE MODEL — ACTORSUSE CASE MODEL — ACTORS

actor name

actors are the source for discovering use cases

4.4.1

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 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 — USE CASEUSE CASE MODEL — USE CASE

A specific way of using the system by 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 events/actions

ignore exceptions, alternate ways of doing things

2.4.1; 4.4.3

specifies the interaction that takes place between an actor and the system considered from the user’s viewpoint

constitutes a complete sequence of events/actions initiated by an actor

A use case is a stereotype of class

use case is a classifier; scenario is an instance


IDENTIFYING USE CASESIDENTIFYING USE CASES

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?

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 — USE CASESASU — USE CASES

At the beginning of each semester, students may request a course catalog containing a list of course offerings needed for the semester. Information about 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 ten students or fewer than three 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.


ASU — USE CASESASU — USE CASES

Professors must be able to access the online system to indicate which courses they will be teaching, and to see which students signed up for their course offerings.

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


USE-CASE MODEL — SCENARIOUSE-CASE MODEL — SCENARIO

A A concreteconcrete, , focusedfocused, , informal descriptioninformal description of a of a single single use of the systemuse of the system from the from the viewpoint of a single actorviewpoint of a single actor

A A concreteconcrete, , focusedfocused, , informal descriptioninformal description of a of a single single use of the systemuse of the system from the from the viewpoint of a single actorviewpoint of a single actor

an attempt to carry out a use case

types of scenarios used in software development

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

visionary - describes a future system

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

training - used for introducing new users to the system

2.4.1; 4.4.2

used to gain a shared understanding betweendevelopers and users of what the system should do


IDENTIFYING SCENARIOSIDENTIFYING SCENARIOS

Since scenarios are instances of use cases, the same questions can be asked as for identifying uses cases.

Note: two viewpoints of use-case modeling

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

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

In reality, the use case specifier uses both viewpoints

BUT scenarios mostly used to describeerrors and alternate flows


WHAT IS A GOOD USE CASE?WHAT 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 System:– select courses– be added to course offerings– be billed

deals with one completesequence of events/actions

Consider Registrar in ASU Course Registration System:– add courses– delete courses– 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

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


USE-CASE DETAIL — FLOW OF EVENTSUSE-CASE DETAIL — 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 scenario/use caseaccomplish a scenario/use case

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 scenario/use caseaccomplish a scenario/use 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 — no errors, no exceptions (always required).

Alternate paths: show exceptional conditions or errors.

start with basic path, then add alternate paths as needed

Goal:Goal: specify everything the user might do


USE CASE DETAIL — USE CASE SPECIFICATIONUSE CASE DETAIL — USE CASE SPECIFICATION

use case name

participating actors

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

flow of events– required order of actions the normal sequence of events– what interaction the use case has with the actors– what data is needed by the use case

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

special requirements (if any)

alternate or exceptional flows (if any)

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


USE CASE DETAIL — FLOW OF EVENTS USE CASE DETAIL — FLOW OF EVENTS SPECIFICATIONSPECIFICATION

branchingn. If boolean-expression

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

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. (e.g., 3. The user enters a login id.)

√ repetition should be used sparingly!

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


USE-CASE MODEL DETAIL — GENERALIZATIONUSE-CASE MODEL DETAIL — GENERALIZATION

Since actors and use cases are Since actors and use cases are classifiers, they can be generalized.classifiers, they can be generalized.

Since actors and use cases are Since actors and use cases are classifiers, they can be generalized.classifiers, they can be generalized.

ManagerSales clerk

represents a design decision!

EmployeeValidate user

Check password Retinal scan

2.4.1


USE-CASE DETAIL — INCLUDEUSE-CASE DETAIL — 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 <<include>> relationship

Validate user

<<include>>

Register for courses Select courses to teach Request enrollment list

<<include>><<include>>


include use case(usually not invokeddirectly by user)

main use cases(invoked directlyby user)

2.4.1; 4.4.5


models conditional additionsto a use case’s sequence of actions

used to show:– optional behavior

– behavior that is executed only under certain conditions

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

USE-CASE DETAIL — EXTENDUSE-CASE DETAIL — EXTEND

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

<<extend>>(semester invalid)

Select courses to teach

extenduse case

main use case

Invalid semester


extensionpoint label

2.4.1; 4.4.5


IDENTIFYING NONFUNCTIONAL REQUIREMENTSIDENTIFYING NONFUNCTIONAL REQUIREMENTS

user-visible system properties that cannot be expressed as use cases, but often place constraints on the use cases

– performance (time and throughput) requirements

– reliability requirements

– the environment in which the software is to operate

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

– constraints on implementation —hardware, quality, etc.

– life-cycle considerations — schedule, budget, etc.

4.4.7

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


USE CASES THROUGH THE DEVELOPMENTUSE CASES THROUGH THE DEVELOPMENT

Planning– Basis for negotiation with customer

determine which use cases to provide in the first release

Political aspects– Demonstrate the system doing something valuable to the most

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

Technical aspects– Deliver the highest risk use cases first

use knowledge from risk analysis

System validation– “walk the use case” to see if it can provide the required functionality


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 shop:– The system must be able to keep track of which movie videos have been

bought/rented 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.





– 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 (cont’d)USE-CASE MODELING EXAMPLE (cont’d)

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



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

videos to the store's inventory.– When selling or renting videos, staff must be able to look up customer information

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

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


USE-CASE MODELING EXAMPLE — ANALYSISUSE-CASE MODELING EXAMPLE — ANALYSIS

We first analyze the functional requirements of the system and then present the use-case model. Note that for the purposes of producing the use-case model, we are only really interested in those functional requirements that provide something of value for some actor.

– The system must be able to keep track of which movie videos have been bought/rented 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.




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





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

– Staff must be able to sell/rent videos from the store’s inventory and return rented videos to the store's inventory.

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



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


VALIDATE SYSTEM REQUIREMENTSVALIDATE SYSTEM REQUIREMENTS

requirements should be continuously validated with the customer and the user and they should be:

correct - represent the customer’s 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

correctness and completeness often difficult to show

4.3.4


VALIDATE REQUIREMENTS — ACCEPTANCE TESTSVALIDATE REQUIREMENTS — ACCEPTANCE TESTS

Functional validity – does the system provide the required functionality and obey the required constraints? Show that a professor can select a course offering to teach. Show that a student cannot register for more than four courses.

Interface validity – do interfaces perform desired functions (accept desired input/provide desired output) and follow consistent design standards? Show that all required data for course registration can be input.

Information content – are the data structures/data bases correct (store the right data in the required format)? Show that all required information of a student’s course schedule is shown.

Performance – does the system meet specified performance criteria? Show the response time to register for a course is less than 1 second.

Tests must be specified that 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

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 way– group related requirements

– remove any requirements that cannot be tested

add any additional requirements gathered from users– look at use cases for functional and interface requirements

– look at domain model for information content requirements

– 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 interface,they can not be completed until the user interface is designed)


SUMMARY — SYSTEM REQUIREMENTS CAPTURESUMMARY — SYSTEM REQUIREMENTS CAPTURE

requirements are captured over several iterations by specifying:– a domain model– a use-case model– initial user interfaces (and building some user interface prototypes)– an acceptance test plan

These are all documented in theSystem Requirements Specification (SRS)

Use cases drive the subsequent iterations/phases

in subsequent iterations/phases we refine and/or transform the requirements by specifying:– more detail for each of the above artifacts– matching use-case realizations in analysis model– matching use-case realizations in design model– a set of test cases in the test model

310414 requirements capture 1/67 system requirements capture 310414 software engineering 310414...

Documents