1. An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process McGraw-Hill, Stephen R. Schach

2. THE REQUIREMENTS WORKFLOW I
CHAPTER 4
THE REQUIREMENTS WORKFLOW I

3. Chapter Overview 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

4. Chapter Overview (contd)
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

5. Determining the Client’s Needs
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

6. Determining the Client’s Needs (contd)
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

7. Determining the Client’s Needs (contd)
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

8. Overview of the Requirements Workflow
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

9. Flowchart of the Requirements Workflow

10. Definitions Discovering the client’s requirements
Requirements elicitation (or requirements capture)
Methods include interviews and surveys
Refining and extending the initial requirements
Requirements analysis

11. Understanding the Domain
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

12. Initial Understanding: Osbert Oglesby Case Study
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)

13. Glossary: Osbert Oglesby Case Study

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

15. Interviewing
The requirements team meet with the client and users to extract all relevant information

16. Interviewing (contd) 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

17. Interviewing (contd) 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

18. Other Information Gathering Techniques
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

19. Other Information Gathering Techniques (contd)
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

20. Use Cases
A use case models an interaction between the information system itself and the users of that information system (actors)
Example:

21. Use Cases (contd) 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

22. Use Cases (contd)
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

23. Use Cases (contd) A user of the system can play more than one role
Example: A customer of the bank can be
A Borrower or
A Lender

24. Use Cases (contd)
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

25. Use Cases (contd) 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

26. Use Cases (contd) 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

27. Use Cases (contd) Alternatively:
Actor Medical Staff with two specializations: Physician and Nurse

28. Init. Business Model: Osbert Oglesby Case Study
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

29. Init. Business Model: Osbert Oglesby Case Study
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

30. Init. Business Model: Osbert Oglesby Case Study
Osbert has three business activities:
He buys paintings
He sells paintings
He produces reports

31. Init. Business Model: Osbert Oglesby Case Study
Buy a Painting use case

32. Init. Business Model: Osbert Oglesby Case Study
Sell a Painting use case

33. Init. Business Model: Osbert Oglesby Case Study
Produce a Report use case

34. Init. Business Model: Osbert Oglesby Case Study
For conciseness, all three use cases are combined into a use-case diagram  

35. Init. Business Model: Osbert Oglesby Case Study
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

36. Init. Business Model: Osbert Oglesby Case Study
Next, the use cases have to be annotated
Here are the initial use-case descriptions

37. Init. Business Model: Osbert Oglesby Case Study
Buy a Painting use case

38. Init. Business Model: Osbert Oglesby Case Study
Sell a Painting use case

39. Init. Business Model: Osbert Oglesby Case Study
Produce a Report use case

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

41. Initial Requirements (contd)
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

42. Initial Requirements (contd)
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

43. Initial Requirements: Osbert Oglesby Case Study
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

44. Initial Requirements: Osbert Oglesby
Buy a Painting use case

45. Initial Requirements: Osbert Oglesby (contd)
Sell a Painting use case

46. Initial Requirements: Osbert Oglesby (contd)
Produce a Report use case

47. Initial Requirements: Osbert Oglesby (contd)
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

48. Requirements Workflow: Osbert Oglesby
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

49. Attributes: 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 4.15)
Attributes when selling a painting are:
Date of sale, name of buyer, address of buyer, actual selling price

50. Requirements Workflow: Osbert Oglesby
Now the algorithm for computing the maximum purchase price is considered
Classify the painting as a
Masterpiece
Masterwork, or
Other painting 

51. Maximum Price for a Masterpiece
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

52. Maximum Price for a Masterwork
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)

53. Maximum Price for an Other Painting
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

54. Coefficient of Similarity: Osbert Oglesby
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

55. Coefficient of Similarity: Osbert Oglesby (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

56. Fashionability Coefficients: Osbert Oglesby
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

57. Auction Data: Osbert Oglesby Case Study
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

58. Updated Use Cases : Osbert Oglesby Case Study
The use-case descriptions must reflect this information
The resulting description of the Buy a Painting use case is in Figure 4.15

59. Updated Use Cases : Osbert Oglesby Case Study
The description of the Sell a Painting use case:

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

61. Report of Purchases during the Past Year
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

62. Report of Sales during the Past Year
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

63. Report of Trends during the Past Year
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

64. Updated Use-Case Description: Produce a Report
The updated description of the Produce a Report use case, incorporating the details listed above, appears in Figure 4.20

65. It Ain’t Over Till it’s Over
There is a serious omission
The use case for updating a fashionability coefficient has been overlooked
Missing use case Modify a Fashionability Coefficient

66. Use-Case Modify a Fashionability Coefficient
Use-case description

67. Second Iteration of Use-Case Diagram
Incorporate all four use cases

68. Analysis of Req. Workflow: Osbert Oglesby
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