Especificación de Requisitos

Título

de Software (ERS) para el

“Automobile Sharing System”
Proyecto Práctica obligatoria de la Asignatura “Ingeniería del
Software I”

Equipo ISW1 Versión: 1.0

Código ISW1_ASS_EREQ_2011 Fecha: 08/03/2011

Autores Félix Serna Estado: DOCUMENTO DE

REFERENCIA

Resumen Este documento presenta una Especificación de

Requisitos de Software (ERS) para la aplicación
informática “Automobile Sharing System”, a
realizar en la parte práctica de la asignatura
Ingeniería de Software I.
1. INTRODUCCIÓN ...................................................................................... 3
1.1. Propósito ........................................................................................... 3
1.2. Alcance .............................................................................................. 3
1.3. Definiciones, acrónimos y abreviaturas ............................................. 4
1.4. Visión general del documento ........................................................... 4
2.1. Perspectiva del producto ................................................................... 6
Interfaz de sistema ........................................................................... 6
Interfaz de usuario ........................................................................... 6
Interfaz hardware ............................................................................. 6
Interfaz software............................................................................... 7
Diagramas de Casos de Uso ........................................................... 7
2. CARACTERÍSTICAS DEL PRODUCTO................................................. 11
2.1. Características del Producto............................................................ 11
2.2. Características del usuario .............................................................. 11
2.3. Restricciones ................................................................................... 11
3. REQUISITOS ESPECÍFICOS ................................................................ 13
3.1. Requisitos de Interfaz ...................................................................... 13
3.2. Registro de usuarios ........................................................................ 13
3.3. Registro de rutas ............................................................................. 14
3.4. Suscripción a rutas .......................................................................... 14
3.5. Notificación a usuarios..................................................................... 15
3.6. Comunicación con el administrador ................................................. 15
3.7. Información estadística .................................................................... 16
1. INTRODUCCIÓN
El presente documento contiene una Especificación de Requisitos de Software (ERS)
para la aplicación informática “Automobile Sharing System”, a realizar en la
parte práctica de la asignatura Ingeniería de Software I. La estructura del presente
documento está basada en las directrices referidas en el estándar IEEE
Recommended Practice for Software Requirements Specifications IEEE 830-1998.

El objetivo principal de esta práctica es diseñar y construir una aplicación

informática que pueda ser utilizada por un número indeterminado de usuarios/as
para ayudarles a gestionar el uso compartido de sus automóviles para sus
desplazamientos periódicos cotidianos.

1.1. Propósito
El objeto de la especificación de requisitos es definir de manera clara y precisa tanto
las funcionalidades como las posibles restricciones del sistema de información a
construir.

Dicho documento irá dirigido tantos a los miembros del equipo de desarrollo
(alumnos de la asignatura) como al cliente del proyecto (profesor). En él, se
establecen las bases sobre las cuales el equipo de desarrollo procederá al diseño y
posterior construcción del sistema software.

También servirá de modelo en el cual basar las pruebas funcionales de aceptación

por parte del cliente y la evaluación final del producto por parte del mismo.

1.2. Alcance
El producto a desarrollar será no solamente el software “ASS”, sino también la
especificación del hardware necesario para su ejecución con unos tiempos de
respuesta que se consideren aceptables.

El sistema consistirá en una aplicación informática que permita a un número

indeterminado de usuarios, gestionar el uso compartido de sus automóviles para sus
desplazamientos periódicos cotidianos.
Se requerirá que toda la documentación referente al proceso de diseño sea
conforme al estándar UML.

1.3. Definiciones, acrónimos y abreviaturas

Sesión Mecanismo mediante el cual un usuario registrado se autentica
en el sistema (introduciendo usuario y contraseña) para
realizar actividades (añadir un nuevo podcast a la lista,
cambiar de orden, consultar los enlaces asociados...). De esta
manera la aplicación puede identificar (y por lo tanto también
distinguir) cada petición de cada usuario, y generar páginas
con contenido individualizado para cada uno de ellos.
Automóvil Vehículo que puede ser guiado para marchar por una vía
ordinaria sin necesidad de carriles y lleva un motor,
generalmente de explosión, que lo pone en movimiento.
(fuente: DRAE)
Requerimiento Función o característica que debe poseer el producto software.

Requisito Véase “Requerimiento”.

GPS Global Positioning System: sistema de posicionamiento global)

