3 Ways Requirements Documents Kill Product Development Projects

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?

documentsCreative 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.

Conclusion
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

Comments

Requirements engineering is the first and most important task in any project. Requirements must be written from the perspective of the product user and a good technique is the Kano model.

Couldn't _disagree_ more. I'm a C-level consultant and a Ph.D-educated professor in Systems Engineering. Quality is all about the customer's perception of value, and requirements are only meaningful if they reflect that perception. But perception changes over time, often faster than the requirements can be instantiated. Taking time to develop stellar requirements simply gives more opportunity for perception to change . To innovate, you must try, fail, learn quickly, and try again,

Thanks, guys. Though the “fail early fail often” mantra is popular these days, we always add “fail smart” to the end of that slogan for a reason. Perception plays a part, but there are some things that a user needs to do to be successful with the device or product that do not change. We discover these and write them into requirements. The idea is that with this kind of input, requirements will change less, and if you learn “smartly” from this, you will need to “try again” less often.

QFD is a better method to define a project. I have simplified it into a process called Structured Product Definition, which is freely available to use. See http://dmajic.com/papers/spd_01.ppt

Great info in your presentation. Your methods align nicely with a design driven development mentality for medical device development.

Hii, Thanks for the sharing nice posting with us. i’m really impressed. netgear wireless router setup netgear help http://router-supports.com

Add new comment

By submitting this form, you accept the Mollom privacy policy.