1 / 68

CHAPTER 4

An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process McGraw-Hill, 2004 Stephen R. Schach srs@vuse.vanderbilt.edu. CHAPTER 4. THE REQUIREMENTS WORKFLOW I. Chapter Overview. Determining What the Client Needs Overview of the Requirements Workflow

waskew
Télécharger la présentation

CHAPTER 4

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 

More Related