Software Requirements

Specification
for

Prepared by

Mohamm
ad
Arman
ID:
ASH22
25009
M

Md. Ismail Hossen Shohib

ID: ASH2225012M

Mofassel Alam Maruf

ID: ASH2225014M

Ishrat Mohammad Nahin

ID: MUH2225023M

Institute of Information
 Technology
Noakhali Science and
Technology University
Date: 21-
09-2025
 Software Requirement Specification for “লাঙল”

Table of Contents
Table of Contents..................................................................................................................i
List of Figures.......................................................................................................................v
1. Chapter 1: Project Overview.........................................................................................1
1.1 Project Background.....................................................................................................1
1.2 Problem Statement.......................................................................................................1
1.3 Objectives......................................................................................................................2
1.4 Project Scope................................................................................................................3
1.5 Major Functionalities...................................................................................................4
1.6 Development Tools and Technologies........................................................................5
1.7 References.....................................................................................................................5
2. Chapter 2: Requirement Specification........................................................................7
2.1 Functional Requirement..............................................................................................7
2.1.1 User Registration & Onboarding.............................................................................7
2.1.2 Role-Based Authentication & Access Control........................................................7
2.1.3 User Profile Management........................................................................................8
2.1.4 Crop Recommendation System...............................................................................8
2.1.5 Crop Planning Guideline.........................................................................................9
2.1.6 Diseases Diagnosis System.....................................................................................9
2.1.7 Expert Consultation...............................................................................................10
2.1.8 Social Feed System...............................................................................................10
2.1.9 Weather Forecasting..............................................................................................11
2.1.10Marketplace System..............................................................................................11
2.1.11Market Price Monitoring.......................................................................................11
2.1.12Agricultural News and Policy Updates.................................................................12
2.1.13Expert Service Dashboard.....................................................................................12
2.1.14Crop & Diagnosis Management............................................................................12
2.1.15Profile Verification................................................................................................13
2.1.16Field Data Collection.............................................................................................13
2.1.17Crop Info Verification...........................................................................................13
2.1.18Social Feed Report Management..........................................................................13
2.1.19Data Operator Report Analysis.............................................................................14
2.1.20Administrative Report Review & Export..............................................................14
2.2 Data Requirement.....................................................14
i| 2.2.1 User Information..................................................15
2.2.2 Crop Data..............................................................................................................15
 Software Requirement Specification for “লাঙল”

2.2.3 Soil Data................................................................................................................15

2.2.4 Weather Data.........................................................................................................15
2.2.5 Chemical & Fertilizer Treatment Dose Data.........................................................15
2.2.6 Market Price Data (DAM):....................................................................................16
2.2.7 Expert Consultation Data:.....................................................................................16
2.2.8 Agricultural News & Policy Update:....................................................................16
2.3 Performance Requirement........................................................................................16
2.3.1 System Availability:..............................................................................................17
2.3.2 Response Time:.....................................................................................................17
2.3.3 Scalability:.............................................................................................................17
2.3.4 Data Processing Speed:.........................................................................................17
2.3.5 TTS Advice Playback:...........................................................................................17
2.3.6 Social/Marketplace Publish:..................................................................................18
2.3.7 Media Upload Performance:.................................................................................18
2.3.8 Search Functionality Performance:.......................................................................18
2.3.9 Batch Processing:..................................................................................................18
2.3.10Mobile Optimization:............................................................................................19
2.3.11Error Rate:.............................................................................................................19
2.3.12Operator Summary Dashboard:.............................................................................19
2.4 Security Requirement................................................................................................19
2.4.1 Authentication & Session Security:......................................................................20
2.4.2 Role-Based Data Access:......................................................................................20
2.4.3 Data Encryption:....................................................................................................20
2.4.4 Marketplace & Contact Safety:.............................................................................20
2.4.5 Audit Trail:............................................................................................................20
2.5 Reliability Requirement.............................................................................................21
Reliability requirements ensure the system behaves consistently and fails gracefully, which
matters here because farmers depend on it for time-sensitive decisions (spraying,
harvesting) and rural networks are unreliable.......................................................21
2.5.1 Fault Tolerance:.....................................................................................................21
2.5.2 Data Integrity:........................................................................................................21
2.5.3 Backup & Recovery:.............................................................................................21
2.6 Scalability Requirement............................................................................................21
2.6.1 Horizontal Scalability:...........................................................................................21
2.6.2 Geographic Scalability:.........................................................................................21
2.7 Maintainability Requirement....................................................................................21
2.1.1 Modular Codebase:..............................................22
ii | 2.1.2 Documentation.....................................................22
2.1.3 Testability:.............................................................................................................22
 Software Requirement Specification for “লাঙল”

Chapter 4: Design Model..................................................................................................23

4.1 Architectural Design..................................................................................................23
4.2 Data Design.................................................................................................................24
4.3 Interface Design..........................................................................................................26
4.4 Component Design.....................................................................................................27
4.5 Deployment Design.....................................................................................................28
4.6 Quality Design............................................................................................................30
Chapter 5: Architectural Pattern and Tactics................................................................32
1. Client-Server Pattern...................................................................................................32
2. Layered Pattern............................................................................................................32
3. MVC Pattern................................................................................................................32
4. Event-Driven Pattern...................................................................................................32
Architectural Tactics for Quality Attributes:................................................................33
Chapter 6: Quality Attribute Analysis.............................................................................35
6.1 Performance................................................................................................................35
6.2 Security........................................................................................................................36
6.3 Reliability....................................................................................................................36
6.4 Availability..................................................................................................................37
6.5 Scalability....................................................................................................................37
6.6 Modifiability...............................................................................................................37
6.7 Maintainability...........................................................................................................38
6.8 Usability......................................................................................................................38
Chapter 7: Architecture Views (4+1 View Model).........................................................40
Logical View.....................................................................................................................40
40
Process View.....................................................................................................................41
Sequence Diagram of Register and Verify:.....................................................................41
Sequence Diagram of Recommend Crops:......................................................................44
Sequence Diagram of Diagnose Disease.........................................................................45
Sequence Diagram of Agriculture News:........................................................................46
Sequence Diagram of Expert Consultation:....................................................................47
Sequence Diagram of Social Feed:..................................................................................48
Sequence Diagram of Weather Forecast:........................................................................49
iii | Sequence Diagram of Market Prices Lookup:...............50
Sequence Diagram of Manage Account & Profile:.........................................................51
 Software Requirement Specification for “লাঙল”

Development View............................................................................................................52
Physical View....................................................................................................................53
Scenario View (+1)...........................................................................................................54
Chapter 8: Deployment Architecture..............................................................................55
Deployment Diagram.......................................................................................................55

......................................................................................................................................55
Hardware Environment...................................................................................................56
Software Environment.....................................................................................................57
Network Configuration....................................................................................................58

iv |
 Software Requirement Specification for “লাঙল”

...............................................................................................................................58
Cloud Services..................................................................................................................59

List of Figures
Figure 1:Distribution of Interview Among Stakeholders......................................................................40
Figure 2: Stakeholders proposals for requirement in "লাঙল" project...................................................41
Figure 3: Use Case Diagram..................................................................................................................45
Figure 4: Activity Diagram of profile login...........................................................................................62
Figure 5: Activity Diagram of Crop Recommendation.........................................................................63
Figure 6:Activity Diagram of Request Consultation.............................................................................64
Figure 7:Activity Diagram of Create Social Post..................................................................................65
Figure 8: Activity Diagram of Profile Update.......................................................................................66
Figure 9:Activity Diagram of Diagnose Disease...................................................................................67
Figure 10: Activity Diagram of Authentication.....................................................................................68
Figure 11: Activity Diagram of Verify Profile......................................................................................69
Figure 12:Activity Diagram of Farmer Registration.............................................................................70
Figure 13:Activity Diagram of Verify Crop....................................71
v| Figure 14: Activity Diagram of Collect Field Data.........................72
Figure 15: Activity Diagram of Generate Reports...........................73
Figure 16:Activity Diagram of Diagnose Farmer Request....................................................................74
 Software Requirement Specification for “লাঙল”

Figure 17:Activity Diagram of Create Crop Advice.............................................................................75

Figure 18: Activity Diagram of Buy Crop Activity...............................................................................76
Figure 19: Activity Diagram of View Order History Activity..............................................................77
Figure 20:Activity Diagram of Handle Consultation Farmer Request..................................................78
Figure 21: Activity Diagram of Consultant Registration.......................................................................79
Figure 22: Activity Diagram of Farmer Self Registration.....................................................................80
Figure 23:Activity Diagram of Buy & Rent..........................................................................................81
Figure 24: Activity Diagram of Manage Selling Listing.......................................................................82
Figure 25: Swimlane Diagram of Registration......................................................................................83
Figure 26: Swimlane Diagram of Login Profile....................................................................................84
Figure 27: Swimlane Diagram of Manage Account & Profile..............................................................85
Figure 28:Swimlane Diagram of Recommend Crop.............................................................................86
Figure 29:Swimlane Diagram of Diagnose Disease..............................................................................87
Figure 30:Swimlane Diagram of Weather Forecast..............................................................................88
Figure 31:Swimlane Diagram of Market Prices Lookup.......................................................................89
Figure 32:Swimlane Diagram of Social Feed........................................................................................90
Figure 33: Swimlane Diagram of Data Operator...................................................................................91
Figure 34:Sequence Diagram of Registration........................................................................................92
Figure 34:Sequence Diagram of Registration........................................................................................92
Figure 35:Sequence Diagram of Log Profile.........................................................................................93
Figure 36: Sequence Diagram of Crop Recommendation.....................................................................94
Figure 37:Sequence Diagram of Diagnose Disease...............................................................................95
Figure 38:Sequence Diagram of Agriculture News...............................................................................96
Figure 39:Sequence Diagram of Expert Consultation...........................................................................97
Figure 40: Sequence Diagram of Social Feed.......................................................................................98
Figure 41:Sequence Diagram of Weather Forecast...............................................................................99
Figure 42:Sequence Diagram of Market Prices Lookup.....................................................................100
Figure 44: Database Schema “লাঙল”.................................................................................................102

vi |
 Software Requirement Specification for “লাঙল”

1. Chapter 1: Project Overview

1.1 Project Background

Bangladesh is an agrarian economy where a majority of the rural population depends directly or
indirectly on farming for their livelihood. Despite this, farmers frequently lack timely access to
accurate agricultural information — proper crop selection guidance, disease identification, weather-
based planning, fair market prices, and professional consultation. Traditional extension services
(Upazila Agriculture Officers, Agricultural Extension Workers) are limited in number and cannot
reach every farmer promptly. At the same time, mobile phone penetration among rural populations
has increased sharply, creating an opportunity to bridge this information gap through a digital
platform. Langal was conceived as a mobile-first, Bangla-language digital agriculture assistant that
consolidates disease diagnosis, crop recommendation, weather forecasting, expert consultation,
marketplace, and community knowledge-sharing into a single accessible application.

1.2 Problem Statement

Satement-1:
Many farmers lack quick access to reliable crop, disease, weather, and market price
information. They depend on informal sources. This causes low yield, delayed action,
and financial loss and limited profitability.

