Chap 004

Slide 4.
An Introduction to
Object-Oriented
Systems Analysis and Design
with UML and
the Unified Process
McGraw-Hill, 2004
Stephen R. Schach
srs@vuse.vanderbilt.edu
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
CHAPTER 4 Slide 4.2
THE REQUIREMENTS
WORKFLOW I

Chapter Overview Slide 4.3
● Determining What the Client Needs

● Overview of the Requirements Workflow
● Understanding the Domain
● Initial Understanding of the Domain: Osbert Oglesby
Case Study
● Business Model
● Interviewing
● Other techniques

Chapter Overview (contd) Slide 4.4
● Use Cases
● Initial Business Model: Osbert Oglesby Case Study
● Initial Requirements
● Initial Requirements: Osbert Oglesby Case Study
● Continuing the Requirements Workflow: Osbert
Oglesby Case Study
● It Ain’t Over Till it’s Over

Determining the Client’s Needs Slide 4.5
● Consider the requirements workflow
● The primary task of the systems analyst is to

determine what the client needs
– This may not be what the client says that he or she wants
● Information systems are complex

– Clients therefore often ask for the wrong information
system

Determining the Client’s Needs (contd) Slide 4.6
● It is hard for a systems analyst to visualize an

information system and its functionality
– The problem is far worse for the client
● A skilled systems analyst is needed to elicit the

appropriate information from the client
● The client is the only source of this information

Determining the Client’s Needs (contd) Slide 4.7
● The solution:
– Obtain initial information from the client
– Use this initial information as input to the Unified Process
– Follow the steps of the Unified Process to determine the
client’s real needs

Overview of the Requirements Workflow Slide 4.8
● First, gain an understanding of the application

domain (domain, for short)
– (The specific business environment in which the information
system is to operate)
● Second, build a business model

– Use UML to describe the client’s business processes
● Third, use the business model to determine the

client’s requirements
● Then iterate (“repeat”) the above steps

Flowchart of the Requirements Workflow Slide 4.9

Definitions Slide 4.10
● Discovering the client’s requirements

– Requirements elicitation (or requirements capture)
– Methods include interviews and surveys
● Refining and extending the initial requirements

– Requirements analysis

Understanding the Domain Slide 4.11
● Every member of the development team must

become fully familiar application domain
– Correct terminology is essential
● We must build a glossary

– That is, a list of technical words used in the domain, and
their meaning

Initial Understanding: Osbert Oglesby Case Study Slide 4.12
● Osbert Oglesby, Art Dealer, needs an information

system to assist him in buying and selling paintings
● Obtaining domain knowledge is the first step
● Osbert is interviewed to obtain the relevant

information
● This information is put into a glossary (see next

slide)

Glossary: Osbert Oglesby Case Study Slide 4.13

Business Model Slide 4.14
● A business model is a description of the business

processes of an organization
● The business model gives an understanding of the

client’s business as a whole
– This knowledge is essential for advising the client
regarding computerization
● The systems analyst needs to obtain a detailed

understanding of the various business processes
– Different techniques are used, primarily interviewing

Interviewing Slide 4.15
● The requirements team meet with the client and

users to extract all relevant information

Interviewing (contd) Slide 4.16
● There are two types of questions

– Close-ended questions requires a specific answer
– Open-ended questions are asked to encourage the person
being interviewed to speak out
● There are two types of interviews

– In a structured interview, specific preplanned questions
are asked, frequently close-ended
– In an unstructured interview, questions are posed in
response to the answers received, frequently open-ended

Interviewing (contd) Slide 4.17
● Interviewing is not easy

– An interview that is too unstructured will not yield much
relevant information
– The interviewer must be fully familiar with the application
domain
– The interviewer must remain open-minded at all times
● After the interview, the interviewer must prepare a

written report
– It is strongly advisable to give a copy of the report to the
person who was interviewed

Other Information Gathering Techniques Slide 4.18
● Interviewing is the primary technique
● A questionnaire is useful when the opinions of

hundreds of individuals need to be determined
● Examination of business forms shows how the client

currently does business

Other Information Gathering Techniques (contd) Slide 4.19
● Direct observation of the employees while they

perform their duties can be useful
– Videotape cameras are modern version of this technique
– But, it can take a long time to analyze the tapes
– Employees may view the cameras as an unwarranted
invasion of privacy

Use Cases Slide 4.20
● A use case models an interaction between the

information system itself and the users of that
information system (actors)
● Example:

Use Cases (contd) Slide 4.21
● A use case shows the interaction between

– The information system and
– The environment in which the information system operates
● Each use case models one type of interaction

– There can be just a few use cases for an information
system, or there can be hundreds
● The rectangle in the use case represents the

information system itself

● An actor is a member of the world outside the

information system
● It is usually easy to identify an actor

– An actor is frequently a user of the information system
● In general, an actor plays a role with regard to the

information system. This role is
– As a user; or
– As an initiator; or
– As someone who plays a critical part in the use case

● A user of the system can play more than one role
● Example: A customer of the bank can be

– A Borrower or
– A Lender

● Conversely, one actor can be a participant in

multiple use cases
● Example: A Borrower may be an actor in

– The Borrow Money use case;
– The Pay Interest on Loan use case; and
– The Repay Loan Principal use case
● Also, the actor Borrower may stand for many

thousands of bank customers

● An actor need not be a human being
● Example: The Cardholder Clothing Company

information system has to interact with the credit
card company information system
– The credit card company information system is an actor
from the viewpoint of the Cardholder Clothing Company
information system
– The Cardholder Clothing Company information system is
an actor from the viewpoint of the credit card company
information system

● A potential problem when identifying actors

– Overlapping actors
● Example: Hospital Information System

– One use case has actor Nurse
– A different use case has actor Medical Staff
– Better:
» Actors: Physician and Nurse

● Alternatively:
– Actor Medical Staff with two specializations: Physician and
Nurse

Init. Business Model: Osbert Oglesby Case Study Slide 4.28
● Osbert wants an information system, running on his

laptop computer, that will
– Determine the maximum price he should pay for a painting
– Detect new trends in the art market as soon as possible
● To do this, the information system needs to keep a

record of all purchases and all sales
● Currently, Osbert produces reports of annual sales

and purchases by hand
– At only a small additional cost, the information system can
also print these two reports on demand
● Osbert wants an information system that can

– Compute the highest price he should pay for a painting;
and
– Detect new art trends
● Osbert needs an information system that can also

– Provide reports on purchases and sales
● It is vital to determine the client’s needs up front,

and not after the information system has been
delivered
● Osbert has three business activities:

– He buys paintings
– He sells paintings
– He produces reports

● Buy a Painting use case

● Sell a Painting use case

● Produce a Report use case

● For conciseness, all three use cases are combined

into a use-case diagram

● The only person who uses the current (manual)

information system is Osbert
– Osbert is therefore an actor in all three use cases
● The customer may initiate the Buy a Painting or the

Sell a Painting use case
● The customer plays a critical part in both use cases

by providing data entered into the information
system by Osbert
– The customer is therefore an actor in both these use
cases
● Next, the use cases have to be annotated
● Here are the initial use-case descriptions




Initial Requirements Slide 4.40
● The initial requirements are based on the initial

business model
● Then they are refined
● The requirements are dynamic—there are frequent

changes
– Maintain a list of likely requirements, together with use
cases of requirements approved by the client

Initial Requirements (contd) Slide 4.41
● There are two categories of requirements
● A functional requirement specifies an action that the

information system must be able to perform
– Often expressed in terms of inputs and outputs
● A nonfunctional requirement specifies properties of

the information system itself, such as
– Platform constraints
– Response times
– Reliability

Initial Requirements (contd) Slide 4.42
● Functional requirements are handled as part of the

requirements and analysis workflows
● Some nonfunctional requirements have to wait until

the design workflow
– The detailed information for some nonfunctional
requirements is not available until the requirements and
analysis workflows have been completed

Initial Requirements: Osbert Oglesby Case Study Slide 4.43
● The initial business model (the three use cases)

shows how Osbert currently does business
● Decide which of these use cases are also

requirements of the information system to be built
– Clearly, all three are requirements
● Refine the resulting initial requirements

– The descriptions of the use cases have to be refined

Initial Requirements: Osbert Oglesby Slide 4.44

Initial Requirements: Osbert Oglesby (contd) Slide 4.45


● All three descriptions are still vague

– A consequence of the iterative nature of the Unified
Process
– For example, the algorithm details are irrelevant at this
time
● Basic principle: Defer all details to as late as

possible
– This will simplify the inevitable changes of the next
iteration

Requirements Workflow: Osbert Oglesby Slide 4.48
● More details of each use case are needed now
● First consider use cases

– Buy a Painting, and
– Sell a Painting
● To refine the descriptions, determine what attributes

need to be input when a painting is bought and
when a painting is sold

Attributes: Osbert Oglesby Case Study Slide 4.49
● Attributes when buying a painting include:

– Title of work, name of artist, date of painting, classification,
medium, purchase price, name and address of seller
– (The complete list of attributes appears in the textbook in
Figure 4.15)
● Attributes when selling a painting are:

– Date of sale, name of buyer, address of buyer, actual
selling price

Requirements Workflow: Osbert Oglesby Slide 4.50
● Now the algorithm for computing the maximum

purchase price is considered
● Classify the painting as a

– Masterpiece
– Masterwork, or
– Other painting

Maximum Price for a Masterpiece Slide 4.51
● Scan worldwide auction records over the past 25

years for the most similar work by the same artist
● Use the auction purchase price of the most similar

work as the base price
● The maximum purchase price is found by adding 7.5

percent to the base price, compounded annually, for
each year since that auction

Maximum Price for a Masterwork Slide 4.52
● Compute the maximum purchase price as if the

painting were a masterpiece by the same artist
● If the picture was painted in the 21st century,

multiply this figure by 0.25
● Otherwise, multiply it by (21 – c) / (22 – c), where c

is the century in which the work was painted
(12 < c < 21)

Maximum Price for an Other Painting Slide 4.53
● Measure the dimensions of the canvas
● The maximum purchase price is then given by the

formula F × A, where
– F is a constant for that artist (fashionability coefficient),
and
– A is the area of the canvas in square centimeters
● If there is no fashionability coefficient for that artist,

Osbert will not buy the painting

Coefficient of Similarity: Osbert Oglesby Slide 4.54
● For a masterpiece or masterwork, the coefficient of

similarity between two paintings is computed as
follows:
– Score 1 for a match on medium, otherwise 0
– Score 1 for a match on subject, otherwise 0
– Add these two numbers, multiply by the area of the
smaller painting, and divide by the area of the larger
– The resulting number is the coefficient of similarity

Coefficient of Similarity: Osbert Oglesby (contd) Slide 4.55
● If the coefficient of similarity between the painting

under consideration and all the paintings in the file
of auction data is zero, then Osbert will not buy that
masterwork or masterpiece

Fashionability Coefficients: Osbert Oglesby Slide 4.56
● The information system must include a list of artists

and their corresponding F values
● The value of F can vary from month to month,

depending on the current fashionability of an artist
● Osbert determines the value of F on the basis of his

knowledge and experience
– He changes the value if prices for work by an artist
increase or decrease

Auction Data: Osbert Oglesby Case Study Slide 4.57
● The information system must utilize information on

auction sales of masterpieces over the past 25
years worldwide
● Each month Osbert receives a CD with updated

worldwide auction prices; these prices are never
modified by Osbert

Updated Use Cases : Osbert Oglesby Case Study Slide 4.58
● The use-case descriptions must reflect this

information
● The resulting description of the Buy a Painting use

case is in Figure 4.15

Updated Use Cases : Osbert Oglesby Case Study Slide 4.59
● The description of the Sell a Painting use case:

Reports for the Osbert Oglesby Case Study Slide 4.60
● There are three reports:

– Purchases during the past year
– Sales during the past year
– Detection of new trends
● Sample reports show Osbert’s needs are as follows

(question marks in the first or last name of artist, or
in the title or date of the work are to be included in
all reports):

Report of Purchases during the Past Year Slide 4.61
● A report is needed to display all the paintings

purchased during the past year
– The average ratio of the purchase price to the suggested
maximum price is required at the end of the report

Report of Sales during the Past Year Slide 4.62
● A report is needed to display all the paintings sold

during the past year
– The average ratio of the actual selling price to the target
selling price is required at the end of the report

Report of Trends during the Past Year Slide 4.63
● A report showing artists whose works Osbert has

sold at a price that has exceeded the target selling
price in every instance during the past year
– To appear in this report, at least two of the artist’s works
must have been sold by Osbert during that period

Updated Use-Case Description: Produce a Report Slide 4.64
● The updated description of the Produce a Report

use case, incorporating the details listed above,
appears in Figure 4.20

It Ain’t Over Till it’s Over Slide 4.65
● There is a serious omission

– The use case for updating a fashionability coefficient has
been overlooked
● Missing use case Modify a Fashionability Coefficient

Use-Case Modify a Fashionability Coefficient Slide 4.66
● Use-case description

Second Iteration of Use-Case Diagram Slide 4.67
● Incorporate all four use cases

Analysis of Req. Workflow: Osbert Oglesby Slide 4.68
● A fault was detected

– There was a missing use case
– The existing artifacts did not need to be changed
● Two additional artifacts had to be added

– A use case, and
– Its description
● The Unified Process is iterative and incremental

– Systems analysts must always be aware that changes and
extensions to the current version of the information system
may have to made at any time

Chap 004

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Chap 004

Hochgeladen von

Copyright:

Verfügbare Formate

Slide 4.

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

● Determining What the Client Needs

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

● Consider the requirements workflow

● The primary task of the systems analyst is to

● Information systems are complex

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

● It is hard for a systems analyst to visualize an

● A skilled systems analyst is needed to elicit the

● The client is the only source of this information

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

● First, gain an understanding of the application

● Second, build a business model

● Third, use the business model to determine the

● Then iterate (“repeat”) the above steps

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

● Discovering the client’s requirements

● Refining and extending the initial requirements

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

● Every member of the development team must

● We must build a glossary

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

● Osbert Oglesby, Art Dealer, needs an information

● Obtaining domain knowledge is the first step

● Osbert is interviewed to obtain the relevant

● This information is put into a glossary (see next

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

● A business model is a description of the business

● The business model gives an understanding of the

● The systems analyst needs to obtain a detailed

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

● The requirements team meet with the client and

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

● There are two types of questions

● There are two types of interviews

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

● Interviewing is not easy

● After the interview, the interviewer must prepare a

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

● Interviewing is the primary technique

● A questionnaire is useful when the opinions of

● Examination of business forms shows how the client

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

● Direct observation of the employees while they

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

● A use case models an interaction between the

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

● A use case shows the interaction between

● Each use case models one type of interaction

● The rectangle in the use case represents the

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

● An actor is a member of the world outside the

● It is usually easy to identify an actor

● In general, an actor plays a role with regard to the

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

● A user of the system can play more than one role

● Example: A customer of the bank can be

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

● Conversely, one actor can be a participant in