Modificado Nov/18

COPPEL
MANUAL TÉCNICO MCC DE “SISTEMAS PROGRAMACIÓN”
DESCRIPCIÓN DEL PROCESO DE “GESTIÓN DE REQUISITOS”

Objetivo: Contar con una guía de las actividades principales para analizar la problemática o
propuesta de mejora del Solicitante, entendiendo las necesidades del negocio, para identificar los
requisitos de software, fomentando la colaboración con el cliente durante la creación del Product
Backlog.

Responsables: Los responsables de este proceso son el Solicitante (SOL), Scrum Master (SM) y
Equipo de trabajo (ET).

Descripción del Diagrama de Flujo

Inicio: Este proceso inicia cuando el Área de negocio cuenta con un conjunto de peticiones
registradas por el Solicitante en la herramienta Administrador de Peticiones de Sistemas (APS). El
Gerente de proyectos agrupa las peticiones que corresponden a un mismo producto y las planifica
asignándolas a un Equipo de trabajo, formando de esta manera los Portafolios de las diferentes
áreas de negocio.

1.- SOL escribe Historias de usuario y crea Product Backlog. Toma una petición, o un conjunto
de peticiones levantadas en la herramienta Administrador de Peticiones de Sistemas (APS) que
estén relacionadas a un mismo producto, y documenta las necesidades del negocio en forma de
Historias de Usuario, las cuales se redactarán de manera puntual, simple y fácil de entender. Cada
Historia de Usuario debe de respetar el siguiente formato:

Como un <rol / tipo de usuario>, necesito<requerimiento / meta> para que <beneficio / razón>.

El Solicitante y Equipo de Trabajo se reúnen para revisar las funcionalidades de las Historias de
Usuario con el objetivo de definir lo siguiente:

- El conjunto de reglas que debe seguir cada Historia para definir el Criterio de aceptación, ya que
esto eliminará la ambigüedad de los requerimientos y ayudará a que el equipo se adhiera a las
normas de calidad obligatorias para todas las Historias de Usuario.

- El Criterio de Terminado, llegando a un acuerdo de en qué momento se dará por terminado el

producto, ya que puede depender de otras áreas o del mismo Solicitante la instalación y/o el uso del
producto independientemente de que el trabajo del equipo ya haya concluido. Los puntos básicos a
revisar son: que el diseño esté revisado, el código completo (auditado), documentación actualizada,
probado con cero defectos conocidos, prueba de Aceptación realizada e instalado en los servidores
de producción.

- La priorización, la cual se define tomando en cuenta dos factores principales:

Valor: El Solicitante debe asegurar en primer lugar la entrega de los productos que ofrezcan el
mayor valor del negocio.
Dependencias: Los requerimientos funcionales a menudo dependen de otros requerimientos
funcionales e incluso no funcionales. Estas dependencias pueden afectar cómo se priorizará la lista
de requerimientos, para resolver dichas dependencias se puede dividir una sola Historia de Usuario
en varias partes o combinar Historias interdependientes.

Posteriormente crea el Product Backlog el cual es la lista de Historias de usuario ya priorizadas que
mantiene actualizada de forma continua, se agregan, eliminan o actualizan antes de ser
comprometidas por el Equipo de Trabajo. A su vez actualiza las Historias de usuario que serán
trabajadas durante el próximo Sprint.

Nota:
 • En cualquier momento del proyecto el Equipo de trabajo, puede estar en contacto con el
Solicitante para aclarar dudas correspondientes a las historias de usuario que se están
trabajando, con la finalidad de entregar un producto que cubra las necesidades específicas
del cliente.
• Las historias de usuario no deben ser demasiado grandes, es necesario descomponerlas
para que sean pequeñas y se les pueda dar un mejor seguimiento.

2.- ET analiza necesidad de negocio. Analiza la o las peticiones del Solicitante con el objetivo de
identificar las funcionalidades o descripciones de productos que están ampliamente definidas, para
posteriormente realizar los modelos de análisis.

3.- ¿Está definida la necesidad de negocio? Nos hacemos esta pregunta para corroborar que la
necesidad de negocio fue definida clara y ampliamente por el Solicitante, en caso de tener definida
la necesidad del negocio, o una parte de la necesidad con la que se pueda comenzar , continuamos
con la Actividad 5 “¿Serán necesarias capacitaciones?”, en caso contrario continuamos con la
siguiente actividad.

