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…
