Requirements, Acceptance Criteria, and Scenarios

What they are?, How they differ?, How they are related?

Context

We are building a very basic calculator, one that only supports the four basic operations: Addition, Subtraction, Multiplication, and Division.

Requirements

(from the SWEBOKv3 @ http://www4.ncsu.edu/~tjmenzie/cs510/pdf/SWEBOKv3.pdf)

What they are?

- At its most basic, a software requirement is a property that must be exhibited by something in order to solve some problem in the real world.

What they do?

- Express the needs and constraints placed on a software product that contribute to the solution of some real-world problem.

Properties:

• An essential property of all software requirements is that they be verifiable as an individual feature as a functional requirement or at the system level as a nonfunctional requirement.
• Priority rating
• Uniquely identified

Types (Categories) of Requirements

• Product: A product requirement is a need or constraint on the software to be developed (for example, “The software shall verify that a student meets all prerequisites before he or she registers for a course”).
• Process: A process requirement is essentially a constraint on the development of the software (for example, “The software shall be developed using a RUP process”).
• Functional: Functional requirements describe the functions that the software is to execute; for example, formatting some text or modulating a signal. They are sometimes known as capabilities or features. A functional requirement can also be described as one for which a finite set of test steps can be written to validate its behavior.
• Nonfunctional: nonfunctional requirements are the ones that act to constrain the solution. Nonfunctional requirements are sometimes known as constraints or quality requirements.

Examples

We're going to map each of the basic arithmetic operations to a single requirement, so we'll have:

• Req-1: The calculator must support the Addition operation.
• Req-2: The calculator must support the Subtraction operation.
• Req-3: The calculator must support the Multiplication operation.
• Req-4: The calculator must support the Division operation.

Acceptance Criteria

Set of statements indicating how to judge if a given [software] component or system satisfies certain requirement. Each element, criterion, is an specific statement.

Examples

We, as math experts, know that these operations have certain "properties". We can think of these properties as rules or statements that further define some aspect of the requirement (arithmetic operation). So, now we'll take the Addition as the subject of our examples. We'll have one Criterion for each of the Addition Operation's properties.

• Cri-1-1: The calculator must comply with the Commutative property for the Addition operation.
• Cri-1-2: The calculator must comply with the Associative property for the Addition operation.
• Cri-1-3: The calculator must comply with the Identity property for the Addition operation.
• Cri-1-4: The calculator must comply with the Distributive property, respect to the Multiplication, for the Addition operation.

Scenarios

Set of concrete examples used to validate a single Acceptance Criteria.

Examples

Now we'll take the Commutative property for the Addition operation, as the subject of our examples of Scenarios. What we need are concrete Addition expressions that validate the "presence", or "proper implementation" of the Commutative property (Acceptance Criterion) for the Addition operation (Requirement).

• Sce-1-1-1: 4 + 2 = 2 + 4
• Sce-1-1-2: 10 + 5 = 5 + 10
• Sce-1-1-3: 1 + 2 + 3 = 3 + 2 + 1

A picture is worth a thousand words

Here is a breakdown structure of these three concepts:

Requirements, Acceptance Criteria, and Scenarios breakdown

Summary

What they are? see above definitions.

How they differ? 
Requirements are high level descriptions of system characteristics. Acceptance Criteria are elements used to comply with the "verifiable" property of requirements. Criteria must state how to determine if the software system had properly implemented the requirement.

Often, acceptance criteria are not detailed enough to be useful in practice, so we need concrete examples of Input-Output,  Input-Response Time, etc.; those are the Scenarios.

How are related?
From the above descriptions, you can infer that they are three levels of details of the same thing: what we expect the system to do.

But, what's the deal with all this?

• All actors of the SDLC process must understand what are, how they differ, and why are all three levels required.
• Requirements / User Stories, without Criteria and Scenarios will be to subjective to be verifiable.
• Criteria and Scenarios alone, will be too difficult to manage, without a grouping element (parent requirement).

The usage of all three levels bring a lot of benefits, such as better effort estimation of Stories, Criteria, and Tasks. They also bring some challenges about how to express, document and/or automate those validations. We can review all this in another article, here I just wanted to point out their difference and give some simple examples of each one.

Requerimientos, Criterios de Aceptación y Escenarios

¿Qué son?, ¿En qué difieren?, ¿Cómo están relacionados?

Contexto

Estamos construyendo una calculadora básica, la cual solo soporta las cuatro operaciones básicas: Adición, Sustracción, Multiplicación y División.

Requerimientos

(tomado del SWEBOKv3 @ http://www4.ncsu.edu/~tjmenzie/cs510/pdf/SWEBOKv3.pdf)

¿Qué son?

- En su forma mas básica, un requisito de software es una propiedad la cual debe ser exhibida por algo (componente / modulo / sistema / etc), con el objetivo de resolver un problema del mundo real.

¿Que hacen?

- Expresan las necesidades y limitaciones colocadas sobre el producto de software, el cual contribuye a la solución de un problema del mundo real.

Propiedades:

• Una propiedad esencial de todos los requerimientos de software es que deben ser verificables como una característica individual como requisito funcional, o a nivel de sistema como un requisito no funcional.
• Deben ser estar priorizados.
• Deben estar identificados de manera única.

Tipos (Categorías) de Requerimientos

• de Producto: un requerimiento de producto es una necesidad o constreñimiento en el software a ser desarrollado (ejemplo, "El software debe verificar que el estudiante cumpla con todos los pre-requisitos antes de que el o ella se registre para un curso").
• Proceso: un requerimiento de proceso es esencialmente un constreñimiento en el proceso de desarrollo de software (ejemplo: "El software sera desarrollado utilizando el proceso RUP").
• Funcional: los requerimientos funcionales describen las funciones que el software debe ejecutar; ejemplo: formatear un texto o modular una señal. A veces son conocidos como capacidades o características. un requerimiento funcional puede ser descrito como uno para el se puede escribir un conjunto de pasos de pruebas finito, a ser utilizado para validar su funcionamiento.
• No-funcional: los requerimientos no-funcionales son los que restringen la solución. Muchas veces se les conoce como constreñimientos o requisitos de calidad.

Ejemplos

Vamos a tomar cada una de las operaciones aritméticas básicas como un único requerimiento, así que tendremos:

• Req-1: La calculadora debe soportar la operación Adición.
• Req-2: La calculadora debe soportar la operación Sustracción.
• Req-3: La calculadora debe soportar la operación Multiplicación.
• Req-4: La calculadora debe soportar la operación División.

Criterios de Aceptación

Conjunto de sentencias las cuales indican como sera juzgado (evaluado) un componente de software dado para ver si satisface o no un requerimiento. Cada elemento, criterio, es una sentencia especifica.

Ejemplos

Nosotros, como expertos en matemáticas, sabemos que las operaciones aritméticas básicas tienen ciertas "propiedades". Podemos pensar en esas propiedades como reglas o sentencias las cuales definen en mayor detalle algún aspecto del requerimiento (operación aritmética). Así que ahora tomaremos la operación (requerimiento) Adición como el sujeto de nuestros ejemplos. Tendremos un Criterio por cada una de las propiedades de la operación Adición.

• Cri-1-1: La calculadora debe cumplir con la propiedad Conmutativa para la operación Adición.
• Cri-1-2: La calculadora debe cumplir con la propiedad Asociativa para la operación Adición.
• Cri-1-3: La calculadora debe cumplir con la propiedad Elemento Neutro para la operación Adición.
• Cri-1-4: La calculadora debe cumplir con la propiedad Distributiva, respecto a la multiplicación, para la operación Adición.

Escenarios

Conjunto de ejemplos concretos utilizados para validar un único Criterio de Aceptación.

Ejemplos

Ahora tomaremos la propiedad Conmutativa para la operación Adición, como nuestro sujeto. Lo que necesitamos son ejemplos concretos de expresiones de suma los cuales validen la "presencia", o "implementación correcta" de la propiedad Conmutativa (Criterio de Aceptación), para la operación Adición (Requerimiento).

• Sce-1-1-1: 4 + 2 = 2 + 4
• Sce-1-1-2: 10 + 5 = 5 + 10
• Sce-1-1-3: 1 + 2 + 3 = 3 + 2 + 1

Una imagen vale mas que mil palabras

Aquí tenemos un desglose de los tres conceptos::

Desglose de Requerimientos, Criterios de Aceptación y Escenarios

Resumen

¿Qué son? ver definiciones anteriores.

¿En que se diferencias? 
Son descripciones de alto nivel de características de un sistema. Los Criterios de Aceptación son elementos utilizados para cumplir con la característica "verificable" de los requerimientos. Los criterios deben especificar como determinar si el sistema de software ha implementado correctamente el requerimiento.

Con frecuencia, los criterios de aceptación no tienen el detalle suficiente para ser útiles en la practica, así que tenemos que utilizar ejemplos concretos como Entrada-Salida, Entrada-Tiempo de Respuesta, etc.; estos son los Escenarios.

¿Como se relacionan?
De las descripciones anteriores, usted podrá inferir que son tres niveles de detalle de la misma cosa: que se espera que el sistema haga.

Y ¿Cual es el asunto de todo esto?

• Todos los actores del proceso de desarrollo de software deben entender que son, en que se diferencian y porque son necesarios los tres niveles.
• Los Requerimientos / Historias de Usuario, sin sus Criterios de Aceptación y Escenarios serian muy subjetivos para ser verificables.
• Los Criterios y Escenarios solos serian muy difíciles de manejar, sin un elemento de agrupación (requerimiento padre).

El uso de los tres niveles trae muchos beneficios, como mejores estimaciones de esfuerzo requerido para las Historias de Usuario, Criterios y Tareas. También traen algunos retos interesantes sobre como documentar o expresar automatizar todos estas esas validaciones. Podríamos revisar eso en otro articulo, aquí solo quise resaltar sus diferencias y dar algunos ejemplos simples de cada uno.