SRS Document - Passenger Movements Module

Business Systems Project
Passenger Movements Requirements Pack
{A COMPANY} Document No. 1
Document Control
Owner
Status
Version No. Description of Change Date Author
0.1 Original Draft
1.0 Signed Version

1. Sign-off sheet
Version Business Transaction Name
1.0 Passenger Movements
Authorised By:
Name Signature Date
31/03/22 Version 1.0 www.BusinessAnalystSolutions.com Page: 2 of 40

2. Contents
1. Sign-off sheet...............................................................................................................................................2
Passenger Movements.........................................................................................................................................2
2. Contents.......................................................................................................................................................3
3. Overview......................................................................................................................................................4
3.1 SCOPE......................................................................................................................................................4
3.2 INTERACTIONS WITH OTHER DEPARTMENTS & ORGANISATIONS............................................................4
3.3 PRINCIPLES..............................................................................................................................................5
3.4 FEATURES................................................................................................................................................5
3.5 MAIN PROCESSES SUPPORTED................................................................................................................5
4. Business Transactions................................................................................................................................8
4.1 REQUEST TRANSPORTATION...................................................................................................................8
4.2 MAINTAIN TRANSPORT PLAN...............................................................................................................10
4.3 PASSENGERS OR CARGO CHECKS IN....................................................................................................12
4.4 VEHICLE READY TO LEAVE..................................................................................................................14
4.5 VEHICLE ARRIVES.................................................................................................................................16
4.6 TRANSPORT PLAN COMPLETED.............................................................................................................18
4.7 PRODUCE REPORTS...............................................................................................................................20
4.8 INCIDENT RESPONSE SUPPORT..............................................................................................................22
5. Information Model...................................................................................................................................24
6. Entity Descriptions...................................................................................................................................25
7. Activity Descriptions................................................................................................................................30
7.1 REQUEST TRANSPORTATION / RECORD TRANSPORTATION REQUIREMENTS........................................30
7.2 PREPARE TRANSPORT PLAN / MAINTAIN TRANSPORT PLAN................................................................31
7.3 PASSENGERS OR CARGO CHECKS IN / CHECK IN MANIFEST ITEM......................................................33
7.4 VEHICLE READY TO LEAVE / BUILD MANIFEST....................................................................................34
7.5 VEHICLE ARRIVES / DISEMBARK PASSENGERS AND UNLOAD CARGO.................................................35
7.6 TRANSPORT PLAN COMPLETED / TRANSPORT COMPLETED..................................................................36
7.7 PRODUCE REPORTS / PRODUCE REPORTS.............................................................................................37
7.8 INCIDENT RESPONSE SUPPORT / MAINTAIN INCIDENT INFORMATION..................................................38
7.9 INCIDENT RESPONSE SUPPORT / FIND PERSONNEL RECORD................................................................39
7.10 INCIDENT RESPONSE SUPPORT / RECORD CALLS................................................................................40

3. Overview
3.1 Scope
The Passenger Movements module manages the following for Vehicle transports between {a place} and the
offshore platforms for {A COMPANY}:
1. Request for transportation
2. Building a transport plan
3. Checking In Passengers & Cargo
4. Disembarking Passengers & Cargo
5. Amending a transport plan
6. Closing a transport plan
7. Producing the People on Board report on demand
8. Maintain Passengers allocations to seats, lifeboats, beds, constituencies and special duties
9. Incident communications
3.2 Interactions with other departments & organisations

3.3 Principles
Business unit wide underlying reasons for the processes and information requirements. In general, they are
the reason why the processes and information requirements are as they are.
No Principle
1 This will be a stand alone solution in order to minimise the risk of failure.
2 Minimising risk of failure is required because it is essential that the People On Board report can be
produced at any time and it is up to date. The People On Board report is required for HSE reasons in the
event of an incident.
3 Every effort is made to maximise the use of Vehicle transports for cost efficiency purposes.
4 Transport plans change dynamically during the course of a day in order to be able to react to changing
circumstances.
5 Although the vast majority of passenger movements are by helicopter there are also a few by boat. The
system should be able to cope with either.
6 The system is geared around providing People On Board (POB) information for offshore installations. It
is not geared around onshore sites and cannot be used to provide POBs for these locations. This is also
true for Paris – an incident response unit that would be used to co-ordinate communications with
relatives etc in the event of an incident.
7 System must be able to demonstrate compliance with SI1019 legislation and safety case.
8 System must be able to demonstrate compliance with CAA regulations.
3.4 Features
Business unit wide features the candidate solution could possess. N.B: A feature scored at 10 is a ‘must-
have’: if the proposed solution fails to satisfy them then the solution would be rejected. Any other scores
are ‘nice-to-have’ ranging from 9 (very, very nice to have, almost but not quite essential) to 1 (this would
be the icing on the cake).
No Score Description
1. 10 The ability to define reports to be run regularly to a schedule under control of users which
reports using any information on the database that the Job Role is allowed to view.
2. 8 The ability to be able to view and update PARIS data on screen during an incident.
3. 10 The ability to define ad-hoc reports using any information on the database that the Job Role is
allowed to view.
3.5 Main Processes Supported

