Download documento SRS - Trabajos de Grado de la facultad de Ingeniería de

2013
PONTIFICIA UNIVERSIDAD
JAVERIANA
Daniel Warner
SmartGauge
[SRS – (SOFTWARE
REQUIREMENTS
SPECIFICATIONS)]
Especificación de Requerimientos de Software para la aplicación SmartGauge
PREFACIO
El objetivo fundamental de la ingeniería es dar soluciones a problemas y aportar
herramientas que colaboren con el desarrollo de la humanidad y le ofrezcan un
mejor estilo de vida a ésta. Pero para poder hablar de soluciones es indispensable
conocer y entender el problema o problemática en cuestión y así poder plantear
soluciones muy específicas a cada uno de sus componentes para así mismo ir
generando pequeñas soluciones, que bien abarcadas, cuestionadas y medidas
podrán juntarse para nacer como una solución, sino total, al menos parcial o
grande del problema.
En este contexto es donde nace la ingeniería de requerimientos. Ésta se dedica a
la identificación de esas necesidades, a la pregunta por cuáles son
específicamente los aspectos que deben implementarse para dar solución a un
problema. Y para ello se requiere de rigor, más allá de entender “por encima” las
necesidades de un sistema de software por medio de casos de uso o
estimaciones, se hace necesario tener un registro concreto de necesidades y
propuestas de solución que puedan ser monitoreadas, medidas y que se pueda
asegurar que son viables y realizables.
El documento SRS es aquel donde se asegura que se han tenido en cuenta todas
las necesidades y funcionalidades de un producto de software, definiendo los
mecanismos para hallarlos y plantearlos, y siendo una referencia para saber hasta
qué punto una solución de software es en verdad una solución óptima a una
problemática.
1
HISTORIAL DE CAMBIOS
Versión
Fecha de
Actualización
18/03/2013
0.1
0.2
20/03/2013
0.2.1
21/03/2013
0.2.2.
0.3.0.
0.3.1.
0.4.
0.4.1.
0.4.2.
0.4.3.
0.5.1.
22/03/2013
25/03/2013
26/03/2013
27/03/2013
30/03/2013
02/04/2013
03/04/2013
04/04/2013
2
2.1.
05/04/2013
06/04/2013
Descripción
Se incluye en el documento la Introducción
(Propósitos y alcance)
Se incluye parte del punto 2 (2.1., 2.2., y 2.3.)
Se corrige redacción del punto 1 y se modifica
punto 2.2.
Se modifica el punto 1.2.
Se incluyen el documento puntos 3 y 4.
Se modifican los puntos 2.3. y punto 4
Se agregan los puntos 2.4, 2.5 y 2.6.
Se modifica ortografía y redacción del documento
Se modifica el punto 4.4. y 4.5.
Se modifica el punto 3.10
Se modifica el punto 4 y se hace una revisión de
ortografía y redacción de todo el documento.
Se modifican puntos 2,3 y 4
Se modifica punto 3 y se hace revisión de
ortografía y redacción
Tabla 1 Historial de Cambios
2
Contenido
PREFACIO............................................................................................................................................. 1
HISTORIAL DE CAMBIOS ...................................................................................................................... 2
ILUSTRACIONES ................................................................................................................................... 5
TABLAS ................................................................................................................................................ 6
1.
2.
3.
INTRODUCCIÓN ........................................................................................................................... 7
1.1.
PROPÓSITOS ........................................................................................................................ 7
1.2.
ALCANCE .............................................................................................................................. 7
1.3.
ACRÓNIMOS Y ABREVIACIONES .......................................................................................... 8
1.4.
REFERENCIAS ....................................................................................................................... 9
ELABORACIÓN DE REQUERIMIENTOS ....................................................................................... 10
2.1.
OBTENCIÓN DE REQUERIMIENTOS ................................................................................... 11
2.2.
ESPECIFICACIÓN DE REQUERIMIENTOS ............................................................................ 12
2.3.
PRIORIZACIÓN DE REQUERIMIENTOS ............................................................................... 13
2.4
VALIDACIÓN DE REQUERIMIENTOS .................................................................................. 14
2.5.
TRAZABILIDAD DE LOS REQUERIMIENTOS ........................................................................ 15
DESCRIPCIÓN GLOBAL ............................................................................................................... 16
3.1.
DESCRIPCIÓN DEL PRODUCTO .......................................................................................... 16
3.1.1.
INTERFACES CON EL SISTEMA ................................................................................... 16
3.1.2.
INTERFACES CON EL USUARIO .................................................................................. 16
3.1.3.
INTERFACES CON EL HARDWARE .............................................................................. 17
3.1.4.
INTERFACES CON EL SOFTWARE ............................................................................... 18
3.1.5.
INTERFACES DE CONEXIÓN ....................................................................................... 19
3.1.6.
RESTRICCIONES DE MEMORIA .................................................................................. 19
3.1.7.
OPERACIONES............................................................................................................ 19
3.2.
FUNCIONES DEL PRODUCTO ............................................................................................. 20
3.3.
CARACTERISTICAS DEL USUARIO ....................................................................................... 21
3
4.
3.4.
RESTRICCIONES ................................................................................................................. 22
3.5.
SUPOSICIONES Y DEPENDENCIAS ...................................................................................... 23
REQUERIMIENTOS ESPECÍFICOS ................................................................................................ 24
4.1.
REQUERIMIENTOS DE INTERFACES EXTERNAS ................................................................. 24
4.1.1.
INTERFACES CON EL USUARIO .................................................................................. 24
4.1.2.
INTERFACES CON EL HARDWARE .............................................................................. 24
4.1.3.
INTERFACES CON EL SOFTWARE ............................................................................... 24
4.2.
CARACTERÍSTICAS DEL PRODUCTO DE SOFTWARE ........................................................... 25
4.3.
RESTRICCIONES DE DISEÑO ............................................................................................... 25
4.4.
ATRIBUTOS DEL SISTEMA DE SOFTWARE (NO FUNCIONALES) ......................................... 26
4.4.1.
CONFIABILIDAD ......................................................................................................... 27
4.4.2.
DISPONIBILIDAD ........................................................................................................ 27
4.4.3.
SEGURIDAD................................................................................................................ 27
4.4.4.
MANTENIBILIDAD ...................................................................................................... 28
4.4.5.
PORTABILIDAD........................................................................................................... 28
4.5.
REQUERIMIENTOS DE LA BASE DE DATOS ........................................................................ 28
4
ILUSTRACIONES
Ilustración 1 Actividades de elaboración de Requerimientos........................................................... 10
Ilustración 2 Clasificación de Requerimientos .................................................................................. 11
Ilustración 4 Descripción del producto (Interfaces de Usuario) ....................................................... 17
Ilustración 5 Funciones del Producto ................................................................................................ 20
Ilustración 6 Características del Usuario ........................................................................................... 21
Ilustración 8 Arquitectura de conexión. ............................................................................................ 24
Ilustración 9 Interfaces con el Software............................................................................................ 25
Ilustración 10 Atributos No Funcionales (CONFIABILIDAD) .............................................................. 27
Ilustración 11 Atributos No Funcionales (Mantenibilidad) ............................................................... 28
5
TABLAS
Tabla 1 Historial de Cambios ............................................................................................................... 2
Tabla 2 Especificación de Requerimientos ........................................................................................ 13
Tabla 3 Validación de Requerimientos.............................................................................................. 15
Tabla 4 Descripción del Producto (Interfaces con el Software) ........................................................ 19
Tabla 5 Restricciones ......................................................................................................................... 22
6
1. INTRODUCCIÓN
1.1.
PROPÓSITOS
El objeto principal de este documento es definir el proceso de recolección y
especificación de requerimientos junto al proceso del desarrollo del prototipo
de SmartGauge, de acuerdo a las necesidades identificadas dentro de GS1
Colombia. Dichos requerimientos serán la base para el desarrollo de las
funcionalidades del prototipo mencionado y de las subsecuentes fases del
proyecto.
Además se busca:



