• 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.