The document discusses requirements elicitation techniques for identifying stakeholder needs and determining the requirements of a software system. It provides an overview of various elicitation methods like interviews, questionnaires, documentation review, scenarios and ethnography. It also describes best practices for conducting interviews, meetings and active listening during the elicitation process. Finally, it discusses the need for a structured elicitation methodology to effectively gather, analyze and validate requirements from different sources.

1. Requirements Elicitation
Requirements Elicitation
Requirement techniques

2. Requirements Elicitation
Case Studies
Standards
Projects
Req. Validation
Exchanging Req.
Req. Expression &
Modelling
System engineering
Req. Management
Req. Elicitation
Basic introduction
RE Techniques
Requirement Engineering
Req. Traceability
Software systems
Reactive systems

3. Contents
• Requirements elicitation
• Guidelines
• Methodology
• Basic techniques for eliciting requirements
• Interviews
• Meetings
• Planning
• ...

4. Some basic points
• Elicitation is not Acquisition
• Requirements are not available like sensor data
Not just read them systematically !!
• Elicitation is not specification and modelling
• Too much importance has been given to
expression and modelling
• RE Determines the success of the mission
• Elicitation detrmines the success of the RE
process

5. What Is Elicitation ?
• Process of identifying needs
• Front End to systems development
• Involves social, communicative issues and
Technical issues
• Requirement expression is the step to model
the requirements.

6. A common Problem !!
What is your need ?
I need a system that
works OK
Robust and respond to
my wishes

7. As problems in social life
AVOID MISUNDERSTANDING !!

8. A simple scenario
• I need a book
• What for ? Or What discipline ?
• To .....; in fact anything to level up my terminal
• So you any item but Not necessarily a book

9. Elicitation : a subset of goals
• Identify the relavant parties . The stackholders
• Gather the Wish List for each stachholder
• Document and refine the Wish list
• Expected properties
• Unambiguous
• Complete
• Verifiable
• Consistent
• Modifiable
• Traceable
•

10. Common generic problems
• Scope : too much or too little
• Understandings : Users and developpers
• Users have an incomplete understanding of their
needs
• Analysts and SE have a poor knowledge of
problem domain
• Ease of omitting obvious information Volatility :
changing requirements

11. The Scope problem
• Establish a bounday conditions for the target system
• Organisation and context analysis

12. The Misunderstanding pb

13. Some data on the Pb
• 56 % of errors were due to poor communication
between user and analyste
• Such errors cost 82% of the available staff time
•Three main issues
• people involved comes from different backgrounds
• Language used may be too informal or too formal
• A large amount of information to be commnicated
and not really structured

14. The misun ...
• Stakholders may be located at different levels
• May correspond to levels to abstraction
• From informal knowledge to ...formal
expression
• Notion of maturity levels
• Dont mix up with abstraction levels
• Many people are involved : Questions
• When in the eliciaition process ?
• At what level ?

15. The Volatility problem
• REQUIREMENTS EVOLVE : A basis
• Some requiremenrs are more emphasized than needed
during elecitation process
• The boss is always rights
• His needs are more considered even not mature and
ambigous
• Change may occur due to
• Misunderstanding
• Scope

16. An Elicitation methodology Framework
• basic remark : Most requirements problems are due to
requirements elicitation
• General remark . No technique is comprehensive
enough to adequatly cover all mentionned issues
• Objective : Synthesize all methods and techniques
into a methodology which can be instantiated upon a
target system´s atributes

17. The Elicitation methodology
Fact findings
Req Gathering
Evaluation
Prioritisation
Integration
and Validation

18. Fact findings
User Developper
• Identify Stackholders
• Determine operational and
problem contexte
• Identify other systems
•´Perform context analysis
• Identify domain experts
• Id. Domain
• Conduct technological
survey
• Asses cost/implementation

19. Requirements gathering
User Developper
• Get Wish List • Classify wish list
* Functional
* NFR
* Env.
* ...
See www.incose.org/rwg
paper on requirements
categrorisation

20. Evaluation and rationalisation
User Developper
• Perform abstraction to
answer question
• see interview
techniques
•Perform risk assessment
• Cost benefit ...

21. Prioritisation
User Developper
* Dtermine criticality • Prioritisation of requirements
• basis : cost, criticality, ...

22. Integration and validation
User Developper
•Adress completeness :
TBD type
• validate req with respect
concept of operation
• Decide to go on next step
* Demo
* prototype
* ...
•Consistency checking

23. Conclusion on the methodology
• Abstract methodology
• Still be considered as guide
• An evaluation crireria to be developped :
• No information on evaluation

24. The stackholder connection
• Sometimes called requirements analysis or
requirements discovery
• Involves technical staff working with
customers to find out about the application
domain, the services that the system should
provide and the system’s operational
constraints
• May involve end-users, managers, engineers
involved in maintenance, domain experts,
trade unions, etc. These are called
stakeholders

25. Specific elicitation techniques
• Documentation
• Interviews
• Questionnaires
• Scenarios
• Ethnography

26. Gathering Information About...
• The organisation
• goals, structure, functional units, policies
• The people
• authority, duties, relationships, information,
needs
• The work
• tasks, work flows, procedures, schedules,
volumes, performance criteria
• The work environment
• work areas, resources

27. Gathering Information From...
• Documentation
• charts, manuals, job descriptions, forms,
reports
• System users and managers
• External sources
• other companies, vendors, publications,
seminars, workshops, on-line data services

28. Interviews
• The requirements engineer or analyst
discusses the system with different
stakeholders and builds up an
understanding of their requirements.
• Identify
• work flows
• factors that influence the operations of systems
• the elements (documents, procedures, policies etc.)
that make up systems

29. Types of Interviews
• Closed interviews. The requirements
engineer looks for answers to a pre-defined
set of questions
• goal-directed and systematic
• Open interviews There is no predefined
agenda and the requirements engineer
discusses, in an open-ended way, what
stakeholders want from the system.
• Appropriate when we want to explore an issue
• establish rapport and obtain a broad view

30. Interviewing essentials
• Interviewers must be open-minded and
should not approach the interview with pre-
conceived notions about what is required
• Stakeholders must be given a starting point
for discussion. This can be a question, a
requirements proposal or an existing system
• Interviewers must be aware of
organisational politics - many real
requirements may not be discussed because
of their political implications

31. Interview Steps
• Preparing
• Planning
• Opening and Closing
• Conducting
• Following up

32. Preparing for the interview
• Review
• organisation reports
• annual reports
• statements of departments goals
• long-range planning goals
• existing procedure manuals
• systems documentation
• understand their language

33. Planning of Interviews
• Identify sources
• prepare
* purpose, outline of points to cover
• venue
• appointments
• prepare the interviewee
* points to cover, useful documents

34. Questioning
• Open questions
– tell me what happens when a customer calls
• leading questions
• be wary of negative responses
– exceptions?
• Subjects who try to please

35. Listening
• Judge content and not delivery
• withhold evaluation and response
• be flexible
• work at listening
• resist distractions
• keep your mind open
• listen for ideas

36. Opening and closing and Following Up the interview
• Introduce yourself
• state the purpose of the interview
• briefly summarise the areas that have been
discussed, highlight important points and
your understanding of them
• thank the interviewee for the time
• Ask closed questions
• Document the results

37. Questionnaires
• Validity
- sample size, audience
• Reliability
• Questions
- open ended
- fill in the blank
- multiple choice
- rating scales

38. Scenarios
• Scenarios are stories which explain how a
system might be used. They should include
- a description of the system state before
entering the scenario
- the normal flow of events in the scenario
- exceptions to the normal flow of events
- information about concurrent activities
- a description of the system state at the end of
the scenario

39. Scenarios
• Scenarios are examples of interaction
sessions which describe how a user interacts
with a system
• Discovering scenarios exposes possible
system interactions and reveals system
facilities which may be required
 Operational semantics

40. Observation and social analysis
• People often find it hard to describe what
they do because it is so natural to them.
Sometimes, the best way to understand it is to
observe them at work
• Ethnography is a technique from the social
sciences which has proved to be valuable in
understanding actual work processes
• Actual work processes often differ from
formal, prescribed processes

41. Meetings
• Meetings consume resources
• must improve quality of meetings
• Meetings have different objectives
• solve problems, clarify issues
• brainstorm solutions to problems
• resolve conflicts
• conduct reviews
• collect and merge facts and data
• report progress
• assign actions

42. Meetings: Planning
• Define clearly the expected results or
outcomes of the meeting
• Find if possible a way to eliminate the need
for the meeting
• do we really need the outcome of this meeting at
this moment?
• Is there another more efficient and more effective
way to accomplish what is to be accomplished by
holding this meeting?
• If yes and no are the answers to the two questions
then proceed

43. Meetings: Planning
• Prepare agenda for the meeting
• reasonable time allocation for each topic
• circulate at least two days before the meeting
• to allow time for the attendees to prepare, comment and make
schedule arrangements
• identify and notify required meeting attendees. Must have the
right people
• the appropriate information and knowledge to support meeting
goals and objectives
• the authority )direct or delegated) to make decisions and
commitments if required by the meeting’s goals and objectives
• the need to understand what is going on and the rationale behind
any decisions or commitments made during the meeting

44. Meetings: Planning
• Meeting location considerations
• room size, lighting, noise, temperature, humidity can
distract
• need for audio/visual aids in working order
• Start and Finish on time
• Record and publish minutes
• Have handouts ready for distribution
• review the agenda, meeting goals and objectives
first
• discourage interruptions and deflections from the
topic at hand
• follow the agenda schedule as closely as possible

45. Active Listener Guidelines
• Clear your mind of everything except the speaker,
the topic and what the speaker is actually saying.
Prevent trying to read more into what the speaker
is saying than the speaker is actually saying
• Capture as accurately as possible the information
that the speaker is conveying
• Let the speaker know by actions that s/he is
interested in what is being said
• Ask questions as they arise to clarify points,
indicate understanding and provide feedback to
the speaker

46. Active Listener Guidelines
• Ask that the central ideas, themes and summaries
be repeated to assure complete understanding
• Do not attempt to formulate replies, rebuttals or
counterexamples while the speaker is talking
• Do not draw conclusions until you have heard the
whole story
• Accept that understanding is not agreeing
• Do not be afraid to ask if there is something that
you have not been told.

47. Methodologies
• A number of techniques are available to
describe the workings of a system
• Many people have taken a number of these
techniques and produced a method for using
them to arrive at a specification

48. Methodologies Division
• Main Division
• Data driven
• SSADM
• Process driven
• Yourdon
• JSD
• Is there a universally best methodology?
• No
• Can I combine methodologies?
• Maybe

49. Comparison of Methodologies
• Can one compare the available methodologies?
• against an ideal methodology
• not feasible because no suitable specification of an ideal
methodology exists
• assess the features and facilities of each methodology within
a formalised framework
• invent questions about each methodology
• ask the questions for each methodology
• merge and describe the results
• decide?

50. Typical Comparison Questions
• For the comparison one may ask
• Does the methodology cover all phases? Which ones? How
thoroughly.
• Are the steps fairly proceduralised or does the methodology
only give broad directions? Are analysis, design and
implementation given equal weight?
• Is it data or process analysis oriented?
• Does it cover prototyping and incremental development?
• How are the results of analysis and design expressed?
• Is the methodology supported by software?
• What types of applications is it suited to? History?

51. Decomposition Diagrams
• A high-level organisation (or function or activity) is
decomposed into lower organisations (or functions
or activities). The lower we go in the hierarchy the
greater the detail revealed
• Used to show organisation, system, program, file
and report structures
• organisation
• functions
• processes
• procedures
• program structures

52. Viewpoints for requirements elicitation
• The Preview approach adresses the cases
where
• Sources from radical sources
• Identify key business drivers
• Incremental process for requirement elicitation

53. PREVIEW Components
• Viewpoint name : an identifier
• Viewpoint focus : interaction, domain, stakeholder
• Viewpoint concerns : all concerns applicable
• Viewpoint sources : individuals, documents
• Viewpoint requirements : Req. from source
• Viewpoint history : changes record
Limited only to requirement elicitation
and NOT Validation

54. Example (Sommerville paper ICRE-98)
• Emergency braking system
• Viewpoint name : emergency braking system
• Viewpoint focus : The protection system of the train which must
detect dangerous condistions and apply emergency braking to bring train to a
safe state
• Viewpoint concerns : Safe compatibility
• Viewpoint sources : systems design; function spec of existing
protection software

55. Example
• Viewpoint requirements : 1. Detection of excess speed , if
the speed of the train exceeds the safe speedfor the current track segment by
more than 6 kmh emergency braking must be applied
2. Detection of overshooting, if the signal sensor indicates a danger setting
and the front of the train has entered the signalled track segment,
emergency braking shall be applied
3. Frequency of invocation , detection of excess speed, detection of
overshooting, and determining the necessity of emergency brake application
shall be performed once every iteration of the on board software application
cycle
• Viewpoint history : case of evolving requirement(following an
accident or a failure)

56. Conclusions
• Elicitation Process is The FIRST PHASE
• Needs to be successful  Just DO IT
• Be convinced it needs to be done
• Any technique will do (see resources and
papers)

57. Appendix: Additional Slides

58. Where are we right now?
• Three ways to deal with complexity:
– Abstraction
– Decomposition (Technique: Divide and conquer)
– Hierarchy (Technique: Layering)
• Two ways to deal with decomposition:
– Object-orientation and functional decomposition
– Functional decomposition leads to unmaintainable code
– Depending on the purpose of the system, different objects
can be found
• What is the right way?
– Start with a description of the functionality (Use case
model). Then proceed by finding objects (object model).
• What activities and models are needed?
– This leads us to the software lifecycle we use in this class

59. Software Lifecycle Definition:
• Software lifecycle:
– Set of activities and their relationships to each other to
support the development of a software system
• Typical Lifecycle questions:
– Which activities should I select for the software project?
– What are the dependencies between activities?
– How should I schedule the activities?
– What is the result of an activity

60. Problem Statement:
• The problem statement is developed by the client as a
description of the problem addressed by the system
• Other words for problem statement:
– Statement of Work
• A good problem statement describes
– The current situation
– The functionality the new system should support
– The environment in which the system will be deployed
– Deliverables expected by the client
– Delivery dates
– A set of acceptance criteria

61. 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!

62. ARENA: The Problem
• The Internet has enabled virtual communities
– Groups of people sharing common of interests but who have never met
each other in person. Such virtual communities can be short lived (e.g
people in a chat room or playing a multi player game) or long lived (e.g.,
subscribers to a mailing list).
• Many multi-player computer games now include support for virtual
communities.
– Players can receive news about game upgrades, new game levels,
announce and organize matches, and compare scores.
• Currently each game company develops such community support in each
individual game.
– Each company uses a different infrastructure, different concepts, and
provides different levels of support.
• This redundancy and inconsistency leads to problems:
– High learning curve for players joining a new community,
– Game companies need to develop the support from scratch
– Advertisers need to contact each individual community separately.

63. ARENA: The Objectives
• Provide a generic infrastructure for operating an arena to
– Support virtual game communities.
– Register new games
– Register new players
– Organize tournaments
– Keeping track of the players scores.
• Provide a framework for tournament organizers
– to customize the number and sequence of matchers and the
accumulation of expert rating points.
• Provide a framework for game developers
– for developing new games, or for adapting existing games
into the ARENA framework.
• Provide an infrastructure for advertisers.

64. Types of Requirements
• Functional requirements:
– Describe the interactions between the system and its environment
independent from implementation
– Examples:
• An ARENA operator should be able to define a new game.
• Nonfunctional requirements:
– User visible aspects of the system not directly related to functional
behavior.
– Examples:
• The response time must be less than 1 second
• The ARENA server must be available 24 hours a day
• Constraints (“Pseudo requirements”):
– Imposed by the client or the environment in which the system operates
• The implementation language must be Java
• ARENA must be able to dynamically interface to existing games
provided by other game developers.

65. 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
– Example: Develop a game from scratch: Asteroids
• Re-engineering
– Re-design and/or re-implementation of an existing system
using newer technology
– Triggered by technology enabler
– Example: Reengineering an existing game
• Interface Engineering
– Provide the services of an existing system in a new
environment
– Triggered by technology enabler or new market needs
– Example: Interface to an existing game (Bumpers)

66. Current Situation: The Problem To Be Solved
• There is a problem in the current situation
– Examples:
• The response time when playing letter-chess is far too slow.
• I want to play Go, but cannot find players on my level.
• What has changed? Why can address the problem now?
– There has been a change, either in the application domain or in the
solution domain
– Change in the application domain
• A new function (business process) is introduced into the
business
• Example: We can play highly interactive games with remote
people
– Change in the solution domain
• A new solution (technology enabler) has appeared
• Example: The internet allows the creation of virtual communities.

67. Heuristics: How do I find use cases?
• Select a narrow vertical slice of the system (i.e. one scenario)
– Discuss it in detail with the user to understand the user’s
preferred style of interaction
• Select a horizontal slice (i.e. many scenarios) to define the scope
of the system.
– Discuss the scope with the user
• Use illustrative prototypes (mock-ups) as visual support
• Find out what the user does
– Task observation (Good)
– Questionnaires (Bad)

68. Next goal, after the scenarios are formulated:
• Find all the use cases in the scenario that specifies all possible
instances of how to report a fire
– Example: “Report Emergency “ in the first paragraph of the
scenario is a candidate for a use case
• 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, Nonfunctional
Requirements

69. ReportEmergency
Use Cases
• A use case is a flow of events in the system, including interaction with
actors
• It is initiated by an actor
• Each use case has a name
• Each use case has a termination condition
• Graphical Notation: An oval with the name of the use case
Use Case Model: The set of all use cases specifying the complete
functionality of the system
Name of Use Case
Actors: Description of Actors involved in use case)
Entry condition: “This use case starts when…”
Flow of Events: Free form, informal natural language
Exit condition: “This use cases terminates when…”
Exceptions: Describe what happens if things go wrong
Special Requirements: NFR, Constraints

70. Another Use Case Example: Allocate a Resource
• Actors:
– Field Supervisor: This is the official at the
emergency site....
Resource Allocator: The Resource Allocator is
responsible for the commitment and decommitment
of the Resources managed by the FRIEND system.
...
Dispatcher: A Dispatcher enters, updates, and
removes Emergency Incidents, Actions, and
Requests in the system. The Dispatcher also closes
Emergency Incidents.
– Field Officer: Reports accidents from the Field

71. Another Use Case Example: Allocate a Resource
• Use case name: AllocateResources
• Participating Actors:
– Field Officer (Bob and Alice in the Scenario)
– Dispatcher (John in the Scenario)
– Resource Allocator
– Field Supervisor
• Entry Condition
– The Resource Allocator has selected an available resource.
– The resource is currently not allocated
• Flow of Events
– The Resource Allocator selects an Emergency Incident.
– The Resource is committed to the Emergency Incident.
• Exit Condition
– The use case terminates when the resource is committed.
– The selected Resource is now unavailable to any other Emergency Incidents or
Resource Requests.
• Special Requirements
– The Field Supervisor is responsible for managing the Resources

72. Order of steps when formulating use cases
• First step: name the use case
– Use case name: ReportEmergency
• Second step: Find the actors
– Generalize the concrete names (“Bob”) to participating actors
(“Field officer”)
– Participating Actors:
• Field Officer (Bob and Alice in the Scenario)
• Dispatcher (John in the Scenario)
• Third step: Then concentrate on the flow of events
– Use informal natural language