DUOC UC - ESCUELA DE INFORMÁTICA Y TELECOMUNICACIONES

Propuesta de Proyecto
Design Thinking
Proyecto: “Pedidos Duoc”
Revisión​: [03]
13/09/2018

Especificación de Requisitos según estándar de IEEE 830.

 Especificación de Requisitos, estándar de IEEE 830

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

2.1. PERSPECTIVA DEL PRODUCTO 6

2.2. FUNCIONES DEL PRODUCTO 6
2.3. CARACTERÍSTICAS DE LOS USUARIOS 6
2.4. RESTRICCIONES 6
2.5. SUPOSICIONES Y DEPENDENCIAS 7
2.6. REQUISITOS FUTUROS 7

3. REQUISITOS ESPECÍFICOS 8

3.1 REQUISITOS COMUNES DE LAS INTERFACES 9

3.1.1 Interfaces de usuario 9
3.1.2 Interfaces de hardware 9
3.1.3 Interfaces de software 9
3.1.4 Interfaces de comunicación 9
3.2 REQUISITOS FUNCIONALES 9
3.3 REQUISITOS NO FUNCIONALES 10
3.3.1 Requisitos de rendimiento 10
3.3.2 Seguridad 10
3.3.3 Fiabilidad 11
3.3.4 Disponibilidad 11
3.3.5 Mantenibilidad 11
3.3.6 Portabilidad 11
3.4 OTROS REQUISITOS 11

4. PROPUESTA INICIAL PLANIFICACIÓN 12

4.1 DESCRIPCIÓN GENERAL ACERCA DE LA PLANIFICACIÓN 12
4.1.2 Definición de Actividades principales del Proyecto 12
4.1.3 Estructura EDT 12
4.2 PLAN DE CONTROL DE CAMBIO 12
5. ANEXOS 14

2
 Especificación de Requisitos, estándar de IEEE 830

5.1 Acta de Proyecto 14

5.2 Matriz Especificación de Requerimientos 14
5.3 Diagrama de Casos de Uso General 14
5.4 Planilla Casos de Uso 14
5.5 Prototipado de Software 14
5.6 Resultado Análisis de Calidad Diagramas Modelamiento 14
5.7 Resultado Análisis de Calidad Prototipado No funcional del Sistema 14
5.8 Planilla Control de Cambio 14
5.9 Planilla Control de Cambio 14

Ficha del documento

Fecha Revisión Autor Modificación

05-09-2018 1.0 Nicole Casanova Inician ingreso de datos en ERS.

Manuel Diaz, Javier Gutiérrez, Modificación documento V1, doc pasa

06-09-2018 2.0
Claudio Cortés. a V2.

09-09-2018 2.1 Javier Gutiérrez Corrección de Datos.

Corrección de Datos, actualización en

11-09-2018 2.2 Pedro Farías
punto 2.1-2.3.

Se agregan imágenes casos de uso y

