3rd
Order
Requirements
Engineering
Richard Veryard
The Problem(s) of Changing Requirements
Changing Requirements
• Engineers on long design and
development projects must rew...
Requirements Engineering
• There is also a perceived need
for tools and methods for
requirements engineering.
• Note that ...
Constructivist account of requirements
• A requirement is a demand
statement that can be expressed
in the form ‘We Require...
Evolving Requirements
↓↓↓
Third Order
Second Order↓
First Order↓↓
Focus on evolution
of solution
Focus on evolution
of pro...
Constructivist account of requirements
• First-order requirements
engineering concentrates on
the ‘This’. In other words,
...
Identity
• Most approaches to requirements
engineering only address the
solution, and take the process
(including the proc...
Developmental account of requirements process
• The requirements engineering
process can be regarded as a
progression
– st...
Iterative Requirements Process
• But although this may be the
starting point for
requirements engineering,
much of the tim...
Developing identity of requirements owner
(or client)
• During the requirements
formulation process, the
requirements owne...
References
Source
• R.A. Veryard & J.E. Dobson, Third
Order Requirements
Engineering: Vision and Identity,
in Proceedings ...
Upcoming SlideShare
Loading in …5
×

Third Order Requirements Engineering

1,909 views

Published on

Published in: Technology, Business, Design

Third Order Requirements Engineering

  1. 1. 3rd Order Requirements Engineering Richard Veryard
  2. 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. 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. 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.  
  5. 5. Evolving Requirements ↓↓↓ Third Order Second Order↓ First Order↓↓ Focus on evolution of solution Focus on evolution of process Focus on evolution of client THISREQUIREWE
  6. 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. 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. 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. 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. 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. 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

×