1. Preparing a transport plan
2. Processing a journey
3. Handling an incident

3.6 Essential Reports
People On Board (POB):

Alphabetic listing of POB by Name
No Field Comments
1. Date/time
2. Location
3. Company Name, address and contact number
4. Name/id Full fore, middle and surnames
5. Job Title
6. Company and site totals
People On Board (POB):

Alphabetic listing of POB by Company and then by Name
No Field Comments
1. Date/time
2. Location
3. Company Name, address and contact number
5. Job Title
6. Company and site totals
Paris:
Report produced for all personnel whose last known location was offshore
No Field Comments
1. Date/time
3. Person’s address and phone no
4. Date of birth
5. Marital status
6. Nationality
7. Passport no
8. Sex
9. Job title
10. Person certification details Medical certificates, Survival type courses etc
11. Contact address and phone no
12. Person’s employer contact details Name, address, phone
13. Person’s doctor contact details Name, address, phone
Manifest:
No Field Comments
1. Date/time
2. Manifest no Transport Plan Stage on the information model
3. Journey no

4. Journey plan A list of locations to be visited

5. Stage Start location
6. Stage Destination location
7. Vehicle Type
8. Vehicle identifier In the case of a helicopter it’s call sign
9. Person Id, name, initials
10. Person weight
11. Baggage weight
12. No of cargo packages
13. Weight of cargo
14. Total weight
Manifest Summary:
No Field Comments
1. Date/time
2. Manifest no Transport Plan Stage on the information model
3. Journey no
4. Journey plan A list of locations to be visited
5. Stage Start location
6. Stage Destination location
7. Vehicle Type
8. Vehicle identifier In the case of a helicopter it’s call sign
9. Person Id, name, initials
10. Person weight
11. Person’s Baggage weight
12. Person’s destination
13. Person weight + baggage weight
14. No of cargo packages
15. Weight of cargo
16. Total body weight
17. Total baggage weight
18. Total payload weight
19. Vehicle payload capacity Vehicle theoretical payload minus fuel requirement weight
20. Over/under load weight Vehicle payload capacity minus calculation of total payload
weight
Boarding Card:
No Field Comments
1. Standard Text A series of standard texts such as Safety Notices and Forbidden
Articles.
2. Person id
3. Person (full) Name
4. Job Role
5. Medical Certificate Expiry Date
6. Survival Certificate Expiry Date
7. Company
8. Flight Details Id, Date, From and To Location

4. Business Transactions
4.1 Request Transportation
Purpose: To allow requests for transportation to be stored until

included in a Transport Plan.
Frequency: 50 times per day.
Expected Growth: In line with business growth.
Timing: Best endeavours.
Key Benefits: 1) Users specify initial request for transport requirements

reducing work load on Transport Managers.
2) Users now able to book more than 1 set of journeys

within the same time period.
3) Passengers will not have to be checked in twice when

making more than 1 journey in the same transport run.


4.2 Maintain Transport Plan
Purpose: To determine the destinations to be visited on a particular

day and the initial manifest content.
Key Benefits:


4.3 Passengers Or Cargo Checks In
Purpose: Record arrival of passengers and cargo for inclusion on a

flight plan.
Key Benefits: 1) System will prompt users to request review and update
of personal details
2) System will prompt users to remind personnel of

impending expiry of medical certificates


4.4 Vehicle Ready to Leave
Purpose: Provide transport crew with departure manifest.
Key Benefits:


