INSTITUTO TECNOLOGICO SUPERIOR

DE ALVARADO – Campus Medellín

INGENIERÍA EN
SISTEMAS COMPUTACIONALES

Materia:
Fundamentos en Ingieneria de Software.

Semestre - Grupo - Sistema:

5° Semestre - SABATINO .

Producto Académico:
“Documento de Requerimientos”.

Presenta:
José Manuel López Hernández
Edwin Gillmar Chigo Ricarte
Moisés Cervantes Domínguez
Sergio Daniel Galván Cruz
Guillermo Jiménez García

Docente:

I.S.C Fernando Mayorga Guittins.

MEDELLIN DE BRAVO, VER. Agos. – Ene. 2014

 Planteamiento del problema
Debido a la falta de administración de los productos vendidos por Abarrotes
Veracruzana, es necesario contar con un sistema de ventas de fácil uso así con una
curva de aprendizaje muy ligera es por ello que dicho software contara con una
interfaz de usuario minimalista y con bajos requisitos de hardware para evitar que
su ejecución sea lenta y así se pueda maximizar la productividad de los empleados.

Abarrotes Veracruzana

Necesita

Sistema de Ventas

Prevenir Requiere

Problemáticas Inventario

Evitar

Fuga de
Mercancía
1. Estudio de factibilidad

1.1 FACTIBILIDAD TÉCNICA:

Para la realización del proyecto son necesarios algunos recursos tecnológicos que
no corresponden precisamente a un proceso de desarrollo, pues el mercado los
ofrece a costos razonables y de buena calidad.
Para el desarrollo del proyecto, iniciando con el estudio de factibilidad técnica
encontramos que existen por lo menos dos alternativas de implementación, para las
cuales los requerimientos son los siguientes:

1.1.1 ALTERNATIVA 1

Consiste en construir un software el cual tendra como fin automatizar el control de

ventas e inventarios de una tienda de abarrotes o cualquier microempresa, los
requisitos son los siguientes:

• Pc de escritorio.
• Servicio de internet.
• un modem y un router.
• Multifuncional.
• Software y licencias
• Ups.

1.1.2 alternativa 2.

De otro modo el sistema podría estar alojado en un servidor, y no en una sola

estación de trabajo, las estaciones de trabajo podrán acceder al servidor mediante
un programa cliente que permita trabajar de manera distribuida en una cadena de
tiendas; de manera que los recursos necesarios son los siguientes:

• Servidor
• Pc’s de escritorio
• Conexión a internet
• Módems y Router.
• Multifuncional.
• Software y licencias
• Ups

1.2. Factibilidad económica:

Dado que se planteó dos (2) posibles alternativas en el estudio de factibilidad,
igualmente se establecen dos alternativas económicas, correspondiente a cada una
de las anteriores
1.2.1 alternativa 1

En cuanto a los costos de recursos de hardware a adquirir, tenderemos en

cuenta los siguientes: (costos dados en pesos mexicanos)

Dispositivos Cantidad Precio(1) Subtotal

Computadores de desarrollo 2 30,000 60,000

Servicio de internet Mensual(12m) 400 4,800

MULTIFUNCIONAL 1 12,000 1,200

MODEM 1 0 0

HUB 1 100 100

UPS 2 1250.000 2,500

CABLEADO 50 METROS 400 800

TOTAL 67,150.00
(PESOS)

En cuanto al software:

Software/ licencia Cantidad Precio(1) Subtotal

Sistema operativo para pc’s 2 2500 5,000

Suite de aplicaciones de 2 3500 7,000

escritorio
Total (pesos) 12,000.00

1.2.2 alternativa 2
 Dispositivos Cantidad Precio (1) Subtotal

Servicio de internet Mensual(12m) 400 4,800

Computadores de 2 30,000 60,000

desarrollo

Multifuncional 1 1,200 1,200

Ups 2 1250 2,500

Cableado 50 metros 8 800

Servidor 1 12,000 12,000

Total (pesos) 81,300.00

En cuanto al software:

Software/ licencia Cantidad Precio(1) Subtotal

Sistema operativo para 1 12000 1,2000

servidor
Sistema operativo para pc’s 2 2500 5,000

Suite de aplicaciones de 2 3500 7,000

escritorio
Total (pesos) 21,000.00

(1) aproximaciones de los precios, según las tendencias del mercado de

hardware y del software, sujetas a modificaciones.

1.2.3 COSTO MENSUAL DE RECURSOS HUMANO

Personal Cantidad Precio Precio

Ingenier@ de 1 $ 50,000 $ 50,000

