FSD ECommerce v1.6

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 73

Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

Functional Specification Document

WEB ECOMMERCE

MDP CONSULTING S.A.


GERENCIA DE DESARROLLO

1
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

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

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

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

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

2. Objetivo
Implementar una solución web que permita compra boletos de viaje en tren.

El siguiente documento tiene como propósito exponer la especificación de los


requerimientos funcionales identificados para el Ecommerce: búsqueda de viajes,
selección de trenes o cabinas, registro de pasajero, pagos y correos dirigidos al
cliente. Las funcionalidades implementadas están integradas al sistema core Travel
Studio.

3. Alcance
3.1. Dentro del Alcance

Nro Grupo Funcionalidad


REQ 1 Site Widget de Motor de Búsqueda
REQ 2 Paso 1 Búsqueda Búsqueda de Tren
REQ 3 Paso 1 Búsqueda Pop up Bimodal
REQ 4 Paso 1 Búsqueda Bloqueo de fechas
REQ 5 Paso 2 Trenes Modificar búsqueda de tren
NO BAE
REQ 6 Paso 2 Trenes Calendario
REQ 7 Paso 2 Trenes Listado de trenes Regular
REQ 8 Paso 2 Trenes Popup información de Tren Turístico
REQ 9 Paso 2 Trenes Listado de trenes Bimodal
REQ 10 Paso 2 Trenes Selección de trenes
REQ 11 Paso 2 Trenes Cupón de Promoción
REQ 12 Paso 2 Trenes Upselling
REQ 13 Paso 2 Trenes Monto total por pagar
REQ 15 Paso 2 Trenes Términos y condiciones
REQ 16 Paso 3 Datos de Pasajeros Registro de pasajero adulto
REQ 17 Paso 3 Datos de Pasajeros Registro de pasajero niño
REQ 18 Paso 3 Datos de Pasajeros Registro de infante con asiento
REQ 19 Paso 3 Datos de Pasajeros Registro de infante sin asiento
BAE
REQ 21 Paso 2 Trenes Itinerario del viaje
REQ 22 Paso 2 Trenes Disponibilidad de cabinas

4
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

REQ 23 Paso 2 Trenes Selección de cabinas


REQ 24 Paso 2 Trenes Monto total por pagar
REQ 26 Paso 3 Datos de Pasajeros Registro de pasajero adulto por cabina
REQ 27 Paso 3 Datos de Pasajeros Registro de pasajero niño por cabina
REQ 28 Paso 3 Datos de Pasajeros Registro de información tributaria
REQ 29 Paso 4 Confirmación y Pago Aceptar términos y condiciones
REQ 30 Paso 4 Confirmación y Pago Popup términos y condiciones
REQ 31 Paso 4 Confirmación y Pago Pasarela de pago (Visa, Mastercard, PayPal)
REQ 32 Paso 4 Confirmación y Pago Confirmación de la compra
REQ 33 Ecommerce Google Analytics
REQ 34 Ecommerce Mailing
REQ 35 Ecommerce Reimpresión
GENERAL
REQ 36 Mensaje Informativo Mensaje informativo
El ECommerce se adaptará a los estilos
REQ 37 Estilos Belmond Belmond solo a nivel visual, manteniendo
su estructura.

3.2. Fuera del alcance


Los puntos no considerados en el Ecommerce TS.

- Contenido y funcionalidades del Word Press, solo consideraremos un widget


para el motor de búsqueda.

4. Prerrequisitos
Lista de Prerequisitos

5. Supuestos
Lista de Supuestos

5
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

6. Diagrama de Contexto
6.1. Diagrama de Contexto AS IS

6
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

6.2. Diagrama de Contexto TO BE


Sistema ECommerce

WP: Ecommerce CMS v2.0


URL: pax3.perurail.com

WP: Web Peru Rail


URL: www.perurail.com Portal: Ecommerce v2.0
Invitado URL: pax4.perurail.com

Global Collect Google Analytics SafetyPay

Web App
WebECommerce

Virtual Machine TravelStudio SQL Server - MDP / Belmond


CMS ECommerce

Marketing

Web App - API PR

Facturación Electrónica

7
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

7. Diagrama de Proceso
7.1. Diagrama de Proceso AS IS

7.2. Diagrama de Proceso TO BE

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

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

8.2. Pantallas Actuales


 Búsqueda de tren:

 Selección de viaje (rutas NO BAE)

 Mostrar Itinerario (rutas BAE)

9
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

 Selección de Cabinas y Pasajeros (Rutas BAE)

 Registro de la información de Pasajeros

10
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

 Pasarela de pagos

8.3. Situación Futura


Reserva en Línea: Implementar una solución en línea que permita reservar
y compra boletos de viaje en tren. La solución contará con información de
rutas, trenes, cabinas, disponibilidad, itinerarios, pasarela de pago, fotos,

11
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

información turística, alertas, además de administrar las variables y


configuraciones; obteniendo la información desde los servicios de Travel
Studio (TS)

8.4. Maquetas Futuras


 Búsqueda de tren

 Listado de Trenes y aplicación de Upselling (No BAE)

12
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

 Detalle del Upselling

 Trenes Bimodal y aplicación de descuento (No BAE)