Problem description: Farmers often use low end phones with slow internet.
Information is scattered across people, apps, and social groups. Weather data is not
localized enough for timing actions (spray, irrigation). Disease help is delayed due to
unclear photos and no standard process. Market prices are unclear or outdated, so
negotiation is weak. Low literacy and technical terms make advice hard to follow. As
a result, farmers spend more on inputs, miss the right time to act, face pest spread, and
lose profit at sale time.

Specific issues:
 Information fragmentation (no single, trusted source)
 Poor connectivity and low-end devices limit rich media
 Low literacy; need Bengali, icons, and text-to-speech
 Unclear, low-quality photos delay diagnosis
 No case history; farmers repeat mistakes across seasons
 Weather not tied to action windows (spray/irrigation/harvest)
 Market price opacity; limited access to DAM references
 Misinformation in social groups without moderation

1|Page
 Software Requirement Specification for “লাঙল”

Satement-2:
Government and supervisory officers do not get structured, timely field data for
decision-making. Manual verification is slow. There is no unified digital channel for
farmer data, diagnostics, and market insight.

Problem description: Field data arrives through paper, calls, WhatsApp, and ad-hoc
Excel files. It lacks standard fields, geotagging, and timestamps. Verification is
manual and delayed. Upazila officers have limited time and need short summaries, not
raw chats. There is no clear link from expert advice to oversight reports. Market price
feeds and weather alerts are not integrated into one view. Without audit trails and
trend views, early warning and resource allocation are slow.

Specific issues:
 Data scattered across channels; no standard structure
 No geo-tagged evidence; hard to map hotspots or clusters
 Slow, manual verification; duplicates and inconsistencies
 Officers need summaries and simple actions (assign/escalate), not raw detail
 No unified link between expert cases, advisories, and operator reports
 Infrequent or non-transparent “last updated” for DAM prices
 Limited audit trail; hard to trace who did what, when
 Connectivity constraints at offices; need lightweight, low-notification portal

1.3 Objectives

 To provide farmers with an AI-assisted crop disease diagnosis system using image upload.
 To recommend suitable, profitable crops based on location, soil, and seasonal data.
 To deliver real-time and 7-day weather forecasts to support agricultural planning.
 To connect farmers with verified agricultural experts through chat, voice, and video
consultation.
 To create a marketplace where farmers and customers can buy, sell, and rent agricultural
products and equipment.
 To keep farmers informed through agricultural news, government policy updates, and market
price monitoring.
 To build a social feed where farmers can share experiences and learn from the community.
 To make the system accessible to low-literacy users through Bangla text-to-speech (TTS).
 To provide Data Operators and administrators the ability to verify user profiles, moderate
content, and generate structured reports for government/administrative review.

2|Page
 Software Requirement Specification for “লাঙল”

1.4 Project Scope

In Scope (Farmer App):

 Farmers registration & authentication.

 Profile: crops, location (union/upazila), contact preferences, consent.
 Disease submission: text + photos, auto-compress, guided prompts; expert
reply in Bengali with icons and TTS.
 Crop recommendation: simple rule/curated lists by season/region;
disclaimers.
 Weather: 3–7-day forecast.
 Marketplace: create/edit listings (crop/variety, price/unit, quantity, harvest
date, photos); direct contact only with disclaimer; verified farmer badge.
 Market prices: DAM feed with market selector, timestamp, fallback state.
 News: curated agricultural news, source attribution.
 Social feed: posts, images, comments, report/flag, basic moderation.
 Expert consultation system

In Scope (Data Operator Portal):

 Verification queue: flagged registrations/data with Approve/Return/Reject

and short note.
 Summaries: area snapshot (top issues, advisories, trends), “last updated”
time.
 Escalation: send to higher authority with minimal fields; track status.
 Reports: per-case and area summary (PDF/CSV), searchable by
date/union.
 Notifications: only high/critical; configurable cadence.
 Audit: view action history (who/what/when); read-only access to expert
outputs (no chat).

3|Page
 Software Requirement Specification for “লাঙল”

1.5 Major Functionalities

Langal brings together a wide range of functionality under one platform, spanning every stage of a
farmer's agricultural journey as well as the supporting roles (Expert, Customer, Data Operator,
Administrator) that make the ecosystem work. The major functionalities are described below.
 User Registration & Role-Based Access — Separate registration and authentication flows
for Farmer, Expert, Customer, and Data Operator roles, each with role-appropriate
onboarding fields and dashboard access.
 Disease Diagnosis — AI-powered crop disease identification from an uploaded photo,
returning probability scores for each possible disease along with detailed treatment plans.
 Crop Recommendation — Suggests profitable, season- and location-appropriate crops,
complete with cultivation planning guidance and a profitability breakdown.
 Expert Consultation — Chat, voice, and video consultation with agricultural experts,
including appointment scheduling and expert availability management.
 Weather Forecasting — Current conditions and a 7-day forecast to support farm planning
decisions such as irrigation and harvesting.
 Marketplace — Buy, sell, and rent agricultural products, seeds, fertilizer, and equipment
directly between farmers and customers.
 Market Price Monitoring — Real-time and comparative crop price information across
markets to help farmers make informed selling decisions.
 Agricultural News & Policy Updates — A news feed covering agricultural policy changes
and government schemes relevant to farmers.
 Social Feed — Community posting, commenting, liking, and content reporting, allowing
farmers to share experiences and learn from each other.
 Field Data Collection — Data Operators record field-level soil, crop, and verification data
via digital forms while visiting farmers in person.
 Profile & Crop Info Verification — Data Operators verify new user identities and
crop/field submissions, building trust across the platform.
 Reporting & Export — Administrators generate and export usage and analytical reports as
PDF or CSV files.
 Text-to-Speech (TTS) — Bangla voice narration of posts, news, and advice, specifically
supporting low-literacy users.
 Notifications — Push and in-app notifications for crop reminders, consultation updates, and
moderation actions.
4|Page
 Software Requirement Specification for “লাঙল”

1.6 Development Tools and Technologies

 The project was built using a modern, pragmatic technology stack chosen to support rapid
development by a small team while still meeting the system's performance, portability, and
reliability requirements.
 Frontend and Mobile
 React 18 with TypeScript, built using Vite, styled with Tailwind CSS and shadcn/ui (Radix
UI primitives) for accessible, consistent components.
 Capacitor wraps the same React web build into a native Android application, avoiding a
separate mobile codebase.
 React Context API and TanStack Query (react-query) manage application and server state,
with Axios handling HTTP communication.
 Backend and Database
 Laravel 12 (PHP 8.2) powers a RESTful API architecture with roughly 212 routes grouped
by domain.
 Laravel Sanctum provides token-based authentication, complemented by OTP verification
during onboarding.
 MySQL is the primary data store, with a dedicated database-views layer of SQL views
supporting aggregated and reporting queries.
 External Services and Infrastructure
 Azure Blob Storage (accessed through a Flysystem adapter) handles file and media storage.
 Agora RTC SDK provides real-time voice and video communication for expert consultation
calls.
 Firebase Cloud Messaging (FCM) delivers push notifications to farmer and expert devices.
 Hugging Face models power disease diagnosis and Bangla text-to-speech, alongside Google's
Generative AI SDK for crop recommendation analysis.
 jsPDF and jsPDF-AutoTable generate client-side PDF reports, with XLSX export also
supported for administrative reporting.
 Development and Deployment
 GitHub Actions drives the CI/CD pipeline, deploying the frontend automatically to GitHub
Pages on every merge to the main branch.
 The backend is deployed separately on a PHP-compatible hosting platform (a Procfile in the
repository indicates a platform-as-a-service style deployment).
 Git and GitHub are used for version control and collaboration across the team

1.7 References

Standards and textbooks:

 IEEE Std 830-1998: IEEE Recommended Practice for Software

Requirements Specifications
 ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life
cycle processes — Requirements engineering
 Ian Sommerville, Software Engineering (9th ed.), Pearson
5|Page
 Software Requirement Specification for “লাঙল”

 Klaus Pohl, Requirements Engineering: Fundamentals, Principles, and

Techniques, Springer
 Abraham Silberschatz, Henry F. Korth, S. Sudarshan, Database System
Concepts (6th ed.), McGraw-Hill

Domain and data sources (Bangladesh):

 Department of Agricultural Marketing (DAM) — market price

bulletins: [Link]
 Bangladesh Meteorological Department (BMD) — forecasts and
warnings: [Link]
 Department of Agricultural Extension (DAE) — advisories and crop
guides: [Link]
 National Open Data Portal (Bangladesh): [Link]

International guidance:

 FAO — Integrated Pest Management (IPM)

resources: [Link]
 CABI Plantwise Knowledge
Bank: [Link]

APIs and developer docs:

 OpenWeatherMap API (weather): [Link]

 Firebase Cloud Messaging (push
notifications): [Link]
 Twilio (SMS/OTP): [Link]
 OpenStreetMap & Nominatim
(maps/geocoding): [Link] and [Link]
org

6|Page
 Software Requirement Specification for “লাঙল”

[Link] 2: Requirement Specification

All the requirements based on the elicitation process are described in this section.

2.1 Functional Requirement

Functional requirements are specifications that describe the system's functions or

capabilities from a user's perspective. They outline what the system should do and
how it should behave under specific conditions. Functional requirements are
typically expressed as actions or tasks that the system must perform, and they are
crucial for defining the system's behavior and determining its success in meeting
user needs.

2.1.1 User Registration & Onboarding

FR 1: Users can create an account with their role-specific information.

Description The system shall allow farmers, experts, customers, and data operators to
register with role-specific information and document verification to create
secure user accounts.

Stakeholders All new users. Priority High

FR 2: Users can log in to their account.

Description Registered users must be able to securely log in to the application

using their phone number/email & password. OTP system must be
there.
Stakeholders All registered users. Priority High

FR 3: New users get a simple onboarding tour.

Description Upon first login, new users will be shown a brief, guided tour
explaining the main features of the app.
Stakeholders All new users. Priority Medium

2.1.2 Role-Based Authentication & Access Control

FR 4: The system assigns a role to each user.

Description Every user is assigned a specific role (Farmer, Expert, Customer, Data

7|Page
 Software Requirement Specification for “লাঙল”

Operator) which defines their identity in the system.

Stakeholders All users. Priority High

FR 5: Users can only access features permitted for their role.

Description The system must restrict access to certain dashboards, data, and
functionalities based on the user's assigned role. For example, a Data
Operator cannot access the Expert's dashboard.
Stakeholders All users. Priority High

2.1.3 User Profile Management

FR 6: Users can view and edit their profile information.

Description Users must be able to see their profile details and edit information such
as their name, location, and profile picture.
Stakeholders All users. Priority Medium

FR 7: Users can change their password.

Description For security, users must have the ability to change their account
password from their profile settings.
Stakeholders All users. Priority Medium

2.1.4 Crop Recommendation System

FR 8: Farmers can input cultivation parameters for recommendations.

Description The system will allow farmers to enter data such as their location,
season, and land size to get personalized crop suggestions.
Stakeholders Farmers. Priority High

FR 9: An AI model analyzes inputs to recommend suitable crops.

Description The system's AI model will process the farmer's input parameters to
generate a list of the most suitable crops.
Stakeholders Farmers. Priority High

