El buen requisito
En resumen: Un buen requisito es necesario, inequívoco, completo, singular, viable, verificable y correcto. Además, un conjunto de requisitos no debe contradecirse. Un mal requisito es un defecto que se puede cazar leyendo, antes de que exista una sola línea de código.
Problema
«El descuento se ve con claridad»
El requisito es una sola frase: «El descuento se ve con claridad en el carrito». El diseñador lo pone en texto gris bajo el importe. El tester lo ve: se muestra, se lee, aprobado. El dueño lo ve en el lanzamiento y pregunta dónde está la línea roja tachada que él quería.
Cada uno leyó «con claridad» a su manera. Nadie se equivocó en nada, y el producto sigue sin ser lo que debía ser.
El defecto está en la frase. Se puede cazar leyendo, antes de que nadie haya dibujado o escrito nada.
La idea
Qué hace bueno a un requisito
La norma ISO/IEC/IEEE 29148 enumera las características de un buen requisito. Aquí están, con la tienda:
| Característica | Significa | Ejemplo de incumplimiento |
|---|---|---|
| Necesario | si lo quitas, falta algo importante | «El logotipo está arriba a la izquierda», escrito como un requisito que nadie pidió. |
| Apropiado | el nivel de detalle encaja; no dice cómo cuando debería decir qué | «El pedido se guarda en una tabla con tres columnas», al nivel de «lo que necesita contabilidad». |
| Inequívoco | solo se puede leer de una manera | «El código vale una vez»: ¿por cliente o por pedido? |
| Completo | no hace falta nada más para entenderlo y comprobarlo | «Devoluciones en 14 días»: ¿desde cuándo? |
| Singular | dice una sola cosa | «Muestra el importe y permite cambiar la dirección.» |
| Viable | se puede construir con el tiempo, el dinero y la tecnología que hay | existencias en tiempo real de proveedores sin conexión |
| Verificable | hay una forma de demostrar que se cumple | «El carrito se abre rápido.» |
| Correcto | expresa exactamente la necesidad | «Más de 50 €» cuando el dueño quiere «desde 50 €». |
| Conforme | sigue el formato que el equipo acordó | cada requisito es «R-número, frase, medida», y este es un párrafo sin número. |
No te aprendas la tabla de memoria. Las preguntas importantes son tres: ¿se puede leer de una sola manera, se puede comprobar y es la necesidad?
Más precisamente, para curiosos
Las nueve características de arriba son de la segunda edición de ISO/IEC/IEEE 29148 (2018), para un requisito individual: necesario, apropiado, inequívoco, completo, singular, viable, verificable, correcto, conforme.
La lista ha cambiado entre ediciones y entre fuentes. Textos más antiguos añaden «trazable» e «independiente de la implementación». La trazabilidad tiene aquí su propio módulo, y «independiente de la implementación» forma parte de «apropiado»: una solución es un error cuando está a un nivel que necesita una necesidad.
IREB CPRE tiene su propia lista de características, parecida pero con otros nombres. Si te preparas para un examen, aprende la lista del temario que vayas a examinar. La idea en ambas es la misma: el requisito debe leerse de una manera, debe poder comprobarse y debe expresar la necesidad real.
Pruébalo
¿Qué característica falta?
La idea
Palabras trampa
Algunas palabras casi siempre significan un defecto. Cuando las veas, detente:
- «rápido», «cómodo», «fácil», «claro», «moderno»: no tienen medida. Cada uno las lee a su manera, y ninguna prueba puede fallar. Esto es no verificable.
- «etc.», «y otros», «según haga falta»: la lista está abierta. El programador añadirá lo suyo y el tester lo suyo. Esto es incompleto.
- «si es posible», «cuando sea factible», «según corresponda»: una rendija. Un requisito que puede quedar sin cumplir sin romperse no es un requisito. Esto también es no verificable.
- «una vez», «más de», «dentro de 14 días»: palabras que se pueden leer de dos maneras. Esto es ambiguo.
- «el usuario», «el sistema permite»: ¿quién exactamente? ¿Un cliente, un empleado, cualquier visitante? Es un requisito sin actor.
- «botón», «tabla», «en el navegador» en un requisito que debería ser una necesidad: una solución en lugar de una necesidad.
- Y cuando dos requisitos dicen cosas distintas sobre el mismo caso, se contradicen.
Estos seis tipos son los mismos que elegirás en las tareas de abajo.
La idea
Cómo arreglarlo
El arreglo no es una palabra más bonita. Es una medida, una condición y un actor. Un requisito de solución suele tener estas partes:
[cuándo] [quién] [debe] [hacer qué] [con qué] [cómo de bien]
«El carrito se abre rápido» se convierte en:
«Cuando el cliente abre el carrito, la página se muestra en menos de 2 segundos en el 95 % de los casos, con 500 clientes a la vez, en una red móvil.»
«El código vale una vez» se convierte en:
«Un cliente puede usar cada código promocional en un pedido pagado. Un segundo intento con el mismo código se rechaza con el mensaje “El código ya se ha usado”.»
Las frases se hicieron más largas, y ese es el precio. Pero ahora todos las leen de una sola manera, y el tester sabe qué comprobar. La comprobación más fuerte es un ejemplo: «María paga con OTONO10 hoy y otra vez mañana. ¿Qué pasa?»
Más precisamente, para curiosos
IREB CPRE recomienda plantillas de frases para los requisitos. Una de las más conocidas en la práctica es EARS (Easy Approach to Requirements Syntax): «When [evento], the [sistema] shall [respuesta]», «While [estado], …», «If [evento no deseado], then …». En las especificaciones en inglés shall significa obligatorio, should recomendado y may opcional.
La 29148 da además una lista de palabras y construcciones que conviene evitar, por ejemplo: superlativos («el mejor»), palabras subjetivas («cómodo»), pronombres vagos («esto»), rendijas («si es posible», «según corresponda»), palabras de totalidad que no se pueden comprobar («todo», «siempre», «nunca») y afirmaciones negativas cuando se podría decir lo que se exige.
Pruébalo
Revisión: el carrito
Marca las palabras que hacen malo el requisito y elige qué tipo de problema es cada una.
Pulsa las palabras que son un problema; otra vez para quitar la marca. Con las flechas se pasa de palabra en palabra.
Los problemas del texto
- «rápido» no verificable: ¿Qué tan rápido, en qué dispositivo, con cuántos clientes? Sin un número no hay prueba que pueda fallar. Mejor: «el 95 % de las cargas tarda menos de 2 segundos con 500 clientes a la vez».
- «cómodo» no verificable: ¿Cómodo para quién y cómo se mide? Puede convertirse en «un cliente nuevo paga sin ayuda en menos de 2 minutos» o enlazarse con un requisito concreto de accesibilidad.
- «etc.» incompleto: ¿Qué más? ¿El código promocional, los puntos, el plazo de entrega? El programador añadirá lo suyo y el tester lo suyo. La lista tiene que estar cerrada.
Tres arreglos: un número para el tiempo («menos de 2 segundos con 500 clientes»), una medida para la comodidad («un cliente nuevo paga sin ayuda en menos de 2 minutos») y una lista cerrada: el importe, el envío, el descuento y los puntos, y nada más.
La idea
El conjunto de requisitos
Cada requisito puede ser bueno por sí solo y el conjunto puede ser malo. La 29148 enumera también las características del conjunto entero:
- completo: tiene todo lo necesario. Si faltan las devoluciones, la cancelación o el almacén, el conjunto está incompleto, por buena que sea cada frase;
- coherente: dos requisitos no dicen cosas distintas sobre el mismo caso;
- viable: todo junto se puede construir con el tiempo y el dinero que hay;
- comprensible: está claro qué se espera del sistema en conjunto;
- validable: se puede demostrar que el conjunto cubrirá las necesidades del negocio.
Las contradicciones son traicioneras, porque cada uno de los dos requisitos parece bueno. «Envío gratis para más de 50 €» en la página 3 y «sin cargo desde 50 € inclusive» en la página 17 pasan cada uno cualquier revisión por separado. Las cazas cuando las buscas sobre el mismo caso: exactamente 50,00 €.
Ejercicio
Revisa los requisitos
1. Códigos promocionales. Los requisitos de los códigos promocionales, tal como salieron de la reunión.
Marca cada lugar que hace malo el requisito.
Pulsa las palabras que son un problema; otra vez para quitar la marca. Con las flechas se pasa de palabra en palabra.
Los problemas del texto
- «El usuario» sin rol: ¿Qué usuario: cualquier visitante, un cliente registrado, un empleado de la tienda? De eso depende quién puede usar el código y quién no.
- «etc.» incompleto: ¿Solo códigos promocionales, o también vales y puntos de fidelidad? Una lista abierta no se puede comprobar hasta el final.
- «una vez» ambiguo: ¿Una vez por cliente o una vez por pedido? Las dos lecturas dan respuestas distintas cuando el cliente hace un segundo pedido con el código. Este es justo el error que ya vimos.
- «Si es posible,» no verificable: Una rendija: si el descuento no se muestra, siempre se puede decir «no era posible». O el requisito se quiere, o no se quiere.
Arreglado: «Un cliente registrado puede usar un código promocional en un pedido pagado. El descuento se muestra en el carrito como una línea aparte con el importe». Los vales y los puntos tienen sus propios requisitos.
2. Envío. Cuatro requisitos de la especificación del envío, de páginas distintas.
Marca los problemas y elige el tipo de cada uno. Ojo con los requisitos que se contradicen.
Pulsa las palabras que son un problema; otra vez para quitar la marca. Con las flechas se pasa de palabra en palabra.
Los problemas del texto
- «más de 50 €» contradictorio: R-27 dice «desde 50 € inclusive». Con un carrito de exactamente 50,00 € los dos requisitos dan un precio distinto. El dueño dijo «desde 50 €», así que es R-12 el que hay que corregir.
- «Si es posible,» no verificable: Una rendija: un requisito así nunca puede fallar en una prueba. O el envío se calcula automáticamente, o el requisito dice cuándo no.
- «en el navegador del cliente» solución en lugar de necesidad: Dónde se calcula el precio lo decide el equipo. La necesidad es «el cliente ve el coste del envío antes de pagar».
- «desde 50 € inclusive» contradictorio: Contradice a R-12 con exactamente 50,00 €. En el conjunto no pueden quedarse los dos: uno se corrige y el otro puede eliminarse por duplicado.
R-12 y R-27 se convierten en uno: «El envío cuesta 0,00 € para pedidos desde 50,00 € inclusive, y en otro caso cuesta 4,90 €». R-13 pierde el «si es posible». R-14 se convierte en «El cliente ve el coste del envío en el carrito antes de pagar», y dónde se calcula lo decide el equipo.
3. Devoluciones. Los requisitos para devolver un producto.
Marca cada lugar que hace malo el requisito.
Pulsa las palabras que son un problema; otra vez para quitar la marca. Con las flechas se pasa de palabra en palabra.
Los problemas del texto
- «dentro de 14 días» ambiguo: ¿Desde cuándo: desde el pedido, desde el pago o desde la recepción? La ley de la UE cuenta desde la recepción de la mercancía, y el requisito tiene que decirlo.
- «rápido» no verificable: ¿En cuántos días? La ley de la UE da al comerciante como máximo 14 días desde que el cliente comunica su desistimiento. La tienda puede prometer menos, pero con un número.
- «fácil para todos» no verificable: ¿Cómo se mide «fácil» y quiénes son «todos»? Puede convertirse en un requisito concreto: por ejemplo, un cliente con lector de pantalla devuelve un producto por su cuenta.
Arreglado: «El cliente puede solicitar la devolución dentro de los 14 días siguientes a recibir el paquete. La tienda reembolsa el dinero en los 14 días siguientes a la solicitud». Y «fácil para todos» se sustituye por requisitos concretos de accesibilidad que se pueden comprobar.
Test