Language selection

Search

Client application qualification program - v6.7 - September 2017

PDF version

Table of Contents

Copyright notice

©HER MAJESTY THE QUEEN IN RIGHT OF CANADA-2017, as represented by the Minister of Fisheries and Oceans Canada.

This Department of Fisheries and Oceans (DFO) document is the Client Application Qualification Program (Qualification Program). No other reproduction, transmission, telecommunication or publication of whole or any part of this document may be undertaken without the prior written permission of DFO.

Requests for permission to reproduce, transmit, communicate via telecommunication, publish or otherwise exploit the copyright in the whole or any part of this document should be addressed to DFO at the address or coordinates shown below:

Mark Ledwell
Manager, Business Relationship Management
Fisheries and Licence Policy, Fisheries and Harbour Management
Fisheries and Oceans Canada, Government of Canada
Mark.Ledwell@dfo-mpo.gc.ca,709-772-4260

Permission relating to the reproduction or publication of the whole or any part of this document for purposes of sale may be made conditional upon the requester’s entering into a licensing agreement and the payment of royalties.

1. INTRODUCTION

Subsection 61(3) of the Fisheries Act authorizes Fisheries and Oceans Canada (DFO) to impose terms and conditions of any licence issued under this Act to require that fish harvesters keep a log of their catches and their fishing efforts and submit them to DFO. To date, fish harvesters have generally reported this information using paper documents.

The national Electronic Logbook (ELOG) Program will introduce the use of third party developed client applications that will enable fishers to submit their information to DFO, also referred to throughout this document as the client application. This approach is intended to increase the options available to fishers by allowinfg them the flexibility to choose a client application that is best suited to meet their individual needs.

To ensure that fishers can select a client application with confidence, DFO has developed a Client Application Qualification Program (Qualification Program) that will identify which client applications have met the departmental standard.

The Qualification Program seeks to strike a balance between the need to ensure that regulatory and fisher/fleet operational requirements are met and third party developers have the flexibility to innovate.

This document provides further details on the Qualification Program.

2. DEPARTMENTAL STANDARD FOR CLIENT APPLICATIONS

To guide developers in their efforts to develop ELOG client applications, DFO has developed a Standard (DFO Standard for the Development of Electronic Logbook Client Applications) that all client applications must meet in order to be qualified. This Standard defines the requirements, processes and best practices to be taken into account during the development of all ELOG client applications.

Developed with support from the Canadian General Standards Board (CGSB), this Standard is the foundation on which the Qualification Program is built and is therefore key for client application developers to adhere to.

Section 61 of the Fisheries Act requires that fish harvesters keep a log of their catches and their fishing efforts and submit them to DFO. The ELOG system enables transmission of this information by fish harvesters to DFO using XML electronic files.

The Standard covers the following areas:

The complete Standard for the Development of Electronic Logbook Client Applications is available as a separate document.

3. QUALIFICATION PROGRAM DESCRIPTION

As previously stated, the Qualification Program must be effective in approving client applications that meet DFO’s needs without limiting opportunities for innovation.

In keeping with these guiding principles, the Client Application Qualification Program seeks to integrate into the normal client application development cycle by using information obtained during the testing phase as its primary review materials. This approach is intended to streamline the client application approval process to allow fishers and client application developers the flexibility they require.

To augment the approval of a client application based on developer submitted required materials, DFO reserves the right to carry out client application quality assurance reviews, at the Department’s discretion.

The following main areas of the Qualification Program are described below:

3.1 Enrollment in the Qualification Program

To initiate the Qualification Process, interested parties must submit a letter of interest to DFO. This letter must contain the following information:

This letter can be mailed or emailed to the following address:

ELOGS Client Application Qualification Program

Fisheries and Oceans Canada
Fisheries and Harbour Management [Fisheries and Licence Policy]
200 Kent Street, 13th Floor, Station 13N159
Ottawa, Ontario
K1A 0E6

Email: DFO.NAT.ELOGSqual-JBEqual.NAT.MPO@dfo-mpo.gc.ca

Upon receipt of the letter of interest, DFO will enroll the applicant into the Qualification Program by entering the received information into its tracking tool. This will be followed by an email containing further instructions and documentation to the point of contact listed.

This part of the Qualification Program is only required for the initial enrollment and is not required for updates to an existing client application, etc.

3.2 Development Cycle and Preparation of Required Documents

Upon enrollment as an interested party for the Qualification Program, the Qualification Coordinator will provide the registrant with a qualification instruction package.

Included in the instructions package is the following information:

Questions about the instructions package can be directed to the Qualification Coordinator. Information provided in this package should be strictly adhered to.