12-09-2018 2.3 Pedro Farías se llena planilla casos de uso (puntos
5.3 y 5.4 respectivamente.

Se corrigen más datos y se revisa y

14-09-2018 2.4 Javier Gutiérrez corrige y actualiza sección de
requerimientos.

3
 Especificación de Requisitos, estándar de IEEE 830

Integrantes del Equipo

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.

La solución ofrecida es implementar un sistema que permita realizar el proceso de compra de

productos de manera digital, permitiendo a la vez, que el docente reciba su pedido en la sala
mediante un servicio de despacho, disminuyendo de este modo con creces el tiempo utilizado en
comprar productos alimenticios y permitiéndole focalizarse mejor en lo que realmente le
compete: el desarrollo de la clase.

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.

1.2. Ámbito del Sistema

• Nombre del Sistema: P.D. (Pedidos Duoc)

• 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.3. Definiciones, Acrónimos y Abreviaturas

● Stakeholder​: personas, empresas o departamentos interesados en el desarrollo de un
proyecto.

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/

1.5. Visión General del Documento

En esta subsección se describen brevemente los contenidos y la organización del resto de la ERS.
Siguiendo con el orden de lectura del ERS se encuentra la “Descripción general” en donde se
explican las características del producto, se definen los usuarios y sus facultades, se indican las
restricciones del producto y también los posibles requerimientos futuros del sistema. Luego
encontramos los “Requisitos específicos” en donde serán especificados los requisitos funcionales y
no funcionales, señalando los aspectos de seguridad; fiabilidad; disponibilidad; mantenibilidad del
sistema. A continuación, se encuentra la “Propuesta inicial de planificación”. Aquí se explica cómo
se va a ejecutar el desarrollo del proyecto, las tareas de los integrantes del desarrollo y
responsabilidades graficados en la carta Gantt. Finalmente, se encuentra el apartado de anexos en
donde se adjuntan imágenes de las maquetas del proyecto, casos de uso de las interacciones de
usuarios con el sistema, y diagramas Gantt entre otros.

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:

● Control de stock digitalizado

● App que permita registro de usuarios y almacenamiento de información.
● Dentro de la App mostrar productos y promociones.
● Carrito de compras.
● Interfaz web que muestre a los trabajadores del quiosco notificaciones de pedidos y el
detalle de estos.

2.1. Perspectiva del Producto

El producto propuesto como solución a esta problemática es una aplicación que permita a los
docentes realizar compras desde sus dispositivos móviles con la posibilidad de retirar en el mismo
quiosco sus productos o recibirlos en la sala de clase en la cual se encuentren. Es también un sitio
web para los dependientes del quiosco en el cual podrán visualizar y confirmar los pedidos. Por
último, el sitio web tendrá un usuario asignado al administrador del kiosco en donde tendrá la
facultad de modificar los precios y promociones de los productos .

2.2. Funciones del Producto

El resumen de las funciones del futuro sistema es el siguiente:

1. Control de stock digitalizado:

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

3. App Quiosco Duoc:

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.

2.3. Características de los Usuarios

Los tipos de usuarios que utilizarán nuestro sistema son 2: Profesores y personal del quiosco.

● 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.

USUARIO NIVEL EDUCACIONAL EXPERIENCIA EXPERIENCIA

TÉCNICA

Docente Técnico Desde 4 años Computación

superior/Profesional/Maestría/Doctorad nivel usuario
o común

Trabajador del Enseñanza media o Técnico superior Desde 0 años Computación

kiosco nivel usuario
común

Administrador Técnico superior/Profesional Desde 0 años Computación

nivel usuario
común

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.

● Limitaciones de Sistema Operativo: El sistema operativo bajo el cual correrá el sistema

será Windows 10.

• Operaciones paralela: ninguna

• Lenguaje(s) de programación: el lenguaje de programación bajo el cual estará escrito el

programa será C#, principalmente debido a su potencia, en la cual destaca la seguridad en el
manejo de datos (comprueba que efectivamente los tipos de datos que se estén manejando
correspondan a los validados para las funciones que han sido creadas y vigila que no se produzcan
errores en operaciones matemáticas, entre otras funciones), y la administración de memoria
(inicializa variables declaradas y libera memoria de manera automática cuando el programa lo cree
conveniente), y su flexibilidad (programación orientada a objetos, lo que permite ahorrar mucho
código).

• Consideraciones acerca de la seguridad: El sistema operará mediante un control de acceso

simple basado en nombre de usuario y contraseñas.

• El sistema guardará el número de tarjeta que se asocia a la aplicación pero nunca su pin.

• El usuario debe registrarse para poder usar la APP.

2.5. Suposiciones y Dependencias

Si cambian ciertos detalles técnicos como el sistema operativo, puede ser necesario revisar y
cambiar los requisitos. En concreto, el sistema estará creado para funcionar en el sistema
operativo Windows 10, y si se actualiza la versión automáticamente en el equipo PC, existen
riesgos de afectar las funcionalidades locales del sistema.

10
 Especificación de Requisitos, estándar de IEEE 830

2.6. Requisitos Futuros

En un futuro, se podrán implementar las siguientes mejoras para completar el Sistema actual para
realizar y recibir los pedidos.

● Historial de pedidos generado por el docente.

● Historial de pedidos para los trabajadores del quiosco.
● Alerta instantánea al docente cuando el personal del quiosco no pueda entregar su pedido
en el aula.
● Habilitar opción para asociar dos tarjetas a la App.
● Extender la aplicación a coordinadores, directores y funcionarios.

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.

Deberán aplicarse los siguientes principios:

• El documento debería ser perfectamente legible por personas de distintas formaciones e

intereses.

• Deberán referenciarse aquellos documentos relevantes que poseen alguna influencia

sobre los requisitos.

• 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.

3.1 Requisitos comunes de las interfaces

La interfaz debe tener los colores institucionales de Duoc, debe estar en idioma español, debe
tener un menú con opciones y ser simple de usar.

3.1.1 Interfaces de usuario

La aplicación móvil debe ser de fácil usabilidad, debe tener un menú con las opciones Inicio (que
lleva a los productos), ofertas, carro de compras, mis favoritos y mi cuenta. Además de la lista de
los productos ya antes mencionada, dentro de esta debe existir la foto del producto y su precio.

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.

3.1.2 Interfaces de hardware

Como ya fue mencionado, los requisitos mínimos del PC de la caja del quiosco, 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.

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.

3.1.3 Interfaces de software

La app deberá estar integrada al sitio web que a su vez va anexado al sistema del quiosco.

− 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

b) Sitio web: permite al funcionario del quiosco administrar el pedido realizado y

