INGENIERIA EN DESARROLLO DE SOFTWARE.

UNIDAD: 2. REQUERIMIENTOS PARA EL ANÁLISIS DEL DISEÑO

ORIENTADO A OBJETOS
ACTIVIDAD 2. EVIDENCIA DE APRENDIZAJE. REQUERIMIENTOS PARA
DISEÑAR UN PROGRAMA ORIENTADO A OBJETOS
DANIEL JONATHAN OROZCO ZITLE.
NOMBRE DEL DOCENTE VERONICA EZPINOZA ROMO.
GRUPO: B1-008.
Contenido
1 Introducción. ................................................................................................................. 4
1.1 Nombre del proyecto...................................................................................................................... 5
1.2 Formulación del Problema. ........................................................................................................... 5
1.3 Planteamiento. ................................................................................................................................ 5
1.4 Antecedentes. ................................................................................................................................. 6
1.5 Método ............................................................................................................................................. 6
1.6 Justificación. .................................................................................................................................... 6
2 Técnicas de recolección de Datos o información. ........................................................ 8
2.1 Descripción de las técnicas de recolección de datos. .............................................................. 9
. 9
2.2 Diferencias, similitudes, ventajas y desventajas identificas entre las técnicas de
recolección. ............................................................................................................................................... 10
2.3 Resumen. ...................................................................................................................................... 13
2.4 Lista de requerimientos ............................................................................................................... 13
Lista de requerimientos. .................................................................................................... 13
Tabla requerimientos funcionales, no funcionales de sistema y usuario. ....................................... 14
2.5 RESUMEN ..................................................................................................................................... 16
2.6 Propósito ........................................................................................................................................ 16
2.7 Alcance .......................................................................................................................................... 16
2.8 Personal involucrado ................................................................................................................... 16
2.9 Definiciones, acrónimos y abreviaturas .................................................................................... 18
2.10 Referencias ................................................................................................................................... 18
2.11 Resumen........................................................................................................................................ 18
2.12 Perspectiva del producto ............................................................................................................. 18
2.13 Características de los usuarios .................................................................................................. 19
3 Requisitos específicos ................................................................................................ 19
3.1 Requerimientos Funcionales ...................................................................................................... 19
3.2 Requerimientos No Funcionales. ............................................................................................... 21
3.3 Restricciones ................................................................................................................................. 23
3.4 Periodo de desarrollo. .................................................................................................................. 23
3.5 Tecnicas de levantamiento de requerimientos. ....................................................................... 23
 3.6 Check List. ..................................................................................................................................... 24
3.7 Checklist de Verificación de los Requerimientos ....................... Error! Bookmark not defined.
3.8 Estudio de viabilidad .................................................................................................................... 26
3.10 Especificación de requerimientos .............................................................................................. 28
3.10.1 Funcionalidad: ......................................................................................................................... 28
3.10.2 Atributos: ................................................................................................................................ 28
3.10.3 Restricciones de diseño: .......................................................................................................... 29
3.11 Valicación de requerimientos ..................................................................................................... 29

4 Fuentes .................................................................................................................... 32
5 Anexos. .................................................................................................................... 34
Entrevista. ......................................................................................................................... 34
1 Introducción.

Una de las mayores deficiencias en la práctica de construcción de software es la poca atención que se
presta a la discusión del problema. En general los desarrolladores se centran en la solución dejando el
problema inexplorado. El problema a resolver debe ser deducido a partir de su solución.

Esta aproximación orientada a la solución puede funcionar en campos donde todos los problemas son bien
conocidos, clasificados e investigados, donde la innovación se ve en la detección de nuevas soluciones a
viejos problemas.

Pero el desarrollo de software no es un campo con tales características. La versatilidad de

las computadoras y su rápida evolución hace que exista un repertorio de problemas en constante cambio y
cuya solución software sea de enorme importancia.
 1.1 Nombre del proyecto.
Crear un software que ayude al control de inventarios para evitar el rezago de producto y poder tener un
mejor control.

1.2 Formulación del Problema.

En la empresa Gomen and Healt Care (donde yo laboro) se maneja equipo médico, material de curación.

La empresa ha crecido poco a poco y ahora manejan volúmenes considerablemente altos de material de
curación, puesto que ya surten pedidos a empresas como el IMSS (Instituto Mexicano del Seguro Social)

La problemática que yo veo es que a pesar que tienen identificados los productos por un ID el control de
inventarios se debe hacer de manera manual, se necesita un software que pueda utilizarse en Windows 10
que pueda facilitar el trabajo de control de inventarios y que cada que se dé entrada a un producto o salida
de un producto este de manera automática pueda ya sea sumarse o restarse de manera automática en la
memoria donde se va a gurda dar esa información.

1.3 Planteamiento.
Tener una base de datos que nos enseñe de manera automática los productos que están en stock, los
productos los cuales ya no hay en existencia.

Objetivos 1. Llevar un mejor control del inventario.

2. Obtener con antelación productos faltantes.

3. Conocer con exactitud la cantidad de material de curación que existe.

 1.4 Antecedentes.
La compañía para la que laboro se encarga de la venta y distribución de material de curación, tiene cede
en GDL y una cede en CDMX en la cual es donde yo laboro y no hay un buen manejo y control de
inventario y debe estarse haciendo de forma manual, muchas de las veces hay producto existente ya sea
en GDL OCDMX y por lo mismo que no se lleva un buen control se rezaga en alguno de los dos lugares, o
llega a pasar que se piensa que hay producto existente y resulta que ya se vendió.

Esto afecta mucho a la empresa ya que como en muchos de los casos se tiene licitación con el IMSS las
penalizaciones han afectado mucho en ese aspecto a la empresa.

Con este proyecto espero se pueda obtener un mejor control de inventario y así tener mejor optimización en
el manejo del producto y mayor utilidad así como menos penalizaciones.

1.5 Método

Escojo el método incremental

1.6 Justificación.

Porque en el primer incremento podría realizar funciones básicas de administración de archivos, edición y
producción de documentos. En el segundo incremento ediciones más sofisticadas y que tendría funciones
más complejas. En el tercer incremento, nuevas correcciones hasta lograr el producto terminado.

Porque puedo construir un sistema pequeño y es menos riesgoso

Porque si tengo un error puedo desechar la última iteración

Porque las metas están bien definidas.

Y por qué puedo tener con antelación resultado de pruebas y pueden darme el visto bueno antes de
terminar el proyecto.

Puedo entregar proyectos beta

Y porque es menos riesgoso.

Por qué no se requiere que sea en tiempo real.

Incremento 1 - Saber cuánta existencia de equipo médico hay en stock

 Análisis, con base en inventarios anteriores vamos a tener una idea de los productos existentes

Requerimientos de entrada: id, producto, caducidad, lote, fabricante y precio.

Requerimientos de salida: cantidad de producto

