HOUSE SHIFTING
SYSTEM
SOFTWARE ENGINEERING-I
Assignment-IV
Submitted To: Mam Asia Shahab
Group Members:
Shaheer Ahmed
BCS233185
Usman Ali
BCS233194
Modeel Mehdi
BCS233206
Muhammad Tayyab Khan BCS233217
Muhammad Abdul Manan
1. Introduction
We want to create a mobile app that helps people book house shifting services easily.
Right now, when people need to move their homes, they have to make many phone calls
to find reliable movers, and it's really frustrating. Our app will connect customers with
trusted moving companies through a simple booking system.
This project is important because moving is stressful enough without having to worry
about finding good service providers. The app will make the whole process smooth and
transparent. We hope to create something that saves people time and gives them peace of
mind when they're planning to move.
2. Problem Statement
Currently, people face several problems when they need house shifting services. They
don't know which companies are reliable, prices are often unclear until the last minute,
and booking requires multiple phone calls. Moving companies also struggle to find
customers and manage their bookings efficiently.
If we don't solve these problems, customers will continue getting poor service and
unexpected costs. Service providers will miss out on potential business because
customers can't find them easily. The whole industry stays disorganized and inefficient.
3. Requirements Analysis
Functional Requirements:
User registration and login authentication
View available time slots for booking services
Book house shifting service with selected providers
Make payments through integrated payment gateway
Manage bookings and update booking status
Receive notifications about booking confirmations and updates
Provide feedback after service completion
Admin Manage user accounts and profiles
Admin Manage services offered by providers
Admin View comprehensive reports on system usage
Update booking status throughout service delivery
Non-Functional Requirements:
Performance: System should respond within 3 seconds for all user interactions
Security: All user data and payment information must be encrypted and secure
Usability: Interface should be intuitive and easy to navigate for all user types
Reliability: System should maintain 99% uptime with minimal service
interruptions
Compatibility: Application should work on both Android and iOS mobile
platforms
Scalability: System should handle increasing number of users without
performance degradation
Availability: Services should be accessible 24/7 with proper error handling
4. Design
System Architecture
Our app has three main parts:
Frontend (What users see):
Mobile app built with Flutter for both customers and service providers
Web dashboard for administrators
Simple, clean design that's easy to use
Backend (The brain of the system):
Server written in Dart that handles all the business logic
Manages user accounts, bookings, payments, and notifications
Connects to the database and external payment services
Database:
Stores all user information, bookings, payments, and feedback
Keeps everything organized and secure
UML Diagrams:
Use Case Diagram:
Fully Dressed Use Cases:
Register User:
Name: Register User
Short description: The user creates a new account to access the
system.
Precondition: User is not already registered.
Postcondition: User account is created.
Error situations: Email already exists or required fields are
missing.
System state in the event of an error: User account is not created.
Actors: Customer
Trigger: User selects register option.
Standard process: (1) User enters personal and login
information.
(2) System validates the inputs.
(3) System stores user details in the database.
(4) System confirms account creation.
Alternative processes: (3’) Email already in use.
(4’) System prompts user to use a different
email.
Book House Shifting Service:
Name: Book House Shifting Service
Short description: The customer books a house shifting service
from available slots.
Precondition: Customer is logged in.
Available slots are listed.
Postcondition: Booking is made and stored.
Error situations: No slots available or customer does not
confirm booking.
System state in the event of an error: Booking is not completed.
Actors: Customer
Trigger: Customer selects and confirms a slot.
Standard process: (1) Customer views available slots.
(2) Customer selects desired slot.
(3) System checks slot availability.
(4) System confirms booking.
Alternative processes: (3’) Slot not available.
(4’) System prompts customer to select
another slot.
Make Payment:
Name: Make Payment
Short description: The customer completes the payment for the
booked house shifting service.
Precondition: The customer has confirmed a booking.
The customer is logged in.
Postcondition: Payment is completed and booking is
confirmed.
Error situations: Payment fails or customer has insufficient
funds.
System state in the event of an error: Payment is not completed and booking is not
confirmed.
Actors: Customer
Trigger: Customer proceeds to pay for the service.
Standard process: (1) Customer selects payment option.
(2) Customer enters payment details.
(3) System processes the payment.
(4) System confirms successful payment.
Alternative processes: (3’) Payment fails.
(4’) System shows error message and asks
customer to retry.
Manage Booking:
Name: Manage Booking
Short description: The service provider views and updates the
status of bookings.
Precondition: Service provider is logged in.
Bookings are available in the system.
Postcondition: Booking status is updated or confirmed.
Error situations: Invalid booking ID or server error.
System state in the event of an error: Booking is not updated.
Actors: Service Provider
Trigger: Service provider selects a booking to update.
Standard process: (1) Service provider logs in.
(2) Service provider views bookings.
(3) Service provider updates booking status.
(4) System confirms update.
Alternative processes: (3’) Invalid update request.
(4’) System notifies of failure.
Sequence Diagram:
System Sequence Diagrams:
Register:
Login:
Book Slot:
Make Payment:
Domain Model:
Class Diagram:
Activity Diagram:
How Different Parts Communicate:
Based on the sequence diagram, when a customer books a service, the app first checks
their login, then looks for available time slots, processes their payment, confirms the
booking, and sends notifications to everyone involved. If something goes wrong (like
payment fails), the system handles it gracefully and shows appropriate messages.
5. Implementation Plan
We'll build this app using an agile approach Scrum, working in small chunks over 10
two-week periods.
Technology choices:
Frontend: Flutter because it works on both Android and iOS
Backend: Dart for the server-side logic
Database: PostgreSQL to store all the data
Payments: Integration with popular payment gateways
Notifications: Push notification services
Development phases: Development phases using Scrum
methodology:
Sprint 1 - 2: Build the login and user management system
Sprint 3 - 4: Add the core booking functionality
Sprint 5 - 6: Integrate payment processing
Sprint 7 - 8: Add notifications and admin features
Sprint 9 - 10: Test everything thoroughly and deploy
Each sprint will include sprint planning, daily stand-up meetings, sprint reviews, and
retrospectives to ensure we stay on track and continuously improve our process. We'll use
modern development tools like Git for version control, automated testing to catch bugs
early, and continuous deployment to make updates smooth.
6. Project Management
Team structure:
Project Manager: Shaheer Ahmed - coordinates everything and manages
timeline
Frontend Developers: M. Abdul Manan and M. Tayyab Khan - build the
Flutter mobile app
Backend Developers: Usman Ali and Jahanzaib Ahmed - develop server logic
and APIs
Quality Assurance & DevOps: Modeel Mehdi - testing, deployment, and
system maintenance
Timeline: Our project will take about 18 weeks total. First 2 weeks for planning, next 4
weeks for design, 10 weeks for development in short sprints, 2 weeks for thorough
testing, and final 2 weeks for deployment and launch.
How we'll track progress: Daily team check-ins, weekly reviews with
stakeholders, monthly progress reports, and continuous monitoring of development
metrics. If we need to make changes, we'll assess the impact, get approval, and adjust our
timeline accordingly.
Risk management: We'll identify potential problems early (like technical challenges
or team availability), create backup plans, and monitor risks throughout the project.
7. Conclusion
Our House Shifting Service Management System will solve real problems that people
face when moving. By creating a simple, reliable app, we'll make the moving process less
stressful for customers and help service providers grow their businesses.
From a software engineering perspective, our project demonstrates modern mobile app
development using Flutter and Dart, shows how to design user-friendly interfaces, and
implements secure payment processing. It's a practical example of how technology can
improve traditional industries.
Our app will benefit society by making moving services more accessible, transparent, and
reliable. Customers will save time and money, service providers will reach more clients,
and the overall moving experience will be much better for everyone involved.
When completed, our project will serve as a model for digitalizing other service
industries and show how good software engineering practices can create solutions that
really help people in their daily lives.
