1. Slide 10A.1 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005

2. Slide 10A.2 © The McGraw-Hill Companies, 2005 CHAPTER 10 — Unit A REQUIREMENTS

3. Slide 10A.3 © The McGraw-Hill Companies, 2005 REQUIREMENTS- Overview l Determining what the client needs l Overview of the requirements workflow l Understanding the domain l The business model l Initial requirements l Initial understanding of the domain: The Osbert Oglesby case study l Initial business model: The Osbert Oglesby case study l Initial requirements: The Osbert Oglesby case study

4. Slide 10A.4 © The McGraw-Hill Companies, 2005 Overview (contd) l Continuing the requirements workflow: The Osbert Oglesby case study l The test workflow: The Osbert Oglesby case study l The classical requirements phase l Rapid prototyping l Human factors l Reusing the rapid prototype l CASE tools for the requirements workflow l Metrics for the requirements workflow l Challenges of the requirements workflow

5. Slide 10A.5 © The McGraw-Hill Companies, 2005 The Aim of the Requirements Workflow l To answer the question: l What must the product be able to do?

6. Slide 10A.6 © The McGraw-Hill Companies, 2005 10.1 Determining What the Client Needs l Misconception  We must determine what the client wants l “I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant!” l We must determine what the client needs

7. Slide 10A.7 © The McGraw-Hill Companies, 2005 Determining What the Client Needs (contd) l It is hard for a systems analyst to visualize a software product and its functionality  The problem is far worse for the client l A skilled systems analyst is needed to elicit (bring out) the appropriate information from the client l The client is the only source of this information

8. Slide 10A.8 © The McGraw-Hill Companies, 2005 Determining What the Client Needs (contd) l 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

9. Slide 10A.9 © The McGraw-Hill Companies, 2005 10.2 Overview of the Requirements Workflow l First, gain an understanding of the application domain (or domain, for short)  The specific environment in which the target product is to operate l Second, build a business model  Model the client’s business processes l Third, use the business model to determine the client’s requirements l Iterate the above steps

10. Slide 10A.10 © The McGraw-Hill Companies, 2005 Definitions l Discovering the client’s requirements  Requirements elicitation (or requirements capture)  Methods include interviews and surveys l Refining and extending the initial requirements  Requirements analysis

11. Slide 10A.11 © The McGraw-Hill Companies, 2005 10.3 Understanding the Domain l Every member of the development team must become fully familiar with the application domain  Correct terminology is essential l Construct a glossary  A list of technical words used in the domain, and their meanings

12. Slide 10A.12 © The McGraw-Hill Companies, 2005 10.4 Business Model l A business model is a description of the business processes of an organization l The business model gives an understanding of the client’s business as a whole  This knowledge is essential for advising the client regarding computerization l The systems analyst needs to obtain a detailed understanding of the various business processes  Different techniques are used, primarily interviewing

13. Slide 10A.13 © The McGraw-Hill Companies, 2005 10.4.1 Interviewing l The requirements team meet with the client and users to extract all relevant information

14. Slide 10A.14 © The McGraw-Hill Companies, 2005 Interviewing (contd) l There are two types of questions  Close-ended questions require a specific answer  Open-ended questions are asked to encourage the person being interviewed to speak out l 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

15. Slide 10A.15 © The McGraw-Hill Companies, 2005 Interviewing (contd) l 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 l 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

16. Slide 10A.16 © The McGraw-Hill Companies, 2005 10.4.2 Other Techniques l Interviewing is the primary technique l A questionnaire is useful when the opinions of hundreds of individuals need to be determined l Examination of business forms shows how the client currently does business

17. Slide 10A.17 © The McGraw-Hill Companies, 2005 Other Techniques (contd) l Direct observation of the employees while they perform their duties can be useful  Videotape cameras are a 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

18. Slide 10A.18 © The McGraw-Hill Companies, 2005 10.4.3 Use Cases l +A use case models an interaction (business activity) between the software product itself and the users of that software product (actors) l Example: Figure 10.1

19. Slide 10A.19 © The McGraw-Hill Companies, 2005 Use Cases (contd) l An actor is a member of the world outside the software product l It is usually easy to identify an actor  An actor is frequently a user of the software product l In general, an actor plays a role with regard to the software product. This role is  As a user; or  As an initiator; or  As someone who plays a critical part in the use case

20. Slide 10A.20 © The McGraw-Hill Companies, 2005 Use Cases (contd) l A user of the system can play more than one role l Example: A customer of the bank can be  A Borrower or  A Lender

21. Slide 10A.21 © The McGraw-Hill Companies, 2005 Use Cases (contd) l Conversely, one actor can be a participant in multiple use cases l 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 l Also, the actor Borrower may stand for many thousands of bank customers

