1 / 15

Gestión de requerimientos

Gestión de requerimientos. Agenda. Requerimientos SRS Use Cases User stories UATs Gestión de requerimientos. ¿Que es un requerimiento?. Una condición o capacidad necesitada por el usuario para resolver un problema o alcanzar un objetivo.

blenda
Download Presentation

Gestión de requerimientos

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Gestión de requerimientos

  2. Agenda • Requerimientos • SRS • Use Cases • User stories • UATs • Gestión de requerimientos

  3. ¿Que es un requerimiento? • Una condición o capacidad necesitada por el usuario para resolver un problema o alcanzar un objetivo. • Una condición o capacidad que debe poseer un sistema o algún componente del mismo para satisfacer un contrato, estándar, especificación u otro documento formalmente impuesto. Documentación.

  4. Técnicasparaidentificarlos • Entrevistas a usuarios • Cuestionarios • Brainstorming • Observación • Workshops de creación de userstories • Role Playing • Prototipos

  5. Características de los buenos requerimientos • Con valor para usuarios o clientes • Estimable • Correcto • Sin ambigüedades • Completo • Consistente • Priorizable • Testeable • Modificables (Independientes) • Fácil de seguir (Traceable)

  6. ¿Cómopodemosespecificarlos? • SRS (Software RequirementSpecification) • Caso de Uso • UserStories • UATs Es importante expresar el ¿qué? y no el ¿cómo?

  7. SRS • Basado en el standard IEEE Std 830-1998, • Creado el 1984 y revisado en 1993 y 1998. • Incluye: • Prácticas recomendadas • Diferentes alternativas para organizar una especificación de requerimientos. • Descripción detallada de cada sección. • Introducción • Descripción General • Requerimientos Específicos • Funcionales, • De interfaces externas, • De performance, • Restricciones de diseño, • Atributos de calidad • Otros requerimientos.

  8. Ejemplo de Caso de Uso • UC001 – Registro asignación turno • Actores: Recepcionista • Pre-condiciones: El usuario debe de estar registrado y loggeado • Post-condiciones: El turno queda asignado en el sistema • Flujo Principal: • El usuario selecciona la opción de reserva de turnos • El sistema solicita nombre del médico que asistirá al paciente • El usuario ingresa el nombre del médico del cuál se solicita turno • El sistema muestra los próximos 5 turnos disponibles del médico • El usuario selecciona alguno de los 5 turnos o pasa al flujo alternativo 1. • El sistema solicita datos paciente • El usuario brinda datos paciente • El sistema registra el turno • Flujo Alternativo: “Ninguno de los 5 turnos disponibles es apropiado” • El usuario informa que ninguno de los 5 turnos puede ser tomado • El sistema muestra otros 5 turnos disponibles con un lapso no menor a una semana entre fecha y fecha de cada turno.

  9. UserStories • Describe la funcionalidad que será de valor para un usuario o comprador de un sistema o software. • Tienen información sobre: • Quien? (rol del usuario) • Que? (Objetivo) • Porqué? (justificación)

  10. UserStory Como un [rol] Quiero que [objetivo] para poder [valor de negocio] Ejemplo: Como un médico de la clínica Quiero consultar historias clínicas para poder dar un diagnóstico más acertado a mis pacientes

  11. User Acceptance Tests (UATs) • Son usados para expresar detalles que resultan de una conversación entre clientes y desarrolladores • Documentan supuestos sobre la funcionalidad • Determinan si la funcionalidad está completamente implementada • Deberían ser escritas por el cliente en vez de por el desarrollador (o al menos en conjunto) • Son escritas antes de que el desarrollador codee. • Si es posible los desarrolladores deben automatizar el testing (ej. FIT & FitNesse)

  12. Gestión tradicional

  13. Gestión ágil • El involucramiento activo de los usuarios es imperativo • Los requerimientos evolucionan a medida que se desarrolla el software • La cooperación, colaboración y comunicación entre equipos es esencial. • Los requerimientos ágiles son “justos y necesarios”. Alta Prioridad Cada iteración se implementa los PBI más prioritarios Cada nuevo PBI es priorizado y agregado al backlog PBI más detallados Las prioridades pueden modificarse en cualquier momento PBI menos detallados Los PBI pueden ser removidos en cualquier momento Baja Prioridad

  14. Priorizando requerimientos • Los requerimientos pueden ser priorizados por: • Su valor de negocio • Su riesgo • Su impacto en otros requerimientos • El deseo de utilizarlos • La cohesión con otros requerimientos • Permiten confirmar que el sistema o componente cumple su propósito.

  15. Referencias • “User Stories Applied” Mike Cohn • “Managing Software Requirements, A Unified Approach” Dean Leffingwell, Don Widrig • http://www.extremeprogramming.org • http://www.scrumalliance.org/

More Related