Development of the client application is the sole responsibility of the developers. DFO will only provide limited technical assistance to developers. If technical assistance is requested, DFO may require one or more of the following:

Required documentation for qualification should be prepared after successful completion of the client application development phase.

3.3 Required Documentation

The Qualification Process relies mainly on documentation submitted by developers that will show how their product meets the Standard. It’s imperative that developers give careful consideration to the Standard, in order to ensure an effective client application.

Therefore, based on the Standard, DFO has developed a list of required documentation to be submitted as part of the Qualification Process.

The required documentation includes the following:

All documentation must be submitted as a complete package to facilitate the review and avoid delays in the Qualification Program.

Coordination of testing with the DFO ELOG Qualification Program will be necessary. The Qualification Coordinator must be notified when developers commence testing of their client applications to provide limited support if necessary.

A written confirmation will be sent by email to the client application developers upon receipt of all documentation.

3.4 Review and Approval Process

Documents submitted to DFO are reviewed by the Qualification Program. This process is expected to take four to six weeks.

Submissions are prioritized in the order in which they are received by DFO; therefore it is imperative that companies consider the above timeframe when seeking qualification.

During this period, DFO may request additional information and/or materials at its discretion to help facilitate the review and approval process.

Upon completion of the review, an approval of qualification or denial of qualification will be granted. Applicants will subsequently be notified in writing by email of DFO’s decision on qualification.

Successful applicants will be listed on the DFO Electronic Logbook Program web page. Unsuccessful applicants are required to address issues identified in the written notification email and restart the Qualification Process.

If an issue is identified post qualification, DFO will communicate with the applicant to address the situation. Qualification could be revoked at the discretion of DFO, including removal from DFO’s list of qualified ELOG client applications.

3.5 Quality Assurance Review

To ensure the continued accuracy and integrity of the Qualification Process, DFO reserves the right to carry out quality assurance reviews which may include one or more of the following:

Failure to adequately respond to a DFO request for a Quality Assurance Review or failure to meet Standard requirements during a Quality Assurance Review is grounds for qualification revocation, and removal of a client application from DFO’s list of qualified ELOG client applications.

4. UPDATES TO EXISTING QUALIFIED CLIENT APPLICATIONS

Upgrades to existing client applications, or changes to address bugs are part of the client application development cycle and are the responsibility of the client application developer. To ensure that DFO is fully aware of all changes made to the client application and to be able to effectively communicate with fishers about the proper qualified version, client application developers who make changes not directly affecting any of the elements listed below are required to provide in writing a letter to the Qualification Coordinator containing the following:

Any changes to Forms, Fact Sheets or Instructions by DFO require resubmission for renewal of qualification through the entire process.

Additionally, any changes to a client application that affect any of the following also require a resubmission for a renewal of qualification through the entire process. These include:

Failure to follow these procedures is grounds for qualification revocation and can result in removal from the list of qualified ELOG client applications.

5. QUALIFICATION PROCESS FLOW

Below are process flow diagrams for the Qualification Program.

none
Description - Qualification Process Flow - 1.0 Manage Client eLog Application

This diagram documents the management of the entire qualification process. The DFO Qualification Coordinator will be conducting Quality Assurance and audits on Client ELOG Applications.

none
Description - Qualification Process Flow - 1.1 Update Client eLog Application

This diagram documents how the Software Vendor updates a qualified Client eLog Application through communications with the Fisheries and Oceans (DFO) Qualification Coordinator. There are two separate paths that can be taken depending on if the update affects the eLog Standard(s).

none
Description - Qualification Process Flow - 1.2 Enroll

This diagram documents the enrollment process for Software Vendors who are interested in becoming a qualified Client eLog application. The Software Vendor must submit a Letter of Interest, which will be received and entered into an internal tracking tool. If all information is received then an acceptance/qualification package will be sent to the Software Vendor.

none
Description - Qualification Process Flow - 1.3 Develop/Modify Client eLog Application

This diagram documents how the Software Vendor will develop or modify a Client eLog Application. This will require communications between the DFO Qualification Coordinator, as well as DFO Information Management and Information Technology (IM&TS).

none
Description - Qualification Process Flow – 1.5 Assess Client eLog Application Documentation

This diagram documents how the DFO Qualification Coordinator will assess the documentation provided for the Software Vendor’s Client eLog Application. Software Vendors will receive an approved or not approved notification and corresponding listing (if approved).

APPENDIX A: ELOG Test Scenario Scripts

ELOGS TEST SCENARIO SCRIPTS – V. 3

