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 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…
Like This Post? Get More by Email
3) Do not read this blog one sentence per day during your lunch break, while eating a