confirmarlo o rechazarlo.

3.1.4 Interfaces de comunicación

La app debe estar en constante comunicación con el control de stock y la base de datos, de esta
manera, al verificar que un producto no se encuentre en stock, esta podrá arrojar un mensaje de
alerta indicando esto. Por otra parte, debe estar conectada a la base de datos Duoc para
corroborar que la dirección de email que se intenta vincular a esta, sea de un docente Duoc UC,
además de contar con una propia (base de datos) para almacenar la información otorgada por el
docente.

3.2 Requisitos funcionales

Definición de acciones fundamentales que debe realizar el software al recibir información,
procesarla y producir resultados.

Los requisitos funcionales principales pueden ser divididos en sub-secciones.

3.2.1 Registro de usuario

Esta función permitirá a los usuario de la aplicación registrarse y proporcionar la información
solicitada por está.

15
 Especificación de Requisitos, estándar de IEEE 830

3.2.2 Guardar información del docente

Esta función permitirá almacenar la información importante con respecto al docente y no volver a
solicitarla al momento de realizar un pedido.

16
 Especificación de Requisitos, estándar de IEEE 830

3.2.3 Tarjeta asociada.

Esta función permitirá que los usuarios puedan vincular una tarjeta de credito o debito a la
aplicación.

17
 Especificación de Requisitos, estándar de IEEE 830

3.2.4 Verificación cuenta docente Duoc

Esta función permitirá que la aplicación determine si el correo de registro pertenezca a un
docente, si no, arrojará una alerta indicando que no se ha completado el registro porque la cuenta
que se intenta asociar no pertenece a un docente de Duoc.

3.2.5 Verificación tarjeta asociada

Esta función permitirá verificar que la tarjeta que se está asociando a la App exista, en caso que
no, esta arrojará una alerta indicando que el número de tarjeta no existe.

18
 Especificación de Requisitos, estándar de IEEE 830

3.2.6 Desplegar catálogo de productos.

Esta función permitirá a los docentes ver la variedad de productos y precios de esto.

19
 Especificación de Requisitos, estándar de IEEE 830

3.2.7 Buscar Producto

Esta función permitirá buscar productos en específico dentro del catálogo.

3.2.8 Botón agregar al carrito

Esta función permitirá al usuario agregar los productos seleccionados al carrito de compras.

3.2.9 Menú principal

Esta función permitirá ver al usuario el catalogo, ofertas, el carro de compras, sus productos
favoritos y su propia información.

20
 Especificación de Requisitos, estándar de IEEE 830

3.2.10 Botón inicio

Este botón será el encargado de desplegar el inicio de la aplicación.

