Requirements engineering challenges
Ian Sommerville
http://www.youtube.com/watch?v=bK-y0CaGkhU

Requirements engineering challenges, 2013

Slide 1
Fundamental reasons why
establishing requirements for
complex systems will always be a
difficult technical and organisational
problem
Requirements engineering challenges, 2013

Slide 2
• Changing requirements
• Differing perspectives
• Lack of standardization

• People and politics

Requirements engineering challenges, 2013

Slide 3
Requirements change
• System requirements reflect the world outside
of the system.
• As this is constantly changing then the
requirements will inevitably also change
• It is often difficult to understand the
implications of changes for the requirements
as a whole
Requirements engineering challenges, 2013

Slide 4
Types of change
• Technology changes
– New technologies may have to be
incorporated into the system

• Organisational changes
– The business structure and organization
may change
Requirements engineering challenges, 2013

Slide 5
Environmental changes
• Market changes
– The market for a system may change
because of other systems introduced by
competitors or changed customer
expectations

• Economic changes
– The business may do better/worse than
Requirements engineering challenges, 2013

Slide 6
Political and legal changes
• External events lead to a change in
government policies or regulations
• In critical systems – these may lead to
requirements change

Requirements engineering challenges, 2013

Slide 7
Stakeholder perspectives
Technical perspective
Objects
Functions
Roles ...

Social perspective

Certification
perspective

User perspective
Interactions
Usability
Requirements engineering challenges, 2013

The problem and
the required system

Customer
perspective

Management perspective
Slide 8
Requirements conflicts
• Different perspectives are not consistent and
different stakeholders will want different
things from a system
• It is inevitable that some requirements will be
conflicting so that it is impossible to satisfy all
stakeholder requirements without
compromise
Requirements engineering challenges, 2013

Slide 9
Key stakeholders are busy
• Developing detailed requirements for
future systems often cannot be given a
high priority by the senior people who
will be affected by these requirements.

Requirements engineering challenges, 2013

Slide 10
• It is difficult to arrange meetings and
stakeholders do not have time to think
deeply about the system
• They therefore express their
requirements as vague, high-level
descriptions, which have to be
interpreted by engineers
Requirements engineering challenges, 2013

Slide 11
How good are the
requirements?
• There are no objective ways to
compare alternative sets of
requirements proposals to
decide which are ‘better’

Requirements engineering challenges, 2013

Slide 12
• The impact of a system on a business is
very hard to understand in advance so
therefore we cannot tell which might be
the ‘best’ system for any particular
business

Requirements engineering challenges, 2013

Slide 13
Quality improvement
• A common approach to quality improvement
is to develop an effective process then
standardize that process
• This means that all development then uses a
proven approach
• But this is very difficult for requirements
engineering
Requirements engineering challenges, 2013

Slide 14
Process and product variability
• The level of detail required in a requirements
specification differs greatly depending on the
type of product that is being developed
• Specifications for different types of system
may be expressed in completely different
ways
Requirements engineering challenges, 2013

Slide 15
• A railway signalling system is a very
detailed specification that can be
validated by authorities outside of the
organisation procuring the software
• A computer game specification is a
storyboard with pictures and examples
Requirements engineering challenges, 2013

Slide 16
Process variability
• Different companies use completely
different processes involving different
types of people to derive these
specifications
• Scope for process standardisation and
support is therefore limited
Requirements engineering challenges, 2013

Slide 17
Politics and people
• Many system requirements are
influenced by the politics in an
organisation.
• Decisions on requirements are not
made on a rational basis but are made
because of the personal goals of
stakeholders
Requirements engineering challenges, 2013

Slide 18
• New systems are often introduced to give
central management in an organization more
control and to ensure that all parts of the
organization work in the same way
• But this may be resisted by stakeholders who
use existing systems that are better suited to
their ways of working
Requirements engineering challenges, 2013

Slide 19
• Requirements engineers may not
understand the politics and, even when
they do, they may not be able to
challenge the ‘political’ requirements

Requirements engineering challenges, 2013

Slide 20
• 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
Requirements engineering challenges, 2013

Slide 21
Summary
• Requirements engineering is an inherently
difficult process
• Issues that contribute to this difficulty are
– Changing requirements

– Differing views of system stakeholders
– Product and process variablity
– The political nature of system requirements
Requirements engineering challenges, 2013

Slide 22

