Universidad Nacional de Cajamarca

Facultad de ingeniería
Escuela Académico Profesional de Ingeniería de Sistemas

Curso:
Ingenieria de software II

Integrantes del Grupo:

Bacón Aliaga, Elsa.
Garcia Chilon Vilma
Diaz Padilla Karina
Merlo Valdez, Antony.
 Especificación de requisitos de software

1. Funcionalidad
El Sistema debe
1.1. Asociados a los casos de uso del sistema
1.1.1. verificar autenticación de ingreso a este por parte de los usuarios autorizados.
1.1.2. Registrar información de producto.
1.1.3. permitir a los almaceneros poder actualizar y/o eliminar información concerniente a
los productos albergados en la base de datos.
1.1.4. obtener información de algún producto mediante la búsqueda, haciendo uso del
código o nombre perteneciente a este.
1.1.5. Elaborar reporte de almacenamiento
1.1.6. permitir a los almaceneros el registro de nuevos productos.
1.1.7. Ser capaz de mostrar los productos detallados con su respectiva foto.
1.1.8. Poder ser consultado por los usuarios que cuenten con autentificación.
1.1.9. Permitir al usuario checar la verificación de los datos de los productos registrados.
1.1.10. Permite al administrador consultar los datos de productos existentes dentro
del sistema.
1.1.11. Registrar los pedidos y devoluciones de productos.
1.1.12. Permitir al administrador y/o almacenero modificar la información de usuario
en la BD.
1.1.13. permitir gestionar información referente a la fecha de pedidos de producto.
1.2. Asociados a aspectos generales
1.2.1. Permitir generar una copia impresa de reporte de almacenamiento en el ordenador
desde donde se realice el proceso.
1.2.2. Una vez que la información del producto esté almacenada en la base de datos, no
será necesaria ingresarla nuevamente para generar informes o reportes, sino
simplemente actualizarla si fuera necesario.
2. Usabilidad
2.1. El Sistema debe tener una interfaz de uso intuitivamente, sencilla y facil de usar.
2.2. El sistema deberá permitir en el 80% de las veces que con un máximo de 5 clicks sea
suficiente para llegar a la información deseada.
2.3. Un usuario experimentado debe ser capaz de utilizar todas las funciones del sistema tras
un entrenamiento de 15 minutos, tras el cual no cometerá más de 3 errores diarios en
media.
2.4. Ante un fallo en el software del sistema, no se tardará más de 5 minutos en restaurar los
datos del sistema (en un estado válido) y volver a poner en marcha el sistema.
2.5. El Sistema permitira al usuario el registro de la solicitud de servicio como promedio en 25
segundos.
3. Confiabilidad
3.1. El tiempo promedio de fallas del Sistema sera de un mes.
3.2. el sistema debe tener la facilidad de recuperabilidad y tolerancia a fallos.
3.3. La disponibilidad del sistema debe ser continua con un nivel de servicio para los usuarios
de 7 dias por 24 horas.
3.4. El sistema cumplirá los procedimientos definidos el el reglamento de la empresa.
4. Rendimiento
4.1. El sistema deberá tener un tiempo máximo de respuesta de 5 segundos para cualquier
operación de consulta.
4.2. La información almacenada o registros realizados podrán ser consultados y actualizados
permanente y simultáneamente; sin que se afecte el tiempo de resultado de cada proceso.
5. Soporte
5.1. El sistema deberá funcionar correctamente para el sistema operativo Windows 10.
5.2. El sistema deberá ser compatible con los navegadores Internet Explorer y chrome.
5.3. El sistema debe disponer de una documentación fácilmente actualizable que permita
realizar operaciones de mantenimiento con el menor esfuerzo posible.
5.4. La interfazdebe estar complementada con un buen sistema de ayuda; La administración
puede recaer en personal con poca experiencia en el uso de aplicaciones informáticas.

6. Consideraciones de diseño
6.1. El sistema necesitará con un mouse y teclado para su correcto funcionamiento.
6.2. La interfaz del usuario debe ajustarse a las características del sistema de la empresa.
6.3. Para un mejor funcionamiento del sistema se requiere una PC con una capacidad mínima
de RAM 4GB, adema debe contar con un procesador que posea 4 nucleos, también debe
contar con por lo menos 15 GB de espacio disponible en la memoria física.
6.4. El sistema será desarrolado en lenguaje c#.
6.5. El sistema deberá utilizar como sistema de gestión de bases de datos MySql.
1. Modelo de casos de uso.

Diagrama general de casos de uso

