CHAPTER 4

1. An Introduction toObject-Oriented Systems Analysis and Design with UML and the Unified ProcessMcGraw-Hill, 2004Stephen R. Schachsrs@vuse.vanderbilt.edu

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