Especificación de requerimientos de software P á g i n a | 1

ESPECIFICACIÓN DE
REQUERIMIENTOS DE
SOFTWARE
Para
Cappital Pooling
Versión 1.5

Producido por
Nombre del Grupo: Cappital Pooling
David Vega Cel.: 301 791 06 88 David-Vega@javeriana.edu.co
Sergio Bernal R. Cel.: 316 636 55 94 Bernal.sergio@javeriana.edu.co

Director: Luis Guillermo Torres

Curso: Trabajo de Grado Ing. Sist. 2014-3

Fecha: 26/11/2014
 Especificación de requerimientos de software P á g i n a | 2

Tabla de contenido
1 Introducción...................................................................................................... 6
1.1 Propósito del documento............................................................................ 6
1.2 Alcance de Producto .................................................................................. 6
1.3 Audiencia y vista general de producto........................................................ 7
1.4 Definiciones, Acrónimos y Abreviaciones................................................... 7
2 Descripción General ......................................................................................... 8
2.1 Perspectiva de Producto ............................................................................ 8
2.2 Funcionalidad del Producto ........................................................................ 9
2.3 Características de usuario ........................................................................ 11
2.4 Entorno de funcionamiento ...................................................................... 12
2.5 Restricciones de Diseño e Implementación ............................................. 13
2.6 Suposiciones y Dependencias ................................................................. 14
3 Especificación de requerimientos ................................................................... 15
3.1 Requerimientos de interfaces ................................................................... 15
3.1.1 Interfaces de Usuario ......................................................................... 15
3.1.2 Interfaces Gráficas de Usuario .......................................................... 16
3.1.3 Interfaces de Hardware ..................................................................... 17
3.1.4 Interfaces de Software ....................................................................... 18
3.1.5 Interfaces de Comunicación .............................................................. 19
3.2 Requerimientos de Interfaz ...................................................................... 19
3.2.1 Vista de Casos de Uso ...................................................................... 19
3.3 Requerimientos de Servidor ..................................................................... 20
3.3.1 Vista de Casos de Uso ...................................................................... 20
3.4 Requerimientos de Aplicación .................................................................. 20
4 Requerimientos no funcionales ...................................................................... 21
4.1 Atributos de calidad .................................................................................. 21
4.1.1 Requerimientos de desempeño ......................................................... 21
4.1.2 Requerimientos de disponibilidad ...................................................... 22
4.1.3 Requerimientos de escalabilidad ....................................................... 24
 Especificación de requerimientos de software P á g i n a | 3

4.1.4 Requerimientos de seguridad ............................................................ 25

4.1.5 Otros Requerimientos ........................................................................ 26
5 Apéndice A .................................................................................................... 28
 Especificación de requerimientos de software P á g i n a | 4

Lista de Gráficos

Ilustración 1 Perspectiva de producto ..................................................................... 8

Ilustración 2 Características de usuario ................................................................ 11
Ilustración 3 Etorno de funcionamiento ................................................................. 12
Ilustración 4 Interfaces de Usuario ........................................................................ 15
Ilustración 5 Interfaces Graficas de Usuario .......................................................... 16
Ilustración 6 Interfaces de Hardware ..................................................................... 17
Ilustración 7 Diagrama de Casos de Uso .............................................................. 19
 Especificación de requerimientos de software P á g i n a | 5

Lista de Tablas

Tabla 1 Funcionalidad del producto ...................................................................... 10

Tabla 2 Interfaces de software .............................................................................. 18
Tabla 3 Req. No funcional RNFD01 ...................................................................... 21
Tabla 4 Req. No funcional RNFD02 ...................................................................... 22
Tabla 5 Req. No funcional RNFD03 ...................................................................... 22
Tabla 6 Req. No funcional RNFD04 ...................................................................... 22
Tabla 7 Req. No funcional RNFI01........................................................................ 23
Tabla 8 Req. No funcional RNFI02........................................................................ 23
Tabla 9 Req. No funcional RNFI03........................................................................ 23
Tabla 10 Req. No funcional RNFEI01 ................................................................... 24
Tabla 11 Req. No funcional RNFEI02 ................................................................... 24
Tabla 12 Req. No funcional RNFS01 .................................................................... 25
Tabla 13 Req. No funcional RNFS02 .................................................................... 25
Tabla 14 Req. No funcional RNFS03 .................................................................... 26
Tabla 15 Req. No funcional RNF001 ..................................................................... 26
Tabla 16 Req. No funcional RNF002 ..................................................................... 27
Tabla 17 Req. No funcional RNF003 ..................................................................... 27
 Especificación de requerimientos de software P á g i n a | 6