.  Diseño, vamos a acceder a la base de datos de los productos, ir producto por producto para poder
obtener los requerimientos de salida.

El algoritmo podría ser el siguiente.

Teclear id de producto

Que aparezca en pantalla el producto

Si hay en stock se suma o resta según sea el caso

Nos muestra en pantalla el total de existencias

Fin.

 Pruebas, podemos realizar las pruebas con el programa y ver si obtenemos los resultados deseados y
poder empezar a utilizar este software o poder mejorarlo.

Incremento 2 - Saber cuánta existencia de equipo médico hay por lotes

 Análisis, con base en inventarios anteriores vamos a tener una idea de los productos existentes por lotes

Requerimientos de entrada: id, producto, caducidad, lote, fabricante y precio.

Requerimientos de salida: cantidad de producto por lotes.

.  Diseño, vamos a acceder a la base de datos de los productos, ir producto por producto para poder
obtener los requerimientos de salida.

El algoritmo podría ser el siguiente.

Teclear id de producto

Que aparezca en pantalla el producto

Según los lotes dividir por lotes

Nos muestra en pantalla el total de existencias por lotes.

Fin.

 Pruebas, podemos realizar las pruebas con el programa y ver si obtenemos los resultados deseados y
poder empezar a utilizar este software o poder mejorarlo.

Incremento 3 - Saber cuánta existencia de equipo médico por caducidad.

 Análisis, con base en inventarios anteriores vamos a tener una idea de los productos existentes

Requerimientos de entrada: id, producto, caducidad, lote, fabricante y precio.

Requerimientos de salida: cantidad de producto por caducidad

.  Diseño, vamos a acceder a la base de datos de los productos, ir producto por producto para poder
obtener los requerimientos de salida.

El algoritmo podría ser el siguiente.

Teclear id de producto

Que aparezca en pantalla el producto

Si hay varias caducidades se divide según sea el caso.

Nos muestra en pantalla el total de existencias por caducidades.

Fin.

2 Técnicas de recolección de Datos o información.

Son diversas técnicas y herramientas que son utilizadas por el o los analistas para desarrollar sistemas de
información los cuales pueden ser la encuesta, entrevista, la observación, el cuestionario el diagrama de
flujo, inspección de registros análisis documental, observación experimental, observación no experimental
y el diccionario de datos. Cada uno tiene desventajas y desventajas

Con la finalidad de buscar información estos instrumentos se aplicarán en un momento en particular.

Las cinco principales técnicas de recolección de datos son:

1. Entrevistas

2. La encuesta

3. La observación

4. Diccionario de datos

5. Diagrama de flujo
 2.1 Descripción de las técnicas de recolección de datos.

TECNICAS DE RECOLECCION DE INFORMACION

# NOMBRE FUNCION APLICACION
1 LA la función obtener información(se  Psiquiatría y Psicología
ENTREVISTA debe tomar notas) sobre un (entrevista terapeú6ca o
personaje o cosa a través de un clínica)
dialogo que se establece entre el  Periodismo (entrevista
entrevistador y el entrevistado.(es periodís6ca)
más que una simple conversación)  Empresa (entrevista de
evaluación, de
promoción, de
asesoramiento, de
despido, de
reclutamiento)
 Inves3gación social (en
profundidad).
2 LA ENCUESTA La función es para estudiar  Auto aplicado
poblaciones ,y se hace un análisis  Cara a cara
mediante muestras representativas  Por teléfono,
al fin de explicar variables de lo que  Vía web/email.
se está buscando o estudiando .La
encuesta proporciona datos
verídicos y a partir de ahí se toman
decisiones
3 LA Sirve para acumular e interpretar las  De manera natural
OBSERVACION actuaciones, comportamientos y  En base a un plan
hechos de las personas u objetos estructurado
tal y como las realizan  Sobre comportamientos
habitualmente se busca de forma espontáneos
cuidadosa y sistemática contemplar
cómo se desarrollan los hechos, sin
que uno intervenga o las manipule.

4 DICCIONARIO Si una persona o analista desea  Sistemas

DE DATOS saber alguna información de un computacionales.
dato, con qué otros nombres se le  Ingenieria en
conocen en el sistema, o en donde informatica.
 se utilizan dentro del sistema se  Programadores de
debe utilizar un diccionario de datos software
desarrollado apropiadamente.  Desarrolladores web

5 DIAGRAMA DE Es un instrumento que nos ayuda a  En cualquier campo

FLUJO representar las distintas etapas de  Educacion
un proceso de una forma gráfica en  Ventas y marketing
forma de desglose.  Negocios
 Manufactura
 Ingenieria

2.2 Diferencias, similitudes, ventajas y desventajas identificas entre

las técnicas de recolección.

TECNICAS DE RECOLECCION DE INFORMACION

NOMBRE VENTAJAS DESVENTAJAS DIFERENCIAS Similitudes
LA Aplicable a Puede ser
ENTREVISTA toda Limitación en estructurada o no  Sirven para
persona profundizar en estructurada. recabar
el tema. información
Permite Inductiva
obtener Difícil obtener  Pueden ser
informació información Deductiva cualitativos,
n más confidencial. cuantitativos o
fácilmente. Mixta mixtos.
A veces puede
Informació ser costosa  Todas tienen
n fácil de variables.
procesar. Pueden
requerir mucho  Llevan un
Puede ser tiempo proceso
cualitativa
o  Dan un
cuantitativa resultado

 Sirven para
algún campo
LA ENCUESTA Económico Falta de Pueden ser cara a de estudio.
sinceridad cara.
 Practico
Diferencias en Telefónicas
Resultados la compresión
rápidos e Postales
interpretación.
Escalable Vía e mail
Diseño
no se inflexible
necesita
ser
científico
LA Permite Se requiere de Puede ser
OBSERVACION registrar mucha participativa
datos habilidad y No participativa.
cualitativos agudeza Puede tener
y Demanda gran estructura o n
cuantitativo cantidad de tenerla.
s. tiempo.
Se Al
observan interpretarse
condicione pueden
sy distorsionarse
característi los hechos
cas de los
individuos.
Se puede
utilizar en
cualquier
tipo de
investigaci
ón y en
cualquier
área.
No
depende de
terceros o
registros.
DICCIONARIO Agilizan Aumento de Se requiere de
DE DATOS considerabl los costos conocimientos
emente la Complejidad previos en
obtención de la gestión sistemas o alguna
de carrera afín.
informació Requiere
n. actualizacione Pueden ser
Mejor s secuenciales
seguridad De iteración
 de los Se requiere de De selección
datos un equipo U opcional.
Mejora de especial.
la
integración
de datos
Mejora en
la toma de
decisiones
Aumento
de la
productivid
ad del
usuario
final

DIAGRAMA DE Ayuda a la Pueden llegar Se puede conocer

