Have you been asked to write requirements for a piece of work, and don’t know where to start? Or are you coming out of a project that has not quite delivered what you expected, and you want to find out how to avoid making the same mistakes again? Hopefully this information about how to write good functional requirements will help.

What makes a good requirement?

Specific, but not prescriptive

Do say exactly what needs to be included.

Don’t say exactly how it needs to be achieved.
If you include too much information about how a requirement should be met, you will be short-circuiting the skills of all the other team members. Let the designer design, and the developer develop. Being too prescriptive leads to designs that tick the boxes without adding anything creative, imaginative or innovative. Leave scope for people to solve problems in ways you hadn’t thought of.

Measurable

Do say how you will know that a requirement has been met.

Don’t use subjective terms.
A good requirement is testable, and in fact a test team should be basing their test plan on making sure that every requirement is covered.

  • Users must be able to see all their transactions for the past 30 days – good
  • Users should be able to tell what they have bought – bad
  • The application should be easy to use – bad
  • The user interface should be designed to be usable by 5 year olds without any intervention by an adult. – good

Realistic

Do include what you need to make a releasable product.

Don’t turn your requirements into a wishlist
Any requirement that starts: “If there’s time…” or “If possible” deserves to be ignored. If you need something – ask for it. If you don’t need it, leave it out. I’ve seen people get round this by adding a priority e.g. Essential, highly desirable, to each objective. If you are going to do this, you need emake sure everyone agrees on the purpose. Is it so that the developer can prioritise their work in case you need to release without all feaures? In that case, it might be better to plan for phases of development. Is it so that these features should be included if they don’t create any extra effort? I would always err on including fewer requirements and achieving them well than setting an expectation for something that might not be delivered.

Completeness

There is a lot of pressure on the person writing requirements to make sure that they are complete. This is particularly true if you are dealing with an inflexible third party company who are going to charge you for any changes. The best way to make sure that requirements are complete is to get a lot of pairs of eyes on them. Users, sales people, developers, customers, designers, marketers, support staff… they all have their own take on what the product needs.

  • Get them involved early
  • Ask them what was wrong with the last version/a comparable product
  • Find out what is causing support calls on other products
  • Find out what customers are asking for but be careful not to get too bogged down in what will please one particularly vocal customer – what will please most of the people most of the time?

There is often resistance to getting too many people involved too early on, because the chance are that you will be inundated with requests for features that will increase the scope of the work beyond what is possible. This is where the Ownership becomes very important.

Ownership of requirements

Someone has to have the final say. If you are expecting an entire committee to sign off anything longer than a page, you are likely to end up in endless iterations. Agree with the committee that Person X is the ultimate authority and if they are happy then the requirements are signed off. If you are going to invite input from a wide group of people (as you should, if you want to capture gaps early) then someone needs to take responsibility for going back to these people and saying “your request didn’t make the cut”. This could be you, or the ultimate requirements owners but it has to be done. The alternative is that everyone expects their requests to be implemented, and it is easier to deal with their disappointment at the start than when you are trying to get everyone excited about a finished product.

Walk it through

Once you have a draft of what you think the requirements are, walk through some typical use. Some people use scenarios or use cases for this – where you map out all the players involved in performing a particular action. Pick a few typical tasks that a typical user might want to perform, and draw them out on a whiteboard. As you move through the process, ask yourself:

  • What am I assuming?
  • Can this task be achieved with these requirements?
  • Will it be obvious to someone reading these requirements that this task needs to be supported?

Do that for a few different tasks and you’ll get a feel for whether or not you’ve included enough information. Use pictures and keep talking.

Finally, if you can refer to diagrams, mock-up, prototypes then do so. Getting a designer involved early will pay off in the long run. The creation of requirements should be a collaborative process between designer, developer and requirement owner. Don’t expect to write the requirements and then throw them over the fence to someone else to produce. Expect it to be an ongoing conversation, and if you can refer to pictures and diagrams during the conversation then even better.

Getting requirements gathered and agreed is not an easy process, but if you can listen to what people are asking for and work with a strong requirements owner, then you’re halfway there. The rest is down to your ability to describe the needs in precise, unambiguous and specific language.

Bigger is not necessarily better - keep it simple! Credit: Florian

Bigger is not necessarily better - keep it simple! Credit: Florian