13
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

 Detalle del tren

 Términos y condiciones

14
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

 Registro de Pasajeros

 Confirmación y pago de reserva

15
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

16
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

9. Casos de USO

17
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

10. Especificaciones del requerimiento del sistema


Buscar Trenes

Código CU-001 (Código de Caso de USO)


Nombre Búsqueda de tren
Descripción El objetivo es darle al pasajero las herramientas para encontrar el tren en el que
desea viajar e iniciar con la reserva de este. El pasajero deberá seleccionar la
ruta, las fechas de viaje y la cantidad de pasajeros. De forma opcional tendrá la
opción de ingresar un cupón de descuento.

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

Internamente la Ciudad Cusco, contiene estaciones asociadas y por cada


una de ellas se mostrará la información de los trenes o cabinas en el paso
siguiente:
Nombre Ciudad Nombre Estación
Ciudad del Cusco Poroy
Ciudad del Cusco Wanchaq
Ciudad del Cusco San Pedro

18
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

2  Viajes BAE:

Se muestran los siguientes campos en el motor de búsqueda

o Tipo de viaje solo de ida.


o No se muestra la cantidad de pasajeros (adultos, niños, infantes)
o Los viajes se realizan una vez por semana (configurable en el
CMS).
o Puno – Cusco: miércoles
o Cusco-Puno: martes
o Arequipa – Cusco: sábado
o Cusco – Arequipa: jueves
o Para las rutas compartidas Puno – Cusco y viceversa se habilita
un campo el tipo de tren en el cual podrá seleccionar entre el tren
Titicaca Train y Belmond Andean Explorer.
o Al seleccionar el tipo de tren Belmond Andean Explorer se
habilita un pop up.

3 En caso el usuario cuente con un código de cupón de descuento, deberá


marcar el check “Cupón de descuento” para habilitar el campo e ingresar
su código.
4 Las fechas de viajes pueden ser deshabilitados basados en la información
registrada en el CMS en la opción Bloqueo de Fechas, al pasar el cursor
por la fecha bloqueada se podrá visualizar el motivo del bloqueo.
5 Se puede modificar el idioma al modificar en la parte superior derecha el
idioma de la aplicación haciendo que todas las etiquetas se modifiquen al
idioma seleccionado.
6 Se muestra el mapa registrado en el CMS para el origen y destino
seleccionado.
Viaje NO BAE 7 - Viajes NO BAE:
o o Los tipos viajes de ida y retorno se encuentran habilitados.
o Todas las fechas de viaje de ida y retorno, por defecto, se encuentran
o habilitadas
o o El comprador deberá ingresar la cantidad de pasajeros (adulto, niño)
que realizarán el viaje.
o El pasajero deberá indicar si viaja con infantes y de ser así deberá
indicar la cantidad de infantes con asiento y la cantidad de infantes
sin asiento.

8 En caso el usuario cuente con un código de cupón de descuento, deberá


marcar el check “Cupón de descuento” para habilitar el campo e ingresar
su código.

19
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

9 Las fechas de viajes pueden ser deshabilitados basados en la información


registrada en el CMS en la opción Bloqueo de Fechas, al pasar el cursor
por la fecha bloqueada se podrá visualizar el motivo del bloqueo.

10 Para las rutas compartidas Puno – Cusco y viceversa se habilita un campo


el tipo de tren en el cual podrá seleccionar entre el tren Titicaca Train y
Belmond Andean Explorer.

Al seleccionar el tipo de tren PeruRail TiticacaTrain se habilita un pop up


11 Se puede modificar el idioma al modificar en la parte superior derecha el
idioma de la aplicación generando que todas las etiquetas se modifiquen
al idioma seleccionado.
Se muestra el mapa registrado en el CMS para el origen y destino
12 seleccionado.
Flujo Alterno  Bimodal:
o Cuando se seleccione una ruta y fecha Bimodal (configurada en el CMS),
automáticamente se mostrará un pop up con la descripción de esta.
o La descripción para mostrar estará configurada en el CMS en la opción
Temporada Bimodal.

 Rutas No BAE (Perurail Titicaca Train):


o Se reservan viajes solo de ida.
o Los calendarios fueron todas las fechas activas a partir de la fecha en la que
se ingresa el sistema hacia adelante excepto para el tren Titicaca Train.
Cusco-Puno: domingo, miércoles, viernes.
Puno-Cusco: lunes, jueves, sábado.
o Deberá indicar la cantidad de pasajeros que viajan.
o Al seleccionar una ruta compartida, se mostrará el campo Tren con la
finalidad que el usuario seleccione el tren en el que desea viajar, sus
opciones son Belmond Andean Explorer o Perurail Titicaca Train.

Post-Condición Se direcciona al paso 2 del Ecommerce.


Criterios de - Fechas de búsqueda:
Aceptación  Rutas BAE:
o Se reservan viajes solo de ida por lo cual se deberá ocultar el campo
fecha de retorno.
o Los viajes se realizan una vez a la semana, por lo cual se deben tener
habilitados solo un día a la semana en el calendario.
o Se deberá ocultar el campo fecha de retorno.
 Rutas No BAE:
o Por defecto estarán habilitados todos los días de la semana.
o Se deshabilitarán las fechas configuradas en el CMS en la opción
bloqueo de fechas, mostrando el mensaje configurado con la
descripción del bloqueo.
o Se pueden configurar viajes de ida y vuelta.

 Rutas No BAE (Perurail Titicaca Train):


o Se podrán reservar viajes solo de ida, por lo cual se oculta el campo

20
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

fecha de regreso y el check ida y retorno.


o Los viajes se realizan tres veces a la semana, por lo cual se deben
tener habilitados solo tres días a la semana en el campo ida.
 Todos:
o Se deshabilitan las fechas previas a la fecha actual.
o La fecha de retorno no puede ser menor a la fecha de ida.
o Si al seleccionar la fecha de ida, la fecha de retorno no tiene un valor
asignado o tiene un valor menor a la fecha de ida, se le debe asignar la
fecha de ida seleccionada.
o Si al seleccionar la fecha de ida, la fecha de retorno tiene un valor
mayor asignado, este mantiene su selección.
o Cuando se seleccione viajes solo de ida, se debe deshabilitar el campo
de fecha de retorno.
o La fecha de retorno deberá bloquear las fechas menores a la fecha de
ida.
o Al cargar la página, por defecto las fechas de ida y retorno deberán
tener el valor de la fecha actual.
o Cada vez que se cambie la ruta, se deben de limpiar los campos de
fecha de ida y de retorno.
- Pasajeros:
 Rutas BAE:
o La selección de pasajeros (adulto, niño, infante) no debe mostrarse.

 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

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

Modal viaje BAE

22
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

- Búsqueda No BAE:

23
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

Detalles Técnicos 1.- Las fechas de disponibilidad de viaje corresponden a la configuración


realizada en TS.
2.- Los parámetros usados en el caso de uso son.
o idiomas
o max_compra
o rutas
o origen
o destino
3.- Las opciones de CMS utilizadas en el caso de uso son
o Pasos
o Bloqueo de fechas
o Temporada Bimodal
o Términos y Condiciones
o Promoción Cupón.

24
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

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.

El motor de búsqueda mostrado en la parte superior de la pantalla


tiene las mismas funcionalidades descritas en el motor de
búsqueda del CUS 01.

2 Los listados de trenes estarán agrupados por el tipo de viaje a


realizar (ida y vuelta).

Listado de trenes de ida en la parte superior y el listado de trenes


de retorno en la parte inferior (solo para el tipo de viaje ida y
retorno)

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)

 El listado de trenes tiene la siguiente cabecera:


Nombre del tren
Estación
Hora de salida
Hora de llegada
Tarifa de Pasajero
 La información que se muestra es:
o Tren
o Icono informativo que mostrará en un modal el detalle
del tren
o Estación
o Hora de salida
o Hora de Llegada
o Tarifa regular por persona (adulto) en dólares y soles

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

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

idioma y paso en que se desea mostrar.


5 - Como resumen del listado de trenes, en la parte inferior se
mostrará la siguiente información:
 Monto del costo total del o los viajes en dólares.
 Monto del costo total del o los viajes en soles.

6 El sistema mostrará los términos y condiciones del paso2.


7 El pasajero dará click en siguiente para continuar con el proceso.
Flujo Alterno - Viaje Bimodal:
Los viajes bimodales se dan cuando parte de la ruta se realizará en bus,
motivo por el cual existe un horario de transbordo.

 El título de listado varía a Servicio Bimodal.

 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)

La configuración de la promoción se realiza en Travel Studio, cuando el


ECommerce consulte la ruta verificará los trenes que tengan cupón.

Flujo General:

1. El USUARIO ingresa los filtros de búsqueda de viajes No BAE. Se


considerará el ingreso del filtro “Código de Promoción”.

26
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

2. EL SISTEMA: Listara los trenes basados en los filtros ingresados.


Nota: El método MDL a invocar es el “getListarTrenesNoBAE”, el cual
traerá la información estructurada de la siguiente manera:

Bloque INFORMACIÓN DE LOS SERVICIOS


1  CUPONES ASOCIADOS AL SERVICIO
Bloque INFORMACIÓN DE LOS CUPONES
2  DETALLE DE LOS CUPONES.
3. EL SISTEMA: mostrará el mensaje informativo que se encuentre
configurado en el sistema CMS, considerando la ruta, las fechas, el
idioma y el paso en el que se encuentre:

27
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

4. EL SISTEMA: procederá a aplicar el cupón de descuento ingresado en el


filtro.
Con respecto a los servicios que no se encuentren asociados al cupón
ingresado, el sistema mostrará los precios regulares.
5. EL SISTEMA: aplicará estas acciones para los viajes de IDA y RETORNO.

6. EL USUARIO: Procederá a seleccionar el viaje de IDA y RETORNO.


7. EL SISTEMA: Procederá a calcular el monto total:
Los descuentos aplicados se mostrarán en “montos monetarios”.
Por ejemplo, si el monto a pagar es USD 189.20 y se cuenta con un
descuento del 10.00 %, el monto de descuento promocional a mostrar
será el descuento monetario que sería USD 20.00.

28
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

1. No BAE: Cupón de descuento porcentual por persona


 En el listado de trenes, se mostrará la siguiente información:
o Icono con el título de la promoción.
 Este título se registrará y configurará en el sistema CMS.
o Tren
o Icono informativo que mostrará en un modal el detalle del tren.
o Hora de salida
o Hora de Llegada
o Tarifa regular por persona en dólares y soles (tachada).
o Tarifa promocional por persona en dólares y soles.

 Al seleccionar un registro con cupón, se mostrará el detalle de la


información estructurada, y adicional, la información que se encuentre
registrada en el sistema CMS.

29
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

Dentro del cuadro de la información del cupón, se puede encontrar el


botón “See terms and conditions” el cual permitirá mostrar u ocultar los
términos y condiciones registrados en el CMS.

La información estructurada se encuentra dentro del cuadro rojo,


mientras que la información que se obtiene desde lo configurado en el
CMS se encuentra en el cuadro azul.

o En caso se seleccione un servicio el cual aplique para Upselling, se


mostrará primero la información del Upselling y en la parte inferior la
información del cupón.

2. No BAE: Cupón de descuento porcentual por reserva


 En la parte superior de cada listado de trenes se deberá mostrar un
mensaje indicando “DESCUENTO APLICARÁ AL TOTAL DE LA
COMPRA”.
 En el listado de trenes, se mostrará la siguiente información:
o Icono con el título de la promoción.
 Este título se registrará y configurará en el sistema CMS.
o Icono del tren
o Tren
o Icono informativo que mostrará en un modal el detalle del tren.
o Estación
o Hora de salida
o Hora de Llegada
o Tarifa regular por persona en dólares y soles (tachada).
o Tarifa promocional por persona en dólares y soles (nuevo).

30
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

3. No BAE: Cupón de descuento con monto fijo por persona


 En la parte superior de cada listado de trenes se deberá mostrar un
mensaje indicando “DESCUENTO APLICARÁ AL TOTAL DE LA
COMPRA”.
 En el listado de trenes, se mostrará la siguiente información:
o Icono con el título de la promoción.
 Este título se registrará y configurará en el sistema CMS.
o Icono del tren
o Tren
o Icono informativo que mostrará en un modal el detalle del tren.
o Estación
o Hora de salida
o Hora de Llegada
o Tarifa regular por persona en dólares y soles (tachada).
o Tarifa promocional por persona en dólares y soles (nuevo).

31
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

4. No BAE: Cupón de descuento con monto fijo por persona


 En la parte superior de cada listado de trenes se deberá mostrar un
mensaje indicando “DESCUENTO APLICARÁ AL TOTAL DE LA
COMPRA”.
 En el listado de trenes, se mostrará la siguiente información:
o Icono con el título de la promoción.
 Este título se registrará y configurará en el sistema CMS.
o Icono del tren
o Tren
o Icono informativo que mostrará en un modal el detalle del tren.
o Estación
o Hora de salida
o Hora de Llegada
o Tarifa regular por persona en dólares y soles (tachada).
o Tarifa promocional por persona (mensaje informativo).

Para todas las casuísticas revisadas previamente, el sistema mostrará un


link en la parte inferior de la pantalla para visualizar los términos y
condiciones del cupón

32
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

- 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

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

upselling de un tren anterior.


o Se tomará de referencia el código de Google Analytics creado para
Upselling V&R.
o El servicio upselling no se considerará para servicios BAE.

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

o Viaje Bimodal: Listado de Trenes, descuentos.

34
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

o Upselling

35
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

o Eventos

36
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

Detalles Técnicos 1.- Las fechas de disponibilidad de viaje corresponden a la configuración


realizada en TS.
2.- Las tarifas, horarios, trenes son configuradas en TS, el ecommerce solo
muestra la información de TS.
2.- Los parámetros usados en el caso de uso son.
o idiomas
o listado de trenes
o upselling
3.- Las opciones de CMS utilizadas en el caso de uso son
o Pasos
o Eventos
o Upselling
o Términos y Condiciones
o Promoción Cupón.
4.- Los métodos consumidos de MID son:
o GetDetalleParametro
o getListarTrenesNoBAE

Listar Cabinas

37
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

Código CU-003 (Código de Caso de USO)


Nombre Listar Cabinas
Descripción Dirigido a viajes BAE. El objetivo es que el pasajero pueda seleccionar el las
cabinas en las que desea viajar, ver su detalle y distribuir los pasajeros por
cada una.
Usuarios Pasajero
Requerimientos REQ 21, REQ 22, REQ 23, REQ 24, REQ 25
Asociados
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.

El motor de búsqueda mostrado en la parte superior de la pantalla


tiene las mismas funcionalidades descritas en el motor de
búsqueda del CUS 01.

2 El sistema mostrará al usuario una sección con la información del


itinerario del viaje. La información que se muestra en el itinerario
es:
o Descripción del viaje
o Duración del viaje
o Fecha del viaje
o Estación de salida
o Estación de llegada
o Ruta a realizar incluyendo la duración (días / noches)
o Descripción de la ruta
o Itinerario detallado por día y horas.

3 El sistema mostrará al pasajero las cabinas disponibles por cada


tipo de cabina. La información a mostrar es:
o Imágenes de las cabinas
o Nombre de la cabina
o Detalle del contenido de la cabina