FLUJO comprensi a ser muy el proceso de un
ón del laboriosos. solo vistazo.
proceso. Se necesitan Al ser muy visual,
Fácil de conocimientos permite que las
identificar. previos. personas
Nos Se necesita de involucradas,
permite equipo lleguen a acuerdos
identificar especial. sobre los métodos
los errores Puede ser a utilizar y
y nos da la difícil el resolución de
oportunida seguimiento si problemas, de una
d de el diagrama manera más fácil.
alegrarlo y tiene Se puede usar
mejorar el diferentes para identificar
proceso. caminos. problemas,
Los asignar recursos,
diagramas No tiene coordinar
de flujo normas fijas actuaciones y
ayudan a la para la delimitar tiempos.
comprensi elaboración de Deja bien definidas
ón del los diagramas las funciones y
proceso al de flujos. responsabilidades
mostrarlo de cada una de las
con un personas que
dibujo. el intervienen en un
cerebro proceso.
humano Permite establecer
reconoce indicadores
fácil mente operativos.
los dibujos
 2.3 Resumen.

Después de haber aplicado la fuente de recolección de información (entrevista), y quedando en un

Sanborns café, entregándole antes un aviso de privacidad donde se le notifica al entrevistado que no se
hará mal uso de sus datos personales y que toda información recaba es con fines laborales.
Se logra identificar, las principales necesidades, deficiencias, dificultades e inconvenientes que existen
actualmente en la empresa con referente al manejo de control de inventarios que opera la empresa.
Se hallaron requisitos de mayor relevancia relacionados con la carencia de no tener una base de datos de
producto e inventarios actualizados en tiempo real, lo cual no les permite tener un orden para conocer el
estado de las cantidades, producto, lotes y fecha de caducidad.
Con esto se logra identificar que es el mayor problema dentro la empresa en cuanto a la necesidad
requerida.
A partir de esta necesidad terminante se precisa crear un software que permita de manera absoluta el buen
control y manejo de producto e inventarios para así poder minimizar el tiempo, desabasto, exceso y
desorden que actualmente tiene la empresa en el control de los productos se crea y ejecuta el siguiente
software el cual cumple con los requerimientos indispensables, buscando mejorar el manejo de los
productos.

2.4 Lista de requerimientos

Lista de requerimientos.
1. Base de datos
2. Sistema control de inventarios
3. Registro de usuarios
4. Registro de productos
5. Registro de marcas
6. Registro de proveedores
7. Gestión entradas de inventarios
8. Soporte.
9. Gestión de salidas de inventario
10. Desplegar información en tiempo real
11. Visualizar la información sobre la existencia de los productos
12. Disponibilidad
13. Tener acceso por usuario y contraseña
14. Fiabilidad
15. Acceso del usuario solo por la aplicación.
16. Filtro de búsqueda.
 Tabla requerimientos funcionales, no funcionales de sistema y usuario.

Requerimientos Usuario Sistema Argumenta la clasificación del

requerimiento

Funcional No
funcional

1. Base de datos X No les permite tener un orden

para conocer el estado de las
cantidades, producto, lotes y
fecha de caducidad.

2. Sistema control de X Un software que no les genere

inventarios
mucha papelería y les ayude a
llevarlo en tiempo real se lleve un
orden que les facilite el control
de inventarios.

3. Registro de usuarios X Registro de vendedores, de

quien usara el software o por si
hay rotación de personal.

4. Registro de X Requiere el sistema para el

productos
ingreso de ID, código de barras
.claves de registro, precio, grupo,
nombre, características,
presentación, registro de precios.

5. Registro de marcas X Muchas veces manejan un

mismo producto, puede que se
necesite ingresar una nueva
marca.

6. Registro de X Para que el usuario pueda

proveedores
ingresar nombre, dirección,
teléfono, o por si encuentran un
nuevo proveedor.

7. Gestión entradas de X El software debe permitir el

inventarios
 ingreso de un nuevo producto ,
de una nueva compra, así como
de alguna devolución o de un
intercambio(trueque)

8. Soporte X Tener un soporte de horario

oficina de 9:00 a 18:00 horas de
lunes a viernes.

9. Gestión de salidas X Cantidad vendida y se verá por

de inventario
lote y caducidad, cantidad, la
cantidad vendida se verá con
letras en otra tipografía más
grande.

10. Desplegar X Tendrá que reflejar el sistema el

información en
stock con el que se cuenta,
tiempo real
cantidad, marca, fecha de
caducidad, lote, descripción del
producto, ingreso, egreso.

11. Visualizar la X El sistema deberá, mostrar

información sobre la
existencia de los
productos
descripción de producto, stock
con el que se cuenta, fechas,
lotes caducidades. ID, marcas

12. Disponibilidad X El sistema debe trabajar 24

Horas los 365 días de la
semana.

13. Tener acceso por X El sistema contara con una

usuario y contraseña
restricción que contara con un
usuario y contraseña para limitar
el ingreso del personal según el
rol.

14. Fiabilidad X El sistema debe permitir

actualizaciones de la plataforma
donde se desarrolle.

15. Acceso del usuario X Que el sistema solo trabaje por

solo por la aplicación medio de la aplicación, que no se
pueda alterar por ningún otro
medio posible.
16. compatibilidad X Que sea compatible con el
hardware necesario tanto de
entrada como de salida y sobre
todo para impresión del
inventario.

2.5 RESUMEN
Este documento es una Especificación de Requisitos Software (ERS) para el Sistema de
información para la gestión de procesos y control de inventarios Crear un software que ayude al control de
inventarios para evitar el rezago de producto y poder tener un mejor control.
Esta especificación se ha estructurado basándose en las directrices dadas por el estándar IEEE Práctica
Recomendada para Especificaciones de Requisitos Software ANSI/IEEE 830, 1998.

2.6 Propósito
El presente documento tiene como propósito definir las especificaciones funcionales, no funcionales
para el desarrollo de un sistema de control de inventario para el almacén de equipo médico y material de
curación, el cual le permitirá gestionar mejor su inventario. Este será utilizado por director y jefe de amasen.

2.7 Alcance
Esta especificación de requisitos está dirigida al usuario del sistema para estimar el inventario calcular el
cambio en él y proyectar los niveles de inventario futuro, Estimar las variaciones en el inventario permite a
la empresa planificar las necesidades futuras del inventario.

2.8 Personal involucrado

Nombre Daniel J, Orozco
Rol Analista y diseñador de software
Categoría Profesional ING-Programador de software
Responsabilidad Análisis y diseño de software
Información de contacto radiosnakes@yahoo.com.mx

Nombre Ismael Vargas

