INFORME DE EVALUACION DE LOS REQUERIMIENTOS

GA1- 220501092-AA5-EV02

PARTICIPANTES
Alexey Joset Payan Rentería
Mónica Cristina Suarez Ospina
Oscar Iván Useche Aguilar
Samuel Gómez Henao
Gabriela Melo Camargo

REGION VALLE DEL CAUCA

JUNIO 2023

VERSION DEL DOCUMENTO 20/06/2023

FICHA: 2721477
 INFORME DE EVALUACION DE LOS REQUERIMIENTOS

1. introducción
2. Alcance
3. Lista de requerimientos
3.1 Requerimientos Funcionales
3.1.1 Gestión de productos
3.1.2 Gestión de ventas
3.1.3 Gestión de clientes
3.1.4 Gestión de empleados
3.1.5 Gestión de caja
3.1.6 Gestión de proveedores
3.1.7 Gestión de inventario
3.1.8 Gestión de informes e informes
3.2 Requerimientos no funcionales
3.2.1 Usabilidad
3.2.2 Rendimiento
3.2.3 Seguridad
3.2.4 Escalabilidad
3.2.5 Mantenibilidad
3.2.6 Integración
3.2.7 Cumplimiento normativo
3.2.8 Disponibilidad
4. Caso de pruebas
 1. INTRODUCCIÓN

El presente documento de especificación de requisitos de software brindara a los

lectores una comprensión adecuada de las características mas relevantes de un
sistema de información que apoyara el funcionamiento, control, registro, y
optimización de la información que allí se maneja. Mediante este documento
pretendemos establecer la especificación de requisitos de software ERS, SRS,
aplicando la norma IEEE 830 al proyecto destacado en este caso un minimercado.

Un paso importante antes de iniciar cualquier tipo de modelo de arquitectura de

software es la captura y análisis de requerimientos. Es importante conocer en
detalle las necesidades del cliente, para que así el software realmente pueda
transformar una situación A, que conlleva un problema, a una situación B, que lo
soluciona. En caso contrario, puede no terminar con él, e incluso, agravarlo.

En nuestro caso escogimos la entrevista y encuesta, ya que la disponibilidad del

propietario de “FRESKITO’S” es limitada. Por otra parte, nos apoyamos en la
información suministrada en el material de trabajo para mantener el orden
estructural del prototipo de servicio o producto a prestar en tal proyecto a optimizar

Este informe, una vez obtenidos los requerimientos, los clasificaremos de acuerdo
al estándar de la IEEE 830.Esto, debido a que un requerimiento considerado en
primera instancia como funcional necesitaba que se cumpliesen algunos no
funcionales, de ahí el ajuste.
Una vez teniendo clara la organización de los requerimientos, podremos avanzar
hacia la siguiente etapa.
 2. ALCANCE

El siatema será definido como SACP (sistema de Administración de Clientes y

Proveedores)
Para poder generar un modelo de la arquitectura de software, una vez escogida la
solución con más méritos, es necesario conocer las necesidades y deseos del
cliente.
Sin este paso importante, sería inútil generar un modelo, ya que no tendríamos la
garantía de si el software va ser de completa utilidad al cliente. Por esto debemos
hacer un lista de requerimientos.

