Informe de especificación de requerimientos.

Presentado por:
NELSON CORREA ABRIL
CAROLINA CORREA PERDOMO
CARLOS ANDRES VELEZ HIDALGO
RUBEN DARIO WILCHES
JONNATHAN GARCIA OSPINA

Presentado a:
LUIS CARLOS OSSA GOMEZ

DIANA MARIA DE JESUS RICO MESA

Servicio Nacional de Aprendizaje SENA

Marzo de 2018
 Introducción.

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.

Existen tres formas de capturar los requerimientos: entrevistas, encuestas y auditorías.

En nuestro caso escogimos la auditoría, ya que la disponibilidad de los funcionarios de
NEXUS SERVICIOS TECNOLOGICOS es limitada, por lo que es probable que no
quieran enfrentar las dos primeras modalidades, o bien, no prestarles la debida atención.
Por otra parte, investigamos en Internet acerca de los tipos de control de inventario y sus
características y el hardware necesario para reconocer los productos. Expondremos en
detalle las actividades realizadas y las fuentes de Internet.

En este informe, una vez obtenidos los requerimientos, los clasificaremos de acuerdo
con el estándar de la IEEE, en funcionales y no funcionales. Justificaremos la importancia
de cada uno de ellos, para posteriormente ordenarlos jerárquicamente, de acuerdo con
el aporte de cada uno de ellos a la satisfacción del objetivo o la dependencia de unos
con respecto a otros. Hay que recalcar, por otro lado, que requerimientos que son
considerados en primera instancia como no funcionales, terminan siendo clasificados
como funcionales. 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.
 Contexto.

En este momento nos hallamos en la primera etapa del proyecto de software. Ya se

detectó un problema (situación A), al cual se le propuso una situación B (objetivo) que
acaba con él. Posteriormente, se propusieron algunas ideas para cumplir con dicho
objetivo, y para éstas se hicieron estimaciones en cuanto a su factibilidad, ya sea en
cuanto a la efectividad en cumplir el objetivo, el costo monetario y la demora en la
implementación. Luego, nos vimos en la obligación de reformular nuestro objetivo, ya
que las ideas planteadas no lo estaban cumpliendo a cabalidad. Una vez reformulado,
propusimos criterios de evaluación, los ponderamos y asignamos un puntaje a cada una
de las ideas, después de lo cual, surgió la definitiva.

Detectamos deficiencias en los sistemas de inventarios que emplean los locales

comerciales. Nos dimos cuenta de que no existe un respaldo con el cual contrastar los
resultados del inventario físico. Examinamos lo que ocurre en el Almacén de Nexus
servicios tecnológicos, aunque por el volumen de ventas y complejidad del proceso, nos
inclinamos a enfocar todo nuestro trabajo en esta última empresa.

Sin embargo, es imposible comenzar con el modelado de la arquitectura de software,

que son las etapas que prosiguen, si no se pasa por esta etapa, de análisis de
requerimientos, en que se investigan las necesidades del usuario. Estas deben ser
recogidas por nuestra propuesta de software, para que le sea realmente útil. Hay
requerimientos que son obvios, pueden ser propuestos desde fuera. Para obtener otros,
es necesario investigar en la web respecto al tema y ver, si existen otros proyectos
similares que tengan el mismo objetivo que nosotros. Finalmente, es necesario ir a
observar en terreno el proceso, en nuestro caso ir a la empresa, para examinar cómo se
registran las mercaderías y éstas son pasadas por cada una de las etapas previas a la
venta por caja.

Es importante destacar, que de aquí en adelante nos referiremos a los “productos” como
el conjunto de unidades que tienen definida una categoría, marca, peso y presentación
en común (ejemplo: “tarjetas de video, marca referencia, GIGAS.”, siendo todos aquellos
que cumplan dichas características, considerados como el mismo producto). Los
“artículos”, serán las unidades de cada producto contenidas en el stock. La unidad será
entendida como un grupo de diez.
 Desarrollo.

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 a ser de completa utilidad al cliente. Por esto debemos hacer
una 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.

Existen tres formas de capturar los requerimientos:

1.- Entrevistas : Consiste en realizar un cuestionario de necesidades a una persona de

jerarquía dentro de la empresa, en este caso, un almacén venta de suministros
electrónicos y de tecnología.
2.- Encuestas: Consiste en hacer un cuestionario a distintos niveles de la empresa, con
opciones prefijadas, acerca de sus necesidades).

3.- Auditorías: Corresponde a una inspección en terreno para observar cómo se ejecuta
un proceso.

También es factible discutir proponer requerimientos basados en las impresiones o

conocimientos de los integrantes del proyecto y buscar en Internet proyectos que
apunten al mismo objetivo o similar, para así poder capturarlos.

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

conocimiento e impresiones, en una reunión, que anteriormente ya se había realizado
Luego, investigamos acerca de proyectos similares al nuestro y averiguamos acerca de
qué sistema de control de inventario es el que estamos proponiendo, para conocer mejor
sus características, en otra reunión. 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 artículos de alto costo), sólo que no se lleva a
cabo un seguimiento a cada unidad en particular (se consideran todas las unidades de
un producto como “iguales”).
Fuentes:

- http://www.monografias.com/trabajos14/inventarios/inventarios.shtml
- http://mexico.smetoolkit.org/mexico/es/content/es/3546/%C2%BFGanas-o-
pierdesEstado-de-Resultados-

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 1D el que se emplea en
supermercados.

Fuente:

- http://www.tomadeinventarios.com/

Finalmente, llevamos a cabo una Auditoría el viernes 14 entre 12:30 y 13:30 hrs. En
ella observamos el flujo de mercadería entre bodega y sala de ventas, para así
descubrir necesidades. Fue obtenida previa petición al Encargado de Inventario, don
Miguel Sepúlveda.

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 una función que permita al administrador crear “packs” de productos,
registrando en la caja sólo un artículo, pero contando la totalidad (requerimiento funcional
N° 13). 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 a 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
físico debe buscar dentro del local para saber si todavía existen o declararlos 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
(Rebús), 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 dueños
de almacenes que los vuelven a vender, y se los vienen a comprar varios días después
de adquirirlos en el supermercado mayorista. 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.
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 de la 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 supermercado 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 es el último de la semana en que atiende “Nexus servicios tecnológicos.

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. Esta necesidad la
pudimos percibir ya que observamos que el administrador, algunas veces, se ausenta
del local para hacer trámites o almorzar. Además, en el caso que se vea en la obligación
de faltar un día a su empleo (por enfermedad o enviado por la empresa a la Casa ), y no
tenga alguien de confianza para dejar en su reemplazo, ésta es una buena alternativa
para no perder el control.

Luego, para poder tener clara la organización de los requerimientos, con el fin de poder
generar la arquitectura de software, es necesario ordenarlos de forma jerárquica. Esta
jerarquía puede ser con respecto a su influencia en la satisfacción del objetivo, de manera
descendente (desde el que más influye al que menos lo hace), o bien, de dependencia.
A veces ocurre, que, para cumplir con un requerimiento, se debe satisfacer con otro
primero. Así, se pueden ordenar de manera descendente, desde el que depende de
todos los posteriores, hasta el que no depende del cumplimiento de otros. De esta
manera, la jerarquización de los requerimientos antes expuestos, funcionales y no
funcionales queda de la siguiente forma:

Requerimientos funcionales.

El más importante, sin duda, es el siguiente, puesto que es el que satisface el objetivo
de generar un respaldo a los resultados del inventario físico:

1.- 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, defectuosos) de la
sala de ventas, para cada producto, tomando en cuenta los registros llevados hasta ese
momento.

Pero, el cumplimento de éste depende de estos otros:

1.1.- 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.

1.2.- 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.

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

1.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.
1.5.- 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”.

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

sala de ventas, por producto y con fecha.

El requerimiento 1.2 se lleva a cabo en el primer registro (llegada a bodega), el 1.3 en la

segunda (entre bodega y sala de ventas) y los 1.4, 1.5 y 1.6, en el tercer registro (salida
del local por cajas o por no estar en condiciones para ser vendidos). Por otro lado, 1.2
depende de éste:

1.2. 1.- 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).

También, para que el administrador pueda hacer uso de la función creada por 1.5., debe
cumplirse:

1.5.1.- 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.

Pero, para que se cumpla 1.5.1, deberán satisfacerse:

1.5.1.1.- Cada vez que se ingrese un nuevo producto, deberá leerse el código de barras,
ingresar detalle y sección.

1.5.1.2.- Cada vez que se saquen artículos de bodega, para reponer en sala de ventas,
se deberá descontar de los pedidos más antiguos.

Luego, los requerimientos que quedan, ordenados por su aporte al objetivo, son:

2.- Cuando se ingresen los datos del punto 1.5.1.1, deberá asignarse automáticamente
al nuevo producto un código interno del supermercado, que servirá para identificarlo
más fácilmente.

Como se observa, éste depende, a su vez, de 1.5.1.1.

3.- 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.

Requerimientos no funcionales.

Por orden de importancia, con respecto a su aporte a los deseos del usuario (adicionales,
que no tienen que ver con el objetivo, son:

1.- 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.

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

3.- 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.

4.- Las reposiciones de productos a la sala de ventas deberán indicar: fecha, hora y
cantidad.

5.- 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.

6.- 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.

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

8.- 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.

El requerimiento 1 no funcional depende del 1 funcional. El requerimiento 5 no funcional,

del 1.6 funcional. El requerimiento no funcional 6, del 1.2 funcional. El requerimiento 8
no funcional, del 1.1 funcional. Finalmente, el requerimiento 3 no funcional, depende de:

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

bodega (stock completo).
2.- Se deberá mantener registrado el porcentaje del stock en bodega bajo el cual es
necesario efectuar un nuevo pedido, para cada producto.

Pero, para que el administrador decida 3.1, debe conocer:

3.1.1.- 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.

A su vez, 3.2 depende de 3.1.1 y:

3.2.1.- 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.

3.2.1 requiere de:

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

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

Que a su vez necesita de:

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

pedido.
Conclusión.

En el momento de buscar los requerimientos, comenzamos con proposiciones generadas

por los integrantes del grupo. La experiencia laboral dentro de “NEXUS SERVICIOS
TECNOLOGICOS” obtenida por Sergio Rosas nos resultó valiosa para comprender el
flujo de mercaderías dentro del local. Sin embargo, como esto fue insuficiente, es que
decidimos investigar más en la web acerca de los tipos de control de inventario y efectuar
una Auditoría.

Al analizar cada uno de los requerimientos, y la justificación de cada uno, es posible

percatarse que requerimientos catalogados en un principio como “no funcionales”,
terminan siendo “funcionales”. Esto ocurrió con todos aquéllos necesarios para
determinar cuántos artículos por producto están por vencer. El conocer este dato, en
principio, no afecta la satisfacción del objetivo de nuestro proyecto de software (generar
un conteo de artículos que llegan a bodega, entran a sala de ventas y son finalmente
vendidos, para relacionarlos entre sí y generar una base de comparación con los
resultados del inventario físico). Sin embargo, en ocasiones el supermercado crea
“packs” entre artículos de distintos productos o de un mismo producto, cuando hay una
cantidad importante próxima a vencer. Como generar una función que permita lo anterior
es indispensable para mantener un conteo eficaz en caja, evitando que sólo se registre
un artículo del “pack”, es que todos los requerimientos para determinar la proximidad del
vencimiento de artículos pasan a ser “funcionales”.

A la hora de jerarquizar los requerimientos, es posible percatarse que muchos de ellos

dependen del cumplimiento de otros, y éstos, a su vez, de otros más. También, ocurre
que un requerimiento no funcional dependa de uno funcional, como ocurrió con el
requerimiento de generar estadísticas de las ventas por caja, del registro de los artículos
retirados por vencimiento durante el mes, entre otros. De esta manera, se termina
creando una red de dependencias entre muchos de los requerimientos.

Sin duda es esta red la que permite el desarrollo de un modelo de software usando UML.
Es la que se necesita para generar los diagramas de arquitectura estática, de casos de
uso y el modelado de datos.