1 Introducción
1.1 Propósito del documento

Este documento pretende especificar todas las características de Cappital

Pooling, para que así los desarrolladores tengan una guía permanente sobre las
características a desarrollar requeridas por el cliente.

1.2 Alcance de Producto

A continuación se describen las características que describen el alcance de este

producto:

En alcance:

a) La aplicación debe ser multiusuario con perfiles independientes y con

modos diferentes (conductor y pasajero).
b) Autentificación por medio de un nombre de usuario (correo institucional) y
una contraseña.
c) Cálculos de rating para cada usuario en cada modo representado en una
escala de 0 a 5.
d) Contador de número de viajes realizados para cada usuario en cada modo
e) Puntaje para cada usuario en cada modo. Este puntaje debe ser
representación de logros y acciones que realizan los usuarios para mejorar
la experiencia de uso de la aplicación.
f) Mensajería (solo texto) entre usuarios y entre diferentes modos.
g) Sección de noticias donde cada usuario publica lo que desee y donde se
publican noticias importantes.
h) Validación en el RUNT de licencias de conducción y tarjetas de propiedad.
i) Validación de los usuarios como estudiantes de la Pontificia Universidad
Javeriana.
j) Calificaciones a los usuarios después de cada viaje incluyendo un
comentario y un puntaje entre 0 y 5.
k) Dos tipos de viajes para crear; personalizado y express.
l) Alertas push a los usuarios para los siguientes casos:
a. Mensaje nuevo
b. Solicitud de cupo
c. Solicitudes validadas
m) Trazo de rutas de viajes por medio de Google Maps con 2 puntos mínimo y
10 máximo.

Fuera de alcance:
a) Aplicación multiplataforma
 Especificación de requerimientos de software P á g i n a | 7

1.3 Audiencia y vista general de producto

Este documento está destinado para las siguientes personas:

a) Desarrollador: Los encargados de desarrollar la aplicación.

b) Director de proyecto: Es el encargado de guiar todo el proyecto
c) Usuarios: Todo aquel que utilice la aplicación. Puede ser un estudiante, un
profesor o un jurado de trabajo de grado.

El resto del documento está distribuido de la siguiente manera:

La segunda parte hace referencia a la visión general de la aplicación. Esta

describe de manera general el contexto del producto, sus funcionalidades, las
características del usuario, el entorno donde funcionará el producto, las
restricciones del diseño e implementación y por último las suposiciones y
dependencias del producto.
La tercera parte describe la especificación de requerimientos funcionales de la
aplicación. Incluye la vista de casos de uso.

El la ultima parte se encuentra la especificación de requerimientos no funcionales

incluyendo los escenarios.

1.4 Definiciones, Acrónimos y Abreviaciones

App: Se refiere a una aplicación móvil para un Smart Phone

SRS: Especificación de Requerimientos de Software

 Especificación de requerimientos de software P á g i n a | 8

2 Descripción General

2.1 Perspectiva de Producto

Este proyecto surge como una iniciativa para mejorar la movilidad de los
javerianos como una herramienta, ofreciendo más seguridad, más usabilidad y
más sociabilidad.
Este proyecto a diferencia de los actuales proyectos de carpooling, está enfocado
solamente a plataformas móviles debido a su facilidad de uso y a su fuerte
crecimiento.
Cabe resaltar que este proyecto está enfocado principalmente a la comunidad
Javeriana, esto con el fin de poder ofrecer más seguridad al poder verificar la
autenticidad de los usuarios.
Inicialmente el proyecto se desarrollará para el sistema operativo Android, pero a
futuro (1 año) será incluido el sistema operativo IOS logrando así expandir el nicho
de mercado.
Otro aspecto importante de mencionar es la fuerte dependencia del sistema a una
plataforma CLOUD, pues la base de datos con la que funciona el sistema es
CLOUD y el sistema depende 95% de esta.