FR 10: Each recommendation includes a detailed profit and cost analysis.

Description For each suggested crop, the system will provide a breakdown of the
estimated cultivation cost, potential yield, market price, and expected
profit. Also filter according to their choice.

8|Page
 Software Requirement Specification for “লাঙল”

Stakeholders Farmers. Priority High

2.1.5 Crop Planning Guideline

FR 11: Farmers can get a step-by-step guide for crop cultivation.

Description For a chosen crop, the system provides a simple, sequential guide
covering all stages from planting to harvesting.
Stakeholders Farmers. Priority Medium

FR 12: The guide includes a schedule for farming activities with notifications.
Description The system provides a calendar or timeline that reminds farmers about
important activities like planting, watering, and fertilizing.
Stakeholders Farmers. Priority Low

2.1.6 Diseases Diagnosis System

FR 13: Farmers can upload a crop photo for AI-powered diagnosis.

Description Users can upload an image of an affected plant. The AI model will analyze
the image to identify potential diseases.
Stakeholders Farmers. Priority High

FR 14: The system provides a list of possible diseases with probability scores.

Description After analysis, the system presents a list of potential diseases, each with a
confidence score (probability) to indicate the likelihood of the diagnosis.
Stakeholders Farmers, Experts. Priority High

FR 15: The system suggests detailed treatment plans for each disease.
9|Page
 Software Requirement Specification for “লাঙল”

Description For each identified disease, the system provides information on

treatment options, including recommended chemicals, application
dosage, and estimated costs.
Stakeholders Farmers, Experts. Priority High

FR 16: Farmers can view their past diagnosis history.

Description The system saves all previous diagnoses, allowing farmers to track
recurring crop health issues over time.
Stakeholders Farmers. Priority Low

10 | P a g e
 Software Requirement Specification for “লাঙল”

2.1.7 Expert Consultation

FR 17: Users can find and view a list of available experts.

Description The system displays a list of agricultural experts, showing their

specialization and availability.
Stakeholders Farmers, Customers. Priority High

FR 18: Users can start a message with an expert.

Description The system allows users to initiate a real-time conversation with an

expert to get personalized advice.
Stakeholders Farmers, Experts. Priority High

FR 19: Users can schedule an appointment with an expert.

Description Users can book a consultation with an expert for a future date and time.

Stakeholders Farmers, Experts. Priority Medium

2.1.8 Social Feed System

FR 20: Users can create and share posts with text and images.
Description Users can publish their own content, including text updates and
photos, to the community social feed.
Stakeholders Farmers, Customers, Experts. Priority Medium

FR 21: Users can view a feed of posts from others.

Description The system displays a scrollable feed of posts created by other members
of the community.
Stakeholders Farmers, Customers, Experts. Priority Medium

FR 22: Users can comment on and like posts.

Description To encourage interaction, users can leave comments and "like" posts on the
social feed.
Stakeholders Farmers, Customers, Experts. Priority Medium

11 | P a g e
 Software Requirement Specification for “লাঙল”

2.1.9 Weather Forecasting

FR 23: Users can see the weather forecast for their location.

Description The system provides current and future weather information, including
temperature, rainfall, and humidity, for the user's area.
Stakeholders Farmers, Experts, Data Operators Priority High

FR 24: The system provides a 7-day weather forecast.

Description Users can view a forecast for the upcoming week to help them plan
their agricultural activities in advance.
Stakeholders Farmers. Priority Medium

2.1.10 Marketplace System

FR 25: Farmers and Customers can list their agricultural products for sale and rent.

Description Farmers can create listings for their products, including details like price,
quantity, and photos.
Stakeholders Farmers, Customers Priority High

FR 26: Both can browse and search for products basis on their demands.

Description Both can view all available products in the marketplace and use a
search or filter function to find specific items.
Stakeholders Customers, Farmers Priority Medium

FR 27: Both can purchase or renting products or tools through the app.
Description The system must provide contact information of customers and farmer
to buy and rent face to face.
Stakeholders Customers, Farmers Priority High

2.1.11 Market Price Monitoring

FR 28: Market prices monitor and display updated price information

Description The system shall display real-time market prices and comparative pricing
across different markets to help users make informed trading decisions.
Stakeholders Farmers, Customers Priority Low

12 | P a g e
 Software Requirement Specification for “লাঙল”

2.1.12 Agricultural News and Policy Updates

FR 29: The system displays a feed of agricultural news.

Description Users can read recent articles and updates related to the agriculture
sector.
Stakeholders All users. Priority Medium

FR 30: The system provides information on new government policies.

Description The app informs users about new or updated government policies
and schemes relevant to farmers.
Stakeholders All users. Priority Medium

2.1.13 Expert Service Dashboard

FR 31: Experts can view and manage consultation requests.

Description Experts have a dashboard where they can see all incoming
consultation requests and accept or decline them.
Stakeholders Experts. Priority High

FR 32: Experts can manage their appointment schedule.

Description The dashboard allows experts to set their availability and view their
calendar of scheduled appointments.
Stakeholders Experts. Priority High

2.1.14 Crop & Diagnosis Management

FR 33: Manage crop and diagnosis records efficiently

Description The system shall allow experts to review farmer submissions,

provide diagnosis, and manage crop-related consultations to
deliver professional agricultural services
Stakeholders Experts, Farmers Priority Medium

13 | P a g e
 Software Requirement Specification for “লাঙল”

2.1.15 Profile Verification

FR 34: Data operators can review and verify new user profiles.

Description Data operators are responsible for checking the documents and
information provided by new Farmers and Experts to verify their
identity.
Stakeholders Data Operators, Farmers, Priority High
Experts.

FR 35: Verified users get a "verified" badge on their profile.

Description Once a user's profile is successfully verified, a badge will appear on

their profile to build trust within the community.
Stakeholders All users. Priority Medium

2.1.16 Field Data Collection

FR 36: Data operators can input field data using a form.

Description Data operators can use a digital form in the app to record data
collected from the field, such as soil test results and crop conditions.
Stakeholders Data Operators Priority High

2.1.17 Crop Info Verification

FR 37: Verify crop information submitted by users

Description The system shall enable data operators to verify crop information,
yields, and agricultural data accuracy
Stakeholders Data Operators Priority High

2.1.18 Social Feed Report Management

FR 38: Users can report inappropriate posts or comments.

Description Users must have an option to flag content on the social feed that they
believe is harmful, spam, or inappropriate.
Stakeholders Farmers, Experts, Customers Priority Medium

14 | P a g e
 Software Requirement Specification for “লাঙল”

FR 39: Data Operator can review and take action on reported content.

Description Data Operators have a dashboard to see all reported content and can
decide whether to remove the content or warn the user.
Stakeholders Data Operators Priority High

2.1.19 Data Operator Report Analysis

FR 40: Allow data operators to perform report analysis.

Description The system shall enable data operators to aggregate farmer &
crop datasets, validate and analyze trends, and prepare structured
analytical reports for government/administrative review
Stakeholders Data Operators Priority High

2.1.20 Administrative Report Review & Export

FR 41: Admins can generate reports on system usage.

Description Admins can create report on various activity like farmer data, crop
data etc.
Stakeholders Govt. Administration Priority Medium

FR 42: Admins can export reports as PDF or CSV files.

Description The system allows administrators to download the generated reports in

standard file formats for offline analysis or record-keeping.
Stakeholders Govt. Administration Priority Medium

2.2Data Requirement

Data requirements define the critical agricultural, user, operational, and analytical
information that the “লাঙল” must capture, validate, store, relate, and deliver to
support its core services. They ensure the system effectively serves farmers,
agricultural experts, customers (buyers), data operators, and administrators by
enabling: verified user onboarding, crop recommendation, disease diagnosis,
expert consultation, weather-informed planning, marketplace transactions, market
price tracking, social engagement, field data validation, and structured reporting
for administrative/government review. Properly structured data underpins accurate
recommendations, trustworthy analysis, secure role-based access, and transparent
15 | P a g e
 Software Requirement Specification for “লাঙল”

decision-making across the agricultural ecosystem.

2.2.1 User Information

Description: Basic details about each user: name, role (farmer, expert, buyer,
operator, admin), contact, location, and verification status. This helps manage
accounts, control access, and send the right updates. Accurate user data builds
trust and keeps the platform secure.
Stakeholders: Farmers, Experts, Data Operators, Customers.
Priority: High

2.2.2 Crop Data

Description: Information about the crops farmers is growing: crop type, variety,
planting and harvest dates, growth stage, and expected yield. This helps farmers
plan better and lets experts give timely advice. It also connects with weather, soil,
and disease insights.
Stakeholders: Farmers, Experts, Data Operators.
Priority: High

2.2.3 Soil Data

Description: Information about different soil types, including pH levels,

nutrient composition, and overall soil health. This data supports farmers in
making decisions about soil treatment and crop suitability, and helps experts
offer precise soil management advice.
Stakeholders: Farmers, Agricultural Experts, Data Operators
Priority: High

2.2.4 Weather Data

Description: Historical and real-time weather information, covering temperature,

rainfall, humidity, and forecasts. Access to accurate weather data enables farmers
to plan their agricultural activities, mitigate risks, and optimize crop yields by
responding to weather changes promptly.
Stakeholders: Farmers, Data Operators
Priority: Medium

2.2.5 Chemical & Fertilizer Treatment Dose Data

Description: Information about the chemicals and fertilizers applied to crops:

product name, purpose (disease, pest, nutrition), recommended dose, actual dose
used, application method, timing, safety and who applied it. Helps ensure correct
usage, traceability, compliance, and better advisory recommendations. Supports
16 | P a g e
 Software Requirement Specification for “লাঙল”

tracking what worked and avoiding overuse or unsafe residues.

Stakeholders: Farmers, Experts, Data Operators.
Priority: High

2.2.6 Market Price Data (DAM):

Description: Daily prices for crops in different markets, including minimum,

maximum, and common prices. This helps farmers decide where and when to sell
and gives buyers fair visibility. Historical trends support better planning.
Stakeholders: Farmers, Customers
Priority: Medium

2.2.7 Expert Consultation Data:

Description: Information on consultations provided by agricultural experts,

including the type of advice given, follow-up recommendations, and farmer
feedback. This data facilitates continuous improvement of expert services and
ensures farmers receive relevant and effective guidance.
Stakeholders: Farmers, Agricultural Experts
Priority: Medium

2.2.8 Agricultural News & Policy Update:

Description: Information on the latest agricultural news, trends, and updates.

Providing users with current news helps them stay informed about market trends,
policy changes, and new agricultural practices.
Stakeholders: Farmers, Agricultural Experts, Customers
Priority: Low

2.3 Performance Requirement

Performance requirements specify how well the system should respond in terms
of speed, throughput, and resource utilization. They define criteria for the
system's responsiveness, scalability, and efficiency under varying conditions.
These requirements ensure that the system can handle the expected workload
without degradation in performance and meet user expectations for speed and
reliability.

17 | P a g e
 Software Requirement Specification for “লাঙল”

2.3.1 System Availability:

Description: The system should be available 99.5% of the time to ensure access
for farmers, experts, buyers, and operators, considering rural connectivity
constraints.

Stakeholders: All users

Priority: High

2.3.2 Response Time:

Description: Common actions (open dashboard, search, view case/listing, submit

forms) should complete in under 2 seconds under normal conditions.

Stakeholders: All users

Priority: High

2.3.3 Scalability:

Description: The system should scale during seasonal peaks to support up to 500
concurrent active users and bursts of 50 requests/second for 60 seconds without
breaching response targets.

Stakeholders: Platform Administrators, All users

Priority: High

2.3.4 Data Processing Speed:

Description: User-facing updates (cases, advice, listings) should appear in real-

time or within 5 seconds for aggregated views (summaries, lists).

Stakeholders: Farmers, Customers, Experts, Data Operators

Priority: High

2.3.5 TTS Advice Playback:

Description: Description: Bengali TTS becomes available within 2 seconds after

advice is sent and plays without stutter on baseline devices.

Stakeholders: Farmers

Priority: High

18 | P a g e
 Software Requirement Specification for “লাঙল”

2.3.6 Social/Marketplace Publish:

Description: New post/listing appears to the author within 1 second and to others
within 5 seconds; reported content soft-hidden within 5 minutes.

Stakeholders: Farmers, Customers, Experts

Priority: Medium

2.3.7 Media Upload Performance:

Description: Photos are auto-compressed on-device to a compact, network-

friendly size. A single photo should upload in a few seconds over typical mobile
connectivity, and a standard case should confirm shortly after. Uploads run in the
background, support pause/resume after network interruptions, show clear
progress, and retry automatically when needed.

Stakeholders: Farmers, Experts, Customers

Priority: High

2.3.8 Search Functionality Performance:

Description: Search and filtered results (crops, listings, cases) should return
within 2 seconds under normal load. For slower networks, show incremental
results as available.
Stakeholders: All users

Priority: High

2.3.9 Batch Processing:

Description: Bulk jobs (imports/exports, area summaries) complete within a

reasonable processing window. Show progress, support resumable operations, and
produce partial results were safe.
Stakeholders: Administrators, Data Operators

Priority: Medium

19 | P a g e
 Software Requirement Specification for “লাঙল”

2.3.10 Mobile Optimization:

Description: Primary screens load quickly on low-end Android devices. Lists

scroll smoothly, memory use remains modest, and interactions are responsive even
on limited networks.
Stakeholders: Farmers, Customers, Experts

Priority: High

2.3.11 Error Rate:

Description: Core operations have low failure rates. The system retries transient
errors automatically and shows friendly, actionable messages if user action is
needed.

Stakeholders: All users

Priority: High

2.3.12 Operator Summary Dashboard:

Description: The regional summary renders quickly, and switching filters or

pages feels immediate. Heavy queries are cached to keep the UI responsive.
Stakeholders: Upazila Agriculture Officer (admin), Data Operators

Priority: High

2.4 Security Requirement

Security requirements define how the system protects user data, prevents unauthorized access, and
maintains trust across four different user roles (Farmer, Expert, Customer, Data Operator) that each
hold sensitive information.

20 | P a g e
 Software Requirement Specification for “লাঙল”

2.4.1 Authentication & Session Security:

Description: All logins must use OTP-verified phone/email and password, with hashed (not plain-
text) password storage and expiring session tokens (e.g., Sanctum tokens).
Stakeholders: All users
Priority: High

2.4.2 Role-Based Data Access:

Description: The system shall enforce RBAC so a user can never view or modify data outside their role's
scope (e.g., a Data Operator cannot open an Expert's chat; a Farmer cannot see another farmer's private
diagnosis history).
Stakeholders: All users
Priority: High

2.4.3 Data Encryption:

Description: Personal data, location, and uploaded photos shall be encrypted in transit (HTTPS/TLS) and at
rest (Azure Blob Storage encryption) to prevent interception or leakage.
Stakeholders: All users
Priority: High

2.4.4 Marketplace & Contact Safety:

Description: Since payments happen outside the app, the system shall not store payment credentials;
it shall only expose verified contact info (Call/SMS/WhatsApp) with a clear disclaimer, and allow
reporting of suspicious listings.
Stakeholders: Farmers, Customers
Priority: High

2.4.5 Audit Trail:

Description: All Data Operator actions (approve/return/reject/escalate) must be logged with user ID and
timestamp, and cannot be altered or deleted after the fact.
Stakeholders: Data Operators, Upazila Agriculture Officer
Priority: Medium

21 | P a g e
 Software Requirement Specification for লাঙল”

2.5 Reliability Requirement

Reliability requirements ensure the system behaves consistently and fails gracefully, which matters
here because farmers depend on it for time-sensitive decisions (spraying, harvesting) and rural
networks are unreliable

2.5.1 Fault Tolerance:

Description: If an external feed (DAM price, BMD weather) is unavailable, the system shall show
the last cached value with a "last updated" timestamp instead of an error or blank screen.
Stakeholders: Farmers, Data Operators
Priority: High

2.5.2 Data Integrity:

Description: A submitted case, listing, or report shall never be silently lost; failed submissions must be retried
or saved as a local draft until successfully synced.
Stakeholders: Farmers, Experts
Priority: High

2.5.3 Backup & Recovery:

Description: All production data (cases, users, listings, reports) shall be backed up daily, with recovery
possible within 4 hours of a failure.
Stakeholders: Platform Administrators
Priority: Medium

2.6 Scalability Requirement

Scalability requirements ensure the system can grow from a pilot region to nationwide use without
redesign, since agricultural usage is seasonal and geographically expanding.

2.6.1 Horizontal Scalability:

Description: The Laravel backend and database shall support horizontal scaling (additional server
instances) to accommodate growth beyond the initial 500 concurrent-user target.
Stakeholders: Platform Administrators
Priority: Medium

2.6.2 Geographic Scalability:

Description: The system's location model (union/upazila tagging) shall support onboarding of new
districts/regions without schema changes.
Stakeholders: Data Operators, DAM
Priority: Medium

2.7 Maintainability Requirement

22 | P a g e
 Software Requirement Specification for লাঙল”

Maintainability requirements ensure the codebase can be safely updated by a small student/dev
team over time, and that new features (e.g., new crop models) can be added without breaking
existing ones.
2.1.1 Modular Codebase:

Description: Frontend (React components) and backend (Laravel controllers/services) shall

follow a modular, role-separated structure so a change to one feature (e.g., marketplace) does not
require touching unrelated modules (e.g., weather).
Stakeholders: Development Team
Priority: Medium

2.1.2 Documentation

