Proyecto Kioskito v2
Proyecto Kioskito v2
Proyecto Kioskito v2
Propuesta de Proyecto
Design Thinking
Proyecto: “Pedidos Duoc”
Revisión: [03]
13/09/2018
Contenido
FICHA DEL DOCUMENTO 3
1. INTRODUCCIÓN 5
1.1. PROPÓSITO 5
1.2. ÁMBITO DEL SISTEMA 5
1.3. DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS 5
1.4. REFERENCIAS 5
1.5. VISIÓN GENERAL DEL DOCUMENTO 5
2. DESCRIPCIÓN GENERAL 6
3. REQUISITOS ESPECÍFICOS 8
2
Especificación de Requisitos, estándar de IEEE 830
3
Especificación de Requisitos, estándar de IEEE 830
Nombre Integrante
Nicole Casanova
Claudio Cortés
Manuel Diaz
Pedro Farias
Javier Gutiérrez
Rodolfo Villalobos
4
Especificación de Requisitos, estándar de IEEE 830
1. Introducción
En este informe de requerimientos se le dará solución a la problemática planteada por el docente
Fernando Sepúlveda en la sede Duoc Padre Alonso de Ovalle del instituto profesional Duoc UC, con
respecto al atochamiento de gente que se encuentra en el quiosco de la sede anteriormente
mencionada, en los descanso que existen entre clases y, ocasionalmente, durante las mismas
clases, provocando así una larga demora en el proceso de compra de productos por su parte.
1.1. Propósito
En este documento, se entregará una propuesta de solución a la problemática entregada por el
stakeholder (cliente) Fernando Sepúlveda con respecto al atochamiento que hay en el quiosco de
la sede Duoc Padre Alonso de Ovalle durante los recesos entre clases que le quita tiempo al bajar
al primer piso a realizar compras para alimentarse durante el desarrollo de sus clases.
• El sistema deberá ser capaz de registrar nuevos usuarios a través de un mail y contraseña
dada por estos. Paralelamente, se comprobará que la dirección sea perteneciente a Duoc UC y de
un usuario tipo docente. Luego del registro se guardará el nombre, el teléfono, las aulas en las que
imparte clases, y por último el medio de pago con el que realizará las compras (tarjetas de débito
o crédito). La app debe ser capaz de guardar el número de la tarjeta y al momento de la compra
solo solicitar la clave numérica de esta y la confirmación de la compra mostrando todos los
productos que ha agregado al carrito.
• Por otra parte, el sistema debe entregar en tiempo real el pedido solicitado por el docente
al personal del quiosco a través de una interfaz web destinada para ello, donde podrán ver el
producto, la cantidad, el nombre del docente que solicitó, y si este será para retiro en el quiosco o
entrega en el aula previamente seleccionada por el docente.
• La app debe estar en línea con el control de stock que tiene el quiosco para que en caso de
que un producto se haya agotado, esta arroje un mensaje indicando que el producto solicitado no
se encuentra disponible, anulando así la posibilidad de agregarlo al carro de compras.
5
Especificación de Requisitos, estándar de IEEE 830
1.4. Referencias
● IEEE830
http://wikis.fdi.ucm.es/ELP/Especificaci%C3%B3n_de_Requisitos_Software_seg%C3%BAn
_el_est%C3%A1ndar_IEEE_830
● Xamarin https://visualstudio.microsoft.com/es/xamarin/
6
Especificación de Requisitos, estándar de IEEE 830
2. Descripción General
El contexto que rodea los requisitos y los factores que afectan al producto que proponemos
desarrollar como solución, son los siguientes:
Esto permitirá que el control de stock del quiosco sea de forma digital, de tal forma que no haya
intervención del personal a menos que se desee ingresar el nuevo stock entrante. A
medida que se vayan generando compras, el stock irá disminuyendo y al llegar a la
cantidad de 15 arrojará una ventana emergente avisando al trabajador que tal producto
está a punto de agotarse y finalmente al llegar a 0 no se podrán generar más ventas de
este producto.
2. Página web que permita recibir los pedidos por parte del personal:
Esta página web estará ligada al actual sistema que tienen los trabajadores del quiosco y su
función principal será recibir los pedidos, guardar el estado de estos (recibido o
entregado).
7
Especificación de Requisitos, estándar de IEEE 830
Aplicación que permitirá registrar usuarios, almacenar información, ver productos, promociones y
generar pedidos.
4. Registro:
Esta función permitirá a los usuarios registrarse una única vez en la aplicación solicitando
información tal como: usuario y contraseña, nombre, apellido, teléfono, y número de
tarjeta que desea asociar.
5. Selección de productos:
Esta función permitirá elegir los productos que desea comprar y visualizar promociones que
puedan existir, además de esto, poder seleccionar la cantidad de dicho producto y ver sus
precios.
6. Carrito de compra:
En esta opción visualizará todos los productos seleccionados, la cantidad, precios individuales y
total a pagar por la compra. En caso de haber seleccionado una promoción también se
indicará en el detalle.
Además de esto, también tendrá la opción de eliminar productos del carrito o disminuir y/o
aumentar la cantidad seleccionada de estos.
7. Confirmar compra:
Al confirmar la compra la aplicación solicitará la clave o pin de la tarjeta asociada a esta, saber si
desea el producto para retiro o recibir en aula y por último en caso de seleccionar esta
última opción, el número del aula.
● Docente: Será el actor principal de la APP, ya que será el encargado de registrarse dentro
de esta, llenar la información solicitada, seleccionar los productos que desea comprar,
confirmar el aula en el que se encuentra, y confirmar e ingresar el pin de la tarjeta que
seleccionó anteriormente como medio de pago.
● Encargado del quiosco: Será el encargado de recibir los pedidos y confirmar el estado de
estos, ya sea recibido o entregado, además tiene que entregar el pedido en la sala
requerida en el caso de despacho.
8
Especificación de Requisitos, estándar de IEEE 830
● Administrador del quiosco: Corresponde a la persona que supervisa a los trabajadores del
quiosco. Será el encargado de agregar las promociones y modificar los precios de los
productos en caso de ser necesario.
A continuación se presenta una tabla con las características generales de los usuarios del
producto, incluyendo nivel educacional que por lo general poseen, y la experiencia de campo y
experiencia técnica que deben poseer para utilizar este sistema.
9
Especificación de Requisitos, estándar de IEEE 830
2.4. Restricciones
Esta subsección describe aquellas limitaciones que se imponen sobre los desarrolladores del
producto:
• Limitaciones del hardware: los requisitos mínimos de PC son un All In One con un
procesador intel Celeron de 1.6 Ghz Dual Core, 4 Gb de memoria RAM, y un disco duro con
capacidad de almacenamiento de 500 Gb.
• El sistema guardará el número de tarjeta que se asocia a la aplicación pero nunca su pin.
10
Especificación de Requisitos, estándar de IEEE 830
11
Especificación de Requisitos, estándar de IEEE 830
3. Requisitos Específicos
● Como requisito principal, el cliente espera que la forma de comprar en el quisco Duoc sea
más rápida y expedita, así evitando el atochamiento de gente que espera comprar, la
demora que esto pueda generarle al llegar a las aulas y el no poder salir de estas y dejar al
alumnado solo.
● Que la app esté sincronizada con el quiosco Duoc, específicamente con el sistema de
inventario.
● Que la app funcione tanto para Android como para iOS.
● Que la app sea de uso personal y exclusivo de los docentes de Duoc Uc sede Padre Alonso
de Ovalle.
● Que tenga un usuario y contraseña determinada por el usuario.
● Que el email asociado a la cuenta sea del dominio exclusivo profesores.duoc.cl
● Que esta pueda tener asociada una tarjeta de credito o debito para generar compras.
● Que cuente con un carrito de compras.
● Que tenga un catálogo de los productos.
● Que junto a los productos aparezcan sus precios.
● Que se pueda recuperar contraseña en caso de olvidarla.
● Que posea un buscador de productos.
● Que se pueda modificar o eliminar lo ya existente en una sección de “check out” antes del
pago.
● Poder tener una sección de productos favoritos dentro de la App.
● Que funcione sincronizadamente con las ventas presenciales del quiosco.
● Que se cree una web destinada a solo recibir pedidos por parte de los empleados del
quiosco.
● Que arroje una alerta cuando la cantidad de stock de un producto sea igual o menor a 15 a
los empleados del quiosco.
● Que la App arroje una alerta al usuario cuando se intente comprar un producto y este no
tenga stock.
● Que a los empleados del quiosco les llegue una alerta en tiempo real del pedido solicitado
por algún docente.
● Que la compra tenga la opción de despacho a la sala o retiro en quiosco.
● Que estos puedan ver dentro de los pedidos si el pedido deben entregarlo en aula o el
docente lo retirara.
● Que los empleados del quiosco puedan cambiar el estado de los pedidos de “recibido” a
“entregado”.
● Que la app utilice los colores corporativos de Duoc UC.
● Que cada compra deba ser verificada o aprobada en el quiosco por algún empleado para
evitar problemas por falta de stock.
● Que cada proceso de respuesta de la app no tome más de 0.5 segundos.
● Que la app permita el pago en línea mediante el uso de Webpay o Mach.
12
Especificación de Requisitos, estándar de IEEE 830
Más adelante, en las Matrices de especificación de requerimientos, se detallarán cada uno de ellos
en forma más Técnica en los puntos: 3.1, 3.2 y 3.3.
Esta sección contiene los requisitos a un nivel de detalle suficiente como para permitir a los
diseñadores diseñar un sistema que satisfaga estos requisitos, y que permita al equipo de pruebas
planificar y realizar las pruebas que demuestren si el sistema satisface, o no, los requisitos. Todo
requisito aquí especificado describirá comportamientos externos del sistema, perceptibles por
parte de los usuarios, operadores y otros sistemas.
• Todo requisito deberá ser unívocamente identificable mediante algún código o sistema de
numeración adecuado.
• Lo ideal, aunque en la práctica no siempre realizable, es que los requisitos posean las
siguientes características:
− Corrección: La ERS es correcta si y sólo si todo requisito que figura aquí (y que será
implementado en el sistema) refleja alguna necesidad real. La corrección de la ERS implica
que el sistema implementado será el sistema deseado.
− No ambiguos: Cada requisito tiene una sola interpretación. Para eliminar la ambigüedad
inherente a los requisitos 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 requisitos relevantes han sido incluidos en la ERS. Conviene incluir
todas las posibles respuestas del sistema a los datos de entrada, tanto válidos como no
válidos.
− Consistentes: Los requisitos no pueden ser contradictorios. Un conjunto de requisitos
contradictorio no es implementable.
− Clasificados: Normalmente, no todos los requisitos son igual de importantes. Los
requisitos pueden clasificarse por importancia (esenciales, condicionales u opcionales) 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 ERS es verificable si y sólo 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,
13
Especificación de Requisitos, estándar de IEEE 830
verificable. Expresiones como a veces, bien, adecuado, etc. Introducen ambigüedad en los
requisitos. Requisitos como “en caso de accidente la nube tóxica no se extenderá más allá
de 25 Km" no es verificable por el alto costo que conlleva.
− Modificables: La ERS es modificable si y sólo si se encuentra estructurada de forma que los
cambios a los requisitos pueden realizarse de forma fácil, completa y consistente. La
utilización de herramientas automáticas de gestión de requisitos facilitan enormemente
esta tarea.
− Trazables: La ERS es trazable si se conoce el origen de cada requisito y se facilita la
referencia de cada requisito a los componentes del diseño y de la implementación. La
trazabilidad hacia atrás indica el origen (documento, persona, etc.) de cada requisito. La
trazabilidad hacia delante de un requisito R indica que componentes del sistema son los
que realizan el requisito R.
Por otra parte la interfaz web que usarán los empleados del quiosco Duoc deberá ser simple, ya
que solo debe contener una notificación que debe resaltar sobre las demás opciones, el listado de
las ventas del día, el detalle de estas y por último un botón para cambiar el estado del pedido de
recibido a entregado.
Por otra parte, los requisitos mínimos de los dispositivos móviles que correrán la app, son
memoria RAM de 4 Gb, 64 Gb de memoria, 8 procesadores. Es decir, dispositivos móviles de gama
media.
− Descripción del producto software utilizado: app y sitio web anexado a sistema de
quiosco.
− Propósito del interfaz:
a) App: permite al docente comprar productos.
14
Especificación de Requisitos, estándar de IEEE 830
15
Especificación de Requisitos, estándar de IEEE 830
16
Especificación de Requisitos, estándar de IEEE 830
17
Especificación de Requisitos, estándar de IEEE 830
18
Especificación de Requisitos, estándar de IEEE 830
19
Especificación de Requisitos, estándar de IEEE 830
20
Especificación de Requisitos, estándar de IEEE 830
21
Especificación de Requisitos, estándar de IEEE 830
22
Especificación de Requisitos, estándar de IEEE 830
23
Especificación de Requisitos, estándar de IEEE 830
24
Especificación de Requisitos, estándar de IEEE 830
25
Especificación de Requisitos, estándar de IEEE 830
3.3.2 Seguridad
Se sugiere la utilización de Bit Defender para proteger los PC de los usuarios contra amenazas en
Windows, detección de malware, optimización de rendimiento y protección contra ransomware.
Defina:
26
Especificación de Requisitos, estándar de IEEE 830
apenas ayuda a prevenir que nos roben la cuenta. En cambio, se dirigirá a los usuarios a
crear una contraseña realmente fuerte.
− Comprobaciones de integridad de información crítica en la base de datos: adoptaremos
procedimientos recomendados, como Security Requirements for Data
Management (Requerimientos de seguridad para la gestión de datos), descrito en la
sección de Entrega y soporte (DS, Deliver and Support) 11.6 de COBIT (Objetivos de control
para la TI y tecnologías afines), junto con los procedimientos indicados en la
correspondiente sección de la guía de aseguramiento IT Assurance Guide: Using COBIT.
3.3.3 Fiabilidad
Es importante mencionar que esta aplicación no debería presentar ningún tipo de falla que afecte
en su funcionamiento. Los errores esperados son solo cuando el usuario no tenga acceso a
internet. En caso de una falla al sistema, contamos con una persona encargada de revisar de
manera inmediata o lo más pronto posible al detectar la falla. En caso de mantención y/o
actualizaciones, esto se hará fuera del horario de clases que está descrito en el punto 3.3.4.
3.3.4 Disponibilidad
Nuestra App debe tener una disponibilidad de 100% durante los horarios de clases de Duoc Uc.
Durante los horarios que no se están realizando clases, se podrá acceder a todas las opciones de la
App pero no generar ninguna compra.
3.3.5 Mantenibilidad
Nuestro sistema al estar conectado a la base de datos de Duoc y del Quiosco, necesitará una
mantención semestral en el caso que se deba actualizar la información de docentes (cambios de
email, nuevas contrataciones etc) y mensual en el caso del Quiosco, ya que el stock de este puede
ir variando mes a mes en distintas proporciones.
3.3.6 Portabilidad
Especificación de atributos que debe presentar el software para facilitar su traslado a otras
plataformas o entornos. Pueden incluirse:
27
Especificación de Requisitos, estándar de IEEE 830
4. Propuesta de Planificación
En cuanto a las buenas prácticas, nos guiaremos por la metodología Ágil Kanban.
Nombre Integrante
Nicole Casanova
Claudio Cortés
Manuel Diaz
Pedro Farias
Javier Gutiérrez
Rodolfo Villalobos
28
Especificación de Requisitos, estándar de IEEE 830
29
Especificación de Requisitos, estándar de IEEE 830
QA 1.5 70 105
TOTAL 1072.4
$29,306,547
30
Especificación de Requisitos, estándar de IEEE 830
[ Obs.
Insertar Descripción de los aspectos del desarrollo en los que se permitirá aplicar cambios como
parte del Desarrollo del Software definiendo sus alcances y limitaciones asociadas.
El control de cambios es una actividad paralela al desarrollo del proyecto que responde a eventos
que surgen del mismo, sea por requerimientos propios del usuario o por mejoras o correcciones
detectadas por el mismo equipo del proyecto.
Se describe de manera independiente de las demás fases de la metodología pues puede ser
aplicada indistintamente a proyectos en marcha o proyectos ya implementados, y porque es
necesario resaltar su importancia y no relegarla como una actividad posterior al desarrollo, sino
reconocerla como una actividad que debe estar definida, presente y es crítica desde el inicio del
proyecto. Deberá describir qué tipo aspectos Funcionalidades y no funcionales se podrán
modificar con cambio, en qué instancia de proyecto se podrán aplicar y qué motivos los validarían
para ser aplicables y en qué caso no será posible aplicar cambios.
Luego esto se debe complementar con la observación de que en el anexo encontrarán la Planilla
de Control de Cambio con los Tipos de Cambio que podrán aplicarse en la cual posteriormente se
debe completar la planilla al ejecutarse la instancia. ]
5. Anexos
31
Especificación de Requisitos, estándar de IEEE 830
32
Especificación de Requisitos, estándar de IEEE 830
33
Especificación de Requisitos, estándar de IEEE 830
34
Especificación de Requisitos, estándar de IEEE 830
35
Especificación de Requisitos, estándar de IEEE 830
36
Especificación de Requisitos, estándar de IEEE 830
37
Especificación de Requisitos, estándar de IEEE 830
38
Especificación de Requisitos, estándar de IEEE 830
39