Writing Industrial Strength Requirements Using the IEEE Checklist

 The industrial strength IEEE well-formed requirements checklist found in IEEE Standard 830-1998 allows us to write well-formed requirements at any level of detail. However, it is one thing to recite the elements in the list and quite another thing to understand and consistently apply them to your requirements writing efforts.

Let’s step through each element in the checklist in greater detail. According to the checklist, well-formed requirements should be correct, verifiable, testable, unambiguous, modifiable, complete, traceable, consistent and prioritized. It’s time to take a more detailed look at these nine elements:


Correctness of requirements and requirements documents is not absolute. A requirements document is correct if every requirement stated within it will be met and provided to the users by the resulting product, system, or process. There is no one tool or procedure to ensure correctness of individual requirements or a requirements document. Correctness must be determined and targeted across all steps of the requirements development process. For the overall document, compare the document with other relevant project documentation and standards to see if it agrees. It is essential to seek user and stakeholder review and agreement of the contents using a review or walk through. For individual requirements, show they are correct and relevant by comparing them with their source, and select an appropriate verification method and correctness criteria for each requirement.

Verifiable and testable

Verifiable and testable requirements allow us to ensure that requirements can be met or achieved in the end result. If this is not the case, the requirement should be removed or revised. In general, all requirements must be measurable and provable in some way. Testing proves that what is needed is indeed present in the system, service, or product. So that means that each functional and nonfunctional requirement in our documents must be provable either as a single, standalone statement or within a specific functional scenario. Numerous techniques exist for ensuring that requirements are met, including demonstration, inspection, execution, analysis and prior qualification.


If a requirement can be interpreted in more than one way, it is ambiguous. Choosing the right word is not always easy. Where terms have multiple meanings, it is best to define each word in a glossary based on the document’s audience, scenario, and purpose. There are many problems with “natural language” (the way we speak!). Natural language lends itself to multiple interpretations, includes too many compound sentences, has multiple definitions for words, and uses imprecise adjectives, imprecise conditional instructions, and compound conditions. Structured language combines the language elements with structured programming rules; e.g., structured English uses imperative English verbs, terms are defined in the data dictionary, and reserved words for logic include “If,” “Then,” and “Else.” Our goal is to strike the right balance between understanding and precision in our requirements and our requirements documents.


Requirements should be written and structured to allow for easy changes. Best practices for building and maintaining well-organized documentation include using a table of contents, an index, unique numbering for requirements, and cross-references, as well as minimizing requirements duplication and redundancy. Our goal relative to this checklist item is to have the ability to easily modify requirements within the existing document structure and writing style. This needs to be done both in aggregate and at the individual requirement level.


Requirements should specify everything that is needed at the appropriate level of detail relative to the audience we are writing for. They should also have the correct focus: business, user, system, and software. When assessing completeness of requirements and requirements documents, we need to ask ourselves: Have we missed anything? If there are any unresolved issues or incomplete documents, they need to be corrected. Partially complete requirements can be found by static inspection (reading!), by using a requirements checklist when reviewing a document or document section, by looking at graphical models and seeing if they are completely reflected in the text requirements, by prototyping, and by formal or informal user review.


Requirements are not written in isolation: Traceable requirements are linked to one another, to sections within each document, and to other project documents and deliverables across the project life cycle. Traceability provides us with a mechanism for finding and referring to requirements throughout the project life cycle. It requires unique identifiers within the documents for each requirement. Traceability can be done manually with a spreadsheet, pencil, and piece of paper or it can be implemented using a requirements management tool. There are two basic types of traceability: backward, to previous stages of development and earlier documents and forward, to all documents that originate from the current document


Consistent requirements do not contradict or conflict with one another. If they do, they must either be revised or removed. Detecting consistent requirements requires manual review and analysis of the complete set of requirements. There are subtle difference between contradict and conflict. Contradicting requirements tend to be opposites with no happy medium and are resolved through negotiation. When two requirements contradict one another, you must either choose one or negotiate. Conflicting requirements allow you to identify a trade-off or middle ground between the two by prioritizing the conflicting requirements relative to the project and product scope.


Ranking requirements is essential for scope management across the project life cycle. Prioritizing requirements starts during requirements elicitation activities, as we define our prioritization scheme and ask users to rank what they tell us they need using that scheme. You can also prioritize requirements in multiple dimensions. Typical schemes for prioritization of requirements include importance to the customer, stability, risk, technical difficulty and cost.

Next time you start developing requirements for your project, consider applying the industrial strength IEEE well-formed requirements checklist.  It can assist you and your team in producing a high quality set of requirements defining what is to be done!

Susan Weese

Successful Business Analysts: How They Avoid the Five Most Common BA Mistakes

Business analysts are increasingly becoming the critical liaisons between business and solution development (oftentimes IT), so they must communicate and relate with equal effectiveness throughout all levels of an organization. Download this free White Paper to see which five common obstacles business analysts face and how to address them to ensure success.

Type to search blog.learningtree.com

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.