22. Slide 10A.22 © The McGraw-Hill Companies, 2005 Use Cases (contd) l An actor need not be a human being l Example: An e-commerce 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 e-commerce information system  The e-commerce information system is an actor from the viewpoint of the credit card company information system

23. Slide 10A.23 © The McGraw-Hill Companies, 2005 Use Cases (contd) l A potential problem when identifying actors  Overlapping actors l Example: Hospital software product  One use case has actor Nurse  A different use case has actor Medical Staff  Better: Actors: Physician and Nurse

24. Slide 10A.24 © The McGraw-Hill Companies, 2005 Use Cases (contd) l Alternatively:  Actor Medical Staff with two specializations: Physician and Nurse Figure 10.2

25. Slide 10A.25 © The McGraw-Hill Companies, 2005 10.5 Initial Requirements l The initial requirements are based on the initial business model l 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

26. Slide 10A.26 © The McGraw-Hill Companies, 2005 Initial Requirements (contd) l There are two categories of requirements l A functional requirement specifies an action that the software product must be able to perform  Often expressed in terms of inputs and outputs l A nonfunctional requirement specifies properties of the software product itself, such as  Platform constraints  Response times  Reliability

27. Slide 10A.27 © The McGraw-Hill Companies, 2005 Initial Requirements (contd) l Functional requirements are handled as part of the requirements and analysis workflows l 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

28. Slide 10A.28 © The McGraw-Hill Companies, 2005 10.6 Initial Understanding of the Domain: The Osbert Oglesby Case Study l Osbert Oglesby, Art Dealer, needs a software product to assist him in buying and selling paintings l Obtaining domain knowledge is the first step l Osbert is interviewed to obtain the relevant information l This information is put into a glossary (see next slide)

29. Slide 10A.29 © The McGraw-Hill Companies, 2005 Glossary: The Osbert Oglesby Case Study Figure 10.3

30. Slide 10A.30 © The McGraw-Hill Companies, 2005 10.7 Initial Business Model: The Osbert Oglesby Case Study l Osbert wants an software product, 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 l To do this, the software product needs to keep a record of all purchases and all sales

31. Slide 10A.31 © The McGraw-Hill Companies, 2005 Initial Business Model: The Osbert Oglesby Case Study (contd) l Currently, Osbert produces reports of annual sales and purchases by hand  At only a small additional cost, the software product can also print these two reports on demand l It is vital to determine the client’s needs up front, and not after the software product has been delivered

32. Slide 10A.32 © The McGraw-Hill Companies, 2005 Initial Business Model: The Osbert Oglesby Case Study (contd) l Osbert has three business activities:  He buys paintings  He sells paintings  He produces reports

33. Slide 10A.33 © The McGraw-Hill Companies, 2005 Initial Business Model: The Osbert Oglesby Case Study (contd) Buy a Painting use case Figure 10.4

34. Slide 10A.34 © The McGraw-Hill Companies, 2005 Initial Business Model: The Osbert Oglesby Case Study (contd) Sell a Painting use case Figure 10.5

35. Slide 10A.35 © The McGraw-Hill Companies, 2005 Initial Business Model: The Osbert Oglesby Case Study (contd) Produce a Report use case Figure 10.6

36. Slide 10A.36 © The McGraw-Hill Companies, 2005 Initial Business Model: The Osbert Oglesby Case Study (contd) l For conciseness, all three use cases are combined into a use-case diagram Figure 10.7

37. Slide 10A.37 © The McGraw-Hill Companies, 2005 Initial Business Model: The Osbert Oglesby Case Study (contd) l The only person who uses the current (manual) software product 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 l The customer plays a critical part in both use cases by providing data entered into the software product by Osbert  The customer is therefore an actor in both these use cases

38. Slide 10A.38 © The McGraw-Hill Companies, 2005 Initial Business Model: The Osbert Oglesby Case Study (contd) l Next, the use cases have to be annotated l Here are the initial use-case descriptions

39. Slide 10A.39 © The McGraw-Hill Companies, 2005 Initial Business Model: The Osbert Oglesby Case Study (contd) Buy a Painting use case Figure 10.8

40. Slide 10A.40 © The McGraw-Hill Companies, 2005 Initial Business Model: The Osbert Oglesby Case Study (contd) Sell a Painting use case Figure 10.9

41. Slide 10A.41 © The McGraw-Hill Companies, 2005 Initial Business Model: The Osbert Oglesby Case Study (contd) Produce a Report use case Figure 10.10

42. Slide 10A.42 © The McGraw-Hill Companies, 2005 Continued in Unit 10B