38
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

o Cabinas disponibles

4 El pasajero deberá seleccionar las cabinas que utilizará y distribuir


los pasajeros por cada cabina.
o La cantidad máxima de pasajeros por cabina es dos.
o La cantidad máxima de pasajeros por compra es nueve.
o Un niño solo no puede realizar un viaje.
o Un niño no pude viajar sin un adulto en una cabina.
5 Por cada tipo de cabina, el sistema mostrará:
 Monto del subtotal del costo de la cabina en dólares.

7 El sistema mostrará en la parte inferior de las cabinas lo siguiente:


o Total de Cabinas
o Total de Pasajeros
o Monto del costo total del viaje en dólares.

8 El sistema mostrará los términos y condiciones de la reserva.


9 El pasajero dará click en siguiente para continuar con el proceso.
Flujo Alterno 1. BAE: Cupón de descuento porcentual por cabina

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

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

3. Montos de cabinas
El monto subtotal se mostrará tachado, se mostrará el monto del
descuento y el nuevo subtotal.

40
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

4. Monto total
El monto total presenta 3 valores: antes del descuento (tachado), monto
monetario del descuento (independiente del tipo de descuento %, monto
fijo).

2. BAE: Cupón de descuento porcentual por reserva


 Al aplicar el descuento, en el listado de cabina deberá mostrarse el
siguiente detalle:
o Subtotal en dólares por cabina
o Monto a pagar por cabina (en dólares considerando el descuento)

3. BAE: Cupón de descuento con monto fijo por cabina


 Al aplicar el descuento, en el listado de cabina deberá mostrarse el
siguiente detalle:
o Subtotal en dólares por cabina
o Descuento en dólares
o Monto a pagar por cabina (en dólares considerando el descuento)

41
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

4. BAE: Cupón de descuento con monto fijo por reserva


 Al aplicar el descuento, en el listado de cabina deberá mostrarse el
siguiente detalle:
o Subtotal en dólares por cabina

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

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

 Tipos de cabina , disponibilidad y distribución de pasajeros

1.- Las fechas de disponibilidad de viaje corresponden a la configuración


Detalles Técnicos realizada en TS.
2.- Las tarifas, horarios, cabinas son configuradas en TS, el ecommerce solo
muestra la información de TS.
3.- Los parámetros usados en el caso de uso son.

43
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

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

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

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

o Al marcar el check “¿Infante viaja contigo?”, en la parte inferior de este


grupo se mostrará el formulario correspondiente al registro de la
información del infante.

2. Registro de pasajero Infantes sin asiento


 Para el registro de infantes se mostrará la siguiente información:
o Nombres infante
o Apellidos infante
o Género infante
o Nacionalidad infante
o Tipo documento infante
o Número documento infante
o Fecha nacimiento infante

45
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

 En la versión móvil, el campo


Teléfono, el teclado a mostrar
será el numérico:

3. Registro de pasajero Niño e Infante con asiento


 La información que se registra para estos tipos de pasajeros es la
siguiente:
o Nombres
o Apellidos
o Género
o Nacionalidad
o Tipo Documento
o Número de documento
o Fecha de nacimiento

46
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

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

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

o No permitirá que se repita el mismo carácter 3 veces seguidas.


 DNI:
o Permitirá de 5 a 16 caracteres alfanuméricos.
7. Sexo:
 Campo obligatorio.
 Campo de tipo selección.
8. Correo electrónico:
 Campo obligatorio.
 Tiene un tamaño máximo de 80 caracteres.
 Se validará el formato de un correo electrónico: ‘[email protected]
9. Correo electrónico confirmación:
 Campo obligatorio.
 Tiene un tamaño máximo de 80 caracteres.
 Se validará el formato válido de un correo electrónico:
[email protected]
 Deberá ser el mismo valor que el correo electrónico.
10. Teléfono:
 Campo obligatorio.
 Tiene un tamaño máximo de 26 caracteres.
 Permitirá solo caracteres numéricos.
 Se validará el formato de un número telefónico: ‘963852741’.
11. Información Tributaria:
 Ruc:
o Tiene un tamaño máximo de 11 caracteres.
o Permitirá solo caracteres alfanuméricos.
 Razón Social:
o Tiene un tamaño máximo de 80 caracteres.
o Permitirá solo caracteres alfanuméricos, caracteres especiales,
espacios en blanco.
 Dirección:
o Tiene un tamaño máximo de 200 caracteres.
o Al digitar, deberá mostrarse el texto en mayúscula.
o Permitirá solo caracteres alfanuméricos, caracteres especiales,
espacios en blanco.

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

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

 Viajes BAE
o Registro de Pasajeros

 Viajes No BAE
o Registro de Pasajeros

o Asociando pasajeros infantes sin asiento

49
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

Detalles Técnicos 1.- Los parámetros usados en el caso de uso son.


o rango_edad
o paises
o tipo_documento
o nacionalidad
o conf_banderas
o tipo_documento_pj

2.- Los métodos consumidos de MID son:


o insReservaBAE

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

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

o Tren en el que viajaran


o Fecha de salida del viaje
o Importe del viaje

 Viajes No BAE Regular:


o Pasajero
o Ruta
o Tren
o Salida (fecha)
o Hora (hora)
o Importe
o Asiento / Nro. Fila

 Viajes No BAE Bimodal:


o Pasajero
o Ruta
o Tren
o Salida (fecha)
o Hora (hora)
o Importe
o Asiento / Nro. Fila

51
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

Esta información se mostrará agrupada por Viaje y listada por cada


uno de los pasajeros.

2 El sistema mostrará en un segundo grupo los medios por los cuales


el pasajero podrá realizar su pago en línea, el sistema contempla
como alcance los pagos con :
 Visa
 Mastercard
 Paypal
 Safetypay Bancos Nacionales
 Safetypay Bancos Internaciones.

3 El usuario deberá seleccionar la forma de pago con la que desea


comprar sus pasajes.
4 El usuario deberá aceptar los términos y condiciones establecidas
para el pago y dar click en continuar.
5 En base al tipo de pago seleccionado, el usuario deberá ingresar la
información que se le solicite.
6 Para finalizar el pago, el usuario debe dar click en Pagar y
continuar con el proceso.
7 Pago Exitoso:
 Cuando el usuario ingresa correctamente la información de
su tarjeta y esta no presenta ninguna observación, se
considera un pago exitoso.
 El sistema confirma la reserva.
 El sistema emite el correo electrónico al pasajero asignado
como ‘Comprador’ enviándole la confirmación de la reserva
y los tickets o boletos adjuntos en el correo.
 El sistema le da la opción para descargar los tickets.

Flujo Alterno Pago Observado


 Cuando el usuario ingresa correctamente la información de su tarjeta
y esta presenta algún tipo de observación, se considera un observado.

52
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

 El sistema muestra la confirmación del pago y por ende la


confirmación de la reserva.
 El sistema emite el correo electrónico al pasajero asignado como
‘Comprador’ enviándole la confirmación de la reserva, pero a
diferencia del pago exitoso, los tickets o boletos no son adjuntos en el
correo, se le indica al pasajero que deberá recoger los tickets
personalmente en la agencia.
 El sistema no le dará la opción a descargar los boletos desde la web.
Por regla de negocio, se considera pago observado cuando:
1. El servicio es un Hiram Bingham y la fecha de compra es menor o
igual a 15 días de la fecha de viaje.
2. El servicio es Perurail Titicaca (antes Andean Explorer) y la fecha de
compra es menor o igual a los 30 días de la fecha de viaje.
3. El servicio es Vistadome y la fecha de compra es menor o igual a los
30 días de la fecha de viaje.
4. El servicio es Expedition y la fecha de compra es menor o igual a los
30 días de la fecha de viaje.
5. El servicio es Belmond Sacred Valley y la fecha de compra es menor
o igual a los 15 días de la fecha de viaje.
6. Considerar que para los pagos con Paypal, no existen restricciones
esto sin importar el servicio.
7. Considerar que para viajes en Belmond Andean Explorer, no existen
restricciones.

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

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

o Ejemplo de Pago con Visa

54
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

o Resultado del pago exitoso

Detalles Técnicos 1.- Los parámetros usados en el caso de uso son.


o PaisesSafetyPayExt
o PaisesSafetyPayInt
o Validacion_de_Fraude
2.- Los métodos consumidos de MID son:
o insTransaccion
o GuardaryEnviarCorreo/GuardarCorreo

Enviar email
Código CU-006 (Código de Caso de USO)
Nombre Enviar email

55
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

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

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

encuentre observada, no deberá adjuntar los ticket.


Prototipo
 Correo de compra exitosa (documento pdf con los boletos)

 Correo de compra no completada Perurail:

 Documento pdf con los boletos adjuntos (la imagen es referencial)

57
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

1.- Los parámetros usados en el caso de uso son.


Detalles Técnicos o dias_reenvio
2.- Las opciones utilizadas del CMS son
o Mailing Plantilla
o Mailing Parámetro
o Mailing Buscador
3.-Los métodos consumidos de MID son:
o insTransaccion
o GuardaryEnviarCorreo/GuardarCorreo

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

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

2 Búsqueda por nombre:


 En este tipo de búsqueda los filtros obligatorios son:
o Apellido
o Nombre
o Tipo de documento
o Número de documento
o Nacionalidad

3 Búsqueda por reserva:


 En este tipo de búsqueda los filtros obligatorios son:
o Número de reserva

4 Búsqueda por ticket:


 En este tipo de búsqueda los filtros obligatorios son:
o Tipo de documento
(Boleta o Factura)
o Serie
o Número

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

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

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

Detalles Técnicos 1.- Los parámetros usados en el caso de uso son.


o cant_dias_impresion
o paises_impresion
2.-Los métodos consumidos de MID son:
o getbookinglist
o getbookinginfo
o getdocumentinformation
o printdocument

60
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

Buscar Trenes

61
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

Código CU-008 (Código de Caso de USO)


Nombre Búsqueda de tren en wordpress
Descripción El objetivo es darle al pasajero las herramientas para encontrar para realizar la
búsqueda de tren en el wordpress. El motor de búsqueda creado debe ser un
widget de modo que pueda utilizarse en cualquier versión de Home.

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:

Se muestran los siguientes campos en el motor de búsqueda

o Tipo de viaje solo de ida.


o No se muestra la cantidad de pasajeros (adultos, niños,
infantes)
o Los viajes se realizan una vez por semana (configurable en el
CMS).
o Puno – Cusco : miércoles
o Cusco-Puno : martes
o Arequipa – Cusco : sábado
o Cusco – Arequipa : jueves
o Para las rutas compartidas Puno – Cusco y viceversa se habilita
un campo el tipo de tren en el cual podrá seleccionar entre el
tren Titicaca Train y Belmond Andean Explorer.

62
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

o Al seleccionar el tipo de tren Belmond Andean Explorer se


habilita un pop up.

3 Las fechas de viajes pueden ser deshabilitados basados en la


información registrada en el CMS en la opción Bloqueo de Fechas, al
pasar el cursor por la fecha bloqueada se podrá visualizar el motivo del
bloqueo.
4 Se puede modificar el idioma en la parte superior del WordPress y se
actualizarán las etiquetas
Viaje NO BAE - Viajes NO BAE:
o Los tipos viajes de ida y retorno se encuentran habilitados.
o Selecciona el origen y destino de la ruta del tren.
o La fecha de viaje de salida y retorno según haya seleccionado
o o el tipo de viaje.
5 o El comprador deberá ingresar la cantidad de pasajeros
o o (adulto, niño) que realizarán el viaje.

6 Las fechas de viajes pueden ser deshabilitados basados en la


información registrada en el CMS en la opción Bloqueo de Fechas, al
pasar el cursor por la fecha bloqueada se podrá visualizar el motivo del
bloqueo.
7 Para las rutas compartidas Puno – Cusco y viceversa se habilita un
campo el tipo de tren en el cual podrá seleccionar entre el tren Titicaca
Train y Belmond Andean Explorer.

Al seleccionar el tipo de tren PeruRail TiticacaTrain se habilita un pop up


8 Se puede modificar el idioma en la parte superior del WordPress y se
actualizarán las etiquetas

Flujo Alterno  Bimodal:


o Cuando se seleccione una ruta y fecha Bimodal (configurada en el CMS),
automáticamente se mostrará un pop up con la descripción de la misma.
o La descripción a mostrar estará configurado en el CMS en la opción
Temporada Bimodal.

 Rutas No BAE (Perurail Titicaca Train):


o Se reservan viajes solo de ida.
o Los calendarios fueron todas las fecha activas a partir de la fecha en la que
se ingresa el sistema hacia adelante excepto para el tren Titicaca Train.
Cusco-Puno: domingo, miércoles, viernes.
Puno-Cusco: lunes, jueves, sábado.
o Deberá indicar la cantidad de pasajeros que viajan.
 Al seleccionar una ruta compartida, se mostrará el campo Tren con la
finalidad que el usuario seleccione el tren en el que desea viajar, sus
opciones son Belmond Andean Explorer o Perurail Titicaca Train.
 Convivencia

63
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

o En el CMS se configura una fecha de convivencia


Rango de fecha de viaje < fecha de convivencia, se direcciona al ecommerce
de V&R
Rango de fecha de viaje >= fecha de convivencia, se direcciona al
ecommerce de TS
En caso la fecha de convivencia se encuentre en el rango de viaje no se
permitirá la compra.

Post-Condición Se direcciona al paso 2 del Ecommerce.


Criterios de - Fechas de búsqueda:
Aceptación  Rutas BAE:
o Se reservan viajes solo de ida por lo cual se deberá ocultar el campo
fecha de retorno.
o Los viajes se realizan una vez a la semana, por lo cual se deben tener
habilitados solo un día a la semana en el calendario.
o Se deberá ocultar el campo fecha de retorno.
 Rutas No BAE:
o Por defecto estarán habilitados todos los días de la semana.
o Se deshabilitaran las fechas configuradas en el CMS en la opción
bloqueo de fechas, mostrando el mensaje configurado con la
descripción del bloqueo.
o Se pueden configurar viajes de ida y vuelta.

 Rutas No BAE (Perurail Titicaca Train):


o Se podrán reservar viajes solo de ida, por lo cual se oculta el campo
fecha de regreso y el check ida y retorno.
o Los viajes se realizan tres veces a la semana, por lo cual se deben
tener habilitados solo tres días a la semana en el campo ida.
 Todos:
o Se deshabilitan las fechas previas a la fecha actual.
o La fecha de retorno no puede ser menor a la fecha de ida.
o Si al seleccionar la fecha de ida, la fecha de retorno no tiene un valor
asignado o tiene un valor menor a la fecha de ida, se le debe asignar la
fecha de ida seleccionada.
o Si al seleccionar la fecha de ida, la fecha de retorno tiene un valor
mayor asignado, este mantiene su selección.
o Cuando se seleccione viajes solo de ida, se debe deshabilitar el campo
de fecha de retorno.
o La fecha de retorno deberá bloquear las fechas menores a la fecha de
ida.
o Al cargar la página, por defecto las fechas de ida y retorno deberán
tener el valor de la fecha actual.
o Cada vez que se cambie la ruta, se deben de limpiar los campos de
fecha de ida y de retorno.

- 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

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

