Magitodaos10

Writing Good Requirements

(A Requirements Working Group Information Report)

Ivy Hooks
Compliance Automation, Inc.
17629 Camino Real, Suite 207
Houston, Texas 77058
Abstract. The primary reason that people write poor requirements is that they have had no training or experience in writing good requirements. This paper will address what makes a good requirement. It will cover some of themost common problems that are encountered in writing requirements and then describe how to avoid them. It also includes examples of problem requirements and how to correct them.

INTRODUCTION
If you or your staff are having problems with writing good requirements, you may benefit from guidance in how to write good requirements. The college courses you took probably never mentioned the subject ofrequirements. Even if you have taken classes in system engineering or program management, you may have had only an introduction to the subject of writing requirements. If you are using existing specifications for guidance, you may be using poor examples. The information provided in this paper is used in training people to write good requirements and generally results in a step functionimprovement in the quality of requirements.
An important aspect of system engineering is converting user "needs" into clear, concise, and verifiable system requirements. While this paper primarily discusses system level requirements, it is equally applicable at all lower levels.
The first section discusses what is a good requirement. This is followed by a discussion of common problems and how to avoidthem. It also includes examples of problem requirements and how to correct them.

GOOD REQUIREMENTS
A good requirement states something that is necessary, verifiable, and attainable. Even if it is verifiable and attainable, and eloquently written, if it is not necessary, it is a good requirement. To be verifiable, the requirement must state something that can be verified by examination, analysis,test, or demonstration. Statements that are subjective, or that contain subjective words, such as "easy", are not verifiable. If a requirement is not attainable, there is little point in writing it. A god requirement should be clearly stated.
Need. If there is a doubt about the necessity of a requirement, then ask: What is the worst thing that could happen if this requirement were not included?If you do not find an answer of any consequence, then you probably do not need the requirement.
Verification. As you write a requirement, determine how you will verify it. Determine the criteria for acceptance. This step will help insure that the requirement is verifiable.
Attainable. To be attainable, the requirement must be technically feasible and fit within budget, schedule, and otherconstraints. If you are uncertain about whether a requirement is technically feasible, then you will need to conduct the research or studies to determine its feasibility. If still uncertain, then you may need to state what you want as a goal, not as a requirement. Even is a requirement is technically feasible, it may not be attainable due to budget, schedule, or other, e.g., weight, constraints. There isno point in writing a requirement for something you cannot afford -- be reasonable.
Clarity. Each requirement should express a single thought, be concise, and simple. It is important that the requirement not be misunderstood -- it must be unambiguous. Simple sentences will most often suffice for a good requirement.

COMMON PROBLEMS
The following is a list of the most common problems inwriting requirements:
Making bad assumptions
Writing implementation (HOW) instead of requirements (WHAT)
Describing operations instead of writing requirements
Using incorrect terms
Using incorrect sentence structure or bad grammar
Missing requirements
Over-specifying
Each of these are discussed in detail below.

BAD ASSUMPTIONS
Bad assumptions occur either because requirement authors do not...