Slide 10C.1

© The McGraw-Hill Companies, 2005

Object-Oriented and Classical Software

Engineering

Sixth Edition, WCB/McGraw-Hill, 2005

Stephen R. Schachsrs@vuse.vanderbilt.edu

Slide 10C.2

© The McGraw-Hill Companies, 2005

CHAPTER 10 — Unit C

REQUIREMENTS

Slide 10C.3

© The McGraw-Hill Companies, 2005

Continued from Unit 10B

Slide 10C.4

© The McGraw-Hill Companies, 2005

10.9 Continuing the Requirements Workflow: The Osbert Oglesby Case Study

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

Slide 10C.5

© The McGraw-Hill Companies, 2005

Attributes: The Osbert Oglesby Case Study

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

Slide 10C.6

© The McGraw-Hill Companies, 2005

Attributes: The Osbert Oglesby Case Study (contd)

Figure 10.14

Slide 10C.7

© The McGraw-Hill Companies, 2005

Continuing the Requirements Workflow: The Osbert Oglesby Case Study

Now the algorithm for computing the maximum purchase price is considered

Classify the painting as a MasterpieceMasterwork, orOther painting 

Slide 10C.8

© The McGraw-Hill Companies, 2005

Maximum Price for a Masterpiece: The Osbert Oglesby Case Study

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

Slide 10C.9

© The McGraw-Hill Companies, 2005

Maximum Price for a Masterwork: The Osbert Oglesby Case Study

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)

Slide 10C.10

© The McGraw-Hill Companies, 2005

Maximum Price for an Other Painting: The Osbert Oglesby Case Study

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

Slide 10C.11

© The McGraw-Hill Companies, 2005

Coefficient of Similarity: The Osbert Oglesby Case Study

For a masterpiece or masterwork, the coefficient of similarity between two paintings is computed as follows:Score 1 for a match on medium, otherwise 0Score 1 for a match on subject, otherwise 0Add these two numbers, multiply by the area of the

smaller painting, and divide by the area of the largerThe resulting number is the coefficient of similarity

Slide 10C.12

© The McGraw-Hill Companies, 2005

Coefficient of Similarity: The Osbert Oglesby Case Study (contd)

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

Slide 10C.13

© The McGraw-Hill Companies, 2005

Fashionability Coefficients: The Osbert Oglesby Case Study

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 experienceHe changes the value if prices for work by an artist

increase or decrease

Slide 10C.14

© The McGraw-Hill Companies, 2005

Auction Data: The Osbert Oglesby Case Study

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

Slide 10C.15

© The McGraw-Hill Companies, 2005

Updated Use Cases: The Osbert Oglesby Case Study

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)

Slide 10C.16

© The McGraw-Hill Companies, 2005

Updated Use Cases: The Osbert Oglesby Case Study

The description of the Sell a Painting use case:

Figure 10.15

Slide 10C.17

© The McGraw-Hill Companies, 2005

Reports: The Osbert Oglesby Case Study

There are three reports: Purchases during the past yearSales during the past yearDetection 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):

Slide 10C.18

© The McGraw-Hill Companies, 2005

Report of Purchases during the Past Year: The Osbert Oglesby Case Study

A report is needed to display all the paintings purchased during the past yearThe average ratio of the purchase price to the suggested

maximum price is required at the end of the report

Figure 10.16

Slide 10C.19

© The McGraw-Hill Companies, 2005

Report of Sales during the Past Year: The Osbert Oglesby Case Study

A report is needed to display all the paintings sold during the past yearThe average ratio of the actual selling price to the target

selling price is required at the end of the report

Figure 10.17

Slide 10C.20

© The McGraw-Hill Companies, 2005

Report of Trends during the Past Year: The Osbert Oglesby Case Study

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 yearTo appear in this report, at least two of the artist’s works

must have been sold by Osbert during that period

Figure 10.18

Slide 10C.21

© The McGraw-Hill Companies, 2005

Updated Use Cases: The Osbert Oglesby Case Study

The updated description of the Produce a Report use case, incorporating the details listed earlier, appears in Figure 10.19 (see over)

Slide 10C.22

© The McGraw-Hill Companies, 2005

