Act II - Ingeniería de Requerimientos - SRS - Ieee830

Especificación de requisitos de software
Proyecto: Administrador de rutas

Revisión [2]
SEMINARIO DE INGENIERÍA DE SOFTWARE
Universidad de Guadalajara
Centro Universitario de Ciencias Exactas e Ingenierías
Departamento de Ciencias Computacionales
13 de Octubre de 2015
Ficha del documento
Fecha Revisión Autor Verificado dep. calidad.
[05/Oct/2015] [1] [Equipo de Desarrollo] OK
[13/Oct/2015] [2] [Equipo de Desarrollo] OK
Documento validado por las partes en fecha: [13 de octubre de 2015]
Por el cliente Por la empresa suministradora
OK OK
Fdo. D./ Dña [AGQDETP S.A.] Fdo. D./Dña [Desarrollo Inteligente S.A.]
Administrador de rutas Rev. 2
Especificación de requisitos de software Pág. 4
Contenido
FICHA DEL DOCUMENTO 3
CONTENIDO 4
1 INTRODUCCIÓN 6
1.1 Propósito 6
1.2 Alcance 7
1.3 Personal involucrado 7
1.4 Definiciones, acrónimos y abreviaturas 8
1.5 Referencias 8
1.6 Resumen 8
2 DESCRIPCIÓN GENERAL 8
2.1 Perspectiva del producto 8
2.2 Funcionalidad del producto 9
2.3 Características de los usuarios 9
2.4 Restricciones 10
2.5 Suposiciones y dependencias 10
2.6 Evolución previsible del sistema 10
3 REQUISITOS ESPECÍFICOS. 11
3.1 Requisitos comunes de los interfaces. 11

3.1.1 Interfaces de usuario 11
3.1.2 Interfaces de hardware 11
3.1.3 Interfaces de software 11
3.1.4 Interfaces de comunicación 11
3.2 Requisitos funcionales 11

3.2.1 Requisito funcional 1 11
Descripción de requisitos del sofware


3.3 Requisitos no funcionales 16

3.3.1 Requisitos de rendimiento 16
3.3.2 Seguridad 17
3.3.3 Fiabilidad 17
3.3.4 Disponibilidad 18
3.3.5 Mantenibilidad 18
3.3.6 Portabilidad 18
3.4 Otros requisitos 18
4 APÉNDICES 18

1 Introducción
A continuación se presentará mediante este documento, las pretensiones que por parte del
grupo de desarrollo del proyecto se buscan alcanzar. Se justificará porque un sistema de
apoyo para usuario de transporte público en una ciudad relativamente grande y en
constante expansión como lo es Guadalajara, Jalisco, es necesaria para una mejor
experiencia en el traslado de dichos usuarios cuando para realizar este, requieren el uso del
sistema de transporte público, específicamente camiones urbanos.
Los usuarios podrán gestionar mediante una aplicación en distintas plataformas, una serie
de rutas y caminos que podrán utilizar para poder moverse de un punto a otro, es decir, se
busca que cualquier persona, independientemente de que tenga o no conocimiento de cuál
es la trayectoria diaria de un camión, o de que camiones transitan cerca de un punto de
interés para este, pueda buscar la mejor alternativa de movimiento, considerándose para
esto como los principales puntos de criterio, un ahorro en tiempo de traslado en él camión o
en caminar al punto donde se aborda, así como en el dinero y el servicio que dicho por
otros usuarios de alguna ruta de camión en específico, es brindado a los usuarios.
1.1 Propósito
Como se mencionó anteriormente, este servicio y/o aplicación está orientada
principalmente para el uso de las personas que utilizan el STP ya sea de forma regular u
ocasional.
En una ciudad tan grande como lo es Guadalajara (ciudad que será con sus colindantes,
como se pretende, el gran “lienzo” en donde se llevará a cabo la prestación del servicio
de este proyecto) los municipios cercanos geográficamente a su centro pero que para
una persona física eran distancias largas, en los últimos años han comenzado a
expandir sus límites en todas las direcciones, por lo que dichas distancias se han
recortado y donde antes eran zonas no habitadas, por este y otros factores están
urbanizándose a pasos agigantados.
Guadalajara está cada vez más “fusionada” con estas ciudades (Tlaquepaque,
Tlajomulco de Zúñiga, Tonalá, Zapopan y el Salto por mencionar algunos) y la gente al
mismo ritmo está cubriendo estas nuevas zonas, por lo que puntos de interés quedan
más retirados al paso del tiempo, provocando una complicación para que las personas
puedan moverse a ciertos lugares.
Para solucionar este problema de movilidad, se implementan tantas nuevas rutas de

