Software Requirements

Specification
for
Chefs!
Version 1.0

Javier Felipe Vasquez

Pablo Robayo

Pontificia Universidad Javeriana

Tabla de contenido
1. INTRODUCCION .................................................................................................... 3
1.1. PROPÓSITO ........................................................................................................................................................ 3
1.2. OBJETIVOS .......................................................................................................................................................... 3
1.2.1. Objetivo General ...............................................................................................................................................3
1.2.2. Objetivos Específicos .....................................................................................................................................3
1.3. ALCANCE .................................................................................................................................................................. 3
1.4 DEFINICIONES, ACRÓNIMOS Y ABREVIACIONES .................................................................................... 4
2. DESCRIPCIÓN GLOBAL ...................................................................................... 4
2.1. PERSPECTIVA DEL PRODUCTO ...................................................................................................................... 4
2.1.1. Interfaces Con El Sistema...........................................................................................................................4
2.1.2. Interfaces Con El Usuario ...........................................................................................................................4
2.1.3. Interfaces Con El Hardware .......................................................................................................................5
2.1.4. Interfaces Con El Software .........................................................................................................................5
2.1.5. Interfaces De Comunicación .....................................................................................................................5
2.1.6. Restricciones De Memoria ..........................................................................................................................5
2.1.7. Operaciones.........................................................................................................................................................5
2.1.8. Requisitos De Adaptación Del Sitio ......................................................................................................6
2.2. FUNCIONES DEL PRODUCTO .......................................................................................................................... 6
2.3. CARACTERÍSTICAS DEL USUARIO ................................................................................................................ 6
2.4. RESTRICCIONES.................................................................................................................................................... 6
2.5. SUPOSICIONES....................................................................................................................................................... 7
2.6. DISTRIBUCIÓN DE REQUERIMIENTOS ....................................................................................................... 7
3. PLAN DE MANEJO DE REQUERIMIENTOS ....................................................... 7
3.1 LEVANTAMIENTO DE REQUERIMIENTOS ................................................................................................. 7
3.1.1 Requerimientos Funcionales ......................................................................................................................8
3.1.2 Requerimientos No Funcionales ..............................................................................................................8
3.1.3 Verificación y Validación de Requerimientos ...................................................................................8
3.2 TIPOS DE REQUERIMIENTOS........................................................................................................................... 8
3.3 ATRIBUTOS DE LOS REQUERIMIENTOS ..................................................................................................... 9
3.4 MECANISMO DE CONTROL DE ESTADO DE LOS REQUERIMIENTOS .......................................... 10
3.5 MECANISMO DE PRIORIZACIÓN DE LOS REQUERIMIENTOS ......................................................... 10
3.6 TRAZABILIDAD ................................................................................................................................................... 11
4. REQUERIMIENTOS ESPECIFICOS ................................................................... 15
4.1 REQUERIMIENTOS FUNCIONALES ............................................................................................................. 15
4.2 REQUERIMIENTOS NO FUNCIONALES ..................................................................................................... 15
Bibliografía .................................................................................................................. 15
1. INTRODUCCION
1.1. PROPÓSITO

El propósito del documento es identificar, analizar, detallar, jerarquizar y priorizar

los requerimientos asociados al proyecto Chefs!, y de esta manera poder
clasificarlos en requisitos funcionales y no funcionales.

1.2. OBJETIVOS
Estos son los objetivos que se plantean para el desarrollo de este documento

1.2.1. Objetivo General

Determinar las características de la aplicación Chefs! y analizar sus componentes

para darle un desarrollo adecuado a la implementación de los requerimientos, los
cuales serán especificados de acuerdo a las necesidades de los clientes
potenciales.
1.2.2. Objetivos Específicos

 Identificar las necesidades para la posterior implementación del sistema .

 Verificar y validar los requerimientos recolectados que cumplan con el
desarrollo de la aplicación, durante el transcurso del proyecto
 Definir los requerimientos dentro de un alcance para el desarrollo del
prototipo a partir de los requerimientos recolectados.

1.3. ALCANCE

El alcance del proyecto de software se establece de acuerdo a los siguientes

parámetros:
 Identificación y especificación de los requerimientos funcionales y no
funcionales del sistema, para estipular los que este debe ejecutar.
 Determinar el porcentaje de implementación del producto para establecer el
estado que se encuentra cada requerimiento.
1.4 DEFINICIONES, ACRÓNIMOS Y ABREVIACIONES

 SAD: Software Architecture Document.

 Android: Sistema operativo basado en el kernel de Linux diseñado
