1. Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 4, Requirements Elicitation

2. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2 Software Lifecycle Activities Application Domain Objects SubSystems class... Implementat ion Domain Objects Source Code Test Cases ? Expressed in Terms Of Structured By Implemented By Realized By Verified By System Design Object Design Implemen- tation Testing class.... ? Requirements Elicitation Use Case Model Requirements Analysis

3. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3 Defining the System Boundary: What do you see?

4. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4 System Identification  Development of a system is not just done by taking a snapshot of a scene (domain)  Definition of the system boundary  What is inside, what is outside?  Requirements Process:  Requirements Elicitation: Definition of the system in terms understood by the customer  Analysis: Technical specification of the system in terms understood by the developer.

5. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5 System and Object identification  Two important problems during requirements engineering and requirements analysis:  Identification of objects  Definition of the system purpose  Depending on the purpose of the system, different objects might be found  What object is inside, what object is outside?  How can we identify the purpose of a system?  Scenarios  Use cases: Abstractions of scenarios

6. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6 Products of requirements elicitation and analysis Requirements Elicitation analysis model :Model system specification :Model Analysis (UML activity diagram) Contract with the user

7. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7 Can you develop this?

8. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8 Requirements Elicitation  Challenging activity  Requires collaboration of people with different backgrounds  User with application domain knowledge  Developer with implementation domain knowledge  Bridging the gap between user and developer:  Scenarios: Example of the use of the system in terms of a series of interactions with between the user and the system  Use cases: Abstraction that describes a class of scenarios

9. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9 Types of Requirements  Functional requirements: Describe the interactions between the system and its environment independent from implementation  The watch system must display the time based on its location  Nonfunctional requirements: User visible aspects of the system not directly related to functional behavior.  The response time must be less than 1 second  The accuracy must be within a second  The watch must be available 24 hours a day except from 2:00am- 2:01am and 3:00am-3:01am  Constraints (“Pseudo requirements”): Imposed by the client or the environment in which the system will operate  The implementation language must be COBOL.  Must interface to the dispatcher system written in 1956.

10. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10 What is usually not in the Requirements?  System structure, implementation technology  Development methodology  Development environment  Implementation language  Reusability It is desirable that none of these above are constrained by the client. Fight for it!

11. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11 Functional requirements for SatWatch SatWatch is a wrist watch that displays the time based on its current location. SatWatch uses GPS satellites (Global Positioning System) to determine its location and intemal data stnictures to convert this location into a time zone. The information stored in the watch and its accuracy measuring time (one hundredth of second uncertainty over five years) is such that the watch owner never needs to reset the time. SatWatch adjusts the time and date displayed as the watch owner crosses time zones and political boundaries (e.g., standard time vs. daylight savings time). For this reason, SatWatch has no buttons or controls available to the user. SatWatch has a two-line display showing, on the top line, the time (hour, minute, second, time zone) and, on the bottom line, the date (day of the week, day, month, year). The display technology used is such that the watch owner can see the time and date even under poor light conditions. When a new country or state institutes different rules for daylight savings time, the watch owner may upgrade the software of the watch using the WebifyWatch seria1 device (provided when the watch is purchased) and a persona1 computer connected to the Intemet. SatWatch complies with the physical, electrical, and software interfaces defined by WebifyWatch API 2.0.

12. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12 Nonfunctional requirements for SatWatch SatWatch determines its location using GPS satellites, and as such, suffers from the same limitations as al1 other GPS devices (e.g., ~100 feet accuracy, inability to determine location at certain times of the day in mountainous regions). During blackout penods, SatWatch assumes that it does not cross a time zone or a political boundary. SatWatch corrects its time zone as soon as a blackout period ends. The battery life of SatWatch is limited to 5 years, which is the estimated life cycle of the housing of SatWatch. The SatWatch housing is not designed to be opened once manufactured, preventing battery replacement and repairs. Instead, SatWatch is priced such that the watch owner is expected to buy a new SatWatch to replace a defective or old SatWatch.

13. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13 Pseudorequirement for SatWatch Al1 related software associated with SatWatch, including the onboard software, will be written using Java, to comply with current company policy.

14. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 14 Requirements Validation  Critical step in the development process,  Usually after requirements engineering or requirements analysis. Also at delivery  Requirements validation criteria:  Correctness:  The requirements represent the client’s view.  Completeness:  All possible scenarios through the system are described, including exceptional behavior by the user or the system  Consistency:  There are functional or nonfunctional requirements that contradict each other  Clarity:  There are no ambiguities in the requirements. To be continued …

15. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 15 Requirements Validation Criteria (continued)  Realism:  Requirements can be implemented and delivered  Traceability:  Each system function can be traced to a corresponding set of functional requirements

16. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 16 Types of Requirements Elicitation  Greenfield Engineering  Development starts from scratch, no prior system exists, the requirements are extracted from the end users and the client  Triggered by user needs  Re-engineering  Re-design and/or re-implementation of an existing system using newer technology  Triggered by technology enabler  Interface Engineering  Provide the services of an existing system in a new environment  Triggered by technology enabler or new market needs

17. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 17 Requirements Elicitation Activities  Identify actors  Identify scenarios  Identify use cases  Identify relationships among use cases  Refine use cases  Identify nonfunctional requirements  Identify participating objects

18. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18 Identifying actors  Actors represent external entities that interact with the system  An actor can be an human or an external system  Actors in the SatWatch example:  Watch owner  GPS satellites  WebifyWatch serial device

19. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 19 Scenarios  “A narrative description of what people do and experience as they try to make use of computer systems and applications” [M. Carrol, Scenario-based Design, Wiley, 1995]  A concrete, focused, informal description of a single feature of the system used by a single actor.  Scenarios can have many different uses during the software lifecycle

20. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 20 Scenario Example: Warehouse on Fire  Bob, driving down main street in his patrol car notices smoke coming out of a warehouse. His partner, Alice, reports the emergency from her car.  Alice enters the address of the building, a brief description of its location (i.e., north west corner), and an emergency level. In addition to a fire unit, she requests several paramedic units on the scene given that area appear to be relatively busy. She confirms her input and waits for an acknowledgment.  John, the Dispatcher, is alerted to the emergency by a beep of his workstation. He reviews the information submitted by Alice and acknowledges the report. He allocates a fire unit and two paramedic units to the Incident site and sends their estimated arrival time (ETA) to Alice.  Alice received the acknowledgment and the ETA.

21. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 21 Documentation schema for the scenario Scenario name: warehouse0nFire Participating actor instances: bob, alice : FieldOfficer john: Dispatcher Flow of events : 1.Bob, driving down main street in his patrol car notices smoke coming out of a warehouse. His partner, Alice, activates the “Report Emergency” function from her FRIEND laptop. 2.Alice enters the address of the building, a brief description of its location (i.e., northwest corner), and an emergency level. In addition to a fire unit, she requests severa1 paramedic units on the scene, given that the area appears to be relatively busy. She confirms her input and waits for an acknowledgment. 3.John, the Dispatcher, is alerted to the emergency by a beep of his workstation. He reviews the information submitted by Alice and acknowledges the report. He creates allocates a fire unit and two paramedic units to the Incident site and sends their estimated arrival time (ETA) to Alice. 4.Alice receives the acknowledgment and the ETA.

22. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 22 Types of Scenarios  As-is scenario  Used in describing a current situation. Usually used during re- engineering. The user describes the system.  Visionary scenario  Used to describe a future system. Usually described in greenfield engineering or reengineering.  Can often not be done by the user or developer alone  Evaluation scenario  User tasks against which the system is to be evaluated  Training scenario  Step by step instructions designed to guide a novice user through a system

23. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 23 Questions for finding Scenarios Ask yourself or the client the following questions:  What are the primary tasks that the system needs to perform?  What data will the actor create, store, change, remove or add in the system?  What external changes does the system need to know about?  What changes or events will the actor of the system need to be informed about? Insist on task observation if the system already exists (interface engineering or reengineering)  Ask to speak to the end user, not just to the software contractor  Expect resistance and try to overcome it

24. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 24 Summary  Requirements Elicitation:  Greenfield Engineering, Reengineering, Interface Engineering  Scenarios:  Great way to establish communication with client  As-Is Scenarios, Visionary scenarios, Evaluation scenarios Training scenarios  Use cases: Abstraction of scenarios  Pure functional decomposition is bad:  Leads to unmaintainable code  Pure object identification is bad:  May lead to wrong objects, wrong attributes, wrong methods  The key to successful analysis:  Start with use cases and then find the participating objects  If somebody asks “What is this?”, do not answer right away. Return the question or observe: “What is it used for?”