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

UNB CS3013 Software Engineering II lectures adapted from 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

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3 Requirements Elicitation Activities  Identify actors  Identify scenarios  Identify use cases  Identify relationships among use cases  Refine use cases  Identify nonfunctional requirements  Identify participating objects

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4 Defining the System Boundary: What do you see?

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5 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?  How can we identify the purpose of a system?  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.

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6 Products of Requirements Process Requirements Elicitation analysis model :Model system specification :Model Analysis

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7 System Specification vs Requirements Analysis Model  Both focus on the requirements from the user’s view of the system.  System specification uses natural language (derived from problem statement)  Requirements analysis model uses formal or semi-formal notation (e.g., UML)

UNB CS3013 Software Engineering II lectures adapted from 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

UNB CS3013 Software Engineering II lectures adapted from 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.

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10 Figure 4-2. A System is a collection of real world Phenomena. A Model is a collection of Concepts that represent the System ’s Phenomena. Many Models can represent different aspects of the same System. An unambiguous Model corresponds to only one System. describes * 1 * * Model System ConceptPhenomenon

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11 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!

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12 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.

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13 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

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 14 Requirements evolution  Requirements change rapidly during requirements elicitation. Tool for managing requirements:  Requisite Pro from Rational  Stores requirements in a repository  Multi-user access  Automatically creates a requirements document from the repository  Provides traceability and change management throughout the project lifecycle 

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 15 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

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 16 Figure 4-3. Actors for the SatWatch system. WatchOwner moves the watch (possibly across time zones) and consults it to know what time it is. SatWatch interacts with GPS to compute its position. WebifyWatch upgrades the data contained in the watch to reflect changes in time policy (e.g., changes in daylight savings time start and end dates). WatchOwner GPS WebifyWatch SatWatch

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 17 Figure 4-4. Actors of the FRIEND system. FieldOfficers not only have access to different functionality, they use different computers to access the system. FieldOfficerDispatcher FRIEND

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18 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

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 19 A Good Scenario?  Example 1. The guest makes a reservation with the hotel. The hotel will take as many reservations as it has rooms available. When a guest arrives, he or she is processed by the registration clerk. The clerk will check the details provided by the guest with those that are already recorded. Sometimes guests do not make a reservation before they arrive. Some guests want to stay in non-smoking rooms. [Roberts et al., 1998: 68]

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 20 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

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 21 How do we find scenarios?  Don’t expect the client to be verbal if the system does not exist (greenfield engineering)  Don’t wait for information even if the system exists  Engage in a dialectic approach (evolutionary, incremental)  You help the client to formulate the requirements  The client helps you to understand the requirements  The requirements evolve while the scenarios are being developed

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 22 Heuristics 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

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 23 Example Scenario  It is 2 o'clock in the morning, and Ian cannot get his new HyperCam software to install properly. He points his browser to gets the splash page, and waits for the corporate home page to appear. He scrolls down the page and clicks on the tech support link. On the provided form, he types his name, then gets his customer ID off the packing slip for the HyperCam and types it in. He clicks the Submit button. He scans the Tech Support home page and finally clicks on the GIF showing a befuddled user with a packing crate. This takes him to the Installation Help page, where he begins filling out the Incident Report form. Dissatisfied with the suggestion supplied by the system after the form is submitted, he goes to the Contact Us page and sends an message.

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 24 Example Use Case  The use case begins when the customer goes to the Customer Log-On page. There, the customer types in his/her name and customer ID on the form and submits it. The system then displays the Tech Support home page with a list of Problem Categories. The customer clicks on Installation Help within the list, and the system supplies the Incident Report Form. The customer completes and submits the form, and the system presents a suggested resolution.