T5 - Requisitos para Sistemas de Información

Universidad de Sevilla

Departamento de Lenguajes y Sistemas Informáticos

Objetivos

Contenido

  • Introducción
  • Historias de usuario
  • Requisitos generales (objetivos)
  • Requisitos de información
  • Reglas de negocio
  • Requisitos funcionales
  • Requisitos no funcionales
  • Pruebas de aceptación

Contenido

  • Introducción
  • Historias de usuario
  • Requisitos generales (objetivos)
  • Requisitos de información
  • Reglas de negocio
  • Requisitos funcionales
  • Requisitos no funcionales
  • Pruebas de aceptación

¿Qué es un requisito?

Glosario IEEE 610.12

Una condición o capacidad que un usuario necesita para resolver un problema o lograr un objetivo.

Norma MIL-STD-498

Una característica del sistema que es una condición para su aceptación.

J. Goguen

Propiedad que un sistema debería tener para tener éxito en el entorno en el que se usará.

Tipos de requisitos

Contenido

  • Introducción
  • Historias de usuario
  • Requisitos generales (objetivos)
  • Requisitos de información
  • Reglas de negocio
  • Requisitos funcionales
  • Requisitos no funcionales
  • Pruebas de aceptación

Historias de usuario

Son la propuesta de las metodologías ágiles para la especificación de los requisitos.

Se escriben desde el punto de vista del usuario del sistema y usando su vocabulario.

Se suele usar el formato propuesto por Mike Cohn:

Historias de usuario

Ejemplos:

Historias de usuario

Ejemplos:

Historias de usuario

Ejemplos:

Contenido

  • Introducción
  • Historias de usuario
  • Requisitos generales (objetivos)
  • Requisitos de información
  • Reglas de negocio
  • Requisitos funcionales
  • Requisitos no funcionales
  • Pruebas de aceptación

Objetivos (requisitos generales)

No todas las historias de usuario están al mismo nivel de detalle

Objetivos (requisitos generales)

En los objetivos, el nivel de detalle suele ser insuficiente como para que a partir de ellos pueda implementarse una solución.

Ejemplos:

Mapas de historias de usuario

A veces las historias épicas (objetivos) sólo contienen el nombre y se utilizar para organizar jerárquicamente el resto de historias.

Se suelen colorear de forma diferente y se organizan visualmente como mapas de historias de usuario.

Mapas de historias de usuario

Ejemplo de mapa de historias “físico”. Fuente: www.AgileProductDesign.com

Mapas de historias de usuario

Ejemplo de mapa de historias “físico”

Contenido

  • Introducción
  • Historias de usuario
  • Requisitos generales (objetivos)
  • Requisitos de información
  • Reglas de negocio
  • Requisitos funcionales
  • Requisitos no funcionales
  • Pruebas de aceptación

Requisitos de información

Describen qué información se debe almacenar sobre un concepto relevante para poder cumplir los objetivos.

También qué datos específicos del concepto son importantes para los usuarios.

Contenido

  • Introducción
  • Historias de usuario
  • Requisitos generales (objetivos)
  • Requisitos de información
  • Reglas de negocio
  • Requisitos funcionales
  • Requisitos no funcionales
  • Pruebas de aceptación

Reglas de negocio

Definen reglas o políticas del negocio que son importantes para los usuarios y deben ser respetadas.

Reglas de negocio

Suelen ser requisitos relativamente inestables, p.e. la sanción por devolución tardía o el número máximo de préstamos simultáneos en una biblioteca podría cambiar en el futuro por cambios en la política de la biblioteca.

Contenido

  • Introducción
  • Historias de usuario
  • Requisitos generales (objetivos)
  • Requisitos de información
  • Reglas de negocio
  • Requisitos funcionales
  • Requisitos no funcionales
  • Pruebas de aceptación

Requisitos funcionales

En general, definen los servicios que los usuarios desean que el sistema les ofrezca. Por ejemplo:

Contenido

  • Introducción
  • Historias de usuario
  • Requisitos generales (objetivos)
  • Requisitos de información
  • Reglas de negocio
  • Requisitos funcionales
  • Requisitos no funcionales
  • Pruebas de aceptación

Requisitos no funcionales

Describen aspectos relacionados con la calidad que son importantes para los usuarios: usabilidad, rendimiento, disponibilidad, fiabilidad, seguridad, compatibilidad, etc.

Requisitos no funcionales: ISO 9126

Requisitos no funcionales. Ejemplos

Contenido

  • Introducción
  • Historias de usuario
  • Requisitos generales (objetivos)
  • Requisitos de información
  • Reglas de negocio
  • Requisitos funcionales
  • Requisitos no funcionales
  • Pruebas de aceptación

Pruebas de aceptación

No sólo describen cómo validar que el sistema desarrollado satisface los requisitos.

También añaden más detalle a las historias de usuario, sin complicar su descripción.

Lo ideal es que puedan programarse para que se ejecuten automáticamente.

Se asocian a uno o más requisitos (trazabilidad).

Pruebas de aceptación. Ejemplos

Pruebas de aceptación. Ejemplos

Pruebas de aceptación. Ejemplos

Pruebas de aceptación. Ejemplos

Conclusiones

Un requisito es una condición o capacidad que el sistema debe cumplir para satisfacer necesidades reales de usuario y negocio.

La especificación debe combinar visión global (objetivos) con detalle operativo (historias de usuario y criterios verificables).

Las historias de usuario facilitan una captura ágil de necesidades desde el punto de vista del usuario.

Los mapas de historias ayudan a organizar requisitos por jerarquía, prioridad y alcance.

Conclusiones

Los requisitos de información definen qué datos hay que almacenar para soportar los objetivos del sistema.

Las reglas de negocio expresan políticas que el sistema debe respetar, aunque suelan ser más inestables.

Los requisitos funcionales describen los servicios que debe ofrecer el sistema.

Los requisitos no funcionales fijan atributos de calidad como usabilidad, rendimiento, seguridad, disponibilidad o fiabilidad.

Conclusiones

Las pruebas de aceptación validan que el sistema cumple los requisitos definidos.

Estas pruebas aportan más detalle a las historias sin sobrecargar su redacción inicial.

La automatización de pruebas mejora la validación continua y reduce errores en entregas.

La trazabilidad entre requisitos y pruebas es clave para evaluar cobertura y justificar decisiones.

Gracias

Universidad de Sevilla

Departamento de Lenguajes y Sistemas Informáticos