Ilustración 1 Perspectiva de producto

 Especificación de requerimientos de software P á g i n a | 9

2.2 Funcionalidad del Producto

Cappital Pooling contemplara las funciones que se detallan en la siguiente tabla:

Pantalla Función Especificación

Inicio Registrarse En esta el usuario llena un formulario

con los datos más importantes. En
esta también registra su nombre de
usuario y su contraseña
Inicio Ingresar Para ingresar se necesita el nombre
de usuario y la contraseña. Es
obligatorio que el usuario haya
validado su correo para poder
ingresar a la App.
Menú principal Mis viajes Se muestran todos los viajes que ha
(conductor) creado ese usuario. Opcional, puede
eliminar un viaje siempre y cuando
no sea un viaje finalizado.
Menú principal Mis autos Aquí se muestran los autos
(conductor) registrados por el conductor.
También se pueden agregar autos,
eliminar autos y validar autos. En
caso de eliminar un auto este no
debe tener viajes asociados
Menú principal Driver Hub Esta función tiene integrada las
(conductor) solicitudes y los mensajes. Para
solicitudes puede aceptarlas,
rechazarlas o ver el perfil. Para
mensajes puede leer y responder
mensajes.
Menú principal Crear Viaje Opción de crear un viaje
(conductor) personalizado o un viaje xpress.
Para el personalziado se muestra un
formulario, para el express se
muestra un mapa.
Menú principal Mis viajes Se muestran en una lista todos los
(pasajero) viajes asociados a ese pasajero
Menú principal Mis mensajes Se muestran en una lista todos los
(pasajero) mensajes para ese pasajero con la
opción de leer y de responder
 Especificación de requerimientos de software P á g i n a | 10

Menú principal Buscar viaje Se muestran en una lista todos los

(pasajero) viajes que han publicado los
conductores de una hora después a
la actual.
Menú principal Buscar viaje Se muestra un mapa en donde el
(pasajero) Express pasajero selecciona su punto de
destino,
Menú principal Notificaciones Se muestran las notificaciones de
mensajes y solicitudes
Menú principal Noticias En una lista se muestran las últimas
(noticias) 50 noticas publicadas por cualquier
usuario. También se pueden crear
noticias con la opción ”lápiz”
Menú principal Editar perfil En esta opción el usuario puede
modificar algunos de los datos de
registro. También puede subir su foto
de perfil y validar su licencia de
conducción.
Menú principal Cerrar sesión El usuario cierra sesión y se borran
todos sus datos locales.
Tabla 1 Funcionalidad del producto
 Especificación de requerimientos de software P á g i n a | 11

2.3 Características de usuario

Cappital Pooling sólo tiene un usuario el cual puede desempeñar dos roles. El
siguiente diagrama muestra cada rol y sus características:

Usuario Cappital
Pooling

Conductor Pasajero

Características: Características:

-Tiene carro -Usuario que puede o no tener carro

-Usa el carro regularmente -Estudiante javeriano o profesor

-Busca seguridad -De 17 años a 50 años

-Estudiante javeriano o profesor -Experiencia media-avanzada en uso

de Smart Phones
-De 17 años a 50 años
-Persona que utiliza seguido
-Experiencia media-avanzada en uso transporte publico
de Smart Phones

Ilustración 2 Características de usuario

 Especificación de requerimientos de software P á g i n a | 12

2.4 Entorno de funcionamiento

Cappital Pooling depende de 3 grandes componentes que se muestran en la

siguiente figura:

Ilustración 3 Etorno de funcionamiento

Android: Es el sistema operativo en donde es ejecutada la aplicación. Al ser

ejecutada en este sistema operativo el lenguaje de programación es Java, por lo
tanto la aplicación se desarrolla en Java para que sea nativa par Android. La
versión elegida para el desarrollo de la aplicación es 4.0 o superior.

Google Maps: Es la plataforma escogida para la representación de mapas en la

