Problems and Solutions
To develop software is to build a machine, simply by describing it.
The people and places touched by the machine are the application domain.
Our special quest within this domain is the problem.
The machine's role in realising our quest is the solution.
To get the right machine we must describe our requirements precisely and not leave it up to programmers to read our minds.
This is the discipline of requirements capture.
It's a discipline that you can learn even if you're not a technical specialist.
You learn by studying the essential components of a good requirements specification together with the prescriptive frameworks for describing them.
Frameworks that are solidly based in sixty years of software and systems engineering practice.
The What and the How
This is Montserrat and I am a pilgrim. My quest is: redemption. My need is urgent.
So, onward, to worship at the monastery's Basilica de Santa Maria and to travel safely from the valley to the monastry in less than 15 minutes.
My quest is fulfilled with a cable car.
The requirement: rapid mountain travel.
The machine: a cable car.
Notice that my requirement is not a ride in a cable car, my core need is redemption.
So in writing requirements we reflect on the user's problem and the capabilities we need to solve it. This is the "what".
We do not concern ourselves with the solution embodied by the machine. That is the "how".
Specifying Requirements
Specifying requirements can be daunting there are often thousands of issues at play.
Attempting to reflect on everything, at once, in detail, is a recipe for madness.
The best approach is to divide and conquer, addressing our concerns with layers of reasoning.
Here's a three layer framework:
- Business requirements: what the business wants and why
- User requirements: what the users of the system must be able to do and
- Software requirements: how the system behaves, as viewed by a user.
The upper layers produce a rough sketch of the problem and each successive layer engages with increasing levels of detail to the point where our statement of requirement is sufficiently precise to make sure that the machine we build will solve our problem.
In addition to behavioural requirements we also need to consider the qualities a machine exhibits in use; its character traits (for example: reliability, trustworthiness ); these are technically termed non-behavioural requirements.
Then there's the issue of what the machine doesn't do. We need to consider risk. What could go wrong and what should we do about it?
Finally, organisations routinely forget why they stated a requirement.
Corporate memory loss can be expensive, so to jog our collective memory we introduce the concept of rationales.
Mastering Requirements Frameworks
How do you tell your story to a technical person? How do you shed light on real life? How do you make it easy for technologists to build you a truly useful machine?
Well you don't have to start with a blank page. There are plenty of published frameworks out there to help you structure your thoughts.
To illustrate let's examine a framework for a "use case".
A use case describes an interaction between a user and a system that produces some useful outcome. For example: withdrawing money from an automatic teller machine.
We construct our use case by answering a series of questions.
Who's involved?
What is to be achieved?
What conditions need to be in place before the interaction can start?
What conditions indicate successful completion?
What is the normal course of the interaction?
Are there any alternative courses of interaction?
What could go wrong?
Do any business rules apply?
Do any non behavioural requirements apply?
Are we assuming anything?
So there you have it. The use case framework shines when you need to describe heavy interaction between a user and a system. It is not suited to describing complex algorithms like the ones you find in automated stock trading. Which isn't a problem unless you're a stock broker.
So the trick is to learn the frameworks that apply to your application domain and use them to tell more compelling stories to the builders of your special machine.
Controlling Your Destiny
When your machine is built, you are the one in the driver's seat.
How do you know it will fly?
Are you confident it won't crash?
If you can't afford a failure there's only one course of action. You must learn how to write concise requirements.
Stay in control of your destiny by learning the frameworks, models and modes of expression that make up a complete, correct, unambiguous and verifiable statement of requirement.
Be in a position to specify what you want and verify that you got it ... before you take off.
This is the core mission of the requirements capture process.
If you'd like to learn more about capturing, writing and managing software requirements please join us at our requirements specification workshops.
We'll look forward to it.