4.5 Vehicle Arrives
Purpose: Record arrival of passengers and cargo at a destination.
Key Benefits:


4.6 Transport Plan Completed
Purpose: Complete a transport plan.
Frequency: 5 per day.
Key Benefits:


4.7 Produce Reports
Purpose: Produce pre-defined reports on demand instantly.
Timing: 2 minutes max to make information available for viewing

and printing.
Key Benefits: 1) The system will automatically print a revised POB report
after logging a Manifest Item Event of persons arriving or
departing from an offshore location.
2) System shall have the ability to auto fax / e-mail POB

reports or excerpts from them to contractors and the police.
3) POB reports will now meet legislatory requirements.


4.8 Incident Response Support
Purpose: Provide and record information on personnel for relative’s support

during an incident offshore.
Frequency: 5 times per annum, usually for incident response exercises.
Key Benefits: 1) PARIS team can read information and log calls on to the screen.
2) Audit trail for review of incident management now more secure

as more actions recorded on the system.


5. Information Model

6. Entity Descriptions
Note: C|U|D columns are Create, Update & Delete. They should be marked Y or blank to indicate if this Business Area requires functionality to maintain these entities.
All CUD functionality is to be restricted by Job Role within the Business Area.
Entity name Description Example Information Vols C U D Comments
Source
Address An identifier for a 1 Sunnyside Meadows Transport 12,500 Y Y Vols based on Persons.
geographical location – this Wetherfield Supervisor
will usually be a postal
address.
Allocation A record of Offshore items Bed 101, Constituency 10, Transport 5,000 Y
that can be assigned to Lifeboat 19, First Aider Supervisor
Persons (q.v.) while at the
Offshore location.
Allocation Type A list of the items that can Bed, constituency, lifeboat, Transport 25 Y
be allocated to people on special duties, muster point Supervisor
board offshore facilities.
Cargo A type of Manifest Parcel 1234 Transport 1,250 Y Vols based on 10% of Persons
Item(q.v.). Goods of some Supervisor
sort to be transported.
Certification The types of certificates that First aider, survival, Transport 25 Y
Type people or Companies (q.v.) offshore insurance Supervisor
hold that are relevant to their
offshore role.
Communication A record of who has been Paris Team Member Smith Paris Team 5,000 C
History talking to who in connection took call from Helen
with an Incident (q.v.) and Rigby-Jones (fiancé) re B.
what has been said. Eastham. Told her he is
safe and well.
Company An organisation that a {A COMPANY}, {another Transport 25 Y Y
Person (q.v.) is employed by company} Supervisor
or has been certified by.
Company A Company (q.v.) may have {another company} – Transport 25 Y Y
Certification an offshore role that requires Offshore Insurance Supervisor
Type certification. This is a list of
the Certification Types (q.v.)
held by a Company (q.v.).


Source
Contact A communication point for Liz Hurley, Mr Brown Transport 12,500 Y Y Vols Based on Persons.
information regarding a Supervisor
Person (q.v.) to be contacted
in the event of an incident.
Contact Type The role that a Contact (q.v.) Girlfriend, Company rep Transport 25 Y
has in relation to a Person Supervisor
(q.v.)
Crew Member An individual who is a J.T.Kirk Transport 500 Y Y
Vehicle crew member Supervisor
Crew Member The types of roles that are Captain, Pilot Transport 10 Y
Role relevant to Transport Plan Supervisor
Crews (q.v.)
Dept Sub-division of a Company Maintenance, Production Transport 25 Y
(q.v.) that is responsible for Supervisor
the Person (q.v.)
Frequency The cycle of time which Fortnightly, monthly, daily Transport 25 Y
Person Transportation Supervisor
Requests are to be
implemented
Incident An accident that threatens Incident 1 – ship collides Paris Team 10 Y
life and property and with DP6.
declared to be an Incident by
the Duty Manager
Incident Information about incidents A support vessel collided Paris Team 1,000 C
Information that needs to be with DP6 on 2/11/00 at
History communicated to the 16:35 GMT. No known
Incident Response Team and casualties – not everyone
possibly the public. accounted for yet.
Job Title Position within a Dept (q.v.) Engineer, Electrician Transport 250 Y
that can be held by a Person Supervisor
(q.v.)
Location A geographical location that {a place}, CPP. Transport 250 Y
features in a Transport Plan Supervisor
(q.v.)