1.2.
Aprender y poner en práctica algunas de las principales técnicas de
levantamiento de requerimientos.
Ser consecuentes en el seguimiento del plan trazado para el SRS
contemplado en el documento SPMP de la Fase I del proyecto.
Hacer un seguimiento de la trazabilidad de los requerimientos a fin de
facilitar el desarrollo del prototipo, su documentación y sus pruebas.
ALCANCE
El desarrollo de la Fase II del proyecto se basa principalmente en los
siguientes avances y entregas:




Las Correcciones de la Fase I.
Se prevé entregar, además, el Diagrama y la Especificación de Los
casos de uno ya refinados, que venían trabajándose desde la fase I.
Se entrega también el Modelo de Dominio del software que ayuda a
comprender los conceptos que maneja el usuario en el software e
identifica sus clases conceptuales (que no requieren necesariamente las
clases del diseño formal de software). A partir de éste se entrega
también una primera aproximación a lo que será el Diagrama de Clases
del sistema, previsto para la Fase III.
Para esta Fase se tiene contemplada también la entrega al cliente de los
requerimientos del sistema con su respectiva priorización, numeración,
descripción y demás atributos, además de su escalabilidad para el caso
7
de los requerimientos funcionales ya implementados en el software. Es
probable que sea necesario en el futuro hacer algunos cambios a los
requerimientos ya definidos (esto en parte también por las
observaciones del cliente) por lo que también se dispondrá de una
plantilla de solicitud de cambios y modificaciones de requerimientos.
1.3.