aplicación. Esto nos permite una fácil integración con el sistema operativo ya que
tanto el sistema operativo como la plataforma de mapas pertenecen a la misma
empresa. La versión utilizada de Google Maps es la 2.0 ya que no requiere de un
pago y es las conocida por los desarrolladores de Cappital Pooling.

Parse CLOUD: Es la base de datos en la nube. En esta se almacena toda la

información de cada usuario junto con la información derivada de este (viajes,
mensajes, comentarios y registro de autos). Esta plataforma también provee los
servicios push utilizados para la interacción entre usuario-usuario, usuario-
aplicación-usuario y administrador-usuario.
 Especificación de requerimientos de software P á g i n a | 13

2.5 Restricciones de Diseño e Implementación

Batería:

La betería es el principal limitante para el desarrollo móvil, pues esta tiene una
capacidad muy limitada. Para Cappital Pooling otro fuerte limitante está en el uso
del GPS y en la comunicación con la base de datos.

Uso de la base de datos:

Debido a que se utiliza un servicio gratuito, existe una limitación de solicitudes a la

base de datos por segundo, este límite es de 30 soli/s. Por lo tanto se debe
minimizar el trabajo con la base de datos.

Tiempo:

Puesto que este proyecto está establecido como trabajo de grado, se tiene un
límite de tiempo de 4 meses y medio.

Lenguaje de programación:

Cappital Pooling al ser desarrollada para Android requiere que sea desarrollada en
Java.

Seguridad:

La aplicación está enfocada solamente a la comunidad Javeriana, por lo tanto se

debe garantizar por diferentes mecanismos que los usuarios sean exclusivamente
pertenecientes a la universidad Javeriana.
 Especificación de requerimientos de software P á g i n a | 14

2.6 Suposiciones y Dependencias

Suposiciones:

 La aplicación debe ser ejecutada en sistemas operativos Android 4.0 o

superior.
 La aplicación solamente es funcional si se tiene una conexión a internet, se
habilitaran ciertas opciones en modo offline pero no lograra persistir datos
(datos o WIFI).
 La aplicación solo puede ser utilizada por la comunidad Javeriana.
 El usuario solamente puede estar conectado en un dispositivo a la vez.

Dependencias:

 Cappital Pooling depende 95% de Parse, por lo tanto la disponibilidad de

Cappital Pooling está ligada a la disponibilidad de Parse.
 Las funcionalidades de mapas dependen del servidor de Mapas de Google
 El rendimiento de la aplicación depende de las características del teléfono
celular (RAM, procesador y almacenamiento).
 El desempeño de las consultas depende de la velocidad de conexión a
internet y de la velocidad de respuesta de Parse.
 La disponibilidad de descarga de la aplicación depende de Google Play.
 EL uso masivo de la aplicación depende del periodo activo de los usuarios
(solamente en época de estudio)
 Especificación de requerimientos de software P á g i n a | 15

3 Especificación de requerimientos

3.1 Requerimientos de interfaces

3.1.1 Interfaces de Usuario

La aplicación móvil Cappital Pooling necesita de dispositivos móviles para su

correcto funcionamiento, para poder aprovechar todas las ventajas que cuentan
hoy en día la mayoría de estos dispositivos.
En el siguiente cuadro resumiré todas las características que brinda un dispositivo
móvil para que pueda ejecutar correctamente la aplicación

Pantalla Táctil
• Esta interfaz será itilizada para que el usuario puede tener
una impresion grafica de la ejecucion de la aplicación movil.

Teclado Virtual
• Esta interfaz será utilizada para ingresar datos al dispositivo
movil como caracteres alfanumericos.

Conexión Movil
• Esta interfaz sera utilizada para que el dispositivo obtenga
conexión con los datos que se alojan en el servidor remoto.

Conexión GPS
• Esta interfaz sera utilizada para que se integre la posición
geo-espacial del usuario con la aplicación y los otros
usuarios.

Ilustración 4 Interfaces de Usuario

 Especificación de requerimientos de software P á g i n a | 16

3.1.2 Interfaces Gráficas de Usuario

