Whitepapers on Requirements

Thinking Ahead to Verification and Validation (.pdf 723kB)

Second only to re-work, a project’s largest costs are involved in verification and validation. Failing to adequately plan for verification and validation from the beginning of the project places the project at high risk for cost overruns and schedule slips. To mitigate these risks project teams must outline their concepts for verification and validation during the scope definition activities.

Paper written by Louis S. Wheatcraft in 2012; Updated Feb 2016.

Triple Your Chances of Project Success Risk and Requirements (.pdf 211kB)

The emphasis of this paper is to identify common requirement development and management risks that can have an impact on a project’s success, possible consequences of these risks, and strategies to mitigate the risks and avoid the consequences of those risks. Recognizing the fact that poor requirements represent a significant risk to your project and mitigating these risks can triple your chances of project success.

Paper written by Louis S. Wheatcraft in 2011.

Everything you wanted to know about interfaces, but were afraid to ask (.pdf 205kB)

Some of the most critical requirements for every system that we build are interface requirements. Interface requirements cannot be written in a vacuum, both sides must participate. Yet how to write interface requirements is barely covered in the literature – and what is in the literature is not consistent. This paper will address some things you can do to get better interface requirements. Topics covered include: Understand what constitutes an interface, how to identify interfaces, how to define and document interface definitions, what constitutes a good interface requirement, and where and how to document interface requirements.

Paper written by Louis S. Wheatcraft, 2010

Getting Started on the Right Foot: Developing Requirements for Constellation’s Next Generation Space Suit (.pdf 159kB)

In 2007, the Constellation Space Suit Element (CSSE) was tasked to produce their Level IV Element Requirements Document (ERD) and baseline it within a 3-month period. Aware of the consequences resulting from a poor set of requirements, NASA’s Space Suit Project instituted a continuous requirement validation process that would allow the project team to develop a correct, consistent, and complete requirement set within tight schedule constraints. The result was an order of magnitude reduction of review comments against the ERD compared to the number of comments against the parent Level III System Requirements Document (SRD).

Paper written by Louis S. Wheatcraft and Terry R. Hill (NASA), Published and used by INCOSE with permission.

Developing Requirements for Technology-Driven Products (.pdf 118kB)

New technology development is often a mainstay in product development, yet projects responsible for developing products based on new technology frequently are over budget, delivered late, poor in quality, and fail to meet customer and user needs and expectations. Two things that contribute to these problems are: 1) failing to define the product requirements up-front and 2) failing to adequately manage the maturation of the enabling technology(s) needed. This paper introduces several key approaches and processes that address these issues and the many challenges of developing and managing requirements for technology- driven products.

Paper written and presented at INCOSE 2005 by Lou Wheatcraft

Managing Requirements for a System of Systems (.pdf 375kB)

What organizations have done in the past for an SOS, what they are doing now, what they must do in the future to meet this requirement management challenge.

Requested article by Ivy Hooks; Published in CrossTalk, The Journal of Defense Software Engineering, August 2004, Vol. 17 No. 8

Delivering Quality Products That Meet Customer Expectations (.pdf 56kB)

Why is it so difficult for project personnel to deliver a quality product on time and on budget that meets or exceeds their customer’s expectations? A major contributor to project failure is neglecting to spend time at the beginning of the project on the basics.

Article by Lou Wheatcraft; Published in CrossTalk, The Journal of Defense Software Engineering, January 2003, Vol. 16 No. 1

10 Steps to Better Requirements (.pdf 32kB)

Why do some companies deliver winning products – those that are on-time, within budget, and deliver the promised features, while other companies fail? Here’s why and how to be the former, not the latter.

Paper by Larry Fellows presented at the International Conference on Practical Software Quality Techniques (PSQT)and Practical Software Testing Techniques (PSTT) 2003 North, Minneapolis, MN, on September 10, 2003.

Scope Magic (.pdf 264kB)

If you don’t define you project scope before you write requirements you will write your requirements multiple times and poorly capture the scope as you go. You can define scope first and reduce the total time to collect scope and requirements and with much better results.

Paper By Ivy Hooks and Lou Wheatcraft, based on a presentation by Ivy Hooks to the Alamo Chapter of the Project Management Institute (PMI). The subject of this paper was the topic of a presentation made by Ivy Hooks at the Project Management Institute PMI 2001 Symposium at the Opryland Hotel, Nashville, Tennessee, on Tuesday, 6 November, 2001.

Increase Product Quality, Decrease Development Cost (.pdf 107kB)

Apply the proven technique of Inspections to removing requirement defects plus save time and money throughout the develop life-cycle

Paper by Larry A. Fellows

A Case for Priority Classifying Requirements (.pdf 25kB)

You have a choice – prioritize your requirements so the developer is aware of what is on your mind; or just let them guess and have great surprises at CDR or during operations.

Paper presented at the 1998 International Council on Systems Engineering annual symposium by Ivy Hooks and Larry Fellows.

Managing Requirements (.pdf 44kB)

A real-life look at the implementation of requirements management at NASA. This classic article written by Ivy Hooks, was published in Issues in NASA Program and Project Management: A Collection of Papers on Aerospace Management Issues, Winter 1994.

Writing Good Requirements

Helpful hints to avoid many of the most common requirement writing problems.

Paper written by Ivy Hooks for 3rd INCOSE Symposium, July 1993.

ALFS: A Requirement Management Success Using Document Director (.pdf 32kB)

An automation success story. Using allocation and traceability to identify requirement defects.

Paper written by Buddy F. Webb, 1993

Why Johnny Can’t Write Requirements (.pdf 75kB)

This classic paper is as relevant today as it was in 1990. People are still making the same mistakes when writing and managing requirements. Managers are still rushing to design and making bad assumptions about the time and skills it takes to write requirements.. Products are still late, over budget and failing to meet customer expectations.

Requested paper given by Ivy Hooks at AIAA conference, 1990.