SWE505: Object Oriented Software Engineering

Lab Practical File

CASE STUDY- Courier Management System
Submitted towards the partial fulfillment of
the requirements of the award of the degree of
Master of Technology
In
Software Engineering
Submitted by
DEVANSH SINGH (23/SE/54)
Submitted to
Dr. Rahul
Assistant Professor
Department of Software Engineering

Delhi Technological University

(Formerly Delhi College of Engineering)
Bawana Road, New Delhi - 110042
 December, 2025
Problem Statement: Courier Management System (CMS)

Introduction
In today’s fast-paced logistics environment, courier service providers are facing growing challenges
in managing their operations smoothly and efficiently. Outdated paper-based processes and
fragmented digital tools are no longer sufficient to handle the complex interactions between delivery
staff, dispatch managers, and customers. To address these inefficiencies, there is a need for a robust
Courier Management System (CMS) that can streamline workflows and enhance the overall
delivery experience for all involved.
The current system suffers from several shortcomings:
 Manual parcel booking and dispatch procedures result in delays and excessive administrative
effort
 Disorganized parcel tracking through various disconnected platforms
 No centralized system for managing delivery statuses, customer feedback, and payment
details
 Difficulty in monitoring delivery agents and vehicle routes in real-time
 Poor communication between delivery personnel and recipients
 Limited accessibility to parcel and delivery updates outside of working hours
 Time-consuming manual checks for address validation and delivery eligibility

Previous systems have proven slow and inefficient due to several key drawbacks:
1. Lack of Customization: Most legacy systems are rigid and fail to meet the specific
operational needs of different courier companies.
2. Manual Data Handling: Staff are often required to enter data into multiple systems
manually, which increases errors and slows down processes.
3. No Mobile Accessibility: Without dedicated mobile applications, delivery agents and
customers cannot track or manage deliveries on the go.
4. High Operational Costs: Many solutions are expensive to deploy and maintain, posing a
challenge for smaller courier businesses.
5. Inadequate Technical Support: Limited or slow support services lead to extended
downtimes, affecting customer satisfaction and business performance.

To overcome these challenges, a modern, all-in-one Courier Management System is proposed,

offering the following advanced features:

2
 1. User-Friendly Interface: A simple, intuitive interface that makes navigation easy for all
users—couriers, dispatchers, and customers—with built-in accessibility options.
2. Enhanced Security and Data Privacy: Secure data handling through encryption and full
compliance with data protection regulations ensures trust and safety.
3. Mobile Compatibility: A responsive, mobile-ready platform that allows real-time access and
updates from any location.
4. High Scalability and Reliability: Built to efficiently manage high volumes of deliveries and
users without compromising performance.
5. Flexible and Customizable Design: Easily tailored to meet the unique requirements of
various courier service models, supporting local, regional, and national logistics operations.

Constraints and Limitations

1. Technical Constraints
 Platform Dependency: The system may initially be designed for web or Android platforms
only, limiting compatibility with iOS or other operating systems unless further development
is undertaken.
 Internet Connectivity Requirements: The CMS relies heavily on real-time data exchange and
tracking, which may be impacted in regions with poor or unstable internet connectivity.
 Hardware Limitations: Delivery personnel may not have access to modern smartphones or
GPS-enabled devices, which can affect location tracking and app performance.

2. Operational Constraints

 Staff Training and Adoption: Delivery agents and administrative staff may require proper
training to adapt to the new system. Resistance to change or lack of digital literacy may slow
down adoption.
 Budgetary Constraints: Smaller courier services may have limited budgets for acquiring new
devices, implementing software, or maintaining cloud services, which can delay full-scale
deployment.
 Limited Technical Support Staff: In the early stages, the organization might lack dedicated IT
staff to handle technical issues, leading to extended downtimes or slow issue resolution.
 Geographical Limitations: Rural or remote delivery zones may present challenges such as
