¡Descarga Sistema de Gestión de Inventario para Tiendas de Barrio y más Guías, Proyectos, Investigaciones en PDF de Ingeniería del Software solo en Docsity!
SERVICIO NACIONAL DE APRENDIZAJE
CENTROS DE SERVICIOS DE SALUD (REGIONAL-ANTIOQUIA)
ANALISIS Y DESARROLLO DE SOFTWARE.
FICHA:
ACTIVIDAD:
Evidencia de producto: GA1-220501092-AA4-EV02 documento con
especificación de requerimientos
PRESENTADO POR:
ANDRES FELIPE GARCES VANEGAS
TATIANA RUBIO CHAMORRO
VERSION 1.
INDICE GENERAL.
- Introducción…………………………………………………………………………………………..
- 1.1 Alcance…………………………………………………………………………………………..……
- Descripción General……………………………………………………………………………….
- 2.1 Perspectiva del Producto……………………………………………………………………..
- 2.2 Funciones del Producto………………………………………………………………………..
- 2.3 Características de los Usuarios…………..…………………………………………………
- 2.4 Restricciones………………………………………………………………………………………..
- Requerimientos Específicos……………………………………………………………………
- 3.1 Requisitos Funcionales…………………………………………………………………………….
- 3.2 Requerimientos No Funcionales………………………………………………………………
- 3.3 Historias de usuario……………………………………………………………………………….
ALCANCE.
En esta sección documentaremos y daremos a conocer los siguientes
elementos de la norma estándar IEEE830 como lo son los siguientes
elementos:
o Perspectiva del producto.
o Funciones del producto.
o Características de los usuarios.
o Restricciones.
o Requisitos funcionales (formato de casos de uso).
o Requisitos no funcionales.
Anexaremos adicionalmente a lo anterior las historias de usuario con
enfoque informativo a cada caso de uso antes ya presentados. En ellas
podremos identificar mucho mas lo que se espera de nosotros y que las
acciones que desarrollaremos en esta versión para solucionar todos sus
requerimientos.
2. DESCRIPCION GENERAL.
La norma IEEE830 es una guía que nos ayuda a documentar los
requerimientos del software de una manera clara y ordenada. Básicamente,
define cómo debemos describir todas las cosas que el software tiene que
hacer y las limitaciones que debe tener. Esta norma nos ayuda a tener una
comunicación más fácil entre todas las personas involucradas en el desarrollo
del software y asegura que todos estemos en el mismo objetivo y
pensamiento. Además, nos ayuda a verificar y garantizar los requerimientos
para asegurarnos de que todo lo que se pide sea cumplido. En resumidas
cuentas, la norma IEEE830 nos ayuda a documentar y organizar los
requerimientos del software para que sea comprensibles, completos,
verificables y trazables, como lo dice el estándar.
2.1 Perspectiva del producto:
El producto final permite el control operacional del 80% de las actividades de
una tienda de barrio colombiana, debe permitir llevar un control total de
caja, inventario, registro de ventas, además debe realizar de manera
temprana alarma de existencia de productos para garantizar que la operación
no pare por falte por falta de estos productos, deberá ser intuitiva y de fácil
en la usabilidad del software.
Por parte del segundo actor que es el cliente, deberá desplegar todas las
opciones de productos existente con información clara y precisa de precio y
descripción de los mismos, ayudará a que el cliente sienta total libertad al
momento de su compra, debe garantizar el rápido cambio de interfaz para
usar el factor tiempo a su favor, además estará siempre con la opción de
cancelar compra si se llega a cambiar de opción u opinión de la misma.
Tendero o vendedor: De los tenderos debemos recalcar que son
personas con experiencia en todas las técnicas que se aplican a la hora
de comprar barato y vender con un margen de ganancia la cual permita
su sostenimiento y en la mayoría de los casos el sostenimiento de sus
familias. Estos han adquirido habilidades como gestión de inventario,
caja, promociones y estrategias de ventas para los productos requeridos
en los barrios colombianos, son personas que enfrentan a grandes
desafíos como lo es la competencia con las grandes cadenas de
supermercados, la logística de distribución y abastecimiento de sus
negocios, lo cual es un desafío en su día a día.
Son personas con un gran espíritu emprendedor, que empatizan con los
clientes formando no solo lazos comerciales, si no también vínculos de
amistad los son muy duraderos, son personas que cuentan con poca
disponibilidad de tiempo ya que en su gran mayoría deben de tener su
tienda abierta a disposición de la comunidad para la adquisición de
productos al por menor, además deben de conocer a detalle los
productos que venden para garantizar calidad en asesoramiento y
ventas, normalmente son personas que no están acostumbradas al uso
de la tecnología para sus negocios y esto dificulta en gran manera la
gestión precisa de su acción comercial o en caso de los mas disciplinados
a un gran sobresfuerzo.
2.3 Restricciones: La norma IEEE830 establece una serie de
restricciones o limitaciones que podrían aplicarse a los usuarios
principales, como los tenderos y los clientes, en las tiendas de barrio
colombianas. Estas restricciones pueden incluir:
1. Disponibilidad de tiempo: Los usuarios pueden tener restricciones de
tiempo debido a sus responsabilidades diarias en la tienda de barrio.
Pueden requerir que el software sea fácil de usar y rápido de navegar
para minimizar el tiempo dedicado al sistema. O en su defecto el
software debe estar en capacidad de cambiar para el solo uso del
tendero y evitar complicaciones al cliente.
2. Conocimiento técnico : Los usuarios pueden tener diferentes niveles
de conocimiento técnico. El software para esto debe desarrollar una
interfaz y funciones intuitivas que no requieran conocimientos
especiales para su uso.
3. Acceso a tecnología : Los usuarios pueden tener restricciones en la
conexión a internet estable. El sistema deberá diseñarse teniendo en
cuenta estas limitaciones y en lo posible el software debería funcionar
offline.
4. Idioma : Los usuarios principales pueden tener restricciones
relacionadas con el idioma. El sistema debe estar disponible en nuestro
idioma español.
5. Seguridad : Los tenderos y los clientes pueden requerir restricciones
en términos de seguridad para proteger su información personal y
financiera. El sistema deberá garantizar altos niveles de seguridad y
privacidad de datos.
6. Costos : Los tenderos pueden tener restricciones en cuanto a los
costos asociados con el software. Debe ser económico y ofrecer un
excelente servicio para que se convierta en una herramienta útil y no se
catalogue como gasto si no mas bien como inversión.
7. Personalización : Los tenderos y los clientes pueden tener
restricciones relacionadas con la personalización del software según sus
necesidades. Él sistema debe permitir personalización para adaptarse a
diferentes requerimientos y procesos.
2. INTERFAZ:
*Una interfaz amigable y fácil de usar para registrar ventas y tener un
seguimiento detallado de los productos más vendidos.
*La interfaz debe tener dinamismo fácil de comprender, se debe usar
imágenes adecuadas para cada proceso.
*La interfaz debe de tener siempre la opción de cancelar compra,
pedido, venta, para proporcionar el cambio de opiniones y deseos de los
usuarios.
3. PLATAFORMA:
*Una plataforma de comunicación directa entre proveedores y dueños
de tiendas para agilizar los pedidos y resolver incidencias.
*Una plataforma que permita ver la lista de deudores de productos de la
tienda en donde este registrados los datos de comunicación.
4. Capacitación y soporte técnico:
* Capacitación y soporte técnico para asegurar el correcto uso del
software.
*El sistema debe de informar a los desarrolladores cuando haya
requisito de capacitación o de soporte técnico.
*El sistema debe registrar por orden, quien ha sido el primer cliente
dueño de tienda que requiera la capacitación o soporte.
*El sistema debe de mostrar los correos, teléfonos y demás canales de
atención al usuario.
5. PQR:
*El sistema deberá tener habilitada la opción de ( PQR ), en donde se
pueda filtrar información que evidencie si la falla es humana del local o
la atención o es del sistema.
ESPECIFICACION DE USOS.
Identificador de Caso Uso (^) CU_ Nombre Solicitud del producto Descripción Este caso de uso permite al Cliente seleccionar en la tienda el producto de su interés. Actores Cliente. Secuencia normal Actor Software
- El Cliente selecciona la opción comprar producto. Despliega un menú intuitivo dividido en los diferentes tipos de productos que hay en la tienda. 2.observa opciones. 2. muestra los diferentes tipos de productos. *Aseo. *cárnicos. *Frituras. *Golosinas. *Servicios (recargas, pago de facturas etc.) *Granos. *frutas y verduras. *Bebidas. *Lácteos. *otros.
- Selecciona opción de preferencia. Ejemplo (Aseo) Muestra diferentes marcas de productos de aseo que se encuentran disponibles en la tienda. Ejemplo. *Ariel *Colgate-palmolive *familia *p&G *Unilever *clorox *otros 4.Selecciona marca favorita. EJEMPLO (Colgate-palmolive).
- Despliega opciones de productos de la marca. Ejemplo. *Crema Colgate en todas sus variaciones. *Jabon Protex. *Fabuloso *etc 5.selecciona producto. Ejemplo. (Fabuloso) 5.Muestra producto en sus diferentes presentaciones y precio. 6.Elije producto. 6. Se agrega al carro de compras. Y da opción de agregar mas productos nuevamente o concluir compra.
Descripción Este caso de uso permite al vendedor revisar si el producto está en el inventario y puede ser vendido. Actores Vendedor-cliente. Secuencia normal Actor Software 1.El cliente concluye Compra, no llevara más productos. 1.Genera los diferentes tipos de pago: *efectivo. *digital: -pse. -transferencia bancaria. -nequi. -moovi. 1.1. mostrará en el software del vendedor, la solicitud del cliente en cuanto a productos, adicionalmente se mostrara si en el inventario del sistema hay el articulo determinado en disponibilidad. 1.2. En el caso de SI haya producto disponible se procede a dar en la opción, aceptar venta y se realizara y guardara transacción de manera exitosa. 2.El vendedor observa en el sistema la no existencia del producto en el inventario. 2.Despliega opción de cancelar compra con un mensaje para el cliente de disculpas y ofrece interactivamente con base a inventario productos con similitud al que quería escoger.
- Vendedor cancela la compra por no existencia de producto en el inventario. 3.Despilega posteriormente de cancelada la compra la opción de contactar proveedor de productos y hacer solicitud de abastecimiento. 4.Vendedor da clic en comunicar con proveedor.
- Muestra lista de proveedores con sus respectivos datos de contacto como lo es: *correo electrónico. *teléfono de contacto. *whassap 5.El Vendedor se comunica con el proveedor y hace solicitud de productos.
5. N/A
6.El vendedor cuenta con los productos en su negocio. 6.Dentro del software para el vendedor tendrá la opción de registrar productos que ingresaran a inventario y registrar la compra de los productos nuevos con su valor inicial y total, que llevara a un control de gestión financiera. 6.1 Despliega opción de agregar productos al inventario. 7.El vendedor da clic en agregar producto a inventario. 7.Se despliega la opción a que tipo especifico de producto quiere agregar inventario. EJEMPLO. **Aseo. *cárnicos. *Frituras. *Golosinas. *Servicios (recargas, pago de facturas etc.) *Granos.
*frutas y verduras. *Bebidas. *Lácteos. *otros. 8.El VENDEDOR elije opción. Ejemplo. *ASEO. 8.1. POSTERIORMENTE. Ejemplo. *Colgate-palmolive. 8.2 luego. Ejemplo. *fabuloso. 8.3.El vendedor aumenta cantidad de productos escogidos con la opción +. 8.4.El vendedor termina y guarda proceso. 8.despliega las marcas de los diferentes tipos de marcas de productos de aseo existentes. 8.1. luego de elegir marca favorita se desplegará opción de producto a ingresar. 8.2. luego de elegir producto a ingresar le mostrara las opciones ( + y/o - ). 8.3. aumentará o disminuirá según se seleccione. 8.4. tendrá en la parte superior derecha la opción de guardar, cuando se ingrese la cantidad deseada. 8.5.al guardar información de inventariado quedara listo para ser interactivo en el proceso de futuras ventas. 9.Paga al vendedor. 9.guarda y procesa la operación, saca producto de inventario, lleva control de caja.
- N/A. 10.Guarda información, agrega productos al inventario del software interactivo. Excepciones Software
- Error al ingresar el producto de interés. b. Muestra una opción de poder cancelar compra en cualquier fase del proceso de la compra. Regresar al paso 3. CU relacionados
CU_01-
Precondició n Debe contarse con proveedores antes de iniciar operacion Post condición Debe obligatoriamente darle en el botón guardar para poder ingresar productos al software. Identificador de Caso Uso CU_ Nombre Paga producto.
Actores (^) Cliente. Secuencia normal Actor Software 1.El vendedor cobra el producto mediante las herramientas de su que le permite el software. Ejemplo. *Efectivo. 1.Le permitirá registrar el pago manualmente con cantidad exacta de y detallada del proceso (con que billete se efectuó el pago, cuanto devolvió, etc ) .Esto permitirá un control preciso del dinero que hay en caja y una contabilidad mas confiable. 2.El vendedor se le notifica elección de pago por transferencia o herramienta digital.
- mostrara la opción de pago exitoso verificado o pago no efectuado. Esto con el fin que el vendedor pueda verificar en la herramienta digital la veracidad del pago. 3.El vendedor corrobora el pago que es exitoso. 3.1.El vendedor corrobora pago no exitoso. 3.Muestra opciones de: -pago exitoso verificado. *finalizar venta y procede a guardar información del procedimiento. *saca producto del inventario. 3.1.pago no efectuado. *Genera opción de cancelar compra o cambiar método de pago. 4.El vendedor procesa venta con éxito. 4.Guarda proceso de venta y saca productos del inventario. *posteriormente genera empalme con la caja del software en donde se evidencia efectivo disponible. Excepciones Software 1.El cliente cancela compra. 1.generara opción de cancelar compra en todas las etapas del proceso de la venta. CU relacionados
CU_
Precondición N/A Identificador de Caso Uso (^) CU_ Nombre Se lleva el producto Descripción Este caso de uso permite al Cliente obtener el producto deseado. Actores Cliente-vendedor
Secuencia normal Actor Software
- El Cliente finaliza la compra. 1.muestra opción tipo pregunta cerrada de la satisfacción en el proceso.
- el nivel de satisfacción de compra ira del 1 al 5 asi: -1=muy mala. -2=mala. -3=normal. -4=buena. -5=Exelente. 2.El cliente decide participar en la encuesta. Ejemplo. *elije opción NORMAL. 2.Guarda información de encuesta y genera opción de PQR.
- El cliente genera PQR. (^) 3.Guarda información del PQR, y notifica en modo alerta al vendedor. 4.El cliente se retira. 4. Guarda información y vuelve al inicio intuitivo para una nueva venta. Excepciones Software
- N/A (^) 1. N/A CU relacionados
N/A
Precondición N/A Post condición (^) N/A Identificador de Caso Uso CU_ Nombre (^) Factura venta.
Actores (^) Vendedor. Secuencia normal Actor Software 1.El vendedor da clic en finalizar venta. 1.Sofware saca producto del inventario. 2.el vendedor observa falta de algunos productos en existencias y repite procesos del CASO DE USO #2, acción #04 al #08.5. 2.Procesa información, guarda cambios, Excepciones Software
- N/A 1. N/A CU relacionados
N/A
Precondición N/A Post condición N/A Identificador de Caso Uso (^) CU_ Nombre CONTROL DE CAJA Descripción Este caso de uso permite al vendedor tener control financiero total de su negocio. Actores Vendedor. Secuencia normal Actor Software
- el vendedor finaliza proceso de venta con éxito. 1.Guardalo los detalles de la venta en cuanto a precio de producto, precio de venta y margen de ganancia. 2.El vendedor abastece el inventario de productos. 2.sube productos al inventario y guarda información. *despliega opción de registrar compra con detalles de precios de compra. *genera opción de registrar en cada producto precio de venta. *calcula ganancias potenciales.
- El vendedor necesita saber cuanto dinero esta generando en su negocio. 3.el software tendrá una opción de resumen contable en donde compara: *precio de compra de cada producto. *precio de venta. *margen de ganancias. *Deudas totales. 3.1 Generara un informe diario, semanal, mensual de gastos, y ganancias potenciales, sumara a ello gastos inmobiliarios como recibo de luz, agua etc. 4.El vendedor necesita saber cuanto le deben a su negocio.
- El software mostrará nombres de cada deudor con su valor en deuda al darle clic se desplegará la información del deudor con números de contacto por si el vendedor desea cobrar dicha deuda. Excepciones Software
- N/A (^) 1. N/A CU relacionados
N/A
Precondición N/A Post condición (^) N/A 3.2 REQUISITOS NO FUNCIONALES.
Los requisitos no funcionales son restricciones o requisitos impuestos al
sistema que especifican el atributo de calidad del software. Estos requisitos
se ocupan de problemas como la escalabilidad, la mantenibilidad, el
rendimiento, la portabilidad, la seguridad, la confiabilidad y muchos más. Los
requisitos no funcionales definen las características o cualidades generales
que se esperan de un sistema y establecen restricciones sobre el producto, el