proyecto
Programadores 2 $25,000 $50,000
Secretari@ 1 $ 5,000 $ 5,000
 Asistentes técnicos 2 $ 6,000 $ 12,000

Total (pesos) $ 117,000

1.2.4. GASTO MENSUAL (OTROS).

Cuentas Precio

Papelería $500.000

Luz eléctrica $1,000.000

Agua $100.000

Teléfono $400.000

Arriendo $2,500.000

Insumos de oficina $ 550.000

Total $ 5,050.00
(pesos)

1.3.2. REQUISITOS ESTÁNDAR

1.3.2.1 ALTERNATIVA 1

RESUMEN ESPECIFICACIONES TÉCNICAS PARA PC´S

Características pc tipo Configuración base

clon
Marca, modelo, referencia Especificar, torre o minitorre
Tipo de procesador Pentium de 3.0 GHz o superior
Motherboard Tecnología Intel
Memoria RAM 1 Gb (1dimm ddr3) expa. A 4 Gb
Memoria cache 1 Mb
Arquitectura bus 1666 MHz
Disco duro 80 Gb o superior
Controladora de disco Sata
 64 Mb (se acepta
Tarjeta de video Compartida, especificar si no lo
Monitor 17 ” es)
LCD o LED
Bahías Mínimo 2 libres
Slots Mínimo 2 libres
Puertos (mínimos) 1 serial 1 paralelo 1 para video 4
USB 1
Rj45 10 /100 1 ps2 para teclado

Teclado Español / ps2 o USB

Mouse Óptico USB o ps2

Tarjeta de red 10/100/1000 Mbps o superior

Software preinstalado licenciado Windows 8

ALTERNATIVA 2:
RESUMEN ESPECIFICACIONES TÉCNICAS PARA EL SERVIDOR

Especificaciones técnicas mínimas

Servidor Requeridas
Información general
Sistema operativo Microsoft Windows Server Standard 2012
Tipo de chasis Tipo torre
Fabricante Hp
Familia Proliant
Modelo Ml 10 xenón e3-1220
Cantidad 1
Precio sin IVA (MXN$) 8,820
Precio con IVA (MXN$) 10231.20
Arquitectura
Bus del sistema 1666 MHz
Procesador
Cantidad 1
Tipo Intel® Xenón e3-1220
Marca Intel®
Familia Xenón
 Velocidad 3.1ghz
Caché -
Memoria
Capacidad instalada 2 Gb de memoria

Tipo de memoria DDR3

Máxima instalable 4 Gb
Almacenamiento
Disquetera Opcional
Unidad optica #1 Combo CD-RW/DVD-RW
Discos duros internos
Cantidad 1
Capacidad por disco 2 TB
Velocidad 7200 rpm
Tecnología Sata
Configuración Básica
Fabricante y modelo Segate
Vídeo
Tipo Tarjeta gráfica integrada
Memoria de video 64 Mb o superior

RESUMEN ESPECIFICACIONES TÉCNICAS PARA PC´S

Características pc
tipo clon Configuración base
Marca, modelo, referencia Especificar, torre o minitorre
Tipo de procesador Pentium de 3.0 GHz o superior
Motherboard Tecnología Intel
Memoria RAM 1 GB (1dimm ddr3) expa. A 4 Gb
Memoria cache 1 Mb
Arquitectura bus 1666 MHz
Disco duro 80 Gb o superior
Controladora de disco Sata
64 Mb (se acepta
Tarjeta de video Compartida, especificar si no
Monitor 17lo” LCD
es) o LED
Bahías Mínimo 2 libres
Slots Mínimo 2 libres
 Puertos (mínimos) 1 serial 1 paralelo 1 para video 4
USB 1
Rj45 10 /100 1 ps2 para teclado

Teclado Español / ps2 o USB

Mouse Óptico USB o ps2

Tarjeta de red 10/100/1000 Mbps o superior

Software preinstalado licenciado Windows 8

El desarrollo del estudio de factibilidad operativa comprende una probabilidad de

que el nuevo sistema que se use se implemente como se supone. Para tal hecho
se debe considerar algunos aspectos de la factibilidad operacional. Primero, un
nuevo sistema puede ser demasiado complejo para los usuarios operadores del
sistema. Si llegase a serlo, los usuarios pueden ignorar el sistema o bien usarlo en
tal forma que cause errores o fallas en el sistema.

Segundo, un sistema puede hacer que los usuarios se resistan a él como

consecuencia de una técnica de trabajo, miedo a ser desplazados, intereses en el
sistema antiguo u otras razones. Para cada una de estas alternativas se debe
explorar con cuidado la posibilidad de resistirse al cambio al nuevo sistema. Tercero,
un nuevo sistema puede introducir cambios demasiado rápido para permitir al
personal adaptarse a él y aceptarlo. Un cambio repentino que se ha anunciado,
explicado y “vendido” a los usuarios con anterioridad puede crear resistencia.

