requirements quality depends on understandability

For Requirements Quality, understandability is critical.

I’ve been reading a book called Hackers and Painters, by Paul Graham. It’s not a new book by any means, but it has many principles that apply to life beyond software. One of the principles that Graham mentions is that one of the key elements of success is empathy. When we think of empathy, we tend to think that it is one level higher than sympathy in terms of actually feeling someone’s sorrows. But in terms of software, I don’t think we can get too sad about a Do Loop. Graham discusses how we, as software folks (he refers to many of us as Hackers), need to have empathy to truly understand our end users and stakeholders, and that with empathy, we can develop great software. The simple principle of really standing in someone else’s shoes and deeply understanding everything they think, feel and do, whether its related to software or not, can be applied to success in just about every field. And I agree. But getting back to software, I started thinking about requirements quality.

We recently had a webinar with Robin Goldsmith where he discussed in depth where we can get requirements and how to capture them. Robin says that if you can capture them – especially those that are discussed in water cooler conversations – you are one step ahead of the game and going in the right direction. But beyond capturing them, I think that requirements have to have certain properties to be considered “good” or acceptable. Therefore, requirements quality should be based on several criteria. The most important criteria in my opinion (tying back to empathy) is understandability – that requirements are truly understood. So what does that mean? Thinking from the other person’s point of view.

Requirements Quality Depends, Foremost, on Being Understandable to All.

Does the requirement contain specialized language that could be unfamiliar to stakeholders? Can each phrase or sentence be understood by a:

  • Developer
  • Executive
  • Accountant (domain of the software)
  • Customer service representative
  • Developer
  • or Tester?

By applying a simple test of understandability from each of the stakeholder viewpoints, we can utilize empathy to drive requirements quality. And with that, we’re really on our way to building software that meets expectations.