o NAVSTAR-GPS es un sistema global de navegación por
satélite que permite determinar en todo el mundo la posición
de un objeto, una persona, un vehículo o una nave, con una
precisión hasta de centímetros (si se utiliza GPS diferencial),
aunque lo habitual son unos pocos metros de precisión.
(fuente: wikipedia)
TBD “To Be Defined”. Se aplica a aquellas situaciones en las que
aún no se conoce algún valor específico relativo a algún
requisito, o todavía no se ha tomado una decisión al respecto.
Viaje En nuestro contexto, hace referencia a cada desplazamiento
de un vehículo desde el punto de origen del conductor, hasta el
destino de todo el grupo.
Ruta En nuestro contexto, trayecto genérico al que se le da un
nombre, tiene una zona de origen y un punto de destino.
El punto exacto de origen podrá ser distinto en cada viaje, y
coincidirá con el lugar en el que el conductor recoja su
vehículo.
Una ruta podrá tener varios viajes, uno por cada coche
utilizado (a distintas horas con distintos conductores), de ida o
de vuelta.

1.4. Visión general del documento

El resto del documento está estructurado en tres secciones:

Capítulo 2.- Perspectiva del producto. Visión general del documento.

Capítulo 3.- Características del Producto: Descripción general del sistema a
desarrollar, con el fin de indicar los factores que afectan al producto y sus
requerimientos. Proporciona las principales características a cumplir por el
producto.

Capítulo 4.- Requisitos específicos: Especificación detallada de los requerimientos

a satisfacer por el producto.DESCRIPCIÓN GLOBAL
2. Perspectiva del producto

El sistema actúa de manera independiente y no interactuará con ningún otro (a

excepción de los navegadores web de los usuarios).

2.1 Interfaz de sistema

Al tratarse de una aplicación web, ASS deberá de poder interactuar con navegadores
convencionales, utilizando únicamente código HTML y cierto código JavaScript.
Opcionalmente podrán usarse también plantillas CSS.

2.2 Interfaz de usuario

• La aplicación deberá de poder ser utilizada mediante un interfaz web.

• La interfaz de usuario deberá diseñarse de modo que pueda ser utilizada

tanto en pantallas con una resolución mínima de 800x600 píxeles, como en
los navegadores de teléfonos móviles con resolución mínima de 320x480
píxeles.

• Deberán aplicarse criterios estandarizados de usabilidad.

2.3 Interfaz hardware

En esta figura se muestra un diagrama de despliegue, en el que la lógica de negocio
(módulo ASS), la gestión del almacenamiento persistente y el módulo de
presentación de la aplicación web se han colocado en tres servidores
independientes, si bien estos tres elementos también podrían compartir un mismo
equipo informático.

2.4 Interfaz software

En el cliente:

• Navegador Firefox 3.0 ó superior.

• Navegador Internet Explorer 6.0 o superior.
• Android web browser.
• Soporte de javascript.
En el servidor:

• JDK 6 (disponible en http://java.sun.com)

• Contenedor de Servlets 2.4 y JSP (Java Server Pages 2.1), como por
ejemplo: Tomcat 6 o Glassfish v3.

2.5 Diagramas de Casos de Uso

Cada caso de uso está numerado para facilitar su referencia.

CU 1. Solicitar alta en el sistema

La interfaz de usuario deberá ofrecer la posibilidad de que los usuarios/as puedan

solicitar el alta en el sistema, para lo que deberán rellenar un formulario cuyos
campos son TBD. El administrador deberá recibir dicha notificación y posteriormente
podrá aceptarla o denegarla (véase CU101). El usuario deberá ser notificado
cualquiera que sea el resultado de su solicitud.

CU 2. Autenticarse en el sistema

Los usuarios no deberán poder interactuar con el sistema sin haber superado
previamente con éxito la fase de autenticación. Esta consistirá en proporcionar al
sistema una pareja válida de identificador de usuario y contraseña.

Si un usuario no interacciona con la aplicación durante 5 minutos, se cancelará esa

autenticación y deberá repetirla de nuevo.

CU 3. Gestionar perfil personal

Los usuarios podrán editar su perfil personal, que sólo deberá incluir aquellos datos
personales que sean estrictamente imprescindibles, como por ejemplo: nombre de
pila (no tiene por qué ser el auténtico), contraseña de acceso, matrícula del coche
que se comparte, número de plazas, color, coordenadas de los puntos en los que
puede esperar a ser recogido por los coches de otros usuarios (ver CU13), dirección
de correo electrónico (en la que recibir los recordatorios y mensajes “de última
hora”, ver CU08 y CU10), cuándo desea recibir los e-mail de recuerdo.

Las rutas a las que se suscribe el usuario no forman parte del perfil personal y se
contemplan en CU04.

CU 4. Establecer/editar calendario de rutas

Los usuarios/as deberán poder seleccionar una o varias de las rutas existentes y
“suscribirse” a ellas, indicando qué días de la semana va a hacer esa ruta y las
horas de salida (origen-destino) y de regreso (destino-origen).

Los usuarios podrán consultar su

lista de suscripción de rutas y
eliminar las que deseen.

CU 5. Mostrar mapa de
ruta con marcadores

Como ayuda a los usuarios que

van a realizar una determinada
ruta, la aplicación deberá poder mostrar un mapa en el que aparezcan una serie de
marcadores que indiquen la posición de las paradas a realizar donde recoger a los
otros pasajeros. La figura muestra un posible ejemplo. Pinchando en el marcador,
deberá aparecer la información asociada a ese pasajero: alias, calle en la que
espera, hora prevista y tipo de flor que llevará en el ojal.

CU 6. Mostrar mensajes recibidos del administrador (y enviados)

Los usuarios deberán poder consultar los mensajes intercambiados con el

administrador del sistema. Importante: se trata de un servicio de mensajería
interno. Esto es, no utiliza las direcciones de correo electrónico de los usuarios.

CU 7. Eliminar mensaje enviado/recibido

Los usuarios deberán poder eliminar los mensajes de la lista anterior (CU06).

CU 8. Recibir e-mail recordatorio de viaje

Con la anterioridad que cada usuario haya indicado en su perfil personal, se recibirá
un e-mail de recuerdo previo a cada viaje que vaya a realizarse. En él se indicará la
fecha y horarios de salida y regreso, quién es el conductor, identificación del coche
que se utilizará (marca, color, matrícula; para evitar equívocos y/o secuestros
innecesarios) y la lista ordenada de los otros usuarios que habrá que recoger por el
camino.

CU 9. Obtener info estadística de los viajes

Este caso de uso permite al usuario saber el número de viajes que ha realizado en
cada ruta, el número de veces que ha sido el conductor/a. También deberá mostrar
quienes han sido sus compañeros de viaje y el número de veces que han sido
conductores. Deberán aparecer ordenados de forma decreciente por el número de
veces que han sido conductores.

CU 10. Notificar incidencia puntual

Los imprevistos existen. Este caso de uso permite a un usuario cancelar su

participación en un viaje. Los demás compañeros de viaje deberán recibir
inmediatamente el texto asociado a esta notificación en un mensaje de correo
electrónico. Ningún usuario podrá conocer la dirección de correo de los demás.

Si el usuario que emite la notificación es el conductor, el sistema deberá elegir un

nuevo conductor de entre los otros pasajeros. El sistema deberá sugerir al nuevo
conductor que emita una nueva notificación en la que informe a los demás de que se
da por enterado de la nueva situación y confirme que acepta ser el conductor.
CU 11. Enviar/recibir mensaje al/del administrador

Ver CU06. El usuario deberá poder enviar mensajes de texto exclusivamente al

administrador/a y leer los que haya recibido de éste/a. Los usuarios no podrán
comunicarse entre sí usando este medio.

CU 12. Establecer fecha o rango de fechas

Este caso de uso está incluido en CU05 y CU09. Permite que el usuario establezca
una fecha o un rango de fechas. El uso que se dé a esa información dependerá de
los casos de uso que lo utilicen.

CU 13. Obtener las coordenadas de un punto señalado en el mapa

Este caso de uso está incluido en CU03, CU102 y CU103. Dado un mapa que deberá
aparecer en la página, el usuario deberá poder establecer un punto concreto en él y
el sistema deberá poder conocer sus coordenadas.

CU 101. Autorizar o denegar el alta de un nuevo usuario

Asociado con CU01. El administrador tendrá noticia de todas las solicitudes de alta
que hayan podido crear los candidatos a usuario. Deberá poder autorizarlas o
denegarlas.

CU 102. Registrar ruta

El administrador/a es el encargado de crear nuevas rutas (normalmente a petición

de los usuarios registrados).

Cada ruta tendrá un nombre descriptivo y estará definida por las coordenadas de los
puntos de origen y de destino. Dichas coordenadas serán las correspondientes a los
puntos que el administrador haya seleccionado en un mapa (ver CU13)

CU 103. Editar ruta

El administrador podrá modificar el nombre o los puntos de origen o destino de una

ruta existente (ver CU13).

CU 104. Eliminar ruta

El administrador deberá poder eliminar una ruta del sistema. Si tuviera usuarios
suscritos a ella, estos deberán recibir inmediatamente un correo electrónico en el
que se les notifique esta situación.

CU 105. Contestar mensaje de usuario

En relación a los mensajes que los usuarios pueden enviar al administrador (ver
CU11 y CU6), este deberá poder contestarles por este mismo canal.
3. CARACTERÍSTICAS DEL PRODUCTO

2.1. Características del Producto

CAR01.- Los usuarios/as de este sistema deberán poder acceder a él
identificándose mediante su nombre de usuario y su contraseña.

CAR02.- Los nombres de usuario deberán de ser únicos.

CAR03.- Las contraseñas que utilice cada usuario deberán tener al menos 6
caracteres. Aunque durante la fase pruebas, podrán ser de 1 único carácter.

CAR04.- El sistema permitirá gestionar un número indeterminado de usuarios.

CAR05.- Cada usuario podrá estar suscrito a un número indeterminado de rutas.

CAR06.- El sistema dispondrá de un modo de administración, gracias al cual un

usuario con privilegios especiales (administrador) podrá desempeñar sus funciones a
través de páginas web específicas.

CAR07.- Esos usuarios administradores, podrán modificar la contraseña de acceso

de los usuarios y también eliminar del sistema a un usuario y toda su información
asociada.

CAR08.- Cada usuario sólo podrá acceder a la información que le pertenezca.

CAR09.- El sistema contemplará los viajes previstos para los próximos 30 días.

2.2. Características del usuario

Deberá considerarse la existencia de dos tipos de usuarios:

• Usuarios: Nivel básico de conocimientos técnicos.

• Administradores: Nivel medio de conocimientos técnicos.

2.3. Restricciones
• De diseño:

o Se requiere el uso de la notación de diagramas de diseño UML.

• De implementación:

o Se requiere que la generación de páginas dinámicas y la construcción

de la lógica de programa se lleve a cabo mediante el uso de páginas
JSP, Servlets y clases Java.

o Como sistema de almacenamiento persistente podrán usarse ficheros

secuenciales, si bien el diseño de la aplicación deberá facilitar el
uso futuro de un sistema gestor de bases de datos.

o Deberá accederse al API de google maps. Ejemplos en:

http://code.google.com/intl/es-
ES/apis/maps/documentation/javascript/. Deberán cumplirse todas las
limitaciones impuestas en la licencia de utilización de dicha API.

o Todos los aspectos no contemplados en los requisitos que se muestran

en el siguiente capítulo, deberán ser interpretados por el alumno/a
según su criterio.
4. REQUISITOS ESPECÍFICOS

3.1. Requisitos de Interfaz

RQ 1. La navegación en la interfaz del sitio web “ASS” será sencilla y eficiente,
atendiendo a criterios estándar de usabilidad.

RQ 2. La estructura de páginas deberá ser homogénea.

RQ 3. El usuario deberá tener información en todo momento de la sección del

sitio web en que se encuentra.

RQ 4. Todas las páginas deberán disponer de un enlace a la página de inicio.

RQ 5. En el caso de estar navegando bajo un perfil registrado, desde cualquier

página debe incluirse la posibilidad de abandonar la sesión.

RQ 6. La interfaz web deberá poseer una estructura balanceada (4 niveles de

profundidad a lo sumo).

RQ 7. Siempre que algún tipo de información se presente en forma de tabla, la

primera de las filas deberá contener los encabezados de la información que
se muestre en cada columna. Junto a este rótulo deberán aparecer 2
símbolos (una flecha hacia arriba y otra hacia abajo) que permitan que,
cuando sean pinchadas, se reordene la información contenida en dicha
tabla de acuerdo a ese criterio y en el orden que indique la flecha (orden
ascendente o descendente). Solamente se considerará un criterio de
ordenación.

RQ 8. Con la única excepción de la página de inicio (index.jsp), no podrá

accederse a ninguna página de la aplicación web sin haber superado con
éxito el proceso de autenticación.

3.2. Registro de usuarios

RQ 9. La aplicación web no deberá ser accesible a todo el público en general.
Solamente podrán acceder a él usuarios/as registrados.

RQ 10. Al instalar la aplicación, deberá existir un usuario por defecto que tendrá el
 rol de administrador general. Su identificador de usuario y contraseña
serán “administrador” y “cambiameYA”, respectivamente.

RQ 11. Los usuarios administradores, podrán modificar la contraseña de acceso de

los usuarios y también eliminar del sistema a un usuario y toda su
información asociada.

RQ 12. Cuando un administrador elimine un usuario, deberá eliminarse también

toda la información que tenga asociada.

RQ 13. El identificador de un usuario deberá ser único en todo el sistema.

3.3. Registro de rutas

RQ 14. Los usuarios administradores deberán poder crear nuevas rutas, indicando
un punto de origen y un punto de destino. Deberán asociar a cada ruta un
nombre que será único.

RQ 15. Las rutas deberán tener un trazado teórico. Este consistirá en un polyline
que no tiene por qué seguir el trazado de las calles de la ciudad o
carreteras.

RQ 16. La aplicación deberá contemplar el mecanismo por el que los usuarios

puedan solicitar a los administradores la creación de una ruta.

RQ 17. Los administradores deberán poder modificar una ruta previamente creada.

RQ 18. Podrán existir rutas con diversos horarios de salida y de regreso.

3.4. Suscripción a rutas

RQ 19. Un usuario podrá suscribirse a cualquier ruta que haya disponible en el
sistema. De modo similar, podrá cancelar dicha suscripción en cualquier
momento.

RQ 20. Cuando un usuario se suscriba a una ruta, deberá de indicar en qué lugar
(o lugares) podrá esperar a ser recogido cuando no sea él/ella el conductor
(puntos de espera). Los puntos de espera definidos no deberán estar
situados a una distancia mayor de 500m del trazado teórico.

RQ 21. Los usuarios del sistema deberán poder buscar rutas existentes
seleccionando un punto en un mapa e indicando un radio. El sistema
deberá devolverles la lista de rutas que atraviesen, o que estén contenidas,
 en la zona indicada.

RQ 22. Los usuarios deberán poder ver dibujada sobre un mapa, el trazado de las
rutas existentes.

RQ 23. La suscripción a una ruta deberá ser periódica (no se admiten viajeros para
un único viaje).

RQ 24. Cuando un usuario se suscriba a una ruta deberá indicar qué días de la
semana está interesado en viajar.

3.5. Notificación a usuarios

RQ 25. Cuando un usuario se conecte al sistema, deberá de recibir un recordatorio
de los viajes en los que está previsto que participe durante los próximos 7
días. En él se indicará su rol (conductor o pasajero), nombre de ruta y la
hora prevista.

RQ 26. Si un usuario no puede tomar parte en un viaje previsto, deberá de poder

notificarlo al sistema. Tras ello, el sistema deberá de volver a planificar
dicho viaje.

RQ 27. Si se produce un cambio de participantes en un viaje programado en las

próximas 24 horas, el sistema deberá de enviar un correo electrónico a los
nuevos participantes para informarles de las modificaciones producidas.

RQ 28. En ningún caso podrán los usuarios conocer la dirección de correo del
resto.

RQ 29. Si debe elegirse un nuevo conductor de entre los otros pasajeros. El

sistema deberá pedir al nuevo conductor que confirme al sistema de que se
da por enterado de la nueva situación y por tanto acepta ser el conductor.
EL resto de pasajeros deberán ser informados de este hecho, mediante
algún tipo de mensaje en la página web.

3.6. Comunicación con el administrador

RQ 30. La propia página web incluirá un sistema de mensajería personal y privado,
que permita el intercambio de mensajes de texto entre el administrador y
los usuarios.

RQ 31. Los usuarios podrán eliminar los mensajes existentes en su buzón.

 3.7. Información estadística
RQ 32. Los usuarios podrán obtener una serie de resultados estadísticos relativos a
su utilización del sistema: número total de viajes realizados, número de
viajes como conductor, número de viajes como pasajero, número total de
kilómetros, kilómetros como conductor, kilómetros como pasajero.