G_ISO21500_Alc_P06_V1

PLAN DE GESTIÓN DE
REQUISITOS PAG. 1 DE 7

Código Identific. Proyecto PTY-SIGLO-XXI

TITULO DEL PROYECTO

Director del proyecto Persona Líder de proyecto

Departamento
Persona Líder de proyecto
APROBACIÓN
Firma

PLAN DE GESTIÓN DE REQUISITOS

METODOLOGÍA DE IDENTIFICACIÓN DE REQUISITOS

Se utiliza cuestionarios y entrevistas, además, la identificación se basa en los requisitos que
han sido expresados por escrito en la petición del cliente. Estos requisitos han sido definidos
de en la planilla de requerimientos

FUENTES Y ORÍGENES DE REQUISITOS

Los requisitos han sido expresados por escrito en la petición del cliente además de las
diversas entrevistas que sido llevadas a cabo para la aclaración de ciertos aspectos los cuales
se encontraban definidos de manera poco clara o ambigua.

TIPOS Y CATEGORÍAS DE REQUISITOS

 G_ISO21500_Alc_P06_V1
PLAN DE GESTIÓN DE
REQUISITOS PAG. 2 DE 7

Dentro del proyecto, se pueden identificar 2 tipos de requisitos:

Funcionales: Se define como requisito funcional las declaraciones de los servicios que
proveerá el sistema, de la manera en que éste reaccionará a entradas particulares.
No funcionales: Son aquellos requerimientos que no se refieren directamente a las funciones
específicas que entrega el sistema, sino a las propiedades emergentes de éste como la
fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento.
Para la priorización de los requisitos se utilizará la técnica de juicio de expertos La cual
consiste en considerar la pericia de los individuos o grupos que tengan conocimientos
especializados o capacitación en los siguientes temas:
 Análisis de negocios

 Recolección de requisitos

 Análisis de requisitos

 Documentación de requisitos

 Requisitos del proyecto en proyectos similares anteriores

 Técnicas de diagramación

 Facilitación

 Gestión de conflictos

TRAZABILIDAD

Tipo de
Nombre del Requerimiento Actores Descripción del
[R-N°]
requerimiento [Funcional, No relacionados requerimiento
funcional]
El sistema de
información
debe considerar
el rol de
administrador,
cliente, bodega,
finanzas y
1 Rol de usuario Funcional Administrator cocina
2 Gestionar Funcional Sistema El administrador
recursos podrá crear en
el sistema todos
los recursos que
el sistema
 G_ISO21500_Alc_P06_V1
PLAN DE GESTIÓN DE
REQUISITOS PAG. 3 DE 7

necesita para su
operación
(usuarios,
productos,
mesas, etc.).
Además será el
encargado de
realizar los
pedidos a los
proveedores y
llevar el control
del negocio en
todo momento.
El módulo de
bodega debe
ingresar y
controlar stock
3 Control de stock Funcional Administrador de productos.
El módulo de
finanzas debe
controlar los
ingresos y
egresos de
dinero además,
determinar la
Control de utilidad a nivel
4 finanzas Funcional Finanzas diario y mensual
En la cocina se
visualizará un
tablero de
Visualización de ejecución de
5 pedidos Funcional Cocina órdenes
6 Realizar Pedido Funcional Cliente El cliente
realizará el
pedido a través
de una
aplicación en
mesa, la cual
contiene la
información de
los diferentes
platos que se
ofrecen y sus
precios. El
cliente podrá
 G_ISO21500_Alc_P06_V1
PLAN DE GESTIÓN DE
REQUISITOS PAG. 4 DE 7

