FSD ECommerce v1.6
FSD ECommerce v1.6
FSD ECommerce v1.6
WEB ECOMMERCE
1
Functional Specification Document
Tabla de contenido
1. Definiciones de Términos...........................................................................................................4
2. Objetivo......................................................................................................................................5
3. Alcance.......................................................................................................................................5
3.1. Dentro del Alcance.....................................................................................................................5
3.2. Fuera del alcance........................................................................................................................5
4. Prerrequisitos.............................................................................................................................5
5. Supuestos...................................................................................................................................5
6. Diagrama de Contexto................................................................................................................6
6.1. Diagrama de Contexto AS IS.......................................................................................................6
6.2. Diagrama de Contexto TO BE.....................................................................................................6
7. Diagrama de Proceso.................................................................................................................7
7.1. Diagrama de Proceso AS IS.........................................................................................................7
7.2. Diagrama de Proceso TO BE.......................................................................................................7
8. Descripción Textual....................................................................................................................7
8.1. Situación Actual..........................................................................................................................7
8.2. Pantallas Actuales......................................................................................................................7
8.3. Situación Futura.........................................................................................................................8
8.4. Maquetas Futuras......................................................................................................................8
9. Casos de USO.............................................................................................................................9
10. Especificaciones del requerimiento del sistema.......................................................................10
11. Lista de Escenarios Potenciales de vulnerabilidad (Casos de Abuso Potenciales)....................12
12. Aprobaciones de Usuarios........................................................................................................14
13. Anexos......................................................................................................................................15
2
Functional Specification Document
1. Definiciones de Términos
Nº Concepto Definición
Es la versión antigua (legacy) del Ecommerce, no
1 Ecommerce V&R
está integrada con Travel Studio.
Es la nueva versión de Ecommerce que está
2 Ecommerce TS
integrada a Travel Studio
Es el nuevo software que está implementadose
3 Travel Studio para el core de negocio de Peru Rail, el equipo a
cargo de la implementación es Open Destination
Es el grupo de sistemas complementarios al
4 Satélites Travel Studio desarrollados por el equipo de
MDP.
Es el servicio Belmond Andean Explorer,
5 BAE caracterizado por ser un servicio de viaje en
cabinas.
Son todos los trenes que no sean BAE (Belmond
6 NO BAE
Andean Explorer) y se comercializan en asientos.
Es la técnica de marketing y ventas que consiste
en ofrecerle a un potencial cliente o cliente un
7 Upselling
producto o servicio similar al que quiere comprar
o que ha comprado.
Es el servicio combinado de BUS + TREN que se
brinda en las temporadas de lluvia en Cusco.
8 Bimodal Debido a las lluvias se bloquean algunas rutas y
el viaje se realiza en BUS normalmente en los
meses de Enero a Marzo.
3
Functional Specification Document
2. Objetivo
Implementar una solución web que permita compra boletos de viaje en tren.
3. Alcance
3.1. Dentro del Alcance
4
Functional Specification Document
4. Prerrequisitos
Lista de Prerequisitos
5. Supuestos
Lista de Supuestos
5
Functional Specification Document
6. Diagrama de Contexto
6.1. Diagrama de Contexto AS IS
6
Functional Specification Document
Web App
WebECommerce
Marketing
Facturación Electrónica
7
Functional Specification Document
7. Diagrama de Proceso
7.1. Diagrama de Proceso AS IS
8. Descripción Textual
8.1. Situación Actual
Reserva en Línea: PeruRail se encuentra en proceso de implementación
de una nueva herramienta integrada “Travel Studio” y sus proyectos
satélites que pasarán a reemplazar a los actuales sistemas.
8
Functional Specification Document
9
Functional Specification Document
10
Functional Specification Document
Pasarela de pagos
11
Functional Specification Document
12
Functional Specification Document
13
Functional Specification Document
Términos y condiciones
14
Functional Specification Document
Registro de Pasajeros
15
Functional Specification Document
16
Functional Specification Document
9. Casos de USO
17
Functional Specification Document
Usuarios Pasajero
Requerimientos REQ2 REQ3, REQ4
Asociados
Precondición Las etiquetas deben estar registradas en el CMS.
Los códigos de cupón deben estar registrados en el CMS.
Viaje BAE Pa Acción
so
1 El flujo inicia cuando el pasajero ingresa la información del viaje que
desea realizar. Dependiendo de la ruta seleccionada, el tipo de viaje se
califica como Belmond Andean Explorer (BAE) o No BAE.
La información para mostrar serán las Ciudades.
Origen Destino
Cusco Machupicchu
Ollaytantambo Machupicchu
Urubamba Machupicchu
NO BAE Machupicchu Ollaytantambo
Machupicchu Urubamba
Machupicchu Cusco
Puno Cusco
Arequipa Cusco
Cusco Arequipa
BAE
Puno Cusco
Cusco Puno
18
Functional Specification Document
2 Viajes BAE:
19
Functional Specification Document
20
Functional Specification Document
Rutas No BAE:
o La selección de pasajeros debe estar visible.
o La selección de infantes debe estar visible.
o Se deberá validar que la suma de pasajeros Adultos, Niños e Infantes
con asiento, no debe ser mayor a 9 (configurable en el CMS)
o La cantidad de infantes sin asiento no debe superar a la cantidad de
adultos.
o Se considera Niño a las personas entre los 3 y 11 años.
Consideraciones:
La fecha de nacimiento de los pasajeros estará restringidas a la fecha de viaje:
1. Por ejemplo, para los niños que son considerados entre los 3 y 11 años,
la fecha de nacimiento se asignará hasta dos años antes de la fecha de
viaje de ida.
2. No se podrá colocar fechas mayores o iguales a la fecha actual.
- Botón siguiente
Se validan los siguientes campos obligatorios
Rutas BAE: tipo de viaje, origen, destino, fecha de viaje.
Rutas No BAE: tipo de viaje, origen, destino, fecha de viaje, tipo de tren,
pasajeros.
Prototipo
- Búsqueda BAE:
21
Functional Specification Document
22
Functional Specification Document
- Búsqueda No BAE:
23
Functional Specification Document
24
Functional Specification Document
Listar Trenes
Código CU-002 (Código de Caso de USO)
Nombre Listar Trenes
Descripción Dirigido a viajes No BAE. El objetivo es que el pasajero pueda seleccionar el
tren en el que desea viajar y a su vez visualizar el detalle los trenes, horarios,
tarifas, eventos, promociones.
Usuarios Pasajero
Requerimientos REQ5,REQ6,REQ7,REQ8,REQ9,REQ10,REQ11,REQ12,REQ13,REQ14,RE
Asociados Q15, REQ 36
Precondición
Flujo Principal Paso Acción
1 El sistema mostrará al usuario una sección en el cual podrá
cambiar los filtros ingresados y repetir la búsqueda.
3 - Viaje Regular:
El sistema, mostrará al pasajero el listado de trenes disponibles
basados en los filtros ingresados.
En la parte superior del listado mostrará:
o Estación de llegada
(el viaje de retorno podrá editar esta información)
4 - Mensaje informativo
El sistema mostrará un pop up con el mensaje configurado en
el sistema CMS, este mensaje se configura por ruta, fecha,
25
Functional Specification Document
Listado de trenes:
o Icono del tren más el icono del bus
o Tren
o Icono informativo que mostrará en un modal el detalle del tren
o Estación (estación de enbarque)
o Hora de salida (puede ser del tren o del bus)
o Transbordo (adicional al viaje regular), dependiendo de la ruta
puede ser Bus + Tren o Tren + Bus.
o Hora de Llegada
o Tarifa regular por persona en dólares y soles
Términos y condiciones:
o Para los viajes Bimodal, los términos y condiciones varían con
respecto a los viajes regulares.
- Cupón de descuento:
Criterios:
1. Tipo de pasajero: adultos y niños
2. Tipo de descuento
o Porcentual, se aplica un porcentaje de descuento por persona y por
reserva.
o Monto fijo, se aplica un monto fijo por persona y por reserva
3. Tipo de viaje: trenes (NO BAE) y paquetes (BAE)
Flujo General:
26
Functional Specification Document
27
Functional Specification Document
28
Functional Specification Document
29
Functional Specification Document
30
Functional Specification Document
31
Functional Specification Document
32
Functional Specification Document
- Eventos:
En caso se tenga registrado eventos en el CMS, se mostrará un icono de
admiración azul al lado de la descripción del tren el cual mostrará en una
ventana emergente la información asociada al evento.
Los eventos pueden ser configurados por origen, destino, fecha de inicio,
fecha fin y trenes. La información que se registra es el texto informativo
sobre el evento, tanto en inglés como en español.
- Upselling:
Cuando el usuario seleccione su viaje y este aplique para upselling, el
sistema mostrará por única vez lo siguiente:
Información para mostrar:
o Descripción del tren
o Hora de salida
o Hora de llegada
o Monto con la diferencia entre los costos en dólares.
o Botón para visualizar el detalle.
o Botón para realizar el cambio.
Regla de Negocio:
o Son servicios con disponibilidad diferentes al servicio seleccionado
(upgrade), es decir el upselling de un servicio EXPEDITION no será
otro EXPEDITION.
o La ruta debe ser la misma que el tren seleccionado en la misma
fecha de viaje.
o Se considerará a los trenes de estaciones pertenecientes a la
misma ciudad.
o La tarifa debe ser superior a la tarifa original seleccionada.
o La hora de salida de los servicios seleccionado tienen una
diferencia de 3 horas.
o La cantidad de horas será registrada como parámetros en el módulo
de Seguridad.
o Debe ser el inmediato superior a la del tren seleccionado, este debe
encontrarse dentro de las 3 horas siguientes. En este punto se
comparan las horas de salida.
o El upselling se muestra por única vez en los servicios de Ida y
Retorno.
o Se realizará seguimiento mediante la herramienta Google Analytics
con la finalidad de identificar si el tren fue seleccionado como
33
Functional Specification Document
Post-Condición No Aplica
Criterios de 1. El sistema deberá listar los trenes en viajes de ida y vuelta considerando
Aceptación, alto todos los filtros de búsqueda ingresados.
nivel Origen
Destino
Código promoción (opcional)
Fecha de ida
Fecha de retorno
2. En caso de haber ingresado un código promocional, el sistema deberá
mostrar la tarifa regular y la tarifa con el descuento.
3. En caso de rutas bimodales, el sistema deberá mostrar la información del
transbordo.
4. En caso de upselling, el sistema deberá mostrar por única vez el viaje al
cual el pasajero puede cambiar.
5. En caso de tener registrado eventos en la fecha de viaje, el sistema
deberá mostrar el ícono de admiración para mostrar el modal con la
información del evento.
6. El sistema deberá validar que, en casos de viajes de ida y retorno, estos
tengan una diferencia mínima de 3 horas.
7. Será la configuración de Travel Studio quien indique a que tipos de
pasajeros afectará el cupón, ya sea Adultos o Niños.
8. En caso de que el monto del descuento supere el monto del precio del
pasaje, se mostrará el monto cero.
El precio del pasaje del adulto es: USD 60
El precio del pasaje del niño es: USD 30
9. Si un cupón no se encuentra registrado en el sistema CMS, este no se
aplicará en el sistema ECommerce. La forma de asociar un cupón en el
CMS versus el cupón en el Travel Studio, es mediante código de cupón
ingresado.
10. En el listado de trenes, se muestra el monto a pagar asociado a los
adultos. En caso se tenga configurado el cupón solamente para niños, se
seguirá mostrando los precios del adulto y los descuentos se visualizarán
en el carrito de compras.
Prototipo
34
Functional Specification Document
o Upselling
35
Functional Specification Document
o Eventos
36
Functional Specification Document
Listar Cabinas
37
Functional Specification Document
38
Functional Specification Document
o Cabinas disponibles
Flujo General
1. EL USUARIO: ingresará los filtros de viaje de tipo BAE.
2. EL SISTEMA: mostrará la información registrada en el CMS asociada al
cupón ingresado en el filtro.
39
Functional Specification Document
3. Montos de cabinas
El monto subtotal se mostrará tachado, se mostrará el monto del
descuento y el nuevo subtotal.
40
Functional Specification Document
4. Monto total
El monto total presenta 3 valores: antes del descuento (tachado), monto
monetario del descuento (independiente del tipo de descuento %, monto
fijo).
41
Functional Specification Document
Post-Condición No Aplica
Criterios de 1. El sistema deberá mostrar el itinerario de viaje.
Aceptación, alto 2. El sistema deberá mostrar los tipos de cabina que se tiene.
nivel 3. El sistema deberá listar la cantidad de cabinas disponibles por tipo de
cabina.
4. Si se ha ingresado un cupón de descuento, el sistema mostrará los
precios considerando el descuento.
5. Un niño no puede viajar sin un adulto en una cabina.
6. Un niño o infante no puede realizar un viajar solo.
7. Será la configuración de Travel Studio quien indique a que tipos de
pasajeros afectará el cupón, ya sea Adultos o Niños.
8. En caso que el monto del descuento supere el monto del precio del
pasaje, se mostrará el monto cero.
El precio del pasaje del adulto es: USD 60
El precio del pasaje del niño es: USD 30
9. Si un cupón no se encuentra registrado en el sistema CMS, este no se
aplicará en el sistema ECommerce. La forma de asociar un cupón en el
CMS versus el cupón en el Travel Studio, es mediante código de cupón
ingresado.
Prototipo
Itinerario
42
Functional Specification Document
43
Functional Specification Document
o idiomas
o Listado de cabinas
4.- Las opciones de CMS utilizadas en el caso de uso son
o Pasos
o Trenes
o Términos y Condiciones
o Promoción Cupón.
5.- Los métodos consumidos de MID son:
o getInfoReserva
o getListarDetalleTrenBAE
Registro de Pasajeros
Código CU-004 (Código de Caso de USO)
Nombre Registro de Pasajeros
Descripción El objetivo es que el usuario registre la información necesaria de todos los
pasajeros del viaje.
Usuarios Pasajero
Requerimientos REQ16, REQ17, REQ18, REQ 19, REQ 20
Asociados
Precondición
Flujo Principal Paso Acción
1 El sistema mostrará al usuario un formulario con la siguiente
información a completar:
Registro de pasajero Adulto
o Nombres
o Apellidos
o Genero
o Check para indicar si es contacto de compra
o Nacionalidad
o Tipo de documento
o Número de documento
o Fecha de nacimiento
o Teléfono
o E-mail
o Confirmación de email
o Check para indicar si desea recibir publicidad (marcado por
defecto)
Para viajes BAE la distribución de los formularios será por Tipo
de Cabina y pasajero.
Para viajes No BAE, la distribución de los formularios será por
pasajero.
2 Él sistema mostrará también un formulario de Información
Tributaria opcional solo para empresas peruana, la información a
registrar es:
o RUC
o Razón Social
44
Functional Specification Document
o Dirección
3 El sistema mostrará los términos y condiciones de la reserva.
4 El pasajero dará click en siguiente para continuar con el proceso.
Flujo Alterno 1. Viajes con Infantes sin asiento en rutas no BAE
Todos los pasajeros infantes sin asiento deberán estar asociados a un
adulto, cuando el sistema identifique que viajan infantes sin asiento, en el
registro de la información de adultos se mostrará:
o Check para indicar si el pasajero adulto lleva un infante
45
Functional Specification Document
46
Functional Specification Document
4. Información Tributaria
En caso lo requiera, el pasajero podrá registrar su información tributaria la
cual se visualizará en su factura.
La información por registrar es:
o RUC
o Razón Social
o Dirección
Post-Condición No Aplica
Criterios de Validación de los campos a registrar de un pasajero:
Aceptación, alto 1. Nombre de pasajero:
nivel Es un campo obligatorio.
Tiene un tamaño máximo de 50 caracteres.
Al digitar, deberá mostrarse el texto en mayúscula.
No permitirá caracteres especiales ni números permitiendo solo letras,
espacios en blanco, tildes, apóstrofes y diéresis.
No permitirá que se registren la misma letra 3 veces seguidas.
2. Apellido del pasajero:
Es un campo obligatorio.
Tiene un tamaño máximo de 50 caracteres.
Al digitar, deberá mostrarse el texto en mayúscula.
No permitirá caracteres especiales ni números permitiendo solo letras,
espacios en blanco, tildes, apóstrofes y diéresis.
No permitirá que se registren la misma letra 3 veces seguidas.
3. Fecha de Nacimiento:
Campo obligatorio
El sistema validará que el formato sea de tipo fecha.
4. Nacionalidad:
Campo obligatorio.
Campo de tipo selección.
5. Tipo de documento:
Campo obligatorio.
Campo de tipo selección.
6. Número de documento:
Campo obligatorio.
Pasaporte:
o Permitirá de 5 a 16 caracteres alfanuméricos.
47
Functional Specification Document
Reglas de negocio:
12. Por regla de negocio, se permitirá registrar solo un contacto de compra.
13. Por regla de negocio, el número de documento solo admitirá dígitos y un
mínimo 8 caracteres.
14. Por regla de negocio, el check "Quiero recibir novedades" estará habilitado
únicamente para pasajeros adultos.
15. Por regla de negocio, se debe asociar todos los infantes sin asiento a un
adulto.
16. Por regla de negocio, la cantidad máxima de pasajeros por cabina es dos.
17. Por regla de negocio, la cantidad máxima de pasajeros por compra es
nueve.
18. Por regla de negocio, un niño o infante no puede realizar un viajar solo.
19. Por regla de negocio, un niño no puede viajar sin un adulto en una cabina.
Prototipo
48
Functional Specification Document
Viajes BAE
o Registro de Pasajeros
Viajes No BAE
o Registro de Pasajeros
49
Functional Specification Document
Registro de Pago
Código CU-005 (Código de Caso de USO)
Nombre Registro de Pago
Descripción El objetivo es que confirme su reserva realizando el pago de la misma
mediante la pasarela de pagos.
Usuarios Pasajero
Requerimientos REQ 29, REQ 30, REQ 31, REQ 32
Asociados
Precondición
Flujo Principal Paso Acción
1 El sistema mostrará en un primer bloque la información del viaje:
Viajes BAE:
o Nombre completo del pasajero
o Ruta a realizar
50
Functional Specification Document
51
Functional Specification Document
52
Functional Specification Document
Pago Denegado
Se da cuando el usuario ingresa en dos oportunidades información
errónea de su tarjeta o esta no permite realizar el pago por motivos
externos a la aplicación.
El sistema procederá a anular la reserva y liberar los asientos o
cabinas asociados.
El sistema emitirá un correo electrónico informando que la reserva fue
anulada.
Post-Condición No Aplica
Criterios de 1. El sistema deberá mostrar las modalidades de pago.
Aceptación, alto 2. El sistema deberá mostrar los términos y condiciones para realizar el
nivel pago.
3. El sistema le dará al usuario hasta 2 intentos para realizar su pago.
4. El sistema deberá validar el pago mediante la pasarela de pagos y emitir
un resultado en base al flujo indicado.
5. Dependiendo del resultado, el sistema dará la opción a descargar el ticket
o boletos de viaje.
Prototipo
o Pasarela de pago
53
Functional Specification Document
54
Functional Specification Document
Enviar email
Código CU-006 (Código de Caso de USO)
Nombre Enviar email
55
Functional Specification Document
Descripción El objetivo de este caso de uso es que se notifique al usuario vía correo
electrónico el resultado de la reserva del ticket.
Usuarios Pasajero
Requerimientos REQ 34
Asociados
Precondición
Flujo Principal Paso Acción
1 Notificación por email:
Con la información ingresada por el usuario, el sistema validará
el pago y emitirá un correo electrónico con el resultado del pago
los cuales podrían ser:
o Compra exitosa
o Validación
o Denegado
2 Compra exitosa:
o El sistema enviará al usuario la confirmación de su reserva
incluyendo los boletos de viaje adjuntos en un documento pdf.
Flujo Alterno Compra exitosa: En caso de darse una compra exitosa, se deberá validar:
o Si es un Servicio Belmond Andean Explorer, el correo a enviar es exitoso
e incluye los tickets adjuntos.
o Si la fecha de viaje está dentro de los próximos 15 días y el servicio es
Hiram Bingham o Belmond Sacred Valley, el correo a enviar es
observado y no se incluyen los tickets adjuntos. El pasajero deberá
recoger sus tickets personalmente.
o Si la fecha de viaje está dentro de los próximos 30 días y el servicio es
Perurail Titicaca o Vistadome o Expedition, el correo a enviar es
observado y no se incluyen los tickets adjuntos.
Validación:
o El sistema notificará al usuario vía correo electrónico la confirmación de
su reserva, pero no enviará el documento pdf adjunto ya que es
necesario que el usuario se acerque a recogerlos personalmente a una
de las agencias.
Pago erróneo
o El sistema notificará al usuario vía correo electrónico que su reserva ha
sido cancelada.
Post-Condición No Aplica
Criterios de 1. El sistema deberá enviar el correo electrónico en caso de compra exitosa
Aceptación, alto incluyendo el ticket adjunto.
nivel 2. El sistema deberá enviar el correo electrónico en caso la compre se
56
Functional Specification Document
57
Functional Specification Document
Reimprimir ticket
Código CU-007 (Código de Caso de USO)
Nombre Reimprimir ticket
Descripción El objetivo de este caso de uso es que el usuario tenga la opción de descargar
su boleto en formato pdf.
Usuarios Pasajero
Requerimientos REQ 35
Asociados
Precondición
Flujo Principal Paso Acción
1 El pasajero deberá seleccionar la forma en la que desea realizar la
búsqueda de un ticket:
Búsqueda por nombre
Búsqueda por reserva
Búsqueda por ticket
58
Functional Specification Document
5 Resultados de búsqueda:
Realizada la búsqueda, la información que se muestra es:
o Ticket
o Apellidos y nombres del pasajero
o Ruta
o Fecha de salida
o Hora de salida
o Moneda
o Importe
59
Functional Specification Document
6 Descarga:
El pasajero tendrá la opción de descargar su boleto en formato
pdf.
Flujo Alterno No Aplica
Post-Condición No Aplica
Criterios de 1. El sistema, en base al tipo de búsqueda y a los filtros ingresados,
Aceptación, alto permitirá acceder al ticket de compra.
nivel 2. El sistema deberá permitir al pasajero la descargar de la información en
formato pdf.
Prototipo
60
Functional Specification Document
Buscar Trenes
61
Functional Specification Document
Usuarios Pasajero
Requerimientos REQ 1
Asociados
Precondición Las etiquetas deben estar registradas en el CMS.
Los códigos de cupón deben estar registrados en el CMS.
Viaje BAE Pas Acción
o
1 El flujo inicia cuando el pasajero ingresa al Home (actualmente en
WordPress) para buscar una ruta de tren para viajar. Dependiendo de la
ruta seleccionada, el tipo de viaje se califica como Belmond Andean
Explorer (BAE) o No BAE.
Origen Destino
Cusco Machupicchu
Ollaytantambo Machupicchu
Urubamba Machupicchu
NO BAE Machupicchu Ollaytantambo
Machupicchu Urubamba
Machupicchu Cusco
Puno Cusco
Arequipa Cusco
Cusco Arequipa
BAE
Puno Cusco
Cusco Puno
2 rutas BAE:
62
Functional Specification Document
63
Functional Specification Document
- Botón siguiente
Se validan los siguientes campos obligatorios
Rutas BAE: tipo de viaje, origen, destino, fecha de viaje.
Rutas No BAE: tipo de viaje, origen, destino, fecha de viaje, tipo de tren,
64
Functional Specification Document
pasajeros.
Prototipo
- Búsqueda en el Home
- Búsqueda No BAE:
Pop up bimodal
65
Functional Specification Document
Estilos Belmond
Usuarios Pasajero
Requerimientos REQ 37
Asociados
Precondición Se debe enviar la información indicada a la web ECommerce para que esta la
interprete y se adapte.
Viaje NO BAE Paso Acción
1 El flujo inicia cuando el pasajero ingresa a la página web de Belmond, e
ingresa la información del viaje que desea realizar.
66
Functional Specification Document
67
Functional Specification Document
o Listado de Trenes
68
Functional Specification Document
5 Paso 4: Pago
69
Functional Specification Document
Post-Condición
Criterios de Adaptación de los estilos Belmond a la página web ECommerce.
Aceptación Adaptación de los correos Belmond a la página web ECommerce.
Se respetará la estructura y distribución de la información que muestra el
ECommerce.
Prototipo
70
Functional Specification Document
71
Functional Specification Document
datos así obtenidos son utilizados posteriormente para realizar otro tipo de
ataques, o para su venta.
11.5.
72
Functional Specification Document
13. Anexos
N Anexo Archivo
°
1 Diagrama de Contexto
Diagrama Contexto
ECommerce.vsdx
2 Diagrama de proceso AS IS
1. Diagrama de
Proceso ECommerce AS IS.bpm
3 Diagrama de Proceso TO BE
2. Diagrama de
Proceso ECommerce TO BE.bpm
73