Updated Use Cases: The Osbert Oglesby Case Study (contd)

Figure 10.19

Slide 10C.23

© The McGraw-Hill Companies, 2005

10.10 The Test Workflow: The Osbert Oglesby Case Study

There is a serious omissionThe use case for updating a fashionability coefficient

has been overlooked

Missing use case Update a Fashionability Coefficient

Figure 10.20

Slide 10C.24

© The McGraw-Hill Companies, 2005

The Test Workflow: The Osbert Oglesby Case Study (contd)

The description of the use case Update a Fashionability Coefficient

Figure 10.21

Slide 10C.25

© The McGraw-Hill Companies, 2005

Second Iteration of the Use-Case Diagram: The Osbert Oglesby Case Study

Incorporate all four use cases

Figure 10.22

Slide 10C.26

© The McGraw-Hill Companies, 2005

The Test Workflow: The Osbert Oglesby Case Study (contd)

A fault was detected There was a missing use caseThe existing artifacts did not need to be changed

Two additional artifacts had to be addedA use case, and Its description

Slide 10C.27

© The McGraw-Hill Companies, 2005

The Test Workflow: The Osbert Oglesby Case Study (contd)

The Unified Process is iterative and incrementalMembers 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

Slide 10C.28

© The McGraw-Hill Companies, 2005

10.11 The Classical Requirements Phase

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

Slide 10C.29

© The McGraw-Hill Companies, 2005

The Classical Requirements Phase (contd)

The classical approach to requirements

Requirements elicitation

Requirements analysis

Construction of a rapid prototype

Client and future users experiment with the rapid prototype

Slide 10C.30

© The McGraw-Hill Companies, 2005

10.12 Rapid Prototyping

Hastily built (“rapid”) Imperfections can be ignored

Exhibits only key functionality

Emphasis on only what the client seesError checking, file updating can be ignored

Aim: To provide the client with an understanding of the

product

Slide 10C.31

© The McGraw-Hill Companies, 2005

Rapid Prototyping (contd)

A rapid prototype is built for changeLanguages for rapid prototyping include 4GLs and

interpreted languages

Slide 10C.32

© The McGraw-Hill Companies, 2005

10.13 Human Factors

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

Slide 10C.33

© The McGraw-Hill Companies, 2005

Human Factors (contd)

Human factors must be taken into accountAvoid a lengthy sequence of menusAllow the expertise level of an interface to be modifiedUniformity of appearance is importantAdvanced psychology vs. common sense?

Rapid prototype of the HCI of every product is obligatory

Slide 10C.34

© The McGraw-Hill Companies, 2005

10.14 Reusing the Rapid Prototype

Reusing a rapid prototype is essentially code-and-fix

Changes are made to a working productExpensive

Maintenance is hard without specification and design documents

Real-time constraints are hard to meet

Slide 10C.35

© The McGraw-Hill Companies, 2005

Reusing the Rapid Prototype (contd)

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 prearrangedThose parts pass SQA inspectionsHowever, this is not “classical” rapid prototyping

Slide 10C.36

© The McGraw-Hill Companies, 2005

10.15 CASE Tools for the Requirements Workflow

We need graphical tools for UML diagramsTo make it easy to change UML diagramsThe 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

Slide 10C.37

© The McGraw-Hill Companies, 2005

CASE Tools for the Requirements Workflow (contd)

Graphical CASE environments extended to support UML includeSystem ArchitectSoftware through Pictures

Object-oriented CASE environments includeRoseTogetherArgoUML (open source)

Slide 10C.38

© The McGraw-Hill Companies, 2005

10.16 Metrics for the Requirements Workflow

Volatility and speed of convergence are measures of how rapidly the client’s needs are determined

Slide 10C.39

© The McGraw-Hill Companies, 2005

Metrics for the Requirements Workflow (contd)

The number of changes made during subsequent phases

Changes initiated by the developersToo many changes can mean the process is flawed

Changes initiated by the clientMoving target problem

Slide 10C.40

© The McGraw-Hill Companies, 2005

10.17 Challenges of the Requirements Phase

Employees of the client organization often feel threatened by computerization

The requirements team members must be able to negotiateThe 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