5 INCOSE Guidelines That Every Requirement Engineer Should Know

Articles and Posts Apr 13, 2020 4 mins 15283 Views 0 Comments 0 Likes

The International Council on Systems Engineering (INCOSE) outlines a number of guidelines for writing better requirements, 44 to be exact. From avoiding universal quantifiers, superfluous infinitives, and open-ended clauses, to maintaining consistency throughout the document - the INCOSE guidelines are the gold standard for writing top-notch requirements. Tools such as QVscribe by QRA Corp can help bring your attention to these syntactical errors, but it is important for requirement engineers to have a good understanding of what makes a document as clear and concise as possible to reduce future risk and rework.

Below are 5 of the 44 INCOSE guidelines that every requirement engineer should know prior to starting their project. For more information on INCOSE best practices, check out this helpful guide: Automating the INCOSE Guide for Writing Requirements

R6 - Use Appropriate Units

Although this rule should be a no-brainer, it has been poorly followed in the past which has resulted in millions of dollars in losses. The importance of using the same units throughout the entire requirements document is crucial, as the difference between the imperial and metric system when it comes to measurements is quite large and could result in disaster if converted improperly. QVscribe displays all detected units in the Unit Consistency tab of the Analysis Results screen - sorted by type (length, mass, time, etc.) - along with a count of how many times each unit appears in the document. Each term or unit in the list can be expanded to show the corresponding requirements where the term or unit was found.

R7 - Avoid the Use of Vague Terms

This guideline is tricky as it requires the author to remove themselves from their own work to ensure what they’ve written is universally understood. What ‘immediately’ means to one person, might mean something completely different to the next. For example, the requirement ‘the vehicle door shall open immediately upon stopping’ is vague because it is not clear what immediately means. For this requirement to be more easily understood, immediately should be replaced with an exact time - such as ‘within 1 second or less’. When writing requirements, it is important to be as specific as possible, don’t assume that every reader will interpret it the same way.

R19 - Avoid Compound / Multiple Sentences

A requirement should be written as a simple declarative sentence with a single subject, a single main action verb, a single positive imperative, and a single object. Sometimes requirements are written in a way that would be better suited as two or three separate requirements. For example, the requirement ‘the system shall operate as per performance requirements for at least 48 hours and 240 km continuously without failure in a relevant deployment environment and nominal operation’ is written as one requirement, where it would be more easily understood if it were split into two. One requirement stating the system shall operate for at least 48 hours without failure, and a separate requirement stating that the system shall operate at 240 km continuously without failure.

While sometimes less is more, in this case being as clear as possible with each individual requirement is the ideal way to ensure the document is easily understandable. QVscribe’s Imperatives Test checks that each requirement statement contains one and only one positive imperative, and flags those requirements containing either multiple imperatives, negative imperatives, or no imperatives at all.

R39 - Define Acronyms and Use Them Consistently

When authoring requirements, it is important to have acronyms decided upon prior to starting work on the document. Ensure that all acronyms are also defined beforehand to keep each requirement author and reviewer on the same page. Not everyone will know what certain acronyms stand for, especially if multiple departments are involved. Keep things as clear and simple as possible.

R40 - Avoid Using Abbreviations

One of the trendiest (and quickest) ways to communicate these days is through the use of abbreviations. While it may be fun to refer to certain things with a shortened name when talking with friends, when it comes to requirements writing there should not be any found throughout the document. The abbreviation ‘op’, for example, could mean ‘operation’ in one requirement, but ‘operator’ in another, and thus be misinterpreted in either.

Conclusion

While this article has only outlined 5 of the INCOSE guidelines, it is important for engineers to familiarize themselves with all 44 of the guidelines to help avoid misinterpretation in the future. QVscribe is one way that requirement engineers can better understand these guidelines, as the software helps to automate and speed up the review process. It works within the INCOSE guidelines to help identify all of the aforementioned rules and make suggestions wherever necessary, using a term consistency analyzer to check for similar spelling, abbreviations, and acronyms. Its Vague Words Test checks for an extensive list of terms categorized as vague and flags them when found, and more.

Whatever route requirement engineers decide to take to ensure they are writing clear and concise requirements documents; it is important that they abide by and understand all 44 of the INCOSE guidelines.