The primary reason that people write poor requirements is that they have had no training or experience in writing good requirements. An important aspect of system engineering is converting user "needs" into clear, concise, and verifiable system requirements.

​

GOOD REQUIREMENTS SHOULD BE...

Necessary: 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 not a good requirement.

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. 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 other constraints. 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 [objective], not as a must-have [threshold] requirement. Even if a requirement is technically feasible, it may not be attainable due to budget, schedule, or other, e.g., weight, constraints. There is no 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.

User Correct Terms: In a specification, there are terms to be avoided and terms that must be used in a very specific manner. Authors need to understand the use of shall, will, and should:

• Requirements use shall

• Statements of fact use will

• Goals use should.

• Example

  • WRONG: The system shall support the training coordinator in defining training scenarios.

  • RIGHT: The system shall provide input screens for defining training scenarios.

Easy to Read & Understand: ​Requirements should be easy to read and understand. The requirements in a system specification are either for the system or its next level, e.g. subsystem. Each requirement can usually be written in the format:

• The System shall provide ...

• The System shall be capable of ...

• The System shall weigh ...

• The Subsystem #1 shall provide ...

• The Subsystem #2 shall interface with ...

Note: The name of your system and the name of each subsystem appear in these locations. If you have a complex name, please use the acronym or your document will be unnecessarily long.

​

AVOID THESE WHEN WRITING REQUIREMENTS 

Bad Assumptions: Bad assumptions occur either because requirement authors do not have access to sufficient information or the information does not exist. This information then must be made available to all authors. You can create and maintain a list of other relevant documents and make these easily accessible to each author. Your can use RTD Manager​ to store links to your project related documents or internet references so that individual authors can quickly view the reference material.

​

Over Specifying: The DoD has stated that over-specification is the primary cause of cost-overruns on their programs. Over-specifying is most often from stating overly stringent requirements. Some of the major horror stories of the aerospace industry deal with overly stringent requirements.

Example: One contractor was severely criticized for charging $25,000 per coffee pot in airplanes built for the government. But the requirements for the coffee pot were so stringent, that if the plane crashes, no coffee would spill. The solution to this problem is to discuss the allowable tolerances then write the requirement to take into consideration those tolerances.

Unnecessary Items. Unnecessary requirements creep into a specification in a number of ways. The only cure is careful management review and control. Many project requirements are deleted when their authors are queried as to the need. System Engineers need to ask "is this a nice to have or must have?" Most program do not have budgets for nice to have items.

RTD Manager​ includes a peer-review process to ensure proper review and control to avoid these cost overruns. 

​

The above is a condensed version written by Ivy Hooks for Third INCOSE Symposium and Published in the Proceedings of the Third International Symposium of the INCOSE