Creating Good Requirements

I’ve been thinking quite a bit recently and surveyed lots of options and opinions on the best way to translate UX research into good requirements. It’s a complex topic, and there are lots of people that are sure that they advocate the best way to accomplish this. There are certainly lots of good options from scenarios, user stories, use cases, and much more. There arealso lots of different types of requirements to think about: user, functional, business, and so on.

As my company steps back and evaluates the way we do this, I also wanted to take a step back and ask: What makes a good requirement? Regardless of documentation/presentation method, surely there are characteristics that are universal. Here is my attempt to think through some of those characteristics of a good requirement. There are other lists like this out on the web, and they matched what I was thinking; but I wanted to add a distinctly UX spin on it.

Testable & Measurable

This one has a lot to do with my thinking about UX research. It we have a requirement that simply isn’t measurable in terms of how we’ve improved the project through testing, then how can we really understand empirically that we’ve done our job? Anecdotal evidence is very limited in measuring success, and ensuring that we can put our requirement through the rigor of testing with tools such as usability testing, A/B testing, UAT and so on we can ensure we are doing the right thing.

Verifiable

The language is bit awkward here, but it’s the best I could think of. By “verifiable” I mean we can point our requirement and match it with some specific business or user need. As a strong UCD proponent, ensuring that it matches with your user research is particularly important to me. It ensures you’re not paying lip-service to being “user-centered.”

Usable

This one is related to the testing one above. Obviously the only way we know something is in fact “usable” is by empirical testing (otherwise it’s only opinion). However, this is important because if we have a requirement but there are situations are challenges that make the end result unusable then it’s not adding real value.

Valuable

You’ve already heard me mention the word “valuable” in this post because I think it’s one of the most important. As a big proponent of the value-up paradigm, it’s important to ensure that whatever we’re cementing as a requirement is adding tangible value. This is hard because what one audience deems as valuable can be ignored by another, but this is why comprehensive user research is so, if you will, valuable.

Implementation Agnostic

A good requirement should not have lots of implementation details in them. You shouldn’t have something like, “The records center will be utilized for records management.” By locking yourself into a specific implementation you are first of limiting the value from your developers and designers by tying their hands, and secondly if something changes about the records center in this case you have to change the requirement itself.

Clear

One of the difficulties in a lot of IT projects is an eventual spiral into technical jargon. It is important that our requirements be stated as outcomes that are clear. It should be something that anyone should be able to understand with none or very little explanation and context. It’s much easier to write requirements that only the stakeholders understand, but as if your client requires showing them to a wider audience you’ll quickly appreciate writing clear requirements. If you or your client feels like you need to be there to explain the requirement than it’s not clear enough.

Realistic

There are all kinds of reasons why a requirement may be unreasonable for a project. Perhaps money, time, customer/consultant willingness and much more can make it unrealistic. It’s important to identify things that are potentially unrealistic as soon as possible, and this is done by soliciting feedback from everyone on the team and continually testing our options.

Concise & Complete

Those two characteristics sound like they are odds with one another, but they help to balance your requirements. If you have a requirement that doesn’t comprehensively speak to the need that needs to be addressed while maintaining appropriate brevity it will be difficult to attain shared understanding.

Hypothetical

Now by “hypothetical” I mean that it’s stated as a hypothesis free of
assumptions. When we start talking about our requirements as hypothesis it allows us to test and be more flexible when we see something needs to change. It brings us out of the world of “set-in-stone waterfall” into something that can be constantly refined. Jared Spool wrote a great article on this entitled: Replacing “Requirements Gathering” with Something That Works.

Harmonious

The worst thing is when you have requirements that seem to be at odds with other requirements. There are many reasons this may happen, and it’s the job of a good BA to ensure that this is avoided. One outcome shouldn’t be at odds with another, and if you realize it is there is an opportunity to fix that long before you start implementing.

User/Activity-Centered

Of course the last thing that is important to notice is that what you’re suggesting as requirements are in fact user/activity-centered. This means they are developed with user goals and activities in mind. It is also ensures the stakeholders are simply speaking on behalf of users but you are in fact matching it to real research (which connects to our “verifiable” characteristic above).

Conclusion

As you can see there’s a lot to think about when doing good requirements. Did I miss any? Did I misspeak about the priority of one of these characteristics? Let me know what you think.