Chapter 8: The Challenge of Requirements Elicitation

1
Chapter 8The Challenge of Requirements
Elicitation
2
Objectives

• To understand the barriers to requirements
  elicitation.

3
Why is requirements engineering difficult?

• Businesses operate in a rapidly changing
  environment so their requirements for system
  support are constantly changing.
• Multiple stakeholders with different goals and
  priorities are involved in the requirements
  engineering process.
• System stakeholders do not have clear ideas about
  the system support that they need.
• Requirements are often influenced by political
  and organizational factors that stakeholders will
  not admit to publicly.

4
RE process inputs and outputs
5
Requirements change

• System requirements reflect the world outside of
  the system. As this is constantly changing then
  the requirements will inevitably also change
• Technology changes
• Organizational changes
• Market changes
• Economic changes
• Political and legal changes
• It is often difficult to understand the
  implications of changes for the requirements as a
  whole

6
Stakeholder uncertainty

• Key stakeholders have other jobs to do!
• Developing detailed requirements for future
  systems often cannot be given a high priority by
  the senior people who will be affected by these
  requirements.
• They therefore are unable to express their
  requirements except as vague, high-level
  descriptions
• There are no objective ways to compare
  alternative sets of requirements
• The impact of a system on a business is very hard
  to understand so therefore we cannot tell which
  might be the best system for any particular
  business

7
Process variability

• The level of detail required in a requirements
  specification differs greatly depending on the
  type of product that is being developed
• A railway signaling system is a very detailed
  specification that can be validated by
  authorities outside of the organization procuring
  the software
• A computer game specification is a storyboard
  with pictures and examples
• They use completely different processes involving
  different types of people to derive these
  specifications
• Scope for process standardization and support is
  therefore limited

8
Politics and people

• Many system requirements are influenced by the
  politics in an organization. Decisions on
  requirements are not made on a rational basis but
  are made because of the personal goals of
  stakeholders
• Requirements engineers may not understand the
  politics and, even when they do, they may not be
  able to challenge the political requirements
• People providing requirements for a system may
  not be convinced that the system is necessary or
  may feel that other systems should have a higher
  priority. They may actively or passively refuse
  to cooperate in the requirements engineering
  process

9
Barriers to Requirements Elicitation

• The "Yes, But" Syndrome
• The "Undiscovered Ruins" Syndrome
• The "User and the Developer" Syndrome

10
The "Yes, But" Syndrome

• For whatever reason, we always see two immediate,
  distinct, and separate reactions when the users
  see the system implementation for the first time.
• "Wow, this is so cool we can really use this,
  what a neat job" and so on.
• "Yes, but, hmmmmm, now that I see it, what about
  this ... ? Wouldn't it be nice if . . . ?
  Whatever happened to . . . ?

11
The "Yes, But" Syndrome (Contd)

• The "Yes, But" syndrome is human nature and is an
  integral part of application development.
• We should plan for it.
• We can significantly reduce this syndrome by
  applying techniques that get the "Buts" out
  early.
• In so doing, we elicit the "Yes, But" response
  early, and we then can begin to invest the
  majority of our development efforts in software
  that has already passed the "Yes, But" test.

12
The "Undiscovered Ruins" Syndrome

• In many ways, the search for requirements is like
  a search for undiscovered ruins.
• The more you find, the more you know remain.
• You never really feel as though you have found
  them all, and perhaps you never will.
• Indeed, software development teams everywhere
  continually struggle to determine when they are
  done with requirements elicitation, that is, when
  have they found all the requirements that are
  material or when have they found at least enough?

13
The "User and the Developer" Syndrome

• Communication gap between the user and the
  developer.
• Users and developers are typically from different
  worlds, may even speak different languages, and
  have different backgrounds, motivations, and
  objectives.

14
The "User and the Developer" Syndrome (Contd)

• Reasons for this problem and some suggested
  solutions.

15
Elicitation Techniques

• Traditional techniques
• Reading existing documents
• Analyzing hard data
• Interviews
• Surveys / Questionnaires
• Meetings

16
Elicitation Techniques (cont.)

• Collaborative techniques
• Group techniques
• Focus Groups
• Brainstorming
• Joint/Rapid Application Development workshops
• Prototyping
• Participatory Design
• Cognitive techniques (Knowledge Elicitation
  Techniques)
• Task analysis
• Protocol analysis
• Knowledge Acquisition Techniques

17
Elicitation Techniques (cont.)

• Contextual approaches
• Ethnographic techniques
• Discourse Analysis
• Conversation Analysis
• Speech Act Analysis
• Sociotechnical Methods
• Soft Systems Analysis

18
Background Reading

• Sources of information
• company reports, organization charts, policy
  manuals, job descriptions, reports, documentation
  of existing systems, etc.
• Advantages
• Helps the analyst to get an understanding of the
  organization before meeting the people who work
  there.
• Helps to prepare for other types of fact finding
• e.g. by being aware of the business objectives of
  the organization.
• may tell you the detailed requirements for the
  current system.
• Disadvantages
• written documents often do not match up to
  reality.
• Can be long-winded with much irrelevant detail
• Appropriate for
• Whenever you are unfamiliar with the organization
  being investigated.

19
Key Points

• Requirements elicitation is complicated by three
  endemic syndromes.
• The "Yes, But" syndrome stems from human nature
  and the users' inability to experience the
  software as they might a physical device.
• Searching for requirements is like searching for
  "Undiscovered Ruins" the more you find, the more
  you know remain.
• The "User and the Developer" syndrome reflects
  the profound differences between these two,
  making communication difficult.