1. Chapter 5, Requirements Elicitation and Analysis

2. Last Lesson and Outlook
Requirements Elicitation
What are requirements?
Functional vs. non-functional requirements
Process of requirements elicitation
1. Step: How to elicit requirements
Analyzing existing systems (Tests, Manuals)
Interviews
Today:
Elicitation
Observations
Write Down Requirements ( Scenarios)
Aggregate Scenarios ( Use Cases) and Refine Use Cases
Requirement Validation
Requirements Analysis
Map Use Cases to the Analysis Object Model

3. Observation
People often find it hard to describe what they do because it is so natural to them.
Actual work processes often differ from formal, prescribed processes
 Sometimes the best way to understand it is to observe them at work
Approach: adopt methods e.g. from the social sciences which has proved to be valuable in understanding actual work processes
Suitable Approach: Ethnography (Lecture ORE)

4. Brainstorming
Brainstorming refers to the process of systematic and liberal generation of a large volume of ideas from a number of participants.
Participants are encouraged to provide creative inputs in an atmosphere that is free of criticism and judgment from other participants. 
Unstructured brainstorming
Participants can give ideas as these come to mind
Quite often not very efficient
Structured brainstorming
Participants must follow a process model in order to make the gathering of inputs more orderly and more efficiently.

5. Roles in the Software Life-Cycle
Developer
A role that is concerned with specifying and implementing (sub)systems
Client (Customer)
(End-)User
A role representing the people who will use the delivered system
A role representing the person or company commissioning paying for the development of the system

6. Process of Requirements Elicitation: The Requirements Elicitation Cycle
Tests
Validation
Validation
Validation
Observing users
As-Is Scenarios
Use Cases + Refinements
Prototypes
Interviewing users and clients
Visionary Scenarios
Validation
Validation
Stable Requirements Specification (System Specification)
Functional Requirements
Non-Functional Requirements
Use Cases
Scenarios

7. 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.
Developers and Users collaboratively write scenarios to gain a shared understanding of what the system should be
Scenarios can have many different uses during the software lifecycle
Requirements Elicitation: As-is scenario, visionary scenario
Client Acceptance Test: Evaluation scenario
System Deployment: Training scenario.

8. Scenarios: Different Types
As-is scenario
Used in describing a current situation
Usually used in re-engineering projects
The user describes the system
Visionary scenario
Used to describe a future system
Usually used in greenfield engineering and reengineering projects
Can often not be done by the user or developer alone  brainstorming sessions, future workshop
Evaluation scenario
User tasks against which the system is to be evaluated
Training scenario
Step by step instructions that guide a novice user through a system
Re-design and/or re-implementation of an existing system using newer technology
Helps to reveal problems and hints that exist in the current situation

9. Scenarios: 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?
However, don’t rely on questionnaires alone.
Insist on task observation if the system already exists (interface engineering or reengineering)
Ask to speak to the end user, not just to the client

10. Scenarios: Example - Accident Management System
What needs to be done to report an incident?
What do you need to do if a person reports “Warehouse on Fire?”
Who is involved in reporting an incident?
Can the system cope with a simultaneous incident report “Warehouse on Fire?”
What kind of questions could be asked for such as systmes.

11. 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 by using the SYSTEM.
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.

12. Scenarios: Observations about “Warehouse on Fire”
Concrete scenario
Describes a single instance of reporting a fire incident.
Does not describe all possible situations in which a fire can be reported.
Participating actors
Bob, Alice and John

13. Process of Requirements Elicitation: The Requirements Elicitation Cycle
Tests
Validation
Validation
Validation
Observing users
As-Is Scenarios
Use Cases + Refinements
Prototypes
Interviewing users and clients
Visionary Scenarios
The validation process can be improved by implementing prototypes
Prototypes are used to simulate selected functions of the system to the client, so that users have a better understanding of what the system should be. Also used to evaluate the requirements
Validation
Validation
Stable Requirements Specification (System Specification)
Functional Requirements
Non-Functional Requirements
Use Cases
Scenarios

