1. Object Oriented Software Development 2009-2010 Modelling information systems OOSAD Booklet Chapter 3 Lecture: Week 2 Brian Farrimond

2. 2 Objectives At the end of this session you should be able to: Explain some difficulties in requirements analysis Describe in outline some strategies for obtaining requirements Explain the purpose of the following UML models in the process: Use Case Class Association Diagram Sequence Diagram

3. 3 System Requirements The Requirements specification must provide sufficient information to enable the system to be constructed “ successfully. ” Functional requirements What the system must do (tasks) Non-Functional Requirements Eg constraints, such as hardware to be used, Eg interface, documentation, training, management standards to be used.

4. 4 The Difficulty with Requirements System Requirements are normally written in English According to the Oxford English Dictionary, the 500 words used most in the English language each have an average of 23 different meanings.

5. 5 Examples: Anti-nuclear protestors released live cockroaches inside the White House Friday, and these were arrested when they left and blocked a security gate. The Duchess handled the launching beautifully, confidently smashing the champagne against the prow. The crowd cheered as she majestically slid down the greasy runway into the sea.

6. 6 What’s wrong with these? “The system shall list all the details of the members”. Instructions to make tea Fill kettle with water Put tea bag in cup Pour water from kettle into cup Add milk Drink

7. 7 From a British Airways Memorandum, quoted in Pilot Magazine, December 1996: The Landing Pilot is the Non-Handling Pilot until the decision altitude call, when the Handling Non-Landing Pilot hands the handling to the Non-Handling Landing Pilot, unless the latter "calls go around," in which case the Handling Non-Landing Pilot continues handling and the Non-Handling Landing Pilot continues non-handling until the next call of "land" or "go around" as appropriate. In view of recent confusions over these rules, it was deemed necessary to restate them clearly.

8. 8 Requirements should be.. Complete Unambiguous Correct ( does what the user wants) …. Whatever that is.

9. 9 A checklist for fuzzy requirements 1. Incomplete lists ending with "etc.," "and/or," and "TBD.“ 2. Vague words and phrases such as "generally," "normally," "to the greatest extent," and "where practicable.“ 3. Imprecise verbs such as "supported," "handled," "processed," or "rejected.“ 1988, the MITRE Corporation, prepared a checklist for the U.S. Air Force:

10. 10 A checklist for fuzzy requirements 4. Implied certainty, flagged by words such as "always," "never," "all," or "every.“ 5. Passive voice, such as "the counter is set." (By whom or what?) 6. Every pronoun, particularly "it" or "its." Each should have an explicit and unmistakable reference. 7. Comparatives, such as "earliest," "latest," "highest." Words ending in "or" or "est" should be suspect. 1988, the MITRE Corporation, prepared a checklist for the U.S. Air Force:

11. 11 A checklist for fuzzy requirements 8. Words and phrases whose meaning can be disputed between developer and customer, such as instantaneous, simultaneous, achievable, minimum, 9. Contractually troublesome phrases: a. "Design goal." The developer will spend money and other resources with no guarantee of goal accomplishment. b. "To the extent practicable." A decision in the eyes of the developer. c. "Where applicable." There are no criteria for judgment. d. "Shall be considered." The developer will think about. e. "A minimum of X." The developer will provide exactly X. 1988, the MITRE Corporation, prepared a checklist for the U.S. Air Force:

12. 12 Gathering requirements – How? Background Reading Interviewing Observation Document Sampling Questionnaires

13. 13 Your Coursework You will eventually need to Think about how this applies to your feasibility study (Coursework 3)

14. 14 Modelling for Clarity Models represent the key features An abstraction of reality The meaning of the model elements and rules for combining must be understood and clear Unambiguous syntax and semantics Used to communicate with Developers, Clients, (and any passing aliens)

15. 15 Example – Mountain bike hire company Extract from Statement of Requirements “ Only members can hire bikes. A member can reserve bikes in advance (the system records details of the bike, member, date and time reserved).” “Leaders (who must be members) take groups of members on particular rides. A leader has to hold a leadership certificate. ” “Members can ride by themselves or can book specific rides”

16. 16 Use Case Modelling This shows the tasks and what or who will initiate them. What tasks can you identify?

17. 17 Use Case MemberLeader Lead RideReserve Bike Book Ride Static Model

18. 18 Class Modelling The system is composed of objects that communicate to perform the system’s tasks. Objects represent real-world things, events or roles (e.g. a particular member or bike) Objects have Attributes and Behaviour A Class is a template for objects of the same type (eg Bike is a Class)

19. 19 Class Association Model A Class-Association Diagram shows the structure of the system: eg

20. 20 Class Association Generalisation

21. 21 Generalisation A Leader is-a-kind-of Member Therefore The Leader Inherits all the characteristics of a Member and adds extra (specialised) behaviour or attributes Member is a generalisation of leader Leader is a specialisation (or Sub- class) of Member

22. 22 Association A Ride is led by 1 Leader A Leader Leads many Rides

23. 23 How many reservations can a member make?

24. 24 Dynamic Models Use Case and Class diagrams do not show how a system behaves over Time Dynamic models can show this UML has several Dynamic models, you will only meet Sequence Diagrams on this course. These show details of how a Use Case is implemented, corresponding to program code.

25. 25 A Possible Book Bike Ride Use Case Time Object Message

26. 26 Summary Systems are complex, Models help to represent key features clearly and reduce ambiguity. Requirements should be Unambiguous Complete Correct Use Case models show tasks Class Diagram models show structure Sequence Diagram models show behaviour of a single use case over time.