Cargando Registro de Creación de un Validación de Especificación

sesión de CappitalPooling Viaje en carnet ruta
CappitalPooling CappitalPooling Javeriana CappitalPooling
En esta imagen
En esta imagen se evidencia las En esta imagen En esta imagen En esta imagen
se muestra campos para se evidencia las se evidencia un se evidencia la
como esta registrarse o opciones que aviso sobre la ruta que un
cargando los para realizar el dispone la validación de usuario publico
datos previos logueo a la aplicación para carnet que un para realiza
desde el aplicacion crear viajes usuario ha
servidor realizado

Ilustración 5 Interfaces Graficas de Usuario

 Especificación de requerimientos de software P á g i n a | 17

3.1.3 Interfaces de Hardware

La aplicación móvil CappitalPooling está implementada con una arquitectura

Cliente-Servidor, la aplicación que debe estar instalada en un dispositivo móvil y
contar con sistema operativo Android, la aplicación está escrita en Java utilizando
el SDK de Android, incluyendo librerías adicional como “Parse” que se utiliza para
conectar con los servidores remotos del proveedor que actualmente nos está
ofreciendo el servicios de alojamiento de datos, lógica de algunas funcionalidades
de la aplicación, concurrencia entre otras características que serán mencionadas
en los requerimientos funcionales.

Ilustración 6 Interfaces de Hardware

En el cuadro anterior se describe las interfaces de red que proporciona el API de

parse.com ya que da la posibilidad de vincular usuarios, data, tecnología push,
todo en una sola interfaz.
Los dispositivos que soportan esta aplicación son dispositivos Android sujetos a
las versiones estables por parte del API de Parse.
 Especificación de requerimientos de software P á g i n a | 18

3.1.4 Interfaces de Software

La siguiente tabla fue utilizada a partir de la plantilla IronWorks

Producto Windows 7 Eclipse Android Parse

de
Software

Descripci Sistema Operativo IDE de desarrollo Appi que permite

que brinda la que brinda la conectar, vincular, y
ón
posibilidad posibilidad de administrar la
interactuar con generar código aplicación, de una
diferentes vinculando de manera integrada y
herramientas de manera automática ligera
desarrollo con las librerías de
Android

Propósito Debido a que es una Debido a que Brinda un

tecnología de fácil actualmente es el componente
de Uso
acceso, que permite único Framework que fundamental, para
realizar la nos brinda soporte poder gestionar de
construcción de con el desarrollo dela manera centralizada
software de manera aplicación móvil componentes de la
rápida y facil arquitectura de la
aplicación
Versión Windows Vista o Eclipse Android Juno Versión Octubre
superior 2014
Tabla 2 Interfaces de software
 Especificación de requerimientos de software P á g i n a | 19

3.1.5 Interfaces de Comunicación

La comunicaron de la aplicación móvil se soporta directamente en el API de Parse

que se encarga de realizar la conexión cliente en nuestro caso los dispositivos
móviles, con el servidor que actualmente lo gestiona la API de Parse, realizando
las conexiones con las bases de datos, servidor centralizado.

3.2 Requerimientos de Interfaz

Los requerimientos de interfaz que previamente en la descripción de describieron
(Interfaces Graficas de Usuario), se encuentran definidas de manera detallada en
el anexo (Excel requerimientos, hoja de Req. Interfaz)

3.2.1 Vista de Casos de Uso

Ilustración 7 Diagrama de Casos de Uso

 Especificación de requerimientos de software P á g i n a | 20

3.3 Requerimientos de Servidor

Los requerimientos de Servidor que previamente se describieron en (Interfaces

Graficas de Usuario), se encuentran definidas de manera detallada en el anexo
(Excel requerimientos, hoja de R. Interfaz)

3.3.1 Vista de Casos de Uso

La vista de casos de uso se encuentra detallada en el siguiente anexo (Excel
requerimientos y Casos de uso Hoja 11)

3.4 Requerimientos de Aplicación

Los requerimientos de aplicación se encuentran detallados en el siguiente anexo
(Excel requerimientos y Casos de uso Hoja 6)
 Especificación de requerimientos de software P á g i n a | 21