2. Especificación de casos de usos:

Especificación de caso de uso: ingresar al sistema

1. Breve descripción
Permite ingresar al Usuario al sistema

2. Actores
Almacenero
3. Flujo de eventos
3.1 flujo básico
1. El CU empieza cuando el usuario ingresa con su cuenta al sistema llenando sus datos
(usuario y contraseña).
2. Da clic en el botón ingresar.

3.2 subflujos
Ninguno
3.3 flujos alternativos
 FA1 Si los datos que el usuario proporciona son incorrectos:
 El sistema le envía un mensaje de ERROR (“usuario o contraseña incorrecta”).
 El usuario vuelve a ingresar los datos y da clic en el botón ingresar.
 FA2 Si el usuario no recuerda los datos a ingresar (usuario y/o contraseña):
 Si no recuerda el usuario:
- Si es el Administrador:
--Se comunica con el encargado del software.
-Si no es el Administrador:
--Se comunica con Administrador, quien le dará el nombre del usuario.
 Si no recuerda la contraseña:
El usuario hará clic en el botón
“¡olvidé mi contraseña!”.

4. Precondiciones
 Que el usuario pertenezca al sistema.

5. Pos condiciones
 El usuario ingresa al sistema.

6. Prototipo
 Especificación de caso de uso: Gestionar producto
1. Breve descripción
Permitirá ingresar un nuevo producto, modificarlo, eliminarlo y restaurar los productos
eliminados. Además, permitirá ingresar una nueva categoría que la vez podrá eliminarla y
modificarla
2. Actores
Almacenero
3. Flujo de eventos
3.1 flujo básico
1. El almacenero desea ingresar un nuevo producto.
2. Va al icono de ingreso nuevo producto.
3. El almacenero ingresa los datos requeridos del producto.
4. El sistema verifica que los datos sean validos
5. El sistema verifica que el código sea nuevo
6. El sistema almacena el nuevo producto
7. El almacenero desea conocer los productos registrados.
8. Va a la opción mostrar productos.
9. El almacenero desea consultar un producto seleccionado.
10. El sistema mostrar un formulario con todos los datos del producto seleccionado.
11. El almacenero desea modificar uno o varios productos
12. Va a la opción modificar y se despliega un formulario con todos los productos,
selecciona el producto a modificar y cambiara los datos que desea.
13. El sistema verifica que los datos modificados sean correctos y luego lo almacenera.
14. El almacenero desea eliminar un producto.
15. Va a la opción mostrar productos, se desplegará una lista con todos los productos, luego
selecciona el producto a eliminar y confirma la eliminación.
16. El sistema verifica que no exista stock, y cambia el estado a inactivo o activo.
17. El almacenero desea restaurar un producto
18. El sistema desplegara una lista con los productos eliminados
19. El almacero selecciona los productos a restaura.
20. El sistema cambia el estado de los productos a “activo”
21. El almacenero quiere ingresar nueva categoría
22. El sistema despliega un formulario para el ingreso de categoría
23. El almacenero ingresa la categoría
24. El sistema verifica que la categoría sea valida
25. El sistema verifica que la categoría ingresada no este registrada
26. El sistema almacena la categoría
27. El almacenero desea modificar una categoría registrada
28. El sistema despliega una lista con las categorías ordenadas por código
29. El almacenero selecciona la categoría a modificar
30. El sistema despliega un formulario con la categoría seleccionada en forma editable
31. El almacenero confirma la modificación
32. El sistema verifica que la categoría sea valida
33. El sistema verifica que la nueva categoría no exista
34. El sistema almacena la nueva categoría
35. El almacenero desea eliminar una categoría
36. El sistema despliega la lista de todas las categorías ordenadas por código
37. El almacenero selecciona la categoría a eliminar
38. El sistema muestra un formulario con la categoría a eliminar.
39. El almacenero confirma la eliminación
40. El sistema cambia el estado de categoría de activo a inactivo.

3.2 subflujos
Ninguno
3.3 flujos alternativos
 el sistema detecta un dato invalido al momento de registrar el producto nuevo
se mostrará un mensaje y se volverá al paso 2.
 Si el código existe. El sistema mostrar un mensaje y volverá al paso 2.
 El sistema detecta un dato invalido al momento de modificar un producto se
mostrará un mensaje y va al paso 12.
 Si el sistema detecta productos con stock al momento de eliminar se mostrar
un mensaje y va al paso 15.
 Si el sistema detecta un dato invalido al momento de ingresar nueva categoría
