Standards

This section describes the criteria which have been established for requirements documentation and from which organizations or companies they come from. It must always be decided as to what criteria should be used for the requirements documentation for each project.

Quality Criteria according to IEEE 830

The Institute of Electrical and Electronic Engineers (IEEE) already defined the standard IEEE 830 in 1998. This stipulates the basic quality criteria for the documentation of requirements.

The criteria formulated in the standard IEEE 830 are:

• Correct: The requirements are checked and passed by the person who submitted them.
• Unambiguous: They are formulated so as to leave no room for interpretation. They unambiguously define what is required so that it cannot be misinterpreted.
• Complete: Via the submitter of the requirements, it is ensured that the formulation is not only correct but also complete. No aspects may be omitted here.
• Consistent: The description has been drawn up and checked so that the individual requirements do not automatically raise questions regarding other requirements and make further unknown changes necessary.
• Ranked (Priority/Effort): Formulated requirements are prioritized by the requirements submitter. They are marked according to importance and have a first approximate cost estimate.
• Verifiable: For each request, so-called “acceptance criteria” are formulated, which state under what conditions the requirement will be accepted by the requirements submitter.
• Modifiable / Granular: The requirements are formulated so granularly that a change is possible without affecting the other requirements.
• Traceable: The formulations must be implemented so that transparency and traceability are guaranteed. From the request of a Stakeholder, through the project planning, implementation and acceptance, the requirement should be traceable. This is made possible for example by allocating unambiguous numbers per requirement.
• Valid and up-to-date: The requirements controller has the formulated requirements to keep up-to-date.

Sophist Group

The book by the Sophist Group “Requirements Engineering and Management” is a standard reference for dealing with requirements for many requirements analysts.

The Sophist Group is extending the IEEE 830 standard with the following criteria:

• Classifiable: Meant with this is the ‘ability to classify’ in regards to the legal liability. Each contractual partner has to make the legal relevance clear.
• Understandable: The requirements must be understandable to all stakeholders. It may be necessary to use different documentation techniques for the different stakeholders depending on the project phase.
• Validity – currentness of the requirements: requirements are kept up-to-date. Change requests adapt to their documentation and the changes are recorded.
• Feasible: requirements must be implemented with the known features, the limits of the system and their environment. Found here is the coordination with the development which can check the requirements for feasibility and implementation costs.

Necessary: each requirement should describe a performance or feature that is actually required by the customer or required to adapt to an external system. A requirement is only necessary if you fulfill a system objective.

INVEST-features to Cohn

The INVEST-features according to Cohn are specially formulated for user-stories (a type of requirements documentation in agile process models), but can also be used without these requirements.

There are the following features:

• Independent: requirements should be independent from each other. Ideally, they should be able to be implemented in any order; dependencies lead to risks.
• Negotiable: A requirement should be formulated so that it contains a margin of discretion and can be negotiated in the planning meetings. This increases the productivity of the development team because the creativity of the team can be brought in.
• Valuable: A requirement should be formulated so that the real benefit is seen.
• Estimable: A requirement must be clearly worded so that it can be estimated by the team.
• Small: requirements should be described in small packages. Complex requirements should be further subdivided.
• Testable: All requirements should be testable. These acceptance criteria should be available to every requirement.

If you would like to know how to deal with requirements in Scrum professionally, refer to the chapter “Professional Requirements Management with Scrum”.