TestLink - Requirements management

Requirements quality criterias

Quality of requirement

• A requirement must be :
  • Valid,correct
  • Feasible, realizable
  • Useful, necessary
  • Prioritized
  • Not ambiguous
  • Verifiable, testable
  • Atomic, unique
  • Independent from the implementation

Quality of requirements specification

• A requirement specification must be
• Complete
• Coherent
• Editable
• Traceable
• In compliance with standards

How to write requirements

Requirement workflow

Requirement writing guideline

• IDs
• The id of the requirement is the prefix of the project followed by 4 digits.
• The id of the requirement must be coded independently of the section it belongs to.
• Roles
• The roles concerned by the requirement shall be defined in a specific field.
• If the requirement is concerned only by one role, it can appear in the scope and the title.
• If the requirement is concerned by several roles, they must not appear in the title and the scope.
• Priority
• The priority must be defined in a specific field accordingly to the following 4 levels :
• High
• Medium
• Low
• Optional
• The priority must be reflected in the scope and the title of the requirement using the muscow verb method :
• MUST
• SHOULD
• COULD
• WOULD
• Tests
• The number of required test must be 1 at least.
• If the requirement does not need at least 1 test, it means the requirement is unusefull or poorly draft.

Requirements specification building guideline

• Nesting
• Requirements must be grouped by sections.
• A requirement must NOT have child requirements. Only sections can have child requirements.
• Sections can have child sections.
• More than three level of nested sections should be avoided.
• ID
• The ID of the section must reflect its hierarchical location.
• Obsolete section
• As a requirement must not be deleted, the specification must have an section dedicated to receive obsolete requirements.
• Other attributes
• Priority and Roles must NOT be defined for sections.