poor mapping data, GPS inaccuracy, or lack of consistent delivery patterns.
• Data migration from existing systems needed
Conclusion
The Courier Management System offers a vital solution to overcome existing logistical and
operational inefficiencies in the courier industry. Its successful implementation will streamline
parcel tracking, improve delivery accuracy, enhance customer communication, and reduce manual
workload for staff. By adopting this system, courier companies can ensure faster, more reliable
service while boosting customer satisfaction and operational scalability.

4
Initial Requirement Document
Title of the project Courier Management System

Stakeholder required to capture Administration, Dispatch Team, System Maintainer,

requirement Delivery Personnel, Customers

Techniques used for requirement Brainstorming session, Interviewing, Past Drawback

capturing analysis

Name of person along with designation Dr. Rahul (Assistant Professor)

DEVANSH SINGH (23/SE/54)
Garvit Chaudhary (23/SE/62)
Date
Version VI.o

Consolidated list of initial requirement:

 The system shall allow customers to book courier services by entering sender and
receiver details, parcel information, and delivery preferences.
 The system shall provide real-time tracking of courier status from pickup to delivery.
 The system shall allow customers and delivery personnel to communicate through an
integrated messaging feature.
 The system shall store contact details of customers and delivery staff for smooth
coordination.
 The system shall maintain a history of all courier transactions, including timestamps,
delivery status, and personnel assigned.
 The system shall enable customers to cancel or reschedule deliveries before dispatch.
 The system shall allow upload and storage of digital documents such as delivery
proofs, invoices, or ID verification.
 The system shall allow dispatch teams to send updates or alerts to individual
customers, delivery agents, or all users simultaneously.
 The system shall support the creation of delivery zones and assignment of agents to
specific zones.
 The system shall allow users (staff and customers) to update their personal
information including address and contact details.
 The system shall provide options for password change and secure password reset via
registered email.
 The system shall notify users about key events such as pickup confirmation, out-for-
delivery status, and successful delivery.
 The system shall display monthly or weekly delivery statistics, including successful,
delayed, or failed deliveries.
Use Case Diagram of the Case Study
 Use Case Diagram:

Administrator

Student

Use Case Description of the Case Study

Complete Use Case Descriptions - Course Management System

Use Case #1: Login to the System
Primary Actor: All Users (Administrator, Delivery Personnel, Customer)

6
Description:
This use case handles user authentication by verifying login credentials and granting role-based
access to the system.

Preconditions:
 User has valid login credentials
 The Courier Management System is online and accessible

Main Flow:
1. User navigates to the login page
2. User enters their username and password
3. System verifies credentials against stored data
4. System identifies user role (Administrator, Delivery Personnel, or Customer)
5. System grants appropriate access level
6. System logs the login activity with timestamp

Postconditions:
 User is authenticated and logged into the system
 A user session is created and tracked
 Role-based permissions and dashboard are activated
 Login event is recorded in the system logs

Alternative Flows:
 Invalid credentials: Show error message “Invalid username or password”
 Forgot password: Provide option to reset password via email or OTP
 Account locked due to multiple failed attempts: Display message and prompt to contact
administrator

Use Case #2: Manage Users

Primary Actor:
Administrator

Description:
This use case allows the Administrator to manage system users by creating, modifying, deactivating,
or resetting user accounts for customers, delivery personnel, and other admins.

Preconditions:
 Administrator is authenticated
 User management module is accessible
Main Flow:
1. Administrator logs into the system
2. Navigates to the user management section
3. System displays a list of all registered users
4. Administrator can:
o Create a new user (assign role: customer, delivery personnel, or admin)
o Edit existing user details (contact info, role, etc.)
o Activate/deactivate user accounts
o Reset user passwords
5. System validates the entered data
6. System updates the user database
7. Notifications (if applicable) are sent to affected users

Postconditions:
 User database is updated with the latest user information
 Role-based permissions are applied to new or updated accounts
 All changes are recorded in the system logs

Alternative Flows:
 Duplicate username/email: Prompt for unique credentials
 Invalid or missing input: Display validation error messages
 Bulk user import: Allow uploading of a CSV file and display import summary

Use Case #3: Book Courier

Primary Actor:
Customer