21
Especificación de Requisitos, estándar de IEEE 830

22
 Especificación de Requisitos, estándar de IEEE 830

3.2.11 Botón Productos

Dentro de esta función podrá encontrar diversas ofertas y productos que ofrece el quiosco Duoc.

23
 Especificación de Requisitos, estándar de IEEE 830

3.2.12 Botón Carro de compras

Dentro de esta función podrá visualizar los productos seleccionados con anterioridad.

3.2.13 Botón Mis favoritos

Aquí podrá ver la lista de favoritos según la cantidad de estos haya comprado. Por ejemplo si ha
comprado muchas veces el mismo refresco, esté aparecerá de los primeros en su lista de favoritos.

24
 Especificación de Requisitos, estándar de IEEE 830

3.2.14 Botón Mi cuenta

Aquí podrá modificar información de su cuenta, como por ejemplo el teléfono y/o la tarjeta
asociada.

3.2.15 Alerta en interfaz web

Al realizar un pedido, esta función de manera automática y en tiempo real deberá mostrar una
alerta en el sitio web de los empleados del quiosco Duoc.

3.2.16 Botón estado pedido.

Esta función permitirá cambiar el estado del pedido de recibido a entregado.

25
 Especificación de Requisitos, estándar de IEEE 830

3.3 Requisitos no funcionales

3.3.1 Requisitos de rendimiento

● Número de terminales soportados: 120 docentes conectados a la vez.
● Número esperado de usuarios simultáneamente conectados: 50 aprox.
● Número de transacciones por segundo que deberá soportar el sistema: 200.
● Que la app sea rápida (que no demore más de 3 segundos en iniciar y 2 segs. en desplegar
los datos solicitados). En suma, el 100% de las operaciones deben realizarse entre 0.5 y 3
segundos.
● Que la las gráficas de la app reflejen los colores institucionales de Duoc UC.

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:

− Empleo de técnicas respaldo de la información:​ sugerimos al cliente realizar 1 respaldo

completo cada 6 meses y respaldos diferenciales entre medio.
− No se sugerirá el cambio periódico de contraseñas​ a los usuarios debido a que estudios
recientes de la Universidad de Carleton (Canadá) indican que cambiarla regularmente

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.

Lunes a Viernes 08:30 a 22:00 hrs.

Sábado 08:30 a 16:00 hrs.

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:

− Porcentaje de componentes dependientes del servidor: 70% relativo a la base de datos.

− Porcentaje de código dependiente del servidor: 30% relativo al programa. La base de datos
estará en el servidor, mientras que la aplicación o programa de acceso para crear,
modificar, visualizar, eliminar datos, estará operando en el PC de escritorio del usuario.

27
 Especificación de Requisitos, estándar de IEEE 830

− Uso de un determinado instalador para su portabilidad: la aplicación contemplará en un

futuro próximo y si los estudios previos que realicemos así lo reflejen, estar disponible en
una versión para sistemas operativos de Macintosh.
− Uso de un determinado sistema operativo: El sistema operativo para el cual estará creada
la aplicación es Windows 10, de Microsoft.

3.4 Otros Requisitos

No hay otros requisitos.

4. Propuesta de Planificación

4.1 Descripción general acerca de la Planificación

En general, el tiempo estimado para la ejecución de este proyecto es de 6 meses considerando
dentro de ellos, una marcha blanca de 1 mes.

El equipo de trabajo debería estar conformado por un desarrollador o ingeniero de software, un

responsable de calidad, o Q.A, un diseñador (externo) y un Jefe o Gerente de Proyecto.

En cuanto a las buenas prácticas, nos guiaremos por la metodología Ágil Kanban.

4.1.2 Definición del Equipo de Trabajo

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

4.1.3 Definición de Actividades principales del Proyecto

Las actividades principales son las siguiente:

● Reunión de Kick Off:

o Objetivo Principal
o Medios de Comunicación Oficiales
o Levantamiento de Requerimientos

● Reunión de Presentación de Contrato de Servicios:

o Resumen de Kick Off
o DDR

● Procesos de Entrega y Revisión de Sprints.

