CHAPTER 10 — Unit C

1. Object-Oriented and Classical Software EngineeringSixth Edition, WCB/McGraw-Hill, 2005Stephen R. Schachsrs@vuse.vanderbilt.edu

2. CHAPTER 10 — Unit C REQUIREMENTS

3. Continued from Unit 10B

4. 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

5. 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

6. Attributes: The Osbert Oglesby Case Study (contd) Figure 10.14

7. 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 • Masterpiece • Masterwork, or • Other painting 

8. 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

9. 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)

10. 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

11. 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 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

12. 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

13. 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 experience • He changes the value if prices for work by an artist increase or decrease

14. 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

15. 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)

16. Updated Use Cases: The Osbert Oglesby Case Study • The description of theSell a Painting use case: Figure 10.15

17. Reports: 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 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):

18. 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 year • The average ratio of the purchase price to the suggested maximum price is required at the end of the report Figure 10.16

19. 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 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

20. 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 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

21. 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)

22. Updated Use Cases: The Osbert Oglesby Case Study (contd) Figure 10.19

23. 10.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 caseUpdate a Fashionability Coefficient Figure 10.20

24. The Test Workflow: The Osbert Oglesby Case Study (contd) • The description of the use case Update a Fashionability Coefficient Figure 10.21

25. Second Iteration of the Use-Case Diagram: The Osbert Oglesby Case Study • Incorporate all four use cases Figure 10.22

26. The 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

27. The 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

28. 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

29. 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

30. 10.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

31. Rapid Prototyping (contd) • A rapid prototype is built for change • Languages for rapid prototyping include 4GLs and interpreted languages

32. 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

33. Human 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

34. 10.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

35. 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 prearranged • Those parts pass SQA inspections • However, this is not “classical” rapid prototyping

36. 10.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

37. CASE 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)

38. 10.16 Metrics for the Requirements Workflow • Volatility and speed of convergence are measures of how rapidly the client’s needs are determined

39. Metrics 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

40. 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 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