Source
Location A record of which Locations DP6 – Incident 1 Paris Team 100 Y
Incident (q.v.) have been affected by
which Incidents(q.v.)
Manifest Item An item that can be Passenger B. Eastham Transport 13,750 Y Vols based on Persons plus Cargo.
manifested to be on a Cargo: Envelope from Supervisor
Transport Plan Stage (q.v.) Heysham to CPP for
Transport Supervisor
Manifest Item The Manifest Item Event Passenger B Eastham Transport 30,000 Y Vols based on Persons plus cargo
Event Types (q.v.) that befall a boarded at {a place} on Supervisor multiplied by 2
Manifest Item (q.v.) 26/10/00 07:30 Must be able to record who created
entries for audit purposes especially
for recording when a Person has
seen a safety video.
Manifest Item The types of events that can Arrived, boarded, Transport 25 Y
Event Type befall a Manifest Item (q.v.) disembarked. Supervisor
in the course of being
moved.
Manifest Item The Special Instructions Hazardous – radioactive Transport 1,000 C U
Special (q.v.) that apply to a material in Smoke Supervisor
Instructions Manifested Item (q.v.). detectors.
Manifest Item A record of which Manifest Passenger B. Eastham on Transport 13,750 Y Y Full audit trail of updates required.
Transport Plan Items (q.v.) are on which Transport Plan 12345 Supervisor Vols based on Persons plus Cargo.
Stage Transport Plan Stages (q.v.). Stage 1
Manifest Item A request for transportation B.Eastham From {a place} Transport 12,500 Y
Transport between two Locations to CPP Supervisor
Requirement (q.v.) of a Manifest Item 6” valve from AP1 to DP6
(q.v.)
Manifest Item Every time a Manifest 110kg Transport 13,750 Y
Weight History Item(q.v.) is transported it Supervisor
should be weighed. This
holds the result of the
weighing.
Nationality The country that issues a U.K., U.S.A. Transport 250 Y
Person’s (q.v.) passport. Supervisor


Source
Person A type of Manifest Item B. Eastham. Transport 12,500 Y Vol Per year.
(q.v.). A person to be Supervisor Based on around 500 people on
transported. board at any one time all requiring
a complete changeover once every
two weeks.
Person The Allocations (q.v.) that B.Eastham Bed 101 Transport 30,000 Y Vol assumes each Person has 2 or
Allocation have been assigned to a Supervisor so allocations.
Person (q.v.)
Person The Certification Types B.Eastham Survival Transport 12,500 Y
Certification (q.v.) held by a Person (q.v.) Certificate Supervisor
Person Status The Person Status Types B. Eastham – unharmed Paris Team 1,000 Y
History (q.v.) that actually are
assigned to a Person (q.v.) in
the event of an Incident
(q.v.)
Person Status For the purposes of Unknown, unharmed, Paris Team 25 Y
Type managing communications injured, critical, dead.
in the event of an Incident
(q.v.), the states that a
Person (q.v.) can be in.
Special A list of instructions that are Hazardous, fragile, keep Transport 100 Y Y
Instructions relevant for Manifest Items upright, protect from heat Supervisor
(q.v.) being transported.
Transport Plan A plan produced for a Vehicle 12345 on 26/10/00 Transport 1,250 per Y Holds the starting location.
Vehicle (q.v.) to define its starts at {a place} Supervisor year
movements between
Locations (q.v.) for a day.
Transport Plan The crew that have been Pilot J.T.Kirk for Transport 2,500 per Y Vols based on 2 crew per transport
Crew assigned to a Transport Plan Transport Plan 1001 Supervisor year
(q.v.)
Transport Plan The components of a Vehicle 12345 on 26/10/00 Transport 5,000 per Y Y Full audit trail of updates required.
Stage Transport Plan (q.v.) in Stage 1: to CPP Supervisor year Vols based on Transport Plan
terms of scheduled multiplied by 4 stages each.
movements between
Locations (q.v.).