Rol Analista, diseñador y programador
Categoría Profesional ING-Sistemas computacionales
Responsabilidad diseño y programación de software
Información de contacto ismaelvg@gmail.com
Nombre Ivan López
Rol Ingeniero en sistemas computacionales
Categoría Profesional ING-Sistemas computacionales
Responsabilidad Análisis y diseño de sistemas.
Información de contacto ivanxp@gmail.com
 2.9 Definiciones, acrónimos y abreviaturas

Nombre Descripción
Usuario Persona que usará el sistema para gestionar procesos
ID Identificación.
ERS Especificación de Requisitos Software
RF Requerimiento Funcional
RNF Requerimiento No Funcional
REG Registro

2.10 Referencias

Título del Documento Referencia

Standard IEEE 830 - 1998 IEEE

2.11 Resumen
Después de haber aplicado la fuente de recolección de información (entrevista), se logra identificar, las
principales necesidades, deficiencias, dificultades e inconvenientes que existen actualmente en la empresa
con referente al manejo de control de inventarios que opera la empresa.
Se hallaron requisitos de mayor relevancia relacionados con la carencia de no tener una base de datos de
producto e inventarios actualizados en tiempo real, lo cual no les permite tener un orden para conocer el
estado de las cantidades, producto, lotes y fecha de caducidad.
Con esto se logra identificar que es el mayor problema dentro la empresa en cuanto a la necesidad
requerida.
A partir de esta necesidad terminante se precisa crear un software que permita de manera absoluta el buen
control y manejo de producto e inventarios para así poder minimizar el tiempo, desabasto, exceso y
desorden que actualmente tiene la empresa en el control de los productos se crea y ejecuta el siguiente
software el cual cumple con los requerimientos indispensables, buscando mejorar el manejo de los
productos.

2.12 Perspectiva del producto

El sistema IMVEMEX será un producto diseñado para trabajar en plataforma cruzada, lo que permitirá su
utilización de forma rápida y eficaz,
 2.13 Características de los usuarios
Tipo de usuario Director
Formación Licenciado en Bioingeniería medica
Actividades Control y manejo del sistema en general, registro de
usuarios.

Tipo de usuario Jefe de almacén 1

Formación Licenciatura trunca
Actividades Manejo de almacén, ingreso de productos, lotes, marcas ,
caducidades, entradas y salidas de mercanias.

Tipo de usuario Jefe de compras

Formación Licenciatura Ejecutiva en Dirección de ventas
Actividades Participación activa en compra y venta de productosyen la
gestión de inventarios.

.
.

3 Requisitos específicos

3.1 Requerimientos Funcionales

Identificación del RF01

requerimiento:
Nombre del Base de Datos.
Requerimiento:
Características: Se introducirá toda la información sobre los productos clientes,
proveedores al sistema.
Descripción del El sistema podrá ser consultado por cualquier usuario dependiendo del
requerimiento: módulo en el cual se encuentre y su nivel de accesibilidad.
Requerimiento  RNF02
NO funcional:
Prioridad del requerimiento: Alta

Identificación del RF02

requerimiento:
Nombre del Sistema control de inventarios
Requerimiento:
Características: Sistema para control de productos
Descripción del El sistema permitirá al usuario ver todo lo relacionado con los productos
requerimiento: asi como lote fecha de caducidad ,marca..
Requerimiento  RNF02
NO funcional:  RN03
 RN04
Prioridad del requerimiento: Alta

Identificación del  RF03

requerimiento:
Nombre del Gestión de salidas de inventario
Requerimiento:
Características: El sistema ofrecerá al usuario información general acerca de cada
evento que registre el sistema
Descripción del Muestra información general sobre las salidas del producto si fue venta
requerimiento: o intercambio.
Requerimiento  RNF02
NO funcional:  RNF04

Prioridad del requerimiento: media

Identificación del RF04

requerimiento:
Nombre del Desplegar información en tiempo real
Requerimiento:

Características: El sistema ofrecerá al usuario información general acerca de cada

evento que registre el sistema
Descripción del . Tendrá que reflejar el sistema el stock con el que se cuenta, cantidad,
requerimiento: marca, fecha de caducidad, lote, descripción del producto, ingreso,
egreso.
Requerimiento  RNF02
NO funcional:  RNF03
 RNF05
Prioridad del requerimiento: media
3.2 Requerimientos No Funcionales.
Identificación del RNF01
requerimiento:
Nombre del Soporte
Requerimiento:
Características: Tener un soporte de horario oficina de 9:00 a 18:00 horas de lunes a
viernes.
Descripción del Por cualquier eventualidad respecto al sistema brindar ayuda.
requerimiento:
Prioridad del requerimiento: Alta

Identificación del RNF02

requerimiento:
Nombre del Visualizar la información sobre la existencia de los productos
Requerimiento:
Características: . se podrán mostrar productos con el sor de usuario administrador
Descripción del El sistema tendra una base de datos que muestre existencias en tiempo
requerimiento: real.
Prioridad del requerimiento: Alta

Identificación del RNF03

requerimiento:
Nombre del Disponibilidad
Requerimiento:
Características: 24/7
Descripción del El sistema debe estar disponible las 24 horas los 365 dias del año.
requerimiento:
Prioridad del requerimiento: baja

Identificación del RNF04

requerimiento:
Nombre del Tener acceso por usuario y contraseña
Requerimiento:
Características: El sistema deberá tener una protección
Descripción del .Se solicitara usuario y contraseña cada que quiera ingresasrse al
requerimiento: sistema y o modificar algún dato
Prioridad del requerimiento: Alta

Identificación del RNF05

requerimiento:
Nombre del Fiabilidad
Requerimiento:
Características: El sistema garantizara a los usuarios un desempeño en cuanto a los
datos almacenado en el sistema ofreciéndole una confiabilidad a esta
misma.
Descripción del Garantizar el desempeño del sistema informático a los diferentes
requerimiento: usuarios. En este sentido la información almacenada o registros
realizados podrán ser consultados y actualizados permanente y
simultáneamente, sin que se afecte el tiempo de respuesta.
Prioridad del requerimiento: Alta

Identificación del RNF06

requerimiento:
Nombre del Acceso del usuario solo por la aplicación
Requerimiento:
Características: El sistema tendrá seguridad y restriccion
Descripción del Que el sistema solo trabaje por medio de la aplicación, que no se pueda
requerimiento: alterar por ningún otro medio posible
Prioridad del requerimiento: media

Identificación del RNF08

requerimiento:
Nombre del compatibilidad
Requerimiento:
Características: Ser compatible con el hardware-
Descripción del Que sea compatible con el hardware necesario tanto de entrada como
requerimiento: de salida y sobre todo para impresión del inventario.
Prioridad del requerimiento: media
 3.3 Restricciones
 Interfaz para ser usada con internet.
 No contara con un sistema de pago en línea
 Contará con base de datos SQL Server Número especificación o Versión; 2019
 Los servidores deben ser capaces de atender consultas concurrentemente.
 El protocolo de comunicación que se utilizará en la comunicación del sistema es
 HTTP
 El sistema deberá tener un diseño e implementación sencilla, independiente de la plataforma
