FORMATO Código: FRM-AREQM02

Revisión: 01
Aprobado: Jefe OTI
Fecha: 05/09/2017
Plan de Gestión de Requerimientos Página: 1 de 9

Autoridad Portuaria Nacional

Oficina de Tecnologías de la Información

Proyecto [Acrónimo]: [Nombre del Proyecto]

Documento: Plan de Gestión de Requerimientos

 FORMATO Código: FRM-AREQM02
Revisión: 01
Aprobado: Jefe OTI
Fecha: 05/09/2017
Plan de Gestión de Requerimientos Página: 2 de 9

CONTROL DE VERSIONES

Fecha de
Versión Descripción del cambio Modificado por
cambio
1.0 Versión inicial 05/09/2017 Reynaldo Rodríguez
 FORMATO Código: FRM-AREQM02
Revisión: 01
Aprobado: Jefe OTI
Fecha: 05/09/2017
Plan de Gestión de Requerimientos Página: 3 de 9

CONTENIDO

1. OBJETIVO DEL DOCUMENTO............................................................................................4

2. DOCUMENTOS BASE.........................................................................................................4
3. ROLES Y RESPONSABILIDADES DE LA GESTIÓN DE REQUERIMIENTOS...................4
4. CRITERIOS DE SELECCIÓN DE PERSONAS AUTORIZADAS PARA DEFINIR
REQUERIMIENTOS............................................................................................................. 4
5. PERSONAS AUTORIZADAS EN DEFINIR REQUERIMIENTOS.........................................5
6. CRITERIOS PARA ACEPTAR Y APROBAR REQUERIMIENTOS.......................................5
7. NOMENCLATURA DE REQUERIMIENTOS Y CASOS DE USO.........................................5
8. ESTADO DE LOS REQUERIMIENTOS...............................................................................6
9. PRIORIDAD DE REQUERIMIENTOS..................................................................................6
10. ELEMENTOS DE TRAZABILIDAD.......................................................................................6
11. TRAZABILIDAD.................................................................................................................... 6
12. CRONOGRAMA DE REUNIONES DE DEFINICIÓN DE REQUERIMIENTOS.....................7
13. GESTIÓN DE CAMBIOS EN LOS REQUERIMIENTOS.......................................................7
13.1. PROCEDIMIENTOS DE CONTROL DE CAMBIOS.......................................................7
13.2. FORMATO DE SOLICITUD DE CAMBIOS....................................................................9
14. FRIMAS DE APROBACIÓN...............................................................................................10
 FORMATO Código: FRM-AREQM02
Revisión: 01
Aprobado: Jefe OTI
Fecha: 05/09/2017
Plan de Gestión de Requerimientos Página: 4 de 9

1. OBJETIVO DEL DOCUMENTO

Definir la manera de gestionar los requerimientos del proyecto, identificando los roles y
responsabilidades de las personas involucradas durante la definición de requerimientos, los
criterios y procedimientos para seleccionar, aceptar o realizar cambios a los requerimientos, así
como otros elementos relacionados al proyecto.

2. DOCUMENTOS BASE
Los siguientes documentos han servido de fuente para la elaboración del presente documento
así como para la especificación de requerimientos del software:

DOCUMENTO DESCRIPCIÓN BREVE

Acta de reuniones iniciales
Plan de Gestión del Proyecto
Plan de Desarrollo de
Software
Visión del Proyecto
Donde se definen los requerimientos iniciales del software a
desarrollar.
Documento que define como se ejecuta, supervisa y controla el
proyecto.
Documento que planifica todo el análisis y diseño del sistema.
Facilita una visión general sobre todas las tareas que deben realizarse
en el proyecto, presentando un desglose de los paquetes de trabajo.

3. ROLES Y RESPONSABILIDADES DE LA GESTIÓN DE REQUERIMIENTOS

ROL
Jefe del Proyecto
Analista de Sistemas
Jefe del Proyecto del
lado del Cliente
NOMBRES Y APELLIDOS
Roger Marcelo Concha Valdivia
Daniel Castillón García
Leonardo Rodriguez
ENTREGABLE BAJO SU
RESPONSABILIDAD
 Plan de Gestión de Requerimientos
 Cronograma del Proyecto
(Programación de reuniones)
 Especificación de Requerimientos
del Software
 Actas de reunión de especificación
de requerimientos
 Especificación de Casos de uso del
Software
 Informe de Prototipo del Software
 Matriz de trazabilidad.
 Responsable de la revisión y
aprobación de los entregables
relacionados con la fase de Análisis
de requerimientos

4. CRITERIOS DE SELECCIÓN DE PERSONAS AUTORIZADAS PARA DEFINIR

REQUERIMIENTOS
La siguiente tabla describe las cualidades y habilidades que deberán tener las personas que
participarán y están autorizadas para la definición de los requerimientos:

Nº CRITERIO
 FORMATO Código: FRM-AREQM02
Revisión: 01
Aprobado: Jefe OTI
Fecha: 05/09/2017
Plan de Gestión de Requerimientos Página: 5 de 9

