This document discusses the process of requirements elicitation for object-oriented software engineering. It describes identifying actors, scenarios, use cases, relationships between use cases and actors, non-functional requirements, and initial analysis objects. The goal of requirements elicitation is to develop a requirements document that is correct, complete, consistent, unambiguous, realistic, verifiable, and traceable. This is achieved through activities like questions to identify actors and scenarios, elements to include in scenario and use case descriptions, and refining the use case model through iterations with users.

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

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

5. 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]

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

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

8. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8
Elements of a Scenario Description
 Scenario name warehouseOnFire
 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.

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

10. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10
Elements of a Use Case Description
 Use case name ReportEmergency
 Actor[s] Initiated by FieldOfficer
Communicates with Dispatcher
 Entry conditions FieldOfficer initiates ReportEmergency
function on her laptop
 Flow of events 1. 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 conditions FieldOfficer receives ETA.
 Special requirements Ack report within 30 sec. Send ETA
within 30 more sec.

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

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

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

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

15. 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)
 While (there are unresolved items) do:
 Resolve an item on list of issues/ambiguities;
 Modify RAD accordingly;
 Insert new, more detailed unresolved items;