Description:
This use case enables customers to book a courier pickup for package delivery by entering shipment
details and selecting the preferred service type.

Preconditions:
 Customer is authenticated and logged in
 Courier booking module is accessible

Main Flow:
1. Customer logs into the system
2. Navigates to the “Book Courier” section
3. Enters pickup and delivery addresses
4. Inputs package details (weight, dimensions, type)

8
 5. Selects delivery type (e.g., standard, express)
6. Reviews estimated cost and delivery time
7. Confirms booking
8. System generates booking ID and pickup schedule
9. System notifies customer and delivery personnel

Postconditions:
 Booking is saved in the system
 Pickup task is queued and visible to delivery personnel
 Confirmation and tracking ID are sent to the customer
 Booking is recorded in system logs

Alternative Flows:
 Invalid address or package info: Show validation errors and prompt corrections
 Service unavailable for entered location: Display error and suggest alternatives
 Payment failure (if pre-payment is enabled): Show retry option or alternate method

Use Case #4: Assign Delivery Task

Primary Actor:
Administrator

Description:
This use case allows the Administrator to assign booked courier pickups and deliveries to available
delivery personnel based on location, schedule, and availability.

Preconditions:
 Administrator is authenticated
 Courier bookings exist in the system
 Delivery personnel are registered and active

Main Flow:
1. Administrator logs into the system
2. Navigates to the “Delivery Assignment” section
3. System displays list of unassigned courier bookings
4. Administrator filters bookings by region or priority
5. Selects a booking and assigns it to an available delivery personnel
6. System updates the booking status and records the assignment
7. Assigned delivery personnel is notified of the task

Postconditions:
 Delivery task is assigned and reflected in both admin and personnel dashboards
 Booking status is updated to "Assigned"
  Notifications are sent to the assigned personnel

Alternative Flows:
 No available personnel: Show alert and add to pending queue
 Personnel already at full capacity: Prompt reassignment to another person
 System error in assignment: Log issue and notify admin

Use Case #5: Upload and Manage Delivery Proofs

Primary Actor:
Delivery Personnel

Description:
This use case allows delivery personnel to upload proof of successful delivery, such as customer
signatures, photos, or delivery notes, to maintain delivery records and support accountability.

Preconditions:
 Delivery personnel is authenticated
 Assigned delivery task is marked as "Out for Delivery" or "In Progress"
 Mobile device or web portal access is available

Main Flow:
1. Delivery personnel logs into the system
2. Navigates to the “My Deliveries” section
3. Selects a completed delivery task
4. Uploads delivery proof (e.g., digital signature, photo, note)
5. System validates and stores the proof
6. System updates the delivery status to “Delivered”
7. Notification is sent to customer and admin

Postconditions:
 Delivery proof is securely stored in the system
 Status of delivery is updated
 Record is available for future reference and dispute resolution

Alternative Flows:
 Invalid file format or size: Prompt for supported formats (e.g., JPG, PDF)
 No internet connection: Queue upload and retry when online
 Missing delivery task: Show error and prompt re-verification of booking ID

Use Case #6: Track Shipment

10
Primary Actor:
Customer

Description:
This use case enables customers to track the real-time status and location of their shipments using a
unique tracking ID provided during booking.

Preconditions:
 Customer is authenticated (optional if public tracking is allowed)
 Shipment has been booked and assigned a tracking ID
 Tracking module is operational

Main Flow:
1. Customer accesses the “Track Shipment” section
2. Enters or selects the tracking ID
3. System retrieves shipment data from database
4. Displays current status (e.g., Booked, In Transit, Out for Delivery, Delivered)
5. Shows delivery milestones and timestamped updates
6. Optionally shows live location or estimated delivery time (if GPS is enabled)

Postconditions:
 Shipment status and history are presented to the customer
 System logs access to tracking info for security

Alternative Flows:
 Invalid or expired tracking ID: Display error and suggest verification
 No updates available yet: Notify customer that tracking will begin shortly
 Backend service failure: Display fallback message and prompt retry later

Use Case #8: Update Delivery Status

