Requirements are an often misunderstood necessity of software testing. Furthermore, the ways in which they are used changes depending whether you are using them in the context of classical or agile testing. Understanding Requirements aims to introduce the most common terms and concepts used in determining requirements, as well as their relationship to each other within classical and agile methodologies.

1. Motivation

System engineering literature is filled with countless inconsistent terminologies and vocabularies concerning requirements. The overall goal of this document is to introduce some of the most common terms and concepts used in describing requirements in agile and classical system engineering. It is worth mentioning that we don’t intend to flood you with myriad examples, which by themselves are vague in nature; rather, we aim to emphasize the fundamental distinctions and relationships of requirements in both the classical and agile worlds. Bear in mind that the explanations given below are by no means the industry standard, insofar as a standard exists at all. This document should rather be viewed as a primary basis for creating a common understanding about requirements. Having that said, let us dive into the topic. A requirement in its most general form is defined as follows:

A requirement is a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or any other formally imposed documentation. Hence, a requirement represents a condition or capability required by a user to solve a problem or to achieve an objective.

Wow, looks like a bunch of lawyers wrote that definition. However, it will do quite well for now. In order to reassure those who are worried about that apparently vague definition, it is noted that this concept is developed further in the subsequent sections.

2. Classical World

First of all, it is worth noting that the term “classical software development” is just a collective title for numerous traditional models (e.g. waterfall, v-model) applied in software development and testing. In this section the requirements and their relationships that evolve through these models are briefly summarized.

2.1 Stakeholder Need

Get the full Whitepaper

2.2 Feature

Understanding Requirements chart

Clearly, these abstract stakeholder needs must be stated in more concrete terms to move towards implementation. That means we have already reached the hard part, i.e. to form a concrete solution to the problems and objectives identified by the stakeholder needs. These more concrete terms are simply called features. Together with the associated stakeholder needs, the features are usually cited in a vision document that highlights the overall intent and purpose of the system being built. By defining “features”, we have moved from the problem domain into thesolution domain.

A feature represents a service that the system provides to fulfill one or more stakeholder needs.

Furthermore, these features aim to describe a desired and/or not desired behavior of the system in the user’s language. For that reason alone, these concrete terms are also referred to as user requirements. These features express what is needed rather than how it must be achieved. As a result, one can conclude that each stakeholder need can be translated into one or more features, and each feature can provide a service that fulfills one or more stakeholder needs. […]

Continue Reading the Whitepaper