ACRÓNIMOS Y ABREVIACIONES
SPMP: Software Project Management Plan.
Know How: Define los conocimientos académicos y capacidades de
una persona o colectivo.
SO: Sistema operativo.
Resolución de pantalla (en pixeles): Dimensiones de la matriz de
pixeles que se imprime en pantalla.
Pixel: Picture element. Unidad de color que forma una imagen digital.
NIC: Network Interface Card o Tarjeta de Red. dispositivo para
conectarse a redes e internet.
RAM: Random Access Memory: Memoria principal del computador
donde se cargan todas las aplicaciones y datos ya procesador y a ser
procesados.
Hardware: Componentes físicos del computador.
Software: Componentes lógicos del computador. Programas y
aplicaciones.
Firewall: Dispositivo de hardware o software que autoriza o desautoriza
la conexión o envío de datos de algún programa en un equipo hacia una
red o viceversa.
SRS: Software Requirements Specification.
SPMP: Software Project Management Plan.
8
1.4.
REFERENCIAS
[1] Bruegge, B. Ingeniería de Software Orientado a Objetos. Primera Edición.
México: Pearson Educación. S.A., 2002.
[2] Buenos Requerimientos. Franky, María Consuelo y Torres, Miguel. Clase
Análisis y Diseño O.O. Universidad Javeriana. 2009
[3] Sommerville and Sawyer. 1997.
[4] Brackett, John W. "Software Requirements". Software Engineering Institute
Education Program. Carnegie Mellon University.1990.
[5] Martínez, Nadina. Priorización de requerimientos de software utilizando una
estrategia cognitiva. Universidad Nacional del Comahue. Buenos Aires,
Argentina. http://ficcte.unimoron.edu.ar/wicc/Trabajos/III%20-%20isbd/678PriorizRequerimientos.pdf
[6] Information Science Institute. University of Southern California. Protocolo de
Control de Transmisión. 1981. Disponible en: http://www.rfc-es.org/rfc/rfc0793es.txt
9
2. ELABORACIÓN DE REQUERIMIENTOS
La elaboración de requerimientos es un proceso de actividades consecutivas
que se describen a continuación:
1. Obtención
2. Especificación
3. Priorización
4. Validación
5. Realización
6. Trazabilidad
Ilustración 1 Actividades de elaboración de Requerimientos
10
2.1.
OBTENCIÓN DE REQUERIMIENTOS
“Los requerimientos son una especificación de lo que debe ser implementado”.
[3]
En el siguiente gráfico se describe cómo y a partir de qué se realizó la
obtención de los requerimientos del sistema SmartGauge. Para su obtención
se hace uso del modelo FURPS+ para obtención de requerimientos de
software de calidad. Dichas herramientas son la definición de requerimientos
Funcionales y No Funcionales. Además dentro de los requerimientos
funcionales se hace una distinción entre aquellos restrictivos y permisivos,
siendo los primeros los requerimientos inversos. [2]
FUNCIONALES
•Aquellos
requerimientos que se
espera sean
funcionalidades
propías del sistema, su
funcionamiento lógico.
NO
FUNCIONALES
•Requerimeintos del
proyecto que no se
encuentran en la estructura
lógica del software, sino en
aquellos que permiten
conocer la operación del
sistema.
INVERSOS
•Requerimientos lógicos de la
aplicación, pero enfocados a lo
que no debe hacer o permitir
el sistema.
Ilustración 2 Clasificación de Requerimientos
11
El modelo de apoyo de levantamiento de requerimientos FURPS+ desarrollado
por Hewlet Packard, es usado a la hora de extraer requerimientos del sistema,
pero su uso no se documenta para mantener la clasificación de Funcionales,
no funcionales e inversos descrita anteriormente.
El uso de estas herramientas de levantamiento de requerimientos se hizo
sobre los casos de uso descritos en la Fase I y refinados en la Fase II del
proyecto [ver Casos de uso refinados]. El buen entendimiento de las reglas de
negocio y de las necesidades del cliente se logró mediante reuniones con el
mismo y acercamientos con el director del presente proyecto, de manera que
se lograra identificar necesidades y recibir retroalimentación y asesoría en la
definición formal de los requerimientos obtenidos.
2.2.
ESPECIFICACIÓN DE REQUERIMIENTOS
La especificación de los requerimientos busca para cada requerimiento
definido dar una descripción precisa de éste, su prioridad, clasificación,
trazabilidad, entre otros aspectos. Se decidió especificar cada requerimiento
por medio de los atributos que se muestran en la siguiente tabla. (ver plantilla
de especificación de requerimientos)
Código
Especificación
Justificación
Alcanzable
Prioridad
Tipo
Es un código
único y secuencial
que identifica a
cada requerimiento,
ya sea Funcional,
No Funcional o
Inverso. El formato
del código es de la
forma RQ-xxx con
xxx como número
de secuencia y RQ
identificando que es
el código de un
requerimiento.
Aquí se da la
descripción
formal del
requerimiento
y en qué
consiste. Para
los funcionales
se describe
qué debe
hacer el
sistema, para
los inversos
qué no debe
hacer o
permitir y para
los no
funcionales se
define el cómo
debe hacer el
trabajo el
sistema
además de
especificar
requerimientos
para el
usuario.
Este campo justifica
la necesidad del
requerimiento, por
qué es importante y
por qué debe
tenerse en cuenta.
Aquí se especifica si
el requerimiento es
o no alcanzable,
esto de acuerdo a
los recursos del
proyecto,
principalmente de
tiempo y de “know
How”.
Aquí se especifica el
grado de
importancia y
necesidad de
implementar el
requerimiento.
Clasificación
del
requerimiento
en funcional,
No Funcional
o
Inverso.
12
Tabla 2 Especificación de Requerimientos
La especificación de los requerimientos de SmartGauge puede consultarse en
la siguiente tabla: (ver tabla de especificación de requerimientos)
Dado que es probable que en las siguientes iteraciones del proyecto sea
necesario hacer alguna modificación o actualización en los requerimientos del
proyecto, se ha diseñado una plantilla para este fin, donde se especifica cuál
es el requerimiento a actualizar o modificar, se justifica ésta acción, y se
definen los cambios en las características y especificación de dicho
requerimiento. (ver plantilla Actualización/Cambios de requerimientos).
2.3.
PRIORIZACIÓN DE REQUERIMIENTOS
La estrategia de priorización de requerimientos se basa en algunas propuestas
de La Ingeniería Cognitiva, que propone un proceso de priorización basado en
3 etapas:



Selección de criterios de priorización: Pueden ser criterios de negocio o
técnicos.
Cada integrante del equipo propone una métrica de ordenamiento y
explica sus criterios de ordenamiento.
Determinar una métrica conjunta y definitiva.
Ésta estrategia está diseñada para organizaciones jerárquicas de varios
despachos y trabajadores, por lo que habla de asignar puntos a la persona
antes que al requerimiento, de acuerdo a su cargo e influencia en la
organización para, ahí sí, darle un peso en su calificación del requerimiento.
Los criterios de calificación de requerimientos se tuvieron en cuenta fueron:
1. La importancia funcional del requerimiento. Cómo éste es sustento de
otras funcionalidades menores.
2. El impacto negativo que tendría dentro del proyecto al no ser
implementado.
3. Una idea mental aproximada de cuántas líneas de código podría
requerir la implementación en el software dicho requerimiento de ser
13
funcional o inverso, y cuanto tiempo consumiría en el caso de los
requerimientos no funcionales.
De acuerdo a estos parámetros, se asignaron valores de ésta manera:
1. Prioridad Baja
2. Prioridad Media
3. Prioridad Alta
Los valores numéricos se utilizaron para poder calcular de manera más fácil la
media de la prioridad.
2.4
VALIDACIÓN DE REQUERIMIENTOS
Una responsabilidad del Director de Calidad y Gestión de Riesgos es validar
los requerimientos luego de definidos y antes de implementados con el fin de
corroborar su calidad y que no representará un problema a la hora del
desarrollo. Para ello se evalúan algunos aspectos del requerimiento mismo y
del requerimiento frente a los demás.
A continuación se describen los atributos de validación de un requerimiento: [2]
[5].
VALIDACIÓN DE REQUERIMIENTOS
No Ambiguo
Completo
Consistente
No Repetido
Verificable
No tiene varios significados o permite más de una interpretación.
Referencia a las cosas por su nombre, evitando el uso de pronombre
(el, ella, ellos, ellas, éstos, éstas, aquellos, aquellas, etc.)
No le hace falta información para ser entendido a cabalidad.
No contradice a otro u otros requerimientos.
No hay otro requerimiento que diga lo mismo, así sea en otros
términos.
Puede asegurarse que luego del desarrollo del sistema puede
verificarse que el requerimiento fue satisfecho.
14
Independiente del
El requerimiento especifica qué se hace y no cómo se hace.
diseño
Dado que muchos de los requerimientos son conocidos por medio
Escrito en Lenguaje del cliente y es importante que este los apruebe, el requerimiento
de
debe evitar estar escrito en un lenguaje técnico incomprensible para
el cliente.
Cliente
Trazable
Se puede verificar en el código o en la documentación dónde
fue implementado el requerimiento.
Tabla 3 Validación de Requerimientos
2.5.
TRAZABILIDAD DE LOS REQUERIMIENTOS
La trazabilidad de un requerimiento consiste en saber en qué parte o partes de
la documentación o del código del sistema puede verse implementado un
requerimiento, esto con la intención de poder hacer un seguimiento a todos los
requerimientos que van siendo implementados, saber cuál es su estado, cuáles
faltan por ser implementados, y al hacer las pruebas saber exactamente cuál
requerimiento está siendo probado y en qué parte del código.
Para el manejo de la trazabilidad de los requerimientos, se ha definido una
plantilla de trazabilidad, donde para evitar los comentarios sobre el código que
no son muy accesibles para su lectura, se ordena la información de
trazabilidad sobre una tabla donde se especifica el código del requerimiento
implementado, el método que lo implementa, la clase a la cual pertenece dicho
método y el atributo que realiza el llamado a dicho método o que sirve para
realizarlo. Ver plantilla de trazabilidad de los requerimientos.
Para los requerimientos que se han implementado hasta la fecha de la entrega
de la Fase II podemos ver su trazabilidad: Ver tabla de trazabilidad.
15
3. DESCRIPCIÓN GLOBAL
3.1.
DESCRIPCIÓN DEL PRODUCTO
3.1.1. INTERFACES CON EL SISTEMA
SmartGauge es un sistema nuevo que para la entrega final al cliente es
liberado en su primera versión, este interactúa las bases de datos internas de
GS1 Colombia, específicamente de su catálogo CABASnet para la
manipulación de la información de los productos a ser tomados como
elementos de prueba.
3.1.2. INTERFACES CON EL USUARIO
Para que el usuario pueda interactuar con el sistema SmartGauge, requiere de
las siguientes interfaces:
16
PANTALLA
TÁCTIL
• Interfaz de visualización de la aplicación
móvil. Los requerimientos de esta van de la
mano con las configuraciones del sistema
operativo que administra la presentación
gráfica. Para SmartGauge se recomienda
una resolución mínima de 1024 x 768
pixeles.
SISTEMA
OPERATIVO
• El usuario puede correr la aplicación móvil
sobre cualquier sistema operativo Android
superior a la versión 3.0. El equipo servidor
debe soportar como minimo un Sistema
Operativo Microsoft Windows XP para
compilar un archivo .exe
INTERFAZ
GRÁFICA
• La impresión en pantalla de SmartGauge
estará por defecto en una resolución de
1024 x 768 pixeles y la interfaz será
implementada usando las librerías gráficas
estándar de Android.
Ilustración 3 Descripción del producto (Interfaces de Usuario)
3.1.3. INTERFACES CON EL HARDWARE
Para la conexión remota con el sistema CABASnet, se requiere seguir sus
protocolos y reglas, que están definidas por el manejo adecuado de cuatro
campos esenciales en cada tabla de la base de datos:
17
CREATION_DATE: Indica la fecha en la que fue creado un registro en la BD.
CREATION_LOGIN: Indica qué usuario creó dicho registro.
MODIFICATION DATE: Indica la fecha en la cual se realizó la última
modificación de dicho registro.
MODIFICATION_LOGIN: Indica qué usuario fue el que realizó dicha
modificación.
Para la operación de la aplicación móvil, el usuario final debe contar con un
dispositivo móvil que utilice Android como sistema operativo, la versión mínima
requerida del mismo es la 3.0, que soporta tareas de red de manera asíncrona
para utilizar los Web Services colocados en un servidor de GS1 Colombia. El
dispositivo debe contar con cámara fotográfica de resolución VGA y
conectividad a Internet; este último requisito no es de carácter permanente,
pues puede haber tareas llevadas a cabo por un servidor en momentos
específicos.
3.1.4. INTERFACES CON EL SOFTWARE
INTERFACES CON EL SOFTWARE
PRODUCTO DE
SOFTWARE
DESCRIPCIÓN
Sistema operativo para arquitecturas de
32 y 64 bits. Es el normalmente utilizado
SO WINDOWS
por hogares y empresas y está muy bien
acoplado con funcionalidades web.
Android 3.0+
El sistema operativo líder en el mercado de
dispositivos Smartphone y Tablets,
compatible con gran variedad de marcas y
desarrollado sobre Java.
PROPÓSITO DE USO
Debido a las restricciones del IDE del
desarrollo del proyecto, la aplicación
analizadora de imágenes debe
compilarse para ser una aplicación local
en un sistema operativo Windows.
Permite un proceso de desarrollo de la
aplicación bastante efectivo y ágil
debido a los conocimientos del
desarrollador.
VERSIÓN
XP, Vista o 7
3.0+
18
Aplicación de desarrollo de software
especializada en construcción de
aplicaciones para el sistema operativo Windows.
Facilita la integración y el desarrollo de los
servicios web, así como también permite
desarrollar código reutilizable al interior de
la organización, pues allí se trabaja
exclusivamente con productos Microsoft.
Microsoft
Visual Studio
2010
10.0.4
Tabla 4 Descripción del Producto (Interfaces con el Software)
3.1.5. INTERFACES DE CONEXIÓN
Para la conexión entre los equipos cliente y servidor se utilizarán servicios web
SOAP, ya que al ser servicios que soportan múltiples plataformas, permiten
una mejor escalabilidad y mantenibilidad, pues tanto la aplicación móvil, como
las demás aplicaciones de escritorio harán uso de los mismos para acceder a
la base de datos y hacer consultas y modificaciones.
3.1.6. RESTRICCIONES DE MEMORIA
El equipo servidor, ya que maneja múltiples conexiones de los clientes debe
contar al menos con 2GB de RAM para asegurar la buena atención de todos
los procesos. Por otra parte los equipos Cliente necesitan 512MB de RAM que
asegura una buena fluidez en las interacciones de la interfaz gráfica.
3.1.7. OPERACIONES
3.1.7.1.
MODOS DE OPERACIÓN
Modo Precarga: El usuario debe hacer una precarga de datos de las
empresas que visitará y de los productos que necesitan actualización.
Modo Actualización: El usuario actualiza los datos de los productos que lo
requieran y el sistema en un momento posterior actualiza el catálogo
CABASnet con la nueva información.
19
3.2.
FUNCIONES DEL PRODUCTO
Estas funciones son las interacciones que el usuario debe poder tener con el
sistema, y la descripción de dichas interacciones. Todo esto está consignado
en la definición y refinamiento de Caos de Uso de SmartGauge. [ver casos de
uso]
Sin embargo algunas de las funciones principales son las siguientes:
Realizar la conexión del usuario.
Realizar una precarga de datos de empresas y
productos.
Sincronizar la información actualizada con la base de
datos.
subir imágenes a la base de datos para su posterior
análisis.
Analizar las imágenes de la base de datos para
calcular las dimensiones de sus correspondientes
productos.
Ilustración 4 Funciones del Producto
20
3.3.
CARACTERISTICAS DEL USUARIO
Las características del usuario de SmartGauge están descritas en sus
privilegios en el sistema, sus conocimientos técnicos y sus conocimientos
sobre la aplicación así:
CONOCIMIENTOS
TÉCNICOS
DESCRIPCIÓN
Es aquel que debe realizar
una visita a un
productor/fabricante con
ánimo de actualizar datos de
productos de consumo.
El usuarió debe tener nociones
básica sobre el uso de un
dispositivo móvil tales como
conocer sus interfaces de
comunicación humano-máquina
como lo son los la pantalla táctil
y sus botones de manejo,
además de saber desplazarse sin
mayores inconvenientes en un
sistema operativo de la máquina
(SOs Windows, Ubuntu , Mac OS,
etc).
PRIVILEGIOS
CONOCIMIENTOS
DE LA APLICACIÓN
MÓVIL
El usuario puede descargar la
información correspondiente a
las visitas que debe realizar en
una jornada laboral.
USUARIO
La aplicación se destaca por
su simplicidad de uso e
interacción, esto facilita que
las tomas de datos se hagan
de una manera eficiente y
poco agotadora.
Ilustración 5 Características del Usuario
21
3.4.
RESTRICCIONES
Las restricciones de desarrollo de SmartGauge son las siguientes:
RESTRICCIÓN
Lenguaje
Legales
DESCRIPCIÓN
El sistema está diseñado bajo el
paradigma Orientado a Objetos
por lo que debe usar un lenguaje
de programación pensado bajo
éste paradigma. Se ha elegido el
lenguaje Java.
La ejecución de la aplicación no
requerirá de licenciamientos
pagos, aunque serán utilizadas
algunas herramientas de diseño
en su versión de evaluación de 30
días.
Los dispositivos de entrada/salida
requeridos por el sistema para
ser
usado por el usuario son la
Interfaces de Usuario pantalla táctil y el
teclado virtual del dispositivo
móvil. El idioma de la aplicación
y su interfaz gráfica estarán en el
idioma Español de Colombia.
Las normas del cliente definidas
por éste al inicio del proyecto no
pueden ser cambiadas. El período
Cliente
de desarrollo establecido por el
cliente es del 4 de Febrero de
2013 al 21 de Mayo del mismo
año.
Arquitectura
El software implementará una
arquitectura Cliente-Servidor.
Tabla 5 Restricciones
22
3.5.
SUPOSICIONES Y DEPENDENCIAS
Las suposiciones y dependencias sobre las cuales se desarrollará el sistema
que puedan afectar los requerimientos especificados en el documento SRS,
son los listados a continuación:




La entrega al cliente se hará en las instalaciones de GS1 Colombia, una
semana después de hacer la sustentación correspondiente al presente
trabajo de grado.
El Cliente dará los principales requerimientos y pautas para el desarrollo
del proyecto y este se iniciará con dicha base. Luego de esta iniciación
no habrá cambios en dichas pautas y requerimientos.
El cliente no pedirá funcionalidades extra luego de iniciado el desarrollo
del proyecto.
SmartGauge representa la continuación de un proyecto a ser implantado
en un ambiente productivo real, por lo cual se tiene una alta
dependencia de interfaces externas.
23
4. REQUERIMIENTOS ESPECÍFICOS
4.1.
REQUERIMIENTOS DE INTERFACES EXTERNAS
4.1.1. INTERFACES CON EL USUARIO
Para la interacción entre el usuario y la aplicación móvil deben existir como
mínimo los siguientes dispositivos y características. (Ver sección 3.1.2.)
4.1.2. INTERFACES CON EL HARDWARE
Para que los usuarios puedan crear, unirse y participar en una partida se
utilizará una arquitectura cliente-servidor. Como ya fue especificado con
anterioridad en el SPMP.
Ilustración 6 Arquitectura de conexión.
4.1.3. INTERFACES CON EL SOFTWARE
Para el diseño, arquitectura, construcción y ejecución de SmartGauge es
necesario que se tenga como mínimo disponibilidad del software que se
muestra en la siguiente imagen con su respectiva versión:
24
Eclipse Juno
Visual Studio 2010
Entorno de desarrollo para
la aplicación móvil.
(Versión 4.2)
Entorno de desarrollo para
los servicios web y la
aplicación analizadora de
imágenes. (Versión 10.0.4)
WINDOWS XP
Sistema operativo
necesario (Pueden
utilizarce sistemas
operativos más recientes)
para ejecutar las
aplicaciones de escritorio y
los IDE.
Ilustración 7 Interfaces con el Software
4.2.
CARACTERÍSTICAS DEL PRODUCTO DE SOFTWARE
Los requerimientos funcionales muestran las acciones fundamentales que
debe realizar el sistema. Para el caso de SmartGauge, las características del
software son estas funcionalidades.
A partir de la especificación de requerimientos (ver Especificación de
Requerimientos) y los casos de uso refinados (ver casos de uso refinados)
realizados.
4.3.
RESTRICCIONES DE DISEÑO
Las restricciones de diseño que existen para SmartGauge se mencionarán en
los siguientes puntos.

