We reform how you...
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.
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.
Definition is a many faceted thing, some facets will be domain specific. However, there are some common bases to be covered:
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
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.