Ingeniería de Requisitos

1. Desarrollo de requisitos: identificar, acordar y documentar el conjunto de requisitos y

características de producto que permitan alcanzar los objetivos de negocio planteados.

Involucra actividades de: Captura, Análisis (desarrollan y valoran), Especificación (registro

de las especificaciones) y validación (asegurarse de que son correctos los requisitos).

2. Gestión de requisitos: gestiona la evolución de los requisitos del sistema: control de estado
y seguimiento en la evolución de requisitos, trazados de dependencias entre requisitos
adelante y atrás a lo largo del ciclo de vida.

Un requisito es una capacidad, característica o factor de calidad que un sistema (software)

necesita para tener valor y utilidad para un usuario.

Requisitos funcionales y no funcionales

1. El Requisito Funcional, permite describir el comportamiento del usuario con el software.

Se realiza con los siguientes niveles:

 Nivel objetivo agregado: centrado en los procesos de negocio de alto nivel. Ejemplo: Control
flujo de caja, gestionar relaciones con clientes, efectuar gestión de los recursos.
 Nivel objetivo de usuario: centrado en las tareas. Ejemplo: cancelar cuentas por cobrar,
emitir certificado de participación del alumno en el curso.
 Nivel de subfunción: centrado en pasos y reglas de tareas. Ejemplo de pasos: sistema de
cajero automático. Transacciones como: retiro, pago, transferencia. Ejemplo de reglas:
clientes con edad mayor a 18 años pueden ser titulares de cuentas, los niños menores de
dos años no pagan pasaje y son llevados en el regazo del responsable.

2. Requisitos no funcionales, permite describir los atributos de calidad del sistema (tiempo de
procesamiento, seguridad de los datos, interfaz de comunicación con dispositivos de E/S,
requisitos de portabilidad (diferente Navegador web), ….)

EJEMPLO DE HISTORIAS DE USUARIO

FRENTE DE LA TARJETA
Nombre historia: Pagar cuenta por celular
Descripción:
 Como <rol>: Como comensal con prisa
 Puedo <acción>: Puedo pagar la cuenta de mis alimentos consumidos por celular
 Para <justificación>: Para no tener que esperar que el mesero me cobre
Criterios de Aceptación:
 Dado que []: Dado que quiero pagar mi cuenta con tarjeta
 Cuando []: Cuando en mi celular elija la mesa y los alimentos consumidos
 Entonces []: entonces se solicitará que proceda con el pago usando mi tarjeta

CONVERSACIÓN (AL REVERSO)

Detalles:
  Reglas de negocio: el listado de alimentos deberá contener nombre, precio e imágenes
 Requerimientos no funcionales: la transacción deberá tomar menos de 10seguntos
 Otros detalles importantes: previo a la venta de alimentos deberá proceder a verificar los
alimentos y la mesa.

Ejemplos:
 As a registered user I want to log in so I can Access subscriber-only content.
 Como usuario típico quiero leer criticas objetivas de los restaurantes próximos a una
localización con objeto de decidir a donde puedo ir a cenar.
 Como usuario de la wiki quiero subir ficheros a la wiki para compartirlos con mis colegas.
 Como estudiante quiero consultar mis notas on-line para no esperar hasta una
comunicación formal para saber si he aprobado.

FORMATO DE HISTORIAS DE USUARIO

 TARJETA: Descripción escrita de la historia de usuario a efectos de descripción de requisitos

y planificación y como referencia para discusión posterior.
 CONVERSACIÓN: sección para recoger información adicional en relación con la historia de
usuario y detalles surgidos de conversaciones posteriores.
 CONFIRMACIÓN: sección que recoge condiciones de satisfacción o pruebas de aceptación a
realizar para comprobar que la historia está completa y funciona como se espera.

CRITERIOS DE HISTORIAS DE USUARIO

EMPLEAR

 Independent (Independiente): deben ser independientes entre sí o estar débilmente

relacionadas.
 Negotiable. No son un contacto ni una especificación sino una referencia a una característica
que el equipo debe discutir y clarificar para su desarrollo.
 Valuable. Deben proporcionar valor al usuario (en general, stakeholder) y describir
características del sistema, no tareas.
 Estimable. Deben contener suficiente detalle como para estimar el esfuerzo/coste de
desarrollo.
 Small. Su tamaño debe permitir implementar en un sprint.
 Testable. Deben ser comprobables mediante pruebas.

***********************************

Usuario: estudiante

 Registro de documentos en la web de la EPIS

 Consulta de estado de documentos en la web de la EPIS.

Usuario: Secretaria

 Registra de documentos que llegan a la EPIS.

 Registra los documentos que se generan en la EPIS.
 Registro la derivación de documentos a las comisiones de la EPIS.
 Consulta y actualiza el estado de los documentos registrados en la EPIS.
 Registra los tramites que se realizan en la EPIS y los requisitos correspondientes.
 Registra las comisiones de la escuela y asigna a los responsables de la misma.
 Reporte de: documentos (ingresados, atendidos, pendientes)
 Búsqueda de documentos ingresados y el estado del documento (atendido, pendiente)

Usuario: Director

 Consulta los documentos derivados por la secretaria EPIS.

 Autoriza o deniega la “solicitud de pedido” de los documentos.

Usuario: Comisión

 Consulta los documentos derivados por la secretaria EPIS.

 Autoriza o deniega la “solicitud de pedido” de los documentos.
 Registra archivo (*.pdf) de atención al documento.