What are Requirements?
Please Sir, I know this <hand waving excitedly>. “Requirements are the things that people need, like in Harry Potter’s Room of Requirement that appears to solve a problem when you want it most.”
Good answer, a requirement is something to do with satisfying a need or fixing a problem, so should be simple? However, in IT apparently simple concepts can become invested with much more meaning, nuance, and lets be honest, sometimes unnecessary confusion and complication! That said, the processes of identifying, documenting, validating and managing Requirements run through the heart of software development and maintenance. You might also find them in similar activities in non-IT projects, process improvement, feasibility and case studies, for example. That covers almost anything that needs designing, specifying, building, creating or improving. The work will always start with a wish, a desire or a need…whether stated explicitly or not.
So why are requirements important anyway?
I hope you agree that it’s a good idea to decide what you want before you set out to achieve it. Another way to look at this is to start from the end, if the Requirements are wrong, i.e. not what the requester or Customer wants, then the solution is unlikely to be well received or acceptable.
But, sometimes what the Customer needs, or thinks they need, is not clear. Their thinking may be incomplete, muddled or contradictory. Then again, those desires may be unrealistic, or too complicated, or too costly to achieve. Enter a Business Analyst or Requirements Analyst with a handy SMART acronym to help translate these wishes into good Requirements.
S – Specific
M – Measurable
A – Achievable/Attainable
R – Realistic
T – Time-bound (when is it wanted by)
More problems with Requirements
Having thought a little about your requirements, you may have written them down or otherwise illustrated them (requirements can come in different forms, what about a story board, or a hand-drawn picture of the finished product or website?) However, there are other potential problems and conversations with your imaginary Customer – or yourself!
‘I don’t really know what I want’
‘I want it all and I want it now!’
‘Is that what I asked for, I thought it would look different’
‘It has cost too much and it’s taking too long to build.’
‘I’ve changed my mind…again.’
To summarise:
- Humans can be fickle, they can change their minds, they can be wooly-headed and irrational – that is, they can be human!
- Requirements change.
- The world changes!
In traditional projects, tools are available to help prevent these risks happening or reduce the impact (mitigation) on the health of your project, such as Prioritisation, Requirements/ Change Management, prototyping and modelling.
Luckily in the world of computers and software projects there are non-traditional ways (see Agile vs. waterfall) that requirements can be met. Software ‘code’ is malleable, it can be changed, built in small chunks and connected together, thrown-away and re-written quickly and efficiently…of course this isn’t as easy if you are half-way through building a new car model, or a battleship!
I hope you agree, Requirements are important to help turn your ideas into a reality. Enjoy the ride!
Did you found this interesting? Do you want to read more? There is a longer module available on request from the IT elementary school.
@ITelementary
(c) 2015 Antony Lawrence CBA Ltd.
[…] in this environment I first came across a notation and technique to capture business and system requirements, Use Cases, introduced by Swedish Computer Scientist Ivar Jacobson in 1992. Many other thinkers and […]