principalmente para dispositivos móviles con pantalla táctil, como teléfonos
inteligentes o tabletas.
 Modelo: Representación abstracta, conceptual, gráfica o visual, física, de
fenómenos, sistemas o procesos a fin de analizar, describir, explicar,
simular, explorar, controlar y predecir esos fenómenos o procesos.
 GoogleMaps: Es una solución para localizar objetos, localizar direcciones,
instrucciones, e información de localización todo a través de un mapa.
 Firebase : Firebase es una plataforma de desarrollo de aplicaciones móviles
y web. Firebase se compone de características complementarias que los
desarrolladores pueden combinar y adaptar para satisfacer sus necesidades

2. DESCRIPCIÓN GLOBAL

El documento da una descripción general de la funcionalidad de software y la

funcionalidad de acuerdo a las especificaciones de los clientes, del mismo modo
contribuye a la fase de implementación y desarrollo.

2.1. PERSPECTIVA DEL PRODUCTO

2.1.1. Interfaces Con El Sistema

Las interacciones del software especifican las interacciones con otros sistemas, en
los cuales se encuentran
 Google Firebase: se establece que se va a utilizar el servicio de Google,
firebase para la conexión directa con una base de datos no relacional que
maneja este servicio con las ventajas de una conexión estable, rápida y con
la posibilidad de la visualización de los datos en tiempo real, el sistema de la
aplicación se conecta con este por medio de un api propia del ambiente
Firebase

2.1.2. Interfaces Con El Usuario

Los dispositivos que actúan como interfaz de entrada y salida para la interacción
con el usuario son:
  Pantalla: Recurso utilizado para la interacción y visualización de las
interfaces gráficas , y la principal interfaz de salida

2.1.3. Interfaces Con El Hardware

Se refiere a los dispositivos e interfaces que permiten la conexión, acceso y

modificación de los datos, para esto es indispensable tener una conexión a
internet ya sea Ethernet o WiFi.
2.1.4. Interfaces Con El Software

 Sistema operativo: Es el software encargado del procesamiento y el

encargado de comunicar el hardware con la aplicación para el acceso a los
datos y la conexión en general.
 Aplicación móvil: Software usado para la presentación de las
funcionalidades del sistema, así como la información que se le da al usuario
final a partir de los datos que estos mismos proveen.

2.1.5. Interfaces De Comunicación

Para la conexión es necesario disponer de una interfaz de red de coneccion

TCP/IP la cual es la encargada de la transmisión de datos del usuario al ambiente
de Firebase y del ambiente al usuario.

2.1.6. Restricciones De Memoria

Es necesario que para que el dispositivo del usuario soporte la aplicación, este
deberá tener como mínimo una disposición de memoria de 1GB. El ambiente del
servidor Firebase no tiene restricción en cuanto a memoria en ejecución, pero si
depende de las conexiones simultáneas. El uso de la base de datos tendrá una
restricción, la cual se mitiga adquiriendo un plan de aumento de carga, debido a
esto la operación es totalmente escalable
2.1.7. Operaciones

 Operación del usuario: Durante la ejecución de este sistema a través de la

aplicación móvil, el usuario puede iniciar sesión, registrarse como Chef o
Usuario, Crear productos, adquirirlos, visualizarlos, filtrarlos, entre otras que
se pueden ver en el documento de casos de uso. (Ver documento
CasosdeUso.docx)
  Ejecución con Firebase: El servicio o ambiente Firebase se conecta
directamente con la aplicación dándole acceso en tiempo real a los datos.
 Modos de error: La aplicación realizará un rastreo del error a través de
debugs y Logs que mostraran los pasos de la ejecución para encontrar
fácilmente el problema.

2.1.8. Requisitos De Adaptación Del Sitio

En los dispositivos móviles, se debe contar con memoria de 1GB, procesador de

1.2 GHz y que soporte el sistema operativo Android. Además, debe disponer de la
aplicación instalada en el dispositivo y una versión mínima de Android 4.2.

2.2. FUNCIONES DEL PRODUCTO

Los siguientes serán las restricciones que se han contemplado en el transcurso de

la implementación:
 Se debe manejar estricto control en la identificación del usuario, mediante
el inicio y cierre de sesiones, para lo cual se usa una herramienta de
autenticación por tokens de Firebase.
 Se debe velar por la integridad y seguridad de los datos previniendo
ciberataques o accesos no permitidos a la información. Para una
descripción más detallada de las funciones del sistema, los documentos
adicionales de casos de uso y requerimientos explicarán más las
propiedades de los actores y los privilegios que cada uno tienen en el
acceso al sistema (Ver documentos CP-CasosdeUso,
CPRequerimientosFuncionales.docx y
RequerimientosNoFuncionales.docx).

