Rules on Requirement structure

The Navigate > Structure Rules contains rule switches for the examination of requirements structure.

Unique tags

Unique tags makes certain than all requirements have unique tags.

All requirements in a Specification, and this applies even to projects, need to have unique identities for traceability reasons. A Specification can not be stored into the Repository if tags are not unique.

Rationale in chapter

Rationale in chapter makes certain that each requirement chapter has at least one Rationale.

Rationales set the context for requirements. Chapter headings and plain texts provide also a context. Rationales help a reader to understand the requirements. Rationales are normally not treated as requirements during analysis.

Version in tag

Version in tag makes certain that each requirement tag contains a version. The application does not check what type is used. Authors can use capital letters (A-Z), numbers (1, 1.0) or some other system to describe requirement versions.

Versioning information is strictly not needed in rCoach One, but it can make it easier to keep track on which requirements are changed.

No figures

No figures makes certain that the requirement does not contain a figure.

Figures can be open for interpretation and may therefore be unsuitable for requirements. Figures should use a standard notation, for example UML (Unified Modelling Language), ERD (Entity Relationship Diagram) or similar.

No tables

No tables makes certain that the requirement does not contain a table.

Authors who use tables to describe vast quantities of data may be guilty of requirement amalgamation, which is when several requirements are specified as a single requirement. Correctly used, tables can increase the understanding of requirements.

No bulleted lists

No bulleted lists makes certain that the requirement does not contain a bulleted list.

Authors who use bulleted lists to describe vast quantities of information may be guilty of requirement amalgamation. Correctly used, bulleted lists can increase the understanding of requirements.

No numbered lists

No numbered lists makes certain that the requirement does not contain a numbered list.

Authors who use numbered lists to describe vast quantities of information may be guilty of requirement amalgamation. Correctly used, numbered lists can increase the understanding of requirements.

No URL addresses

No URL addresses makes certain that the requirement does not contain URL addresses.

URL addresses act as a reference. The referenced information can however change or become invalid. URL addresses should therefore be used with caution in a Requirements Specification.

The maximum sentence length

The maximum sentence length constrains the number of words a sentence can contain. If this number is exceeded, a serious issue is generated.

Sentence length influences the readability of a Specification. Long sentences can make the content harder to understand. A maximum length of 20 words in a sentence is commonly used.

Modal form

Requirements use different modal forms to describe:

Present or future behavior and abilities;
Suggested behavior and abilities;
Enforced behavior and abilities.

Requirements can be written on five modal forms:

shall-form;
present tense form;
will-form;
should-form;
must-form.

All modal forms can be used in the same Requirements Specification. However, using more than one modal form is not recommended. Usually, requirements are written either on the shall-form or on the present tense form.

A modal form is allowed for requirements when the corresponding check box is set to on. The modal form is not allowed when the corresponding check box is set to off. Requirements written on other modal forms generate a serious issue.

No requirements are checked when the Do not check form box is set to on.

Readability indexes

Four types of readability indexes can be calculated for requirements.