o del lenguaje de programación.
 Disco Duro 500 GB
 Memoria RAM 4 GB
 Procesador INTEL CORE I7
 Monitor 24 pulgadas
 Sistema Operativo Windows 10

3.4 Periodo de desarrollo.

Actividad
Aplicación de entrevista
Requerimientos del sistema
Diseño del sistema a crear
Desarrollo de herramientas
Pruebas y validación con la
empresa
Ajuste de software
Liberación del producto
Recopilación de experiencias
Reporte final
comentario Fecha de entrega
25 Agosto 2019
29 Agosto 2019
7 Septiembre 2019
Entradas y salidas de 10 septiembre 2019
mercanias
Conteo de inventario 13 septiembre 2019
17 septiembre 2019
Si es que llegase a requerirse 21 septiembre 2019
24 septiembre 2019
30 septiembre 2019
2 Octubre 2019

3.5 Técnicas de levantamiento de requerimientos.

La etapa inicial y muy importante para el desarrollo de un sistema de información es un buen levantamiento
, ya que si no se lleva bien se puede desviar de lo que la empresa o cliente tiene contemplado.

El análisis de requerimientos es el conjunto de técnicas y procedimientos que permiten conocer los

elementos necesarios para definir un proyecto de desarrollo de un sistema de información.

caterísticas para los requerimientos que se mencionan en el estándar IEEE830 (Std-

830-1998, 2008), son:
  Corrección: La Especificación de Requerimientos de Software (ERS) es correcta si y solo si todo requisito
que figura en la especificación refleja alguna necesidad real. La correcta especificación de los
requerimientos implica que el sistema implementado será el sistema deseado.

 No ambiguos: Cada requerimiento tiene una sola interpretación. Para eliminar la ambigüedad inherente a
los requerimientos expresados en lenguaje natural, se deberán utilizar gráficos o notaciones formales. En el
caso de utilizar términos que, habitualmente, poseen más de una interpretación, se definirán con precisión
en el glosario.

 Completos: Todos los requerimientos relevantes han sido incluidos en la especificación de requerimientos.
Conviene incluir todas las posibles respuestas del sistema a los datos de entrada, tanto validos como no
validos

 Consistentes: Los requerimientos no pueden ser contradictorios. Un conjunto de requisitos contradictorio

no es implementable.

 Clasificados: Normalmente, no todos los requisitos son igual de importantes. Los requerimientos pueden
clasificarse por importancia (esencial, condicional u opcional) o por estabilidad (cambios que se espera que
afecten al requisito). Esto sirve, ante todo, para no emplear excesivos recursos en implementar requisitos
no esenciales.

 Verificables: La especificación de requerimientos es verificable si y solo si todos sus requisitos son

verificables. Un requisito es verificable (testeable) si existe un proceso finito y no costoso para demostrar
que el sistema cumple con el requisito. Un requisito ambiguo no es, en general, verificable.

Modificables: La especificación de requerimientos es modificable si y solo si se encuentra estructurada de

forma que los cambios a los requerimientos puedan realizarse de forma fácil, completa y consistente. 
Trazables: La especificación de requerimientos es trazable si se conoce el origen de cada requerimiento y
se facilita la referencia de cada requisito a los componentes del diseño y la implementación.

3.6 Chuck List.

Si
g. ¿Es posible implementar todos y cada uno de los requerimientos?
Si
h. ¿Se ha especificado la mantenibilidad del sistema/software, incluyendo la habilidad de respuesta
a los cambios en el entorno operativo, las interfaces, la precisión, el rendimiento, y otras
capacidades adicionales predecibles?
Si
i. ¿Se han especificado los requerimientos para la comunicación entre los componentes del
sistema/software?
Si
j. ¿Se ha definido la funcionalidad y el comportamiento global de todo el sistema/software?
Si
k. ¿Se han establecido de forma explícita y sin ambigüedades las restricciones, suposiciones y
dependencias apropiadas?
 Si
l. ¿Se ha especificado adecuadamente la infraestructura tecnológica para el sistema/software?
Si
m. ¿Se ha limitado el ámbito del sistema/software?
Si
n. ¿Se han etiquetado de forma descriptiva todas las figuras, tablas y diagramas?
Si
o. ¿Se han referenciado dentro del documento todas las figuras, tablas y diagramas?
Si
p. ¿Se han definido de forma apropiada todos los términos y las unidades de medición?

4. Consistencia — La consistencia se refiere a la consistencia interna. Si la Especificación de los

Requerimientos no concuerda con el resto de documentación de la organización y del proyecto,
significa que no es correcta.
No
a. ¿Los requerimientos evitan la especificación del diseño?
Si
b. ¿Se han especificado los requerimientos con un nivel de detalle consistente?
Si
c. ¿Algunos de los requerimientos tienen que especificarse con mayor detalle?
Si
d. ¿Algunos de los requerimientos deben ser especificados con menor detalle?
Si
e. ¿Los requerimientos están en concordancia con el contenido del resto de documentación de la
organización o del proyecto?

Criterio Sí / No / NA

5. Categorizado por importancia y/o estabilidad – Una Especificación de los Requerimientos se

categoriza por importancia y/o estabilidad si cada requerimiento particular especificado en ella
posee un identificador que establece su importancia o estabilidad. Ejemplos de rangos de
categorización incluyen esencial, condicional u opcional. La estabilidad puede ser especificada en
términos del número de cambios esperados para un requerimiento.
Si
a. ¿Los requerimientos poseen asociado un identificador para indicar la importancia o la estabilidad
de un requerimiento en particular?
No
b. ¿Existen conflictos en relación a la categorización de la importancia y/o estabilidad de los
requerimientos?

6. Verificable — Una Especificación de los Requerimientos es verificable si, y solo si, cada
requerimiento especificado en ella es verificable. Un requerimiento es verificable si, y solo si, existe
un proceso finito y rentable con el cual una persona o máquina puede comprobar que el
sistema/software cumple con dicho requerimiento.
Si
a. ¿El lenguaje y vocabulario con el que están escritos los requerimientos es entendible para los
stakeholders? ¿Los stakeholders coinciden?
Si
b. ¿Cada requerimiento puede ser probado? A partir de pruebas independientes, ¿puede ser
posible determinar cuándo se satisface cada requerimiento?

7. Modificable — Una Especificación de los Requerimientos es modificable si, y solo si, su

estructura y estilo son tales que cualquier cambio en los requerimientos puede realizarse de forma
fácil, completa y consistente, conservando la estructura y el estilo.
Si
a. ¿Los requerimientos se identifican de forma única?
Si
b. ¿Se han consolidado los requerimientos redundantes?
Si
c. ¿Cada requerimiento se ha especificado de forma separada, evitando requerimientos
compuestos?
 8. Trazable — Una Especificación de los Requerimientos es trazable si el origen de cada uno de
