Definition Concepts

+44 (0)207 993 2287
Ideas to shape how you define a programme and what it must deliver

Definition, an introduction

What do we mean by “Definition”? We mean the information that delineate the envelopes within which the things we are producing should sit. People and organisations involved in the work should be clear where the final, combined, outputs of their efforts is intended to “land”. This should shape their own efforts.

Emergent and Evolving Definition

Do not mix this idea up with “full up front specification”, they are not the same thing. Some aspects of definition may be clear up front, and just need to be managed, others will emerge or evolve over time. There is a nuance around emergent definition that is often missed. Even though the “what is needed” may already be reflected in the “product”, there is a need to capture and manage the consensus that has emerged. Without this parties will have differing, and fluid, opinions on what is “essential” and what is just “how it happens to be”. These differences will lead to trouble later on.

Facets

Definition is a many faceted thing, some facets will be domain specific. However, there are some common bases to be covered:

  • What must the end “product” allow its “owners” to achieve?
  • What is the general “form” of the solution?
  • What are the aspirations for both the perceived and the concrete quality of the solution?
  • What are the “requirements” applicable to any form of solution, ones that would also apply to a replacement?

Outcome Specification

We refer to the practice of crystallising and managing the Definition as Outcome Specification. It is a discipline and activity that must operate for the full duration of the work. It is not a “one time” activity, it is not about producing a spec and putting it on the shelf. It is a continuous process to maintain a shared and accessible representation of the Definition. Further explanation of this idea can be found in Outcome Specification and within the associated notes on

Robust Requirements

A full spectrum requirements engineering practice must cover many bases. This paper, Essential Requirements Engineering, outlines a model for the concerns such a fully rounded practice must address. It identifies twelve key features of an effective requirements approach. It also discusses requirements in an “Agile” context and how, contrary to what may be said, there is often as much need for Requirements Engineering in an “Agile” world as any other, all be it operating on a different timeline.