• Author / Uploaded
• Fernando Restrepo

Citation preview

Diplomado en Aplicaciones Web CORPORACIÓN UNIVERSITARIA COMFACAUCA

Especificación de Requerimientós del Sistema SRS

Integrantes del proyecto Fernando Enrique Restrepo V. Jhon Alexander Astaiza Solarte.

Proyecto OrderCook Facultad de Ingeniería Marzo de 2016

1

Diplomado en Aplicaciones Web TABLA DE CONTENIDO

2

Diplomado en Aplicaciones Web TABLA CONTROL DE VERSIONES

Fecha

Versión

27/Febrero/2016

1.0

Descripción de la Versión Se expone la estructura SRS de “OrderCóók” generando la primera versión entregable del documento.

2.0 3.0

DESCRIPCIÓN DE CAMBIOS RESPONSABLE

APROBADO POR:

Fernando Enrique Restrepo V - “Líder del proyecto”

3

Diplomado en Aplicaciones Web SECCIÓN 1 - INTRODUCCIÓN 1.1 PROPÓSITO A través de este documento se pretende establecer el SRS al proyecto denominado “Order Cóók” aplicandó la nórma IEE830. “Order Cóók” es un sistema de información el cual desea establecer el orden administrativo que se presenta dentro de un restaurante, pretendiendo ahorrar al máximo los recursos tales como información y tiempo. Dando a conocer la necesidad de algunos establecimientos de este tipo, se desea implementar este sistema con el fin de que el cliente acepte que cumplen los requerimientos propuestos para el desarrollo y funcionamiento del sistema. 1.2 ALCANCE “Order Cóók” se caracterizará por ser un sistema de información diseñado mediante una aplicación web donde se podrá controlar, administrar y suplir la información que se obtiene dentro de un restaurante. Ejecutará funciones como:     

Acceso de dos usuarios: Administrador y Funcionario Registro de Proveedores Registro de Compras Registro de Ventas Registro de Inventario

Funciones mediante las cuales se pretende tener seguridad y mantener un orden adecuado de la información reduciendo al máximo la pérdida de ésta. 1.3 DEFINICIONES, SIGLAS Y ABREVIACIONES  IEE: Institute of Electrical and Electronics Engineers (Instituto de Ingenieros Eléctricos y Electrónicos). Es una asociación técnico-profesional mundial dedicada a la estandarización.  Aplicación Web: (Web Application, WebApp). Aplicación que es accedida vía WEB por una RED como Internet o Intranet.  HTML5: (Hyper Text Markup Languaje), lenguaje de programación usado para estructurar y presentar el contenido para la WEB.  HTTP: Hyper text Transfer Protocol (Protocolo de transferencia de hipertexto), es un protocolo de comunicación que permite transferencias de información en la World Wide Web (WWW).

4

Diplomado en Aplicaciones Web 1.4 REFERENCIAS  Norma IEE830 1.5 APRECIACIÓN GLOBAL El documento está organizado en dos secciones, la primera sección está compuesta por ítems en los cuales se especifican cómo se elabora el sistema hasta su alcance. La segunda sección se establece un marco general donde se establecen todas las descripciones del producto. SECCIÓN 2 – DESCRIPCIÓN GENERAL “OrderCóók” es un sistema independiente de ótrós próductós sóftware utilizadós pór el cliente. La perspectiva de “OrderCóók” abarcará: INTERFACES DEL SISTEMA: 

Contendrá dos interfaces donde se enlazarán los módulos de logeo dependiendo el usuario. (Administrador: Genera una vista – Funcionario: Genera otra vista)

INTERFACES DE USUARIO: 

 

Contendrá un menú en el cual podrá navegar mediante hipervínculos hacia los demás componentes/ módulos que contiene el sistema: o Proveedor o Compra o Venta o Inventario El usuario podrá manipular la información de acuerdo a los privilegios que tenga de tal manera que si hay errores; se puedan modificar. Únicamente el privilegio tipo Administrador tiene acceso total de toda la aplicación.

INTERFACES HARDWARE: 

El usó de la aplicación “OrderCóók” será mediante un computador con sistema operativo WINDOWS de cualquier versión (xp/vista/7/8/10) de x84 y x64bits que actuará como servidor tanto de base de datos como de aplicación.

5

Diplomado en Aplicaciones Web INTERFACES SOFTWARE: 

El usuario puede interactuar…

REQUERIMIENTOS DE ADAPTACIÓN: 

La forma de autenticidad del sistema se efectuará mediante login y contraseña; dependiendo del privilegio entre usuarios (Administrador y Funcionario).