Assumptions:

Test Case: 1. Creation of New Account
Purpose: To verify:
  • Application Security; Data Security [19.1; 19.2]
  • Obtaining an ELOG Key [13.1]
  • Technical Support [20]
  • User Guide [21]
  • Instructions[17]
Input Test Data: The tester has obtained the ELOG Key created for testing.
Step# Step Description Expected Results Pass/Fail Comments
1. Open proposed ELOG client application. A login or registration page is successfully displayed.    
2. Click on the registration function and complete steps to create an account.
  • Steps to create a new account appear and are esily discoverable and self-guided.
  • User is asked to create a password or subscribe to another recognized security means. [19.1; 19.2]
  • User is asked to enter the ELOG Key provided by DFO. [13.1]
   
3. Account is created. User account is created.    
4. User browses profile to locate ELOG Key.
  • ELOG Key is not visible however there is indication that an existing ELOG Key has been stored. [13.1; 19.1]
  • Steps on how to obtain and store a new ELOG Key should be easily discoverable and self-guided. [13.1; 20; 21]
   
5. User browses how to create an ELOG and other features of the client application. User can easily discover and self-guide themselves to locate a user guide, help functions and technical support contact information. [20; 21]    
6. Logout. The user is logged out and a login screen is displayed. [19.1; 19.2]    
Test Case: 2. Creation of New ELOG
Purpose: To verify:
  • Application Security; Data Security [19.1; 19.2]
  • Privacy Notice Statement [23]
  • Basic Information Verification [12.2]
  • Forms [3.4; 3.4a; 3.4b]
  • Fact Sheets [18]
  • Data Dictionary [3.3]
  • Generating a Unique Logbook Identifier [7]
  • Default Values [6]
  • Data Recording [4]
  • Integrity [2.4]
  • Coordinates (latitude/longitude) [11]
  • Manual Entry [11.1]
  • Reading the GPS [11.2]
  • Operating Rules Related to Data Group Closure [5.1]
  • Data Group Closure [5]
  • Data Verification [5.2]
Input Test Data: The tester should have completed Test Case 1. The tester also needs to have relevant Forms, Fact Sheets; Data Dictionary and Appendix B of the Standard.
Step# Test Case Expected Results Pass/Fail Comments
1. Log in to the client application with the user account created in Test Case 1.
  • User is asked to enter a password. [19.1; 19.2]
  • The Privacy Notice Statement is presented with option to not show the message again. [23]
   
2. Click on function to create a new ELOG.
  • Basic information (likely entered during account creation) is presented for verification, including:
    • Captain’s name
    • Fisher Identification Number (FIN) of the license holder
    • Vessel Registration Number (VRN)
    • Licence number
    • Current date and time [12.2]
  • Basic information presented can be modified. [12.2]
   
3. User is presented with an option to choose the applicable fishery. The user can easily discover and self-guide themselves to choose their fishery.    
4. User is presented with a new ELOG.
  • The user is presented with the appropriate information fields or ELOG to be completed for the type of fishery sought. [3.4]
  • Unique logbook identifier consisting of six uppercase alphabetical characters is generated and visible to user. [7]
  • Required fields are distinguishable from optional fields. [3.4]
   
5. User enters data in all fields.
  • Default value fields are visible to the user and the user can modify these. [6]
  • All fields cannot exceed limits set by the Data dictionary and Fact Sheets during entry. [3.3; 18]
  • Data elements identified in Appendix B of the Standard cannot be modified. [6]
  • User is able to enter data without external communication capabilities. [4]
  • User is able to declare all species caught without limitations. [2.4]
   
6. User enters coordinates data (latitude and longitude).
  • The user can always manually enter both the latitude and the longitude. [11]
  • Coordinates can not be partially entered (latitude and longitude must both be entered) [11]
  • The user can manually edit the information entered by the GPS. This is not applicable if a GPS function is not available. [11.1]
  • A GPS function is available where the user clicks so that current coordinates are established and recorded. The request for coordinates must be initiated by the fish harvester. This is an optional function. [11.2]
   
7. User saves data entered.
  • The status of the data group (open, closed, transmitted, modified) is clearly displayed (visible and distinguishable). Group status is used as defined in the Standard. [5.1]
  • The user is always able to edit the data of a data group while the status of the data group is different from “Closed”. [5.1]
  • The user can save data and close data groups without transmitting. [5]
  • User is able to save and close data groups without external communication capabilities. [4]
  • User is alerted if any required fields have not been completed and will not be able to proceed with changing the status of the group until data is entered. [3.4a; 3.4b]
  • User is prompted to verify data before closing the data group. [5.2; 3.4]
  • All data within the given ELOG is visible and is displayed in the same units of measurement as those during data entry. [5]
  • User is alerted that no modifications can be made while the status of the data group is “Closed”. [5.1]
   