Los requerimientos pueden ser funcionales (son imprescindibles para satisfacer el

objetivo) o no funcionales (para cumplir con ciertas formalidades o necesidades
anexas que no están relacionadas con el objetivo.
 LISTA DE REQUERIMIENTOS
3.1 REQUERIMIENTOS FUNCIONALES

Para cumplir con esta función el sistema debe permitir que se realice lo siguiente:

RF1.Administrar clientes

Crear cliente: mediante un formulario se ingresarán los datos que corresponden a

la información de un nuevo cliente.
Consultar cliente: Por medio de esta función se podrá ver los clientes que ya han
sido registrados en el sistema y se podrá acceder a todos o a cada uno según la
necesidad del usuario.
Modificar Cliente: Esta función permite al usuario del sistema actualizar la
información de los clientes registrados.
Eliminar cliente: A través de esta función, el usuario del sistema podrá eliminarlos
registros de los clientes si así lo requiere.

RF2. Administrar proveedores

Para llevar a cabo esta función el sistema debe cumplir con lo siguiente:
Crear proveedor: Mediante un formulario se ingresarán los datos que
correspondan con la información de un nuevo proveedor.
Consultar proveedor: Por medio de esta función se podrá ver los proveedores,
con los que trabaja la microempresa, que ya han sido registrados en el sistema y
se podrá acceder a todos o a cada uno según la necesidad del usuario del
sistema.
Modificar proveedor: Esta función permite al usuario del sistema actualizar la
información de los proveedores registrados.
Eliminar proveedor: A través de esta función, el usuario del sistema podrá
eliminar los registros de proveedores si así lo requiere.
RF3. Administrar las ventas que se realizan en la microempresa

Se muestra el diagrama de actividades correspondiente al proceso de venta.

El cliente realiza una

El sistema No Se crea un nuevo
verifica si el
solicitud de venta registro de cliente
usuario esta
registrado

El usuario inicia el proceso El cliente da sus datos al

de venta usuario del sistema Si
Se añaden los datos del
cliente a la orden de venta

Se añaden los
productos a orden de
venta

El sistema realiza los

cálculos para efectuar la
venta

Se almacena los datos de venta El sistema emite en la base de datos se crea

en la base de datos factura un código único de
identificación
Para llevar a cabo con esta función se debe considerar que el sistema permita:
Generar venta: Esta función se llevará a cabo cada vez que el usuario del sistema
requiera registrar una venta.
Consultar venta: Por medio de esta función el usuario del sistema tiene acceso a
todas las ventas que han sido realizadas, en caso de que quiera consultar un
registro especifico, el usuario ingresará el código correspondiente al registro que
quiere encontrar.

Requerimientos no funcionales

RNF1.Lenguaje de Programación

El sistema se desarrollara en un Lenguaje de programación de alto nivel,

orientado a objetos. En este caso se ha escogido JAVA debido a todas las
características presentadas al inicio.
BNF2: Restricciones de funcionamiento
El

En nuestro caso, primero propusimos una lista de requerimientos en base a

nuestro conocimiento e impresiones, en una reunión con el dueño de la tienda
FRESKITO’S.

Así, pudimos conocer:

1.- Que nuestro sistema de apoyo al inventario físico es muy similar al inventario
perpetuo (se lleva un seguimiento de los artículos día a día, cuántos han
ingresado y se han vendido, utilizándose principalmente para todos los artículos ya
que la tasa comercial varia en algunos productos), sólo que no se lleva a cabo un
seguimiento a cada unidad en particular.

2.- El tipo de instrumentos necesarios para leer el código de barras, según las
necesidades del usuario. Éstos pueden ser fijos, semi- móviles y móviles. Además,
pueden leer distintos códigos de barras, siendo el primero el que se emplea en
minimercados.

Veamos el flujo de mercadería entre bodega y ventas, para así descubrir

necesidades. Fue obtenida previa petición al Encargado de Inventario, el señor
Carlos Fernando Ochoa.

De esta manera, llegamos a una lista de requerimientos, los cuales, divididos en

funcionales y no funcionales, junto con la justificación a su elección, son los
siguientes:
1.- Captura de código de barras mediante pistola láser.
La captura debe ser de esta forma, porque es la más segura para el control de la
información en tiempo real. Un ingreso del código en forma manual requiere un
tiempo mucho mayor, la incomodidad de leerlo en el producto, haciendo los
acomodos dentro del carro de transporte y esforzando la vista.
Aparte que los errores en el ingreso de datos serían enormes.

2.- El propietario debe tener, aparte de la pistola láser, un computador con pantalla
y teclado donde ingresar las características que contenga cada lote (artículos por
producto).

Este computador es necesario para registrar los ingresos a bodega de forma

agrupada. Como los pedidos por producto son generalmente grandes, sería
sumamente agotador ingresarlos al sistema uno por uno.

Así, se registra el lote una sola vez, leyendo el código de barras de un artículo de
cada producto, o bien, de la caja. Luego, se digita en el computador la cantidad y
la fecha de vencimiento.

3.- El sistema deberá ser capaz de ingresar cada nuevo pedido de un producto
indicando fecha de ingreso, fecha de vencimiento y la cantidad de artículos.
La justificación para la cantidad de artículos es la misma que la del requerimiento
anterior.
El ingreso de la fecha de vencimiento tiene que ver con varios requerimientos
adicionales con el fin de generar una función que permita al administrador crear
“packs” de productos, registrando en caja sólo un artículo, pero contando la
totalidad.
Esto es fundamental para que no se vendan artículos sin contar y estropear
nuestro sistema. La fecha de ingreso tiene que ver porque de esta manera se
fortalece la rotación de fechas de vencimiento de los productos manejo de las
buenas prácticas de manufactura y almacenamiento de los mismos evitando
contaminaciones cruzadas entre los artículos y la predominancia de el buen
estado de los alimentos en el caso de los perecederos y refrigerados teniendo en
cuenta que también se evidencia todos estos en los casos de devoluciones por
defecto del producto para efectuar la respectiva reposición de los mismos
mantenimiento preventivo y predictivo de los equipos de refrigeración en cuyo
caso sea necesario para la preservación de ciertos productos.

De esta manera, llegamos a una lista de requerimientos, los cuales, divididos en

funcionales y no funcionales, junto con la justificación a su elección, son los
siguientes:

Requerimientos funcionales.

1.- Captura de código de barras mediante pistola láser.

La captura debe ser de esta forma, porque es la más segura. Un ingreso del
código en forma manual requiere un tiempo mucho mayor, la incomodidad de
leerlo en el producto, haciendo los acomodos dentro del carro de transporte y
esforzando la vista. Aparte que los errores en el ingreso de datos serían enormes.

2.- El recepcionista (de bodega) debe tener, aparte de la pistola láser, un

computador con pantalla y teclado donde ingresar las características que
contenga cada lote (artículos por producto).
Este computador es necesario para registrar los ingresos a bodega de forma
agrupada. Como los pedidos por producto son generalmente grandes, sería
sumamente agotador ingresarlos al sistema uno por uno.
Así, se registra el lote una sola vez, leyendo el código de barras de un artículo de
cada producto, o bien, de la caja. Luego, se digita en el computador la cantidad y
la fecha de vencimiento.

3.- El sistema deberá ser capaz de ingresar cada nuevo pedido de un producto
indicando fecha de ingreso, fecha de vencimiento y la cantidad de artículos.
La justificación para la cantidad de artículos es la misma que la del requerimiento
anterior.
El ingreso de la fecha de vencimiento tiene que ver con varios requerimientos
adicionales con el fin de generar un función que permita al administrador crear
“packs” de productos, registrando en caja sólo un artículo, pero contando la
totalidad. Esto es fundamental para que no se vendan artículos sin contar y
estropear nuestro sistema. La fecha de ingreso tiene que ver un requerimiento no
funcional, que es determinar cuánto se demora en llegar un pedido desde que se
necesita.

4.- Se deberá ir registrando continuamente las mermas de cada producto

(artículos consumidos sin pagar dentro del local o rotos), tanto en bodega como
en sala de ventas.

Esto es para no alterar el conteo de artículos cuando salen de bodega o salen por
caja, porque, en caso contrario, el sistema los va a mostrar en la diferencia, y al
momento del inventario físico van tener que ser buscados inútilmente como
“extraviados”.

5.- Cada vez que se realice un inventario físico, el software deberá calcular la
diferencia entre los artículos que han ingresado (reposiciones) y salido (ventas,
mermas y vencimientos) de la sala de ventas, para cada producto, tomando en
cuenta los registros llevados hasta ese momento.
El mismo proceso para bodega.
Esta diferencia es la que es crucial obtener, a la hora de llevar cabo el inventario
físico.
Así se conoce la cantidad de artículos que no aparecen en el sistema y que el
inventario en físico debe buscar dentro del local para saber si todavía existen o
declararlos como pérdida.

6.- La base de datos deberá tener la opción de ser actualizada, en el caso de la

salida de un nuevo producto al mercado, o el retiro de alguno.
Esto es porque, se podría pretender llevar el registro de ingresos y salidas de un
producto que ya no existe, o bien, ingresar y vender un producto nuevo que el
sistema no va a reconocer.

7.- Cada vez que se ingrese un nuevo producto, deberá leerse el código de
barras, ingresar detalle y sección.
Importante, para que al momento que el sistema indique cantidad de productos
vencidos, por ejemplo, el administrador sepa de qué producto se trata (no tener
que estar viendo después, en una larga lista, a qué producto corresponde un
código).

8.- Cuando se ingresen los datos del punto 7, deberá asignarse automáticamente
al nuevo producto un código interno del supermercado, que servirá para
identificarlo más fácilmente.
Esto, porque la empresa que efectúa el inventario físico, entrega sus datos
clasificados mediante este código interno, también llamado SKU.

9.- La cantidad de artículos por producto en bodega y sala de ventas deberá ser
actualizada cada vez que se lleve a cabo un inventario físico, con los datos que
éste arroje. No debe ocurrir lo mismo con estadísticas de ventas, promedios de
tiempo de demora en llegada de pedidos y vencimientos.
Se deben “resetear” las cantidades de artículos debido a que el objetivo de
nuestro software es generar un respaldo al inventario físico. Si se llega a la
conclusión de que faltan artículos, el inventario físico es el que va determinar su
paradero, por lo que una vez terminado, el sistema debe partir a contar desde
cero, sin mostrar diferencias entre los conteos (porque ya se han confirmado).

10.- Se deberá ir registrando continuamente los artículos que ya estén vencidos en

sala de ventas, por producto y con fecha.
Este requerimiento tiene la misma importancia que el que exige el registro de las
mermas, para que no se retiren sin contar y estropeen el conteo de salida por caja.
También, este requerimiento es necesario para que se cumpla uno no funcional
(entregar a fin de mes el porcentaje de artículos por producto que han vencido en
sala de ventas, con respecto al total de ingresados).

11.- Cada vez que se saquen artículos de bodega, para reponer en sala de ventas,
se deberá descontar de los pedidos más antiguos.
Esto, porque los artículos se almacenan en bodega de tal forma, que los pedidos
más antiguos son los primeros que se venden. Así, se lleva un conteo correcto de
los artículos por pedido que quedan en bodega, si los pedidos más antiguos se
han terminado, y en caso de que esto no haya ocurrido, determinar la cantidad de
unidades próximas a vencer.

12.- Si de un pedido registrado, aún quedan artículos y quedan 15 días para que
Venzan, se deberá avisar al final del día, indicando producto y cantidad que queda
del pedido.
Este plazo se debe a que los productos no se pueden vender en una fecha más
cercana a su vencimiento, debido a que muchos de los compradores son del
vecindario y pretendemos mantener los altos estándares de calidad, bienestar y
cuidado de la salubridad de mercancía alimenticia a comercializar.
Este aviso se debe generar para que el administrador del local haga ofertas con
dicho producto y lo saque a sala de ventas, para que se acabe pronto.

13.- El administrador debe poder ordenarle al sistema que, cada vez que se venda
un producto por caja, descontar de sala de ventas dos o más artículos de éste.
Esta función se llamará “registrar pack”, y deberá pedirle al usuario que ingrese el
código de producto, cantidad total de artículos que se venderán como “packs” y
cuántos artículos contendrá un “pack”.

Esta función se debe crear para considerar este tipo de ofertas que realizan los
supermercados, y de esta forma, no alterar el correcto conteo de artículos por
producto una vez que pasen por caja. En caso contrario, se va a contar sólo una
unidad, cuando en realidad salieron más de una.

Este tipo de ofertas las realizan los supermercados cuando los artículos llevan
mucho tiempo en bodega y están próximos a vencer.

Entendiendo que lo términos de los requerimientos funcionales son las

características y funcionalidades específicas que se describen para que un
software para un mini mercado cumpla:

1 Gestión de productos:

 Registro y actualización de productos en inventario

 Categorización de los productos (por tipo, marca, etc)
 Control de precios y promociones
 Manejo de información de proveedores
2 Gestión de ventas :
 Registro y seguimiento de ventas realizadas
 Cálculo automático de subtotal, impuestos y total de venta
 Generación de facturas o recibos para los clientes
 Posibilidad de aplicar descuentos y promocione
3 Gestión de clientes:
 Registro de información básica de los clientes (nombre, dirección ,teléfono,
correo electrónico, etc.)
 Creación de perfiles de clientes para ofrecer promociones personalizadas
 Registro de historial de compras de cada cliente
4 Gestión de empleados:
 Creación de perfiles de empleados con diferentes niveles de acceso
 Asignación de roles y permisos
 Registro de horarios y control de asistencia
5 Gestión de caja:
 Registro de ingresos y egresos en efectivo
 Cálculo de saldo y arqueo de caja
 Generacion de informes y cierre de caja
6 Gestión de proveedores:
 Registro de información de proveedores ( nombre, dirección, número de
teléfono, correo electrónico,etc,)
 Control de compras a proveedores
 Generación de ordenes de compra
7 Gestión de inventario:
 Control de stock de productos
 Notificación de niveles bajos de inventario
 Actualización automática de inventario al realizar ventas o compras
8 Reportes e informes:
 Generación de informes de ventas, ingresos, egresos, inventario, entre
otros
 Visualización de estadísticas y gráficos sobre el rendimiento del mini
mercado
 Requerimientos no funcionales.

1.- Los lectores de código de barras deben ser inalámbricos y omnidireccionales.

Estas características tienen como objetivo evitar que el cable les estorbe a los
reponedores en el momento de registrar los productos. También, han de ser
omnidireccionales para reconocer el código desde cualquier dirección.

2.- El sistema deberá ingresar, automáticamente, la fecha de llegada de cada

pedido.

3.- Es necesario un registro de todas las diferencias obtenidas, por producto,

correspondientes a los días entre la detección del a necesidad de un pedido y su
llegada a bodega, durante los últimos 6 meses.

4.- Se deberá mantener un registro, para cada producto, de la cantidad de días

que se demora en llegar un pedido a bodega, desde que se necesita, más dos
días por eventuales atrasos. Esta información se obtendrá promediando la
información actualizada descrita en el punto 3.

Los requerimientos 2 al 4 han de cumplirse, para así conocer la demora estimada

de un pedido entre que se necesita y su llegada. Se ha de registrar dicha demora
para cada producto, ya que ésta puede variar, puesto que el minimercado solicita
aprovisionamientos a distintas empresas, dependiendo del rubro. Estos tres
requerimientos podrían haberse agrupado en uno solo, pero se separaron para
comprenderlos mejor.
5.- Se deberá entregar, cuando se lleve a cabo el inventario físico, una estadística
de ventas para cada producto, utilizando el registro histórico. Se deberá indicar el
promedio de ventas para cada uno de los días de la semana (promedio de ventas
los días lunes, martes, etc.), para cada una de las semanas de un mes (primera,
segunda, tercera y cuarta) y para cada mes.

Estas estadísticas las requiere el administrador del local, para determinar si existe
una relación entre un día en especial de la semana, una semana en particular o un
mes determinado, con el incremento de la venta de un producto. Dichas
conclusiones son necesarias para fijar el porcentaje del stock bajo el cual se ha
solicitar un nuevo pedido.

6.- Se deberá mantener registrado el porcentaje del stock en bodega bajo el cual
es necesario efectuar un nuevo pedido, para cada producto. Éste se calculará
tomando en cuenta el promedio histórico de tiempo de llegada del pedido y el
promedio de ventas de dicho producto la misma semana el año anterior. Si no
existe registro del año anterior, se tomará en cuenta el promedio de ventas de la
misma semana del mes anterior. Si no, el promedio de ventas de la semana
anterior.
Es pertinente, ya que estos parámetros varían de un producto a otro, aún en un
mismo día (por ejemplo, en Semana Santa se venden más huevos de chocolate
que en ninguna otra época del año, pero menos carne que en ninguna otra).

7.- Ingresar en la base de datos la cantidad establecida para cada producto en

bodega (stock completo).

Es necesario conocer este valor, para así poder aplicarle el porcentaje bajo el cual
se necesita un nuevo pedido.
8.- Impresión al final del día, de un listado de todos los productos que hayan
traspasado el porcentaje bajo el cual es necesario hacer un nuevo pedido,
indicando la cantidad que debe tener.

Esto le permite al administrador tener con claridad la nómina de productos que

requieren pedidos y no tener que revisar miles de productos, uno por uno, viendo
si los necesitan.

9.- Cuando el administrador desee analizar los conteos históricos de la sala de

ventas y de la bodega, para compararlos con los resultados del inventario físico,
deberá ver 3 columnas. Una corresponderá a la suma de las reposiciones, otra a
la suma de ventas, mermas y vencimientos y otra con la diferencia entre las dos
anteriores, para cada producto.

Esto, para visualizar mejor dicha diferencia, que corresponde a los artículos que
no aparecen en el sistema y “deberían” estar en alguna parte del local.

10.- Las reposiciones de productos a la sala de ventas deberán indicar: fecha,

hora y cantidad.
Con estos datos, se fija la remuneración a cada uno de los reponedores.

11.- La actualización de la base de datos, con respecto a los productos que

entran o salen del mercado, deberá llevarse a cabo los días sábado.
Se llevará a cabo ese día, porque se estima como posible último de la semana en
que atiende actualización de productos llevados por los proveedores a el
establecimiento comercial “FRESKITO’S”.

12.- Cada mes, el último día, se le deberá entregar al administrador un listado de

todos los productos, indicando la cantidad de pedidos que se han hecho de cada
uno de ellos.
13.- Se deberá llevar un conteo mensual de los artículos que vencen en sala de
ventas, para cada producto. El último día del mes se debe entregar un listado con
dichos conteos, expresados en porcentaje con respecto al número total de
artículos por producto ingresados a sala de ventas.

Los requerimientos 12 y 13 los necesita el administrador para conocer si acaso el

stock que mantiene en bodega para un producto es demasiado grande para su
nivel de ventas. También se podrían reunir estos dos requerimientos en uno solo,
pero se separaron para su mejor comprensión.

14.- Se deberá acceder a este sistema vía web y con contraseña.

Los requerimientos no funcionales son los atributos de calidad que se espera
cumpla un software más allá de sus funcionalidades específicas.
1 Usabildad:
 Interfaz intuitiva y fácil de usar para los empleados
 Diseño responsable, adaptable a diferentes dispositivos ( computadores,
tablets, smartphones)
 Soporte para múltiples idiomas, si es necesario
 Tiempos de respuesta rápidos para evitar retrasos en las operaciones
2 Rendimiento:
 Respuesta rápida para el sistema, incluso en momento de alta carga
 Capacidad para manejar una gran cantidad de productos y transacciones
sin degradar el rendimiento
 Tiempos de carga reducidos para minimizar la espera del usuario
3 Seguridad:
 Acceso seguro y controlado mediante autenticación y autorización
 Protección de datos personales y confidenciales de clientes y empleados
 Respaldo regular de los datos y posibilidad de recuperación en caso de
fallas
4 Escalabilidad:
 Capacidad de crecimiento y adaptación a medida que el negocio se
expande
 Posibilidad de añadir nuevos módulos o funcionalidades en el futuro sin
afectar la estabilidad del sistema

5 Mantenibilidad:
 Código limpio y modularizado para facilitar la comprensión y el
mantenimiento
 Documentación clara y actualizada del software y sus componentes
 Facilidad para realizar actualizaciones y correcciones de errores
6 Integración:
 Capacidad para integrarse con otros sistemas o herramientas utilizadas en
el minimercado como sistemas de contabilidad o sistemas de pago
 Compatibilidad con los estándares y protocolos de comunicación relevantes
7 Cumplimiento Normativo:
 Cumplimiento de las regulaciones y normativas locales aplicables al
negocio, como protección de datos y facturación
8 Disponibilidad:
 Alta disponibilidad del sistema, minimizando tiempos de inactividad no
planificados
 Plan de contingencia y recuperación ante posibles fallas o desastres
 4. CASO DE PRUEBA
FORMATO CASOS DE PRUEBA
OBJETIVO DE CASO DE PRUEBA
IDENTIFICADOR
NOMBRE O IDENTIFICADOR
REQUERIMIENTO
PRECONDICIONES
PASOS
1. entrar a la aplicación
2. ver todos los productos que tenemos
3. revisar las alarmas de stock
4. revisar por categorías los productos
El objetivo de este caso de prueba es realizar
una aplicación o una web la cual nos mande
notificaciones cada que un producto este
agotado y podamos ver los productos que
tenemos y cuantos tenemos.
Número 4.
DEL Aplicación para encargado de inventario por
falta de stock.
Tiene que mandar notificaciones y mostrar los
productos con los datos que tenga.
RESULTADOS ESPERADOS
1. la aplicación al ser iniciada deberá de
llevarnos a la pantalla principal.
2. la aplicación debe de mostrar una lista de
los productos que hay con su respectiva fecha
de vencimiento y cuantos hay en ese
momento.
3. habrá un botón que nos indicara que
productos están faltos de stock según el
número mínimo que debe tener cada
producto.
4. habrá un selector por categorías para 3
tipos de productos y estos serán productos de
aseo, productos de alimentos (empacados) y
productos de alimentos (no empacados).
FORMATO CASOS DE PRUEBA
OBJETIVO DE CASO DE PRUEBA El objetivo de este caso es poder dar crear
anillos de seguridad para los empleados hasta
con el menor anillo de seguridad que seria el
gerente con todos los privilegios y el mayor
anillo de seguridad que seria un empleado con
muy pocos privilegios
IDENTIFICADOR Número 5.
NOMBRE O IDENTIFICADOR DEL Aplicación para el jefe y empleado capaz de
REQUERIMIENTO dar y quitar permisos y diferentes niveles de
accesos a todo el personal de trabajo.
PRECONDICIONES Tiene que poder quitar y asignar permisos a
los diferentes tipos de empleados
PASOS RESULTADOS ESPERADOS
1. iniciar la aplicación y registrarse en ella
2. Acceder a la pantalla principal
2. escoger la selección de empleados que
queremos
3. quitar y poner accesos en las diferentes
categorías
5. dar privilegios específicos
1. la aplicación al ser iniciada nos pedirá que
rellenar una solicitud de datos que son el
nombre, cargo y contraseña.
Se nos mostrara por grupo todos el personal
de la empresa en ese momento
2. habrá un selector para poder seleccionar la
categoría de los empleados y en que están a
cargo como lo son personal, jefes y sub jefes
3. cuando se desea dar o quitar un acceso a un
empleado o jefe se dará clic en su portada y
esta dirá ascender y nos dirá los privilegios de
obtendrá o si lo queremos quitar del puesto
en el que esta. La aplicación solo nos dejará
colocar un jefe y un sub jefe por categoría por
lo tanto no nos permitirá darle a todo el
mundo subir de puesto si ya esta alguien con
ese puesto
4. dentro del mismo perfil del trabajador en el
que estemos nos permitirá dar un privilegio
especifico a un empleado.
FORMATO CASOS DE PRUEBA
OBJETIVO DE CASO DE PRUEBA
IDENTIFICADOR
NOMBRE O IDENTIFICADOR
REQUERIMIENTO
PRECONDICIONES
PASOS
1. entrar a la aplicación
2. escoger el informe que queramos ver
3. realizar una actualización al informe
4. ver el grafico de barras de un informe
Crear una aplicación que genere informes de
venta para poder llevar un control de la tienda
por días semanas y meses.
Número 2.
DEL Aplicación para el administrador de informes
de ventas de la tienda.
Tiene que generar informes de las ventas por
días, semanas y meses.
RESULTADOS ESPERADOS
1. la aplicación al ser iniciada deberá de
llevarnos a la pantalla principal.
2. la aplicación tendrá un selector de opciones
en el cual el usuario puede escoger entre
informe del dia, informe de la semana y
informe del mes
3. habrá un botón que actualice la aplicación
para que entren nuevos datos y quede
registrado en el informe ya se en el que se
lleve del dia o de la semana o mes
4. la aplicación también deberá de mostrar un
grafico de barras del informe que se solicite
según la fecha en el apartado de “grafico de
barras”
FORMATO CASOS DE PRUEBA
OBJETIVO DE CASO DE PRUEBA Crear una tienda virtual de la tienda para
poder que el usuario mire nuestros productos
y pueda saber que productos tenemos y si hay
promociones en dichos productos.
IDENTIFICADOR Número 3.
NOMBRE O IDENTIFICADOR DEL Aplicación para usuarios para visualizar la
REQUERIMIENTO tienda virtualmente.
PRECONDICIONES Se tiene que ver los productos que estén es en
stock y los productos que tengan promociones
PASOS RESULTADOS ESPERADOS
1. entrar a la aplicación 1. la aplicación al ser iniciada deberá de
llevarnos a la pantalla principal.
2. el usuario podrá visualizar todos los 2. la aplicación debe de mostrar los productos
productos que se tengan en la tienda por por fases los productos con descuentos en 3
categorías fases productos de aseo, alimentación, y
alimentación (no empacado), y después podrá
seguir viendo todos otros los productos por
sus categorías o seleccionar solo una opción y
mostrar esos productos seleccionados.
3. el usuario podrá seleccionar el producto y 3. cada producto debe de tener un perfil y
ver a cuanto esta si tiene o no promoción y dentro de este podrá visualizar el titulo del
una descripción del producto producto, costo del producto, si tiene o no
promoción y una descripción del producto.
4. acceder al menú y seleccionar el apartado La aplicación tendrá un menú en el cual
que quiera ver podremos escoger entre 4 opciones las cuales
serán principal, aseo, empacado y
alimentación.