Embed Size (px)
Citation preview
25-11-2015
SRS Software Requirement Specification
LAURA DANIELA CHACÓN HERNÁNDEZ
LAURA TATIANA GÓMEZ REINA
LAURA VANESSA LÓPEZ CASTRILLÓN
PONTIFICIA UNIVERSIDAD JAVERIANA
1
1 Historial de Cambios
Tabla 6.1.1 Historial de cambios
Fecha Versión Sección
29 de septiembre 0.1 6 - 7
30 de septiembre 0.2 8
1 de octubre 0.3 8.2 - 8.3
2 de octubre 0.4 8.4
2 de octubre 0.5 9.1
5 de octubre 0.6 7.5
6 de octubre 0.7 9
7 de octubre 0.8 10.1 - 10.2
8 de octubre 0.9 10.3
2
2 Prefacio
Este documento presenta el desarrollo del Software
RequirementsSpecificationDocument aplicado a la creación de la aplicación
denominada L3, la cual pretende ser un sistema de recomendación de servicios de
alimentación.
De manera general los temas que se abordarán son: la vista general o introducción
del proyecto en donde se definirán alcances,objetivos y definiciones.
Posteriormente se creará la especificación del sistema, en esta parte se definirán
mecanismos de priorización, especificación y estructura de requerimientos y el
modelo de análisis de dominio. Más adelante se mostrará el plan de control de
requerimientos.
Este trabajo se ha realizado con el propósito de realizar un análisis de las
funcionalidades del sistema. Además el desarrollo de este documento permitirá
determinar la precedencia y el grado de criticidad de cada uno de los requerimientos.
3
3 Tabla de Contenidos
1 Historial de Cambios ................................................................................................... 1
2 Prefacio ...................................................................................................................... 2
3 Tabla de Contenidos ................................................................................................... 3
4 Lista de Figuras .......................................................................................................... 6
5 Lista de Tablas ............................................................................................................ 7
6 Introducción ................................................................................................................ 8
6.1 Propósito ............................................................................................................. 8
6.2 Alcance ................................................................................................................ 8
6.3 Definiciones, Acrónimos, Abreviaciones ............................................................... 9
6.4 Referencias ....................................................................................................... 10
6.5 Apreciación Global ............................................................................................. 12
7 Descripción Global .................................................................................................... 14
7.1 Perspectiva del Producto ................................................................................... 14
7.1.1 Interfaces con el sistema ............................................................................ 14
7.1.2 Interfaces con el usuario ............................................................................. 14
7.1.3 Interfaces con el Hardware ......................................................................... 14
7.1.4 Interfaces con el software ........................................................................... 15
7.1.5 Interfaces de Comunicación ....................................................................... 15
7.1.6 Operaciones ............................................................................................... 16
7.1.7 Requerimientos de adaptación al sitio ........................................................ 16
7.2 Funciones del producto ..................................................................................... 16
7.3 Características del usuario ................................................................................ 17
7.4 Restricciones ..................................................................................................... 18
7.5 Modelo de Dominio ............................................................................................ 20
7.5.1 Usuario ....................................................................................................... 20
4
7.5.2 Punto .......................................................................................................... 21
7.5.3 Producto ..................................................................................................... 22
7.5.4 Enfermedad ................................................................................................ 22
7.5.5 Promoción .................................................................................................. 23
7.5.6 Precio ......................................................................................................... 23
7.5.7 Preferencia de comidas .............................................................................. 24
7.5.8 Preferencia Producto .................................................................................. 24
7.5.9 Preferencia Punto ....................................................................................... 25
7.5.10 Horario de un punto .................................................................................... 25
7.6 Suposiciones ..................................................................................................... 26
7.7 Distribución de requerimientos........................................................................... 26
8 Requerimientos Específicos ..................................................................................... 26
8.1 Requerimientos de interfaces externas .............................................................. 27
8.1.1 Interfaces con el usuario ............................................................................. 27
8.1.2 Interfaces por el hardware .......................................................................... 28
8.1.3 Interfaces por el software............................................................................ 28
8.1.4 Interfaces de comunicación ........................................................................ 29
8.2 Características del producto de software ........................................................... 29
8.3 Requerimiento de desempeño ........................................................................... 29
8.4 Requerimiento de diseño ................................................................................... 29
8.5 Requerimiento de usabilidad ............................................................................. 29
8.6 Priorización de requerimientos........................................................................... 29
8.7 Trazabilidad ....................................................................................................... 29
9 Proceso de Ingeniería de Requerimientos ................................................................ 30
9.1 Obtención de requerimientos ............................................................................. 31
9.2 Análisis de requerimientos ................................................................................. 32
9.2.1 Clasificación de requerimientos .................................................................. 32
5
9.2.2 Priorización de requerimientos ................................................................... 33
9.2.3 Especificación de requerimientos ............................................................... 36
10 Proceso de Verificación y Validación ..................................................................... 39
10.1 Verificación de los requerimientos ..................................................................... 39
10.2 Validación de requerimientos ............................................................................. 42
10.3 Gestión de requerimientos ................................................................................. 43
6
4 Lista de Figuras
Ilustración 6.1 Apreciación Global .................................................................................... 13
Ilustración 7.1 Modelo de dominio L3 ............................................................................... 20
Ilustración 9.1 Proceso de Ingenería de Requerimientos ................................................. 30
Ilustración 9.2 Clasificación de requerimientos ................................................................ 33
7
5 Lista de Tablas
Tabla 6.1.1 Historial de cambios ........................................................................................ 1
Tabla 7.3.1 Características de los tipos de usuarios ....................................................... 18
Tabla 7.4.1Restricciones de la aplicación L3 .................................................................... 19
Tabla 7.5.1 Elemento Usuario .......................................................................................... 21
Tabla 7.5.2 Elemento Punto ............................................................................................. 21
Tabla 7.5.3 Elemento Producto ........................................................................................ 22
Tabla 7.5.4 Elemento Enfermedad ................................................................................... 23
Tabla 7.5.5 Elemento Promoción ..................................................................................... 23
Tabla 7.5.6 Elemento Precio ............................................................................................ 23
Tabla 7.5.7 Elemento Preferencia - Comida ..................................................................... 24
Tabla 7.5.8 Elemento Preferencia - Producto ................................................................... 25
Tabla 7.5.9 Elemento Preferencia - Punto ........................................................................ 25
Tabla 7.5.10 Elemento Horario punto ............................................................................... 25
Tabla 8.1.1 Requerimientos Mínimos de Software ........................................................... 28
Tabla 9.1.1 Obtención de requerimientos ......................................................................... 32
Tabla 9.2.1: Plantilla para el cálculo de la prioridad [16] ................................................... 35
Tabla 9.2.2 Planilla de Especificación de requerimientos ................................................. 39
Tabla 10.1.1 Planilla de verificación de requerimientos .................................................... 42
8
6 Introducción
6.1 Propósito
El propósito de este documento es especificar los requerimientos del sistema L3.
Además el proceso que será utilizado para lograr una exitosa implementación de
este.
De la misma manera el documento de especificación de requerimientos de software
abarcará la perspectiva, las funciones y características del producto y así mismo se
delimitará el alcance del sistema con las restricciones de éste.
Adicionalmente, se describirá el proceso de ingeniería de requerimientos, el cual se
tendrá como base para la obtención de buenos requerimientos y así pues lograr un
producto de calidad que satisfaga las necesidades de los clientes.
El presente se realiza como guía para las integrantes de L3 para el diseño y
desarrollo del producto, por otra parte, este documento anexo al trabajo de grado
tendrá el fin de brindar una descripción general del prototipo.
6.2 Alcance
El nombre de la aplicación móvil que se desea desarrollar es L3, está dirigida hacia
los estudiantes de la Pontificia Universidad Javeriana que deseen utilizar los servicios
de alimentación, Se pretende que con esta aplicación los usuarios tengan una mejor
experiencia con estos, además que puedan encontrar productos orientados a sus
gustos, preferencias, intereses y restricciones .
En primer lugar, con el prototipo se pretende que los usuarios acudan con mayor
frecuencia y se interesen por buscar los productos que deseen consumir.
La aplicación móvil estará disponible solo para dispositivos con sistema operativo
android desde la versión 4.0 Ice cream Sandwich.
L3, proveerá los siguientes servicios:
El servicio innovador de la aplicación es el de distribuir presupuesto: el sistema L3
proveerá el servicio para administrar el presupuesto de un estudiante. El servicio
operará mensualmente para optimizar los gastos de alimentación en ese periodo. El
sistema recomendará productos según las características del usuario.
9
Adicionalmente, el sistema notificará promociones vigentes de las cafeterías y
restaurantes afines al perfil del usuario. Vale la pena notar que también se usará
información contextual (localización, horario y clima) con el fin de enriquecer el
servicio.
Otro servicio es el de informar punto: el sistema L3 proveerá el servicio para informar
la cafetería y/o restaurante más cercana al usuario, donde cercana se define como:
◦ Distancia
▪ Medida de longitud
▪ Medida de tiempo
▪ Medida de esfuerzo
◦ Afinidad
▪ Productos ofrecidos
▪ Ocupación
▪ Espacio
6.3 Definiciones, Acrónimos, Abreviaciones
Modelo de Dominio: Un modelo del dominio es una representación de las clases
conceptuales del mundo real, no de componentes software. No se trata de un
conjunto de |diagramas que describen clases software, u objetos software con
responsabilidades [1]
Prototipo: “Es una representación de un sistema, aunque no es un sistema
completo, posee las características del sistema final o parte de ellas.” [2]
Requerimiento: “Condición o capacidad que un usuario necesita para poder
resolver un problema o lograr un objetivo”, “Condición o capacidad que un usuario
necesita para poder resolver un problema o lograr un objetivo(IEEE)” [3]
Android: Es un sistema operativo para Smartphones y tabletas [4]
HTTP: Protocolo de transferencia de hipertexto. ) es el método más común de
intercambio de información en la world wide web, el método mediante el cual se
transfieren las páginas web a un ordenador. [5]
API: AplicationProgramming Interface [6]
10
Puntos: Cafeterias y/o Restaurantes de la Pontificia Universidad Javeriana.
Database Oracle 11g: base de datos diseñada para Grid Computing, ofrece un
rendimiento y una escalabilidad excepcionales en servidores Windows, Linux y
UNIX [7]
Eclipse Kepler: plataforma de desarrollo de código abierto basada en Java [8].
Ionic: framework gratuito y open source para el desarrollo de aplicaciones híbridas
(nativas y móviles) basadas en HTML5, CSS y JS [9].
TCP: “Protocolo de Control de Transmisión es uno de los principales protocolos de
la capa de transporte del modelo TCP/IP. En el nivel de aplicación, posibilita la
administración de datos que vienen del nivel más bajo del modelo, o van hacia él,
(es decir, el protocolo IP)” [10].
6.4 Referencias
[1] C. Larman, UML y Patrones, Pretice Hall, 2003.
[2] Wikipedia, «Prototipo,» [En línea]. Available:
http://es.wikipedia.org/wiki/Prototipo. [Último acceso: 20 Octubre 2014].
[3] Wikipedia, «Requisito (Sistemas),» [En línea]. Available:
http://es.wikipedia.org/wiki/Requisito_(sistemas). [Último acceso: 20 Octubre
2014].
[4] Android, «Android,» 2015. [En línea]. Available:
http://www.android.com/history/. [Último acceso: 20 05 2015].
[5] MasAdelante.com, «Qué Significa HTTP,» [En línea]. Available:
http://www.masadelante.com/faqs/que-significa-http. [Último acceso: 19
Octubre 2014].
[6] S. T. Burg, «ABCTecnología,» 16 02 2015. [En línea]. Available:
http://www.abc.es/tecnologia/consultorio/20150216/abci--
201502132105.html. [Último acceso: 2 Agosto 2015].
[7] «Oracle,» [En línea]. Available:
11
http://www.oracle.com/es/solutions/midsize/oracle-
products/database/index.html. [Último acceso: 5 Septiembre 2015].
[8] «Eclipse,» [En línea]. Available:
http://www.ibm.com/developerworks/ssa/library/os-ecov/. [Último acceso: 5
Septiembre 2015].
[9] «IonicFramework,» Drifty, 2013. [En línea]. Available:
http://ionicframework.com/. [Último acceso: 5 Septiembre 2015].
[10] Kiosea.net, «Protocolo TCP,» [En línea]. Available:
http://es.kioskea.net/contents/281-protocolo-tcp. [Último acceso: 20 Octubre
2014].
[11] K. E. Wiegers, More About Software Requirements: Thorny Issues and
Practical Advice (Best Practices), Microsoft Press, 2010.
[12] I. Alexander, R. Stevens y R. R. Young, Writing Better Requirements,
Addison Wesley Pub Co Inc, 2002.
[13] R. R. Young, The Requirements Engineering Handbook (Artech House
Technology Management and Professional Development Library), Artech
House Print on Demand, 2003.
[14] IEEE, «IEEE Recommended Practice for Software Requirements
Specifications,» IEEE, 2009.
[15] K. Wiegers, «Software Requirements (3rd Edition) (Developer Best
Practices),» Microsoft Press, 2013.
[16] K. wiegers, Requirements Prioritization Worksheet, 2002.
[17] H. Jonasson, Determining Project Requirements, Auerbach Publishers Inc,
2012.
[18] K. Pohl y C. Rupp, Requirements Engineering Fundamentals: A Study Guide
for the Certified Professional for Requirements Engineering Exam -
Foundation Level - IREB compliant (Rocky Nook Computing), Rocky Nook,
2011.
12
[19] E. Hull, K. Jackson y J. Dick, Requirements Engineering, Springer, 2005.
[20] A. Durán Toro, «Atributos de los requisitos,» Marco de Desarrollo de Junta
de Andalucía, [En línea]. Available:
http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/409.
[Último acceso: 15 Octubre 2014].
[21] Universidad Distrital Francisco José de Caldas, «Proceso de Desarrollo
Open Up/OAS Subroceso: Gestión de Requerimientos y Requisitos,» [En
línea]. Available:
http://www.udistrital.edu.co:8080/documents/276352/356568/Cap6GestionRe
querimientosRequisitos.pdf. [Último acceso: 15 Octubre 2014].
[22] U. d. l. Andes, Procesos de Verificación y Validación, Bogotá:
http://sistemas.uniandes.edu.co/~csof5101/dokuwiki/lib/exe/fetch.php?media
=principal%3Acsof6101-clase5-1.pdf.
[23] IEEE , estándar de IEEE para las revisiones ,Estándar, 1997.
[24] Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del
Software, «Modulo II - requisitos de Sistemas de Softare,» [En línea].
Available:
http://is.ls.fi.upm.es/docencia/masterTI/ARS/docs/Manual_M2C1U11.pdf.
[Último acceso: 20 10 2014].
[25] J. H. Doorn, «Ingeniería de Requisitos,» Universidad Central de Buenos, [En
línea]. Available:
http:www.exa.unicen.edu.ar/catedras/ingrequi/index_archivos/antonelli.pdf.
[Último acceso: 16 Octubre 2014].
6.5 Apreciación Global
La figura 6.5.1 representa la organización del documento, es decir, es una guía que
estructura la información que se encontrará en el texto, dirigido al lector de este
documento. El presente documento describe las diferentes actividades realizadas
13
para la adecuada gestión de requerimientos, también incluye los servicios que
brindará la aplicación y las interfaces que interactúan con el sistema.
Ilustración 6.1 Apreciación Global
• Incluye el propósito y el alcance que va a tener el proyecto. Adicionalmente menciona el vocabulario relevante que se va a utilizar a lo largo del documento.
• Esta sección ayuda a tener una visión general acerca del contenido del documento
Introducción
• En esta sección se realiza una descripción de las funcionalidades de la aplicación, además de las caracteristicas del usuario,Las restricciones que va a presentar el producto, el modelo del dominio y la distribución de los requerimientos a desarrollar.
Descripción Global
• Se focaliza en los requerimientos que el usuario desea, y lo que el grupo de trabajo va a a implementar
• Incluye los requerimientos, características del proyecto con las restricciones del diseño.
• Esta sección le sirve a L3 para reconocer y saber que se quiere desarrollar y cómo, mediante los requerimientos.
• Además aquí se encuentra la trazabilidad y la priorización de los requerimientos.
Requerimientos Especificos
• Incluye las técnicas y métodos utilizados para la construcción del SRS.
• Esta sección le sirve al equipo de desarrollo para conocer cómo se debe llevar a cabo el proceso de Ingeniería de los requerimientos.
Proceso de Ingeniería de Requerimientos
• Muestra el proceso con el cual se va a validar y verificar los requerimientos especificados.
• Adicionalmente se presenta la gestión de requerimientos.
• Esta sección es de vital importancia para que la aplicación cumpla los parametros de calidad.
Proceso de Verificacion y Validación
14
7 Descripción Global
7.1 Perspectiva del Producto
L3 es una aplicación que tiene como objetivo brindar a los estudiantes de la Pontificia
Universidad Javeriana conocimiento acerca de los productos y puntos que ofrecen los
servicios de alimentación dentro del campus, pero además de esto es una aplicación
personalizada basada en los gustos, preferencias, intereses, restricciones y
necesidades del usuario.
Por otro lado, el sistema se retroalimentará mediante las interacciones del usuario
con este, para así proveer información cada vez más acorde al usuario y al contexto
en el que este se desenvuelve.
7.1.1 Interfaces con el sistema
Para recomendar un punto es necesario que L3 se comunique con
OpenWeatherMap, servidor que proveerá información acerca de la temperatura
actual del ambiente. Adicionalmente, el sistema se comunica con Google Maps
API, el cual brindará información acerca de las rutas entre puntos y la distancia
mínima entre estos. La comunicación con los servidores externos será mediante
HTTP.
7.1.2 Interfaces con el usuario
Pantalla Táctil: Permite al usuario interactuar y observar la información
que el sistema les muestra.
Interfaz GUI: En Android el GUI se implementa usando XML.
Tarjeta Gráfica: Para una mejor experiencia se recomienda una tarjeta
gráfica Adreno 320.
WI-FI/ Plan de Datos: Necesarias para el correcto uso de la aplicación.
7.1.3 Interfaces con el Hardware
A continuación se describirán las interfaces que ayudarán al buen desempeño y
comunicación del sistemas, además se presentarán los protocolos que se
utilizarán.
15
Protocolo de comunicación TCP/IP (HTTP): La comunicación del
sistema con los servidores externos se realiza mendiante el protocolo
HTTP que está sobre TCP
Puerto TCP: el puerto usado para la comunicación por medio de este
protocolo se hace por el puerto por defecto de HTTP, el puerto 18080.
Dispositivo Móvil: La aplicación será desarrollada para funcionar sobre
una plataforma Android, pero la aplicación será probada en smartphones
con conectividad 3G y Wi-Fi.
7.1.4 Interfaces con el software
DatabaseOracle 11g : Esta interfaz es la que aloja la información de forma
segura y la hace accesible para múltiples usuarios.
Windows 8 : Maneja los procesos del servidor y la base de datos para
poder retornar los datos a los clientes.
Android: Sistema operativo donde la aplicación será probada.
Eclipse Kepler: Ambiente donde se programará el servidor de la
aplicación.
Ionic : Framework en el cual se desarrolla el cliente.
Notepad++:Programa que facilita la organización del código de los
lenguajes Javascript, Html, CSS.
DBeaver: Es el manejador de la base de datos, allí es donde se realizan
las actualizaciones e inserciones de las tablas correspondientes.
7.1.5 Interfaces de Comunicación
La comunicación que realiza el servidor con el cliente y con la base de datos se
efectúa mediante el protocolo TCP, ya que el protocolo usado para hacer la
solicitud al servidor y obtener la respuesta por el cliente es HTTP y este hace uso
de TCP el cual asegura que la información se transfiere sin errores.
16
7.1.6 Operaciones
7.1.6.1 Modo Operación
Modo Usuario: Cuando el usuario se registra en el sistema tiene la
posibilidad de acceder a los servicios prestados por la aplicación .
Modo Administrador: El administrador es el encargado de actualizar
la base de datos del sistema, es decir, le es posible actualizar
promociones, productos y puntos.
7.1.6.2 Modo de Conexión
Conectado: cuando el usuario inicia sesión en el sistema,
inmediatamente puede visualizar las notificaciones que el sistema
sistema tiene para él.
Desconectado: el sistema no estará disponible para el usuario cuando
este selecciona la opción de cerrar sesión.
7.1.7 Requerimientos de adaptación al sitio
Para el correcto funcionamiento de L3 es necesario tener en cuenta los
siguientes aspectos:
Tener un dispositivo móvil con sistema operativo Android con versión
minimo de 4.0 Ice cream Sandwich.
Adicionalmente el dispositivo debe estar configurado para recibir
aplicaciones que no son de Play Store. Esto se hace ingresando a
Settings, luego a Security y activando el ítem unknownsources.
Como el servidor de L3 es desarrollado por las integrantes del grupo,
este estará alojado en un computador portátil que debe estar
desplegado todo el tiempo.
7.2 Funciones del producto
En este apartado se describirán las funcionalidades del sistema, sin embargo si se
desea profundizar en estas, puede verse en Especificación Casos de Uso y Diagrama
de casos uso, el cual se encuentra en el SAD
17
Como ya se mencionó en el alcance (Véase en la Sección 6.2 Alcance ), L3 proveerá
las siguientes funcionalidades:
Distribuir Presupuesto, en este servicio el sistema maximizará el valor que el
usuario tiene destinado para su alimentación.
Notificar Promoción, este servicio le informará al usuario las diferentes
promociones que se encuentren en los puntos del campus univeritario.
Buscar Producto, en este servicio el sistema mostrará el punto donde el usuario
puede encontrar su producto y el precio al cual lo pude adquirir.
Buscar Punto, cuando el usuario realiza esta búsqueda el sistema le arroja la
ubicación de dicho punto en el mapa.
Recomendar Producto, el sistema le motrará al usuario el producto que puede
adquirir con el presupuesto que este tiene y su perfil de usuario.
Recomendar Punto, este servicio es complementario a las funcionalidades
recomendar producto y buscar producto, ya que cuando el usuario selecciona
un producto de los presentados , la aplicación le recomienda el punto más
cercano donde puede adquirirlo, donde cercana se puede clasificar por tiempo
o distancia.
7.3 Características del usuario
Las características de los tipos de usuario que maneja la aplicación se describirán en la
tabla 7.3.1 Características de usuarios.
Tipo de usuario Descripción Privilegios
Usuario
Estudiante de la PUJ que accede a la aplicación,
mediante las credenciales del correo de la
universidad.
Consultar recomendación
Buscar producto
Buscar punto
Consultar promoción
Ingresar presupuesto
Administrador Estudiantes que se
encuentran desarrollando el trabajo de grado.
Actualizar producto
Actualizar punto
Actualizar promoción
18
Visualizar estadísticas de producto más vendido
Visualizar estadísticas de punto mas concurrido.
Tabla 7.3.1 Características de los tipos de usuarios
7.4 Restricciones
En la tabla 7.4.1 se describirán las restricciones que manejarán las integrantes para
el desarrollo de la aplicación L3.
Tipo de restricción Restricción
Generales
• L3 tendrá una arquitectura
MVC(Modelo-Vista-Controlador).
• Para poder ingresar al sistema el
usuario debe ser estudiante activo
de la PUJ
• Para ayudar a la correcta
adaptación de los servicios de
alimentación del usuario, este debe
estar retroalimentando el sistema.
Software
• Oraclebase11g es el manejador de
la base de datos.
• Android es el sistema operativo en
el cual debe correr L3.
• Ionic es el framework en el cual se
desarolla el cliente.
• Eclipse es el ambiente donde estará
implementado el servidor.
• El servidor siempre debe estar
deployado.
19
Legales
• Contenido que no haya sido
desarrollado por las integrantes del
grupo deberá ser referenciado
• Como el producto no será lanzado
en la “Play Store” no tendrá gastos
de licencia.
•
Interfaz de usuario
• El Idioma de la aplicación será
Español (Colombia)
• El dispositivo de entrada para la
aplicación sera la pantalla tactil del
celular
• L3 debe contar con una interfaz
gráfica que permita su facilidad de
uso e interactivdad.
• La GUI se implementa usando XML.
Cliente
• El prototipo funcional debe ser
entregado en las fechas
especificadas por la facultad de
ingeniería.
• Las funcionalidades ya establecidas
despues de que el SRS se
convierta en linea base no pueden
ser alteradas.
Hardware
• La aplicación solo estará disponible
para dispositivos móviles.
• El servidor debe correr en una
computadora portatil.
Tabla 7.4.1Restricciones de la aplicación L3
20
7.5 Modelo de Dominio
En esta sección se presentará el modelo obtenido a partir del analisis que se realizó
en el dominio de los servicios de alimentación de la PUJ.
A continuación el la Figura 7.5.1 se podrá visualizar el modelo de dominio que
utilizará L3.
Ilustración 7.1 Modelo de dominio L3
7.5.1 Usuario
ID 1 Elemento
del Dominio
Usuario
Descripción Representación de un Estudiante
Atributos
Nombre Descripción Tipo de Dato
ID Usuario Identificador único
del usuario. Entero
Presupuesto Valor que el usuario
maneja mensualmente para
Entero
21
su alimentación
Contraseña Contraseña unica de
cada usuario Cadena de caracteres
Ambiente
Preferencia del usuario en cuanto al ambiente(Cerrado o abierto) de un punto.
Cadena de caracteres
Bebidas Calientes Preferencia del
usuario en cuanto a una bebida.
Entero
Ruta
Preferencia del usuario en cuanto a
cercania (distancia,tiempo o
afinidad) de un punto.
Cadena de caracteres
Fecha de presupuesto
Tiempo limite en el cual se distribuirá el dinero del usuario
Date
Objetivo Identificar a un usuario dentro del sistema.
Tabla 7.5.1 Elemento Usuario
7.5.2 Punto
ID 2 Elemento
del Dominio
Punto
Descripción Representación de una cafetería, restaurante o
kiosko de la PUJ
Atributos
Nombre Descripción Tipo de Dato
IDPunto Identificador único
del punto. Entero
NombrePunto Nombre del punto. Cadena de caracteres
Tipo
Clasificación de un punto.(Cafetería ,Restaurante o kiosko)
Cadena de caracteres
Abierto Ambiente del punto. Entero
Cerrado Ambiente del punto. Entero
Latitud Coordenada x de un
punto Float
Longotud Coordenada y de un
punto Float
Objetivo Identificar un punto dentro del sistema.
Tabla 7.5.2 Elemento Punto
22
7.5.3 Producto
ID 3 Elemento
del Dominio
Producto
Descripción Representación de los productos que ofrece la
universidad.
Atributos
Nombre Descripción Tipo de Dato
IDProducto Identificador único
del producto. Entero
NombreProducto Nombre del producto Cadena de caracteres
NombreSección
Clasificación de un producto según el grupo alimenticio al que pertenece.
Cadena de caracteres
CP
Categorización de un producto como plato fuerte en una comida.
Entero
P
Categorización de un producto como postre en una comida.
Entero
B
Categorización de un producto como bebida en una comida.
Entero
Objetivo Identificar un producto dentro del sistema.
Tabla 7.5.3 Elemento Producto
7.5.4 Enfermedad
ID 4 Elemento
del Dominio
Enfermedad
Descripción Representación de las enfermedades que tiene
un usuario.
Atributos
Nombre Descripción Tipo de Dato
IDEnfermedad Identificador único de
una enfermedad Entero
NombreEnfermedad Nombre de una Cadena de
23
enfermedad caracteres
Objetivo Identificar una enfermedad relacionada a un
usuario en el sistema.
Tabla 7.5.4 Elemento Enfermedad
7.5.5 Promoción
ID 5 Elemento
del Dominio
Promoción
Descripción Representación de las prociones vigentes en un
determinado tiempo.
Atributos
Nombre Descripción Tipo de Dato
IDProducto Identificador único de
un producto Entero
IDPromoción Identificador único de
una promoción Entero
Foto Imagen de la
promoción vigente String
Objetivo Identificar una promoción que sea del agrado
de un usuario.
Tabla 7.5.5 Elemento Promoción
7.5.6 Precio
ID 6 Elemento
del Dominio
Precio
Descripción Representación del precio que se encuentra
realcionado a unproducto.
Atributos
Nombre Descripción Tipo de Dato
IDProducto Identificador único de
un producto. Entero
IDPunto Identificador único de
un punto. Entero
Valor Costo de un
producto. Entero
Objetivo Identificar el precio de un producto en
especifico.
Tabla 7.5.6 Elemento Precio
24
7.5.7 Preferencia de comidas
ID 7 Elemento
del Dominio
PreferenciaComida
Descripción
Representación de las preferencias que tiene un usuario en cuanto a las comidas
(Almuerzo,Desayuno,Medias nueves, Onces, Cena).
Atributos
Nombre Descripción Tipo de Dato
IDUsuario Identificador único
de un usuario. Entero
Comida
Clasificación del tipo de
comida(Almuerzo, Desayuno,Medias nueves, Onces,
Cena).
Cadena de Caracteres
Prioridad
Escala cuantitativa que un usuario
maneja para una comida.
Entero
Objetivo Identificar las comidas que el usuario ingiere y
la prioridad que le da estas.
Tabla 7.5.7 Elemento Preferencia - Comida
7.5.8 Preferencia Producto
ID 8 Elemento
del Dominio
PreferenciaProd
Descripción Representación de la preferencia que tiene un
usuario en cuanto a un producto
Atributos
Nombre Descripción Tipo de Dato
IDUsuario Identificador único de
un usuario. Entero
IDProducto Identificador único de
un producto. Entero
Prioridad
Escala cuantitativa que un usuario maneja para un
producto.
Entero
Objetivo Identificar los productos que desea adquirir un
usuario y la prioridad que le da estos.
25
Tabla 7.5.8 Elemento Preferencia - Producto
7.5.9 Preferencia Punto
ID 9 Elemento
del Dominio
PreferenciaPunto
Descripción Representación de la preferencia que tiene un
usuario en cuanto a un punto
Atributos
Nombre Descripción Tipo de Dato
IDUsuario Identificador único de
un usuario. Entero
IDPunto Identificador único de
un punto. Entero
Prioridad
Escala cuantitativa que un usuario maneja para un
punto.
Entero
Objetivo Identificar los puntos a los cuales el usuario prefiere asistir y la prioridad que le da estos.
Tabla 7.5.9 Elemento Preferencia - Punto
7.5.10 Horario de un punto
ID 10 Elemento
del Dominio
HorarioPunto
Descripción Representación del horario de un punto.
Atributos
Nombre Descripción Tipo de Dato
IDPunto Identificador único de
un punto Entero
Dia Dias en los cuales el
punto esta disponible.
Cadena de caracteres
Horario Inicio Tiempo en la cual el
punto empieza a atender.
Entero
Horario Fin Tiempo en el cual el
punto cierra. Entero
Objetivo Identificar el horario de un punto en especifico.
Tabla 7.5.10 Elemento Horario punto
26
7.6 Suposiciones
Las suposiciones son utilizadas para tomar ciertas decisiones que pueden llegar a
afectar el software mostrando cómo se deben cumplir determinadas características
para que el proyecto funcione de manera correcta y efectiva. A continuación se van a
listar las que pueden afectar al proyecto y a los requerimientos descritos en la
Sección 8 Requerimientos Especificos del presente documento.
L3 debe correr en sistemas Android Ice cream 4.0 y con las especificaciones de
hardware.
L3 funcionará para las pruebas haciendo uso del wifi o plan de datos del usuario.
La directora de trabajo de grado y el asesor harán parte del proceso de
recolección y especificación de requerimientos como parte fundamental del
proceso de categorización y priorización.
No se podrán adicionar funcionalidades extra después de que se haya finalizado la
realización del SRS.
La aplicación móvil L3 será implantada solo en la Pontificia Universidad Javeriana.
Es necesario tener una conexión de red estable para el buen funcionamiento de la
aplicación.
Si la red de internet se cae, la aplicación trabajará con los datos locales que tenga
hasta el momento.
7.7 Distribución de requerimientos
Para la realización de distribución de requerimientos, en primer lugar se identificaron
las necesidades de negocio, luego se refinaron los casos de uso, seguidamente se
identificaron los requerimientos, luego estos fueron especificados y después se
clasificaron entre funcionales y no funcionales.
8 Requerimientos Específicos
En este apartado, se presentarán los requerimientos que se implementarán en el
sistema, para permitir a los diseñadores crear un sistema que satisfaga las
necesidades del cliente, y así mismo, que su verificación satisfaga dichos
requerimientos. Además, este conjunto de requerimientos son de vital importancia
para asegurar la calidad del sistema.
27
8.1 Requerimientos de interfaces externas
8.1.1 Interfaces con el usuario
La interacción de la aplicación se realizará por medio de un dispositivo móvil, con
sistema operativo Android, esto se llevará a cabo por medio de una pantalla táctil.
La interfaz gráfica que se le muestra al usuario es similar a la siguiente:
Página de inicio
Encuesta Inicial (Registro)
28
Servicios Ofrecidos de la aplicación
8.1.2 Interfaces por el hardware
La comunicación entre los diferentes dispositivos se hará mediante HTTP, para
profundizar sobre el tema (Véase sección 7.1.3 Interfaces con el hardware).
8.1.3 Interfaces por el software
En la tabla 8.1.3.1 se especificán los requerimientos minimos para que la
aplicación pueda funcionar en un dispositivo móvil. Para más información dirigirse
a (Sección 7.1.4 Interfaces con el software)
Requerimientos mínimos
Sistema operativo Android
Versión Ice cream Sandwich 4.0
Servidor de base de datos Oracledatabase 11g
Tabla 8.1.1 Requerimientos Mínimos de Software
29
8.1.4 Interfaces de comunicación
Como los usuarios deben estar conectados a la red mediante su dispositivo
móvil, se puede influir que la conexión es una red de área personal o una red de
área local en la mayoría de los casos.(Vease Sección 7.1.5 Interfaces de
Comunicación).
8.2 Características del producto de software
Las características del software pueden ser visualizadas en el Anexo Especificación
de requerimientos.xml.
8.3 Requerimiento de desempeño
Los requerimientos no funcionales pueden ser visualizados en el Anexo
Especificación de requerimientos.xml.
8.4 Requerimiento de diseño
Los requerimientos no funcionales pueden ser visualizados en el Anexo
Especificación de requerimientos.xml
8.5 Requerimiento de usabilidad
Los requerimientos no funcionales pueden ser visualizados en el Anexo
Especificación de requerimientos.xml
8.6 Priorización de requerimientos
Para un correcto desarrollo de la aplicación es necesario un adecuado proceso de
análisis de requerimientos, para esto se requieren herramientas como la plantilla
descrita en la sección ingeniería de requerimientos, aquella es descrita en la figura
4.2.2 (Véase sección de 4.2 Análisis de Requerimientos)
El uso de esta plantilla tiene como objetivo, asignar una prioridad a cada
requerimiento, para que de esta manera los desarrolladores tengan un orden de
implementación de los requerimientos.
8.7 Trazabilidad
Es importante realizar una adecuada gestión de trazabilidad a lo largo de todo el
proyecto, para que de esta manera, se pueda llevar un adecuado seguimiento del
requerimiento desde sus orígenes, desarrollo, y culminación.
30
En cada etapa del desarrollo del proyecto, la trazabilidad es necesaria. Por ejemplo,
si en la etapa de desarrollo de los requerimientos se encuentra un cambio, teniendo
la trazabilidad definida se podrá evaluar el impacto que tenga este sobre otro
requerimiento (Véase plantilla de trazabilidad de requerimientos)
Por otro lado, estando en la etapa de implementación se presenta un cambio en el
requerimiento, la trazabilidad permitirá hacer una retoralimentación en la parte de
diseño e implementación (Véase plantilla de Requerimiento Vs. Prototipo)
Por último, si el cambio se da en el las últimas etapas del proyecto, la trazabilidad
permitirá realizar una evaluación de cómo afecta el cambio a las fuente involucradas
(Véase plantilla de requerimiento vs. fuente).
9 Proceso de Ingeniería de Requerimientos
El proceso de ingeniería de requerimientos está basado en las actividades que se
encuentran en la figura 4.1, [11] las cuales serán descritas a lo largo de esta sección.
Ilustración 9.1 Proceso de Ingenería de Requerimientos
INGENIERÍA DE REQUERIMIENTOS
31
9.1 Obtención de requerimientos
El levantamiento y obtención de los requerimientos del sistema se realiza desde la
primera iteración, con la elección del proyecto a implementar. Así pues, los
primeros requerimientos definidos fueron aquellos que determinaban los límites del
sistema; especificados en la sección 6.2.2 Alcance en el SPMP.
De esta manera, las integrantes del grupo, con el apoyo de la directora de trabajo
de grado, asesor y servicios de alimentación, se dedicarán a levantar los
requerimientos necesarios para el sistema, con las siguientes técnicas descritas
por Ian F. Alexander [12], excepto donde se indique:
Especificaciones y diseños existentes: En primer lugar, se realizarán
encuestas y entrevista para conocer los puntos de vista que tienen los
usuarios de los servicios de alimentación.
Experimentar la vida como usuario: Luego de tener claro las conformidades
e inconformidades de los usuarios. Las integrantes adicionarán ventajas y
desventajas de los servicios alimenticios que brinda la Universidad.
Además se tendrá una reunión con los servicios de alimentación para
conocer la perspectiva que estos tienen acerca de los usuarios que
consumen sus productos.
Observar a los usuarios trabajando: las integrantes harán un trabajo de
campo donde observarán en diferentes horas los puntos de alimentación
de la PUJ para establecer cuales son las horas críticas de afluencia de
usuarios. Adicionalmente , determinar cual es el punto más concurrido.
Casos de Uso: esta es otra técnica utilizada para la obtención de
requerimientos porque estos ayudan a describir el comportamiento total del
sistema mediante las interacciones entre los usuarios.
Sesiones JAD [13]: Se realizarán dos reuniones una el día miercoles con la
directora de trabajo de grado y la siguiente el día viernes con el asesor.
Estarán presentes todos los integrantes de la compañía y se hablará
acerca de los requerimientos que cada integrante crea necesario para el
sistema.
Lluvia de ideas [13]: Hace parte de la sesión JAD, donde los requerimientos
que se vayan obteniendo se escribirán en un tablero para, seguidamente,
escribirlos en el listado de requerimientos.
Finalmente, se listarán todos los requerimientos resultantes de la sesión JAD
en el siguiente formato de Excel:
32
Tabla 9.1.1 Obtención de requerimientos
En el formato de la tabla 9.1.1 se encuentra un número de ordenación y la
especificación del requerimiento. Este documento será de utilidad para realizar
el análisis de todos los requerimientos, sin dejar de lado ninguno de éstos.
9.2 Análisis de requerimientos
Para el análisis de requerimientos de L3 se realizarán las siguientes actividades:
9.2.1 Clasificación de requerimientos
Utilizará la clasificación de requerimientos por jerarquia funcional descrita en las
últimas versiones del estándar IEEE 830 [14], así pues, serán clasificados de
acuerdo a la funcionalidad principal de cada uno. A partir de esto se identificarán
los escenarios necesarios. En la figura 9.2.1 se describen los requerimientos de
acuerdo a dicha clasificación:
33
Ilustración 9.2 Clasificación de requerimientos
En la figura 9.2.1 se especifican las dos clasificaciones principales para el
desarrollo del sistema, las cuales son funcionales y no funcionales,donde
funcionales define las propiedades y restricciones del sistema a construir y Los
requerimientos no funcionales, suelen ser mas críticos que los funcionales, dado
que su incumplimiento puede hacer inútil el sistema .
Las integrantes se reunirán con el fin de dar una clasificación a cada uno de los
requerimientos, de acuerdo a los conocimientos adquiridos anteriormente por cada
uno de ellas. La clasificación anterior será almacenada en la plantilla de
Clasificación de Requerimientos (Véase plantilla de Clasificación de
Requerimientos).
9.2.2 Priorización de requerimientos
Se realizará una priorización debido a la importancia de implementar los
requerimientos más valiosos en el menor tiempo posible, además ayuda al
cumplimiento del cronograma especificado en la sección 9.3.2 Calendarización
del SPMP. De igual manera es un factor importante para obtener un producto de
calidad que satisfaga a los clientes, puesto que al implementar los requerimientos
de mayor prioridad primero, estos tendrán una etapa de pruebas de mayor
duración, por lo que los errores podrán ser detectados en etapas tempranas.
34
La prioridad se obtendrá al utilizar la ecuación propuesta por Karl Wiegers [15].
𝑃𝑟𝑖𝑜𝑟𝑖𝑑𝑎𝑑 = 𝑉𝑎𝑙𝑜𝑟 %
𝐶𝑜𝑠𝑡𝑜 % + 𝑅𝑖𝑒𝑠𝑔𝑜 %
Ecuación 9.2.1: Ecuación de prioridad descrita por Wiegers.
Donde,
Valor: Representa la suma entre la penalidad y el beneficio.
o Beneficio: Indica el beneficio que le provee al cliente o al negocio de
que el requerimiento esté implementado en el sistema
o Penalidad: El daño que le produce a la organización o al cliente la
falta de implementación del requerimiento en el sistema.
Costo: La cuantía total de la implementación del requerimiento.
Riesgo: Es la probabilidad de no implementar el requerimiento en el
primer intento.
Debido a que por el desarrollo de este producto las integrantes no recibirán
ningún beneficio económico ni tampoco se incurrirá en gastos; por tal motivo la
variable de costo no se tendrá en cuenta para el cálculo de la prioridad, puesto
que este valor siempre será 0%. Por consiguiente la fórmula a utilizar será:
𝑃𝑟𝑖𝑜𝑟𝑖𝑑𝑎𝑑 = 𝑉𝑎𝑙𝑜𝑟 %
𝑅𝑖𝑒𝑠𝑔𝑜 %
Ecuación 9.2.2: Ecuación de prioridad usada por Atlantis Software
En paralelo al proceso de clasificación de requerimientos, el Líder de diseño
realizará el cálculo de la prioridad de cada uno de los requerimientos, para ello,
procederá a calcular cada una de las variables anteriormente mencionadas de la
siguiente manera:
Peso Relativo: 2 1 0.5
35
Tabla 9.2.1: Plantilla para el cálculo de la prioridad [16]
En primer lugar, el responsable del cálculo asignará valores del beneficio relativo,
en una escala del 1 al 9 donde 1 significa que nadie lo encuentra útil y 9 significa
que dicho requerimiento es muy valioso. Además, se calculará la penalidad
relativa, teniendo en cuenta la misma escala; en este caso 1 significa que nadie
se molestará si este requerimiento se excluye y 9 indica un problema grave si
este es excluido. Los anteriores calificadores se le asignarán a un requerimiento
considerando el posible nivel de satisfacción de los usuarios con la
implementación o no del requerimiento. [15]
Luego, se calculará el valor total del requerimiento en cuestión; esto se realizará
con la siguiente ecuación:
𝑣𝑎𝑙𝑜𝑟 𝑡𝑜𝑡𝑎𝑙 = (𝐵𝑒𝑛𝑒𝑓𝑖𝑐𝑖𝑜 𝑟𝑒𝑙𝑎𝑡𝑖𝑣𝑜 ∗ 𝑝𝑒𝑠𝑜 𝑟𝑒𝑙𝑎𝑡𝑖𝑣𝑜) +
(𝑃𝑒𝑛𝑎𝑙𝑖𝑑𝑎𝑑 𝑟𝑒𝑙𝑎𝑡𝑖𝑣𝑎 ∗ 𝑝𝑒𝑠𝑜 𝑟𝑒𝑙𝑎𝑡𝑖𝑣𝑜)
Ecuación 9.2.1: Ecuación para establecer el valor total.
Así pues, el peso relativo asignado para el beneficio relativo será de 2; mientras
que el peso relativo para la penalidad relativa será de 1, para todos los
requerimientos.
Acto seguido, se procede a calcular el riesgo relativo, con una escala similar a las
especificadas anteriormente; donde 1 indica que el requerimiento es fácil de
implementar en el primer intento, con las tecnologías definidas en el SPMP en la
sección 8.2 Lenguajes y herramientas; e indica que seguramente se presentarán
serios inconvenientes en el momento de su implementación. [15]
Requerimiento Beneficio Relativo
Penalidad Relativa
Valor Total
Valor %
Riesgo Relativo
Riesgo %
Prioridad
Total
36
Adicionalmente, se realiza la sumatoria de las columnas anteriormente
explicadas y dicha información se almacenará en la casilla TOTALES. De esta
manera, se procede a calcular el porcentaje del valor, utilizado en el numerador
de la ecuación 9.2.1.; multiplicando el valor total del requerimiento por 100 y
dividiendo este resultado entre la sumatoria de todos los valores de los
requerimientos. Así mismo, se calculará el porcentaje del riesgo, utilizado en el
denominador de dicha ecuación; multiplicando el riesgo relativo del requerimiento
por 100 y dividiendo este resultado entre la sumatoria de todos los valores de
riesgo de los requerimientos.
Finalmente, Se calculará la prioridad total del requerimiento, dividiendo el
porcentaje del riesgo del requerimiento entre el porcentaje del riesgo multiplicado
por el peso relativo asociado a este riesgo, que para efectos del proyecto será de
0.5.
Como se observa en la fórmula, una mayor prioridad indica un valor mayor en
comparación al riesgo, y una prioridad menor indica un valor menor en
comparación al riesgo.
9.2.3 Especificación de requerimientos
Es importante que cada requerimiento tenga atributos determinados, para que
sea catalogado como un buen requerimiento, de tal manera que sea completo,
factible, válido, acordado, clasificado, no ambiguo, actualizado, correcto,
consistente, verificable, realizable, trazable y entendible; Adicionalmente, debe
estar escrito en oraciones cortas, formulando un solo requerimiento por oración.
[17] [18]
L3 manejará la plantilla de especificación de requerimientos descrita a
continuación para la especificación de requerimientos, la cual contará con los
siguientes atributos:
ID: Identificador único de cada requerimiento, es de importancia en el
documento de especificación de requerimientos ya que permite la
localización y trazabilidad del requerimiento. Este identificador ya fue
37
definido en la etapa de Obtención de requerimientos en la sección 9.1
Obtención de requerimientos. [19] [20]
Cambios: Debido a que los requerimientos son propensos a cambios a lo
largo del proyecto, es importante que cada uno de ellos maneje una
etiqueta de versión del requerimiento. [20]
Fecha de creación: Fecha en la cual se empezó a especificar el
requerimiento. Es de importancia porque se tiene una validación de las
actividades descritas en el cronograma descrito en el SPMP.
Tipo: Clasificación descrita en la Sección 9.2 Análisis de requerimientos
Es importante ya que se debe tener consistencia entre la especificación y la
clasificación del requerimiento; garantizando trazabilidad hacia atrás.
Estado: Hace referencia al estado del proceso de Ingeniería de
requerimientos en el que se encuentra el requerimiento que está siendo
especificado. Este atributo tiene valores fijos los cuales son
o Borrador: El requerimiento se encuentra en la etapa de obtención.
o Analizado: El requisito ya posee una clasificación y una priorización de
acuerdo a la Sección 9.2 Análisis de requerimientos
o Especificado: El requerimiento ya se encuentra en la plantilla de
especificación de requerimientos, y ya se encuentra listo para ser
validado.
o Validado: Además de que el proceso de especificación, el
requerimiento ya pasó por el proceso de validación descrito en la
Sección 10.2 Validación de requerimientos.
o Eliminado: El requerimiento fue considerado irrelevante para la
implementación final del sistema. Se decidió no implementar.
Poseer un estado en el documento de Especificación de requerimientos es
necesario porque se necesita conocer la evolución del proceso de
38
ingeniería de requerimientos y así ayudar a la gestión de éstos de una
madera adecuada. [20]
Última modificación: Ya que los requerimientos van generando diferentes
versiones del proyecto, es importante conocer la fecha de la última
modificación para conocer el historial de cambios de los requerimientos.
[20]
Categoría: Se definirán tres tipos de categoría: alta, media y baja. Éstas de
acuerdo a la prioridad calculada para cada requerimiento y descrita en la
Sección 9.2 Análisis de requerimientos. Así pues, si un requisito tiene una
prioridad entre 2.5 y 3 se considerará alta, media se considerará de 1.5 a
2.5 y de 0 a 1.5 se considerará baja. [15]
Prioridad: En esta casilla se encontrará el valor de prioridad calculado en
la sección de priorización del análisis de requerimientos. Este valor es
necesario pues define el orden de implementación de los requerimientos.
(Véase Sección 9.2 Análisis de requerimientos).
Autores: Personas que crearon el requerimiento. Esta casilla es importante
para gestionar posibles no conformidades de calidad de los requerimientos
y, de esta manera, solventar dudas o conflictos que se puedan presentar.
[20]
Nombre: Descripción breve del requerimiento, usada internamente para
referenciar el requerimiento. [20]
Fuente: El origen de la obtención del requerimiento (Véase Sección 9.1
Obtención de requerimientos). Es importante para poder determinar a quién
o a que documento referirse cuando surjan dudas respecto a este. [20] [21]
Especificación: Descripción y explicación del requerimiento.
Casos de uso asociados: Los casos de uso que se relacionan con ese
requerimiento. Definen el alcance del sistema.
39
Requerimientos Asociados: Requerimientos que se relacionan con el
requerimiento en mención .Esta casilla es de vital importancia ya que está
relacionado con la trazabilidad de los requerimientos y ayuda al equipo de
desarrollo a la implementación de los requerimientos. Además es
fundamental para la realización de un análisis de impacto de un cambio.
[20]
Parámetros de Verificación: Las técnicas utilizadas con las cuales se
probará el correcto funcionamiento del requerimiento. Cada requerimiento
manejará una técnica específica con la cual se pueda comprobar su
adecuada implementación.
Tabla 9.2.2 Planilla de Especificación de requerimientos
Al finalizar el proceso de clasificación y priorización de requerimientos líder
de diseño con sus ayudantes, procederán a llenar la plantilla por cada uno
de los requerimientos ya recolectados. Esto se realizará en una reunión
acordada, en la cual se discutirán los respectivos campos para contar con
un único criterio en el documento de especificación.
10 Proceso de Verificación y Validación
10.1 Verificación de los requerimientos
Este proceso tiene como objetivo detectar conflictos entre los requerimientos y el
diseño e implementación del sistema [22]. La verificación se enfoca en el proceso de
evaluación del sistema ya que permite determinar si el entregable al final de cada
40
etapa del ciclo de vida satisface los requerimientos definidos al principio de este y
de la misma manera, verificar en las etapas de implementación que la compañía
está cumpliendo realmente con los objetivos trazados al principio del proyecto.
En primer lugar, se verificará que cada uno de los requerimientos que ya han sido
especificados (Véase Sección 9.2.3 Especificación de requerimientos) sea:
Completo: Describe toda la funcionalidad que deba implementar un
requerimiento. El responsable de la verificación deberá leer el requerimiento
y comprender la funcionalidad que abarca sin necesidad de revisar fuentes
externas.
Factible: El requerimiento debe poder implementarse, Un requerimiento se
considera factible si se encuentra dentro del alcance y límites del sistema
(Véase Sección 6.2 Alcance).
Acordado: el requerimiento es reconocido y aceptado por todos los
integrantes de L3. Este parámetro siempre se cumple ya que todos los
requerimientos definidos en el sistema son producto de una reunión en la
cual toda la compañía está presente. [18]
Clasificado: Un requerimiento se encuentra clasificado si es posible
asignarlo en la clasificación definida en la sección 9.2 Análisis de
requerimientos
No ambiguo: Un requerimiento no ambiguo puede ser entendido de una
única manera, sin dar lugar a distintas interpretaciones. Para las integrantes
de L3 un requerimiento es no ambiguo si todos los lectores del
requerimiento llegan al mismo concepto al leer dicho requerimiento. [18]
Actualizado: Si el requerimiento ha sufrido cambios, estos deben estar
reflejados tanto en el cómo en su plantilla de especificación. Esto se cumple
si las solicitudes de cambio que han sido aprobadas, tengan impacto en el
requerimiento. [18]
Correcto: Debe decir una sola funcionalidad del sistema, y debe ser
coherente con la fuente de obtención del requerimiento.
41
Consistente: No debe entrar en conflicto con otros requerimientos. Para
verificar este parámetro, el requerimiento debe ser comparado con los
requerimientos restantes para así asegurarse que dos o más requerimientos
no definan la misma funcionalidad. Si esto llegase a ocurrir, los
requerimientos sobrantes se eliminarán, modificando su estado a
“eliminado”.
Verificable: Un requerimiento es verificable si se le pueden establecer
parámetros de verificación que sean medibles cuantitativamente.
Trazable: El requerimiento es trazable si se puede dar un seguimiento
desde su origen hasta su final, así como conectar éste con los demás
requerimientos y con los Casos de uso.
Entendible: Tiene un lenguaje natural y conciso. Es entendible si todos los
integrantes de L3 comprenden completamente la funcionalidad que describe
el requerimiento.
Existirán tres tipos de técnicas para la realización de verificación de
requerimientos, descritas a continuación:
Revisión cruzada: Luego de la realización del proceso de especificación
de requerimientos (Véase sección 9.2.3 Especificación de Requerimientos),
a cada integrante del grupo se le asignará un conjunto de requerimientos
que fueron creados por otro integrante. Éste realizará la verificación de
cada uno de los requerimientos siguiendo las pautas mencionadas
anteriormente, usando la plantilla de Verificación de requerimientos. [18] En
caso de que algún requerimiento no llegase a cumplir alguno de estos
parámetros, se procederá a realizar el proceso de cambio especificado en
la sección 10.1 Administración de Requerimientos del SPMP.
En la figura 10.1.1. Se describirá la plantilla que usaran los integrantes en
el proceso de verificación de requerimientos.
42
Tabla 10.1.1 Planilla de verificación de requerimientos
Se puede apreciar que en las filas se encuentra cada uno de los
requerimientos especificados, mientras que en las columnas aparecen los
parámetros de verificación. Así pues, cada integrante marcará con una X si
el requisito cumple con el parámetro correspondiente.
Inspecciones [23]: Las inspecciones se realizarán por los grupos de
trabajo detallados en el SPMP, los cuales revisan el diseño, la
documentación y el código por separado y luego se realizará una reunión
con el fin de examinar las posibles inconsistencias realizadas y de esta
manera realizar una retroalimentación con los requerimientos. De esta
manera, el producto final no será aceptado hasta que se realicen las
correcciones necesarias.
Walkthroughs [23]: Es un proceso similar al de las inspecciones. Sin
embargo, en este caso el Líder de Programación es el único encargado del
análisis; realizando escenarios sobre el código.
10.2 Validación de requerimientos
La validación de requerimientos comprende actividades que se realizan una vez se
haya tenido la primera versión del producto final. Al realizar este proceso, L3
comprueba que el producto desarrollado sea el definido en un principio.
Después de la construcción del prototipo final diseñado para la última entrega, el
Patrocinador ejecutivo, con un integrante del equipo de desarrollo, serán los
encargados de detectar identificar los errores que se presenten en los
43
requerimientos. De esta manera, en caso de encontrar alguna inconsistencia en el
prototipo, se procederá a diligenciar el formato descrito en la figura 10.1.1 para
realizar el cambio del requerimiento; usando el mecanismo de verificación por
prototipos descrito en la Sección 10.1 Verificación de los Requerimientos
Finalmente, el Patrocinador ejecutivo generará un reporte en el cual especifique
todos los requerimientos que necesiten un cambio. [24]
10.3 Gestión de requerimientos
Para el correcto desarrollo del proyecto es importante asegurar la trazabilidad ya
que se aseguran las relaciones de dependencia que existen entre los
requerimientos del usuario (Trazabilidad hacia atrás) y entre el diseño y la
implementación del sistema (Trazabilidad hacia adelante). [20]
Doorn, quien describe la trazabilidad de un requerimiento, afirma que el
requerimiento debe realizarse desde que se especificó, hasta la implementación
de este en el sistema y viceversa, es decir, hacia adelante y hacia atrás [25]. Con
esto, se verifica un plan de control de cambio exitoso. (Véase 10.1 Administración
de Requerimientos en el SPMP)
El Líder de Arquitectura, en compañía de un integrante del equipo de desarrollo,
realizarán las respectivas relaciones y dependencias tomando como base el
documento de especificación de requerimientos y extrayendo de éste la fuente y
los requerimientos asociados. Estas relaciones serán expuestas en la plantilla de
RqeuerimientoVs.Fuente y RequerimientoVs.Requerimiento respectivamente.
Seguidamente, se realizará otro documento, donde se encuentre la relación entre
el requerimiento el Caso de Uso asociado a este(Véase plantilla de trazabilidad de
requerimientos). Estas plantilla será diligenciada en una reunión entre los
responsables mencionados anteriormente.
Estos documentos serán de vital importancia a la hora de realizar un cambio, para
así poder analizar el impacto de análisis descrito en la Sección 10.1 Administración
de Requerimientos del SPMP.