sus requerimientos es claro y si facilita la referenciación de cada requerimiento en el desarrollo
futuro o mejora la documentación.
Si
a. ¿Puede trazarse cada requerimiento hacia su fuente de origen, como una declaración de su
ámbito, una petición de cambio o una legislación?
Si
b. ¿Se ha identificado cada requerimiento con el fin de facilitar su referenciación en el futuro
desarrollo o en los esfuerzos de mejora?
Si
c. ¿Cada requerimiento posee una referencia a los requerimientos previos del proyecto que están
relacionados con él?

3.7 Estudio de viabilidad

“ Para Bruno Cascio (2019) las fases de estandarización de requerimientos se divide en

sacado del documento titulado Ingeniería de Software I“

 Se genero un catalogo de requisitos donde se separaron en funcionales , no funcionales y de

usuario

 Se estudiaron los requisitos para ver los alcances del proyecto

 Se clasificaron los requisitos de acuerdo a las prioridades .y se estudian las alternativas para la
solución.

 Se selecciona una solución.

¿El sistema contribuye a los objetivos generales de la organización?

R= si , ya que se requería de una base de datos para que pudieran llevar un mejor control y una forma mas
ordenada de llevar acabo no solo sus productos, si no también entradas y salidas de mercancía.

¿El sistema se puede implementar con la tecnología actual?

R=Si ya que esta echo para correr en la plataforma mas actual que existe y así pueda tener un buen
periodo de vida.

¿El sistema puede integrarse a otros que existen en la organización?

R= no es un requisito necesario, aunque si llegase a ser necesario se podría trabajar.

3.8 Obtención y análisis de requerimientos.

Después de aplicar una entrevista deductiva y con la lluvia de ideas entre el cliente y el programador
se elabora un catálogo de requisitos y después de ver si es viable se revisaron los requisitos se
 separaron se analizaron y se añadieron las posibles condiciones y/o posibles restricciones, entorno al
sistema.

Para esto se siguió una guía o tabla de requerimientos que los separa y así se pueden clasificar mas
fácilmente y por ende analizarlos.

 Tipos de requerimientos:

o Requerimientos funcionales:

 Describen una interacción entre el sistema y su ambiente. Cómo debe comportarse

el sistema ante determinado estímulo.

 Describen lo que el sistema debe hacer, o incluso cómo NO debe comportarse.

 Describen con detalle la funcionalidad del mismo.

 Son independientes de la implementación de la solución.

o Requerimientos no funcionales:

 Describen una restricción sobre el sistema que limita nuestras elecciones en la

construcción de una solución al problema.

 Requerimientos del producto: Especifican el comportamiento del producto

(usabilidad, eficiencia, rendimiento, espacio, fiabilidad, portabilidad).

 Requerimientos organizacionales: Se derivan de las políticas y procedimientos

existentes en la organización del cliente y en la del desarrollador (entrega,
implementación, estándares).

 Requerimientos externos: Interoperabilidad, legales, privacidad, seguridad, éticos.

o Otras Clasificaciones:

 Requerimientos del dominio:

 Reflejan las características y restricciones del dominio de la aplicación del

sistema.

 Pueden ser funcionales o no funcionales y pueden restringir a los

anteriores.

 Como se especializan en el dominio son complicados de interpretar.

 Requerimientos por Prioridad:

 Que deben ser absolutamente satisfechos

 Que son deseables pero no indispensables

 Que son posibles, pero que podrían eliminarse

 Requerimientos del Usuario:

 Son declaraciones en lenguaje natural y en diagramas de los servicios que

se espera que el sistema provea y de las restricciones bajo las cuales debe
operar.
  Pueden surgir problemas por falta de claridad, confusión de
requerimientos, conjunción de requerimientos.

 Requerimientos del Sistema:

 Establecen con detalle los servicios y restricciones del sistema.

 Es difícil excluir toda la información de diseño (arquitectura inicial,

interoperabilidad con sistemas existentes, etc.)

3.9 Especificación de requerimientos

Los aspectos básicos de una especificación de requerimientos son:

3.9.1 Funcionalidad:
El software se enfoca en el control de mercancías , ventas ,compras ,movimientos tiene la
capacidad de recibir informacion y la almacena es apto para cumplir con los objetivos del proyecto,
y tiene niveles de seguridad protegido con contraseña, para evitar el ingreso de

personas no deseadas que puedan manipular la información a su conveniencia.

Nos proporciona control por lotes, fecha , caducidad etc.

 Intefaces Externas:

Interfaz de usuario:

La interfaz será de un manejofacil , debe contar con un aspecto “amigable”

Interfaz hardware:

Teclado, monitor de 24 pulgadas , mouse.

Interfaz software:

La interfaz software como ya se había mencionado anteriormente será de Windows 10

La interfaz de usuario será una ventana dentro de la interfaz del SO

(Interfaz software), y no necesitarán comunicarse entre ellas salvo para poder

ejecutarse la aplicación.

Rendimiento:

Tiene un funcionamiento optimo ya que ahorra tiempo ya de manera cualquier producto que se
encuentre en el almacen esto ayuda a que sea mas veloz y eficaz la forma búsqueda de productos,
se puede corroborar la existencia o desplazamiento de algún producto en tiempo real

3.9.2 Atributos:

Fiabilidad :
 El software cuenta con edición y eliminación de información incorrecta, en caso de ingresar mal los
productos se abrirá una ventana de edición o eliminación de los datos registrados. Como se
menciono tiene una seguridad basada en cuentas de usuario por medio de una contraseña así que
no podrá manipularse la información ya esta resguardada bajo contraseñas y permisos de
usuarios.

Usabilidad :
Este software es fácil de usar debido a que cuenta con una interfaz simple

Mantenibilidad:
Esta creado por módulos independientes eso hace que requiera de menos mantenimiento

Portabilidad:
El software es una aplicación web, que funciona dentro de una red de área local, por lo que se
puede acceder desde cualquier computador dentro de esta red. No requiere de un software
especializado, sólo un web browser compatible con la aplicación

3.9.3 Restricciones de diseño:

Política reguladora :
La aplicación se desarrollará mediante software de licencia abierta

 Interfaz para ser usada con internet.

 No contara con un sistema de pago en línea
 Contará con base de datos SQL Server Número especificación o Versión; 2019
 Los servidores deben ser capaces de atender consultas concurrentemente.
 El protocolo de comunicación que se utilizará en la comunicación del sistema es
 HTTP
 El sistema deberá tener un diseño e implementación sencilla, independiente de la plataforma
o del lenguaje de programación.
 Disco Duro 500 GB
 Memoria RAM 4 GB
 Procesador INTEL CORE I7
 Monitor 24 pulgadas
 Sistema Operativo Windows 10

