1. 1 OOAD Mehwish Shafiq

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

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

4. 4 Example: Anti-nuclear protestors released live cockroaches inside the White House Friday, and these were arrested when they left and blocked a security gate. Syntax Is correct but there z no semantic

5. 5 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. Now… syntax is okay BUT U cant get the sense out of it….can u???

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 &/or sugar (to taste)  Drink

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

8. 8 A checklist for fuzzy requirements 1. Incomplete lists ending with "etc.," "and/or,“. 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.“ 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 for the U.S. Air Force.

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

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

11. 11 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)

12. 12 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”

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

14. 14 Use Case MemberLeader Lead RideReserve Bike Book Ride Go Back To Slide 11

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