Qué es un requisito de software
Un requisito de software es una frase que dice qué debe hacer un sistema, o qué nivel de calidad debe cumplir. Todo el diseño y todas las pruebas salen de esos requisitos.
Imagina la biblioteca de una universidad. Quiere que los estudiantes reserven salas de estudio desde el móvil, sin hacer cola. Para construirlo, alguien tiene que decir con claridad qué significa eso.
Al terminar esta lección
Nota
Puedo convertir una necesidad en un requisito claro y comprobable.
Palabras clave
| Palabra | Qué significa | Ejemplo |
|---|---|---|
| Necesidad | lo que alguien quiere conseguir | reservar sin hacer cola |
| Requisito | una frase que dice qué debe hacer o cumplir el sistema | |
| Requisito funcional | dice qué hace el sistema | |
| Requisito no funcional | dice con qué calidad lo hace | responde en menos de 2 segundos |
| Comprobable | se puede probar y el resultado es un sí o un no | |
| Parte interesada | una persona a la que afecta el sistema |
Las celdas que rellenan los estudiantes quedan en blanco en esta vista previa.
Una necesidad todavía no es un requisito
Una necesidad es lo que alguien quiere conseguir: "reservar sin hacer cola". Es cierta, pero no dice qué hay que construir.
Un requisito baja un paso. Dice qué hace el sistema con palabras que un programador y una estudiante entienden igual: "El sistema permite reservar una sala para una hora concreta".
De una sola necesidad salen varios requisitos. Unos dicen qué hace el sistema y otros cómo de bien lo hace.
Ejemplo resuelto: de la necesidad a los requisitos
| Necesidad | Requisito | Tipo |
|---|---|---|
| Reservar sin hacer cola | La estudiante reserva una sala para una hora desde el móvil | Funcional |
| Que no se pisen dos reservas | Una sala no puede tener dos reservas a la misma hora | Funcional |
| Que vaya rápido | Una reserva se confirma en menos de 2 segundos | No funcional |
| Que la use cualquiera | Un estudiante nuevo reserva sin ayuda en menos de 3 minutos | No funcional |
Las celdas que rellenan los estudiantes quedan en blanco en esta vista previa.
Un requisito comprobable lleva un número
Un requisito es comprobable si dos personas lo prueban y llegan al mismo sí o no. "Rápido" no lo es: lo que es rápido para una persona es lento para otra.
Para arreglarlo, cambia la palabra vaga por un número o por un hecho. "Responde en menos de 2 segundos" se mide con un reloj. "Rechaza una hora fuera del horario" se prueba con una petición.
Ejemplo resuelto: de vago a comprobable
| Requisito vago | Por qué falla | Requisito comprobable |
|---|---|---|
| El sistema debe ser rápido | ¿Cuánto es rápido? | Una reserva se confirma en menos de 2 segundos |
| La app debe ser fácil de usar | Cada persona opina distinto | Un estudiante nuevo reserva sin ayuda en menos de 3 minutos |
| Debe haber un buen horario | ¿Cuál es el bueno? | Solo se reserva entre las 8 y las 20 horas |
Las celdas que rellenan los estudiantes quedan en blanco en esta vista previa.
Un error frecuente
Advertencia
Mucha gente cree que un requisito con palabras bonitas ya está claro. "Moderno", "intuitivo" y "rápido" suenan bien, pero no se pueden probar. Una palabra así solo sirve si va con un número o un hecho que cualquiera pueda medir.
Un sistema que ya funciona esconde requisitos
Un sistema ya hecho guarda requisitos en sus reglas. Leer lo que rechaza ayuda a escribirlos.
El laboratorio tiene una API web de reservas, hecha sobre una tabla bookings. psql es el cliente de la base de datos y curl envía peticiones web. Los comandos crean la tabla, leen sus filas y prueban dos reservas que la API debe rechazar. Primero da a psql la contraseña.
Dar a psql la contraseña
export PGPASSWORD=shopSe muestra aquí y no se ejecuta. Crea una cuenta gratuita para pulsar Ejecutar y escribirlo en el terminal de tu propio laboratorio.
Crear la tabla de reservas
psql -h db -U shop -c "drop table if exists bookings; create table bookings (id serial primary key, room text not null, student text not null, hour int not null check (hour between 8 and 20), status text not null default 'confirmed', unique (room, hour)); insert into bookings (room, student, hour) values ('A1', 'Lucia', 9), ('A1', 'Marcos', 10), ('B2', 'Irene', 9), ('B2', 'Pablo', 12); notify pgrst, 'reload schema'"Se muestra aquí y no se ejecuta. Crea una cuenta gratuita para pulsar Ejecutar y escribirlo en el terminal de tu propio laboratorio.
Leer todas las reservas
curl -s -w "\n" "http://api:3000/bookings?order=id"Se muestra aquí y no se ejecuta. Crea una cuenta gratuita para pulsar Ejecutar y escribirlo en el terminal de tu propio laboratorio.
Reservar a las 30 horas
curl -s -w "\n%{http_code}\n" -X POST -H "Content-Type: application/json" -d '{"room":"A1","student":"Nora","hour":30}' "http://api:3000/bookings"Se muestra aquí y no se ejecuta. Crea una cuenta gratuita para pulsar Ejecutar y escribirlo en el terminal de tu propio laboratorio.
Reservar sin nombre de estudiante
curl -s -w "\n%{http_code}\n" -X POST -H "Content-Type: application/json" -d '{"room":"A1","hour":11}' "http://api:3000/bookings"Se muestra aquí y no se ejecuta. Crea una cuenta gratuita para pulsar Ejecutar y escribirlo en el terminal de tu propio laboratorio.
Ejemplo resuelto: reglas vistas y requisitos que salen
| Lo que hizo la API | Requisito que escribirías |
|---|---|
| Rechaza la hora 30 con un 400 | Una reserva solo se acepta entre las 8 y las 20 horas |
| Rechaza una reserva sin estudiante con un 400 | Toda reserva lleva el nombre de quien la hace |
| Guarda cada reserva con el estado confirmed | Una reserva nueva queda confirmada desde el primer momento |
Las celdas que rellenan los estudiantes quedan en blanco en esta vista previa.