8. Logout. The user is logged out and a login screen is displayed. [19.1; 19.2]    
Test Case: 3. Submitting an ELOG
Purpose: To verify:
  • Application Security; Data Security [19.1; 19.2]
  • Privacy Notice Statement [23]
  • Data Group Verification [12.1]
  • Generating a Unique Logbook Identifier [7]
  • Logbook Verification [9]
  • Data Recording [4]
  • Data Group Closure [5]
  • Operating Rules Related to Data Group Closure [5.1]
  • Data Verification [5.2]
Input Test Data: The tester should have completed Test Case 1 and Test Case 2.
Step# Test Case Expected Results Pass/Fail Comments
1.

Log in to the client application with the user account created in Test Case 1.

The user will now deactivate the privacy notice from showing in the future.

The privacy notice statement is presented with option to not show the message again. [23]    
2. Click on function that creates a new ELOG. User is presented with a warning message that an existing ELOG has yet to be transmitted to DFO. [12.1]    
3. User retrieves existing ELOG created in Test Case 2.
  • Existing ELOG retrieval is easily discoverable and self-guided.
  • The user can easily discover and self-guide themself to identify which existing ELOG has not been submitted.
  • Unique ELOG identifier is visible. [7]
  • Data entered without external communication capabilities is visible. [4]
  • At minimum, the last two ELOGs entered (or more if stated in Fact Sheets) are visible in their entirety, regardless if they have been transmitted. [9]
   
4. User transmits ELOG to DFO.
  • User is alerted to review data and to contact DFO should modifications be required. [5; 5.1; 5.2]
  • Data of a data group cannot be modified while status of the data group is “Closed”. [5.1]
  • Transmission button is easily discoverable and self-guided.
  • User receives alert confirming transmission.
   
5. Logout. The user is logged out and a login screen is displayed. [19.1; 19.2]    
Test Case: 4. Transmitting an ELOG to DFO
Purpose: To verify:
  • XSD [3.5]
  • Data Groups [3.6]
  • Data Transmission [13]
  • Web Service [13.2]
  • XML File Names [3.7]
  • Electronic Logbook System XML Structure [3]
  • XML Nodes [3.1]
  • Data Elements [3.2]
  • Attributes Describing Mode Used [11.3]
  • Data Group Closure [5]
  • Fact Sheets [18]
  • Transmission Frequency [13.5]
  • Transmission Register [13.3]
  • Archives of XML Files [13.4]
Input Test Data:

The tester should have completed Test Case 1, Test Case 2 and Test Case 3.

This section requires interaction with the DFO ELOG technical support group to test submission to DFO. Coordination of testing times must be arranged through the Qualification Coordinator. Confirmation of successful or unsuccessful transmission will be given at this time for inclusion in this report. Unsuccessful transmission may require rescheduling of test with DFO ELOG technical support group.

Step# Test Case Expected Results Pass/Fail Comments
1. Validation of XML file structure. XML file generated is verified against XSD file. [3.5; 3.6]    
2. DFO ELOG is received by DFO.
  • The ELOG is received in XML format using a DFO web service. [13]
  • The transmission is received via a HTTPS connection with a SOAP envelope including the ELOG Key and file name and XML File. [13.2]
  • XML file name appears as defined in Standard: Region ID-Licence Number-date/time.xml or .7z if the file was compressed. [3.7; 13.2]
  • Node structure is confirmed. [3; 3.1]
  • All elements have data within their field. [3.2]
  • Units of measurements received follow the unit required in the XML data dictionary: [3.2]
    • Dates and times in UTC.
    • Duration is represented in minutes.
    • Positions are in standard WSG84 represented in degrees and decimals (carried out to four decimal places).
    • Weights, lengths and volumes are represented in SI units.
  • Coordinate elements have an XML attribute to indicate the mode used by the user to assign value to the coordinate: M for manual; G for GPS. [11.3]
  • Where required as per Forms and Fact Sheets, the date and time that a data group was closed is visible. [5; 18]
  • The client application allows users to transmit logbook data at the frequency requested in conditions of licence/fact sheets. [13.5]
   