camión para poder cubrir todos estos nuevos puntos habitables como sean necesarias
(en teoría), conectándolos con otros como estos, así como las zonas que ya estaban
previamente urbanizadas.
El propósito de este sistema no se dirigirá a identificar si las rutas que se utilizan en la

ciudad son las necesarias y suficientes para cubrir las necesidades de los usuarios
permitiendo que desde cualquier x posición en la ciudad, puedan llegar a otra y posición
tan solo utilizando los camiones, tampoco se busca solucionar el problema de si una ruta
tiene suficientes unidades, si no que se busca que mediante las rutas que ya están en
funcionamiento, se pueda conseguir la mejor opción (ruta o rutas de camión que en
conjunto hagan un solo trayecto final) para que mediante los recursos que las entidades
correspondientes ya nos están brindando (llámese gobierno de la ciudad o STP) puedan
ser explotados al máximo.

1.2 Alcance
Inicialmente el proyecto será desarrollado para su interacción directa con el usuario final
mediante una aplicación de escritorio y/o una página web.
Se busca que sea totalmente funcional con los camiones que entran o salen de la ciudad
de Guadalajara pero una vez trabajando de manera adecuada en este punto, y después
de haber probado la correcta funcionalidad del sistema, este podrá ser expandido para
utilizarse para la comunicación de un punto x a otro punto y con el simple hecho de
encontrarse dentro de la ZMG, independientemente de que esta ruta no transite en
ningún punto en el territorio de Guadalajara.
El principal alcance es que todas las personas que utilizan el STP podrán solucionar su
problema de traslado (llámese problema a la falta de conocimiento de cuál es la mejor
trayectoria en camiones para moverse) puedan en cuestión de pocos minutos solucionar
dicha situación con la interacción de este con nuestro sistema.
1.3 Personal involucrado
Nombre Dávalos Espinosa Humberto Francisco Javier

Rol Miembro de líderes de proyecto
Categoría profesional Licenciatura (en curso)
Responsabilidades Documento SRS
Información de contacto 3312738488
Aprobación OK
Nombre Esqueda Moreno Miguel Ángel

Responsabilidades Diseño arquitectónico
Aprobación OK
Nombre López Negrete Carlos Roberto

Responsabilidades Requerimientos funcionales
Aprobación OK
Nombre Rodríguez Loza Sergio Alain

Responsabilidades Requerimientos no funcionales
Aprobación OK

1.4 Definiciones, acrónimos y abreviaturas

STP: Servicio de transporte público.
Usuario final: Persona física que será el usuario del servicio.
ZMG: Zona Metropolitana de Guadalajara.
Punto x: Un punto cualquiera de origen en la ciudad.
Punto y: Un punto cualquiera de destino en la ciudad.
SO: Sistema operativo.
GUI: Graphic User Interface.
1.5 Referencias
Referencia Titulo Ruta Fecha Autor
1.6 Resumen
En resumen, un usuario, aunque no tenga conocimiento de las rutas que existen en la
ZMG, podrá seleccionar dentro de un mapa de la ciudad incluido en la aplicación, un
punto x y un punto y, mismos que un gestor de rutas se encargará de enlazarlos
utilizando las rutas de los camiones que actualmente están en funcionamiento,
regresándole al usuario una serie de las mejores rutas que fueron consideradas para
que este pueda seleccionar la mejor.
El mapa permitirá que aunque el usuario no tenga un gran conocimiento de la geografía