2.2 FUNCIONES DEL PRODUCTO

La aplicación deberá permitir realizar lo siguiente:      

Perimir al usuarió tipó “Administradór” manejar el inventarió de lós próductós que se tienen en el restaurante. Permitir al usuarió tipó “Administradór” registrar la cóntabilidad de las ventas realizadas durante la actividad del restaurante. Permitir al usuarió tipó “Administradór” cónsultar, agregar, módificar y eliminar los datos a su placer. Permitir al usuarió tipó “Funciónarió” generar las ventas que se generen durante el tiempo activo que maneje el restaurante. Permitir al usuario tipó “Administradór” cóntrólar el ingresó, módificación y eliminación de los proveedores. Permitir al usuarió tipó “Administradór” cóntrólar el ingresó, módificación y eliminación de funcionarios.

2.3 CARACTERÍSTICAS DEL USUARIO La aplicación web a desarrollar contendrá dos perfiles de acceso: Administrador y Funcionario donde mediante el siguiente esquema se comprenderá mejor sus funciones: 

Administrador: Es aquél que se encargará de manejar el inventario del restaurante. Tiene el derecho de agregar, modificar, eliminar y obtener los datos. Se encarga de realizar las respectivas compras de productos que ingresen al restaurante, dichos datos los podrá agregar al inventario junto con los proveedores que distribuyen aquellos productos. El sistema de información no será de alta complejidad; sin embargo, el administrador debe manejar o conocer bien la función y la experiencia de

6

Diplomado en Aplicaciones Web



administrar inventarios donde se facilitará de alguna manera más el uso de esta aplicación. Para ello se requiere una edad mínima de 18 años. Funcionario: Es aquel encargado de manejar única y exclusivamente las ventas que se realicen en el restaurante. Cabe resaltar que NO tendrá acceso a las funciónes del usuarió tipó “Administradór”. El funcionario debe tener conocimiento en lo relacionado con ventas, como mínimo debe ser bachiller para que tenga el conocimiento mínimo para la manipulación de la aplicación.

2.4 RESTRICCIONES 







Lenguaje de programación. Los lenguajes de programación utilizados para el desarrollo de la aplicación serán mediante HTML y HTML5, JavaScript. Protocolo de comunicación. El protocolo de comunicación utilizado entre el navegador cliente y la aplicación será de HTTP. Seguridad. La seguridad que maneja la aplicación web será mediante los tipos de usuarios disponibles; donde cada usuario tendrá un Login y un Password de autentificación. Requisitos de fiabilidad. La aplicación web se implementará de acuerdo a los requisitos previstos, lo cual permitirá una funcionalidad adecuada y eficaz ofreciéndole al usuario herramientas cohesivas que faciliten su desempeño laboral.

2.5 SUPOSICIONES Y DEPENDENCIAS Los factores que podrían afectar los requerimientos del sistema son:   

Los proveedores entregarán los productos solicitados en el plazo establecido. El producto final cumplirá con los requerimientos y necesidades del cliente final. La velocidad de comunicación entre el administrador, funcionario y sistema; limitará el tiempo de respuesta de la aplicación.

POR PARTE DEL ADMINISTRADOR DEL SISTEMA: En tal caso, se necesitan más recursos para un óptimo funcionamiento de la aplicación ya que el usuario manejará todos los módulos del sistema, dando esto a entender que

7

Diplomado en Aplicaciones Web el sistema se necesita que conste de una adecuada estabilidad para cuando se realicen cambios en alguna de las herramientas o módulos del sistema, se puedan reconfigurar todas las demás. POR PARTE DEL FUNCIONARIO: (Llenar)

SECCIÓN 3 – REQUISITOS ESPECÍFICOS 3.1 INTERFACES EXTERNAS. 3.2 FUNCIONES 3.2.1 ROLES DEL USUARIO EN EL SISTEMA De acuerdo a los tipos de usuarios que se identifican en el documento, se realiza la asignación de funciones para cada uno de estos. Rol Administrador

Funcionario

-

Función Gestionar compras Gestionar proveedores Gestionar productos Gestionar ventas Gestionar categoría Gestionar control de usuarios Gestionar ventas

3.2.2 REQUISITOS FUNCIONALES DEL SISTEMA 1. ADMINISTRADOR/INSERTAR_COMPRA 1.1 Requisito funcional 1. El SISTEMA DEBE PERMITIR INSERTAR UNA COMPRA.

8

Diplomado en Aplicaciones Web CASO DE USO: REFERENCIAS: ACTORES: PRECONDICION: PRIORIDAD:

INSERTAR_COMPRA ADMINISTRADOR INGRESAR AL SISTEMA ALTA

CURSO NORMAL 1. El administrador solicita insertar una nueva compra. 2. El sistema despliega un formulario llamado “Agregar Registro”. 3. El administrador selecciona el producto a agregar. 4. El administrador ingresa la cantidad a comprar. 5. El administrador ingresa el valor de la unidad a comprar. 6. El administrador ingresa la fecha de la compra. 7. El administrador selecciona el nombre del proveedor. 8. El administrador selecciona el nombre del vendedor que realizó la compra. 9. El sistema almacena en la base de datos los registros ingresados. ALTERNATIVAS 1. El administrador cancela la operación y este caso de uso termina. 2. Si el administrador desea editar la compra, se ejecuta el caso de uso Editar_Compra y este caso de uso continúa. 3. Si el administrador desea eliminar la compra, se ejecuta el caso de uso Eliminar_Compra y este caso de uso continúa. EXCEPCIONES 1. Se deben llenar los campos obligatorios*, de lo contrario el sistema pedirá llenarlos obligatoriamente. 2. Los campos Producto, Cantidad a comprar, Valor unidad, Fecha compra, Proveedor, compra “Hecha por”, se deben llenar de acuerdo al tipo de dato que correspondan, de lo contrario el sistema desplegará un mensaje de error.

OBSERVACIONES 1. Producto: (Entero) 2. Cantidad a comprar: (Entero) 3. Valor unidad: (Doble) 4. Fecha compra: (Fecha) 5. Proveedor: (Entero) Cantidad Compra: (Entero) 6. Hecha por: (Entero)

OBSERVACIONES

OBSERVACIONES

9

Diplomado en Aplicaciones Web 2. ADMINISTRADOR/EDITAR_COMPRA 2.1 Requisito funcional 2. El SISTEMA DEBE PERMITIR EDITAR UNA COMPRA

CASO DE USO:

EDITAR_COMPRA

REFERENCIAS: ACTORES: PRECONDICION: PRIORIDAD:

ADMINISTRADOR SE DEBE HABER INSERTADO UNA COMPRA MEDIA

CURSO NORMAL

1. El administrador solicita editar una compra. 2. El sistema despliega el formulario “Agregar registro”. 3. El sistema muestra los campos (Producto, Cantidad a 4. 5.

comprar, Valor unidad, Fecha compra, Proveedor, compra “Hecha por”) llenos, los cuales serán editables. El administrador modifica los campos. El sistema almacena en la base de datos los nuevos registros ingresados.

ALTERNATIVAS 1. El administrador cancela la operación y este caso de uso termina. 2. Si el administrador desea insertar una compra, se ejecuta el caso de uso Insertar Compra y este caso de uso continúa. 3. Si el administrador desea eliminar una compra, se ejecuta el caso de uso Eliminar_Compra y este caso de uso continúa. EXCEPCIONES 1. Se deben llenar los campos obligatorios*, de lo contrario el sistema pedirá llenarlos obligatoriamente. 2. Los campos Producto, Cantidad a comprar, Valor unidad, Fecha compra, Proveedor, compra “Hecha por”, se deben llenar de acuerdo al tipo de dato que correspondan, de lo contrario el sistema desplegará un mensaje de error.

OBSERVACIONES 1. Producto: (Entero) 2. Cantidad a comprar: (Entero) 3. Valor unidad: (Doble) 4. Fecha compra: (Fecha) 5. Proveedor: (Entero) 6. Cantidad Compra: (Entero) 7. Hecha por: (Entero) OBSERVACIONES

OBSERVACIONES

10

Diplomado en Aplicaciones Web 3. ADMINISTRADOR/ELIMINAR_COMPRA 3.1 Requisito funcional 3.

CASO DE USO: REFERENCIAS: ACTORES: PRECONDICION: PRIORIDAD:

ELIMINAR_COMPRA ADMINISTRADOR SE DEBE HABER INSERTADO UNA COMPRA MEDIA

CURSO NORMAL 1. El administrador solicita eliminar una compra. 2. El sistema despliega un recuadro de confirmación. 3. El administrador confirma orden. 4. El sistema almacena en la base de datos los cambios realizados. ALTERNATIVAS 1. El administrador cancela la operación y este caso de uso termina. 2. Si el administrador desea crear una compra, se ejecuta el caso de uso Crear_Compra y este caso de uso continúa. 3. Si el administrador desea insertar una compra, se ejecuta el caso de uso Insertar_Compra y este caso de uso continúa. 4. Si el administrador desea editar una compra, se ejecuta el caso de uso Editar_Compra y este caso de uso continúa. EXCEPCIONES 1. De no seleccionar el registro a eliminar, el sistema despliega un mensaje erróneo al no haber seleccionado un registro.

