Title: Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach srs@vuse.vanderbilt.edu
1Object-Oriented and Classical Software
Engineering Sixth Edition, WCB/McGraw-Hill,
2005Stephen R. Schachsrs_at_vuse.vanderbilt.edu
2CHAPTER 10 Unit C
REQUIREMENTS
3Continued from Unit 10B
410.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
5Attributes 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
6Attributes The Osbert Oglesby Case Study (contd)
Figure 10.14
7Continuing the Requirements Workflow The Osbert
Oglesby Case Study
- Now the algorithm for computing the maximum
purchase price is considered - Classify the painting as a
- Masterpiece
- Masterwork, or
- Other painting
8Maximum 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
9Maximum 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 lt c lt 21)
10Maximum 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
11Coefficient 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 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
12Coefficient 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
13Fashionability 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 experience - He changes the value if prices for work by an
artist increase or decrease
14Auction 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
15Updated 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)
16Updated Use Cases The Osbert Oglesby Case Study
- The description of the Sell a Painting use case
Figure 10.15
17Reports The Osbert Oglesby Case Study
- There are three reports
- Purchases during the past year
- Sales during the past year
- Detection of new trends
- Sample reports show Osberts 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)
18Report of Purchases during the Past Year The
Osbert Oglesby Case Study
- 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
Figure 10.16
19Report of Sales during the Past Year The Osbert
Oglesby Case Study
- 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
Figure 10.17
20Report 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
year - To appear in this report, at least two of the
artists works must have been sold by Osbert
during that period
Figure 10.18
21Updated 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)
22Updated Use Cases The Osbert Oglesby Case Study
(contd)
Figure 10.19
2310.10 The Test Workflow The Osbert Oglesby Case
Study
- 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
24The Test Workflow The Osbert Oglesby Case Study
(contd)
- The description of the use case Update a
Fashionability Coefficient
Figure 10.21
25Second Iteration of the Use-Case Diagram The
Osbert Oglesby Case Study
- Incorporate all four use cases
Figure 10.22
26The Test Workflow The Osbert Oglesby Case Study
(contd)
- 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
27The Test Workflow The Osbert Oglesby Case Study
(contd)
- 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
2810.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
29The 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
3010.12 Rapid Prototyping
- 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
31Rapid Prototyping (contd)
- A rapid prototype is built for change
- Languages for rapid prototyping include 4GLs and
interpreted languages
3210.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
33Human Factors (contd)
- 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
3410.14 Reusing the Rapid Prototype
- Reusing a rapid prototype is essentially
code-and-fix - Changes are made to a working product
- Expensive
- Maintenance is hard without specification and
design documents - Real-time constraints are hard to meet
35Reusing 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 prearranged
- Those parts pass SQA inspections
- However, this is not classical rapid prototyping
3610.15 CASE Tools for the Requirements Workflow
- 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
37CASE Tools for the Requirements Workflow (contd)
- Graphical CASE environments extended to support
UML include - System Architect
- Software through Pictures
- Object-oriented CASE environments include
- Rose
- Together
- ArgoUML (open source)
3810.16 Metrics for the Requirements Workflow
- Volatility and speed of convergence are measures
of how rapidly the clients needs are determined
39Metrics for the Requirements Workflow (contd)
- 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
4010.17 Challenges of the Requirements Phase
- Employees of the client organization often feel
threatened by computerization - The requirements team members must be able to
negotiate - The clients 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