29
 Especificación de Requisitos, estándar de IEEE 830

4.1.4 Diagrama EDT

4.1.5 Carta Gantt

*Se envía adjunta como archivo aparte.

4.1.6 Resumen Costos del Desarrollo del Proyecto

RECURSO VALOR TOTAL DE VALOR TOTAL

HORAS

JEFE DE PROYECTO 2.5 40 100

ANALISTA FUNCIONAL 1.2 144 172.8

DISEÑADOR 1.2 88 105.6

PROGRAMADOR 2 160 320

QA 1.5 70 105

ANALISTA SOPORTE VENTAS 1.2 120 144

JEFE DE PROYECTO (CONTROL) 2.5 50 125

TOTAL 1072.4

$29,306,547

30
 Especificación de Requisitos, estándar de IEEE 830

4.2 Plan de Control de Cambio

[Se recomienda primero describir los tipos de cambio que se podrán resolver y sus alcances]

[Insertar Tabla de Control de Cambios]

[ ​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

5.1 Acta de Proyecto

Insertar Acta de Constitución del Proyecto

31
 Especificación de Requisitos, estándar de IEEE 830

5.2 Matriz Especificación de Requerimientos

Matriz en formato planilla sobre la especificación de Requerimientos con su identificador y
columnas de datos correspondiente. RF1. O RNF.1

5.3 Diagrama de Casos de Uso

Caso de Uso General.

32
 Especificación de Requisitos, estándar de IEEE 830

Caso de uso perfil Profesor: Crear y editar usuario

33
 Especificación de Requisitos, estándar de IEEE 830

Caso de uso perfil Profesor: compra y pago de producto

34
 Especificación de Requisitos, estándar de IEEE 830

Caso de uso Administrador y Encargado quiosco

35
 Especificación de Requisitos, estándar de IEEE 830

5.4 Planilla Casos de Uso

Actor Caso de uso Pre-requisitos

Profesor Registrar datos: sección en donde el usuario Tener la aplicación instalada y
ingresa los campos requeridos para la creación de conexión a internet.
su cuenta.
Ingresar nombres y apellidos: en este apartado el Debe estar seleccionada la
usuario ingresa su nombre y apellidos. opción “crear usuario”

Ingresar tarjeta: el usuario deberá ingresar su Debe haber llenado el campo

tarjeta la cual utilizara para pagar sus productos “Ingresar nombres y apellidos”
en la aplicación.

Ingresar numero de telefono: Campo en donde el Haber llenado el campo

usuario registra su número de teléfono de contacto “Ingresar tarjeta”

Crear usuario y contraseña: En este apartado el Haber llenado los campos

usuario confecciona su nombre de usuario y anteriores
contraseña con la cual se identificará en la
aplicación.
Iniciar sesión: Utilizando su nombre de usuario y Debe haber creado previamente
contraseña el usuario ingresa a la aplicación. su usuario propio.
Editar datos de usuario: En esta parte el usuario Debe estar sesión iniciada.
podrá modificar algunos campos de su perfil.
Cambiar tarjeta: Permite al usuario cambiar el Debe estar sesión iniciada y
número de tarjeta que utilizará para sus dirigirse a la sección “Editar
transacciones. datos”
Cambiar o recuperar contraseña: permite al Debe estar sesión iniciada y
usuario cambiar su contraseña o recuperarla en dirigirse a la sección “Editar
caso de olvido. datos”
Cambiar número de teléfono: permite al usuario Debe estar sesión iniciada y
cambiar su número telefónico. dirigirse a la sección “Editar
datos”
Ver catálogo de productos: permite al usuario Debe estar sesión iniciada.
visualizar los productos y sus precios, tambien, se
mostraran las ofertas y promociones destacadas.

36
 Especificación de Requisitos, estándar de IEEE 830

Seleccionar productos: permite elegir productos Debe estar sesión iniciada.

ordenados por categorías como bebidas, bollería,
confites etc.
Seleccionar cantidad de productos: permite Debe estar sesión iniciada y
indicar el número de ítems que desea comprar. haber seleccionado algún
producto.
Agregar productos al carrito: permite agrupar Debe estar sesión iniciada y
el/los productos en el carro de compra dentro de la haber seleccionado algún
aplicación en donde se muestra su nombre, precio producto.
y cantidades.
Modificar cantidad de productos: permite al Debe estar sesión iniciada y estar
usuario cambiar el número de unidades que desea en la sección del carro de
comprar de un producto. compra.
Eliminar productos del carrito: permite al usuario Debe estar sesión iniciada y estar
borrar un producto seleccionado anteriormente de en la sección del carro de
su carro de compras. compra.
Seleccionar Retiro o Despacho: permite al usuario Debe estar sesión iniciada y estar
seleccionar el método por el cual recibirá sus en la sección del carro de
productos el cual puede ser retiro en el mesón del compra.
kiosco o despacho a la sala donde se encuentra.
Ingresar aula en caso de despacho: permite al Debe estar sesión iniciada y
usuario indicar el aula en donde se encuentra para haber elegido la opción
recibir su compra. “despacho”
Pagar: apartado en donde se indica el total a pagar Debe estar sesión iniciada y
y los productos seleccionados. productos seleccionados en el
carro de compra.
Confirmar pago: permite al usuario hacer efectivo Debe estar sesión iniciada y
el pago de su pedido. haber pasado por el apartado
“pagar”.
Dependiente Ver pedidos: permite al usuario visualizar un Estar en el portal web del
Kiosco listado de pedidos y su estado. sistema
Buscar pedidos: permite buscar un pedido Estar en el portal web del
histórico por fecha o por código. sistema
Ver detalle de venta: permite al usuario ver los Estar en el portal web del
datos de una venta seleccionada. sistema y seleccionar una venta.
Actualizar stock: permite agregar productos al Estar en el portal web del
sistema en caso de haberlos recibidos físicamente sistema y haber recibido
en el kiosco. productos por el administrador
encargado.
Actualizar estado del pedido: cambia la situación Estar en el portal web del
del pedido, en caso de ser confirmado el stock del sistema y seleccionar un pedido
producto pasa a “recibido”, y cuando llega a pendiente.
manos del cliente pasa a “entregado”.
Anular pedido: Opción pensada para ocasiones Estar en el portal web del
especiales como productos en mal estado. sistema y seleccionar un pedido
pendiente.
Administrador Editar precios de productos: permite al usuario Estar en el portal web del
modificar los precios de los productos. sistema como administrador
Actualizar stock: permite agregar productos al Estar en el portal web del
sistema en caso de haberlos recibidos físicamente sistema como administrador
en el kiosco.

37
 Especificación de Requisitos, estándar de IEEE 830

Crear promociones: permite al usuario agregar Estar en el portal web del

promociones indicando el precio normal y el sistema como administrador
precio rebajado.
Eliminar promociones: permite al usuario borrar Estar en el portal web del
promociones que ya no siguen en vigencia según sistema como administrador
su plan de ventas.

5.5 Prototipado de Software

Insertar Mockups y Wireframe de la interfaz de usuario del Sistema

5.6 Resultado Análisis de Calidad Diagramas Modelamiento

Insertar Resultado del Análisis de Calidad basado en los estándares y la Planilla de Análisis de
Calidad de modelado de Software.

5.7 Resultado Análisis de Calidad Prototipado No funcional del Sistema

Insertar Resultado del Análisis de Calidad basado en los estándares y la Planilla de Análisis de
Calidad de Prototipo de Interfaz de Usuario.

5.8 Planilla entregables del Proyecto

Insertar la Planilla que define los Módulos y Artefactos asociados al Caso de Uso a los que se
pueden aplicar cambios en un punto de su desarrollo.

5.9 Matriz de Control de Cambios

Insertar la Planilla que define los Módulos y Artefactos asociados al Caso de Uso a los que se
pueden aplicar cambios en un punto de su desarrollo.

5.10 Matriz EDT. Planilla Detallada Cálculo de Esfuerzo

38
Especificación de Requisitos, estándar de IEEE 830

39