OBSERVACIONES Eliminar:

OBSERVACIONES

OBSERVACIONES

11

Diplomado en Aplicaciones Web 4. ADMINISTRADOR/INSERTAR_PROVEEDOR 4.1 Requisito funcional 4. EL SISTEMA DEBE INSERTAR UN PROVEEDOR.

CASO DE USO: REFERENCIAS: ACTORES: PRECONDICION: PRIORIDAD:

INSERTAR_PROVEEDOR ADMINISTRADOR INGRESAR EN EL SISTEMA ALTA

CURSO NORMAL

1. 2. 3. 4. 5. 6. 7.

El administrador solicita insertar proveedor. El sistema despliega un formulario llamado “Agregar registro”. El administrador ingresa el nombre del proveedor. El administrador ingresa la dirección del proveedor. El administrador ingresa el teléfono del proveedor. El administrador ingresa la ciudad del proveedor. El sistema guarda en la base de datos los registros ingresados.

OBSERVACIONES 1. Nombre Proveedor: (Carácter) 2. Dirección: (Carácter) 3. Teléfono: (Carácter) 4. Ciudad: (Carácter)

ALTERNATIVAS 1. El administrador cancela la operación y este caso de uso termina. 2. Si el administrador desea editar un proveedor, se ejecuta el caso de uso Editar_Proveedor y este caso de uso continúa. 3. Si el administrador desea eliminar un proveedor, se ejecuta el caso de uso Eliminar_Proveedor y este caso de uso continúa.

OBSERVACIONES

EXCEPCIONES Se deben llenar los campos obligatorios* y que concuerden con el tipo de dato establecido en la base de datos, de lo contrario el sistema pedirá llenarlos obligatoriamente, o mostrara un mensaje de dato incorrecto.

OBSERVACIONES

12

Diplomado en Aplicaciones Web 5 ADMINISTRADOR/EDITAR_PROVEEDOR 5.1 Requisito Funcional 5. EL SISTEMA DEBE EDITAR PROVEEDOR

CASO DE USO: REFERENCIAS: ACTORES: PRECONDICION: PRIORIDAD:

EDITAR_PROVEEDOR ADMINISTRADOR SE DEBE HABER INSERTADO UN PROVEEDOR MEDIA

CURSO NORMAL 1. El administrador solicita editar una compra. 2. El sistema despliega el formulario “Agregar registro”. 3. El sistema muestra los campos (Nombre, Dirección, Teléfono, Ciudad) llenos, los cuales serán editables. 4. El administrador modifica los campos. 5. El sistema almacena en la base de datos los nuevos registros ingresados.

OBSERVACIONES Nombre Proveedor: (Carácter) Dirección: (Carácter) Teléfono: (Carácter) Ciudad: (Carácter)

ALTERNATIVAS 1. El administrador cancela la operación y este caso de uso termina. 2. Si el administrador desea insertar un proveedor, se ejecuta el caso de uso Insertar_Proveedor y este caso de uso continúa. 3. Si el administrador desea eliminar un proveedor, se ejecuta el caso de uso Eliminar_Proveedor y este caso de uso continúa. EXCEPCIONES 1. Se quiere editar un registro sin seleccionarlo, el sistema emite alerta “Seleccionar registro”

OBSERVACIONES

OBSERVACIONES

13

Diplomado en Aplicaciones Web 6. ADMINISTRADOR /ELIMINAR_PROVEEDOR 6.1 Requisito funcional 6. El SISTEMA DEBE ELIMINAR PROVEEDOR CASO DE USO: REFERENCIAS: ACTORES: PRECONDICION: PRIORIDAD:

ELIMINAR_PROVEEDOR ADMINISTRADOR SE DEBE HABER INSERTADO UN PROVEEDOR MEDIA

CURSO NORMAL 1. El administrador solicita eliminar un proveedor. 2. El sistema despliega un recuadro de confirmación. 3. El administrador confirma orden. 4. El sistema almacena en la base de datos los cambios realizados. ALTERNATIVAS 1. El administrador cancela la operación y este caso de uso termina. 2. Si el administrador desea insertar un proveedor, se ejecuta el caso de uso Insertar_Proveedor y este caso de uso continúa. 3. Si el administrador desea editar un proveedor, se ejecuta el caso de uso Editar_Proveedor y este caso de uso continúa. EXCEPCIONES Si se ejecuta la opción eliminar sin seleccionar un registro de usuario, el sistema muestra una alerta “Seleccione un registro para poder eliminar”