14. Use Cases: Next goal, after the scenarios are formulated
Find all the use cases in the set of scenarios that completely represent the future system.
Abstractions of many scenarios
Example: “Report Emergency” is a candidate for a use case from the first paragraph of the scenario
Describe each of these use cases in more detail
Participating actors
Describe the Entry Condition
Describe the Flow of Events
Describe the Exit Condition
Describe Exceptions
Describe Special Requirements (Constraints, non-functional Requirements

15. Use Cases: Definition
A Use Case describes a function (behaviour) provided by the system in terms of flowing events, including interaction with actors
It is initiated by an actor
Each use case has a name
Graphical Notation: An oval with the name of the use case
A Use Case describes or a function or behaviour provided by the system in terms of flowing events. Since a use case is initiated by an actor, we can also indicate that a use case realizes the external behaviour of a system as seen from the users point of view. Consequently, a use case does not only model the internal flow of control, but also the communicatin between actors and the function being modelled by the use case
ReportEmergency
Use Case Model: The set of all use cases specifying the complete functionality of the system

16. Use Cases: Communication relationships between actors and use cases
Dispatcher
FieldOf f
icer
OpenIncident
ReportEmergency
A line indicates which users are capable of invoking a use case
AllocateResources
Users, Roles
Which user can invoke which use case

17. Use Cases Textual Representation
Template for a textual use case
Use case name
Participating Actors
Flow of Events
Entry Condition
Exit Condition
Quality Requirements

18. Use Cases Textual Representation
Example (Excerpt, see [Bruegge&Dutoit, 2004], p. 135)
Initialized by an actor
Use case name
Participating Actors
Flow of Events
Entry Condition
Exit Condition
Quality Requirements
ReportEmergency
Initiated by FieldOfficer, communicates with Dispatcher
The FieldOfficer activates the ReportEmergency function on this terminal
SYSTEM responds by presenting a dialog form to the FieldOfficer
FieldOfficer completes and submitts the form
SYSTEM receives the form, evaluates the inform- ation in interaction with a Dispatcher and sends an acknowledge
Initialized by the system
Indented events: denotes who has initialized this step within the entire flow of control.
Writing guide how one can write a use case
The FieldOfficer is logged into the SYSTEM
The FieldOfficer receives an acknowledge
The FieldOfficer‘s request is acknowlegded within 30 seconds.

19. Use Cases: Associations
A use case model consists of use cases and use case associations
A use case association is a relationship between use cases
Important types of use case associations: Include, Extends, Generalization
Include
A use case uses another use case (“functional decomposition”)
Extends
A use case extends another use case
Generalization
An abstract use case has different specializations

20. Use Cases: <<Include>> Functional Decomposition
Problem:
A function in the original problem statement is too complex to be solvable immediately or the function is already existing
Solution:
Describe the function as the aggregation of a set of simpler functions. The associated use case is decomposed into smaller use cases
ManageIncident
Reducing complexity by functional decomposition
<<include>>
CreateIncident
HandleIncident
CloseIncident

21. Use Cases: <<Extend>> Association for Use Cases
Problem:
The functionality in the original problem statement needs to be extended (optional behaviour, exceptional behaviour)
Solution:
An extend association from a use case A to a use case B indicates that use case B is an extension of use case A.
ReportEmergency
FieldOfficer
<<extend>>
Base Use
Case
Supplier
Use Case
ConnectionDown
Note: (a) The base use case can be executed without the use case extension in extend associations. (b) The Extending UC knows when it should be executed.

22. Use Cases in a textual way Describing <<include>> and <<extend>>
Report
Emergency
<<include>>
Evaluate
Info
<<include>> relationship
Flow of Events
...
FieldOfficer completes and submitts the form
SYSTEM receives the form, evaluates the information (by using Use Case EvaluateInfo) being received and sends an acknowledge
<<extend>> relationship
Report
Emergency
<<extend>>
Connection
Down
The ConnectionDown use case extends any use case in which the connection between the FieldOfficer and the SYSTEM can be lost
The FieldOfficer is notified that the connection is broken
Entry Condition
Flow of Events

23. Anticipating Change: Extension Points
ReportEmergency
Entry Condition
The Selection extension point is reached in the extended use case.
Open the help system and show context help for the current selection.
Flow of Events
example taken from the OMG Specification of the Unified Modeling Language: Superstructure version 2.0

24. Use Cases: Generalization association in use cases
Problem:
You would like to model a specialized use case from an existing use case.
Solution:
The generalization association among use cases factors out common behavior. The child use cases inherit the behavior and meaning of the parent use case and add or override some behavior.
CheckPassword
Parent
Case
Child
Use Case
ValidateUser
CheckFingerprint

25. Use Cases: How do I find use cases?
Refine a single scenario of the system
Discuss it in detail with the user to understand the user’s assumption about the system
Define many not-very-detailed scenarios to define the scope of the system.
Discuss the scope with the user
Use illustrative prototypes (mock-ups) as visual support
However: interface design is no integral part of use cases
Present multiple and different alternative scenarios
Particularize all scenarios in more detail
Make abstractions over all identified scenarios (use cases)
Validate with user

26. Requirements Validation (1/3)
Requirements Elicitation
Requirements validation is a critical step in the development process, usually during requirements engineering or requirements analysis. Also at delivery (client acceptance test).
Requirements validation criteria:
Complete
All possible scenarios, in which the system can be used, are described, including exceptional behavior by the user or the system
Consistent
There are no two functional or nonfunctional requirements that contradict each other
Unambiguous
Requirements can not be interpreted in mutually exclusive ways
Correct
The requirements represent the client’s view
Consistent:
FieldOfficer should, on the one hand, report an incident on the way, but should at the same time be responsible to acknowledge the report and to allocate the fire unti.  introduce an other actor (Dispatcher) who takes over this task

27. Requirements Validation (2/3)
Requirements Elicitation
More Requirements validation criteria
Realistic
Requirements can be implemented and delivered
Verifiable
Requirements can be checked
Needs an exact description of the requirements
With respect to deadline and budget restrictions

28. Requirements Validation (3/3)
Requirements Elicitation
Problem with requirements validation
Requirements change very fast during requirements elicitation.
Tool support for managing requirements
Store requirements in a shared repository
Provide multi-user access
Allow for change management
Automatically create a system specification document from the repository
Provide traceability throughout the project lifecycle

29. What is Requirements Engineering? (ctd.)
Requirements Elicitation
Requirements Analysis +
Basis for Discussions
Definition of the system in terms understood by the customer (“Problem Description”)
Design basis for developers
Technical specification of the system in terms understood by the developer (“Problem Specification”)
 System Specification
 Analysis Model

30. Analysis and Analysis Model
Analysis focus on producing a model of the system (analysis model) which is:
Correct
Complete
Consistent
Unambiguous
Structuring and formalizing the requirements
New details are added, insights and errors may be discovered
 Update of System Specification often necessary
Analysis Model is basis for further development
Analysis Object Model
Dynamic Model

31. Process of Requirements Analysis
Problem
Statement
Requirements
Elicitation
System specification: functional and non-functional requirements
Requirements
Analysis
Analysis Model: dynamic model
Analysis object model

32. Analysis Object Model vs. Dynamic Model
System from the user’s perspective
Classes and Objects (User-Level Concepts, no software classes!)
Attributes
Operations
Associations
 can serve as visual dictionary of application domain
Dynamic Model
Models the behavior of the system
Responsibilities, Flow of Control
I.e. using
Statechart Diagram (1 Object)
Sequence diagram (Flow of control, relationships)

33. From Requirements Specification to the Analysis Object Model
Important Objects and Classes
Attributes
Application specific
Attributes in one system can be classes in another
Turning Attributes into Classes
Operations
Detection of operations
Generic operations: Get/Set, General world knowledge, design patterns
Domain operations: Dynamic model, Functional model
Associations (Relations)
Generic associations
Canonical associations
Part of- Hierarchy (Aggregation)
Kind of-Hierarchy (Generalization)
Requirements Elicitation
Specification
Scenarios
Use Cases 
Functional Requirements
Conditions
Exceptions

34. Analysis Object Model: Class Identification (1/3)
Identify and describe all important entities in the system
Steps during object modeling
1. Class identification
Based on the fundamental assumption that we can find abstractions
2. Find the attributes
3. Find the methods
4. Find the associations between classes
What happens if we find the wrong abstractions?
Iterate and correct the model
Order of steps secondary, only a heuristic (Iteration is important)
Basic assumption
We can find the classes for a new software system (Forward Engineering)
We can identify the classes in an existing system (Reverse Engineering)

35. Analysis Object Model: Class Identification (2/3)
Objects are not just found by taking a picture of a scene or domain
The application domain has to be analyzed
Depending on the purpose of the system different objects might be found
How can we identify the purpose of a system?
Scenarios and use cases
Another important problem: Define system boundary
What object is inside, what object is outside?

36. Analysis Object Model: Object vs. Class
Object (instance): Exactly one thing
This lecture on Software Engineering on November 15 from 14:30 -16:00
A class describes a group of objects with similar properties
Game, tournament, mechanic, car, database
Object diagram: A graphic notation for modeling objects, classes and their relationships ("associations")
Class diagram
Template for describing many instances of data
Useful for taxonomies, patterns, schemata...
Instance diagram
A particular set of objects relating to each other.
Useful for discussing scenarios, test cases and examples

37. Analysis Object Model: Class Identification (3/3)
Abbott Textual Analysis, 1983, (noun-verb analysis)
Set of heuristics for identifying objects, attributes and associations from a requirements specification
Mapping of parts of speech to model components
Nouns are good candidates for classes
Verbs are good candidates for operations
In the problem statement (originally proposed, but rarely works if the problem statement is large (more than 5 pages)
Quality depends on style of writing
Too many nouns
In the flow of events of use cases (preferable)
Small list of candidate objects
Focus on user terms (+)
Quality of object model depends on the style of writing of the analyst, imprecise lanugage, many nouns
Works well for short description for generating a small list of candidate objects

38. Mapping parts of speech to object model components [Abbott, 1983]
Part of speech
Model component
Example
Proper noun
object
Jim Smith
Common noun
class
Toy, doll
Doing verb
method
Buy, recommend
being verb
inheritance
is-a (kind-of)
Verbs which take an object are usually called transitive verbs. Verbs which do not take an object are usually called intransitive verbs.
having verb
aggregation
has an
modal verb
constraint
must be
adjective
attribute
3 years old
transitive verb
method
enter
intransitive verb
method (event)
depends on

39. Analysis Object Model: Identifying Participating Objects
Pick a use case and look at its flow of events
Find terms that developers or users need to clarify in order to understand the flow of events
Look for recurring nouns (e.g., Incident),
Identify real world entities that the system needs to keep track of (e.g., FieldOfficer, Dispatcher, Resource),
Identify real world procedures that the system needs to keep track of (e.g., EmergencyOperationsPlan),
Identify data sources or sinks (e.g., Printer)
Be prepared that some objects are still missing and need to be found:
Model the flow of events with a sequence diagram
Always use the user’s terms

40. Analysis Object Model: Example – Analyzing The Flow of events (1/2)
The customer enters the store to buy a toy
It has to be a toy that his daughter likes and it must cost less than 50 Euro.
An assistant helps him.
The suitability of the toy depends on the age of the child.
His daughter is 8 years old
The assistant recommends a type of toy, namely the board game “Monopoly“
Not a good description, but okay as an example

41. Analysis Object Model: Example – Analyzing with Abbott’s (2/2)
Grammatical construct
UML Component
“Monopoly"
Proper noun
Object
“toy“, “board game”
Common noun
class
"8 years old"
Adjective
Attribute
“enters"
verb
Method
“depends on…."
Intransitive verb
Method
“is a" ,“either..or",
“type of…"
Classifying verb
Inheritance
"Has a ", “consists of"
Having Verb
Aggregation
“must be", “less than…"
modal Verb
Constraint