C1 Conocer y tener experiencia en los procesos del Negocio del Cliente que están
involucrados en el software a desarrollar.
C2 Serán usuarios finales del software a desarrollar
C3 Tener ascendencia en el área del Cliente involucrada en el desarrollo del software.

5. PERSONAS AUTORIZADAS EN DEFINIR REQUERIMIENTOS

La siguiente tabla lista a las personas autorizadas a definir los requerimientos:

NOMBRES Y APELLIDOS CARGO PROCESO

Leonardo Rodriguez Gerente de Grupo Garome Verifica y controla los procesos del
grupo Garome.

6. CRITERIOS PARA ACEPTAR Y APROBAR REQUERIMIENTOS

La siguiente tabla lista los criterios que se tomarán en cuenta para aceptar y aprobar los
requerimientos especificados.

Nº CRITERIO
C1 Deberán ser definidos por las personas autorizadas.
C2 Deberán ser proporcionados por escrito. Se realizarán reuniones para explicar los
requerimientos, y luego de ser evaluados se decidirá si son viables o si necesitan un
mayor análisis.
C3 Deberán estar descritos en un acta de reunión.
C4 Si el requerimiento amerita un cambio en la lógica del negocio, este deberá incluir en su
descripción todos los casos posibles, en los que se pueda ver alterado. Tendrá que llenar
una solicitud de cambio en el formato FRM-PMC02 Solicitud de Cambios.
C5 Deberá incluir un glosario de Términos.
C6 Los requerimientos aceptados y aprobados deberán ser descritos en el Documento de
Especificación de Requerimientos.
C7 Los requerimientos nuevos o modificados, deberán manejarse mediante la Solicitud de
Cambio

7. NOMENCLATURA DE REQUERIMIENTOS Y CASOS DE USO

A continuación se especifica la forma mediante la cual, se denominan a los requerimientos y a
los casos de uso:

NOMENCLATURA ESPECIFCACIÓN EJEMPLO

Prefijo de Requerimiento
RI - n Inicial o requerimiento incluido n : correlativo RI-001
en las reuniones iniciales
Prefijo de Requerimiento
RF - n n : correlativo RF-005
Funcional
Prefijo de Requerimiento No
RNF - n n : correlativo RNF-015
Funcional
CU - n Prefijo de Caso de Uso n : correlativo CU-001
 FORMATO Código: FRM-AREQM02
Revisión: 01
Aprobado: Jefe OTI
Fecha: 05/09/2017
Plan de Gestión de Requerimientos Página: 6 de 9

8. ESTADO DE LOS REQUERIMIENTOS

Se definen tres estados para los requerimientos durante todo el proceso de desarrollo:

ESTADO DESCRIPCIÓN
Aprobado Requerimientos aceptados y listos para ser desarrollados.
Rechazado Requerimiento que no cubre ninguna funcionalidad del proceso a desarrollar.
De Cambio Requerimiento generado por una solicitud de cambio.

9. PRIORIDAD DE REQUERIMIENTOS

PRIORIDAD DESCRIPCIÓN
Debe ser implementado a cabalidad y debe cubrir todas las necesidades del
cliente. Estos requerimientos deberán ser implementados durante el desarrollo.
Alta Los cambios realizados sobre estos requerimientos deben ser analizados
cuidadosamente ya que estos forman parte de la estructura base del proceso de
desarrollo.
Influye dentro de la funcionalidad esperada por los usuarios, pero no sobre el
Media
proceso de desarrollo, ni en los productos entregados durante cada iteración.
El impacto de los cambios realizados para esta categoría, no afectan el proceso de
Baja
desarrollo ni la satisfacción del usuario.

10. ELEMENTOS DE TRAZABILIDAD

ELEMENTO DESCRIPCIÓN
Requerimiento Requerimientos formulados en la propuesta técnica o en las bases del proyecto.
s Iniciales
Requerimiento Requerimientos que se derivan de los Requerimientos Iniciales.
funcional
Requerimiento Requerimientos que definen propiedades que el software debe tener. No añaden
no funcional funcionalidad al producto.
Actor Usuario del Software, que forma parte de la Organización.
Caso de uso Funcionalidad propia del sistema.
Entregables Elemento resultado de la ejecución de un proceso X para el presente proyecto.
Entidad mínima que permite ser construida y probada y que consiste en una
Componentes
interfase externa o interna, objeto de BD o de la aplicación.

11. TRAZABILIDAD
Las coincidencias, indican las matrices de Trazabilidad que se van a generar y a utilizar para la
gestión de los requerimientos:

REQ. REQ. NO CASO

ENTREGABLE COMPONENTE
FUNCIONAL FUNCIONAL DE USO
Req. Inicial X X
Req. Funcional X X X
Entregable
Actor X
Componente X
 FORMATO Código: FRM-AREQM02
Revisión: 01
Aprobado: Jefe OTI
Fecha: 05/09/2017
Plan de Gestión de Requerimientos Página: 7 de 9