4.- Llamado a la Gestión de iniciativas. Continuamos en la Actividad 3 “SOL documenta Procesos

de negocio y BNEA” del Proceso de Gestión de iniciativas con el objetivo de definir la necesidad de
completa de negocio, sus impactos y el alcance requerido de la solución.

5.- ¿Serán necesarias capacitaciones? Nos hacemos esta pregunta para verificar si el Equipo de
trabajo necesitará alguna capacitación. En caso de que no sea necesaria una capacitación continúa
en la Actividad 9 “ET modela diagrama de análisis”, de lo contrario continúa en la siguiente
actividad.

6.- SM gestiona capacitación. Evalúa las necesidades de capacitación de los miembros del
equipo y facilita la formación, para lo cual se establece una dinámica de capacitación que se puede
llevar a cabo antes y durante el desarrollo del Sprint. El Scrum Master facilita y gestiona las
capacitaciones técnicas referentes a: lenguaje, software utilizado, ambientes y demás necesidades.

7.- SM planea capacitación. Genera las actividades necesarias de capacitación, ya sea para el
equipo o para un recurso en específico y dichas actividades quedan plasmadas en la herramienta
de seguimiento.

8.- ET toman capacitación. El Equipo de trabajo asiste a la capacitación planeada por el Scrum
Master en caso de ser presencial, o se autocapacita en los tiempos destinados.

9.- ET modela diagramas de análisis. Elabora los modelos que resultan del análisis de la
necesidad de negocio. A continuación se hace una breve descripción del contenido de cada uno de
los modelos generados en la herramienta Enterprise Architect (EA): Modelo de casos de uso, en
este modelo se plasman los actores que van a interactuar con el sistema. Se indica cual es el
diagrama de caso de uso general y el detalle de la interacción sistema-usuario; y el Modelo de
requisitos, en el cual se plasman los requerimientos funcionales, los requerimientos no funcionales,
las reglas de negocio y los prototipos de interfaz en caso de aplicar para el proyecto. El modelo de
requisitos se define como obligatorio, es el punto de partida para el desarrollo del proyecto, donde
se establecen las necesidades del cliente convertidas en requerimientos de sistema. El modelo de
casos de uso describe la funcionalidad propuesta del sistema, por lo cual se establece como
obligatorio generarse apegándose a los siguientes criterios:
• En caso de que el modelo de casos de uso no exista, se tiene que generar
necesariamente.
• Si el modelo de casos de uso ya existe, se actualiza solo la funcionalidad afectada o se
agrega la nueva funcionalidad.
• En caso de que el proyecto solo contenga requerimientos no funcionales, la generación de
casos de uso es opcional, dependiendo de las validaciones que contenga dicho de caso
de uso.

10.- SOL valida modelos. Revisa los modelos de caso de uso, modelo de requerimientos y modelo
de interfaz, con el objetivo de corroborar que las necesidades del negocio plasmadas en forma de
historias de usuario se resuelvan con la solución en sistema propuesta por el Equipo de trabajo.
11.- ¿SOL aceptó modelos? Nos hacemos esta pregunta para verificar si el Solicitante ha
encontrado válidos los modelos de análisis y de interfaces. En caso de que no los haya aceptado
continúa en la Actividad 2 “ET analiza la necesidad de negocio”, de lo contrario continúa en la
siguiente actividad.

12.- ET asisten a reunión de revisión del Product Backlog. El Equipo de trabajo, en conjunto con
el Solicitante, se reúnen para elaborar el plan de liberación, con el cual tendrán una visión general
de la liberación de las Historias de Usuario y el calendario de entrega del producto que están
desarrollando para que puedan alinearse con las expectativas del Solicitante y los involucrados.
Dicho plan se debe agregar como anexo de la primer historia de usuario el cual se evidencia con un
correo electrónico al Solicitante para delimitar el proyecto y las Historias de Usuario que serán
liberadas en cada uno de los Sprint que se definan para el proyecto, quedando plasmado en las
historias comprometidas por Sprint en la herramienta de seguimiento. Así mismo el Equipo de
trabajo deberá estimar el esfuerzo de las Historias de usuario utilizando la dinámica de Planning
poker, en la cual determinarán los puntos de historia que pesará cada Historia de usuario.