4 Requerimientos no funcionales
4.1 Atributos de calidad
4.1.1 Requerimientos de desempeño

 RNFD01: Una solicitud del usuario no debe tardar más de 20 segundos en

ser procesada y respondida.
 RNFD02: El sistema debe suportar un pico de 30 solicitudes por segundo a
la base de datos en su periodo activo de funcionamiento (6:00am a 8:00
pm).
 RNFD03: El sistema debe estar en capacidad en dar respuesta a por lo
menos 500 usuarios en los periodos de alta y media demanda.
 RNFD04: El sistema debe poder ejecutarse en dispositivos móviles con
Android 4.0, Memoria RAM 256MB y procesador de 800MHz

4.1.1.1 Vista de Escenarios

RNFD01

Tipo Valor

Estímulo Usuario realiza una petición

Fuente Sistema
Artefacto Componente grafico de la aplicación
Ambiente Normal
Respuesta Solicitud procesada y respondida
Medida de respuesta Tiempo respuesta menor o igual a 4
segundos
Tabla 3 Req. No funcional RNFD01

RNFD02

Tipo Valor

Estímulo Consulta a la base de datos.

Fuente Sistema
Artefacto Base de datos
Ambiente Alta demanda
Respuesta Consulta
Medida de respuesta Consulta no vacía
 Especificación de requerimientos de software P á g i n a | 22

Tabla 4 Req. No funcional RNFD02

RNFD03

Tipo Valor

Estímulo Usuarios utilizando el sistema

Fuente Sistema
Artefacto Componente grafico del sistema
Ambiente Normal Cualquier demanda
Respuesta Solicitudes procesada y entregada
Medida de respuesta Cantidad de solicitudes procesadas y
entregadas
Tabla 5 Req. No funcional RNFD03

RNFD04

Tipo Valor

Estímulo Inicio del Sistema

Fuente Sistema
Artefacto Cualquier función del Sistema
Ambiente Primera ejecución
Respuesta Función iniciada
Medida de respuesta Función procesada y ejecutada
Tabla 6 Req. No funcional RNFD04

4.1.2 Requerimientos de disponibilidad

 RNFDI01: El sistema debe estar disponible 99% de su periodo activo

(6:00am-8:00 pm Lunes a Viernes).
 RNFDI02: El sistema debe poder atender a los 200 usuarios actuales y a
los 1500 que se esperan para el próximo año sin tener que hacer mayores
cambios a arquitectura de la aplicación.
 RNFDI03: El sistema debe poder recuperarse después de un fallo o cierre
inesperado.
 Especificación de requerimientos de software P á g i n a | 23

4.1.2.1 Vista de Escenarios

RNFDI01

Tipo Valor

Estímulo Cualquier función del Sistema es

utilizada
Fuente Sistema
Artefacto Cualquier función del Sistema
Ambiente Normal
Respuesta Función es iniciada
Medida de respuesta Función ejecutada y entregada
Tabla 7 Req. No funcional RNFI01

RNFDI02

Tipo Valor

Estímulo Más de 300 usuarios utilizando el

Sistema
Fuente Sistema
Artefacto Cualquier función del Sistema
Ambiente Normal
Respuesta Función es iniciada
Medida de respuesta Función ejecutada y entregada
Tabla 8 Req. No funcional RNFI02

RNFDI03

Tipo Valor

Estímulo Fallo o cierre inesperado

Fuente Sistema
Artefacto Cualquier función del Sistema
Ambiente Normal
Respuesta Sistema deja de ejecutarse
Medida de respuesta Sistema vuelve a iniciar
automáticamente.
Tabla 9 Req. No funcional RNFI03
 Especificación de requerimientos de software P á g i n a | 24

4.1.3 Requerimientos de escalabilidad

 RNFEI01: Al definir un requerimiento nuevo el sistema debe poder

incrementar la cantidad de solicitudes por segundo a la base de datos sin
tener que hacer cambios en la arquitectura de la aplicación cuando la
cantidad de solicitudes actuales este cercana a ~28 sol/sec.
 RNFEI02: Cuando la base de datos este en un 80% de su capacidad actual