2.3. CARACTERÍSTICAS DEL USUARIO

El usuario se describe detalladamente en la documentación expresada para los

casos de uso (Ver documento CasosdeUso.docx).

2.4. RESTRICCIONES

Restricción Descripción Arquitectura

 Cliente
o Se debe lograr el acceso a este a través de una aplicación móvil,
inicialmente en Android.
 Interfaz de usuario
o Se espera que se asemeje a una habitual tienda en línea,
permitiendo una interacción intuitiva con el sistema.
 o Se utilizarán escala de verdes para mantener uniformidad en la
interfaz de usuario.
 Lenguaje de programación
o Para la aplicación móvil en android, será implementada en Java.
 Legales
o Todo el contenido obtenido de otras fuentes será referenciado.
o Se respetarán los aspectos de propiedad industrial para convención
de logos y marcas.
o Se respetarán todos los derechos expresados para comercio
electrónico.
 Persistencia
o Se manejara la persistencia en base de datos en “MongoDB”,
ofrecida en Amazon Web Services.
 Sistema operativo
o El sistema operativo dependerá de cada dispositivo y terminal que
acceda al aplicativo

2.5. SUPOSICIONES

La aplicación debe ejecutarse en teléfonos con los siguientes requisitos mínimos: -

Pantalla de 4 pulgadas. - Procesador Dual-Core de 1.2GHz - Memoria RAM de
1GB. - Android Jelly Bean 4.2

2.6. DISTRIBUCIÓN DE REQUERIMIENTOS

Para la distribución de los requerimientos, se realizó un análisis de mercado a los

usuarios objetivos, es decir los chefs. A partir de los datos obtenidos en dicha
encuesta de mercado, se pudieron obtener las diferentes pautas y directrices
necesarias para realizar el producto mínimo viable, en cuanto a funcionalidades
del prototipo se refiere. Una vez obtenidos los datos, se identifican los casos de
uso, se procede a realizar su respectiva documentación y finalmente se realiza el
proceso de levantamiento de requerimientos asociados a los datos obtenidos. Por
último, se identifican y dividen en requerimientos funcionales y no funcionales (Ver
sección 3. Elaboración de requerimientos).

3. PLAN DE MANEJO DE REQUERIMIENTOS

Este Plan de Manejo de Requerimientos describe los procesos realizados para la

captura, clasificación, control, priorización y trazabilidad de los requerimientos
funcionales y no funcionales del sistema.

3.1 LEVANTAMIENTO DE REQUERIMIENTOS

En esta seccion se detalla el proceso que se realizo para el levantamiento de
requerimientos, teniendo en cuenta la opinión de los usuarios finales, y los datos
obtenidos en la encuesta de mercado.
3.1.1 Requerimientos Funcionales

Para la captura de los requerimientos funcionales de la aplicación Chefs, Se

realizaron multimples reuniones con mas de 4 Chefs y mas de 10 Usuarios
comensales, de igual manera se realizaron acompañamientos a los profesionales
de la cocina en su rutina diaria para identificar acciones cotidianas que se
pudieran tener en cuenta dentro del sistema para comodidad del Chef. En cada
una de las reuniones se definieron las funcionalidades más relevantes a
desarrollar en la aplicación, los elementos a describir de un producto y como se
deberían presentar dichos datos a los comensales.
3.1.2 Requerimientos No Funcionales

Los requerimientos no funcionales se tomaron a partir de las observaciones

hechas durante las reuniones, se discutieron y se tomaron en cuenta partiendo de
las funcionalidades que el sistema debe tener para su confiabilidad, disponibilidad
y demás criterios no funcionales que se deben tomar en cuenta para el desarrollo
de la aplicación.
3.1.3 Verificación y Validación de Requerimientos

Se hizo un estudio inicial de las funcionalidades que podría tener la aplicación

móvil, partiendo de las necesidades propias del contexto en el cual se desarrolla el
proyecto y del alcance esperado de la misma. Teniendo como base esto, se
realizó el levantamiento de requerimientos, y a partir de este proceso surge la
primera versión del documento asociado a los requerimientos.

3.2 TIPOS DE REQUERIMIENTOS

A continuación, encontramos los tipos de requerimientos que se encuentran en la
aplicación:
 Requerimientos Funcionales
o Sesión de usuario
o CRUD
o Comercializacion de platos
o Consultas de datos
 Requerimientos No Funcionales
