Iken's guide to writing a requirements specification

Once you’ve decided you need a new system for your team you’ve taken the first step. The next step is to tie down exactly what you need into a software specification.

Software specifications don’t need to be complex; they’re there to communicate your requirements to potential suppliers so they understand the problems that need to be solved and how you expect the software to work in order to solve them.

Being really clear at an early stage about exactly what you need will help you to get a new system with as little cost growth as possible, because you’ll be able to minimise potential surprises and keep a cap on your budget!

There are plenty of in-depth articles about developing a software requirements specification but here are our tips for developing your specification, with some practical insights we’ve gleaned along the way!

Business objectives 

Business objectives are the place to start when you’re defining your requirements. Your software specification should list what you need based on improving your team’s performance, so start big and work your way to the finer details by asking:

  • What do you need to achieve as a team?
  • How is your team’s performance measured?
  • How can you improve performance against your targets?
  • What needs to change in order to do this?
  • How will new software help you to improve/ support changes?
  • What specific functionality will support improvements? 

It’s also worth keeping in mind what made you decide you need new software in the first place?


Once you’ve thought about your team’s objectives and how new software could improve performance you’ll have a better idea of the kind of functionality you need and how new software will help you to measure and demonstrate an improvement. When thinking about functionality try to break down problems into component parts and set a clear boundary on the problem and its possible solutions.

For each new requirement ask yourself:

  • Why do you need it (relating back to objectives and how you’re measured)?
  • How will it work?
  • What is really required i.e. what is essential and what is ‘nice to have’?
  • Does it need to integrate with other software or is it dependent on other software e.g. use of Microsoft Office or Adobe Acrobat?

It’s worth remembering that suppliers may not be able to cater for every requirement. Some of the things you need might not be within the scope of what you’re looking for in terms of a case management system, for example if you have a visually impaired team member you may need to get another software solution to help them see things more clearly on their screen, rather than expecting a case management system to include that too!

It’s also worth asking different members of your team what functionality they need so you don’t miss any important features out. For example fee earners might expect different functionality to what support staff or practice managers will need to use.

Training and change management

Training and change management aren’t strictly speaking software specifications but when you’re putting together your requirements they are an important consideration that’s often overlooked.

Knowing how your team will be trained and how your project will run once you’ve chosen a supplier will give you a better idea of timelines, help you to plan engagement and uptake by your team once the system’s in place and give you a better indication of the overall cost of the project.

It’s also worth finding out what support is provided, getting references and speaking to existing clients and finding out about upgrades and what could cause an increase in your costs once you’ve chosen a solution.

Pratical tips

Finally, here are a few last factors to think about:

  • If you’ve created your specification as a document suppliers need to fill out, make sure they can easily provide their responses. Word limits may make a document easier to review but it can also mean you aren’t given a representative answer. Applications like Excel have built in word limits for each cell that can restrict a supplier’s ability to tell you what they do.
  • Make sure you include the number of user licences you need in your specification.
  • If at all possible make sure you have access to benchmarking data so you can compare performance before and after your new system is implemented. This will make it much easier to demonstrate a return on investment!
  • Software providers don’t necessarily provide the IT infrastructures their software will be hosted on. You could rule out good providers straight away by including requirements such as cloud hosting which aren’t to do with the features you need, but how the software is deployed.
  • Software contracts are different to other contracts because you don’t own the software once you’ve purchased a licence, you only own the right to use it! For this reason most software providers expect you to agree with their terms and conditions and may only agree to minimal negotiations of their contract

Software specifications are ultimately your opportunity to tell a supplier what you need, so being clear on exactly what problems you’re trying to fix and how you expect any new software to help you fix them should lead you to the best supplier for your team!

Post a Comment

Add your comment