The primary reason that people write poor requirements is that they have had no training or experience in actually writing good requirements. This guide addresses what makes a good requirement. It covers some of the most common problems that are encountered in writing requirements and then describes how to avoid them. It also includes examples of problem requirements and how to correct them.

For example, people frequently and unintentionally fall into the trap of making bad assumptions, writing implementation (HOW) vs. requirements (WHAT), and/or over-specifying.  The information provided will help you avoid these and other common pitfalls. 

A specification was released for the development of a requirements management tool. The first requirement was to “provide a database”. The statement is one of implementation and not of need, and it is common to find such statements in requirement specifications. Specifications should state WHAT is needed, not HOW it is to be provided. Yet this is a common mistake made by requirement writers. Most authors do not intend to state implementation; they simply do not know how to state the need correctly.

Crucial to system engineering is the conversion of user “needs” into clear, concise, and verifiable system requirements. While this guide primarily discusses system-level requirements, it is equally applicable at all lower levels.

Inside you will find a multitude of best practices, using real-world examples from two space programs conducted by the NASA Johnson Space Center.  With that said, this deep-dive has been extremely helpful to non-space related industries, ranging from oil and gas companies to financial institutions – particularly those working in the hardware and software arenas.

You may also be interested in Software Requirements, 3rd Edition by Karl Wiegers and Joy Beatty (Microsoft Press, 2013).

Submit the Form Below to Get Instant Access