Selecting an Appropriate Level of Product Requirements Definition — My Teams Say, “We Don’t Need Requirements, Just Your Money!”

Introduction

For 20 million years (approximately), one of the age-old discussions in product, IT and software development is whether a team needs clear requirements to build a great product.

Occasionally, engineering team members can persuade you (the leader) that requirements are no longer necessary in today’s world (aka “Agile,” “Lean,” “Concurrent,” “Value-driven,” “XYZ-style.”)

However, let us take a step back and think this through from a risk perspective. Read the questions below and use your answers to derive simple guidelines for the level of requirements definition your teams should have.

Assume that the requirements of a project represent a target, and that the target represents what your customers want to buy.

Questions

1. Which target (A-D above) represents your current situation regarding how teams operate now on requirements definition?

Targets are usually very difficult to define perfectly. Don’t try to define target A when target B or C will suffice and can be refined later when the team knows more.

2. What requirements are known?

The ultimate product is one that solves your customer’s known problems and meets needs they didn’t know they had. A customer may never be able to define the requirements, but they will be able to tell you specific problems that they want your system to solve. That means you should at least define target C.

3. Do your customers have no idea what they want?

If your teams have the skills to elicit requirements, then propose a series of (paid) events where team members work with customers to scrape the surface of their needs. The result will be better than target D, but not as good as target A (which is probably unachievable anyway).

There will be occasions when Target D is all you have. Staying with this level of definition for an extended period of time is high-risk and can consume a lot of resources.

4. Is a project team having difficulty starting?

There is a chance that the team does not know how to elicit and write requirements and that is why they don’t. At this point you have no target, but you are spending money. This is fixable and they can learn these skills.

Requirements elicitation is the practice of asking specific questions about the work a customer is trying to accomplish and then organizing that information into a target. Questions can be supplemented by creating mockups, prototypes and analysis of competing systems to refine the target. The target will always have some blurred areas but not 100%.

Motivation to Define a Target

Simple requirements practices can be used to:

• Keep ahead of the competition (because you know the target).
• De-scope the project so that something can be delivered early (rather than starting many features and completing few).
• Clarify what additional requirements can be the source of new revenue.
• Understand and set priorities before you run out of money.
• Keep the team on the same page with a single definition of the target (even if it changes every week).
• Manage expectations with internal and external stakeholders to minimize thrashing.
• Minimize the risk of testers guessing what to test.
• Minimize the risk of a huge requirements surprise just before delivery.

If you have questions or comments about this article, or would like to discuss your requirements challenges, please contact us for a complimentary 45-minute chat or just send an email.

[Forward this email to your boss! Subject: Here’s a cool tip for you] Quick Link