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.
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.”
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.
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.
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.
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.
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.
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.
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.
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).
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.
This is a great list, with things in it that I can hardly argue with. Yet somehow it feels a little contrived to me.
Today’s development tools have gotten to the point that in many cases, we almost don’t need detailed requirements anymore. I feel like a great requirement is a great ongoing conversation. I find that as I move through the building process with my clients, the requirements change. In most cases that means we end up with something better (I hope!) than they imagined in the first place.
Be sure you’re serving your customer not just yourselves. If any of what you suggest above gets in the way of your customer feeling like you get what they want, then by all means be flexible for them and mix and match methods so that *they* are happy.
Larger and more complex projects still need requirements on some level, and I’m not poo-poohing that. Most things with SharePoint, at least, can be broken down to reasonable piece-parts that allow for those good conversations.
And hopefully a better result.
Hey Mark: Thanks for reading and commenting. I do agree that requirements are a conversation, and I meant to deal with that in my “hypothetical” characteristic. I am growing on the idea of stating requirements as hypothesis that can be tested, refined, and iterated upon.
But I still wanted to think about a rubric beyond just being stated as a hypothesis. As I’ve read scores and scores of requirements documents (as I’m sure you have as well), there are some base-level issues I see in all of them. There are still clients that want at least high level scenarios/requirements before implementation begins (which is possible and wise as long as it’s understood that it will be refined), and there are still some things that can be improved in the language of our requirements. So, I guess I was going for a baseline to think of when putting them together. Even my characteristic of “complete” doesn’t mean “finished” per se but that it will eventually address all the needs.
As I mentioned on Twitter, I didn’t mean for my comments above to sound negative, but they probably did.
Understanding requirements so that they are measurable is, I think, one of the hardest things. “The system must perform well” is the kind of thing that drives everyone batty. Getting the SLA conversation going as part of the up front requirements gathering saves endless hassle down the road. As with everything else, it should be adjustable over time, but understanding the SLAs can have a HUGE impact on the investment in the overall architecture.
Requirements gathering always reminds me of the project management idea that solving a problem as soon as possible is always the best thing to do. Problems just expand over time, so squashing them early and often is critical. The same can be said of understanding requirements. Specificity up front avoids problems later, as long as everyone understands that it’s totally fine for requirements to change as long as the conversation is open and honest along the way.