Sin importar qué tan atractivo pueda ser un sistema en su aspecto económico si la
factibilidad operacional indica que tal vez los usuarios no aceptarán el sistema o que
su uso resultará en muchos errores o en una baja en la moral, el sistema tal vez no
debe implantarse para evitar causar malestar en el desarrollo de las actividades de
la empresa.

Desde el punto de vista operativo, creemos que el impacto del nuevo sistema sobre
las microempresas en las cuales será aplicado el sistema de será positivo y sin
grandes trabas debido a:

En primera instancia, la idea surge de una necesidad detectada en la administración

de ventas de una microempresa, por lo cual, éste sistema se enfoca a resolver un
problema concreto y que fija un punto de partida a la resolución de los problemas
por ellos planteado.
Habiendo elaborado un detallado análisis de cada uno de los aspectos relacionados
con la parte técnica, económica y operacional del estudio de factibilidad, podemos
concluir que el proyecto es posible de desarrollar y teniendo en cuenta que los
recursos que se requieren son de fácil adquisición, se puede determinar que el
proyecto es factible en su implementación.

ESTUDIO DE MERCADO
Definición del producto. Desarrollaremos un programa que permita manejar,
controlar, administrar y verificar los principales aspectos de una microempresa,
enfocado primordialmente al control de inventarios y administración de impuestos,
los cuales son relacionados a la gestión de la microempresa ya que estos pueden
causar algún tipo de impacto en su operación y que además deben de ser
controlado

Análisis de la demanda. En el ámbito laboral y regional, se destaca la necesidad

de desarrollar e implementar un software que permita manejar, controlar,
administrar y verificar los aspectos de una microempresa. El mercado del software
no se expone una aplicación que se pueda adecuar a las necesidades de los
usuarios y además poder establecer los costos de adquisición, implementación y
mantenimiento de dicho programa. Dentro del proceso de búsqueda de aplicaciones
con algunas empresas interesadas se pudo determinar la existencia de módulos
específicos para algunas de las necesidades con algunos inconvenientes como son
el idioma, el costo, la aplicabilidad, el mantenimiento, las asesorías y el contacto
con los distribuidores, entre otras.

Análisis de la oferta. A nivel regional no se ha encontrado oferta de software y/o

aplicaciones que se adecuen a las necesidades planteadas por los usuarios en el
desarrollo de un proyecto que implemente los aspectos principales de la
administración de una microempresa.

Nosotros entraremos a presentar una oferta a microempresas que así lo requieran,

se estima en implementar una cantidad racional de la primera versión teniendo en
cuenta que trabajaremos con base en la información y requerimientos de una
empresa.

Comercialización del producto.

La comercialización de nuestro producto se hará a nivel de consumidor, teniendo

en cuenta que se realizará las presentaciones a las microempresas que así lo
requieran. Con un punto de distribución y con el apoyo promotor se dará a conocer
el producto, manejando un aspecto muy importante en el ramo de las ventas, la
publicidad y el servicio al cliente.
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, mermas y vencimientos) 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án 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).
3.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.
Casos de Uso
NOMBRE DE ARCHIVO: PRODUCTO FECHA DE CREACION: 30-09-14

DESCRIPCION: ARCHIVO PRINCIPAL PRODUCTO, CONTENDRA INFORMACION DE ESTOS

CAMPO TIPO TAMAÑO DESCRIPCION

ID_PRODUCTO NUMERICO 10 CLAVE DE PRODUCTO

NOMBRE CARACTER 50 NOMBRE DE PRODUCTO

DESCRIPCION CARACTER 50 RESEÑA DEL PRODUCTO

STOCK NUMERICO 10 CANTIDAD DISPONIBLE

FECHA_CREADO FECHA N/A FECHA DE LOTE

FECHA_VENCIMIENTO FECHA N/A FECHA DE CADUCIDAD

PRECIO_COMPRA NUMERICO 10,2 PRECIO AL PUBLICO CON 2

DECIMALES FRACIONARIOS

PRECIO_VENTA NUMERICO 10,2 PRECIO DE COMPRA CON 2

DECIMALES FRACCIONARIOS

RELACIONES: tblCategoria, tblDetalleVenta

CAMPOS CLAVE: ID_PRODUCTO

NOMBRE DE ARCHIVO: CATEGORIA FECHA DE CREACION: 30-09-14

DESCRIPCION: ARCHIVO PRINCIPAL DE CATEGORIAS DE PRODUCTOS, CONTENDRA INFORMACION DE ESTAS