3.10 Valicación de requerimientos

Es el proceso que certifica que los requerimientos definidos son los que hace el sistema.

Validación:
o Al final del desarrollo evaluar el software para asegurar que el software cumple los
requerimientos.
 o La validación sólo se puede hacer con la activa participación del usuario.

o La validación implica hacer el software correcto

El sistema seria incremental y se desarrollaría de la siguiente manera

Incremento 1 - Saber cuánta existencia de equipo médico hay en stock

 Análisis, con base en inventarios anteriores vamos a tener una idea de los productos existentes

Requerimientos de entrada: id, producto, caducidad, lote, fabricante y precio.

Requerimientos de salida: cantidad de producto

.  Diseño, vamos a acceder a la base de datos de los productos, ir producto por producto para poder
obtener los requerimientos de salida.

El algoritmo podría ser el siguiente.

Teclear id de producto

Que aparezca en pantalla el producto

Si hay en stock se suma o resta según sea el caso

Nos muestra en pantalla el total de existencias

Fin.

 Pruebas, podemos realizar las pruebas con el programa y ver si obtenemos los resultados deseados y
poder empezar a utilizar este software o poder mejorarlo.

Incremento 2 - Saber cuánta existencia de equipo médico hay por lotes

 Análisis, con base en inventarios anteriores vamos a tener una idea de los productos existentes por lotes

Requerimientos de entrada: id, producto, caducidad, lote, fabricante y precio.

Requerimientos de salida: cantidad de producto por lotes.

.  Diseño, vamos a acceder a la base de datos de los productos, ir producto por producto para poder
obtener los requerimientos de salida.

El algoritmo podría ser el siguiente.

Teclear id de producto

Que aparezca en pantalla el producto

Según los lotes dividir por lotes

Nos muestra en pantalla el total de existencias por lotes.

Fin.
 Pruebas, podemos realizar las pruebas con el programa y ver si obtenemos los resultados deseados y
poder empezar a utilizar este software o poder mejorarlo.

Incremento 3 - Saber cuánta existencia de equipo médico por caducidad.

 Análisis, con base en inventarios anteriores vamos a tener una idea de los productos existentes

Requerimientos de entrada: id, producto, caducidad, lote, fabricante y precio.

Requerimientos de salida: cantidad de producto por caducidad

.  Diseño, vamos a acceder a la base de datos de los productos, ir producto por producto para poder
obtener los requerimientos de salida.

El algoritmo podría ser el siguiente.

Teclear id de producto

Que aparezca en pantalla el producto

Si hay varias caducidades se divide según sea el caso.

Nos muestra en pantalla el total de existencias por caducidades.

Fin.
4 Fuentes

gabriellebet. (no tiene). TECNICAS DE RECOLECCIÓN DE DATOS. 28-07-2019, de no tiene Sitio web:
https://gabriellebet.files.wordpress.com/2013/01/tecnicas-de-recoleccic3b3n4.pdf.

wilmar gonzalez. (miércoles, 13 de mayo de 2009). RECOLECCION DE DATOS. 28-07-2019, de no tiene

Sitio web: http://recodatos.blogspot.com/2009/05/tecnicas-de-recoleccion-de-datos.html.

José Avilez. (no tiene). Recolección de datos. 28-07-2019, de monografias.com Sitio web:
https://www.monografias.com/trabajos12/recoldat/recoldat.shtml

Survey Monkey. (25/08/2015). CARACTERÍSTICA Y FUNCIÓN DE LAS ENCUESTAS. 28-07-2019, de

estudia y aprende Sitio web: https://www.estudiaraprender.com/2015/08/25/caracteristica-y-funcion-de-las-
encuestas/

Obra colocada bajo licencia Creative Commons Attribution Non-commercia. (no tiene). Modos de aplicación
del cuestionario. 28-07-2019, de Tecnicas de investigacion social Sitio web:
https://sites.google.com/site/tecninvestigacionsocial/temas-y-contenidos/tema-3-las-tecnicas-distributivas-la-
investigacion-cuantitativa-y-la-encuesta/modos-de-aplicacion-del-cuestionario

CONCEPTODEFINICION.DE. (no tiene). Definición de Observación. 28-07-2019, de

CONCEPTODEFINICION.DE Sitio web: https://conceptodefinicion.de/observacion/

Arturo R.. (13 Nov 2013). La técnica de observación. 28-07-2019, de crece negocios Sitio web:
https://www.crecenegocios.com/la-tecnica-de-observacion/

https://ingenieriadesoftwaretdea.weebly.com. (no tiene). Ingenieria De Software. 28-07-2019, de

https://ingenieriadesoftwaretdea.weebly.com Sitio web:
https://ingenieriadesoftwaretdea.weebly.com/diccionario-de-datos.html

LUIS MIGUEL MANENE. (El 28 julio 2011). DIAGRAMAS DE FLUJO: SU DEFINICIÓN, OBJETIVO,
VENTAJAS, ELABORACIÓN, FASES, REGLAS Y EJEMPLOS DE APLICACIONES.. 28-07-2019, de
LUISMIGUELMANENE.COM Sitio web: http://www.luismiguelmanene.com/2011/07/28/los-diagramas-de-
flujo-su-definicion-objetivo-ventajas-elaboracion-fases-reglas-y-ejemplos-de-aplicaciones/

LUCIDCHART. (NO TIENE). Qué es un diagrama de flujo. 28-07-2019, de LUCIDCHART Sitio web:
https://www.lucidchart.com/pages/es/que-es-un-diagrama-de-flujo

Requeridos Blog. (Apr 20, 2018). Requerimientos Funcionales y No Funcionales, ejemplos y tips. 6-08-
2019, de Requeridos Blog Sitio web: https://medium.com/@requeridosblog/requerimientos-funcionales-y-no-
funcionales-ejemplos-y-tips-aa31cb59b22a.

PMOinformatica.com. (lunes, 6 de febrero de 2017). Requerimientos funcionales: Ejemplos. 7-08-2019, de

PMOinformatica.com Sitio web: http://www.pmoinformatica.com/2017/02/requerimientos-funcionales-
ejemplos.html.

Tecnología y Synergix. ( NA). Tipos de requisitos: Funcional vs. No Funcional. 06-08-2019, de Tecnología y
Synergix Sitio web: https://synergix.wordpress.com/2008/07/07/requisito-funcional-y-no-funcional/.

ivai.org.mx/DatosPersonales/Archivos/.../Formatos_de_avisos_de_privacidad.docx.
 Escobar Yanvary. (No tiene). Desarrollo del software. Lunes 22 julio 2019, de monografias.com Sitio web:
https://www.monografias.com/trabajos39/desarrollo-del-software/desarrollo-del-software.shtml

mariCh. (29-03-2016). Modelo incremental. 22 Julio 2019, de blogdiario.com Sitio web:

http://marich.blogspot.es/1459223366/modelo-incremental/

https://gist.github.com/brunocascio/09ba6c90842948bfb9ad
5 Anexos.

Entrevista.

La entrevista que llevare a cabo será de preguntas abiertas, ya que me ayudara saber de forma
más precisa que es lo que busca el cliente o empresa en general e ir terminando con preguntas
cerradas.

Por tanto el método que elegiré es el deductivo.

Como ya se mencionó en el trabajo anterior la empresa Gomen Health Care necesita un mejor
control de inventarios, se formularan las preguntas al encargado de almacén que es el jefe
responsable de esa área, la entrevista formulare unas preguntas con antelación y la forma se
llevara de forma presente, con anotaciones y grabar el audio con un celular.

Nombre de la empresa: GOMEN AND HEALT CARE

Fecha de entrevista: 28-07-2019

Teléfono contacto: 55877887

OBSERVACIONES:

¿Cómo llevan actualmente su inventario?

¿Qué tipo de productos manejan?

¿Cuál es el objetivo de cambiar de sistema?

¿Cómo empieza su inventario?

¿Cómo lo termina?

¿Qué persona o personas están involucradas en el control de inventarios?

¿Cuáles son la cosas que encuentran más difíciles en el proceso actual y que cosa piensan que
puede ser cambiada para mejorar?

¿Utilizan algún software para el control de inventarios?

¿Quién utilizaría el nuevo sistema implementado?

¿Se utilizaría de forma periódica?

¿Le gusta nuestra propuesta?

Entrevista.

Fecha de entrevista: 25-08-2019

Teléfono contacto: 55877887
Nombre: Alejandro Trejo jefe de almacén GOMEN.

OBSERVACIONES: El entrevistado llega con 20 minutos de demora de lo acordado.

¿Cómo llevan actualmente su inventario?

R= la manera que trabajamos los productos es por fecha de caducidad y lote, manejamos varias
marcar pero lo que más nos importa es la caducidad y el lote tenemos una lista de ID (clave
identificadora interna) de cada producto, tratamos de etiquetar con ese id el producto y de manera
manual se lleva acabo el inventario.
¿Qué tipo de productos manejan?
R= son productos material médico y de curación (sondas catéteres, bolsas para uro cultivo,
jeringas etc. etc.) son varias marcas y pueden ser diferentes lotes, muchas veces puede ser un
mismo producto y diferentes caducidades
¿Cuál es el objetivo de cambiar de sistema?
R= Son varios motivos, la empresa está creciendo y eso hace que manejemos grandes volúmenes
de productos, ahora manejamos licitaciones directas con el IMSS(INSTITUTO MEXICANO DEL
SEGURO SOCIAL) y cuando hay mucha carga de trabajo tenemos problemas para elaborar el
inventario,(a veces no hay tiempo) hay productos que llegan pero en ese mismo momento salen, y
tenemos que detectar que paso con ese producto, también por la carga del trabajo no vemos que
lotes y caducidades tenemos y se está empezando a rezagar el producto, aparte que nos empieza
a generar mucho archivo en papel.
¿Cómo empieza su inventario? Para ahorrar tiempo se empieza por identificar lo que tenga ID, el
ID se pega con una etiqueta y ya que se inventario lo que está identificado, se empieza a
inventariar y a identificar o que no tiene id, y se debe contar pieza por pieza, eso nos crea un
margen de error muchas veces por la carga de trabajo.

¿Cómo lo termina?
R= al final se ordena por número de ID de forma descendente se pone de izquierda a derecha ID
producto marca, lote caducidad y cantidad de producto que hay
¿Qué persona o personas están involucradas en el control de inventarios?
R= la personas encargadas de almacén, tenemos dos personas.
¿Cuáles son la cosas que encuentran más difíciles en el proceso actual y que cosa piensan
que puede ser cambiada para mejorar?
Llevar el conteo del inventario, estar conscientes de la proximidad de la caducidad de los productos
y las existencias que tenemos, muchas veces se ha llegado a pedir producto de más porque no se
tenía cuenta que había producto en existencia.
¿Utilizan algún software para el control de inventarios? Solo Excel pero se nos complica
mucho ya que es introducir los valores de forma manual.
¿Quién utilizaría el nuevo sistema implementado?
Prácticamente los jefes, pero principalmente las dos personas encargadas de almacén.
¿Se utilizaría de forma periódica?
Si, realmente me gustaría tenerlo siempre a la mano,
¿Le gusta nuestra propuesta?
Me parece interesante, y sobre todo si me va a ahorrar tiempo y llevar mejor mi control de
inventarios.
Aviso de privacidad.

Aviso de Privacidad simplificado de __________ (indicar a qué trámite, servicio o

procedimiento se refiere)

_________________________ (nombre completo del sujeto obligado sin abreviaturas o

acrónimos), es el responsable del tratamiento de los datos personales que nos proporcione.

Los datos personales que recabamos de usted, los utilizaremos para las siguientes finalidades:
(enunciar las finalidades principales y obligatorias, frases cortas y claras)

De manera adicional, utilizaremos su información personal para las siguientes finalidades que no
son necesarias, pero que nos permiten y facilitan brindarle una mejor atención: (describir las
finalidades secundarias que requieran el consentimiento del titular)

En caso de que no desee que sus datos personales sean tratados para las finalidades
adicionales, usted puede manifestarlo mediante ___________________ (Este enunciado
puede variar de acuerdo al mecanismo para manifestar la negativa puede ser por escrito
libre ante el área que recabe los datos, correo electrónico, plataforma electrónica si es
que la hubiera y lo permitiera u otras, considerar que debe ser previo al tratamiento del
dato)

Le informamos que sus datos personales son compartidos con las personas, empresas,
organizaciones y autoridades distintas al sujeto obligado, para los fines que se describen a
continuación:

Destinatario de los datos País (opcional) Finalidad

personales
Nombre de la autoridad, poderes, Descripción de la finalidad
entidades, órganos y organismos
gubernamentales de los tres órdenes
de gobierno y las personales físicas o
morales a los que se transfieren
Descripción de la finalidad
Descripción de la finalidad

Si usted no manifiesta su negativa para dichas transferencias, se entenderá que ha otorgado su

consentimiento.

Para mayor información acerca del tratamiento y de los derechos que puede hacer valer, usted
puede acceder al aviso de privacidad integral a través de la dirección electrónica:
www._______________ (señalar página web o links en que se encuentra disponible, o
medio que sean aplicables al sujeto obligado)

NOTA: El texto puede sufrir modificaciones según se actualicen los requisitos, o de acuerdo
al medio o mecanismo por el que se dé a conocer. El diseño, tipografía, o inclusión de
colores o imágenes es responsabilidad de cada sujeto obligado siempre que no
contravenga lo dispuesto por la Ley.