de la ciudad, poder tener mediante una interfaz agradable e intuitiva un sencillo
procedimiento para seleccionar ambos puntos.
2 Descripción general
2.1 Perspectiva del producto
Para que el sistema consiga brindar todas las características funcionales y no
funcionales que se pretenden, se requerirá de la interacción con otros sistemas y
componentes más allá de lo que este por sí mismo puede presentar.
Necesitará de un gestor de bases de datos para que información del usuario pueda ser
almacenada en memoria secundaria, así como un sistema que nos permita obtener y
utilizar el mapa de la ciudad (inicialmente se considera el mapa de Google) y una
conexión con el servidor generador y proveedor de las rutas.
Un proveedor de cualquier tipo deberá también de proporcionarnos un dispositivo GPS

que tendrá que estar incluido en el dispositivo en donde se esté ejecutando la aplicación.
Estas conexiones, en una primera instancia, se podrían modelar de la siguiente manera:

2.2 Funcionalidad del producto

Independientemente de si la aplicación es de escritorio o una página web, todo el tiempo
se manejara una interfaz para que cualquier usuario de manera intuitiva pueda utilizar
las diferentes opciones y herramientas que proporcionara el sistema.
El usuario tendrá acceso a una imagen clara de la ciudad o de la zona de esta que será
incluida para la funcionalidad del sistema de donde podrá indicar un punto de origen (x)
y un punto destino (y) y hacerle la petición al gestor de rutas para que este, mediante las
entradas ya mencionadas, devuelva una o un grupo de rutas de las cuales el usuario
seleccionara la que le parezca más apropiada.
El usuario también podrá ingresar criterios más específicos que ayudaran a esta
selección, como por ejemplo el dinero (el sistema podrá integrar o desechar rutas de
camiones de lujo como el tour que son más caros), la cantidad de camiones que puede
tomar para dicha ruta (es posible que el sistema para dirigir un punto x a un punto y
necesite más de un solo camión, pero si el usuario por ejemplo, no está dispuesto a
tomar más que solamente uno de estos, el sistema buscara una ruta de un solo camión
y si no existiera uno que recorriera una ruta que ayude con el propósito, se buscaría el
camión con el que más se encuentre lo buscado haciendo que el usuario tenga que
caminar lo menos posible).
Nuestro usuario podrá guardar la ruta en un espacio de almacenamiento a disco, mismo

que podrá utilizar en ocasiones posteriores. Esto es útil en el caso de que no se
encuentre con una conexión a internet que le permita gestionar una ruta, el usuario
podría considerar una ruta ya almacenada que en algún momento podría ser de utilidad.
Estas rutas podrá compartirlas con otros usuarios.
El sistema automáticamente ingresara alarmas por cada ruta seleccionada, mismas que
serán activadas al momento de pasar por puntos importantes, como por ejemplo cada
que tenga que bajar de la o las rutas, además el usuario tendrá la libertad de agregar
más alarmas a su gusto en un punto intermedio de la ruta seleccionada a la que se le
podrán agregar notas de voz, texto, etcétera.
El usuario podrá calificar un camión y sus servicios y/o características. No se pretende

que estas evaluaciones sean presentadas a los encargados correspondientes que
prestan el servicio de transporte pero si podrán ser almacenadas para que otros
usuarios puedan consultarlas e inclusive el gestor de rutas podrá tomarlas en cuenta
para su elección.
Se habilitara un foro para que los distintos usuarios puedan compartir sus experiencias y
recomendaciones y podrán consultar las evaluaciones de otros usuarios respecto a sus
experiencias en otras rutas.
2.3 Características de los usuarios

Tipo de usuario Cualquiera
Formación Cualquiera
Habilidades Cualquiera que tenga la facultad de utilizar aunque sea de
manera básica, un ordenador
Actividades Cualquiera

2.4 Restricciones
En esta primera etapa, el sistema se limitara a funcionar en cierta área de cobertura,
donde esperamos pueda cubrirse toda la ZMG.
2.5 Suposiciones y dependencias

 2.5.1 Para que el usuario pueda utilizar el gestor de rutas, se necesitara un