Restricciones de Lenguajes de Programación.
La aplicación móvil será programada de acuerdo al paradigma de
programación orientada a objetos, utilizando Java para Android y el IDE
Eclipse. Por otra parte, las aplicaciones de escritorio que harán análisis
25
de imágenes serán desarrolladas en C# utilizando el IDE Visual Studio
2010.

Restricciones de Herramientas Case.
Para el diagrama de clases y el diseño de los casos de usos se utilizará
la herramienta Visual Paradigm.

Restricciones de Arquitectura Final del Sistema.
El sistema utilizará una arquitectura de cliente-servidor para la
comunicación.

Restricciones del Cliente.
El sistema debe ser desarrollado entre las fechas 4 de febrero de 2013 y
21 de Mayo de 2013.

Restricciones Generales.
La aplicación móvil debe poseer un manual de instrucciones en el cual
se le explique al usuario su funcionamiento y características. Dicho
manual estará escrito en el idioma Español de Colombia.
4.4.
ATRIBUTOS DEL SISTEMA DE SOFTWARE (NO FUNCIONALES)
SmartGauge dispondrá de diferentes atributos de calidad que se especificarán
a continuación según su categoría.
26
4.4.1. CONFIABILIDAD
MANEJO DE INFORMACIÓN
Se asegurará que la información en la base de datos sea almacenada
correctamente según los parámetros definidos como estándar por GS1
Colombia, de manera que se hará una validación interna dentro de la aplicación
antes de sincronizar datos.
OPERATIVIDAD DE LA APLICACIÓN MÓVIL
La aplicación podrá ser utilizada sin necesidad de conexión a Internet cuando se
haya precargado información, es decir, cuando se estén efectivamente
actualizando datos en cada uno de los establecimientos a visitar.
TOLERANCIA A FALLOS
En caso de que un cliente pierda la conexión con el servidor en medio de una
sincronización, los datos descargados serán borrados y se le pedirá que
reintente la operación.
Ilustración 8 Atributos No Funcionales (CONFIABILIDAD)
4.4.2. DISPONIBILIDAD
El uso de la aplicación móvil no estará limitado por la conectividad a internet
del dispositivo, pues los datos almacenados y actualizados serán persistidos
en el mismo usando una base de datos interna SQLite hasta el momento en el
que se cuente con una conexión a Internet y se decida hacer sincronización
con la base de datos.
4.4.3. SEGURIDAD
Los parámetros de seguridad en el manejo de usuarios estarán dados por las
reglas de negocio de acceso al catálogo CABASnet. Dichos parámetros serán
llevados a la aplicación móvil y serán factores clave a la hora de integrar
ambos sistemas.
27
4.4.4. MANTENIBILIDAD
CÓDIGO
Se documentará el código que se vaya implementando, para así
llevar un control de este y además que sea entendible por los
desarrolladores futuros que se dediquen a su mantenibilidad.
MÓDULOS
Ligar cada una de las clases al requerimiento correspondiente,
esto garantiza una trazabilidad adecuada.
Ilustración 9 Atributos No Funcionales (Mantenibilidad)
4.4.5. PORTABILIDAD
El sistema puede ser ejecutado en sistemas operativos Android en un rango de
versiones que van desde la 3.0 hasta la 4.2.2, mientras se cumpla con los
requerimientos de Hardware y Software descritos anteriormente (ver sección
4.1.1.).
4.5.
REQUERIMIENTOS DE LA BASE DE DATOS
28
Los requerimientos de la base de datos estarán dados por los protocolos de
seguridad y los modelos de datos utilizados actualmente dentro del catálogo
existente, llamado CABASnet.
29