Primary Actor: Delivery Personnel

Description:
This use case describes how a delivery agent updates the status of a courier shipment during its
journey to the recipient, such as marking it as picked up, in transit, delayed, or delivered.

Preconditions:
 Delivery personnel is authenticated
 A courier has been assigned to the delivery personnel
  Courier booking is active and valid

Main Flow:
1. Delivery personnel logs into the system
2. Navigates to assigned delivery tasks
3. Selects a specific courier
4. System displays status update options (e.g., Picked Up, In Transit, Delivered)
5. Delivery personnel selects appropriate status
6. System validates the input
7. System updates the status in real-time

Postconditions:
 Courier status is updated in the database
 Customer can view updated tracking information
 Admin dashboard reflects updated delivery status
 Status update is logged with timestamp

Alternative Flows:
 Invalid courier ID: Display error message
 Network error: Save update locally and retry sync later
 Unauthorized update attempt: Show permission denied message

Use Case #9: Cancel or Modify Booking

Primary Actor: Customer (User), Administrator

Description:
This use case describes how a customer or admin can cancel a courier booking or modify booking
details before dispatch, such as recipient address, delivery date, or package description.

Preconditions:
 The user is authenticated
 The booking exists and is eligible for modification or cancellation (not yet dispatched)

Main Flow:
1. User accesses the booking history or tracking section
2. Selects a specific courier booking
3. System checks booking status (e.g., not yet dispatched)
4. User chooses to either:
o Modify booking details (e.g., address, contact info)

12
 oCancel the booking entirely
5. System validates the changes
6. System updates the booking database
7. System sends confirmation to the user

Postconditions:
 Booking is updated or marked as canceled
 Affected parties (e.g., delivery personnel) are notified
 Refund or rescheduling process is initiated (if applicable)
 Logs are created for auditing

Alternative Flows:
 Attempt to cancel dispatched courier: Show error "Cannot cancel after dispatch"
 Invalid data in modification: Show input validation error
 Network/server error: Show retry message

Use Case #10: Generate Reports

Primary Actor: Administrator

Description:
This use case allows the administrator to generate various reports for operational analysis,
performance tracking, and decision-making purposes related to courier operations.

Preconditions:
 Administrator is authenticated
 System has up-to-date operational data
 Reporting module is accessible

Main Flow:
1. Administrator logs into the system
2. Navigates to the reporting dashboard
3. Selects the type of report (e.g., delivery success rate, daily bookings, revenue report, courier
delays)
4. Chooses filters (e.g., date range, region, delivery agent)
5. System retrieves relevant data
6. System generates and displays the report
7. Administrator can download, print, or export the report

Postconditions:
 Requested report is generated and available for review/export
  Report is logged in system access history
 Decisions can be made based on report insights

Alternative Flows:
 No data for selected filters: Show message “No data available”
 Export failure: Show export error and allow retry
 Permission issue: Display access denied if user lacks privileges

SOFTWARE REQUIREMENT
SPECIFICATION

Version 1.0

DATE

COURIER MANAGEMENT SYSTEM

DEVANSH SINGH (23/SE/54)

GARVIT CHAUDHARY (23/SE/62)

BTech

14
 In

Software Engineering

1st Semester
Software Requirements Specification
1. Introduction

1.1 Purpose This Software Requirements Specification (SRS) document provides a comprehensive
description of the Courier Management System (CMS). It details the system's intended behavior,
functional and non-functional requirements, and constraints for developers, administrators, and
stakeholders.

1.2 Document Conventions

 SHALL: Mandatory requirement

 SHOULD: Recommended requirement

 MAY: Optional requirement

 Priority Levels: Critical, High, Medium, Low

1.3 Intended Audience

 Development Team

 System Administrators

 Quality Assurance Team

 Logistics Company Stakeholders

 Project Managers

1.4 Project Scope The Courier Management System SHALL provide comprehensive logistics and
parcel handling functionalities including:

 User management and authentication

16
  Courier booking and tracking

 Delivery assignment and proof uploads

 Notification and alert system

 Reporting and analytics