tipo de conexión a internet, puesto que la petición viajará a través de la red
hasta el prestador de servicios (teóricamente nuestro servidor que guarda las
rutas de todos los camiones).
(Es importante mencionar que este último punto puede ser modificado en el
caso de que la aplicación en el momento de su instalación, ya cuente entre sus
paquetes con la información mencionada, de ser así, no se necesitará esta
conexión pero seguirá siendo necesaria para actualizaciones).
 2.5.2 Esta conexión de internet será necesaria también para poder obtener el
mapa de la ciudad.
 2.5.3 Se supone que se podrá gestionar el permiso necesario para utilizar el

mapa de la ciudad perteneciente a Google.
 2.5.4 Se supone de igual manera que los prestadores del servicio de

transporte como los concesionarios, no presentaran dificultad al nosotros
guardar información respecto al comportamiento de sus camiones como lo son
sus rutas y calificaciones de sus servicios, puesto que estas serán almacenadas
en nuestras bases de datos y accesible a todos los usuarios.
2.6 Evolución previsible del sistema

Esta primera etapa nos brindara una aplicación bastante funcional en los aspectos que
se han mencionado anteriormente pero sigue siendo algo “reservada” si consideramos
que los campos en los que trabaja pueden ser mayormente explotados y que se puede
incursionar en otras áreas no tocadas en este instante, haciendo una aplicación mucho
más completa.
Inicialmente se mencionó que la aplicación seria de escritorio y/o web, pero para futuras
evoluciones, ambas deberían estar presentes para el usuario.
También deberá ser posible que exista una versión bastante completa para Smartphone
que debería poder ser utilizable en al menos los dos principales SO para celular (iOS y
Android) y tal vez para otros existentes como Windows phone u otros que más adelante
se pudieran presentar.
El problema inicial del transporte que estamos tratando nace a raíz de la rápida
expansión de las ciudades aledañas a Guadalajara, mismos que no son exclusivos de
esta zona (ZMG) sí no que también podemos verlos en lugares como el Estado de
México y el D.F entre otros lugares.
Una evolución del software sería su alcance, el poder presentar nuestra solución a los
usuarios de más ciudades e incluso de toda la republica mexicana.

3 Requisitos específicos.
3.1 Requisitos comunes de los interfaces.
Aún no se establecen las características que deberán tener las diferentes pantallas e
interfaces con las que el usuario deberá interactuar pero, sean cuales estas sean,
deberá, ser los más sencillas de interpretar para cualquier persona.
3.1.1 Interfaces de usuario

Como se indicó, aun no se proponen las vistas y el diseño de la aplicación en sí
pero, para en el caso de una aplicación de escritorio, será una GUI.
3.1.2 Interfaces de hardware

No aplica.
3.1.3 Interfaces de software

No aplica.
3.1.4 Interfaces de comunicación

No aplica.
3.2 Requisitos funcionales

3.2.1 Requisito funcional 1
Número de requisito RF 1
Nombre de requisito Menú principal
Tipo Requisito Restricción
Fuente del requisito Ángel Esqueda
Prioridad del Alta/Esencial Media/Deseado Baja/ Opcional
requisito
La pantalla principal del sistema deberá presentar un menú con botones; dichos
botones deberán ser: Generar ruta, historial de trayectos, y apartado social cuyo
nombre será definido en fechas posteriores.

Nombre de requisito Establecimiento de origen y destino
Fuente del requisito Carlos López
requisito
La generación de rutas se llevará a cabo a través de diferentes pasos; primero

aparecerá el mapa remarcando la posición del usuario vía GPS, aquí, el usuario
deberá especificar los puntos de origen y destino en el mapa, cabe aclarar que el
punto de origen puede ser la posición actual del usuario o cualquier otro punto.


Nombre de requisito Criterios de búsqueda
Fuente del requisito Sergio Rodríguez
requisito
Una vez especificados los puntos en el mapa, cambiará la pantalla mostrando