se debe poder incrementar su capacidad sin tener que efectuar cambios en
la aplicación o en la arquitectura y sin pérdida de los datos que ya se
encuentren en la base de datos.

4.1.3.1 Vista de Escenarios

RNFEI01

Tipo Valor

Estímulo Aumento de solicitudes concurrentes

Fuente Sistema
Artefacto Cualquier función del Sistema
Ambiente Normal alta demanda
Respuesta Función es iniciada
Medida de respuesta Función ejecutada y entregada
Tabla 10 Req. No funcional RNFEI01

RNFEI02

Tipo Valor

Estímulo Incremento de datos en la base de

datos
Fuente Sistema
Artefacto Crear viaje, registrar usuario, registrar
carro, crear noticia, enviar mensaje
Ambiente Normal
Respuesta Registro enviado a la base de datos
Medida de respuesta Dato insertado en la base de datos
Tabla 11 Req. No funcional RNFEI02
 Especificación de requerimientos de software P á g i n a | 25

4.1.4 Requerimientos de seguridad

 RNFS01: El sistema sólo debe registrar usuarios que pertenezcan a la

Pontifica Universidad Javeriana con un correo institucional válido.
 RNFS02: El ingreso al Sistema es únicamente por ingreso de una
contraseña y un correo institucional previamente validado.
 RNFS03: El acceso a la base de datos solo lo puede hacer el gerente de la
aplicación y/o los desarrolladores. No puede ser accedida por alguna otra
persona.

4.1.4.1 Vista de Escenarios

RNFS01

Tipo Valor

Estímulo Registro nuevo usuario correo no

Válido
Fuente Sistema
Artefacto Registro usuario
Ambiente Normal
Respuesta Registro creado
Medida de respuesta Correo de verificación no es entregado
Tabla 12 Req. No funcional RNFS01

RNFS02

Tipo Valor

Estímulo Usuario no validado intenta ingresar

Fuente Sistema
Artefacto Ingreso y registro
Ambiente Normal
Respuesta Mensaje de error en el ingreso
Medida de respuesta Intento de ingreso fallido
Tabla 13 Req. No funcional RNFS02
 Especificación de requerimientos de software P á g i n a | 26

RNFS03

Tipo Valor

Estímulo Intento de acceso a la base de datos

Fuente Base de datos
Artefacto Ingreso a la base de datos
Ambiente Normal
Respuesta Error de ingreso
Medida de respuesta Ingreso fallido datos no son alterados
Tabla 14 Req. No funcional RNFS03

4.1.5 Otros Requerimientos

 RNFO01: El sistema debe realizar copias de seguridad de las tablas de

usuarios, autos, y viajes cada vez que la cantidad de usuarios aumente en
30.
 RNFO02: EL sistema debe permitir a futuro integrar otras plataforma con la
base de datos actual de modo que desde diferente plataformas puedan
acceder a la misma información
 RNFO03: El Sistema debe poder ser descargado únicamente por medio de
las tiendas de aplicaciones de cada plataforma.

4.1.5.1 Vista de Escenarios

RNFO01

Tipo Valor

Estímulo 30 usuarios nuevos registrados

Fuente Sistema
Artefacto Registro nuevo usuario
Ambiente Normal
Respuesta JSON creado
Medida de respuesta JSON con datos actualizados
Tabla 15 Req. No funcional RNF001
 Especificación de requerimientos de software P á g i n a | 27

RNFO02

Tipo Valor

Estímulo Acceso a la base de datos

Fuente Plataforma diferente a Android
Artefacto CRUD a la base de datos
Ambiente Integración/ prueba
Respuesta CRUD procesado
Medida de respuesta CRUD realizado
Tabla 16 Req. No funcional RNF002

RNFO03

Tipo Valor

Estímulo Ingreso a Google Play

Fuente Tienda de Apps
Artefacto Descarga aplicación
Ambiente Descarga/ instalación
Respuesta Aplicación es encontrada en la tienda
Medida de respuesta Aplicación es descargada e instalada
en el dispositivo.
Tabla 17 Req. No funcional RNF003
 Especificación de requerimientos de software P á g i n a | 28

5 Apéndice A