Tips for Turning “Fluff” Requirements into Real Requirements

Lately I have been getting a lot of “fluff” requirements from my stakeholders… The system must be flexible.  The system must allow for multivariate (A/B) testing.   The system must be more user-friendly.   The features should be re-useable.  

These all sound great in a power point presentation, but hand them to a developer, and they can be interpreted in an infinite number of ways, and you will have no idea what you are getting.   Hand them to a QA person, and they will tell you that these requirements are not testable.  Now, being the detailed and analytical minds that we are, an Business Analyst or Product Manager would never leave a statement like “it must be flexible” at that.   But how do you flush out the details? 

Some tips for taking those generic statements and turning them into something that can be delivered:  

1. Make sure everyone understands the Business Objectives.  Will this requirement increase sales?   Will it reduce abandonment?   What business benefit does it provide?  
2. Define the need with a problem question.  What problem are we trying to solve with this requirement?   Why does the system need to flexible?   
3. Discuss Guiding Principles. Perhaps these “fluff” requirements aren’t actually requirements at all, but actually guiding principles: common themes to be considered in creating a product.   By documenting them as such, you can assure the stakeholder that the principles are not lost in the myriad of detailed requirements, and you can also refer back to them throughout the project to ensure that they are driving the requirements being defined.      
4. Use models to articulate the requirements.  Models help people to organize their thoughts and grasp the interactions with a system.   They help to break problems down into consumable chunks and define requirements with greater detail.  You can also refer to our blogs on Requirements Object Model (ROM) for more detail on how to use models.    

Remember, the end goal is not to just to document the requirements, but to effectively implement them.