Source
Transport Plan The statuses that a Transport Created, closed Transport 25 Y
Stage Status Plan Stage (q.v.) can have Supervisor
which will drive control of
access to it.
Transport Plan The statuses that a Transport Vehicle 1345 on 26/10/00 Transport 10,000 per Y
Stage Status Plan Stage (q.v.) actually starts at {a place} - Supervisor year
History does have. Created
Vehicle A vehicle for the 12345 Transport 25 Y
transportation of people Supervisor
and/or goods!
Vehicle Event The Vehicle Event Types Vehicle 12345 Left {a Transport 10,000 per Y Vols based on two events per
(q.v.) that do befall a place} on 26/10/00 08:00 Supervisor year Transport Plan Stage.
Vehicle (q.v.). This will be used to record times
notified by Pilot via MSLS (Multi-
Sector Load Sheet) report.
Vehicle Event The events that can befall a Arrive, Leave, Breakdown, Transport 25 Y
Type Vehicle (q.v.) that are of Ditch. Supervisor
interest to the system.
Vehicle Type The type of Vehicle (q.v.) Helicopter, Ship Transport 25 Y
used for transportation. Supervisor

7. Activity Descriptions
7.1 Request Transportation / Record Transportation Requirements
Purpose: Store single and multiple repeat requests for transportation.
Input: Person details.

Journey details
Output: Manifest items

Manifest Item Transport Requirements
Operational Method: Details of the Manifest Item are selected (and created first if they do
not already exist).
The Location is selected and a date for travel assigned.
If required, a frequency for repeat journeys can be specified at this
point to commence with the date for travel already entered.
An end date for repeat journeys can be declared if required.
Quality: High.
Exception Handling: When a Manifest Item is first entered, it should be searched for and,
if not found, creation via entering further details should be
prompted.
If a set of journeys are requested that run in the same time period as
for another set of journeys for the same Manifest Item, the system
should warn the user that this is the case but allow creation on
confirmation.
Security/Access: Restricted by Job Role.
Auditable: Yes. Users who create Manifest Items and Manifest Item Transport
Requirements.

7.2 Prepare Transport Plan / Maintain Transport Plan
Purpose: Define a transport plan for a Vehicle.
Input: Transport Plan

Vehicle
Starting Location
Date
Crews
Manifest Items and their Manifest Item Transport Requirements
Output: Transport Plan

Transport Plan Stage
Manifest Item Transport Plan Stage
Transport Plan Crew
Operational Method: If the Transport Plan is being created then the user declares which
Vehicle or Vehicle Type will be departing from which Location on
which date/time and an estimate of the fuel weight required for each
Transport Plan Stage.
They can then define the crew members for the transport and the
roles they will take for the Transport Plan.
The system will inspect the waiting list of Manifest Items and
display a list of those that have transport requirements that are
current and not already assigned to another journey.
The user can select Manifest Item Transport Requirements that have
already been assigned for re-assignment if required.
The user selects Manifest Items from the list for assignment to the
current Transport Plan. The ‘from’ and ‘to’ locations and all other
required information will already have been captured.
The system will use the most recent Manifest Item Weight History
and the fuel weight to total the weight of each Transport Plan Stage
and warn the user if over the Vehicle Type’s Max Load.
Frequency: Several times daily.
Expected Growth: In line with Business growth.
Quality: Total.
Exception Handling: A Transport Plan should not be regarded as complete and allowed to
have a manifest printed until it has estimated fuel entered for each
Transport Plan Stage and the Transport Plan has been assigned to a
vehicle.

Security/Access: Controlled by Job Role.

Auditable: Yes. User who creates Transport Plan.

7.3 Passengers Or Cargo Checks In / Check In Manifest Item
Purpose: Register arrival of Manifest Items for transportation.
Input: Manifest Item
Output: Manifest Item Event

Manifest Item Weight History
Operational Method: The Manifest Item is confirmed as being expected for transportation.
It is then weighed and, in the case of Cargo, tagged and loaded to
the vehicle. Any association between items of cargo a person will
be recorded.
Persons are issued with boarding cards and appropriate

transportation equipment (Thermal and Survival suits etc). System
will identify to the user those if a persons medical certificate or
company liability insurance certificate is due to expire within 3
months. System shall also prompt user to request passengers to
review and update Person details if not done within the last 6
months. Manifest Items may be allocated a seat on the aircraft when
entered.
A record is made of the current location of the Manifest Item on

Manifest Item Event.
Timing: 5 minutes.
Quality: Total.
Exception Handling: If a Manifest Item will take the total known weight of the Manifest
over the vehicle limit then advise the user.
Auditable: Yes. User who registers arrival of Manifest Item.

