3 Requirements

Object-Oriented Software Engineering
Conquering Complex and Changing Systems
Elicitation
Chapter 4,
Requirements
Software Lifecycle Activities
Requirements Requirements System Object Implemen-

Testing
Elicitation Analysis Design Design tation
Implemented
Expressed in By
Structured By Realized By
Terms Of Verified
By
class...
class...
class... ?
class....?
Use Case Application Implementat
Domain SubSystems Source Test
Model ion Domain
Objects Code Cases
Objects
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2
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
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
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]
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
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?
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.
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.
Elements of a Use Case Description
 Use case nameReportEmergency

 Actor[s] Initiated by FieldOfficer
Communicates with Dispatcher
 Entry conditions FieldOfficer 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 conditions FieldOfficer receives ETA.
 Special requirements Ack report within 30 sec. Send ETA
within 30 more sec.
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.
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.
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
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.
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;

3 Requirements

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3 Requirements

Uploaded by

Copyright:

Available Formats

Object-Oriented Software Engineering

Conquering Complex and Changing Systems

Requirements Requirements System Object Implemen-

Questions whose answers identify the actors:

 With which external systems does the system interact?

 Scenario name warehouseOnFire

 A scenario is an instance of a use case.

 Use case format follows.

 Use case nameReportEmergency

Iterate the following steps:

 Access control – which actors access which functionality – is

It may be one of the system objects if it is a:

Investigate the following:

 Create a draft Requirements Analysis Document (RAD)

You might also like