● Scrum es un framework agil muy completo para el desarrollo de proyectos

○ Cliente/Stakeholder: Proporcionar los requerimientos al PO y le entregan el

valor de negocio
○ Product owner: Comunica los requerimientos al Equipo Scrum, elabora el
Product Backlog y define los criterios de CA
○ Scrum Master: asegura un ambiente laboral al equipo Scrum
○ Equipo Scrum: crea los entregables del proyecto y demuestra al PO el
incremento del producto durante la reunion de reviosn de sprint
● Requisito- necesidad y requerimiento-expectativa.
● Problemas:
○ Los usuarios no saben lo que quieren
○ UN sistema tien emuchos usuarios y ninguno tiene una ivsion de conjunto
○ No saben que partes de su trabajo pueden transformarse en software
○ No saben detallar lo que saben de forma precisa
● Solución tradicional: Analistas
○ Labores:
■ Obtener una lista de requisitos de cada usuario
■ Adquirir una vision de conjunto
■ componer un especificacion completa, correacta y consistente
○ Desventajas:
■ Lista de requisitos son dificles de compender y de hacer bien
■ Dificiles de transformar en especificaciones de diseños e
implementación
● Solución Agil
○ User Stroy Lufecycle
● Requisitos Funcionales
○ Definen loq ue el sistema tiene que hacer, los servicios que dbe porporcionar
al usuario
○ describen la duncionaliad del sistema.
● Requisitos No Funcionales
○ DElimintan las condicones que se presta a los usuarios
■ Velocidad ed respuesta
■ Ancho de banda requerido
■ Espacio de memorio o en disco
○ Definicion de requisitos
○ Especificaicoón de requistiros
■ Especificacion de software
● Errores en la toma de requerimientos
○ Al informatizar un determinado proceso el propio proceso puede sufrir
cambios difíciles de predecir.
○ Usuarios diferentes tienen requisitos y prioridades diferentes. Hay una
negociación de cambios en los requisitos.
○ Los usuarios finales del sistema y la organización que paga por el sistema
tienen requisitos diferentes.
○ El prototipado es necesario para clarificar requisitos
● Validación de requisitos
○ Demostración de que los Requisitos que definen el sistema son lo que el
cliente realmente quiere.
 ○ Los costos de errores en los Requisitos son altos, por lo cual, la validación es
muy importante.
■ reparar un error de Requisito después del desarrollo puede resultar
en un coste 100 veces mayor que reparar un error en la
implementación.
○ El Prototipado es una técnica importante de la validación de Requisitos.
● ¿Que comprobar?
○ Validación. ¿Provee al sistema las funciones que mejor soporten las
necesidades del cliente?
○ Consistencia. ¿Existe cualquier conflicto en los Requisitos?
○ Completo. ¿Están incluidas todas las funciones requeridas por el cliente?
○ Realismo. ¿Pueden los Requisitos ser implementados con la tecnología y el
presupuesto disponible?