Professional Documents
Culture Documents
Elicitation
© JK Balikuddembe - Requirements
5-Mar-21 1
Engineering
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.
© JK Balikuddembe - Requirements
5-Mar-21 2
Engineering
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
© JK Balikuddembe - Requirements
5-Mar-21 3
Engineering
Requirements elicitation goals
• Identify and document business needs*; in order
to do so, you have to:
– Know the problem domain, in order to be able to
communicate with customers & users in their own
language.
– Know the current business model, in order to identify
needs, positive & negative aspects and potential
expectations.
– Know the technological environment, in order to
identify the technical restrictions of the system to be
developed.
© JK Balikuddembe - Requirements
5-Mar-21 4
Engineering
Elicitation Goals- Cont.
• “Never lose sight of why software is being
developed: to satisfy real needs, to solve real
problems. The only way to solve real needs is
to communicate with those who have the
needs. The customer or user is the most
important person involved with your project.”
© JK Balikuddembe - Requirements
5-Mar-21 5
Engineering
Elicitation goals Cont..
• Requirements elicitation goals – Information
systems should help their organizations to…
– Make competitiveness strategic decisions.
– Make business tactical decisions.
– Perform business processes and their related
operations.
• Most information systems developments are
operational-level oriented.
© JK Balikuddembe - Requirements
5-Mar-21 6
Engineering
Common generic problems
© JK Balikuddembe - Requirements
5-Mar-21 9
Engineering
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
© JK Balikuddembe - Requirements
5-Mar-21 10
Engineering
Elicitation:
Discover Stakeholder Requirements through
• Interviews
• Ethnographic studies (observe the user using similar
systems)
• Questionnaires
• Requirements workshops
• Brainstorming and idea reduction
• Storyboarding
• Study similar products & relevant docs
• Use cases
• Prototyping
• Context-free questions
© JK Balikuddembe - Requirements
5-Mar-21 11
Engineering
Analyst Role
• Observe and learn the user needs and tasks (the
problem) and understand them from the user point of
view
– What they are doing and why
• Interpret the user work/tasks
– Filter out technology and current way of doing things to get
to the essence of the work, not its incarnation
• Invent better ways to do the work
– Interpret what the product must do to satisfy the essential
requirements
• Record the results in the form of a requirements
specification and analysis models
• Validate that the analyst and user have the same
understanding of the problem and the product, and that
the user agrees that this is the product wanted
© JK Balikuddembe - Requirements
5-Mar-21 12
Engineering
Fact findings
User Developer
© JK Balikuddembe - Requirements
5-Mar-21 13
Engineering
Requirements gathering
User Developer
© JK Balikuddembe - Requirements
5-Mar-21 14
Engineering
Evaluation and rationalisation
User Developer
© JK Balikuddembe - Requirements
5-Mar-21 15
Engineering
Prioritisation
User Developer
* Determine • Prioritisation of
criticality requirements
• basis : cost, criticality, ...
© JK Balikuddembe - Requirements
5-Mar-21 16
Engineering
Integration and validation
User Developer
© JK Balikuddembe - Requirements
5-Mar-21 17
Engineering
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
© JK Balikuddembe - Requirements
5-Mar-21 18
Engineering
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
© JK Balikuddembe - Requirements
5-Mar-21 19
Engineering
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
© JK Balikuddembe - Requirements
5-Mar-21 20
Engineering
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
© JK Balikuddembe - Requirements
5-Mar-21 21
Engineering
Interview the User
• Interviewing is a common approach, but may not be
most effective
• Questionnaire
– Consider it as pre-work to a personal interview
© JK Balikuddembe - Requirements
5-Mar-21 22
Engineering
Interview Structure
• Set the interview in context to set scope and direction of
discussion
• Use business events as an anchor; work one event at a time
• Ask a question, listen to the answer, then feed back your
understanding
• Draw models and encourage user to change them
– Data flow models and work flow charts are effective
• Consider UML Activity Diagrams with data flow
• Use the user’s terminology and artifacts, both conceptual and
real
– Artifacts: papers, computers, meters, spreadsheets, machines,
instruction lists, software applications, etc.
– Avoid letting the user speak in technology/solution
• Keep sample artifacts and documents
• Thank the user for their time and tell them why it is valuable
© JK Balikuddembe - Requirements
5-Mar-21 23
Engineering
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
© JK Balikuddembe - Requirements
5-Mar-21 24
Engineering
Interviewing essentials
© JK Balikuddembe - Requirements
5-Mar-21 26
Engineering
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
© JK Balikuddembe - Requirements
5-Mar-21 27
Engineering
Planning of Interviews
• Identify sources
• prepare
* purpose, outline of points to cover
• venue
• appointments
• prepare the interviewee
* points to cover, useful documents
© JK Balikuddembe - Requirements
5-Mar-21 28
Engineering
Business Event Workshops
• Business events
– Businesses respond to events that are (typically) initiated
outside the scope of work to be done (by a user or an
adjacent system)
– A pre-planned response triggered by
• Arrival of information
• Arrival of request
• Passage of time
– The response to the event is a unit of work to be studied
• A use case
• In a business event workshop, the responsible user
describes or re-enacts the work that is done in
response to the event
– Identify data, processes, messages, subtasks,
checkpoints, etc.
– What contribution is to be made by the software
product?
© JK Balikuddembe - Requirements
5-Mar-21 29
Engineering
Business Event Use-case
Workshops scenario
Low-fidelity
Interaction
Screens
© JK Balikuddembe - Requirements
5-Mar-21 30
Engineering
Deliverables of the Business
Event Workshop
• Purpose of the business event
– Desired outcomes for the business
• Scenarios of the work (to be) done to respond to the
business event
• “What-if” scenarios about things that can go wrong
when the event happens
• The business rules that apply to that part of the work
• The part of the work to be done by the product
separated from the part that is done by people and
other systems
• The likely users of any product built for this event
• Prototypes for some of the steps
– Minimal detail
– Optional
© JK Balikuddembe - Requirements
5-Mar-21 31
Engineering
Purpose of the Business Event
• Focus on the outcome the organization hopes to
achieve whenever the event happens
– Think of outcomes, not outputs
– Example: car rental
• Outcomes: customer drives away in car of their choice, rate
selected is equitable, details are recorded, minimal customer and
clerk inconvenience, minimal cost
• Outputs: rental document, recorded data
• From organization’s view or customer’s view
– What are you trying to achieve?
– Why is this important?
• An outcome is a business objective, not a way of
achieving something
• Should be able to write in one sentence
– If this event happens, what state of affairs do you want to
exist when the work is finished responding?
© JK Balikuddembe - Requirements
5-Mar-21 32
Engineering
Requirements Analysis After
the Workshop
• Analyze each event response and answer:
– What does the product have to do to complete this
step?
– What non-functional requirements are necessary
for this step?
• Quality requirements
• Constraints
© JK Balikuddembe - Requirements
5-Mar-21 33
Engineering
Brainstorming
• Brainstorming is good for invention taking
advantage of the “group effect”
– “Invent” the need and/or the solution
– (See earlier slides on brainstorming)
© JK Balikuddembe - Requirements
5-Mar-21 34
Engineering
Rules for Brainstorming
• Diverse disciplines and backgrounds
• For this session, suspend judgment, evaluation, and criticism
– Don’t stop the creative flow
• Piggyback a new idea on an old one – use ideas to stimulate new ideas
• Write every idea down, without censoring
– “Ideas disappear faster than water evaporates unless written down” [Alex Osborne, the
founder of brainstorming]
• If you get stuck, seed the session with a word pulled randomly from a dictionary
– Word associations, using the word as a springboard
© JK Balikuddembe - Requirements
5-Mar-21 35
Engineering
After the Brainstorming
Session
• Analysts and clients evaluate the ideas
– Some worthless, but they will have served their
purpose of inspiring other, more practical, ideas
– Keep the best and (if feasible) turn them into
requirements
• Merge ideas
– Merge half-formed ideas into an invention
• Form half-formed ideas into true requirements
• Investigate ideas with additional trawling
techniques
© JK Balikuddembe - Requirements
5-Mar-21 36
Engineering
Context-Free Questions
– Process-Oriented
• User
– Who is the customer?
– Who is the user?
– Are their needs different?
– What are their backgrounds, capabilities, environments?
• What is the reason for wanting to solve this problem?
• What is the value of a successful solution?
• How do you solve the problem now?
– Can we copy that solution?
• How much time do we have?
– What is the trade-off between time and value?
– Who should be on the team(s)?
© JK Balikuddembe - Requirements
5-Mar-21 37
Engineering
Context-Free Questions
– Product-Oriented
• What problems does this system solve?
© JK Balikuddembe - Requirements
5-Mar-21 38
Engineering
Context-Free Questions
– Meta-questions
• Am I asking too many questions?
• Do my questions seem relevant?
• Are you the right person to answer these questions?
• To assure we understand each other, may I write down the answers to
these questions and give you a written copy to study and approve?
• Is there someone else who can give me useful answers?
• Is there some way I can see the environment in which the product will
be used?
• Are your answers official requirements?
• Is there anything else I should be asking you?
• Is there anything you want to ask me?
• Can I ask more questions later?
© JK Balikuddembe - Requirements
5-Mar-21 39
Engineering
Group Dynamics:
Be sensitive to them & probe
them
• I noticed you hesitated (had trouble describing, etc.). Is there something
else we should know?
• When I asked X about that, she said Y. Do you have any idea why she might
have said Y?
• I notice you don’t seem to agree with that reply. Would you tell us about
that?
• Are you comfortable with the process right now?
• Is there any reason you don’t feel you can answer freely?
• What can you tell me about the other people on this project?
• How do you feel about the other people working with us on this project?
• Is there anybody we need on this project whom we don’t have?
• Is there anybody we have on this project whom we don’t need?
© JK Balikuddembe - Requirements
5-Mar-21 40
Engineering
Plan Your Tasks
• Identify the techniques that are most appropriate
and will have the greatest impact
© JK Balikuddembe - Requirements
5-Mar-21 41
Engineering
Your Project
© JK Balikuddembe - Requirements
5-Mar-21 42
Engineering
Questioning
• Open questions
– tell me what happens when a customer calls
• leading questions
• be wary of negative responses
– exceptions?
• Subjects who try to please
© JK Balikuddembe - Requirements
5-Mar-21 43
Engineering
Listening
• Judge content and not delivery
• withhold evaluation and response
• be flexible
• work at listening
• resist distractions
• keep your mind open
• listen for ideas
© JK Balikuddembe - Requirements
5-Mar-21 44
Engineering
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
© JK Balikuddembe - Requirements
5-Mar-21 45
Engineering
Questionnaires
• Validity
- sample size, audience
• Reliability
• Questions
- open ended
- fill in the blank
- multiple choice
- rating scales
© JK Balikuddembe - Requirements
5-Mar-21 46
Engineering
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
© JK Balikuddembe - Requirements
5-Mar-21 47
Engineering
Scenarios
© JK Balikuddembe - Requirements
5-Mar-21 48
Engineering
Observation and social analysis
© JK Balikuddembe - Requirements
5-Mar-21 49
Engineering
Meetings
© JK Balikuddembe - Requirements
5-Mar-21 50
Engineering
Meetings: Planning
© JK Balikuddembe - Requirements
5-Mar-21 52
Engineering
Meetings: Planning
© JK Balikuddembe - Requirements
5-Mar-21 53
Engineering
Active Listener Guidelines
© JK Balikuddembe - Requirements
5-Mar-21 54
Engineering
Active Listener Guidelines
© JK Balikuddembe - Requirements
5-Mar-21 55
Engineering
Typical Comparison Questions
© JK Balikuddembe - Requirements
5-Mar-21 56
Engineering
Decomposition Diagrams
© JK Balikuddembe - Requirements
5-Mar-21 57
Engineering
Types of Requirements
• Functional requirements
– Describe the interactions between the system and its
environment independent from the implementation
“An operator must be able to define a new game. “
• Nonfunctional requirements
– Aspects not directly related to functional behavior.
“The response time must be less than 1 second”
• Constraints
– Imposed by the client or the environment
• “The implementation language must be Java “
– Called “Pseudo requirements” in the text book.
© JK Balikuddembe - Requirements
5-Mar-21 58
Engineering
Functional vs. Nonfunctional
Requirements
Functional Requirements Nonfunctional Requirements
• Describe user tasks that the • Describe properties of the
system needs to support system or the domain
• Phrased as actions • Phrased as constraints or
“Advertise a new league” negative assertions
“Schedule tournament” “All user inputs should be
“Notify an interest group” acknowledged within 1 second”
“A system crash should not result in
data loss”.
© JK Balikuddembe - Requirements
5-Mar-21 59
Engineering
Types of Nonfunctional Requirements
• Usability • Implementation
• Reliability • Interface
– Robustness • Operation
– Safety • Packaging
• Performance • Legal
– Response time
– Licensing (GPL, LGPL)
– Scalability
– Certification
– Throughput
– Regulation
– Availability
• Supportability
– Adaptability
– Maintainability Constraints or
Quality requirements Pseudo requirements
© JK Balikuddembe - Requirements
5-Mar-21 60
Engineering
Some Quality Requirements
Definitions
• Usability
– The ease with which actors can use a system to
perform a function
– Usability is one of the most frequently misused
terms ((“The system is easy to use”)
– Usability must be measurable, otherwise it is
marketing
• Example: Specification of the number of steps – the
measure! - to perform a internet-based purchase with
a web browser
© JK Balikuddembe - Requirements
5-Mar-21 61
Engineering
Some Quality Requirements
Definitions
• Robustness: The ability of a system to maintain
a function
– even if the user enters a wrong input
– even if there are changes in the environment
• Example: The system can tolerate temperatures up to 90 C
• Availability: The ratio of the expected uptime of a
system to the aggregate of the expected up and
down time
– Example: The system is down not more than 5
minutes per week.
© JK Balikuddembe - Requirements
5-Mar-21 62
Engineering
Nonfunctional Requirements:
Examples
• “Spectators must be able to watch a match
without prior registration and without prior
knowledge of the match.”
Usability Requirement
• “The system must support 10 parallel
tournaments”
Performance Requirement
• “The operator must be able to add new games
without modifications to the existing system.”
Supportability Requirement
© JK Balikuddembe - Requirements
5-Mar-21 63
Engineering
What should not be in the
Requirements?
• System structure, implementation technology
• Development methodology
– Parnas, How to fake the software development
process
• Development environment
• Implementation language
• Reusability
• It is desirable that none of these above are
constrained by the client.
© JK Balikuddembe - Requirements
5-Mar-21 64
Engineering
Different Types of Requirements
Elicitation
• Greenfield Engineering
– Development starts from scratch, no prior system
exists, requirements come from end users and clients
– Triggered by user needs
• Re-engineering
– Re-design and/or re-implementation of an existing
system using newer technology
– Triggered by technology enabler
• Interface Engineering
– Provision of existing services in a new environment
– Triggered by technology enabler or new market needs
© JK Balikuddembe - Requirements
5-Mar-21 65
Engineering
Prioritizing requirements
• High priority
– Addressed during analysis, design, and
implementation
– A high-priority feature must be demonstrated
• Medium priority
– Addressed during analysis and design
– Usually demonstrated in the second iteration
• Low priority
– Addressed only during analysis
– Illustrates how the system is going to be used in the
future with not yet available technology
© JK Balikuddembe - Requirements
5-Mar-21 66
Engineering
Nonfunctional Requirements
• User interface and human factors
• Documentation
• Hardware considerations
• Performance characteristics
• Error handling and extreme conditions
• System interfacing
• Quality issues
• System modifications
• Physical environment
• Security issues
• Resources and management issues
© JK Balikuddembe - Requirements
5-Mar-21 67
Engineering
Nonfunctional Requirements
User interface and human factors
– What type of user will be using the system?
– Will more than one type of user be using the system?
– What training will be required for each type of user?
– Is it important that the system is easy to learn?
– Should users be protected from making errors?
– What input/output devices are available
Documentation
– What kind of documentation is required?
– What audience is to be addressed by each
document?
© JK Balikuddembe - Requirements
5-Mar-21 68
Engineering
Nonfunctional Requirements (2)
Hardware considerations
– What hardware is the proposed system to be used on?
– What are the characteristics of the target hardware,
including memory size and auxiliary storage space?
Performance characteristics
– Are there speed, throughput, response time constraints
on the system?
– Are there size or capacity constraints on the data to be
processed by the system?
Error handling and extreme conditions
– How should the system respond to input errors?
– How should the system respond to extreme conditions?
© JK Balikuddembe - Requirements
5-Mar-21 69
Engineering
Nonfunctional Requirements (3)
System interfacing
– Is input coming from systems outside the proposed
system?
– Is output going to systems outside the proposed system?
– Are there restrictions on the format or medium that must
be used for input or output?
Quality issues
– What are the requirements for reliability?
– Must the system trap faults?
– What is the time for restarting the system after a failure?
– Is there an acceptable downtime per 24-hour period?
– Is it important that the system be portable?
© JK Balikuddembe - Requirements
5-Mar-21 70
Engineering
Nonfunctional Requirements (4)
System Modifications
– What parts of the system are likely to be modified?
– What sorts of modifications are expected?
Physical Environment
– Where will the target equipment operate?
– Is the target equipment in one or several locations?
– Will the environmental conditions be ordinary?
Security Issues
– Must access to data or the system be controlled?
– Is physical security an issue?
© JK Balikuddembe - Requirements
5-Mar-21 71
Engineering
Nonfunctional Requirements (5)
Resources and Management Issues
– How often will the system be backed up?
– Who will be responsible for the back up?
– Who is responsible for system installation?
– Who will be responsible for system maintenance?
© JK Balikuddembe - Requirements
5-Mar-21 72
Engineering
Example Functional Requirements
© JK Balikuddembe - Requirements
5-Mar-21 73
Engineering
Example Functional Requirements
• Req. 2:
– When the “renew” option is selected,
• the user is asked to enter his membership number
and password.
– After password validation,
• the list of the books borrowed by him are displayed.
– The user can renew any of the books:
• by clicking in the corresponding renew box.
© JK Balikuddembe - Requirements
5-Mar-21 74
Engineering
Req. 1:
• R.1.1:
– Input: “search” option,
– Output: user prompted to enter the key words.
• R1.2:
– Input: key words
– Output: Details of all books whose title or author name
matches any of the key words.
• Details include: Title, Author Name, Publisher name, Year of
Publication, ISBN Number, Catalog Number, Location in the
Library.
– Processing: Search the book list for the keywords
© JK Balikuddembe - Requirements
5-Mar-21 75
Engineering
Req. 2:
• R2.1:
– Input: “renew” option selected,
– Output: user prompted to enter his
membership number and password.
• R2.2:
– Input: membership number and password
– Output:
• list of the books borrowed by user are displayed.
User prompted to enter books to be renewed or
• user informed about bad password
– Processing: Password validation, search books
issued to the user from borrower list and
display.
© JK Balikuddembe - Requirements
5-Mar-21 76
Engineering
Req. 2:
• R2.3:
– Input: user choice for renewal of the books issued
to him through mouse clicks in the corresponding
renew box.
– Output: Confirmation of the books renewed
– Processing: Renew the books selected by the in the
borrower list.
© JK Balikuddembe - Requirements
5-Mar-21 77
Engineering