OBSERVACIONES

OBSERVACIONES

OBSERVACIONES

7. ADMINISTRADOR/INSERTAR_PRODUCTO 7.1 Requisito funcional 7. EL SISTEMA DEBE INSERTAR PRODUCTO

14

Diplomado en Aplicaciones Web

CASO DE USO: REFERENCIAS: ACTORES: PRECONDICION: PRIORIDAD:

INSERTAR_PRODUCTO ADMINISTRADOR INGRESAR AL SISTEMA ALTA

CURSO NORMAL 1. El administrador solicita insertar en el inventario un producto. 2. El sistema despliega un formulario llamado “Agregar Registro”. 3. El administrador selecciona el producto a agregar. 4. El administrador selecciona la categoría del producto. 5. El administrador ingresa la cantidad a almacenar. 6. El administrador selecciona el proveedor a agregar. ALTERNATIVAS 1. El administrador cancela la operación y este caso de uso termina. 2. Si el administrador desea editar un producto, se ejecuta el caso de uso Editar_Producto y este caso de uso continúa. 3. Si el administrador desea eliminar el producto, se ejecuta el caso de uso Eliminar_Producto y este caso de uso continúa. EXCEPCIONES Se deben llenar los campos obligatorios* y que concuerden con el tipo de dato establecido en la base de datos, de lo contrario el sistema pedirá llenarlos obligatoriamente, o mostrara un mensaje de dato incorrecto.

OBSERVACIONES

OBSERVACIONES

OBSERVACIONES

15

Diplomado en Aplicaciones Web 8. ADMINISTRADOR-FUNCIONARIO/INSERTAR_VENTA

8.1 Requisito funcional 8. EL SISTEMA DEBE PERMITIR INSERTAR VENTAS.

CASO DE USO: REFERENCIAS: ACTORES: PRECONDICION: PRIORIDAD:

INSERTAR_VENTA ADMINISTRADOR/FUNCIONARIO LOS ACTORES SE DEBEN HABER AUTENTICADO EN EL SISTEMA ALTA

CURSO NORMAL

OBSERVACIONES

1. El administrador/funcionario solicitan insertar una venta. 2. El sistema despliega un formulario llamado “Agregar Venta”. 3. El administrador/ funcionario seleccionan la cantidad a agregar. 4. El administrador/ funcionario seleccionan el valor unitario a insertar. 5. El administrador/ funcionario ingresan la fecha. 6. El administrador/ funcionario seleccionan el vendedor. ALTERNATIVAS 1. El administrador/funcionario cancela la operación y este caso de uso termina. 2. Si el administrador/ funcionario desea editar una venta, se ejecuta el caso de uso Editar_Venta y este caso de uso continúa. 3. Si el administrador/ funcionario desea eliminar una venta, se ejecuta el caso de uso Eliminar_Venta y este caso de uso continúa. EXCEPCIONES

OBSERVACIONES

OBSERVACIONES

Se deben llenar los campos obligatorios* y que concuerden con el tipo de dato establecido en la base de datos, de lo contrario el sistema pedirá llenarlos obligatoriamente, o mostrara un mensaje de dato incorrecto.

16

Diplomado en Aplicaciones Web 9. ADMINISTRADOR-FUNCIONARIO/EDITAR_VENTA

9.1

Requisito funcional 9.

EL SISTEMA DEBE EDITAR UNA VENTA.

CASO DE USO:

EDITAR_VENTA

REFERENCIAS: ACTORES: PRECONDICION: PRIORIDAD:

ADMINISTRADOR /FUNCIONARIO SE DEBE HABER INSERTADO UNA VENTA MEDIA

CURSO NORMAL

1. 2. 3.

OBSERVACIONES

El administrador solicita editar una venta. El sistema despliega el formulario “Agregar Venta”.

El sistema muestra los campos (Producto, Cantidad, Valor unitario, Fecha, Vendedor) llenos, los cuales serán editables. 4. El administrador modifica los campos. 5. El sistema almacena en la base de datos los nuevos registros ingresados. ALTERNATIVAS 1. El administrador cancela la operación y este caso de uso termina. 2. Si el administrador desea insertar un producto, se ejecuta el caso de uso Insertar_Producto y este caso de uso continúa. 3. Si el administrador desea eliminar un producto, se ejecuta el caso de uso Eliminar_Producto y este caso de uso continúa. EXCEPCIONES

OBSERVACIONES

OBSERVACIONES

Se quiere editar un registro sin seleccionarlo, el sistema emite alerta “Seleccionar registro”

17