3. Open ELOG client application to view transmission register.
  • Easily discoverable and self-guided by the user.
  • The last 30 days of transmissions are available to the user even without connectivity. [13.3.3]
  • The register for transmissions that use the Web service of DFO contains the following information:
    • Transmission confirmation number.
    • Date and time of transmission attempt (UTC).
    • Name of file transmitted.
    • Transmission status (“Fail” or “Success”).
    • Error message (if applicable).
    • Logbook unique identifier.
    • Trip number.
    • Vessel number.

    XSD validation result. [13.3.1]

  • The register for transmissions that do not use the Web service of DFO contains the following information:
    • Date and time of transmission attempt (UTC).
    • Transmission status (“Fail” or “Success”).
    • Error message (if applicable).
    • Logbook unique identifier.
    • Trip number.
    • Vessel number. [13.3.2]
  • An archiving of the XML file is also visible to the user. [13.4]
   
Test Case: 5. Subsequent Testing
Purpose: To verify:
  • Privacy Notice Statement [23]
  • Data Group Verification [12.1]
  • Data Transmission [13]
  • Fact Sheets [18]
  • Operating Rules Related to Data Group Closure [5.1]
Input Test Data: The tester should have completed Test Case 1, Test Case 2, Test Case 3 and Test Case 4.
Step# Test Case Expected Results Pass/Fail Comments
1. Log in to the client application with the user account created in Test Case 1. The privacy notice statement is not presented. [23]    
2.

Click on function that creates a new ELOG.

Enter required information to maintain the ELOG“open”.

Logout.

Log into the client application.

Click on function that creates a new ELOG.

An error message appears indicating that the previous trip data has not been closed and that the user must review before proceeding. [12.1]    
3.

User returns to open ELOG.

User enters required information for a daily report requirement found in a Form if applicable. [13]

User submits a Daily Report.

  • Daily Report requirements are visible and distinguishable.
  • The user has the option to transmit the entire ELOG (all groups that are closed) or transmit only a portion of an ELOG called a Daily Report (as defined in the Forms and Fact Sheets).
   
4.

User retrieves a transmitted ELOG.

User wishes to make modifications to data within transmitted ELOG.

  • The user is reminded to contact DFO to put modifications on official record. [5.1; 14]
  • The status of the ELOG changes from Transmitted to Modified. [5.1]
   
Test Case: 6. User Interface in French
Purpose: To verify:
  • Language [8]
  • Character Sets [3.8]
Input Test Data: The tester should have completed Test Case 1 through Test Case 5 using the English user interface.
Step# Test Case Expected Results Pass/Fail Comments
1. User chooses to view the client application in French (if required as described in Forms and Fact Sheets). [8] Language selection is available in bilingual client applications.    
2. Repeat Test Case 1 through Test Case 5 using the French User Interface.
  • The French user interface is verified. All screens and messages are presented in French.
  • The messaging is identical in both English and French.
  • Terminology is accurate to present day use.
   
3. Verify in each of the tests that all elements of the user interface are in French.
  • All screens and messages are in French.
  • Data that is stored in the database in both French & English should show in French.
  • French accents have been correctly supported.
   
Test Case: 7. Functioning of Each Form
Purpose: To verify:
  • The successful functioning for each Form and Fact Sheet supported by the application.
Input Test Data: The tester should have completed Test Case 1.
Step# Test Case Expected Results Pass/Fail Comments
1. Repeat Test Case 2 through Test Case 6 using the Form and Fact Sheet requiring testing. Use these test scripts to note for each Form and Fact Sheet that is being tested.    

APPENDIX B: Letter of Attestation

APPLICATION DEVELOPERS LETTERHEAD

DATE:

TO:

RE: Development of Electronic Logbook Client Application - Letter of Attestation

This letter is to ascertain that (Application Developers Name) has included all specifications outlined in the Standard for the Development of Electronic Logbook Client Applications. I hereby attest that the Standard was followed throughout the entire development of our client application - (Name and version of Application) and will continue to be met in all maintenance of the client application. I understand that the continued approval of our application is contingent upon continuing to meet the conditions set out in the attestation. I agree that any information I have provided is true, accurate and complete.

I understand that for a court case, under section 13.4 and 18.2 of the Standard, I may be asked to provide files for the verification of data provided by users and attest to the functionality of the client application in terms of data security. The data chain of custody shall always be foolproof; especially concerning the management of the data, including the data converter, if applicable.

I understand that under section 22 of the Standard, I may have to testify as a witness in a court case or provide an affidavit that complies with the provisions of the Canada Evidence Act or other relevant statutes. As the copyright holder, I shall also provide a detailed explanation of any transformation or alteration of data from closure of data group to the transmission of this data group to DFO. This would include the data converter, if applicable.

Sincerely,

Signature

Printed Name
Application Developers Name

Date modified: