Review: INCOSE guide for writing requirements
More than ten years ago, INCOSE published the first version of the "Guidelines for Writing Requirements". Today, this guide is more important than ever, as we need to formulate reasonable requirements for the description of complex systems. The guide is updated regularly and version 3.1 was published in the spring.
For whom is it worth reading the 100+ page guide? That and more in the following review.
On our own behalf: In the Webinar on October 19.29 I will describe how the rules described here can be implemented automatically - register now >>
Target group: People who work with requirements; manufacturers of assistance systems for requirements management.
Rating: ★★★★★ Excellently structured, clear in terms of scope and target group.
Acquire: The The guide is available in the INCOSE store for €25 as a PDF file. available. The guide is free of charge for members. The seven-page summary is also free of charge for non-members.
Scope
The INCOSE guide for writing requirements really only deals with this topic and nothing else. Other important activities, such as requirements elicitation or refinement, are left out. If you are interested in such activities, I recommend other literature, such as the INCOSE SE Manual or the IREB handbook on agile requirements management.
The guideline distinguishes between requirements and needs. It takes into account the formulation of individual requirements and needs (Individual), as well as groups of requirements and needs (Sets).
Characteristics
The guide defines 14 characteristics that our requirements and needs, or groups of these, should fulfill. These have the designations C1-C14.
C1 (Required) means, for example, that individual requirements and needs must be necessary. This may sound trivial at first, but it is amazing how often we find superfluous requirements in practice. One of the reasons for this is that we have a Natural aversion to deletion have.
C11 (consistent) refers to groups and states that they must match. A simple example from the design would be length specifications where the individual lengths do not add up to the correct total length.
Rules
With the definitions and characteristics presented so far, the rules can now be defined and classified. The summary contains tables with which we can quickly find the characteristics that a rule implements. Or, conversely, we can systematically find the rules that help us to check a characteristic.
The rules are formulated in such a way that a clear check is possible. For some rules, this is so simple that a Automatic testing possible and useful is. For example, we have been implementing rule R13 automatically for at least 30 years: R13: Use correct spelling.
In the meantime, we have been able to develop other rules with the help of Natural Language Processing (NLP) automate, such as R5: Use definite article "the" vs "a".
All rules refer to more than one characteristic and some also refer to groups. A simple example of the latter is R36, Use terms & units of measure consistently.
Attributes
Information on requirements (or needs) is not always contained in the requirements text. It is often contained in the associated attributes. A simple example is A15, Unique identifier.
Attributes can make a contribution to the characteristics. The above-mentioned characteristic C1 (Required), for example, is defined by the attribute Rationale (justification).
In the context of this guideline, traceability is also taken into account via attributes. There are the attributes A2 Trace to Parent and A3 Trace to Source.
Target group and application of the INCOSE guidelines
On page 8, the guidelines describe the target group: In principle, all people who work with requirements and needs. I agree with that. However, I see the people who define processes and configure tools as an important subgroup. These people can create the right checklists according to the project goals and based on the guidelines, configure the tools accordingly, and so on.
Even if it would be commendable to always implement all the rules of the guideline, the right cost-benefit ratio should be considered in practice. Concrete example: It certainly makes sense to train the authors of requirements and to teach them Rule R5 (Use definite article "the" vs "a"). However, in most cases it is a waste of time to list this point in an explicit review checklist.
Other target group: Manufacturers of AI assistants
For my activities It is particularly interesting to note that the guide is also aimed at the manufacturers of AI assistants. The guide rightly mentions that the number of rules can be overwhelming. The authors would welcome implementation in corresponding tools.
Such activities already exist. For example, Jama Software is working on an implementation that interested parties can download at labs.jamasoftware.com can try out.
Conclusion
The INCOSE Requirements Writing Guide is now a coherent, well-structured tool for writing high-quality requirements and needs. There is a certain risk that readers will either be put off or, conversely, overdo it when checking the requirements. But I think we can live with that danger.
Photo by Kelly Sikkema on Unsplash, combined with INCOSE
