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 digitalization 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 Booking standard. This list is not exhaustive and serves only to illustrate the concept. The supporting use cases are defined in the dedicated Booking use cases section.

2.2 User stories examples

View examples of user stories that DCSA has relied on to develop the standard for the booking process. The supporting use cases are defined in the dedicated booking use cases page.

User story

Action

“As a shipper I want to add an additional container in my booking request.“

The shipper submits an updated booking request with Booking use case “UC3: Submit updated booking request”.

“As a shipper I want to modify the confirmed booking so that the number of containers is reduced by 1.“

The shipper submits a booking amendment request with Booking use case “UC7: Request amendment to confirmed booking”.

“As a shipper I want to cancel the last amendment I requested to the confirmed booking.“

The shipper cancels the last booking amendment request with Booking use case “UC9: Cancel amendment to confirmed booking”.

“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 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 carrier I want to confirm the booking based on the input received from the Shipper in the booking request.“

The carrier confirms the booking with Booking use case “UC5: Confirm booking request”.

“As a carrier I want to confirm the booking based on the input received from the Shipper in the booking amendment.“

The carrier confirms the booking amendment with Booking use case “UC8: Process amendment to confirmed booking”.

“As a carrier I want to update the confirmed booking with a new ETD (Expected Time of Departure).“

The carrier re-confirms the booking with Booking use case “UC5: Confirm booking request”.

“As a carrier I want to cancel the booking before it has been confirmed.“

The carrier cancels the booking with Booking use case “UC4: Reject booking request”.

“As a carrier I want to cancel the booking after it has been confirmed.“

The carrier cancels the booking with Booking use case “UC10: Decline booking by carrier”.