My friend Christer Fröling asked me to write a piece in this blog about my experiences with requirements, something insightful, something deep, and something cool.
My pick today falls in the category of requirements, which many System projects, in particular IT systems, fail to see, despite of the obvious. I will dedicate this short session to Capability Requirements, and role of Validation as a driver for delivering them.
My name is Sam Lund, and I am a capability addict. You can check more about me at www.stellapolaris.co
Business Requirements: easier said than done
Business requirements represent a contract between the parties, the customer vs the supplier, and provide unambiguity in their expression on what is the expected outcome, and also identify who or what shall act on the requirement.
However, the serenity of this thought does not remain too long, when trouble already sneaks in. Where Business Requirements succeed in describing expectations, they give little or no credence to how it all should take form at the supplier. And very often, there is a large gap to the reality at products and systems as their developers see them.
When it all should be put into action – delivering it – there are range of circumstances which suddenly start to erode the whole delivery process. There are supporting elements, which ought to be included, but were too distant of an idea, when the planning was conducted. There are services which should have been created, and which now would be needed in the delivery, but even those seem to have been missed.
Simply put – organization lacks the Capabilities needed to successfully cover all the elements of the contract.
The hidden factor: Capability Requirements
You cannot solve Business Requirements correctly, if not analyzing all the contributing elements required to solve them. Some of these contributing elements are defined by direct needs and some of them are emerging through in-direct, supporting elements and enabling pre-requisites.
Only when combined, when you apply those elements together – you create a “Capability”. It can be one, or multiple capabilities, which are needed in order to resolve a Business Requirement. And most of the times, this is more than just the technical system. It tends to include processes, organization, documentation, training, support organization and information.
A vehicle will very quickly end being a useful transport, if it lacks gas stations for fuel, maintenance and service, reserve parts, organization, tools, manuals, guidelines…
And all of those identified contributors – will be subject of requirements too! Capability requirements. These align all the contributing factors, with specific requirements and their expected effect levels (acceptance criteria) to create the ultimate expected outcome. When all of these capability requirements are delivered – a capability is born. And to drive this delivery – you need Tasks.
As you execute and complete Tasks, requirements get fulfilled, and eventually a pattern starts to emerge of a System or Element of it, and for which, a level of performance may become verifiable.
Creating Coherence – integration in performance and time
Creating a Capability is an integration effort. Apart from verifying various systems and technical elements, the integration includes also verifying and integrating the intended operational processes (concept of operations), support processes, training requirements, competence requirements, etc. Everything which makes the Capability. And it might be, you need to setup and evaluate operations, so that even these rise to the level of the expectations.
Once every piece clears out, and integrates consistently in time and performance, you can evaluate that the joint effect of this integration – actually delivers the intended outcome, the capability and its effect. This continued integrated delivery of performance, is often called Coherence.
And it is now, you can finally start to Validate, that the solution meets the business requirement. I.e. what is the performance level of the Coherence achievable, and will this meet the acceptance criteria of the Business Requirement.
Victory in Validation
And this, my friends here reading this blog, is the ultimate difference between Verification and Validation.
It is Validation which finally confirms the coherent delivery of the performance and effect. And this validation process can actually be much more than just a final judgement towards customer delivery. It can also be a continuous process of coherence assessment, of behavioral standards of the total System (of systems), in particular when working with operational solutions.
When evolved towards that end, Validation can become much more than just an assurance function. It can assume a continuous role, and an essential part in managing operational delivery of the Capability.
To think about
how much of these Capabilities would appear to be really “new” for any IT system? The actual structure where capabilities are expressed, should be rather stabile for many types of organizations and applications. Variations are rather in the level of requirements and their target performance levels.
Having Capability Structures, expressing current state of affairs, would then streamline Business interaction, and reduce commercial and technical project risk.
To be continued…
Inspiring as always Sam! I will end with a quote I love and next time I will post the first blog about some of the rules you might want to stick to and some advice on how to write good, high quality, requirements. Don´t forgett to contact me with ANY question you might have or suggestion for topics to bring up!
“One of the most dangerous forms of human error is forgetting what one is trying to achieve.” – Paul Nitze (1907–2006)