In my last post, I covered the definition of requirements – i.e. the What. We also briefly touched upon why requirements are important.
In this post, I’ll dive deeper into the Why and Who of requirements. That is:
- Why are requirements important?
- Who uses requirements?
Let’s get started, shall we?
Why Are Requirements Important?
As I mentioned in my previous post (linked above):
Requirements form the basis for any software development project, as they drive all activities that follow. As a result, it is very important to get requirements right – otherwise, the entire project can fail.
Here’s a (poorly hand-drawn!) visualization of this point…
As you can see, requirements constitute the input to every project. If requirements are bad – the world famous, super awesome GIGO effect kicks in, and the odds of project success go down big time.
Now, the next question – who exactly uses requirements…
Who Uses Requirements?
Short answer: Every software development project uses requirements. So everyone involved in a development project uses requirements too – directly or indirectly. Now, let us dive deeper into this…
Every development project uses requirements:
- Most projects use detailed, explicit requirements that are written down.
- Some projects – such as extreme agile projects – use very short (or even one line) requirements.
- Some projects may not write anything down at all – but even in such projects, there is a set of requirements that the project team members agree upon verbally.
People involved in a development project:
Everyone involved in a development project uses requirements – directly or indirectly. Here are some of the most common job roles of people who use requirements:
|Job role||How they use requirements|
|Product Managers, Product Marketing Managers||Capture, develop and document requirements|
|Business Analysts, System Analysts||Capture, develop and document requirements|
|UI, UX Designers||Consume requirements as a part of designing UI/UX|
|Architects, Developers, Engineers||Consume requirements as a part of developing the product|
|QA Testers||Consume requirements as a part of testing the product|
|Project Managers||Manage requirements|
|Executives, Customers||Read requirements and provide feedback|
|Documentation, Support Personnel||Create documentation, support material|
Okay, that is the Why and Who of requirements. In my next post, I’ll cover the different types of requirements…