2.1 Introduction

In line with the techniques used in software development, DCSA has incorporated user stories and use cases into the standards development process to support the digitalisation efforts of the shipping industry. Both user stories and use cases serve the purpose of capturing and documenting requirements, but they differ in granularity, level of detail, and the stages of the development process in which they are most prominently used. They are complementary (a user story may be supported by one or more use cases and vice versa) and can be used together to provide a comprehensive understanding of software requirements. In this section we will focus on user stories.User stories are typically a concise, informal description of a feature or functionality written from an end user's or stakeholder perspective. They express the needs, goals, and expectations of users in a way that is easily understandable to ensure the delivered product meets the intended requirements. In standards development, this translates to creating testable acceptance criteria to validate that the standard is correctly implemented and achieves its intended purpose.The next paragraph provides some examples of user stories that DCSA has relied on to develop the standard for the Bill of Lading. This list is not exhaustive and serves only to illustrate the concept. The supporting use cases are defined in the dedicated Bill of Lading use cases section.

2.2 User stories examples

User story

Description

“As a shipper I want to update the number of packages in the current Shipping Instructions.“

The shipper submits an update of the Shipping Instructions with Bill of Lading use case “UC3: Submit updated Shipping Instructions”.

“As a shipper I want to modify a Reefer attribute in the Draft Transport Document.“

Reefer attributes can only be modified as part of the Booking process. Therefore, the shipper can request an update to the Draft Transport Document by initiating a booking amendment with Booking use case “UC7: Request amendment to confirmed booking”. After approving the amendment with Booking use case “UC8: Process amendment to confirmed booking”, the carrier publishes an updated Draft Transport Document with Bill of Lading use case “UC6: Publish Draft Transport Document”.

“As a shipper I want to modify a Dangerous Goods attribute in the Draft Transport Document.“

Dangerous Goods attributes can only be modified as part of the Booking process. Therefore, the shipper can request an update to the Draft Transport Document by initiating a booking amendment with Booking use case “UC7: Request amendment to confirmed booking”. After approving the amendment with Booking use case “UC8: Process amendment to confirmed booking”, the carrier publishes an updated Draft Transport Document with Bill of Lading use case “UC6: Publish Draft Transport Document”.

“As a shipper I want to modify a seal number in the Draft Transport Document.“

The shipper cannot directly modify the Draft Transport Document. Instead, the shipper requests a Shipping Instructions update with Bill of Lading use case “UC3: Submit updated Shipping Instructions”. After approving the update with Bill of Lading use case “UC4: Process updated Shipping Instructions”, the carrier publishes an amended Draft Transport Document reflecting the new information with Bill of Lading use case “UC6: Publish Draft Transport Document”.

“As a shipper I want to modify a Reefer attribute in the Transport Document (after issuance).“

Reefer attributes can only be modified as part of the Booking process. Therefore, the shipper can request an amendment to the Transport Document by initiating a booking amendment with Booking use case “UC7: Request amendment to confirmed booking”. Depending on the type of Transport Document, different paths are followed:

Sea Waybill
After the carrier has approved the amendment request with Booking use case “UC8: Process amendment to confirmed booking”, the carrier issues an amended Sea Waybill reflecting the new information with Bill of Lading use case “UC8: Issue Transport Document”.

Electronic Bill of Lading (eBL)

Before or after the carrier has approved the amendment request with Booking use case “UC8: Process amendment to confirmed booking”, the shipper must submit a request to surrender the eBL for amendment back to the carrier (via the eBL platform from which it was issued) with Bill of Lading use case “UC9: Request surrender Transport Document (amendment)”.

After both the amendment request (via the Booking use case UC8) and the eBL surrender request are approved with Bill of Lading use case “UC10: Process Transport Document surrender request (amendment)”, the carrier voids the existing eBL and issues an amended eBL reflecting the new information with Bill of Lading use case “UC11: Void original Transport Document and issue amended Transport Document”.

Paper Bill of Lading

The amendment of a physical Bill of Lading happens out of band from the DCSA standard API (e.g. email, phone, mail).

“As a shipper I want to modify a Dangerous Goods attribute in the Transport Document (after issuance).“

Dangerous Goods attributes can only be modified as part of the Booking process. Therefore, the shipper can request an amendment to the Transport Document by initiating a booking amendment with Booking use case “UC7: Request amendment to confirmed booking”. Depending on the type of Transport Document, different paths are followed:

Sea Waybill
After the carrier has approved the amendment request with Booking use case “UC8: Process amendment to confirmed booking”, the carrier issues an amended Sea Waybill reflecting the new information with Bill of Lading use case “UC8: Issue Transport Document”.

Electronic Bill of Lading (eBL)
Before or after the carrier has approved the amendment request with Booking use case “UC8: Process amendment to confirmed booking”, the shipper must submit a request to surrender the eBL for amendment back to the carrier (via the eBL platform from which it was issued) with Bill of Lading use case “UC9: Request surrender Transport Document (amendment)”.

After both the amendment request (via the Booking use case UC8) and the eBL surrender request are approved with Bill of Lading use case “UC10: Process Transport Document surrender request (amendment)”, the carrier voids the existing eBL and issues an amended eBL reflecting the new information with Bill of Lading use case “UC11: Void original Transport Document and issue amended Transport Document”.

Paper Bill of Lading
The amendment of a physical Bill of Lading happens out of band from the DCSA standard API (e.g. email, phone, mail).

“As a shipper I want to modify the HS code in the Transport Document (after issuance).“

The shipper cannot directly modify the Transport Document. Instead, the shipper requests a Shipping Instructions update with Bill of Lading use case “UC3: Submit updated Shipping Instructions”. Depending on the type of Transport Document, different paths are followed:

Sea Waybill
After the carrier has approved the amendment request with Bill of Lading use case “UC4: Process updated Shipping Instructions”, the carrier issues an amended Sea Waybill reflecting the new information with Bill of Lading use case “UC8: Issue Transport Document”.

Electronic Bill of Lading (eBL)
Before or after the carrier has approved the amendment request with Bill of Lading use case “UC4: Process updated Shipping Instructions”, the shipper must submit a request to surrender the eBL for amendment back to the carrier (via the eBL platform from which it was issued) with Bill of Lading use case “UC9: Request surrender Transport Document (amendment)”.

After both the amendment request (via Bill of Lading use case UC4) and the eBL surrender request are approved with Bill of Lading use case “UC10: Process Transport Document surrender request (amendment)”, the carrier voids the existing eBL and issues an amended eBL reflecting the new information with Bill of Lading use case “UC11: Void original Transport Document and issue amended Transport Document”.

Paper Bill of Lading
The amendment of a physical Bill of Lading happens out of band from the DCSA standard API (e.g. email, phone, mail).

Explore chapters

Introduction
Use cases
State Transition Diagram