Slide 10C.52
Object-Oriented and
Classical Software
Engineering
Sixth Edition, WCB/McGraw-Hill, 2005
Stephen R. Schach
srs@vuse.vanderbilt.edu
© The McGraw-Hill Companies, 2005
CHAPTER 10 — Unit C
REQUIREMENTS
© The McGraw-Hill Companies, 2005
Slide 10C.53
Slide 10C.54
Continued from Unit 10B
© The McGraw-Hill Companies, 2005
10.9 Continuing the Requirements Workflow: The Osbert Oglesby Case
Study
Slide 10C.55

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
© The McGraw-Hill Companies, 2005
Attributes: The Osbert Oglesby Case Study
Slide 10C.56

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 10.14 — see over)

Attributes when selling a painting are:
Date of sale, name of buyer, address of buyer, actual
selling price
© The McGraw-Hill Companies, 2005
Attributes: The Osbert Oglesby Case Study (contd)
Slide 10C.57
Figure 10.14
© The McGraw-Hill Companies, 2005
Continuing the Requirements Workflow: The Osbert Oglesby Case Study
Slide 10C.58

Now the algorithm for computing the maximum
purchase price is considered

Classify the painting as a
Masterpiece
Masterwork, or
Other painting
© The McGraw-Hill Companies, 2005
Maximum Price for a Masterpiece: The Osbert Oglesby Case Study
Slide 10C.59

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
8.5 percent to the base price, compounded
annually, for each year since that auction
© The McGraw-Hill Companies, 2005
Maximum Price for a Masterwork: The Osbert Oglesby Case Study
Slide 10C.60

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)
© The McGraw-Hill Companies, 2005
Maximum Price for an Other Painting: The Osbert Oglesby Case Study
Slide 10C.61

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
© The McGraw-Hill Companies, 2005
Coefficient of Similarity: The Osbert Oglesby Case Study
Slide 10C.62

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
© The McGraw-Hill Companies, 2005
Coefficient of Similarity: The Osbert Oglesby Case Study (contd)
Slide 10C.63

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
© The McGraw-Hill Companies, 2005
Fashionability Coefficients: The Osbert Oglesby Case Study
Slide 10C.64

The software product 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
© The McGraw-Hill Companies, 2005
Auction Data: The Osbert Oglesby Case Study
Slide 10C.65

The software product must utilize information on
worldwide auction sales of masterpieces over the
past 25 years

Each month Osbert receives a CD with updated
worldwide auction prices; these prices are never
modified by Osbert
© The McGraw-Hill Companies, 2005
Updated Use Cases: The Osbert Oglesby Case Study
Slide 10C.66

The use-case descriptions must reflect this
information

The resulting description of the Buy a Painting
use case is shown in Figure 10.14 (see 9 slides
back)
© The McGraw-Hill Companies, 2005
Updated Use Cases: The Osbert Oglesby Case Study
Slide 10C.67

The description of the Sell a Painting use case:
Figure 10.15
© The McGraw-Hill Companies, 2005
Reports: The Osbert Oglesby Case Study
Slide 10C.68

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):
© The McGraw-Hill Companies, 2005
Report of Purchases during the Past Year: The Osbert Oglesby CaseSlide
Study
10C.69

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
© The McGraw-Hill Companies, 2005
Figure 10.16
Report of Sales during the Past Year: The Osbert Oglesby Case Study
Slide 10C.70

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
© The McGraw-Hill Companies, 2005
Figure 10.17
Report of Trends during the Past Year: The Osbert Oglesby Case Study
Slide 10C.71

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
Figure 10.18
© The McGraw-Hill Companies, 2005
Updated Use Cases: The Osbert Oglesby Case Study
Slide 10C.72

The updated description of the Produce a Report
use case, incorporating the details listed earlier,
appears in Figure 10.19 (see over)
© The McGraw-Hill Companies, 2005
Updated Use Cases: The Osbert Oglesby Case Study (contd)
Slide 10C.73
Figure 10.19
© The McGraw-Hill Companies, 2005
10.10 The Test Workflow: The Osbert Oglesby Case Study
Slide 10C.74

There is a serious omission
The use case for updating a fashionability coefficient
has been overlooked

Missing use case Update a Fashionability
Coefficient
Figure 10.20
© The McGraw-Hill Companies, 2005
The Test Workflow: The Osbert Oglesby Case Study (contd)
Slide 10C.75

The description of the use case Update a
Fashionability Coefficient
Figure 10.21
© The McGraw-Hill Companies, 2005
Second Iteration of the Use-Case Diagram: The Osbert Oglesby CaseSlide
Study
10C.76

Incorporate all four use cases
© The McGraw-Hill Companies, 2005
Figure 10.22
The Test Workflow: The Osbert Oglesby Case Study (contd)
Slide 10C.77

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 McGraw-Hill Companies, 2005
The Test Workflow: The Osbert Oglesby Case Study (contd)
Slide 10C.78

The Unified Process is iterative and incremental
Members of the development team must always be
aware that changes and extensions to the current
version of the software product may have to made at
any time
© The McGraw-Hill Companies, 2005
10.11 The Classical Requirements Phase
Slide 10C.79

There is no such thing as “object-oriented
requirements”
The requirements workflow has nothing to do with how
the product is to be built

However, the approach presented in this chapter
is
Model oriented, and therefore
Object oriented
© The McGraw-Hill Companies, 2005
The Classical Requirements Phase (contd)
Slide 10C.80

The classical approach to requirements
Requirements elicitation
Requirements analysis
Construction of a rapid prototype
Client and future users experiment with the rapid
prototype
© The McGraw-Hill Companies, 2005
10.12 Rapid Prototyping

Slide 10C.81
Hastily built (“rapid”)
Imperfections can be ignored

Exhibits only key functionality

Emphasis on only what the client sees
Error checking, file updating can be ignored

Aim:
To provide the client with an understanding of the
product
© The McGraw-Hill Companies, 2005
Rapid Prototyping (contd)

Slide 10C.82
A rapid prototype is built for change
Languages for rapid prototyping include 4GLs and
interpreted languages
© The McGraw-Hill Companies, 2005
10.13 Human Factors
Slide 10C.83

The client and intended users must interact with
the user interface

Human-computer interface (HCI)
Menu, not command line
“Point and click”
Windows, icons, pull-down menus
© The McGraw-Hill Companies, 2005
Human Factors (contd)

Slide 10C.84
Human factors must be taken into account
Avoid a lengthy sequence of menus
Allow the expertise level of an interface to be modified
Uniformity of appearance is important
Advanced psychology vs. common sense?

Rapid prototype of the HCI of every product is
obligatory
© The McGraw-Hill Companies, 2005
10.14 Reusing the Rapid Prototype
Slide 10C.85

Reusing a rapid prototype is essentially code-andfix

Changes are made to a working product
Expensive

Maintenance is hard without specification and
design documents

Real-time constraints are hard to meet
© The McGraw-Hill Companies, 2005
Reusing the Rapid Prototype (contd)

Slide 10C.86
One way to ensure that the rapid prototype is
discarded
Implement it in a different language from that of the
target product

Generated code can be reused

We can safely retain (parts of) a rapid prototype if
This is prearranged
Those parts pass SQA inspections
However, this is not “classical” rapid prototyping
© The McGraw-Hill Companies, 2005
10.15 CASE Tools for the Requirements Workflow
Slide 10C.87

We need graphical tools for UML diagrams
To make it easy to change UML diagrams
The documentation is stored in the tool and therefore is
always available

Such tools are sometimes hard to use

The diagrams may need considerable “tweaking”

Overall, the strengths outweigh the weaknesses
© The McGraw-Hill Companies, 2005
CASE Tools for the Requirements Workflow (contd)
Slide 10C.88

Graphical CASE environments extended to
support UML include
System Architect
Software through Pictures

Object-oriented CASE environments include
Rose
Together
ArgoUML (open source)
© The McGraw-Hill Companies, 2005
10.16 Metrics for the Requirements Workflow
Slide 10C.89

Volatility and speed of convergence are measures
of how rapidly the client’s needs are determined
© The McGraw-Hill Companies, 2005
Metrics for the Requirements Workflow (contd)
Slide 10C.90

The number of changes made during subsequent
phases

Changes initiated by the developers
Too many changes can mean the process is flawed

Changes initiated by the client
Moving target problem
© The McGraw-Hill Companies, 2005
10.17 Challenges of the Requirements Phase
Slide 10C.91

Employees of the client organization often feel
threatened by computerization

The requirements team members must be able to
negotiate
The client’s needs may have to be scaled down

Key employees of the client organization may not
have the time for essential in-depth discussions

Flexibility and objectivity are essential
© The McGraw-Hill Companies, 2005