1.5 References

1. IEEE Std 830-1998

2. Local Courier Industry Regulations

3. Data Protection Laws (e.g., GDPR)

4. Accessibility Standards (WCAG 2.1)

2. Overall Description
2.1 Product Perspective
The Courier Management System (CMS) SHALL be a centralized, web-based application
integrated within the courier company's operational infrastructure. It will interact with:
 User Authentication System
 Delivery Tracking APIs
 SMS/Email Notification Services
 Package Scanning Devices
 Database for Courier Records
2.2 Product Functions
The Courier Management System SHALL provide the following high-level functionalities:
1. User Management
o Secure authentication and role-based access
o Profile creation and account management
2. Courier Booking and Management
o Booking new couriers
o Updating and modifying bookings
o Cancelling shipments
3. Shipment Tracking
o Real-time tracking of courier packages
 o Delivery route management
o Status updates
4. Delivery Task Assignment
o Assigning delivery agents to tasks
o Viewing and updating delivery schedules
5. Proof of Delivery Management
o Uploading delivery photos or signed documents
o Validating proof entries
6. Notification System
o Sending status updates to customers
o Alerts for delayed or failed deliveries

2.3 User Classes and Characteristics

Technical Usage
User Type Primary Functions
Proficiency Frequency
System configuration, user
Administrator High Daily
management
Customer Service Booking, canceling, tracking
Medium Daily
Agent support
Delivery Personnel Low Daily View tasks, update delivery status
Customer Basic Occasional Book courier, track packages

2.4 Operating Environment

 Web Browsers: Chrome 90+, Firefox 88+, Safari 14+
 Operating Systems: Windows 10+, macOS 10.15+, Linux
 Mobile Support: Android 10+, iOS 14+
 Server OS: Linux-based servers
 Database: PostgreSQL / MySQL
 Network: Minimum 1 Mbps bandwidth

2.5 Design and Implementation Constraints

 Technology Stack: Must follow approved tech stack (e.g., MERN, LAMP)
 Security: Must comply with encryption and authentication standards
 Scalability: Must support growth in users and delivery volume
 Integration: Must work with GPS/location services and SMS APIs

2.6 User Documentation SHALL include:

 Online Help and Tutorials
 Step-by-step User Guides

18
  FAQs and Troubleshooting Tips
 Admin Manuals

2.7 Assumptions and Dependencies

Assumptions:
 All users have internet access and compatible devices
 Delivery agents have mobile devices with GPS
Dependencies:
 SMS gateway availability
 Working authentication service
 External courier tracking APIs (if used)

3. Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
1. General UI Requirements:
 SHALL be responsive and mobile-friendly
 SHALL comply with WCAG 2.1 accessibility standards
 SHALL offer role-based dashboard views
 SHALL provide clear, consistent navigation and real-time feedback
2. Dashboard Interface:
 SHALL show summary of booked couriers, deliveries, pending tasks
 SHALL provide access to tracking, booking, and assignment modules
 SHALL display notifications and alerts (e.g., delivery failed, status updated)
 SHALL include a search/filter feature for courier entries
3.1.2 Hardware Interfaces
 SHALL support barcode scanners and mobile devices
 SHALL interface with digital signature pads (optional)
 SHALL allow integration with printers for shipping labels
3.1.3 Software Interfaces
1. Authentication System
 Protocol: OAuth 2.0 or JWT
 Data format: JSON
 Error handling: Standard HTTP codes
2. Notification System (Email/SMS)
 Protocol: SMTP for email; HTTP for SMS gateway
 Formats: Text, HTML (Email); UTF-8 (SMS)
 Frequency: Real-time on booking, delivery update
3. External APIs
  Google Maps or OpenStreetMap for route tracking
 Payment Gateway (optional for online payment)
3.1.4 Communications Interfaces
 SHALL use HTTPS protocol
 SHALL support RESTful API architecture
 SHALL provide WebSocket for live updates to dashboard
 SHALL be compatible with SMS, push notifications, and email protocols

3.2 Functional Requirements

