Requirement Structure
The following issue messages deal with the structure of a requirement.
Bulleted list not allowed.
A bulleted list has been found in a requirement, which is not allowed according to an active rule.
Lists can give structure to a requirement, readers tend to like lists for this reason, but authors can misuse lists by writing too much information in a single requirement. This is known as requirements amalgamation.
Numbered list not allowed.
A numbered list has been found in a requirement, which is not allowed according to an active rule.
Lists can give structure to a requirement, readers tend to like lists for this reason, but authors can misuse lists by writing too much information in a single requirement. This is known as requirements amalgamation.
Table not allowed.
A table has been found in a requirement, which is not allowed according to an active rule.
Tables can give structure to a requirement, readers tend to like tables for this reason, but authors can misuse tables by writing too much information in a single requirement. This is knows as requirements amalgamation.
Figure not allowed.
A figure has been found in a requirement, which is not allowed according to an active rule.
Figures and images can be open for interpretation. If a figure does not use a defined notation, the figure can be a source of ambiguity. If a figure on the other hand uses a standard notation, the figure can be an excellent way to explain and understand a requirement.
URL address not allowed.
An URL (Uniform Resource Locator) has been found in the text, which is not allowed according to an active rule.
URLs (or URIs - Uniform Resource Identifier) identifies a resource that is external and not inside the Requirements Specification. Using URLs in requirement texts are more problematic than using URLs in plain texts. Links can become inactive, and the resource itself can be changed without the knowledge of the Specification author. Resources that are referenced by URLs are seldom treated as requirements.
The chapter needs to contain a Rationale.
The specific chapter needs to contain a Rationale. A rule has been activated that requires chapters that contain requirements to have a Rationale.
Rationales are written as an introduction to individual requirements or a collection of requirements in a chapter. A Rationale serves as a background to why a collection of requirements exists. A Rationale makes the requirement easier to understand by defining or explaining concepts that are used by the requirements in the chapter.
The Requirement tag exists.
The requirement tag is already used by another requirement. All requirement tags need to be unique in a specification. Tags do not have to be in sequence. This rule is always active and cannot be turned off during analysis.
Tag requires a version.
The requirement tag does not contain a version. An active rule requires that each requirement tag must contain a version. Once a requirement is specified, the requirement has a tag that identifies it. A tag should never be reused by other requirements, and the tag belongs to a requirement as long as the product has not reached End of Life (EOL). Requirements that have been deprecated but reappears at a later stage in the project use the old tag, possibly with a new version.
The application does not check the version type. The authors can use any versioning system they desire. Examples of versioning systems are:
- 1.0, 1.1, 1.2, 2.0 etc.
- A, B, C, D etc. and AA to ZZ.