o Rendimiento
o Disponibilidad
 o Seguridad
o Portabilidad
o Escalabilidad
o Modificabilidad
o Extensibilidad

3.3 ATRIBUTOS DE LOS REQUERIMIENTOS

Para la especificación de los requerimientos funcionales, se utilizó la siguiente

información:
 ID Req: Identificador único de los requerimientos funcionales (Ejemplo: RF-
001)
 Fecha de Creación: Fecha en la cual fue creado o modificado el
requerimiento.
 Tipo Usuario: Representa el o los usuarios que tienen relación con el
requerimiento funcional definidos.
 ID Caso de Uso: Representa el caso de uso asociado a cada requerimiento
funcional.
 Nombre: Representa una breve explicación del requerimiento.
 Estado: Es una descripción del estado actual del requerimiento el cual
puede ser: Especificado, Diseñado, Implementado o Verificado, los cuales
serán detallados más adelante.
 Prioridad: Es la importancia que tiene la elaboración de dado requerimiento
para el sistema y para los stakeholders, medida en alta, media o baja.
 Descripción: Es una explicación detallada sobre el requerimiento que se
debe elaborar.

Para los requerimientos no funcionales, su información es:

 ID Req: Identificador único de los requerimientos funcionales (Ejemplo:
RNF-001).
  Tipo: Representa el tipo de atributo de calidad a evaluar con el
requerimiento.
 Fecha de Creación: Especifica la fecha en la cual fue creado o modificado
el requerimiento.
 Nombre: Representa una breve explicación del requerimiento.
 Estado: Es una descripción del estado actual del requerimiento el cual
puede ser: Especificado, Diseñado, Implementado o Verificado, los cuales
serán detallados más adelante.
 Prioridad: Es la importancia que tiene la elaboración de dado requerimiento
para el sistema y para los stakeholders, medida en alta, media o baja.
 Descripción: Es una explicación detallada so bre el requerimiento que se
debe elaborar.

3.4 MECANISMO DE CONTROL DE ESTADO DE LOS REQUERIMIENTOS

Para llevar un control del estado de los requerimientos funcionales y no

funcionales del sistema, el cual permita tener una perspectiva del avance del
proyecto y control sobre el proceso, se definieron 4 categorías como se muestran
a continuación:
 Especificado: Requerimiento especificado por los stakeholders.
 Diseñado: Requerimiento en una etapa de diseño, sin implementación
 Implementado: Requerimiento implementado, pero no se ha probado aún.
 Verificado: Requerimiento implementado y probado satisfactoriamente.

3.5 MECANISMO DE PRIORIZACIÓN DE LOS REQUERIMIENTOS

La priorización de requerimientos funcionales y no funcionales del sistema, fue

determinada mediante el analisis de el levantamiento de requerimientos de
proyectos de grado con caracteristicas similares a este y con criterios de
categorizacion analizados en las reuniones de levantamiento de requerimientos
como los de los estándares seguidos, y presentados a continuación:
 Importancia dentro de la funcionalidad de la aplicación.
 Impacto en el desarrollo del prototipo.
  Complejidad de la implementación.
Los criterios que se tuvieron en cuenta para determinar la prioridad de los
requerimientos no funcionales fueron:
 Importancia dentro de la funcionalidad de la aplicación.
 Riesgo para la arquitectura.

De esta manera se definio como se deben priorizar los requerimientos:

 Alta: Requerimiento indispensable para uno o más stakeholders. Debe
tenerse en cuenta en etapas tempranas del desarrollo para que no afecte
procesos futuros.
 Media: Requerimiento que ofrece una funcionalidad importante para el
proyecto pero no es indispensable
 Baja: no genera mayor impacto en el funcionamiento basico de la
aplicacion.

3.6 TRAZABILIDAD

Para el control de la trazabilidad durante el análisis, el diseño, la implementación y

las pruebas del proyecto, se decide utilizar las siguientes plantillas: 3.6.1

4. MODELO DE DOMINIO
En el modelo de dominio se representan todos los elementos del negocio y las
interacciones entre ellos.
5. REQUERIMIENTOS ESPECIFICOS
4.1 REQUERIMIENTOS FUNCIONALES
Se especifican y detallan en el documento de especificación de requerimientos
adjunto.

4.2 REQUERIMIENTOS NO FUNCIONALES

Se especifican y detallan en el documento de especificación de requerimientos
adjunto.

Bibliografía
Applying 4+1 View Architecture with UML 2 (2007) Obtenido de
http://www.sparxsystems.com.au/downloads/whitepapers/FCGSS_US_WP_Applyi
ng_4+1_w_UML2.pdf

