Tipos de requisitos
En resumen: BABOK clasifica los requisitos en cuatro tipos: de negocio (por qué), de las partes interesadas (qué necesita un grupo), de la solución (qué hace el sistema y con qué calidad) y de transición (cómo pasar de lo antiguo a lo nuevo). Las restricciones no son necesidades, sino límites.
Problema
Todo en una lista
Después de la reunión con el dueño, las notas quedan así:
- Los pedidos repetidos suben un 15 %.
- El cliente puede ver sus pedidos antiguos.
- Un botón «Repetir el pedido» junto a cada pedido.
- La página se abre rápido.
- Los pedidos antiguos se pasan del sistema actual.
- Listo para el 1 de diciembre.
Todo es un «requisito». Pero el primero se comprueba seis meses después con un informe de ventas, el tercero con una prueba de la pantalla, el quinto una vez y nunca más, y el sexto con un calendario. Si los mezclas, no sabrás cuál comprobar cuándo, ni cómo.
La idea
Qué es un requisito
Un requisito es una necesidad que alguien tiene, o una capacidad o propiedad que el sistema debe tener para cubrirla. Se escribe de modo que se pueda comprobar después.
Las dos partes importan. «Una necesidad» significa que detrás de cada requisito hay una persona y una razón. «Se puede comprobar» significa que habrá un momento en que alguien diga «sí, se cumple» o «no».
Más precisamente, para curiosos
IREB CPRE da una definición en tres partes: un requisito es (1) una necesidad percibida por una parte interesada; (2) una capacidad o propiedad que un sistema debe tener; (3) una representación documentada de (1) o de (2). La Guía BABOK v3 lo llama una representación utilizable de una necesidad. Las dos dicen lo mismo: el requisito es el puente entre la necesidad de alguien y la solución.
La idea
Los cuatro tipos en BABOK
BABOK clasifica los requisitos del «por qué» al «cómo exactamente»:
| Tipo | Responde | En la tienda |
|---|---|---|
| Requisito de negocio | por qué hacemos el cambio | Los pedidos repetidos crecen un 15 % antes de que acabe el año. |
| Requisito de las partes interesadas | qué necesita un grupo | El cliente encuentra fácilmente lo que pidió antes. |
| Requisito de la solución, funcional | qué hace el sistema | El cliente ve sus pedidos anteriores y repite uno con un botón. |
| Requisito de la solución, no funcional | con qué calidad lo hace | La lista de pedidos se abre en menos de 2 segundos con 200 pedidos. |
| Requisito de transición | cómo pasar de lo antiguo a lo nuevo | Los pedidos de los dos últimos años se pasan antes de que el sistema nuevo entre en servicio. |
Ya conoces los funcionales y los no funcionales. Son las dos mitades de los requisitos de la solución. BABOK llama también a los requisitos no funcionales requisitos de calidad del servicio.
Los requisitos de transición son temporales: después del lanzamiento desaparecen. Por eso es fácil olvidarlos, y sin ellos el sistema nuevo arranca sin los datos antiguos y con un equipo de atención que no conoce la pantalla nueva.
Más precisamente, para curiosos
En las notas del principio: el 1 es un requisito de negocio. El 2 es un requisito de las partes interesadas (las del cliente). El 3 es un requisito funcional de la solución y, en realidad, una solución propuesta para el 2. El 4 es no funcional, pero todavía no tiene medida: «rápido» tiene que convertirse en un número. El 5 es un requisito de transición. El 6 es una restricción.
Otras fuentes reparten las cosas de otra manera. IREB CPRE tiene tres tipos: requisitos funcionales, requisitos de calidad (los no funcionales) y restricciones. «Requisito de usuario» es una expresión habitual en el trabajo. Suele significar el requisito de las partes interesadas de quien usa el sistema.
Pruébalo
¿De qué tipo es?
La idea
Restricciones
Algunas afirmaciones no dicen lo que alguien necesita, sino aquello en lo que tiene que encajar la solución:
- plazo y presupuesto: antes del 1 de diciembre, con 20 000 €;
- ley: el derecho de devolución de 14 días desde la recepción, la protección de datos personales;
- contrato: los pagos pasan solo por el banco con el que la tienda tiene contrato;
- sistemas existentes: la mensajería acepta la dirección solo en su propio formato.
Esto es una restricción. Normalmente no se negocia: ya estaba allí antes de que empezara el proyecto. Pero también se comprueba, también se olvida, y por eso se anota.
La idea
Objetivo frente a solución
En la lección anterior la contadora pidió un botón de Excel, y la necesidad era el informe mensual. Lo mismo pasa con todos los tipos de requisitos.
Un objetivo dice qué hay que conseguir y se puede comprobar sin decir cómo. Una solución dice cómo. «El cliente entiende antes de pagar cuánto costará el envío» es un objetivo. «Una línea “Envío” en el carrito, encima del botón “Pagar”, con el importe en negrita» es una solución.
Las soluciones no están prohibidas. En algún momento alguien tiene que decidir. Lo peligroso es que se escriba la solución en lugar del objetivo:
- el objetivo se pierde, y nadie puede comprobar si la solución lo alcanza;
- se descartan soluciones mejores antes de que alguien las haya visto;
- el tester comprueba el botón, no la necesidad.
La comprobación es sencilla. Para cada requisito pregunta «¿por qué?». Si la respuesta es otro requisito de la lista, este está más abajo en la cadena. Si no hay respuesta, o el requisito sobra o se te ha escapado el objetivo.
Pruébalo
¿Objetivo o solución?
Ejercicio
La cadena
1. Del objetivo a la pantalla. Los requisitos de la solución sirven a los requisitos de negocio. ¿Cuál sirve a cuál, y qué más hay que preguntar?
Test