CAMPO TIPO TAMAÑO DESCRIPCION

ID_CATEGORIA NUMERICO 10 CLAVE DE CATEGORIA

DETALLES CARACTER 50 DETALLE DE CATEGORIA

RELACIONES: tblProducto

CAMPOS CLAVE: ID_CATEGORIA

NOMBRE DE ARCHIVO: VENTA FECHA DE CREACION: 30-09-14

DESCRIPCION: ARCHIVO PRINCIPAL DE VENTAS, CONTENDRA INFORMACION DE ESTAS

CAMPO TIPO TAMAÑO DESCRIPCION

ID_VENTA NUMERICO 10 CLAVE DE PRODUCTO

FECHA_VENTA FECHA N/A FECHA DE VENTA

NUM_DOC NUMERICO 10 NUMERO DE DOCUMENTO

TIPO_DOC BOOLEAN N/A SELECCIONA EL TIPO DE DOC

RELACIONES: tblDetalleVenta

CAMPOS CLAVE: ID_VENTA

NOMBRE DE ARCHIVO: DETALLE_VENTA FECHA DE CREACION: 30-09-14

DESCRIPCION: ARCHIVO PRINCIPAL DETALLE DE VENTA, CONTENDRA INFORMACION DE ESTAS

CAMPO TIPO TAMAÑO DESCRIPCION

ID_PRODUCTO NUMERICO 10 CLAVE DE PRODUCTO

CANTIDAD NUMERICO 10 CANTIDAD DE PRODUCTO

PRECIO_VENTA NUMERICO 10,2 PRECIO AL PUBLICO CON 2

DECIMALES FRACIONARIOS

RELACIONES: tblVenta, tblProducto

CAMPOS CLAVE: ID_DetalleVenta

NOMBRE DE ARCHIVO: USUARIO FECHA DE CREACION: 30-09-14

DESCRIPCION: ARCHIVO PRINCIPAL DE USUARIOS, CONTENDRA INFORMACION DE ESTOS

CAMPO TIPO TAMAÑO DESCRIPCION

ID_USUARIO NUMERICO 10 ID USUARIO

NOMBRE CARACTER 50 NOMBRES DE USUARIO

APELLIDOS CARACTER 50 APELLIDOS USUARIO

DNI NUMERICO 10 CURP USUARIO

TELEFONO INT 10 TELEFONO DE USUARIO

DIRECCION CARÁCTER 50 DIRECCION DE USUARIO

USER CARÁCTER 10 USUARIO SISTEMA

PASSWORD CARÁCTER 10 CONTRASEÑA SISTEMA

RELACIONES:

CAMPOS CLAVE: ID_USUARIO

NOMBRE DE ARCHIVO: CLIENTE FECHA DE CREACION: 30-09-14

DESCRIPCION: ARCHIVO PRINCIPAL DE CLIENTES, CONTENDRA INFORMACION DE ESTOS

CAMPO TIPO TAMAÑO DESCRIPCION

ID_CLIENTE NUMERICO 10 ID CLIENTE

NOMBRE CARACTER 50 NOMBRES DE CLIENTE

DNI CARACTER 10 RFC CLIENTE

TELEFONO INT 10 TELEFONO DE CLIENTE

DIRECCION CARÁCTER 50 DIRECCION DE CLIENTE

RELACIONES: tblVenta

CAMPOS CLAVE: ID_CLIENTE

1- Compra productos
El cliente entrega sus productos o pide servicios al cajero en la caja

Usos de cajero usuario

2-Cancela ventas:
A partir del registro temporal de ventas del sistema se elimina el producto o la
venta total con previa autorización de usuario
3-Entrega cambio:
A partir del cálculo delos detalles de venta al ingresar el importe dado por el
usuario imprimen pantalla el cambio a devolver al cliente
4- Registra productos
El cajero escanea el código de barras de los productos los cuales se registran en
una variable temporal que luego ser aguardada en la base de datos.
5- Registro cliente
Selecciona la opción del sistema y este muestra una ventana con opciones de
registros
6- Busca información
Se conecta con la base de datos y accede a una vista de esta para realizar
búsquedas en general usos de administrador.
7- Eliminar información
Llama a un procedimiento almacenado de la base de datos y elimina los registros
solicitados
8- Modificar información
Mediante un proceso almacenado se modifican los que el usuario requiera
Diagrama de Componentes Caso 1

Diagrama de Componentes Caso 2

Diagrama de despliegue Caso 1

Diagrama de despliegue Caso 2

Software de venta
Mantenimiento de cliente
Detalles de producto
Detalle de venta
Venta