diferentes criterios a considerar para la generación de rutas, estos criterios se
basan en la información de las rutas de transporte público a las cuales tenemos
acceso (menor costo, menor distancia, cantidad de transbordos, higiene, trato con
el conductor, seguridad y velocidad), estos criterios podrán combinarse.

Nombre de requisito Transbordos
Fuente del requisito Javier Dávalos
requisito
Con la información proporcionada en los requisitos 2 y 3, el sistema generará

una propuesta de posibles rutas a tomar. Esta propuesta tomará en consideración
los transbordos, esto se hará estableciendo una distancia máxima a partir de las
rutas del transporte público, si dentro de esa distancia se encuentra otra ruta del
transporte público el sistema tomará en cuenta un posible transbordo. Cabe
aclarar que esto no funciona sólo para rutas del transporte público que se cruzan,
sino también toma en consideración la necesidad de bajarse de una ruta y
caminar para abordar otra.

Nombre de requisito Visualización de propuesta
requisito
La propuesta de posibles rutas se visualizará a través del mapa; el usuario
escogerá una de estas rutas, volviéndose la única visible en el mapa.

Nombre de requisito Generación de alarmas
requisito
El sistema contará con alarmas, habiendo automáticas con la posibilidad de

agregar más alarmas de forma manual; las alarmas automáticas se colocarán en
cada transbordo (de haber) y en el punto destino; por medio de un botón
activable, el usuario será capaz de colocar y remover puntos de alarma de

manera manual a través del mapa, estos puntos sólo podrán ser colocados sobre
la ruta escogida.

Nombre de requisito Tipos de alarmas
requisito
Existirán diferentes tipos de alarma, estos serán por medio de sonido, vibración, o
sonido y vibración.

Nombre de requisito Criterios de activación de alarmas
requisito
Para activar las alarmas será necesario tomar en cuenta la distancia entre los
puntos de alarma y la posición actual del usuario. La distancia a verificar tendrá
un valor por defecto (a decidir) y podrá ser modificada por el usuario al
seleccionar los puntos de alarma teniendo activo el botón de alarmas.

Nombre de requisito Activación de alarmas
requisito
Una vez que el usuario se encuentre dentro del rango del punto de alarma, ésta
deberá activarse.

Nombre de requisito Notas de alarmas
requisito
Se tendrá la posibilidad de agregar notas a las alarmas, esto será posible

seleccionando el punto de alarma teniendo activo el botón de alarmas. Las notas
se desplegarán en la pantalla al momento de activarse la alarma.


Nombre de requisito Inicio de trayecto
requisito
En el mapa, junto al botón de alarmas, aparecerá un botón para iniciar el trayecto,

cuando el usuario presione el botón aparecerá una ventana pidiendo al usuario
que confirme su decisión, de ser positiva la respuesta el sistema guardará la
fecha y hora de inicio del trayecto, al igual que activará un contador de tiempo el
cual se detendrá una vez que el usuario llegue al punto de destino; de ser
negativa la respuesta se volverá al mapa.

Nombre de requisito Pantalla principal del historial
requisito
El historial de trayectos contará con información sobre las rutas utilizadas. En la

pantalla se mostrarán las rutas junto con la fecha y hora en la que inició el
trayecto. Requisito funcional 13

Nombre de requisito Información almacenada en el historial
requisito
Al seleccionar una ruta se desplegará en la pantalla la información completa de

ésta, la cual es, además de la información mostrada con anterioridad, tiempo que
tomó llegar al punto destino, el costo total, número de transbordos, y rutas del
transporte público usadas.

Nombre de requisito Reutilización de rutas
requisito
Las rutas guardadas en el historial serán tomadas en consideración para la

generación de propuestas de rutas. Al visualizar la información de una ruta
utilizada aparecerá un botón el cual al ser activado, hará que el sistema ignore la
ruta al momento de generar nuevas propuestas de rutas.


Nombre de requisito Pantalla principal del apartado social
requisito
Al ingresar a la opción de apartado social, aparecerán en la pantalla dos botones,