12. GESTIÓN DE CAMBIOS EN LOS REQUERIMIENTOS

En esta sección se indica el procedimiento a seguir para gestionar el control de cambio de los
requerimientos. Estos cambios se dan por la necesidad de incluir un nuevo requerimiento en la
lista de requerimientos aprobados y aceptados o por la existencia de un cambio en el alcance o
un cambio en la descripción de un requerimiento ya existente en la lista mencionada.

12.1. PROCEDIMIENTOS DE CONTROL DE CAMBIOS

Para llevar a cabo el tratamiento o gestión de cambios que se presenten durante el desarrollo
del proyecto se seguirá las actividades descritas en el proceso “PMC-02 Controlar Cambios del
Proyecto”, el mismo que se muestra a continuación:

12.2. FORMATO DE SOLICITUD DE CAMBIOS

Para solicitar algún cambio durante el desarrollo del proyecto se usará el formato “FRM-PMC02
 FORMATO Código: FRM-AREQM02
Revisión: 01
Aprobado: Jefe OTI
Fecha: 05/09/2017
Plan de Gestión de Requerimientos Página: 8 de 9

Solicitud de Cambios”, el mismo que se visualiza a continuación:

DATOS GENERALES DE LA SOLICITUD DE CAMBIO

Nº ESTADO DE En Recha
{01} Solicitada Aprobada {x}
SOLICITUD SOLICITUD evaluación zada
FECHA DE <dd/mm/yy PRIORI
SOLICITANTE <Nombres y Apellidos> {Alta}
SOLICITUD > DAD
DESCRIPCION CAMBIO
< Incluir una descripción del cambio a realizarse >

JUSTIFICACIÓN
< Incluir un texto que describa la justificación del porque se realiza el cambio >

ANALISIS DE IMPACTO
1) IMPACTO EN LOS REQUERIMIENTOS
REQUERIMIENTOS IMPACTADOS DESCRIPCIÓN DEL CAMBIO
< Incluir un texto que describa el cambio en el requerimiento>
{RF-001: Descripción corta }

{RF-002: Descripción corta } < Incluir un texto que describa el cambio en el requerimiento>
2) IMPACTO EN EL ALCANCE
< Incluir un texto que describa los cambios en los paquetes de trabajo del WBS>
{El cambio solicitado tiene un impacto en el WBS el cual se traduce en la adición de un nuevo paquete de
trabajo de capacitación en la fase de implantación y en la elaboración de un manual electrónico del software}

3) IMPACTO EN LOS PLAZOS

< Indicar el impacto en el cronograma en función de días>
{El cambio solicitado significa una ampliación de 7 días útiles en la fecha de fin del proyecto, así como también
en la postergación de la fecha Hito dd/mm/yy de la fase de Análisis de requerimientos }
4) IMPACTO EN EL ESFUERZO Y COSTOS

 < Indicar el impacto en función a horas hombre y precio (Inc. Margen) >
{El impacto del cambio se traduce en 100 horas hombres lo cual expresado en términos monetarios es de:
$5,000 (Sin IGV)}.
5) ENTREGABLES A SER MODIFICADOS O ACTUALIZADOS DEBIDO AL CAMBIO
Nombre del Entregable Responsable Impacto por la gestión de cambios (Horas hombre)
 < Entregable >
 < Determinar el esfuerzo que demanda modificar o actualizar el
{Especificación de  <Nombres y
entregable >
Requerimientos del Apellidos>
{2hora }
Software}
 < Entregable >  < Determinar el esfuerzo que demanda modificar o actualizar el
 <Nombres y
 {Arquitectura del Software entregable >
Apellidos>
} {2hora }
 < Entregable >  < Determinar el esfuerzo que demanda modificar o actualizar el
 <Nombres y
 {Módulo de Finanzas - entregable >
Apellidos>
Modificación } {16hora }
 < Determinar el esfuerzo que demanda modificar o actualizar el
 {Módulo de Finanzas –  <Nombres y
entregable >
Nueva Funcionalidad } Apellidos>
{40hora }

13. FRIMAS DE APROBACIÓN

 FORMATO Código: FRM-AREQM02
Revisión: 01
Aprobado: Jefe OTI
Fecha: 05/09/2017
Plan de Gestión de Requerimientos Página: 9 de 9

Para dar la conformidad al presente documento, se requiere las firmas de las personas
indicadas a continuación:

ROGER MARCELO CONCHA VALDIVIA LEONARDO RODRÍGUEZ

______________________________ ______________________________
Gerente del Proyecto Coordinador del Proyecto
Empresa Proveedora de Software Cliente

ING. ROGER CONCHA VALDIVIA DR. JACINTO FERNANDEZ

______________________________ ______________________________
Jefe del Proyecto Líder Usuario
Empresa Proveedora de Software Cliente

ING. DANIEL CASTILLÓN GARCÍA DR. LUIS PÉREZ SANCHEZ

______________________________ ______________________________
Analista de Sistemas Usuario 1
Empresa Proveedora de Software Cliente

Lima, 25 de 05 de 2020.