3.2.1 User Authentication
1. Login Function
 REQ-1.1: System SHALL provide secure login for all roles
 REQ-1.2: System SHALL support password recovery
 REQ-1.3: System SHALL support Multi-Factor Authentication (MFA)
 REQ-1.4: System SHALL maintain and manage active sessions
2. Profile Management
 REQ-1.5: Users SHALL be able to edit personal info
 REQ-1.6: Users SHALL update delivery preferences (for customers)
 REQ-1.7: Admins SHALL assign roles and manage permissions

3.2.2 Courier Management

1. Courier Booking
 REQ-2.1: Customers SHALL book a courier by entering sender/receiver details
 REQ-2.2: System SHALL validate address and phone formats
 REQ-2.3: System SHALL assign a tracking number to each booking
2. Cancel or Modify Booking
 REQ-2.4: Customers SHALL cancel bookings before pickup
 REQ-2.5: System SHALL update status and notify delivery personnel
 REQ-2.6: System SHALL prevent cancellation after package is dispatched

3.2.3 Delivery Operations

1. Assign Delivery Tasks
 REQ-3.1: Admins SHALL assign packages to available delivery agents
 REQ-3.2: System SHALL update agent dashboards in real time
 REQ-3.3: System SHALL avoid overlapping assignments
2. Upload and Manage Delivery Proofs
 REQ-3.4: Delivery agents SHALL upload proof (photo or e-signature)
 REQ-3.5: System SHALL validate file formats (JPEG, PDF, PNG)
 REQ-3.6: System SHALL attach delivery proof to tracking record
3. Update Delivery Status

20
  REQ-3.7: Agents SHALL mark deliveries as "Delivered", "Failed", or "Rescheduled"
 REQ-3.8: System SHALL notify customer of updated status
 REQ-3.9: System SHALL log status history

3.2.4 Tracking & Notification

 REQ-4.1: System SHALL show current status, last known location, and ETA
 REQ-4.2: Customers SHALL track packages using tracking number
 REQ-4.3: System SHALL notify sender/receiver on major status changes

3.3 Non-Functional Requirements

3.3.1 Performance Requirements
 Page load time: < 2 seconds
 Booking confirmation: < 3 seconds
 Real-time tracking updates: < 5 seconds
 System uptime: ≥ 99.9%
3.3.2 Security Requirements
 Password complexity enforcement
 Session timeout after 15 mins of inactivity
 Role-based access enforcement
 Data encryption in transit and at rest
 Secure upload handling (to prevent malicious file types)
3.3.3 Software Quality Attributes
 Reliability: 99.9% uptime
 Usability: Intuitive UI, <1% error rate
 Maintainability: Modular architecture
 Scalability: Support up to 10,000 concurrent users

3.4 Database Requirements

1. Core Entities:
 Users
 Courier Bookings
 Delivery Agents
 Delivery Tasks
 Status Updates
 Delivery Proofs
2. Relationships:
 User–Courier: Booked by and received by
 Courier–Agent: Assigned to
 Courier–Status: Timeline of updates
 Courier–Proof: Final delivery evidence
22
Appendix
1. Data Dictionary
Definitions of key data elements used in the system, including attributes and formats.
2. Use Case Diagrams
Visual representation of system functionalities and interactions between actors and use cases.
3. Class Diagrams
Depiction of system classes, attributes, operations, and relationships among them.
4. Entity Relationship Diagrams (ERD)
Database structure showing entities, attributes, and relationships relevant to courier
operations.
5. User Interface Mockups
Sample screenshots or wireframes for login, booking, tracking, and delivery modules.
A. GLOSSARY
- CMS: Course Management System
- MFA: Multi-Factor Authentication
- MTBF: Mean Time Between Failures
- WCAG: Web Content Accessibility Guidelines

Version History
- 1.0: Initial release (December 10, 2024)
- 0.9: Final review draft
- 0.8: Technical review draft - 0.7: Initial draft

B. ANALYSIS MODELS

24
1. USE CASE DIAGRAM

Administrator

Student