uno será el acceso a un foro para los usuarios de la aplicación; y por medio del
otro se le podrá asignar calificaciones a las rutas del transporte público así como
también visualizar sus calificaciones actuales.

Nombre de requisito Foro de usuarios
requisito
El foro del apartado social funcionará como cualquier otro, en él se podrán hacer
publicaciones y consultas entre los usuarios de la aplicación. La temática
específica de los subforos falta por ser especificada.

Nombre de requisito Criterios de calificaciones
requisito
Las calificaciones que se realizarán y consultarán al seleccionar el botón

correspondiente del apartado social, serán por medio de una puntuación la cual
va desde 1 hasta 10, siendo 1 la calificación más baja y 10 la más alta; los
criterios calificables serán higiene, trato con conductores, seguridad y velocidad

Nombre de requisito Pantalla principal de calificaciones
requisito
Al seleccionar el botón de las calificaciones de rutas se desplegará en la pantalla

una lista de rutas del transporte público y su calificación general.


Nombre de requisito Filtro de rutas a mostrar
requisito
En la parte superior de la pantalla estará un botón llamado filtro, el cual al ser

presionado mostrará dos botones activables, uno para visualizar únicamente las
rutas utilizadas por el usuario; y el otro para visualizar todas las rutas; sólo uno de
esos dos botones podrá estar activo.

Nombre de requisito Visualización de calificaciones
requisito
Al seleccionar una ruta se desplegará su información en toda la pantalla, esta

información será la calificación individual de la higiene, trato con conductores,
seguridad y velocidad.

Nombre de requisito Asignación de calificaciones
requisito
Cada característica (higiene, trato con conductores, seguridad y velocidad),

además de mostrar la calificación actual, contará con un botón para que el
usuario pueda asignarle una calificación propia a dicha característica, este botón
solo podrá ser utilizado por los usuarios que hayan usado la ruta en cuestión.
3.3 Requisitos no funcionales

3.3.1 Requisitos de rendimiento
Número de requisito RNF 22
Nombre de requisito Tiempo en generar ruta.
requisito
El generador de rutas, en base a la información que el usuario ha proporcionado,

(origen, destino, criterio de rutas) procederá a generar la ruta de acuerdo a las
necesidades del usuario, en un tiempo que no deberá rebasar los 10 segundos,
siendo este variable de acuerdo a la complejidad de la ruta.


Nombre de requisito Usuarios conectados
requisito
El sistema no se verá afectado si un gran número de usuarios lo utilizan

simultáneamente.
3.3.2 Seguridad

Nombre de requisito Uso de datos personales.
requisito
El sistema no solicitara información personal al usuario para su funcionamiento.

La ubicación actual del usuario, solo se utilizara para la navegación del usuario en
la ruta seleccionada; no será visible para otros usuarios.

Nombre de requisito Historial de rutas.
requisito
En el historial se almacenara el punto de origen, el punto destino, la ruta

seleccionada por el usuario y el tiempo que tardo en su trayecto. Dicha
información se almacenara de forma local en el dispositivo que fue utilizado. Solo
se tendrá acceso al historial utilizando el mismo dispositivo.
3.3.3 Fiabilidad

Nombre de requisito Fiabilidad del sistema.
requisito
El sistema podría presentar fallas si la información ingresada no es correcta.

Siendo correcta la información ingresada se estima que 2 de cada 100 entradas
causaran fallas, con lo cual la tasa de ocurrencia de falla es de 2 %. El sistema
restablecerá el estado en el que se encontraba antes de presentarse la falla,
permitiendo que el usuario continúe con su trayecto.

3.3.4 Disponibilidad
Nombre de requisito Disponibilidad del sistema.
requisito
El sistema podrá ser utilizado las 24 horas del día, los 7 días de la semana, sin
embargo se verá limitado al horario del servicio de las rutas del transporte público.
3.3.5 Mantenibilidad
Nombre de requisito Mantenimiento del sistema.
requisito
Los desarrolladores del sistema serán los encargados de dar el mantenimiento