se muestra un mensaje y se vuelve al paso 22.
 Si el sistema determina si la categoría ya existe muestra un mensaje y vuelve
al paso 22.
 Si el sistema detecta un dato no valido al momento de modificar una categoría
se mostrará un mensaje y vuelve al paso 30.
  El sistema verifica que la categoría ya existe muestra un mensaje y vuelve al
paso 30.

4. Precondiciones
 Que exista un producto nuevo a ingresar.
 Que haya la necesidad de modificar, eliminar y restaurar un producto.
 Que exista una categoría nueva a ingresar.
 Que exista la necesidad de modificar y eliminar categoría.

5. Pos condiciones

 Registro de producto correcto

 Modificación de producto correcto.
 Eliminación de producto correcto.
 Restauración de producto correcto.
 Registro de categoría correcta.
 Modificación y eliminación de categoría correcta.

6. Prototipo
Especificación de caso de uso: Gestionar devoluciones
1. Breve descripción
El CU permite al encargado de ventas gestionar las devoluciones de productos.

2. Actor
Vendedor

3. Flujo de eventos
3.1 flujo básico
1. El CU se inicia cuando el encargado de ventas ingresa con su cuenta al sistema.
2. Va a la sección de registro de ventas.
3. Busca la fecha de venta de la prenda que se desea hacer la devolución.
4. El encargado de ventas se asegura que la prenda este dentro de los productos
que aceptan devolución.
 5. El encargado de ventas selecciona visualizar inventario.
6. El sistema muestra las prendas disponibles.
7. El encargado de ventas selecciona la prenda con la misma referencia en una
talla o color distinto.
8. El encargado de ventas registra la devolución.
9. Se genera un ticket de devolución

3.4 subflujos
Ninguno
3.5 flujos alternativos
 <Fecha fuera de Rango>
En el paso 3, si la prenda ya no esta dentro de los 7 días hábiles para su devolución no hay
devolución y finaliza el CU.
 <Producto no acepta devolución>
En el paso 4, si la prenda no acepta devolución finaliza el CU.
 < No hay prenda>
En el paso 7, si no hay prendas con la misma referencia el sistema imprime un ticket de
devolución de dinero y finaliza el caso de uso.

4. Precondiciones
 El encargado de ventas debe tener un usuario y una contraseña.
 Prendas disponibles.

5. Pos condiciones
 El sistema imprime un ticket de devolución que será entregado al cliente
.

6. Requisitos especiales
 Prendas en buen estado
7. Prototipo
 Especificación de caso de uso: Gestionar cardex
1. Breve descripción
Permitirá registrar el ingreso y egreso de los productos.
2. Actores
Almacenero
3. Flujo de eventos
3.1 flujo básico
1. El almacenero desea registrar ingreso de productos al sistema.
2. El sistema despliega formulario de ingreso de productos dejando editable
código y cantidad.
3. El almacenero ingresa el código del producto o los productos que desea
agregar stock.
4. El sistema verifica que el código sea valido y que exista en el sistema.
5. El sistema muestra información de los productos ingresados.
6. El almacenero indica las cantidades para los productos seleccionados.
7. El sistema verifica que la cantidad ingresada sea valida y despliega el
stock total.
8. El almacenero acepta el ingreso de productos.
9. El sistema registra los productos seleccionados y aumenta el stock.
10. El almacenero desea registrar el egreso de productos.
11. El sistema despliega un formulario de egreso de productos dejando
editable el código y cantidad.
 12. El almacenero ingresa el código de los productos que salen de la tienda.
13. El sistema verifica que el código ingresado sea valido y que exista en el
sistema.
14. El sistema muestra la información de el o de los productos seleccionados.
15. El almacenero indica la cantdad para cada producto seleccionado.
16. El sistema verifica que la cantidad ingresada sea valida y despliega el
stock final.
17. El almacenero acepta el egreso de productos.
18. El sistema registra el egreso de los productos y disminuye el stock de los
productos seleccionados.

3.2 subflujos
Ninguno
3.3 flujos alternativos
 si el sistema verifica dato no valido muestra un mensaje y vuelve al
paso 2.
 Si el sistema verifica dato no valido muestra un mensaje y vuelve al
paso 6.
 si el sistema verifica dato no valido muestra un mensaje y vuelve al
paso 11.
 Si el sistema verifica dato no valido muestra un mensaje y vuelve al
paso 15.

4. Precondiciones
 Que exista productos para ingresar.
 que haya salida de productos.
5. Pos condiciones
 Que el ingreso y egreso de productos sea correcta.

6. Prototipo