Writing Requirements – What vs. How
This is my site Written by Alora on September 15, 2009 – 5:25 pm

It’s been a long time since I’ve written much about my long-standing discipline. As I’ve been focusing more and more of my energies on entrepreneurial endeavors, the details of project management have not been forefront on my mind. That recently changed, however, thanks to a client project.

In the development of a new startup, a team of project management consultants was organized to develop an RFP to find qualified technical services providers who would be able to build the web site and application at the heart of the new venture.

During the course of the effort, however, something came up which surprised me a bit: a difference among the consulting team about what made good (and even appropriate) requirements documentation and what did not. This surprised me a bit because, after having been doing this for more than a decade and seeing how much the industry and discipline have both matured over time, I did not realize that there were still debates on this matter occurring out in the wild anywhere.

So what are good requirements?
In order to write good requirements, it is important to separate out the “what” question from the “how” question. Confused? Here’s an example:

  • Bad requirement: Provide a drop-down list of choices.
  • Good requirement: Provide the user the ability to select from pre-determined options.

Why not just go with the first choice? Because telling someone to just use “a drop-down” list is dictating both design and functionality. And if you are providing your functional requirements to a provider – who is presumably an expert – then part of what you are asking for is to create the best, and more technically appropriate solution possible.

Now, we could spend weeks going round and round on the different type of requirements: business requirements, functional requirements, non-functional requirements, user requirements, etc. There are plenty of good analysis breakdowns online for what constitutes which one, who uses which type and why. But the key thing for a good consultant to know is which type of requirements are appropriate for the type of project and the audience — because, I promise you, a non-technical business client isn’t going to know the answer to that themselves. Part of what they are paying you for is expertise on what they need to be providing. In this case, we are dealing with a non-technical client for the purposes of finding them a technical vendor to deliver a solution that will meet the needs of their new business. So, in effect — and my apologies to the purists out there — what we were looking for was a combination of business requirements and functional requirements.

In a world of increasingly vital cross-platform applications (iPhone apps, Blackberry apps, etc.) and new UI-driven technologies (Flex/AIR, Ruby on Rails, etc.) this distinction becomes increasingly vital, because different technologies handle these issues natively in different ways. And while a drop-down menu may just be a drop-down menu, there are other design elements that can inadvertently limit your technology if you aren’t clear on the line between the “what” and the “how.”

Another thing to keep in mind is that — again, in a world of prolific cross-platform application development — wherever possible, you’re going to want to get the most bang for your buck out of requirements documents. This means that, while today you may only be building a website, next month you could need to recycle that requirements documentation out to an iPhone developer to build you an app for that platform.

The design logistics of different platforms are inherently different. Unless you want to have to re-write everything to be platform-specific, cut out the “how” all together and keep the requirements platform agnostic so that you can send them to any vendor for any platform built on any technology.

As a project manager or business analyst the goal is to capture the business’ need in a way that gives a web team the ability to provide the critical functionality with the least amount of unnecessary restriction. The biggest danger in that role is to unintentionally impose potentially costly restrictions without realizing it. By including the “how” instead of just the “what” in your requirements, you are potentially limiting solution options — dictating that X needs to be placed over here, or that the page needs to be subdivided a certain way may not be the best or more logical way for a particular technology to work. As a result, you could be giving your potential solution providers a mixed message. Worse yet, it can be a mixed message that hurts the project.