7.4 Vehicle ready to leave / Build Manifest
Purpose: Produce a manifest in order to enable a vehicle to commence it’s

journey.
Input: Manifest Item Event

Manifest Item Transport Plan Stage
Vehicle Event
Output: A manifest for the destination location Transport Supervisor

A manifest summary for the Transport Crew
Operational Method: The user ‘closes’ the flight by recording an appropriate Vehicle
Event.
This should trigger the production of two documents called Manifest
and Manifest Summary (copies of which will be found in the section
titled ‘Essential Reports’). The reports are constructed from
inspecting the Manifest Item Events for the Manifest Item Transport
Plan Stage to ascertain which have arrived and checked in.
Timing: 2 minutes.
Quality: Total.
Exception Handling: None identified.
Auditable: Yes. User who ‘closes’ the flight.

7.5 Vehicle Arrives / Disembark Passengers and Unload Cargo
Purpose: Accept Manifest Items in to a Location.
Input: Manifest Items
Output: Manifest Item Event

Person Allocation
Operational Method: Passengers present themselves for admittance to the location. The
user records their presence at the location by logging a Manifest
Item Event.
If appropriate to the location, the user assigns a bed, muster point,

special duties and any other allocations required by creating Person
Allocations. The system will automatically allocate a lifeboat in the
Person Allocations based on the muster point. The system will
display lifeboat capacity and availability. Users must be able to re-
allocate any of the above if required.
Cargo is recorded as received on the Manifest Item Event.
Timing: 30 seconds at most.
Quality: Total – no data entry, only data association and must be 100%
correct to support POB and Paris.
Exception Handling: If a Manifest Item is not expected at a location then the presence of
a manifest item at a location can be logged even if it does not appear
on a transport plan.
Security/Access: Controlled by Job Role
Auditable: Yes. User who creates Manifest Item Events and Person
Allocations.

7.6 Transport Plan Completed / Transport Completed
Purpose: Create export file of Cost Control information.
Input: Person
Output: Person
Dept
Journey details
Operational Method: When a Transport Plan is recorded as complete, then the relevant
cost control information is exported to the new system in order to
facilitate cost control analysis of work. This information should be
collated by transport plan.
Expected Growth: In line with Business Growth
Quality: Total as no user input required.
Security/Access: Not applicable as system initiated and controlled.
Auditable: Not applicable as system initiated and controlled

7.7 Produce Reports / Produce Reports
Purpose: To produce critical reports on demand as fast as possible with total

accuracy.
Input: All information on the database
Output: See sample report pages in ‘Essential Reports’ section.
Operational Method: In the event of an incident in particular or on demand in general,

reports are requested by the user to support Incident Support Centre
purposes (head-counts and communication).
The system will automatically print a revised POB report after

logging a Manifest Item Event of persons arriving or departing from
an offshore location.
System shall have the ability to auto fax / e-mail POB reports or
excerpts from them to contractors and the police.
Timing: Report information should be produced and available for printing

and viewing within 2 minutes.
Quality: Total. Enquiry only of database held information.
Security/Access: None.
Auditable: If user requested, user who requested report.

7.8 Incident Response Support / Maintain Incident Information
Purpose: To provide information approved for release to outside callers and

next of kin.
Input: Approved incident related information
Output: Information to the PARIS team for outside communication
Operational Method: Statements as to the nature of the incident for issue to media and
relatives of personnel offshore are written as and when information
arrives and approved by the Incident Management Team and
company Public Relations advisors. The statements are released to
the PARIS team as and when they are approved for issue.
Frequency: 10 statements per incident.
Timing: Within 2 minutes
Quality: Total.
Security/Access: All system users.
Auditable: Record of all approved statements released for communication on

the Incident Information History

7.9 Incident Response Support / Find Personnel Record

Purpose: To enable the PARIS team to ensure correct identification of
personnel and their status for communication to outside callers.
Input: Personnel records

Incoming calls
Time to make outgoing calls
Output: Information to the PARIS team for outside communication
Operational Method: An incoming call is answered by a member of the PARIS team

enquiring as to offshore personnel. The PARIS team member will
interrogate the system to locate the person’s record, and ask the
caller a number of questions to ensure the correct record is found.
The PARIS team member will then identify the caller and create a
contact record in the system if not already in existence. If time
permits during the exercise a member of the PARIS team may make
outgoing calls to next of kin to inform of person’s status. In each
case the PARIS team member shall communicate information on the
person and on the nature of the incident from the persons status and
incident information.
Frequency: Up to 1000 calls per hour per incident.
Timing: Immediate
Quality: Identification of correct person’s record must be high. System shall

minimise possibility of human error.
Security/Access: Incident Response Team and PARIS team members.
Auditable: n/a

7.10 Incident Response Support / Record Calls

Purpose: To record information provided by PARIS team members to
relatives and next of kin.
Input: User recollection of call details

Contact
Person
Output: Record of PARIS teams outside communications.
Operational Method: Following completion of a call to a relative of next of kin the PARIS
team member will record details of the call on the person’s record
including contact details, time of call, information given and any
promises of call backs.
Frequency: Up to 1000 calls per hour per incident
Timing: 20 seconds
Quality: User input of text. Total qualify for recording against correct
person’s record.
Security/Access: Incident Response Team and PARIS team members.
Auditable: Record of all calls made on the Communication History.

SRS Document - Passenger Movements Module

Uploaded by

Copyright:

Available Formats

SRS Document - Passenger Movements Module

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SRS Document - Passenger Movements Module

Uploaded by

Copyright:

Available Formats

Business Systems Project

Passenger Movements Requirements Pack

{A COMPANY} Document No. 1

Version No. Description of Change Date Author

0.1 Original Draft

1.0 Signed Version

Version Business Transaction Name

1.0 Passenger Movements

Name Signature Date

31/03/22 Version 1.0 www.BusinessAnalystSolutions.com Page: 2 of 40

31/03/22 Version 1.0 www.BusinessAnalystSolutions.com Page: 3 of 40

3.2 Interactions with other departments & organisations

31/03/22 Version 1.0 www.BusinessAnalystSolutions.com Page: 4 of 40

3.5 Main Processes Supported

31/03/22 Version 1.0 www.BusinessAnalystSolutions.com Page: 5 of 40

3.6 Essential Reports

People On Board (POB):

People On Board (POB):

31/03/22 Version 1.0 www.BusinessAnalystSolutions.com Page: 6 of 40

4. Journey plan A list of locations to be visited

31/03/22 Version 1.0 www.BusinessAnalystSolutions.com Page: 7 of 40

4.1 Request Transportation

Purpose: To allow requests for transportation to be stored until

Frequency: 50 times per day.

Expected Growth: In line with business growth.

Timing: Best endeavours.

Key Benefits: 1) Users specify initial request for transport requirements

2) Users now able to book more than 1 set of journeys

3) Passengers will not have to be checked in twice when

31/03/22 Version 1.0 www.BusinessAnalystSolutions.com Page: 8 of 40

31/03/22 Version 1.0 www.BusinessAnalystSolutions.com Page: 9 of 40

4.2 Maintain Transport Plan

Purpose: To determine the destinations to be visited on a particular

Frequency: 5 times per day.

Expected Growth: In line with business growth.

Timing: Best endeavours.

31/03/22 Version 1.0 www.BusinessAnalystSolutions.com Page: 10 of 40

31/03/22 Version 1.0 www.BusinessAnalystSolutions.com Page: 11 of 40

4.3 Passengers Or Cargo Checks In

Purpose: Record arrival of passengers and cargo for inclusion on a

Frequency: 50 times per day.

Expected Growth: In line with business growth.

Timing: Best endeavours.

2) System will prompt users to remind personnel of

31/03/22 Version 1.0 www.BusinessAnalystSolutions.com Page: 12 of 40

31/03/22 Version 1.0 www.BusinessAnalystSolutions.com Page: 13 of 40

4.4 Vehicle Ready to Leave

Purpose: Provide transport crew with departure manifest.

Frequency: 5 times per day.

Expected Growth: In line with business growth.

Timing: Best endeavours.

31/03/22 Version 1.0 www.BusinessAnalystSolutions.com Page: 14 of 40

31/03/22 Version 1.0 www.BusinessAnalystSolutions.com Page: 15 of 40

4.5 Vehicle Arrives

Purpose: Record arrival of passengers and cargo at a destination.

Frequency: 50 times per day.

Expected Growth: In line with business growth.

Timing: Best endeavours.

31/03/22 Version 1.0 www.BusinessAnalystSolutions.com Page: 16 of 40