pasajeros.

Prototipo
- Búsqueda en el Home

Modal viaje BAE

- Búsqueda No BAE:

Pop up bimodal

65
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

Detalles Técnicos 1.- Las fechas de disponibilidad de viaje corresponden a la configuración


realizada en TS.
2.- Los parámetros usados en el caso de uso son.
o idiomas
o max_compra
o rutas
o origen
o destino
o equivalencias_ts
o fechaTS (para convivencia)

3.- Las opciones de CMS utilizadas en el caso de uso son


o Bloqueo de fechas
o Temporada Bimodal
o

Estilos Belmond

Código CU-009 (Código de Caso de USO)


Nombre Estilos Belmond
Descripción El objetivo es adaptar el sistema ECommerce a los estilos de la web Belmond,
siempre y cuando sea invocado desde esta.

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

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

2 Luego de realizar la búsqueda, los estilos del sistema ECommerce se


adaptarán a la web Belmond.

Paso 1: Se omitirá el paso 1 actual del ECommerce ya que los filtros se


tomarán de la web Belmond.

3 Paso 2: Listado de Trenes


o Mensaje Informativo

67
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

o Listado de Trenes

4 Paso 3: Registro de Pasajeros

68
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

5 Paso 4: Pago

6 Paso 5: Confirmación de compra

69
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

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

Se detallan las pantallas en los pasos anteriores.

Detalles Técnico 1. Se deberá enviar los parámetros establecidos:


Parámetro
Criterios de URL Origen del dato
Estación de salida 1. Tomar los valores del diccionario de equivalencia. Origen
TS 2. Este valor no puede enviarse vacío.
Estación de llegada 1. Tomar los valores del diccionario de equivalencia. Destino
TS 2. En caso este valor se envíe vacío, el sistema interpretará que se
trata de un viaje One Way.

70
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

Idioma N° Valor a enviar Idioma Idioma


1 es-PE Español
2 en-US Inglés
Adultos Web de Belmond Adultos
1. No se deberá enviar un valor mayor a 9.
2. La suma de los adultos más niños no debe superar a los 9
pasajeros.

Niños 1. No se deberá enviar un valor mayor a 9. Ninos


2. La suma de los adultos más niños no debe superar a los 9
pasajeros.
Fecha de salida 1. El valor de este dato no deberá ser menor a la fecha de actual. FSalida
2. El formato de fecha a enviar será DDMMYYYY, por ejemplo
“05062020”.
3. En caso la fecha enviada se encuentra dentro de las fechas
bloqueadas en el CMS, el ECommerce se quedará en el paso 1
del flujo y no seleccionará ninguna fecha.
Fecha de retorno 1. El valor de este dato no deberá ser menor a la fecha de salida. FLlegada
2. El formato de fecha a enviar será DDMMYYYY, por ejemplo (FRetorno)
“05062020”.
3. En caso la fecha enviada se encuentra dentro de las fechas
bloqueadas en el CMS, el ECommerce se quedará en el paso 1
del flujo y no seleccionará ninguna fecha.
Web Origen Se deberá enviar el valor “BM” que hace referencia a la web WebOrige
Belmond. n
Familia N Valor a Familia Fam
° enviar
1 EX Expedition
2 HB Hiram Bingham
3 SV Sacred Valley
4 AS Titicaca Train
5 AV Vistadome

2. En caso no se envíe la información según lo especificado, el sistema


ECommerce se mantendrá en el Paso 1 de su proceso.

11. Lista de Escenarios Potenciales de vulnerabilidad (Casos


de Abuso Potenciales).
11.1. Injección
Una inyección de código ocurre cuando un usuario externo ( atacante) envía datos
inválidos al Ecommerce con la intención de hacerla hacer algo distinto para lo que
fue diseñada.

11.2. Ingeniería social:


Utilizan técnicas de persuasión que aprovechan la buena voluntad y falta de
precaución de la víctima para obtener información sensible o confidencial. Los

71
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

datos así obtenidos son utilizados posteriormente para realizar otro tipo de
ataques, o para su venta.

11.3. Autenticación rota


Cuando las claves o información sensible no es protegida adecuadamente, el
atacante aprovecha estas vulnerabilidades que generalmente son ofrecidas en el
cierre de sesión, en la gestión de las contraseñas, en el tiempo de desconexión, en
la función de recordar contraseña, para robar la información sensible

11.4. Uso de componentes o frameworks


Hace referencia a las vulnerabilidades propias de un framework o por el uso de
herramientas como el Word Press para el caso del Ecommerce.

11.5.

72
Functional Specification Document

Nombre del Requerimiento Código Fecha versión


ECommerce 01/03/2019 1

12. Aprobaciones de Usuarios


Gerencia / Área Rol Versión Fecha Aprobado Adjunto
Aprobada Aprobación Por

<<Gerencia de <<dd/mm/aa.> <<Nombre <<Archivo


<<Líder usuario,
Aprobador>>/<<Áre <<Versión > Usuario adjunto en
Dueño del Proceso,
a de Aprobador>> Aprobada> Aprobador>> formato
Usuario Consultado,
> PDF(correo
<<Usuario de Apoyo>>
con Vo.Bo.)>>

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

También podría gustarte