necesario a la aplicación; el cual consistirá en la actualización de las rutas del
transporte. Dicho mantenimiento deberá realizarse durante la noche, al menos
una vez al mes.
3.3.6 Portabilidad

Nombre de requisito Uso de lenguaje de programación.
requisito
Se desarrollara la aplicación en el lenguaje Java para facilitar la portabilidad.

Nombre de requisito Uso de sistema operativo.
requisito
La aplicación será dirigida a sistemas operativos móviles (Android, IOS).
3.4 Otros requisitos

No aplica.
4 Apéndices
No aplica.
.

Act II - Ingeniería de Requerimientos - SRS - Ieee830

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Act II - Ingeniería de Requerimientos - SRS - Ieee830

Cargado por

Copyright:

Formatos disponibles

Especificación de requisitos de software

Proyecto: Administrador de rutas

SEMINARIO DE INGENIERÍA DE SOFTWARE

Centro Universitario de Ciencias Exactas e Ingenierías

Departamento de Ciencias Computacionales

Fecha Revisión Autor Verificado dep. calidad.

[05/Oct/2015] [1] [Equipo de Desarrollo] OK

[13/Oct/2015] [2] [Equipo de Desarrollo] OK

Documento validado por las partes en fecha: [13 de octubre de 2015]

Por el cliente Por la empresa suministradora

1.3 Personal involucrado 7

1.4 Definiciones, acrónimos y abreviaturas 8

2.1 Perspectiva del producto 8

2.2 Funcionalidad del producto 9

2.3 Características de los usuarios 9

2.5 Suposiciones y dependencias 10

2.6 Evolución previsible del sistema 10

3.1 Requisitos comunes de los interfaces. 11

3.2 Requisitos funcionales 11

Descripción de requisitos del sofware

3.2.12 Requisito funcional 12 14

3.3 Requisitos no funcionales 16

3.4 Otros requisitos 18

Descripción de requisitos del sofware

Para solucionar este problema de movilidad, se implementan tantas nuevas rutas de

El propósito de este sistema no se dirigirá a identificar si las rutas que se utilizan en la

Descripción de requisitos del sofware

1.3 Personal involucrado

Nombre Dávalos Espinosa Humberto Francisco Javier

Nombre Esqueda Moreno Miguel Ángel

Nombre López Negrete Carlos Roberto

Nombre Rodríguez Loza Sergio Alain

Descripción de requisitos del sofware

1.4 Definiciones, acrónimos y abreviaturas

El mapa permitirá que aunque el usuario no tenga un gran conocimiento de la geografía

Un proveedor de cualquier tipo deberá también de proporcionarnos un dispositivo GPS

Descripción de requisitos del sofware

2.2 Funcionalidad del producto

Nuestro usuario podrá guardar la ruta en un espacio de almacenamiento a disco, mismo

El usuario podrá calificar un camión y sus servicios y/o características. No se pretende

2.3 Características de los usuarios

Descripción de requisitos del sofware

2.5 Suposiciones y dependencias

 2.5.3 Se supone que se podrá gestionar el permiso necesario para utilizar el

 2.5.4 Se supone de igual manera que los prestadores del servicio de

2.6 Evolución previsible del sistema

Descripción de requisitos del sofware

3.1.1 Interfaces de usuario

3.1.2 Interfaces de hardware

3.1.3 Interfaces de software

3.1.4 Interfaces de comunicación

3.2 Requisitos funcionales

3.2.2 Requisito funcional 2

La generación de rutas se llevará a cabo a través de diferentes pasos; primero

Descripción de requisitos del sofware

3.2.3 Requisito funcional 3

Una vez especificados los puntos en el mapa, cambiará la pantalla mostrando

3.2.4 Requisito funcional 4

Con la información proporcionada en los requisitos 2 y 3, el sistema generará

3.2.5 Requisito funcional 5

3.2.6 Requisito funcional 6

El sistema contará con alarmas, habiendo automáticas con la posibilidad de

Descripción de requisitos del sofware