2. The Problem(s) of Changing Requirements
Changing Requirements
• Engineers on long design and
development projects must rework
designs to keep them in step with
changes in the specification, or in the
expectations of the clients and/or
markets.
Flexible Requirements
• Technical systems are intended to be
‘flexible’, in other words they should
satisfy not only the original
requirements, but also some range of
new or additional requirements.
Problem FOR WHOM?
• “Changing Requirements” is widely
perceived by engineers of all kinds
to be a problem.
• “Changing Requirements” is also
perceived to be a problem from
the users' perspective.
3. Requirements Engineering
• There is also a perceived need
for tools and methods for
requirements engineering.
• Note that the specification of
such tools and methods is itself
an exercise in requirements
engineering. We might call this
requirements engineering
engineering.
4. Constructivist account of requirements
• A requirement is a demand
statement that can be expressed
in the form ‘We Require This’, a
statement that contains three
components.
• However, requirements
engineering usually focuses on
only one or two of the three
components.
6. Constructivist account of requirements
• First-order requirements
engineering concentrates on
the ‘This’. In other words,
attention on the (evolving)
solution, rather than on the
process or the client.
• Second-order requirements
engineering concentrates on
the ‘Require This’. In other
words, attention on the solution
and on the (evolving)
procurement process/contract,
but still not on the identity of the
client.
• Third-order requirements
engineering concentrates on
the whole ‘We Require This’.
Only now is attention explicitly
directed at the (evolving) identity
of the client. We therefore need
to explore the evolution of the
process and the evolution of the
client, if we expect to have an
adequate account of changing
requirements.
7. Identity
• Most approaches to requirements
engineering only address the
solution, and take the process
(including the procurement
process) for granted. We refer
to these approaches as first order
requirements engineering.
• Some approaches (notably
Checkland’s soft systems
methodology) address the
process as well as the solution.
We refer to these approaches as
second order requirements
engineering.
• Both first order and second
order requirements engineering
consider the identification of the
client to be merely a matter of
correctly naming all the
stakeholders. The development
of the group identity of the
requirements owner (as well as
the other participants in the
requirements engineering
process) is only properly
addressed by what we are calling
third order requirements
engineering.
8. Developmental account of requirements process
• The requirements engineering
process can be regarded as a
progression
– starting with a sense of something
lacking (e.g. from an organization or
process or system)
– via a fantasy or vision of what might
compensate for the lack
– to an engineerable specification of
an engineerable product or service.
9. Iterative Requirements Process
• But although this may be the
starting point for
requirements engineering,
much of the time is often
spent working out what is
lacking in the solution.
• The specification is itself
always incomplete or
incoherent or inadequate.
• This may be discovered when
the product or service is
being designed, or when it is
delivered.
10. Developing identity of requirements owner
(or client)
• During the requirements
formulation process, the
requirements owner is
himself transformed:
• from a ’naive’ client who
articulates an infinite
(imaginary, fantasy)
demand for a magic
solution,
• into a ‘mature’ client
who articulates a
moderated (symbolic,
formal) desire for a
realistic solution.
11. References
Source
• R.A. Veryard & J.E. Dobson, Third
Order Requirements
Engineering: Vision and Identity,
in Proceedings of REFSQ 95, Second
International Workshop on
Requirements Engineering, (Jyvaskyla,
Finland: June 12-13, 1995)
See also
• Vincent Kenny & Philip Boxer, The
Economy of Discourses: a third
order cybernetics? Human Systems
Management Volume 9 Number 4
(1990) pp 205-224.
http://www.oikos.org/discourses.htm
