• 1.1 Objetivos
  • Propósito y audiencia objetivo del ERS
• 1.2 Ámbito
  • Que hace y que no hace el producto
• 1.3 Definiciones, siglas y abreviaturas
• 1.4 Referencias
• 1.5 Visión global
  • Como se organiza el resto del ERS

• 2.1 Perspectiva del producto
  • Relación con otros productos de software del sistema
• 2.2 Funciones del producto
• 2.3 Características del usuario
• 2.4 Restricciones generales
• 2.5 Asunciones y dependencias
  • Factores que pueden afectar los requisitos especificados.

• 3.1 Interfaces externas
  • Descripción de entradas y salidas del sistema
• 3.2 Funciones
• 3.3 Requisitos de rendimiento
• 3.4 Restricciones de diseño
• 3.5 Atributos de calidad del software
• 3.6 Otros requisitos.

Son metodologías alternativas a las tradicionales que dan soporte a los valores incluidos en el manifiesto Ágil. Suelen ser iterativas de ciclo corto y flexibles. Se centran principalmente en el código.

• Valorar a los individuos y su interacción sobre los procesos y herramientas
• Valorar el software que funciona sobre la documentación
• Valorar la colaboración con el cliente sobre la negociación contractual
• Valorar la respuesta al cambio sobre el seguimiento de un plan

• La prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor.
• Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo.
• Entregar con frecuencia software que funcione en períodos de un par de semanas a un par de meses con preferencia en los períodos breves
• Las personas de negocio y los desarrolladores deben trabajar juntos
• La forma más eficiente de comunicar información es cara a cara
• Los procesos Ágiles promueven el desarrollo sostenido
• La atención a la excelencia técnica enaltece la agilidad.

• Extreme Programming (XP)
  • No habla explícitamente de técnicas de ingeniería de requisitos
  • Usa entrevistas, brainstrorming y prioriza las historias de usuario.
• Modelado Ágil (AM)
  • Igual que XP, pero hay diferencia entre modelos informales y documentación
• Scrum
  • Los requisitos se recolectan en el BackLog
  • En cada Sprint se implementan los más prioritarios.

Es una metodología framework, un conjunto de buenas prácticas para la gestión de proyectos. Consiste en la iteración de entregas incrementales

• Product owner
  • Gestiona las necesidades que serán satisfechas en el proyecto
  • Debe recoger y tener claras las necesidades de la aplicación
  • Fijar criterios de aceptación para cada historia de usuario
• Equipo de desarrollo
• Scrum Master
  • Se centra en el proceso de scrum, actúa como mentor y ayuda a resolver los impedimentos que van surgiendo.

Son lo que el cliente quiere que se implemente. Descripción breve de una funcionalidad tal y como la percibe el usuario.

• Product backlog
  • Listado ordenado y priorizado de todo aquello que es necesario añadir al producto
• Sprint backlog
  • Subconjunto seleccionado del Product Backlog para el sprint
  • Los elementos se dividen en subtareas.

• Sprint
  • Dura de 1 a 4 semanas
  • Producto potencialmente entregable
• Planificación del Sprint
  • Se hace el primer día de sprint
  • Product owner, scrum master y equipo de desarrollo
• Daily Meeting
  • No más de 25 minutos
  • Scrum master y equipo de desarrollo
• Revisión del sprint
  • No más de 4 horas
  • Product owner, scrum master y equipo de desarrollo
  • Burndown Chart
• Retrospectiva
  • Aspectos positivos y negativos del sprint
  • Product owner y equipo de desarrollo

Las historias de usuario no son requisitos por lo que según algunos autores se puede considerar que en scrum no hay requisitos, aunque algunos autores consideran que las historias de usuario pueden ser consideradas requisitos poco detallados.

• Captura de requisitos
  • Implicación de los usuarios
    • Las metodologías Ágiles suponen que tendrán al cliente ideal
    • Las metodologías tradicionales evitan esta suposición con técnicas para confrontar y validar
  • Entrevistas
    • Es la principal técnica de las metodologías Ágiles
  • Priorización:
    • Es una práctica donde se implementan primero los requisitos más valiosos para el cliente
• Especificación de requisitos
  • Las reuniones de análisis son frecuentes durante todo el proceso pero la documentación es menos rígida
  • Las técnicas de modelado solo se usan para facilitar comprensión en Ágil
  • No se pretende generar una documentación completa
  • Se deja mucha libertad al equipo de desarrollo
  • Las historias de usuario son las técnicas más utilizadas en Ágil
• Validación de requisitos
  • Se usan las reuniones de revisión
• Gestión de Requisitos
  • No es posible la trazabilidad total de los requisitos como en las metodologías tradicionales
  • Proporcionan buena base con el backlog y un listado de características
  • Aproximación poco detallada a la captura de requisitos, se omiten detalles para completarlos más tarde.
• Las fases de las metodologías tradicionales no son fácilmente separables en las metodologías ágiles
• Las técnicas utilizadas en las metodologías tradicionales se encuentran vagamente descritas ya que se confía mucho en el equipo de desarrollo
• La documentación es poco extensa y compacta, lo que la hace sencilla de mantener.

• Las especificaciones se presenta como un texto informal complementado con descripciones formales, estas últimas contienen pequeños trozos fáciles de leer.
• Los esquemas introducen variables de estado y define restricciones y operaciones en el estado
• Ejemplo:
  • La signatura define las entidades que constituyen el estado del sistema
  • El predicado establece las condiciones que siempre deben cumplirse para esas entidades

• Introducción: se define el tipo y declaran otras especificaciones que se usan
• Descripción: Describe informalmente las operaciones del tipo
• Signatura: Define la sintaxis de las operaciones, número y clase de sus parámetros y las clases de los resultados
• Axiomas: Define la semántica de las operaciones mediante la definición de axiomas que caracterizan su comportamiento