Tips for Turning “Fluff” Requirements into Real Requirements

Share This Post

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.

More To Explore

Email in toolbar

Getting More out of Transactional Emails

Are you taking advantage of all of the opportunities to promote your brand? Emails are great way to interact with your customers, and both marketing and transactional emails can be

Visuals in Requirements Mapping

In Praise of Requirements Mapping

Learn how to tie software requirements together with visual models and other artifacts created during the analysis process.