While there are many different ways to design and build a product or solution, one thing remains the same no matter what you are building – you need to have requirements!
Two of the most popular approaches for organizing product requirements and design are Requirements Driven Development (RDD) and Feature Driven Development (FDD). Which might be best for you? Let’s take a quick look at the differences and see which makes more sense for your project.
| |
Requirements Driven Development |
Feature Driven Development |
| General Characteristics |
High-level, non-prescriptive |
Varying degrees of detail
|
| Focus Area |
Product attributes |
Product functionality |
| Perspective |
Product or solution |
End-user point of view |
| Benefits / Advantages |
May be developed without customer input;
Potentially less cost/effort to develop |
Derived from user perspective;
More likely to meet customer desired experience;
Provides more opportunity for innovation |
| Risks / Disadvantages |
Potential to build a product that does not support user objectives;
Less freedom to innovate and/or experiment with new solutions |
May require more time to develop due to customer collaboration;
|
As this matrix describes, Requirements Driven Development is focused on the attributes of the product/solution, which is generally simpler to derive, but may carry more risk. Describing product characteristics does not ensure the customer’s business objectives will be satisfied. Let’s take a look at a sample requirement snippet below:
The product shall:
- Have 4 rubber wheels.
- Be able to travel at least 15 miles per hour.
- Be able to transport both people and cargo.
Such requirements are relatively easy to develop and agree to. However, the end product being developed may vary depending on assumptions and additional information that may not be captured by the requirements alone. As you can see, it is possible to develop a variety of different end solutions that all fit this set of specifications – you could build a truck, a car, an amphibious boat (that has wheels)…the list goes on.
Alternatively, if we are to describe such requirements using a Feature-Drive approach, it would look more like this:
“As a vehicle operator, I want to be able to transport people as well as cargo on land at a speed of at least 15 mph so that I can move my workers and materials across different farms.”
Using an Feature Driven Development approach, we describe the end-user functionality instead of the system characteristics so that we can more accurately connect with what the customer is trying to accomplish. Knowing this information, we could potentially suggest different solutions that may enable the customer to achieve his/her goal; for example, perhaps this vehicle could be an autonomous vehicle that can be programmed ahead of time and operated without any human intervention.
As you may realize, you might benefit from a requirements approach in some situations, while it might make more sense to use a feature-drive approach. Depending on your organizational and business context, it is possible that you might utilize both of these techniques for different scenarios.
Project Thinking to Product Thinking Unlocking Product Agility
Watch Now
