What should I include in my requirements specification?

By Allan Watton on

what to include in your requirements specificationAmbiguity in service/solution requirements specification is the single biggest cause of disputes in complex strategic supplier relationships. Our ‘Optimise’ service/solution requirements process assures clarity in aligning your specific requirements to your business outcomes. They will be free of ambiguity and can be contractually relied upon. 

Your requirements documentation should clearly communicate your system/service requirements (functional, technical, process related etc) as well as your business objectives, outcomes, and the overall expectations you have from the supplier relationship.  

In articulating your desired outcomes and expectations you are explaining what it is that your organisation will be able to achieve, once you have implemented the service/solution and it is running successfully, that it couldn’t achieve prior to the successful implementation. Articulate this in terms of timeframes, a spectrum of percentage improvements expected across each service/solution area and so forth. Quantify these objectives as best you can as it helps prospective suppliers understand the degree to which you have carefully considered your expectations and how you will measure them. 

It is also helpful for prospective suppliers to get visibility of appropriate parts of your business case, visibility of the end-to-end anticipated procurement process, positive consequences of the solution being fit for its intended purpose and the negative consequences if the service/solution is found wanting. 

Remember the Why of your requirements, not just What you require

Where organisations go to market for solutions/services/projects, they often have very detailed service and/or functional specifications and expectations of what they perceive they need to have delivered in order to achieve their objectives and desired business outcomes. However, misunderstandings between client and supplier can still arise due to a lack of clarity and context around why the requirement was expected. It is vital to explain to potential suppliers the why you see yourselves sourcing the system solution or outsourcing the service as well as presenting the what 

Summary of Requirements Specification Contents

In summary, the holistic approach to documenting your requirements is to assure your prospective suppliers are appropriately informed and can contextualise their responses appropriately, the key aspects to include are: 

    1. An overview of how your organisation/department operates and your strategy/plans for the future and over what time scale 
    2. The business objectives and outcomes your organisation wants to achieve, (as fully quantified as possible) 
    3. Why you think you need to implement the solution/service being procured and how successful delivery will help you achieve those objectives/outcomes 
    4. Management reporting. It is critical to take the view of imagining the solution has been implemented and is now providing you with the management insights to help you drive your team and your organisation to a better place. What does that reporting look like? What specific information is it providing you with (ideally, including a rough schematic layout)
    5. Functional specifications 
    6. Example ‘Use Cases’ (business process operational flows) 
    7. The pro’s and con’s of delivering this solution/service in-house (or via the incumbent supplier) versus sourcing a new solution/service provider, therefore, what you expect from the supplier  
    8. An outline of the end-to-end procurement process so that prospective suppliers fully understand the approach you are taking and why 
    9. The prospective supplier selection process and what evidence the supplier can provide you with that will improve their chances of winning the bid 
    10. How you will manage the performance of the supplier 
    11. The negative impact on the organisation of the solution/service procured if it is not fit for purpose. 

Getting to the detail for your Requirements Specification

Gathering and agreeing service/solution requirements functional specifications and outcomes will involve contributions from multiple stakeholders across your organisation so a thorough elicitation process needs to be undertaken and requirements need to be documented consistently.  

Testing and Refining 

Ideally you should test your requirements specification with the supplier market to see if they are realistic and achievable. You can do this through an Early Market Engagement exercise and use the feedback from suppliers to refine (and if necessary rework) your requirements prior to starting the formal procurement process. See our Early Market Engagement Guidance Document and Request For Information template for further information.