pedir productos
a través de la
aplicación en
cualquier
momento,
mientras se
mantenga
asignado a la
mesa
El sistema debe
considerar un
tótem que
asigne la mesa
al llegar el
cliente,
Asignación de dependiendo de
mesa según la disponibilidad
7 disponibilidad Funcional Sistema del restaurante
El sistema debe
avisar que se
encuentra listo
para pagar a
Notificación de Sistema / través de la
8 pago Funcional Cliente aplicación
El sistema debe
generar
informes de
resumen de
información
relacionado con
el rendimiento
financiero del
restaurante,
además de los
clientes
atendidos, los
platos
consumidos y la
medición del
Generar tiempo de
9 Informes Funcional Finanzas atención.
El módulo web
debe ser
Modelo de desarrollado
10 capas No funcional Sistema mediante el
 G_ISO21500_Alc_P06_V1
PLAN DE GESTIÓN DE
REQUISITOS PAG. 5 DE 7

patrón MVC
Para el módulo
de escritorio se
debe utilizar el
lenguaje C# o
Java mientras
que, para la
aplicación web
se debe utilizar
Python con el
framework
11 Lenguaje No funcional Sistema Django
Los métodos
CRUD deben
estar
implementados
mediante
procedimientos
almacenados
12 CRUD No funcional Sistema con PL/SQL
Los reportes
generados por
el sistema
deben
Formato considerar el
13 reportes No funcional Sistema formato pdf
Las claves
deben ser
enmascaradas
para que no
puedan ser
visualizadas por
14 Claves No funcional Sistema otro usuario
El sistema debe
considerar el
control de
sesiones para
evitar que un
usuario no
autorizado no
haga una acción
que no está
contemplada
Control de según el tipo de
15 sesiones No funcional Sistema usuario.
 G_ISO21500_Alc_P06_V1
PLAN DE GESTIÓN DE
REQUISITOS PAG. 6 DE 7

Las aplicaciones
deben
presentar
interfaz gráfica.
Se debe
considerar los
elementos de
diseño
incorporados en
las aplicaciones
16 Interfaz gráfica No funcional Sistema de Windows.
El motor a
Motor de base utilizar sebe ser
17 de datos No funcional Sistema Oracle
El sistema debe
contar con
manuales de
usuario para
Manuales de cada software
18 usuario No funcional Sistema desarrollado.
Los mensajes
Mensajes de deben ser claros
19 error No funcional Sistema e informativos.
El sistema debe
considerar las
validaciones tal
como campo de
Rut obligatorio,
20 Validaciones No funcional Sistema etc.
El sistema debe
poseer un
diseño
responsivo con
el fin de
garantizar una
visualización
adecuada según
Diseño el tipo de
21 responsivo No funcional Sistema dispositivo
1 Rol de usuario Funcional Administrador El sistema de
información
debe considerar
el rol de
administrador,
cliente, bodega,
 G_ISO21500_Alc_P06_V1
PLAN DE GESTIÓN DE
REQUISITOS PAG. 7 DE 7

finanzas y
cocina

METODOLOGÍA DE GESTIÓN DE CAMBIOS EN REQUISITOS

En primer lugar, se define como cambio todo aquello que modifique las limitaciones iniciales
del proyecto, las cuales estarán definidas en el plan del proyecto.
Para generar el cambio en el proyecto, se debe emitir una solicitud de cambio posterior a la
solicitud, se debe realizar una aprobación técnica del cambio. Si no se obtiene la aprobación
técnica, se cierra la solicitud, en cambio, si la solicitud técnica ha sido aprobada, se analiza el
impacto que tendrá el cambio en el proyecto. Una vez que se ha analizado el impacto, se
decide si el cambio es aceptado o rechazado. Si es rechazada, se cierra la solicitud, en cambio
si se aprueba se procede a realizar la modificación de la planificación para finalizar con la
aplicación del cambio solicitado.
La información se puede visualizar en el siguiente diagrama

PROCEDIMIENTO DE VERIFICACIÓN Y VALIDACIÓN

Los requisitos se validarán a través de prototipos, de esta manera, el cliente tendrá una visión
de lo que será el producto final y brindará una aprobación o rechazo. En caso de rechazo, se
deberá modificar según los cambios definidos por el cliente al momento de ser presentados.