Requirements engineering challenges

  • 1.
    Requirements engineering challenges IanSommerville http://www.youtube.com/watch?v=bK-y0CaGkhU Requirements engineering challenges, 2013 Slide 1
  • 2.
    Fundamental reasons why establishingrequirements for complex systems will always be a difficult technical and organisational problem Requirements engineering challenges, 2013 Slide 2
  • 3.
    • Changing requirements •Differing perspectives • Lack of standardization • People and politics Requirements engineering challenges, 2013 Slide 3
  • 4.
    Requirements change • Systemrequirements reflect the world outside of the system. • As this is constantly changing then the requirements will inevitably also change • It is often difficult to understand the implications of changes for the requirements as a whole Requirements engineering challenges, 2013 Slide 4
  • 5.
    Types of change •Technology changes – New technologies may have to be incorporated into the system • Organisational changes – The business structure and organization may change Requirements engineering challenges, 2013 Slide 5
  • 6.
    Environmental changes • Marketchanges – The market for a system may change because of other systems introduced by competitors or changed customer expectations • Economic changes – The business may do better/worse than Requirements engineering challenges, 2013 Slide 6
  • 7.
    Political and legalchanges • External events lead to a change in government policies or regulations • In critical systems – these may lead to requirements change Requirements engineering challenges, 2013 Slide 7
  • 8.
    Stakeholder perspectives Technical perspective Objects Functions Roles... Social perspective Certification perspective User perspective Interactions Usability Requirements engineering challenges, 2013 The problem and the required system Customer perspective Management perspective Slide 8
  • 9.
    Requirements conflicts • Differentperspectives are not consistent and different stakeholders will want different things from a system • It is inevitable that some requirements will be conflicting so that it is impossible to satisfy all stakeholder requirements without compromise Requirements engineering challenges, 2013 Slide 9
  • 10.
    Key stakeholders arebusy • Developing detailed requirements for future systems often cannot be given a high priority by the senior people who will be affected by these requirements. Requirements engineering challenges, 2013 Slide 10
  • 11.
    • It isdifficult to arrange meetings and stakeholders do not have time to think deeply about the system • They therefore express their requirements as vague, high-level descriptions, which have to be interpreted by engineers Requirements engineering challenges, 2013 Slide 11
  • 12.
    How good arethe requirements? • There are no objective ways to compare alternative sets of requirements proposals to decide which are ‘better’ Requirements engineering challenges, 2013 Slide 12
  • 13.
    • The impactof a system on a business is very hard to understand in advance so therefore we cannot tell which might be the ‘best’ system for any particular business Requirements engineering challenges, 2013 Slide 13
  • 14.
    Quality improvement • Acommon approach to quality improvement is to develop an effective process then standardize that process • This means that all development then uses a proven approach • But this is very difficult for requirements engineering Requirements engineering challenges, 2013 Slide 14
  • 15.
    Process and productvariability • The level of detail required in a requirements specification differs greatly depending on the type of product that is being developed • Specifications for different types of system may be expressed in completely different ways Requirements engineering challenges, 2013 Slide 15
  • 16.
    • A railwaysignalling system is a very detailed specification that can be validated by authorities outside of the organisation procuring the software • A computer game specification is a storyboard with pictures and examples Requirements engineering challenges, 2013 Slide 16
  • 17.
    Process variability • Differentcompanies use completely different processes involving different types of people to derive these specifications • Scope for process standardisation and support is therefore limited Requirements engineering challenges, 2013 Slide 17
  • 18.
    Politics and people •Many system requirements are influenced by the politics in an organisation. • Decisions on requirements are not made on a rational basis but are made because of the personal goals of stakeholders Requirements engineering challenges, 2013 Slide 18
  • 19.
    • New systemsare often introduced to give central management in an organization more control and to ensure that all parts of the organization work in the same way • But this may be resisted by stakeholders who use existing systems that are better suited to their ways of working Requirements engineering challenges, 2013 Slide 19
  • 20.
    • Requirements engineersmay not understand the politics and, even when they do, they may not be able to challenge the ‘political’ requirements Requirements engineering challenges, 2013 Slide 20
  • 21.
    • People providingrequirements 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 Requirements engineering challenges, 2013 Slide 21
  • 22.
    Summary • Requirements engineeringis an inherently difficult process • Issues that contribute to this difficulty are – Changing requirements – Differing views of system stakeholders – Product and process variablity – The political nature of system requirements Requirements engineering challenges, 2013 Slide 22