When working in growing companies, you’ll start to notice that the amount of requirements grows as well. Often these requirements are fuzzy and it is unclear who wrote them in the first place. Before you know it your product has all kinds complexity from requirements that weren’t necessary in the first place. How to fix this?
Question every requirement Link to heading
When discussing existing or incoming requirements, decide first if the requirement makes sense at all. Questions you can ask to determine this include:
- Does it align with common sense?
- Does it add user value to your product or service?
- Does it conflict with other requirements?
If the answer to any of these questions is no, then ignore or refine the requirement.
Every requirement needs a name Link to heading
A big problem with requirements is that they start to live their own life in an organization. After several years it is no longer clear where the requirement came from. To prevent this, put the name of a person behind every requirement. Not a department, a team or a role, but a specific person. When a requirement is challenged, you should go to this person and have an in-depth discussion with them. This person is responsible and accountable for the existence of the requirement, including it’s end-of-life. When this person leaves the organization, their requirements should be handed over to other persons.
Minimize the amount of non-functional requirements Link to heading
Over time, the amount of requirements that are non-functional (not targeting end-users of the product or service) grows. These often cover topics like security, standards, design systems, system architecture, and vendor management. While these can be great enablers, they can also reduce a team’s independence and ability to move fast. A better way would be to treat these as recommendations rather than requirements. If a team sees another tool or way-of-working that fits better with their culture and product, they should be allowed to use it.