Description: Setup, deployment, and API behavior shall be documented (as already started in the
repo's guide files) and kept current with each major change.
Stakeholders: Development Team
Priority: Medium

2.1.3 Testability:

Description: Core backend logic (auth, verification workflow, price feed) shall have automated tests
(Feature/Unit) to catch regressions before deployment.
Stakeholders: Development Team
Priority: Medium

23 | P a g e
 Software Requirement Specification for লাঙল”

Chapter 4: Design Model

4.1 Architectural Design

Theoretical Background: Architectural design defines the high-level structure of a system — how
it is divided into major subsystems, how those subsystems communicate, and what architectural style
governs their interaction. It answers the question "what are the big pieces, and how do they talk to
each other?" before any single feature is considered. A good architectural design provides a stable
skeleton onto which data, interface, and component design can later be attached, and it directly
shapes non-functional qualities like scalability, maintainability, and fault isolation.

Role in This Project: In this system, the architectural design separates the concerns of presentation
(what the user sees and interacts with), application logic (rules, workflows, validation), data
persistence (long-term storage), and third-party capability (functions the system does not implement
itself but delegates to specialized external providers). This separation exists because the project
serves four very different user roles (farmer, expert, customer, government officer) from one shared
client, while the actual business logic and data must remain centralized, consistent, and auditable on
the server side.

Design Decisions Made:

 Two-tier client-server split: The user-facing application (web and mobile) is kept completely
separate from the server that owns the business rules and the database. The client never talks
to the database directly; every interaction goes through a defined API boundary. This
decision was made so the same server can serve a browser-based interface and a packaged
mobile app without duplicating logic.
 Layered backend (presentation-of-API → business logic → data access): Within the server,
incoming requests pass through a request-handling layer (parsing and validating what came
in), then a business-logic layer (deciding what should happen), and finally a data-access layer
(reading/writing persistent storage). No layer is allowed to skip past the one below it — for
example, request handling never queries the database directly; it always goes through the
logic layer first. This was chosen so that business rules (like how a diagnosis case is verified,
or how a marketplace listing is approved) live in one place and can be reused or tested
independently of how the request arrived.
 Broker-based integration for specialized external capabilities: Rather than building real-time
video/voice infrastructure, push-notification delivery, AI-based text-to-speech, or scalable
media storage from scratch, the architecture delegates each of these to a dedicated external
service and only keeps a thin coordinating layer internally. This was a deliberate trade-off:
building and operating that infrastructure in-house was judged not worth the effort for a
project at this scale, so the architecture treats these as pluggable external dependencies rather
than core system responsibilities.
 Shared client for multiple roles instead of separate apps per role: One frontend codebase
renders different views and permissions depending on who is logged in, rather than
24 | P a g e
 Software Requirement Specification for লাঙল”

maintaining four independent applications (one per role). This reduces duplication but means
the client must carry logic for all roles even though a single user only ever exercises one
role's path.
 Independent deployability of client and server: The client is built as a static, deployable
artifact separate from the server, which is deployed as its own long-running service. This
allows the two to be updated, scaled, or restarted independently of each other.

Possible Improvements:

 No API versioning strategy: All endpoints currently sit under a single, unversioned path. As
the system evolves (and it clearly is evolving quickly, given the number of features already
added), a breaking change to one endpoint could silently break the mobile app if it isn't
updated in lockstep. Introducing versioned endpoints would decouple client and server
release cycles more safely.
 The business-logic layer is not uniformly applied: Some simple, low-risk endpoints appear to
skip the logic layer and go straight from request handling to persistence, while more complex
features do route through it properly. This inconsistency means the "layered" rule is a
convention, not something structurally enforced — over time this tends to erode as more
shortcuts get added under time pressure.
 No API gateway or rate-limiting layer in front of the server: Since the same backend must
serve a large number of low-connectivity mobile clients, an intermediate gateway (for rate
limiting, request throttling, and centralized logging) would protect the core server from retry
storms caused by poor rural connectivity, rather than each client naively retrying against the
origin server.
 Tight coupling to specific external providers: Because broker integrations are called directly
rather than through an internal abstraction/interface, switching providers later (e.g., a
different video-calling service or a different notification provider) would require touching
business logic in multiple places rather than swapping one adapter.
 No formal architectural decision record (ADR) process: The reasoning behind major
structural choices (why a broker was chosen over building the capability, why the client is
shared across roles) currently lives only in informal documentation rather than a structured,
versioned decision log — making it harder for future contributors to understand why the
architecture looks the way it does, not just what it looks like.

4.2 Data Design

Theoretical Background: Data design concerns how information is structured, related, and stored
so that it remains accurate, non-redundant, and efficiently retrievable. It covers entity identification,
relationships between entities, normalization, and the choice of storage technology. Good data design
prevents inconsistency (the same fact stored two different ways in two places) and directly
determines how well the system can answer real queries under load.

Role in This Project: The system centers on a relational data model because most of its information
is inherently structured and relationship-heavy: a user has one role-specific profile, a diagnosis case
25 | P a g e
 Software Requirement Specification for লাঙল”

belongs to a farmer and may be reviewed by an expert, a marketplace listing belongs to a seller, and
a consultation involves an appointment, messages, and possibly a prescription. These are naturally
expressed as rows with foreign-key relationships rather than loosely structured documents, which is
why a relational database was the appropriate choice here rather than a NoSQL store.

Design Decisions Made:

 Role-based entity separation instead of one generic "user" table with a type flag: Each role
(farmer, expert, customer, government operator) has its own profile entity linked back to a
core account entity, rather than cramming all role-specific fields into a single wide table. This
keeps each role's data cohesive and avoids a table full of columns that are only meaningful
for some rows.
 Normalized many-to-one relationships for domain data: Cases, listings, appointments, and
messages are each modeled as their own entity with a foreign key back to the user who
created them, rather than duplicating user details onto every record. This is standard
normalization and avoids update anomalies (e.g., a user changing their phone number would
otherwise require updating it in dozens of places).
 Separate entities for workflow state versus core data: Verification/approval status,
notification queues, and audit-relevant actions are modeled as distinct records tied to the core
entity they describe, rather than being flattened into a single status column with no history.
This preserves a trail of what happened over time, which matters for a system with a
government-facing oversight role.
 External reference data is not duplicated locally: Time-sensitive data owned by outside
authorities (market prices, weather) is fetched and cached with a freshness timestamp rather
than being copied into the core schema as if it were locally-owned truth. This reflects a
correct judgment that the system is a consumer of that data, not its source of record.
 Media (photos, voice notes) is referenced, not stored in the relational database: Records store
a pointer/reference to externally-stored media rather than embedding binary data in database
rows, keeping the relational store lean and query-efficient.

Possible Improvements:

 Soft-delete / archival strategy is not consistently visible: For a system with legal/oversight
relevance (government verification, marketplace disputes), permanently and silently deleting
records is risky; a consistent "mark as inactive, keep for audit" pattern across all sensitive
entities would be safer than deleting rows outright.
 No explicit data retention or anonymization policy at the schema level: Since farmer location,
phone numbers, and photos are personal data, the schema doesn't appear to distinguish "data
that must be retained for audit" from "data that should be anonymizable/removable on
request" — this becomes a compliance gap as the system scales.
 Some workflow states are likely represented as plain string/enum columns rather than a
proper state entity with transition history: A single "status" field tells you what the current
state is but not when or why it changed — a more auditable design would log each transition
as its own record, which matters heavily for the verification-heavy government portal.
26 | P a g e
 Software Requirement Specification for লাঙল”

 Indexing strategy is not evident from the schema alone: Location-based queries (finding
cases/listings near a union/upazila) and date-range queries (reports, statistics) benefit heavily
from composite indexes; without seeing explicit index definitions, this is a likely
performance blind spot as data volume grows.
 Cross-role data isolation relies on the application layer, not database-level constraints:
Whether a data operator can see farmer PII is enforced in code (role checks) rather than at the
database boundary — a determined bug in one query could leak data across role boundaries
with nothing at the storage layer to catch it.

4.3 Interface Design

Theoretical Background: Interface design covers two related concerns: the human interface (how a
user interacts with the system — screens, navigation, feedback) and the system interface (how
software components exchange data with each other — API contracts, request/response formats,
error conventions). Good interface design makes both predictable: a user should not be surprised by
what a screen does, and a client should not be surprised by what an API returns.

Role in This Project: Because the target users include low-literacy farmers on low-end devices and
government officers who need fast, no-nonsense review screens, the human interface has to serve
two very different usability profiles from the same design system. On the system side, the interface is
the single REST API boundary through which the shared frontend, and potentially other future
clients, communicate with the backend — so its consistency directly determines how easy the system
is to extend.

Design Decisions Made:

 REST-style resource-oriented API: Endpoints are organized around nouns (resources such as
cases, listings, appointments, notifications) with role-prefixed grouping, rather than an RPC-
style "one endpoint per action" approach. This makes the API's shape predictable and easier
to document.
 Separate request-validation objects from controllers: Incoming data is validated through
dedicated request-validation definitions rather than inline validation scattered in each handler,
which keeps validation rules explicit, reusable, and easy to audit for correctness.
 Dedicated response-shaping objects instead of returning raw database records: Outgoing data
is passed through transformation objects before being sent to the client, so internal database
structure is not directly exposed and can change without necessarily breaking the client
contract.
 Token-based authentication carried on every request: Rather than server-side sessions, the
client attaches an authentication token to each API call, which is what allows the same
backend to serve both a browser client and a packaged mobile client without cookie-related
complications.
 Bengali-first, icon-supported human interface: Screens for farmer-facing roles default to
Bengali text paired with icons and audio playback, while the government-facing interface
favors compact summaries and single-action buttons (approve/return/reject) — reflecting two
27 | P a g e
 Software Requirement Specification for লাঙল”

deliberately different interface philosophies for two different literacy/time-pressure profiles

within one design system.
 Graceful degradation for offline/low-connectivity states: Interface elements are designed to
show cached or last-known data with a visible "last updated" indicator rather than blank or
broken screens when connectivity drops, which was a direct response to the rural-
connectivity assumption stated early in the requirements.

Possible Improvements:

 No formally published API contract/schema: There does not appear to be a machine-readable

API specification (such as an OpenAPI/Swagger document) — the contract currently lives
implicitly in the code. This makes onboarding new frontend developers, or building a second
client in the future, harder than it needs to be.
 Inconsistent error-response shape across endpoints: Some endpoints appear to return
validation errors in a different shape than general failure errors, which forces the client to
handle multiple error formats instead of one predictable envelope.
 No pagination convention enforced uniformly: List-returning endpoints (cases, listings,
notifications) would benefit from a single, consistently-applied pagination pattern; without it,
some endpoints risk returning unbounded result sets as data grows.
 Human interface for the farmer app carries the same navigational complexity regardless of
literacy level: A true accessibility-first design might offer a simplified "core tasks only" mode
for first-time or very low-literacy users, rather than exposing the full feature set uniformly to
every farmer from day one.
 No visible design system documentation (component library / style guide) separate from the
code itself: Consistency currently depends on developers reusing existing components
correctly rather than a documented, enforced set of interface primitives.

4.4 Component Design

Theoretical Background: Component design is about decomposing a system into discrete, self-
contained units, each with a well-defined responsibility, that can be developed, tested, and reasoned
about independently. Two classic quality measures apply: cohesion (does everything inside a
component belong together?) and coupling (how much does one component depend on the internals
of another?). High cohesion and low coupling make a system easier to change safely.

Role in This Project: With four user roles, several external integrations, and a large and still-
growing feature set, component design determines whether the codebase stays maintainable or turns
into a tangle where changing one feature risks breaking an unrelated one. The project addresses this
by decomposing both the frontend and backend along feature/domain boundaries rather than
technical boundaries alone.

Design Decisions Made:

 Domain-oriented component grouping on the frontend: UI components are grouped by

28 | P a g e
 Software Requirement Specification for লাঙল”

feature domain (consultation-related, marketplace-related, field-data-related, social-feed-

related, and so on) rather than dumped into one flat component folder. This keeps related
pieces close together and makes it easier to find everything relevant to a given feature.
 Single-responsibility service classes on the backend: Each backend service class is scoped to
one concern — one handles one-time-password generation and verification, another handles
push-notification delivery, another handles real-time call-token generation, another handles
AI-based recommendations — rather than one large "helper" class doing everything. This is a
textbook application of the single-responsibility principle.
 A thin API-client layer isolating network concerns from UI components: UI components do
not construct HTTP requests themselves; they call into a small set of service functions that
own the details of talking to the backend. This means a change to how authentication tokens
are attached, or how errors are retried, happens in one place rather than being copy-pasted
across every screen.
 Shared, generic UI primitives separated from feature-specific components: Low-level,
reusable interface elements (buttons, dialogs, form controls) are kept separate from higher-
level feature components that compose them, which is a healthy layering of "dumb" reusable
pieces under "smart" feature-aware ones.
 Constructor-based dependency injection for backend services: Controllers receive their
service dependencies through the framework's dependency injection rather than instantiating
them internally, which keeps components loosely coupled and independently testable.

Possible Improvements:

 Evidence of duplicated/parallel component versions for the same feature: More than one
component appears to exist for what looks like the same screen or responsibility (an original
version and a "new" variant, for example), suggesting incomplete refactors were left in place
rather than the old version being retired. This raises maintenance risk — a fix applied to one
version can silently miss the other.
 Some feature components likely mix data-fetching and presentation concerns: Where a
component both requests data and renders it, rather than delegating fetching to a hook/service
and receiving data as input, testability and reusability suffer — the component can't easily be
reused with different data sources or tested with mock data alone.
 No enforced dependency-direction rule between service classes: Nothing structurally stops
one service from calling another in a way that creates a hidden chain of dependencies; over
time, without an explicit rule (e.g., "services may not depend on other services outside a
defined interface"), coupling tends to creep in.
 Component granularity is uneven: Some feature areas are broken into many small, focused
components, while others appear to concentrate a lot of logic into a single large page-level
component — a more consistent granularity policy (e.g., "extract when a component exceeds
N responsibilities") would make the codebase's structure more predictable to new
contributors.

4.5 Deployment Design

29 | P a g e
 Software Requirement Specification for লাঙল”

Theoretical Background: Deployment design describes how software components are mapped onto
physical or virtual infrastructure, how those infrastructure nodes communicate, and how the system
is built, released, and operated. It determines availability, scalability, and how quickly a fix can reach
real users.

Role in This Project: Deployment design here has to account for a genuinely distributed setup: a
statically-hosted client, a separately-hosted API server, a managed relational database, cloud object
storage for media, and several external SaaS providers for real-time and AI capability — all of which
must work together reliably for users on inconsistent rural mobile networks.

Design Decisions Made

 Static hosting for the client, separate from the API server: The web client is built once and
deployed as static files to a content-hosting platform, decoupled entirely from the backend's
runtime. This is appropriate because the client has no server-side rendering needs and
benefits from the low cost and high availability of static hosting.
 Backend deployed as an independent, long-running managed service: The API server runs on
its own platform, separate from the client, which allows it to be restarted, scaled, or rolled
back without touching the client deployment at all.
 Automated build-and-deploy pipeline for the client: Pushing to the main branch triggers an
automated pipeline that installs dependencies, builds the production bundle, and publishes it
— removing manual deployment steps and the risk of deploying a stale or locally-modified
build.
 Externalized, environment-based configuration: Sensitive configuration (API keys, storage
credentials, service secrets) is kept out of source code and supplied through environment
configuration at deploy time, with an example configuration file checked in to document
what's required without exposing real secrets.
 Media storage decoupled from the application server: Uploaded photos and audio are stored
in cloud object storage rather than on the application server's local disk, which means the
server remains stateless and can be redeployed or scaled without risking loss of user-
uploaded content.
 Mobile distribution via a wrapped web build rather than a fully native app: The Android app
is produced by wrapping the same web client in a native shell, rather than maintaining a
separate native codebase — trading some native-platform polish for a single source of truth
across web and mobile.

Possible Improvements:

 No staging/pre-production environment evident: Changes appear to go from development

directly toward the production deployment target, with no intermediate environment to catch
integration issues before real users see them.
 No documented rollback procedure: If a deployment introduces a regression, there's no
visible automated rollback step in the pipeline — recovery currently seems to depend on
manually redeploying a previous commit.
30 | P a g e
 Software Requirement Specification for লাঙল”

 Single-region deployment: Both the API server and database appear to run in one
region/location; for a system meant to scale nationally, this introduces a single geographic
point of failure and higher latency for users far from that region.
 No visible health-check-driven auto-recovery or monitoring/alerting setup: A basic health
endpoint exists, but there's no evidence of automated alerting when it fails, meaning an
outage might only be discovered when users report it rather than proactively.
 Third-party dependency risk is not mitigated architecturally: Because real-time calls,
notifications, TTS, and storage are all outsourced to individual external providers, an outage
or pricing/policy change from any one of them directly degrades a core feature, with no
fallback provider configured.

4.6 Quality Design

Theoretical Background: Quality design is the deliberate set of engineering practices used to
achieve the non-functional requirements defined earlier (performance, security, reliability,
scalability, maintainability, availability, usability, portability). It's the bridge between stating a
quality requirement and actually engineering for it in the codebase.

Role in This Project: Given the earlier chapter's non-functional requirements — heavy emphasis on
usability for low-literacy users, reliability under poor connectivity, and security across four distinct
roles handling sensitive data — quality design in this project is less about a single technique and
more about a consistent set of small decisions repeated across the codebase.

Design Decisions Made:

 Centralized, reusable authentication/verification logic (Security + Maintainability): One-time-

password generation, verification, and expiry are handled through a single dedicated
component reused by every role's registration/login flow, rather than each role implementing
its own copy — reducing the chance of an inconsistent or weaker implementation slipping in
for one role.
 Role-based access enforcement applied consistently at the routing layer (Security): Access
rules are attached at the point requests enter the system, rather than being re-checked ad hoc
deep inside business logic, which reduces the chance of an endpoint accidentally being left
unprotected.
 Fallback-first design for external data feeds (Reliability + Availability): Where the system
depends on an external data source or provider, the pattern observed is to persist the last
known good result and serve it with a freshness indicator when the live source is unavailable,
rather than letting the failure propagate to the user as an error.
 Background-friendly, resumable media upload behavior (Performance + Reliability):
Photo/media submission is designed to tolerate interrupted connections rather than requiring
a single unbroken upload, directly addressing the rural-connectivity constraint.
 Environment-based configuration and stateless API design (Scalability + Portability):
Because the backend does not hold session state in memory and reads its configuration from
the environment rather than hardcoding it, the same backend code can, in principle, be run as
31 | P a g e
 Software Requirement Specification for লাঙল”

multiple parallel instances without modification.

 Consistent Bengali-first, icon-and-audio-supported interface (Usability): This is the most
visible quality investment in the project — it's not a bolt-on accessibility feature but a first-
class design decision reflected throughout the interface layer.
 Cross-platform client from a single codebase (Portability): One frontend serving both a
browser and a packaged mobile shell avoids the classic maintainability/quality risk of two
divergent codebases drifting out of sync.

Possible Improvements:

 No visible automated test suite covering the critical paths described above: Reliability and
security decisions (OTP correctness, role-boundary enforcement, fallback behavior) are
exactly the kind of logic that regresses silently without automated tests; their absence (or
limited presence) is the single biggest quality gap relative to the stated non-functional
requirements.
 No rate-limiting or abuse-protection layer visible on authentication endpoints: OTP and login
endpoints are natural targets for abuse (OTP spam, brute-force attempts); without explicit
throttling, the "high priority" security requirement is only partially met in practice.
 No structured logging/observability strategy evident: Meeting reliability and availability
targets (99.5% uptime, sub-2-second response times) requires being able to measure them;
there's no clear indication of centralized logging, tracing, or metrics collection to verify these
targets are actually being hit rather than just assumed.
 Security relies heavily on application-level checks rather than defense-in-depth: Multiple
layers (database-level constraints, API gateway-level protections, application-level checks)
reinforcing each other would be more robust than application logic being the sole guard
against unauthorized access, as noted also in Data and Interface Design.
 No documented incident-response or backup-verification process: A backup strategy being
configured is different from it being tested — without periodic restore drills, there's no real
assurance that recovery would work when actually needed.

32 | P a g e
 Software Requirement Specification for লাঙল”

Chapter 5: Architectural Pattern and Tactics

1. Client-Server Pattern
Definition: The system is split into two parts — a client that requests services, and a server that
provides them centrally. They talk through a well-defined protocol (like a REST API).
Why it fits here: This system has several different types of users (farmers, experts, buyers,
government staff) using different devices with different network conditions. But everyone must work
from the same shared data and rules. Client-server makes sense because:

Different clients (mobile app, web portal) can reuse the same backend logic instead of duplicating it.
Keeping data centrally on the server ensures consistency — if a farmer submits something, it's
immediately visible to the right expert or officer.
Heavy processing (like disease detection) can run on the server, keeping the client lightweight for
low-end phones.

2. Layered Pattern
Definition: The system is divided into horizontal layers — presentation, business logic, data access,
and data storage. Each layer only talks to the layer directly below it, so layers can change
independently.
Why it fits here: There are many separate feature areas (diagnosis, marketplace, weather,
consultation, social feed), each with its own business rules that should stay separate from the UI.
Benefits:

UI changes don't break business logic underneath.

Authentication and session handling live in one shared layer instead of being repeated in every
feature.
If the database technology changes later, the layers above it don't need to change — improving
maintainability.

3. MVC Pattern
33 | P a g e
 Software Requirement Specification for লাঙল”

Definition: Responsibilities are split three ways — Model (data and business rules), View (what the
user sees), and Controller (handles user input and connects Model and View).
Why it fits here: Different user roles need to see the same underlying data presented differently —
for example, a case might appear as simple advice to a farmer, detailed clinical context to an expert,
and a short summary to an officer. MVC helps because:

The same model can be shown through multiple views without duplicating logic.
The controller layer centralizes input validation and permission checks, improving security and
consistency.

4. Event-Driven Pattern
Definition: Components communicate by publishing and reacting to events rather than calling each
other directly — publishers and subscribers don't need to know about each other (loose coupling).
Why it fits here: Many things happen asynchronously and need to reach multiple parties — like an
urgent disease alert needing to reach the farmer, the expert, and the officer at once, or an expert's
availability changing needing to update pending consultation requests. This pattern helps because:

Asynchronous notifications are more resilient than a chain of direct calls in unstable network
conditions.
New listeners can be added later (like SMS alerts) without changing the part that raises the event.

Architectural Tactics for Quality Attributes:

Authentication — A way to verify user identity, usually token-based or session-based. Chosen

because users mostly connect from low-connectivity mobile devices; a stateless token approach lets a
session survive a dropped connection without the server needing to hold session state, which also
helps scalability.

Authorization (Role-Based Access Control) — Assigning each user a role and limiting what they
can access based on it. Privacy and control matter a lot here — a government officer should never
see private expert-farmer conversations, and a farmer should never reach admin panels. Checking
roles at the entry point (routing level) is chosen because it's the most centralized and easiest place to
audit.

Session Management — Keeping a user's logged-in state persistent over time. Since farmers and
field workers frequently close and reopen the app on modest devices, forcing repeated logins would
hurt usability, so session info is kept locally and restored automatically.

Caching / Offline Drafts — Storing data locally to reduce repeated requests or to keep working
without a connection. Since unreliable rural internet is a core assumption, forms like field data
collection or disease submissions are saved as local drafts until the connection returns, reducing data
loss.

34 | P a g e
 Software Requirement Specification for লাঙল”

Logging / Audit Trail — Recording who did what and when. Accountability matters a lot in
government oversight — decisions like approving, rejecting, or escalating a report need to be
traceable for dispute resolution and compliance.

Fault Recovery — Automatically retrying or gracefully handling failures instead of crashing.

Background checks (like periodic status updates) are designed to fail silently and try again on the
next cycle, which matters a lot over patchy rural network connections.

Encryption — Protecting sensitive data such as passwords and personal contact information, both at
rest and in transit (e.g., using HTTPS). This is needed because the system holds personal identity and
location data that must stay private and meet the stated consent requirements.

Concurrency — The ability to handle multiple requests at the same time. Since many farmers may
upload photos or many operators may be doing verification work simultaneously, the server needs to
process requests in parallel so one slow request doesn't block others.

Resource Pooling (e.g., Connection Pooling) — Reusing a pool of database connections instead of
creating and closing a new one for every request. This reduces the overhead of setting up a
connection each time and improves response speed under load.

Batch Processing — Grouping multiple operations together and processing them as one unit rather
than one at a time (e.g., processing many field-data records or generating summary reports). This
reduces repeated overhead and is useful for operator-side reporting where large volumes of records
need to be reviewed together.

Compression — Reducing the size of data (especially images) before sending it over the network.
This matters a lot here because farmers on low-end devices with weak connections need to upload
photos for diagnosis quickly without consuming excessive data or timing out.

Redundancy — Keeping duplicate copies of critical data or services so that if one fails, another can
take over. This helps ensure the system stays available even if a component temporarily goes down.

Health Monitoring / Heartbeat — Periodically checking whether a component (like an expert's

active status) is still alive and responsive. This lets the system detect problems early (e.g., an expert
going offline) and update dependent parts of the system accordingly.

Graceful Degradation — Designing the system so that if a non-critical feature fails (like a weather
feed or price feed being temporarily unavailable), the rest of the system keeps working, showing a
fallback state instead of crashing entirely. This is important because external data sources (like
market price feeds) may not always be reliable.

User Feedback / Progress Indication — Showing loading indicators, confirmations, or status

messages so the user knows the system is working. This matters especially for slow network
conditions, where users need reassurance that an action (like submitting a diagnosis) is in progress
35 | P a g e
 Software Requirement Specification for লাঙল”

rather than failed.

Localization / Internationalization Support — Structuring the system so content and interface

elements can be presented in a specific language and script. This is central here since the platform is
designed to be Bengali-first for low-literacy users, including text-to-speech support.

Undo / Confirmation Tactics — Requiring confirmation before irreversible actions (like rejecting a
farmer's submitted data or deleting a listing), reducing accidental mistakes, especially important for
less tech-savvy users.

Data Masking / Redaction — Hiding sensitive information (like phone numbers) by default and
only revealing it with explicit consent. This protects farmer and expert privacy while still allowing
necessary contact when needed.

Input Validation — Checking and sanitizing all incoming data before it's processed or stored, to
prevent malformed or malicious data from entering the system. This is especially important since
data comes from many different types of users with varying levels of technical literacy.

Abstraction / Interface Separation — Defining clear boundaries between modules (e.g., separating
how data is fetched from how it's displayed) so that one part can be changed or replaced without
affecting others. This makes it easier to update or extend individual features independently.

Configuration Externalization — Keeping environment-specific settings (like API endpoints)

separate from the core code, so the same codebase can run in different environments (development
vs. production) without modification.

Chapter 6: Quality Attribute Analysis

A quality attribute tells us how well the system does its job — not what it does, but how fast,
how safe, how dependable, and how easy to use it is. Each section below first gives a direct
evaluation (how well the architecture satisfies that attribute), followed by a discussion with
examples from the project supporting that evaluation.

6.1 Performance

Evaluation: The architecture satisfies performance reasonably well for normal, everyday
usage, because it avoids the two most common mistakes — it never runs heavy computation
on the same server that handles regular requests, and it never re-fetches slow-changing
external data unnecessarily. However, performance under real peak load (many users at once)
has not actually been proven, since there is no evidence of load testing, and one internal area
(the operator dashboard) likely lacks proper caching.
Discussion with examples:
1. Heavy work is offloaded, not run on the main server: When a farmer uploads a crop photo for
disease diagnosis, the AI analysis is done by a separate AI service, not the main backend —
36 | P a g e
 Software Requirement Specification for লাঙল”

so one farmer's photo analysis doesn't slow down another farmer checking today's rice price
at the same time.
.
2. Photos are compressed before upload: A farmer's phone photo of a diseased leaf may be 4–5
MB. The app compresses it on the phone before sending. Over a weak 3G rural connection, a
small compressed file uploads in a few seconds instead of possibly timing out.
3. Slow-changing data is cached, not re-fetched every time: Market prices from the government
(DAM) don't change every minute. The app fetches once and shows "last updated 2 hours
ago." If 100 farmers open the price screen within that hour, the government server is called
once, not 100 times.
Weak spot: The Data Operator's regional summary dashboard (trends, top issues for a union)
likely recalculates from raw data on every visit, since caching was only applied to external
data (weather/price), not internal database queries — this would slow down as case volume
grows.

6.2 Security

Evaluation: The architecture satisfies security well at the boundary — every request is
authenticated and role-checked before it reaches any real logic, and OTP adds a second layer
beyond just a password. The main weakness is that this protection exists in only one layer
(the application code) with nothing else backing it up if a mistake is made.
Discussion with examples:
1. Every request is checked for identity and role before anything happens: If a Customer's login
token is used to try to open an Expert's dashboard, the system blocks it at the very first
checkpoint — before any expert data is touched. This check happens identically for every
role, not written separately per screen.
2. OTP adds proof beyond a password: Someone who only knows a farmer's name and phone
number still can't create a fake account impersonating them — they'd also need to receive and
enter the actual OTP sent to that phone.
3. Users only see what they're allowed to see, by design: When a Data Operator reviews a
farmer's diagnosis case for verification, they see a summary (crop, issue, status) — not the
private chat between the farmer and expert, matching the "read-only, no chat access" rule
from the requirements.
4. Marketplace has no payment data to steal: Since payment happens outside the app (buyer and
seller contact each other directly), there's no card or mobile-banking number stored for a
hacker to target in the first place.
Weak spot: There's no visible rate-limiting on login/OTP endpoints, so repeated OTP guesses
aren't architecturally blocked. Also, role protection lives only in application code — if a
developer forgets a role-check on one new feature, there's no second safety net (like a
database-level rule) to catch it.

6.3 Reliability

37 | P a g e
 Software Requirement Specification for লাঙল”

Evaluation: The architecture satisfies reliability strongly, especially from the user's point of
view — failures in one part of the system are contained and don't cascade, and the app is
explicitly designed to degrade gracefully rather than break. The one gap is that the backend
doesn't "learn" when an external service is repeatedly failing.
Discussion with examples:
1. If one external service fails, the rest of the app still works: If the push-notification service
(FCM) has an outage, a farmer still gets the notification saved inside the app (as backup)
even without an instant phone alert. If the video-calling service is down, farmers can still
browse recommendations and check weather — only calling is affected.
2. Stale data is shown instead of an error: If the weather service doesn't respond in time, the app
shows yesterday's forecast marked "may be outdated" instead of a blank error page — a
farmer can still make a rough decision about watering today.
3. Uploads survive a dropped connection: A farmer uploading 3 photos of a sick plant on a
spotty connection can have the upload pause when signal drops and resume automatically —
no need to reselect all photos from scratch.
4. Unsaved work isn't lost: If a farmer is halfway through a marketplace listing and the
connection cuts, the entered data is kept locally so they don't retype everything.
Weak spot: If the video-calling service keeps failing repeatedly, the system doesn't seem to
detect this and switch to a fallback (like voice-note consultation) — each new call attempt
still tries the same failing service.

6.4 Availability

Evaluation: The architecture satisfies availability well for the client and storage tiers, but
poorly for the compute tier — there is only one backend server instance, which is the single
biggest availability risk in the current setup.
Discussion with examples:
1. The client and server are separate — one going down doesn't fully break the other: If the
backend is being restarted for a fix, a farmer who already had the app open can still see
previously loaded profile data, cached prices, and saved listings — the screen doesn't go
blank.
2. The server holds no memory of sessions, so restarting doesn't log anyone out: If the backend
crashes and restarts, a logged-in farmer stays logged in, because their session is proven by a
token on their phone, not something stored temporarily in the crashed server.
3. Uploaded files survive server changes: Even if the entire application server were replaced
tomorrow, every diagnosis photo and marketplace image a farmer ever uploaded is still there,
because it lives in separate cloud storage.
Weak spot: There's only one backend server. If it crashes, gets overloaded, or is being
deployed, every user is affected at once — there's no second server to take over.

6.5 Scalability

38 | P a g e
 Software Requirement Specification for লাঙল”

Evaluation: The architecture is ready for scaling — the foundational decision (a stateless
server) is already in place — but it is not currently scaled. As deployed today, one database
would be the real bottleneck under the stated peak-load target.
Discussion with examples:
1. The server holds no per-user memory, so more copies could be added later: During planting
season, if traffic triples, the backend could in theory run as 2–3 parallel copies behind a
traffic splitter — any copy could handle any farmer's request, since none of them need to
"remember" a specific farmer.
2. File storage grows independently: If a new district joins and photo uploads double, cloud
storage simply expands — no need to touch or resize the main application server.
3. Every record already knows its region: Because every farmer, case, and listing is tagged with
union/upazila from day one, splitting the database by region later (e.g. handling one division
separately) wouldn't need a schema redesign — the field already exists.
Weak spot: Right now there's only one database. If 500 farmers submit cases within the same
10 minutes (realistic during a pest outbreak), all of them hit the exact same database with
nothing to spread the load.

6.6 Modifiability

Evaluation: The architecture satisfies modifiability reasonably well — business rules are
cleanly separated from request-handling, and features are grouped by topic — but two real
weaknesses (a duplicated screen, and direct calls to external services) reduce how cheap
future changes actually are.
Discussion with examples:
1. Business rules are separate from "how the request came in.": If the rule for "who counts as an
available expert" changes later (e.g. it should also depend on current call load, not just a
manual toggle), only the business-logic part changes — the request-handling and database-
saving code stay untouched.
2. Features are grouped by topic, not mixed together: Adding a new marketplace filter (e.g.
"filter by harvest date") only touches marketplace-related code — it doesn't require going
near the weather or social-feed code.
3. Services can be swapped in one place: If the project later switches to a cheaper local
SMS/OTP provider, that change happens in one place — where the OTP service is plugged in
— instead of every registration screen that sends an OTP.
Weak spot: Two versions of the same profile-verification screen (an older one and a "new"
one) both appear to still exist — suggesting a rework created a second copy instead of
updating the original, so a future fix might only be applied to one. Also, calls to external
services (calling, notifications) are made directly rather than through a middle layer, so
switching providers later means changing code in multiple places.

6.7 Maintainability

Evaluation: The architecture satisfies maintainability well structurally — each service does

39 | P a g e
 Software Requirement Specification for লাঙল”

one clear job and setup is documented — but the biggest real gap is the absence of automated
tests, which limits how safely changes can actually be verified.
Discussion with examples:
1. Each backend service does one clear thing: A developer fixing "why aren't farmers getting
notified about expert replies" only needs to look at the one component responsible for
notifications — not crop recommendations or the marketplace.
2. Setup is documented, not hidden in code: A new developer can follow a deployment guide
and a TTS setup guide to get those features running locally, instead of reading through
hundreds of lines of code.
3. Secrets and settings are kept outside the code: API keys for storage, calling, and SMS are
supplied through environment configuration, so a new environment (like a test server) can be
set up just by providing different values.
Weak spot: There's no visible automated test suite. If someone changes OTP verification
logic and accidentally allows expired codes to work, nothing catches that automatically — it
would likely only be discovered when a real farmer somehow logs in with an old code.

6.8 Usability

Evaluation: Usability is the attribute the architecture satisfies most strongly and most
deliberately — nearly every design decision (interface, caching, fallback behavior) circles
back to serving low-literacy, low-connectivity farmers well. The one gap is that this good
design is applied uniformly rather than adapted for first-time users specifically.
Discussion with examples:
1. Different users get different, purpose-built interfaces from the same data: A farmer sees a
large icon, Bengali text, and a "listen" speaker button next to expert advice. A Data Operator
looking at the same underlying case sees a compact table row with Approve/Return/Reject
buttons — because their needs are completely different.
2. Text-to-speech means literacy isn't required: A farmer who can't read Bengali script can still
fully understand an expert's treatment advice by tapping one "play" button and listening.
3. The app never leaves the user with nothing: If a farmer opens the weather screen with no
signal, they still see the last loaded forecast, clearly marked as possibly outdated — not a
blank spinner.
4. Common tasks are short: Posting a marketplace listing (crop, price, quantity, one photo) takes
only a few taps from the home screen, not buried behind multiple menus.
Weak spot: A brand-new farmer opening the app for the first time sees the same full
dashboard (diagnosis, recommendation, marketplace, news, social feed, weather) as someone
who's used it for a year — there's no simplified "just the basics" first-time mode.

40 | P a g e
 Software Requirement Specification for লাঙল”

Chapter 7: Architecture Views (4+1 View Model)

The 4+1 View Model, proposed by Philippe Kruchten, describes software
architecture through five concurrent views, each addressing a different set of
stakeholder concerns. This chapter analyzes the "লাঙল" system using this model.

Logical View

The Logical View describes the system's key classes, their attributes, methods, and
relationships — representing the functionality the system exposes to end users.

41 | P a g e
 Software Requirement Specification for লাঙল”

Figure 1: Database Schema “লাঙল”

The core entities in "লাঙল" are:

 User — represents a Farmer, Agricultural Expert, or Admin. Holds identity,
contact, and role information, and is linked to a Location.
 Diagnosis — represents a disease diagnosis session where a user uploads a
crop image and receives an AI-generated disease name, confidence score, and
treatment recommendation.
 CropRecommendation — captures location- and season-based crop
suggestions along with expected profit estimation.
 Consultation — models the communication session between a Farmer and an
Agricultural Expert (chat, voice, or video).
 MarketplaceListing — represents items (equipment, seeds, produce) listed
for rent or sale.
 Post — represents user-generated content in the social community feed.

A single User can create multiple diagnoses, recommendations, consultations, listings,

and posts, reflected as one-to-many relationships in the class diagram. This design
keeps User as the central entity, since nearly every feature in the system revolves
around a logged-in user's actions. Separating these responsibilities into distinct classes
(rather than one large "God class") supports the Single Responsibility Principle and
makes the codebase easier to extend — for example, adding a new feature like soil
testing only requires a new class rather than modifying existing ones.

Process View

The Process View captures the system's runtime behavior — how components
interact, communicate, and synchronize during execution.

Sequence Diagram of Register and Verify:

42 | P a g e
 Software Requirement Specification for লাঙল”

Figure 2 :Sequence Diagram of Registration

43 | P a g e
 Software Requirement Specification for লাঙল”

44 | P a g e
 Software Requirement Specification for লাঙল”

Sequence Diagram of Log Profile:

Figure 3 :Sequence Diagram of Log Profile

45 | P a g e
 Software Requirement Specification for লাঙল”

Sequence Diagram of Recommend Crops:

Figure 4 : Sequence Diagram of Crop Recommendation

46 | P a g e
 Software Requirement Specification for লাঙল”

Sequence Diagram of Diagnose Disease

Figure 5 :Sequence Diagram of Diagnose Disease

47 | P a g e
 Software Requirement Specification for লাঙল”

Sequence Diagram of Agriculture News:

Figure 6 :Sequence Diagram of Agriculture News

48 | P a g e
 Software Requirement Specification for লাঙল”

Sequence Diagram of Expert Consultation:

Figure 7 :Sequence Diagram of Expert Consultation

49 | P a g e
 Software Requirement Specification for লাঙল”

Sequence Diagram of Social Feed:

Figure 8 : Sequence Diagram of Social Feed

50 | P a g e
 Software Requirement Specification for লাঙল”

Sequence Diagram of Weather Forecast:

Figure 9 :Sequence Diagram of Weather Forecast

51 | P a g e
 Software Requirement Specification for লাঙল”

Sequence Diagram of Market Prices Lookup:

Figure 10 :Sequence Diagram of Market Prices Lookup

52 | P a g e
 Software Requirement Specification for লাঙল”

Sequence Diagram of Manage Account & Profile:

Figure 11 : Sequence Diagram of Manage Account & Profile

53 | P a g e
 Software Requirement Specification for লাঙল”

Development View
The Development View describes the software's internal organization from a programmer's
perspective — how the codebase is structured into packages, modules, and layers.

Figure 12 – Package Diagram

The system is organized as two independently deployable codebases:

Frontend (langal-main/src)
 components/ — reusable UI elements (buttons, cards, forms) shared across pages
 pages/ — route-level screens (Home, Diagnosis, Marketplace, etc.)
 services/ — wrappers around API calls to the backend
 hooks/ — custom React hooks for shared logic (e.g., authentication state, TTS playback)
 contexts/ — global state providers (Auth context, Language context for Bangla/English)
 utils/ & types/ — helper functions and shared TypeScript type definitions
Backend (langal-backend/app)
 Http/Controllers/ — handles incoming requests and coordinates responses
 Models/ — Eloquent ORM classes mapping to database tables
 Http/Middleware/ — authentication and CORS enforcement
54 | P a g e
 Software Requirement Specification for লাঙল”

 routes/[Link] — defines all REST API endpoints

 database/migrations/ — version-controlled schema definitions
 config/ — environment and service configuration (DB credentials, API keys)
This separation follows a clear frontend-backend decoupling, communicating solely through a
REST API. This allows both codebases to be developed, tested, and deployed independently — a
decision that also enabled the same backend to serve both the web app and the Capacitor-based
Android app without duplication.

Physical View

The Physical View (also called the Deployment View) maps software components onto physical or
virtual hardware nodes, showing how the system is distributed across infrastructure.

Figure 13 : Deployment Diagram.

The system is deployed across the following nodes:

 Client devices — user's web browser (desktop/laptop) and Android device (running the
Capacitor-wrapped app)
 Application server — hosts the Laravel PHP runtime, handling all business logic and API
requests
 Database server — runs MySQL, storing all persistent application data
55 | P a g e
 Software Requirement Specification for লাঙল”

 External cloud services — Hugging Face Inference API (AI processing), Azure Blob Storage
(media files), and a third-party Weather API
Communication between the client and the application server occurs over HTTPS using
REST/JSON, while the application server communicates internally with the database over a private
connection (port 3306) and with external services via outbound HTTPS API calls. Separating the AI
inference workload onto an external service (rather than hosting AI models on the application server)
reduces the compute load on the main server and allows the system to scale each component
independently.

Scenario View (+1)

The Scenario View, also known as the Use Case View, ties the other four views together by
validating them against real user scenarios. It represents the architecture from the perspective of end
users.

Satement-2:
Government and supervisory officers do not get structured, timely field data for
decision-making. Manual verification is slow. There is no unified digital channel for
farmer data, diagnostics, and market insight.

Problem description: Field data arrives through paper, calls, WhatsApp, and ad-hoc
Excel files. It lacks standard fields, geotagging, and timestamps. Verification is
manual and delayed. Upazila officers have limited time and need short summaries, not
raw chats. There is no clear link from expert advice to oversight reports. Market price
feeds and weather alerts are not integrated into one view. Without audit trails and
trend views, early warning and resource allocation are slow.

Specific issues:
 Data scattered across channels; no standard structure
 No geo-tagged evidence; hard to map hotspots or clusters
 Slow, manual verification; duplicates and inconsistencies
 Officers need summaries and simple actions (assign/escalate), not raw detail
 No unified link between expert cases, advisories, and operator reports
 Infrequent or non-transparent “last updated” for DAM prices
 Limited audit trail; hard to trace who did what, when
 Connectivity constraints at offices; need lightweight, low-notification port

Figure 14 – Use Case Diagram

56 | P a g e
 Software Requirement Specification for লাঙল”

Chapter 8: Deployment Architecture

This chapter describes how the Langol Krishi Sahayak system is deployed — covering the physical
infrastructure, software stack, network setup, and cloud services that support the application in
production.

Deployment Diagram

Figure 15 : Deployment Diagram

The system follows a client-server deployment model with three primary node types:
 Client nodes — the user's web browser (accessing the system via desktop/laptop) and the
Android device running the Capacitor-wrapped mobile app.
 Application server node — runs the Laravel PHP runtime, handling all API requests,
business logic, and coordination with external services.
 Database server node — runs MySQL, storing all persistent application data (users,
diagnoses, consultations, marketplace listings, etc.).
The client nodes communicate with the application server exclusively over HTTPS using

57 | P a g e
 Software Requirement Specification for লাঙল”

REST/JSON, ensuring encrypted data transfer regardless of platform (web or Android). The
application server, in turn, communicates with the database server over an internal connection and
with external AI/storage/weather services over outbound HTTPS calls. This separation of concerns
— client, application logic, and data — allows each layer to be scaled, updated, or replaced
independently without affecting the others.

Hardware Environment

The hardware requirements are modest, reflecting the system's lightweight web-based architecture
rather than compute-heavy on-premise processing (since AI inference is offloaded to an external
service).

Figure 16 : Hardware Environment Diagram

Client-side hardware:
 Android smartphones running Android 8.0 or higher, with at least 2GB RAM and a
functioning camera (required for crop image capture used in disease diagnosis).
 Any desktop or laptop capable of running a modern web browser (Chrome, Firefox, Edge) for
web access.
Server-side hardware:
 Application server: a virtual machine or container instance with 1–2 vCPUs, 1–2 GB RAM,
and SSD-backed storage — sufficient for running the Laravel application, since heavy AI

58 | P a g e
 Software Requirement Specification for লাঙল”

computation is delegated to Hugging Face's infrastructure rather than the app server itself.
 Database server: a similarly modest instance (1 vCPU, 1GB+ RAM), with storage that scales
as user-generated data (diagnoses, posts, listings) grows over time.
Keeping the server-side hardware requirements low was a deliberate architectural choice — by
offloading AI inference and file storage to external cloud services, the core application server avoids
resource-intensive workloads and remains cost-efficient to host and scale.

Software Environment

The software environment is split across client, server, and database layers, using widely adopted,
well-supported technologies.

Figure 17 : Software Environment Diagram

 Frontend stack: React 18 with TypeScript, bundled using Vite, and styled with Tailwind
CSS. The Android version is produced by wrapping the same web codebase using Capacitor,
allowing a single frontend codebase to serve both web and mobile platforms.
 Backend stack: PHP 8.x running the Laravel framework, using Laravel Sanctum for token-
based API authentication, and Composer for dependency management. The backend exposes
a REST API consumed by both the web and Android clients.
 Database software: MySQL, accessed through Laravel's Eloquent ORM, with schema
changes tracked via versioned migration files — ensuring the database structure can be

59 | P a g e
 Software Requirement Specification for লাঙল”

reliably reproduced across development, staging, and production environments.

 Operating systems: The application server runs on Linux (Ubuntu), while client devices run
either a standard desktop OS (via browser) or Android OS 8.0+.

Using a single shared frontend codebase (React + Capacitor) for both web and Android — rather
than maintaining separate native codebases — significantly reduced development and
maintenance overhead for the team, at the cost of some platform-specific native performance,
which was an acceptable trade-off for this project's scope.

Network Configuration

Figure 18 – Network Configuration Diagram

All client-to-server communication is routed through a domain name resolved via DNS, and secured
end-to-end using HTTPS (port 443). The frontend (static assets) and backend (API) are served from
separate hosting endpoints, connected internally over REST/JSON.
60 | P a g e
 Software Requirement Specification for লাঙল”

The database is placed behind a firewall/security group that restricts direct external access — only
the application server is permitted to connect to it, over its internal port (3306), and this port is never
exposed publicly. This configuration reduces the attack surface significantly, since the database
cannot be reached directly from the internet even if an attacker discovers its address.
Outbound connections from the application server to external services (Hugging Face AI, Azure
Blob Storage, Weather API) are also made over HTTPS, ensuring that data in transit to third-party
services remains encrypted.

Cloud Services

The system relies on a combination of cloud-hosted infrastructure and third-party

managed services rather than a single monolithic server, reflecting a modern cloud-
native deployment approach:

Figure 19 : Cloud Services Diagram

 Frontend hosting — the static React build is deployed on a CDN-backed

hosting platform (e.g., Vercel), ensuring fast global content delivery and
automatic HTTPS.
 Backend hosting — the Laravel application runs on a cloud platform or VPS
(e.g., Railway), providing the compute environment for the API.

61 | P a g e
 Software Requirement Specification for লাঙল”

 Azure Blob Storage — used for storing and retrieving media files such as
crop diagnosis images and user profile pictures, offloading file storage from
the application server itself.
 Hugging Face Inference API — provides the AI models used for crop
disease detection and Bangla text-to-speech generation, removing the need to
host and maintain GPU-backed infrastructure for machine learning inference.
 Weather API (third-party) — supplies real-time weather forecast data used
in the weather planning feature.

By distributing responsibilities across these managed cloud services instead of self-

hosting everything, the project avoids the operational burden of maintaining
specialized infrastructure (e.g., GPU servers for AI inference) while still delivering
AI-powered features. This also means the system can scale each service
independently — for instance, if AI diagnosis usage grows, Hugging Face's
infrastructure absorbs that load without requiring changes to the application server
itself.

62 | P a g e