Essential Software Architecture (2006) Obtenido de

http://disi.unal.edu.co/dacursci/sistemasycomputacion/docs/SWEBOK/Computer%
20Science%20-%20Springer%20-
%20Essential%20Software%20Architecture%20(Ian%20Gorton%202006).pdf

Use-Case-Diagrams. (2014). (uml-diagrams.org) Obtenido de http://www.uml-

diagrams.org/use-case-diagrams.html
Kruchten, P. (Noviembre de 1995). Obtenido de
http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/P
bk4p1.pdf
developerWorks, I. (16 de Agosto de 2005). IBM. Obtenido de
http://www.ibm.com/developerworks/rational/library/05/0816_Louis/
Vilros. (2015). Raspberry Pi 2 User´s Guide. Vilros.
Clements, P. (2003). Software Architecture in Practice.
Gorton, I. (2006). Essential Software Architecture. Springer.
Larman, C. (2014). Applying UML and Patterns: An introduction to Object-Oriented
Analysis and Desing and Iterative Development. Addison Wesley Professional.
Sommerville, I. (2005). Ingeniería de Software. Madrid: Pearson Education.
Class-Diagrams. (2014). (uml-diagrams.org) Obtenido de http://www.uml-
diagrams.org/class-diagrams-overview.html
Use-Case-Diagrams. (2014). (uml-diagrams.org) Obtenido de http://www.uml-
diagrams.org/use-case-diagrams.html
Component-Diagrams. (2014). (uml-diagrams.org) Obtenido de http://www.uml-
diagrams.org/component-diagrams.html
Deployment-Diagrams. (2014). (uml-diagrams.org) Obtenido de http://www.uml-
diagrams.org/deployment-diagrams-overview.html
Sequence-Diagrams. (2014). (uml-diagrams.org) Obtenido de http://www.uml-
diagrams.org/sequence-diagrams.html
Ryan Bigg, O. d. (2015). RailsGuides. Recuperado el Mayo de 2015, de
guides.rubyonrails.org
Software Engineering Body of Knowledge. (24 de abril de 2014). Obtenido de
http://www.computer.org/portal/web/swebok
Wiegers, K. E. (2003). Software Requirements: Practical techniques for gathering
and managing requirement through the product development cycle.
Cer, S. (2008). Casos de Uso. Buenos Aires: Universidad de Buenos Aires.
Tejera, G. (2007). Descripción de la Arquitectura del Sistema. Montevideo -
Uruguay: Instituto de Computación.
Pablo Alvez, P. F. (2006. ). BATUTA. Montevideo: Universidad de la República.
HERNÁNDEZ, J. A. (2011). DESARROLLO DE PROYECTOS DE SOFTWARE.
Ciudad de Mexico: Tecnologico de Estudios Superiores .
Mora, J. T. (2011). Arquitectura de software para aplicaciones Web. M´exico D.F:
entro de Investigacion y de Estudios Avanzados del Instituto Politecnico Nacional.
MySQL. (s.f.). What is MySQL? Recuperado el 18 de Abril de 2015, de
https://dev.mysql.com/doc/refman/4.1/en/what-is-mysql.html
Mozilla Developer Network. (10 de Abril de 2015). HTML (HyperText Markup
Language). Recuperado el 18 de Abril de 2015, de
https://developer.mozilla.org/en-US/docs/Web/HTML
Mozilla Developer Network. (7 de Abril de 2015). CSS. Recuperado el 18 de Abril
de 2015, de https://developer.mozilla.org/en-US/docs/Web/CSS
Mozilla Developer Network. (31 de Marzo de 2015). JavaScript (tooltip en la
primera palabra). Recuperado el 18 de Abril de 2015, de
https://developer.mozilla.org/en-US/Learn/JavaScript
Shema, M. (2012). Hacking with WebSockets. Qualys.
DECSAI . (2012). Introduccion a las bases de datos. Granada: Universidad de
Granada.
Área de Ciencias de la Computación e Inteligencia Artificial. (21 de 03 de 2016).
Arquitectura Cliente/Servidor. Obtenido de CCIA: http://ccia.ei.uvigo.es/
Delgado Ferrín Gabriela;Gutiérrez Cevallos María. (2013). Manual del uso del
Internet y. MANABÍ: UNIVERSIDAD TÉCNICA DE MANABÍ.
Llorente, C. d. (2010). Guia de Arquitectura N-Capas orientada al dominio .NET
4.0. Krasis.