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

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

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3 Requirements Elicitation Activities Requirement:  A feature the system must have  A constraint the system must satisfy Identify  actors  scenarios  use cases  relationships among use cases  nonfunctional requirements  participating objects

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4 Requirements Elicitation Concepts  Functional requirements  Interaction between system & actors  Avoid specifying how the system works  Nonfunctional requirements  Examples include  Performance  Accuracy  Documentation  Pseudo requirements  Imposed by client  E.g., Cappello requires: –Java implementation –Runs in student lab

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5 Requirement Document Desiderata  Correct  The client agrees that it represents the reality  Complete  The client agrees that all relevant scenarios are described  Consistent  Unambiguous  There is only 1 way to interpret the specification  Realistic  All features can be implemented subject to all constraints  Verifiable  Requirements & constraints are testible  Traceable  For each system function there is some requirement[s]  For each requirement there is some system function[s]

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6 Identify Actors Questions whose answers identify the actors:  Which user groups does the system support to do their work?  Which user groups execute the system’s primary functions?  Which user groups execute the system’s secondary functions?  E.g., maintain or administer the system  With which external systems does the system interact?  E.g., hardware or software

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7 Identify Scenarios Scenario  A description of what actors do as they use the system  For each scenario, there is a:  Use case  Acceptance test case Questions for identifying scenarios:  What tasks to the actors want the system to perform?  What data does the actor need?  Who creates, modifies, removes that data?  Which external changes affect the system’s state?  How is the change communicated to the system? (what actor?)  Under what circumstances?

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8 Elements of a Scenario Description  Scenario namewarehouseOnFire  Actor instances Bob, Alice: FieldOfficer John: Dispatcher  Flow of events 1. Bob, driving in partrol car notices smoke coming out of warehouse. Partner Alice activates Report Emergency from laptop. 2. Alice enters building’s address, location, emergency level. Requests fire unit, paramedics. Confirms input. Awaits ack. 3. John is alerted by his workstation’s beep. Acks report. Allocates fire & paramedic units to Incident site; returns ETA to Alice. 4. Alice receives ack and ETA.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9 Identify Use Cases  A scenario is an instance of a use case.  Partition the set of scenarios into use cases.  Keep this set compact  Modify scenarios to increase their uniformity.  Use case format follows.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10 Elements of a Use Case Description  Use case nameReportEmergency  Actor[s]Initiated by FieldOfficer Communicates with Dispatcher  Entry conditionsFieldOfficer initiates ReportEmergency function on her laptop  Flow of events1. FieldOfficer fills form: select emergency level, type, location, description, possible responses. Submits form; 2. Dispatcher acks report. Creates Incident in DB: Invoke OpenIncident use case. Selects response; Sends ETA.  Exit conditionsFieldOfficer receives ETA.  Special requirements Ack report within 30 sec. Send ETA within 30 more sec.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11 Refine the Use case model Iterate the following steps:  Define a horizontal slice (i.e., many high-level scenarios) to define the scope of the system.  Validate the use case model with the user.  Detail a vertical slice.  Validate with the user.  In extreme programming, you design, implement, test [and integrate] this vertical slice, before tackling the next vertical slice.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12 Identify Relationships Among Actors & Use Cases  Access control – which actors access which functionality – is represented with use cases.  Extend relation  ConnectionDown use case:  Entry condition: –Connection between FieldOfficer & Dispatcher fails before EmergencyReport is submitted  Event flow: –FieldOfficer notifies Dispatcher via voice channel  Heuristics:  Use extend relation for exceptions, optional, or rare behavior.  Use include relation for behavior common to 2 or more use cases.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13 Identify Initial Analysis Objects It may be one of the system objects if it is a:  Term developers/users need to clarify to understand a use case;  Recurring noun in the use case model;  Real-world object the system needs to track (e.g., FieldOfficer)  Real-world process the system needs to track (e.g., EmergencyOperationPlan)  Use cases (e.g., ReportEmergency)  Application domain term

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 14 Identify Nonfunctional Requirements Investigate the following:  User interface – level of expertise of user  Documentation – User manual? The system design should be documented. What about development process?  Hardware considerations – What assumptions are made?  Software – Ditto.  Error handling – philosophy (e.g., tolerates failure of any single system component).  Physical environment – what assumptions are made about power supply, cooling, etc.  Physical security  Resource – constraints on power, memory, etc.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 15 To Do List  Project definition  Complete a project description that the customer agrees to.  Research  Initial identification of actors & event flows  Document unresolved issues/ambiguities  Create a draft Requirements Analysis Document (RAD)Requirements Analysis Document  While (there are unresolved items) do:  Resolve an item on list of issues/ambiguities;  Modify RAD accordingly;  Insert new, more detailed unresolved items;