1. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 The requirements engineering process

2. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 2 Feasibility studies l A feasibility study decides whether or not the proposed system is worthwhile. l A short focused study that checks If the system contributes to organisational objectives; If the system can be engineered using current technology and within budget; If the system can be integrated with other systems that are used.

3. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 3 Feasibility study implementation l Based on information assessment (what is required), information collection and report writing. l Questions for people in the organisation What if the system wasn’t implemented? What are current process problems? How will the proposed system help? What will be the integration problems? Is new technology needed? What skills? What facilities must be supported by the proposed system?

4. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 4 Elicitation and analysis l Sometimes called requirements elicitation or requirements discovery. l Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints. l May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.

5. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 5 Problems of requirements analysis l Stakeholders don’t know what they really want. l Stakeholders express requirements in their own terms. l Different stakeholders may have conflicting requirements. l Organisational and political factors may influence the system requirements. l The requirements change during the analysis process. New stakeholders may emerge and the business environment change.

6. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 6 Process activities l Requirements discovery Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage. l Requirements classification and organisation Groups related requirements and organises them into coherent clusters. l Prioritisation and negotiation Prioritising requirements and resolving requirements conflicts. l Requirements documentation Requirements are documented and input into the next round of the spiral.

7. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 7 ATM stakeholders l Bank customers l Representatives of other banks l Bank managers l Counter staff l Database administrators l Security managers l Marketing department l Hardware and software maintenance engineers l Banking regulators

8. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 8 Interviewing l In formal or informal interviewing, the RE team puts questions to stakeholders about the system that they use and the system to be developed. l There are two types of interview Closed interviews where a pre-defined set of questions are answered. Open interviews where there is no pre-defined agenda and a range of issues are explored with stakeholders.

9. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 9 Interviews in practice l Normally a mix of closed and open-ended interviewing. l Interviews are good for getting an overall understanding of what stakeholders do and how they might interact with the system. l Interviews are not good for understanding domain requirements Requirements engineers cannot understand specific domain terminology; Some domain knowledge is so familiar that people find it hard to articulate or think that it isn’t worth articulating.

10. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 10 Scenarios l Scenarios are real-life examples of how a system can be used. l They should include A description of the starting situation; A description of the normal flow of events; A description of what can go wrong; Information about other concurrent activities; A description of the state when the scenario finishes.

11. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 11 LIBSYS scenario (1)

12. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 12 LIBSYS scenario (2)

13. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 13 Use cases l Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself. l A set of use cases should describe all possible interactions with the system. l Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.

14. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 14 Article printing use-case

15. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 15 LIBSYS use cases

16. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 16 Article printing

17. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 17 Print article sequence

18. Slide 10.18 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. 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

19. Slide 10.19 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. 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

20. Slide 10.20 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. 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

21. Slide 10.21 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. 10.4.1 Interviewing l The requirements team meet with the client and users to extract all relevant information

22. Slide 10.22 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Interviewing (contd) l There are two types of questions – Close-ended questions require a specific answer – Open-ended questions are posed 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

23. Slide 10.23 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. 10.4.3 Use Cases l A use case models an interaction between the software product itself and the users of that software product (actors) l Example: Figure 10.1

24. Slide 10.24 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. 10.13 Rapid Prototyping l Hastily built (“rapid”) – Imperfections can be ignored l Exhibits only key functionality l Emphasis on only what the client sees – Error checking, file updating can be ignored l Aim: – To provide the client with an understanding of the product

25. Slide 10.25 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Scenarios l A use case provides a generic description of the overall functionality l A scenario is an instance of a use case l Sufficient scenarios need to be studied to get a comprehensive insight into the target product being modeled

26. Slide 10.26 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Normal Scenario: Elevator Problem Figure 11.3

27. Slide 10.27 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Exception Scenario: Elevator Problem Figure 11.4

28. Example: A Use-Case Diagram for ATM The name of a use case usually conveys that valued provided to the actor.

29. Flow of Events The most important part of the use case in the requirements workflow is its flow of events. It describes the sequence of actions between the actor and the system. It is written in natural language, in a simple, consistent prose, with a precise use of terms that draws on a common glossary of the problem domain.

30. Example: A Flow of Events An initial outline of the flow of events of the use case Withdraw Money could be written as follows: 1) The use case begins when the Client inserts a card into the ATM. The system reads and validates information on the card. 2) The system prompts for a personal identification number (PIN). Client enters the PIN. The system validates the PIN. 3) The system asks which operation the client wishes to perform. Client selects “Withdraw Money.” 4) The system requests the amount of withdrawal. Client enters amount. 5) The system requests the account type. Client selects the account type (checking, savings, credit).

31. Example: A Flow of Events (cont.) The flow of events of the use case Withdraw Money: 6) The system communicates with the ATM network to validate the account ID, PIN, and availability of the amount requested. 7) The system asks the Client whether a receipt is desired. This step is performed only if there is paper available to print the receipt. 8) The system asks the Client to remove the card. Client removes the card. (The request is a security measure to ensure that Clients do not leave their cards in the machine.) 9) The system dispenses the requested amount of cash. 10) The system prints a receipt, if requested, which ends the use case.

32. Courses of Action The path through the use-case flow of events is determined by several things such as: Input from an actor –Actor can choose from several options what to do next. The internal state of the system –ATM may be out of cash or have no paper for receipts, etc. Time-outs and errors –ATM user does not respond within a specified time interval.

33. Scenarios Use cases are grouped with other related use-case flows of events. –A grouping defines a use-case class. An instance of a use-case is one specific flow of events, or a specific path, through the use case. A use-case class is referred to as a use case, while a use-case instance is referred to as scenario. Scenarios are used in the process to extract and emphasize a unique sequence of actions or “thread” through a use case.

34. Structuring of Flows of Events. A scenario is a combination of main and alternate flows from start to finish through a use case.

35. Use-Case Model The use-case model consists of the set of all use cases for the system, or a portion of the system, together with the set of all actors that interact with these use cases. It describes the complete functionality of the system. It can serve as a contract between the customer and the developers. RUP uses use-case diagrams and activity diagrams to visualize the use-cases model, including possible relationships among use cases.

36. Use Case Diagram

37. Activity Diagram