Creative people hate documentation. Technical people hate ambiguity.
We all agree that a requirements document is an essential part of the product development process, but can this document actually lead to the downfall of a project?
Here are 3 ways that a requirements document can hinder the success of a project.
1. It Doesn’t Exist
It’s pretty tough to start a project and get everyone moving forward in the same direction if you don’t have a requirements document. However, this happens far more often than you may think.
Early startups often struggle here. “We are just trying to prove feasibility,” or “We just need to get to proof-of-concept first,” are the most common reasons these early stage companies use to explain the absence of a requirements document.
However, even at this early stage, a requirements document can help focus your activities and eliminate redundancy of tasks, all of which will help you save money. (This can be a big deal since money tends to be the item of scarcity with most young startups.)
2. Requirements Doc Is Really a Specification Doc in Disguise
Too many developers forget that a requirements document is meant to describe what the product will do. Because engineers are problem solvers, our brains love to jump quickly to solutions, and we often fall in love with those early solutions.
This is why we have a tendency early on to describe how the device is going to do what it is going to do (solution-oriented), instead of what we want the device to do (results-oriented).
The former is a scientific approach, and the latter is a user-centered approach.
Describing the “how” of functionality is what the specification document is for, which comes later in the process.
Designing with specifications guiding the early stages of development is a sure way to stifle creativity, and potentially make your device susceptible to getting beaten up by the users and regulatory people late in the process.
3. Requirements Doc Doesn’t Include Design or Usability Requirements
Many times, developers will populate the document with the most well-known items. “It has to be portable; it must fit in the trunk of a car; it must have a display.”
These are all important requirements, but also very simple ones.
Design requirements should go beyond this by gathering a deeper understanding of the user and their needs through various forms of research to discover hidden and unmet user needs.
For example, understanding that a medical device must be handheld is a pretty simple requirement.
A more complete requirement might involve requiring the handle to allow the user to control suction, steering, and activation with that same hand, and without changing the position of that hand during usage.
Taking the time to create a stellar requirements document can prevent wasted time by eliminating redundant tasks. Creating a requirements document that truly is a requirements document and not specifications document may free up your teams to be more creative in their product development approach.
Finally, if requirements are based on deep user needs, it increases the chance of