`

Smart Agriculture Platform

By

Ali Raza
BSSE-FA17-014
Naeem Waqas
BSSE-FA17-051
Adnan Sadiq
BSSE-FA17-080

SUPERVISED BY
Mr. Rehman Shahid

Bachelor of Science in Software Engineering

Department of Computational Science

The University of Faisalabad
2021
`

DECLARATION
We hereby declare that the content of this project report or Software Requirements
Specification (SRS) entitled "Smart Agriculture Platform" Is completely written by us
and it’s totally our effort and none of anyone from outside of our group have copied
it and submitted to the "DEPARTMENT OF COMPUTATIONAL SCIENCES", is a record
of an original work done by us under the guidance of Supervisor "Mr. Rehman
Shahid" and that no part has been plagiarized (except the references, some standard
mathematical or genetic models / equations / protocols etc.). Also, this project work
is submitted in the partial fulfillment of the requirements for the degree of Bachelor
of Software Engineering. The university may take action if the above statement
found inaccurate at any stage. This Report is purely written in a technical way in
accordance to our project which is going to be developed. We proudly declared that
we haven’t copied any content of this Report from Internet or any other source.

Student Name Registration No. Signature

…………………….. ……………………… ………………………

…………………….. ……………………… ……………………….
…………………….. …………………….. ……………………..

Supervisor: Signature/Date

i
`

CERTIFICATE
We accept the work contained in the report titled “Smart Agriculture Platform”,
written by AUTHOR1 Mr. Ali Raza, AUTHOR2 Mr. Adnan Sadiq AND AUTHOR3 Mr.
Naeem Waqas as a confirmation to the required standard for the partial fulfillment
of the degree of Bachelor of Science in Computer Science.

Approved by

Supervisor: Name of the Supervisor (Title)

Internal Examiner: Name of the Internal Examiner (Title)

External Examiner: Name of the External Examiner (Title)

Project Coordinator: Name of the Project Coordinator (Title)

Head of the Department: Name of the HOD (Title)

Tuesday, July 13, 2021

ii
`

ACKNOWLEDGMENT
First and foremost, praises and thanks to the Allah, the Almighty, for His showers of
blessings throughout our project work to complete the Smart Agriculture Platform
successfully.
Before starting the development of the Proposed System and description of the
detailed chapter of software requirement specification, we want to acknowledge the
efforts of those who helped us in different stages of our project. We proudly declare
that the success parameters of this project are confined to the endless prayers and
support of our parents. We would like to thank our parents who helped us a lot in
gathering different information, collecting data and guiding us from time to time in
making this project, despite of their busy schedules, they gave us different ideas in
making this project unique. Our Special thanks goes to our friends of Mr. Hassam Mr.
Farhan, Mr. Ali Raza and Mr. Hamza for their ideas, support, advices and suggestions
in different stages ranging from elicitation to deployment, yielded to ultimate
success of our end product.

“We wish to pay our warmth of gratitude and thankfulness to our honorable faculty
members who rendered their services to help us in different aspects of problem
area. We are thankful to our most Respected Teacher Sir Muhammad Rehman
Shahid for being always a helping hand in all regards, in all development levels of the
project and especially for making usable to move forward in the Field of
development of Software products/projects with standardize international rules. We
are much grateful to Chairman Computer Science Department Dr. Muhammad Asif,
our Supervisor Mr. Rehman Shahid for extreme supportiveness and for motivating us
to do something extraordinary and revolutionary.”
We really acknowledge the help and support by the CS/IT staff for providing us
support and access to IT Labs, different other IT Appliances as required to work on
different stages of end product development. We are Determined & Enthusiastic to
complete this project in different Steps (Requirements, Architecture, Design,
Development and Finally Deployment) as soon as possible, exactly in accordance to
Pure Requirements mentioned in elicitation and analysis chapter.

iii
`

Table of Contents
Chapter 1. Introduction.......................................................................................................1
1.1. Problem Statement...................................................................................................1
1.2. Purpose of Project.....................................................................................................1
1.3. Targeted Audience....................................................................................................1
1.4. Problem Domain.......................................................................................................2
1.5. Proposed Solution.....................................................................................................2
1.6. Project Goals.............................................................................................................2
1.7. Project Scope............................................................................................................2
1.8. Project Planning........................................................................................................3
Chapter 2. Literature Review..............................................................................................4
2.1. Related Work............................................................................................................4
2.1.1. PARC................................................................................................................4
2.1.2. Agri Punjab.......................................................................................................4
2.1.3. OLX..................................................................................................................4
2.1.4. Comparison Table.............................................................................................5
2.2. Area of Studies..........................................................................................................5
Chapter 3. Methodology.....................................................................................................6
3.1. Software Development Life Cycle (SDLC) Methodologies.........................................6
3.1.1. Waterfall...........................................................................................................6
3.1.2. V-Model............................................................................................................6
3.1.3. Spiral Model......................................................................................................7
3.1.4. Prototype Model................................................................................................7
3.2. SDLC Techniques.......................................................................................................7
3.2.1. Incremental Model............................................................................................7
3.3. Adapted Methodology..............................................................................................8
3.3.1. Reasons for Prototyping Model.........................................................................8
3.3.2. Reasons for being Incremental..........................................................................9
3.4. Risk Management.....................................................................................................9
3.4.1. Elicitation and Analyses....................................................................................9
3.4.2. Deliverable Period (time)................................................................................10
3.4.3. System Failure or Data loss.............................................................................10
3.4.4. Unavailability of Team Member.....................................................................10
3.5. Work Division..........................................................................................................10
3.5.1. Final Phase......................................................................................................10
3.6. Requirement Elicitation..........................................................................................11
3.6.1. Interviews........................................................................................................11

iv
`

3.6.2. Document Analysis.........................................................................................11

3.7. Requirement Analysis.............................................................................................11
3.8. System Requirements.............................................................................................12
3.8.1. Functional Requirements.................................................................................12
3.8.2. Non-Functional Requirements.........................................................................13
3.9. Use case diagram....................................................................................................14
3.9.1. Requirement Based Use Case Diagram...........................................................15
3.9.2. Fully Dressed Use Cases.................................................................................20
3.13. Design Methodology...........................................................................................28
3.14. High Level Design................................................................................................28
3.14.1. Conceptual or Logical view point...................................................................29
3.14.2. Process View Point.........................................................................................30
3.14.3. Physical View Point........................................................................................33
3.15. Low Level Design.................................................................................................33
3.16. Database Diagram...............................................................................................33
Chapter 4. Results and Conclusion...................................................................................34
4.1. Verification & Validation.........................................................................................34
4.2. System Testing........................................................................................................34
4.2.1. Black Box Testing...........................................................................................34
4.2.2. White Box Testing..........................................................................................35
4.3. Adapted Methodologies.........................................................................................36
4.4. Test Cases against Function Requirements.............................................................36
4.4.1. User Registration/login Test Case...................................................................36
4.4.2. User Registration/login Test Case...................................................................37
4.4.3. Add Item Test Case.........................................................................................37
4.4.4. View Products Test Case.................................................................................38
4.4.5. View Item History Test Case..........................................................................38
4.4.6. Contact Others Test Case................................................................................39
4.5. Devices used for Functional Requirements testing.................................................39
4.6. Usability Test Case..................................................................................................40
4.6.1. Aesthetics Test................................................................................................40
4.6.2. Ease test..........................................................................................................40
4.6.3. Stress Test Case..............................................................................................40
4.7. User Manual................................................................................................................41
4.7.1. Smart Agriculture Platform Interfaces................................................................41
4.7.1.1. User Registration Interface..........................................................................41
4.7.1.2. User Login Interface....................................................................................42
4.7.1.3. User Dashboard Interface............................................................................42

v
`

4.7.1.4. C2C Market Interface..................................................................................42

4.7.1.5. Shared Economy Interface..........................................................................43
4.8. References..............................................................................................................44

vi
`

List of Figures
Figure 3.1 Project Planning............................................................................................9

Figure 3.2 Smart Agriculture Platform use case.........................................................15

Figure 3.3 Register Use Case Diagram.........................................................................16

Figure 3.4 Select Field Use Case Diagram....................................................................16

Figure 3.5 Add Item in C2C Market Use Case Diagram...............................................17

Figure 3.6 Add Item in Shared Economy Use Case Diagram.......................................17

Figure 3.7 view Products Use Case Diagram...............................................................18

Figure 3.8 Connect with Users Use Case Diagram.......................................................18

Figure 3.9 Connect with Users Use Case Diagram.......................................................19

Figure 3.10 Change Product Specification Use Case Diagram.....................................19

Figure 4.1 System Architecture....................................................................................27

Figure 4.2 Component Based Development Diagram.................................................28

Figure 4.3 Component Diagram of User Registration.................................................29

Figure 4.4 Component Diagram of Shared Economy...................................................29

Figure 4.5 Component Diagram of C2C Market..........................................................30

Figure 4.6 Component Diagram of Select Field...........................................................30

Figure 4.7 Sequence Diagram of User Registration.....................................................31

Figure 4.8 Sequence Diagram of Select Field...............................................................32

Figure 4.9 Sequence Diagram of Add Item..................................................................32

Figure 4.10 Deployment Diagram................................................................................33

Figure 4.11 Database Diagram....................................................................................33

Figure 5.1 black box testing.........................................................................................35

Figure 5.2 White Box Testing.......................................................................................35

Figure 6.1 User Registration interface.........................................................................41

Figure 6.2 User Login Interface....................................................................................42

Figure 6.3 User Login Interface....................................................................................42

Figure 6.4 C2C Market Interface..................................................................................43

Figure 6.5 Shared Economy Interface..........................................................................43

vii
`

List of Tables
Table 1 Estimation Schedule project scope....................................................................3
Table 2 Comparison of agriculture platform..................................................................5

Table 3 Requirements of system..................................................................................13

Table 4 Register user....................................................................................................20

Table 5 Select Field.......................................................................................................21

Table 6 Add Item in C2C Market..................................................................................22

Table 7 Add Item in Shared Economy..........................................................................23

Table 8 View Products..................................................................................................24

Table 9 Connect With Users.........................................................................................24

Table 10 View Product History.....................................................................................25

Table 11 Change Product Specification.......................................................................26

Table 12 User Registration Test Case..........................................................................36

Table 13 User Registration Test Case..........................................................................37

Table 14 Add Item Test Case........................................................................................37

Table 15 view products Test Case................................................................................38

Table 16 view item history Test Case...........................................................................38

Table 17 Contact Others Test Case..............................................................................39

Table 18 Testing Devices Detail...................................................................................39

Table 19 Aesthetics Test Case......................................................................................40

Table 20 Ease Test Case...............................................................................................40

Table 21 Stress Test Case.............................................................................................41

viii
`

Acronyms
DSA Data Structure and Algorithms
OOP Object Oriented Programming

PF Programming Fundamentals
SE Software Engineering

SQL Structured Query Language

UNESCO United Nations Educational, Scientific and Cultural Organization

UNICODE Unique, Universal, and Uniform Character encoding

XML Extensible Markup Language

ix
`

Abstract
Agriculture is helpful in improving food security, raising incomes and reducing
poverty of 80 percent of world’s poor who mainly work in farming and live in rural
area. Most powerful tool to decrease poverty, increase shared prosperity and
feeding people is agricultural development. Effect of agricultural sector’s growth in
raising poor’s income is two to four times more than other sectors. According to
analysis of 2016, 65% of helpless working grown-ups earned their livings through
agriculture. Agriculture is a main part of economy of any developing country. Survey
in 2018 revealed that, agriculture has 4 percent in global Gross Domestic Product
(GDP) and more than 25 percent in GDP of some developing countries.
Agriculture is the main source of employment and income of rural population of
country. Besides all these, agriculture is main source of food. According to rough
estimation, one quarter of earth’s surface is used for agricultural purpose. Countries
with small economy, increasing population and low productivity rate, continues to
increase their agriculture. According to compiled estimates of Millennium Ecosystem
Assessment (MEA), in large parts of ASIA and sub-Saharan Africa, there is almost no
highly productive land left.

Today, there are many apps and websites that aids farmers in many ways but, still
there are some issues like farmers can’t access consumers directly. Farmers have to
deal with commission agents of grain market. Due to this farmers can’t earn much
benefits. Other main issue is availability of machinery used in farming procedures.
Not all farmers have all required machineries, they have to take machineries on rent
from other farmers. Besides these issues there are many issues that are faced by
farmers in daily routine like: checking rates of fertilizers and pesticides, weather
forecasting, checking crop condition on daily base etc.

To resolve all these issues, we are introducing a new platform with name “Smart
Agriculture Platform”. This platform will provide ease to farmers in all the aspects,
mentioned above. By using this platform, farmers will be able to deal directly with
consumers so that more benefits can be earned. Farmers can take machineries on
rent from other farmers to fulfill their farming needs with ease and comfort. Crop
health can be determined by farmers through provided maps on website.

x
`

Chapter 1. Introduction
Before starting Software requirement specification, it’s intended to mention brief
introduction about the project along with the problem area and project scope. All
the targets and objectives will be clearly mentioned in this part. Smart Agriculture
Platform will bring an innovation by empowering farmers for direct interaction with
consumers and other farmers. Connection with others and fertilizer
recommendation makes it imperial. Hence a single product will ease farmers in many
aspects.

1.1. Problem Statement

Some main problems that are normally faced by farmers are sale of their crops,
finding machinery needed for farming procedures, check updated rates of different
pesticides, fertilizers, crops etc. and checking crop condition on daily basis. It is
difficult for farmers to forecast weather, find consumers for their products and check
rates of crops, pesticides, seeds and spray on separate websites/apps. There should
be only one Platform which enables farmers to do all these activities on it.

1.2. Purpose of Project

Main Purpose of this Documentation is to provide a brief description and details for
the product from its functionality to usability. As it’s cited above that the product
with name “Smart Agriculture Platform” is intended to launch as an innovative idea
to merge all the services besides some new services which will ease farmers and
consumers in their daily routine.

1.3. Targeted Audience

Software Requirement Specification will be very helpful for its users as it contains all
information about the problem domain and how those problems will be tackled by
this product. As this is an innovative product so it will define the scope for particular
type of users. If users are farmers or consumers, then through this document they
will get an idea that how they can get advantage of this platform. This platform is
based upon service-oriented architecture which serves on both ends hence the user
is the main entity on both sides. Consumer not limits any user to just find a product
to buy but it allows consumers to sale their agriculture related products in their
1
`

profile too at the same time.

1.4. Problem Domain

The domain should be understood clearly before further details for which this
product will be applicable so that all the time, all the relevant officials and all the
development levels will be carried out by focusing on the exact domain for which
genuinely this product revolute. To bring quality and veracity and for the sake of
determination and dedication to achieve a single and common goal, it’s perfect to
focus only that particular domain and then work within the solid boundary of that
domain.

1.5. Proposed Solution

Project is to build a system which ease the farmers by providing all the facilities
under one roof. Farmers are the main focus of this project and farmers have direct
connection with consumers which makes farmers independent of commission agents
of grain market. Provides a platform for the farmers to raise their productivity.
Consumers can buy products at low rates because products are purchased from
farmers directly.

1.6. Project Goals

• Forecast the weather condition of specific area.
• Check the market rates of different crops, fruits, vegetables, seeds, pesticides
and fertilizers.
• Get information related to fruits, vegetables and crops.
• Select fields from maps shown on website.
• Check the best time and weather condition to cultivate different crops.
• Check expert reviews.

1.7. Project Scope

Using this system there is an ease for everyone to use it according to their interests
and can automates the works of any farmers.
• Leading toward the prosperity and better future of the farmers.
• Increasing benefits of farmers.

2
`

• Motivate to increase production.

3
`

Table 1 Estimation Schedule project scope

Task Name Duration Start Finish
Project Planning 14 days 11/16/2020 12/04/2020
Req. Gathering 21 days 12/13/2020 01/10/2020
Document Phase1 23 days 01/11/2020 02/11/2021
Architecture Design 7 days 02/12/2021 02/20/2021
Design 6 days 02/12/2021 02/28/2021
Coding 37 days 03/03/2021 04/22/2021
Implementation 23 days 04/23/2021 05/25/2021
Testing 5 days 05/25/2021 02/29/2021
Verification 8 days 06/01/2021 06/10/2021

1.8. Project Planning

Project Planning is one of the important phases of our project. We show our
planning of the project in the form of use cases etc. So, it is clear for us the progress
of our project. In project planning table we have four headings like task, name, and
duration, start date, and finish date. These attributes used in a table that clearly give
us information about the planning of our project and we follow this plan by dividing
work between each group members.

4
`

Chapter 2. Literature Review

Agriculture plays an important role in economy of every country. Specifically in
Pakistan’s economy agriculture has 24% part in GDP. Also, agriculture fulfills the food
needs of livings and ensures food security. In these days of information technology
when everything has been transferred on IT there is no such platform which
connects farmers to consumers and other farmers directly. So, we are trying to bring
farmers and consumers on one platform so that direct deals of farmers with
consumers can take place. In this way, farmers and consumers both will get more
benefits.

2.1. Related Work

There are many help desks established by government to provide agriculture related
services to farmers like beneficial advices, recommend fertilizer and seeds basis on
the result of soil test. There are many websites which perform the same task and
help famers in many ways. Some websites motivate farmers by providing
information related to their field so that productivity of crops can be increased to
earn more benefits.

2.1.1. PARC
It is a web based application, actually a learning application having many topics to
study and gaining information related to farming and agricultural growth.
[CITATION htt7 \l 2057 ]

2.1.2. Agri Punjab

It is a web based educational application developed by government for the persons
who want to increase their production. In this website there is a brief knowledge
about many aspects of farming/agriculture.
[CITATION htt2 \l 2057 ]

2.1.3. OLX
It is a good web-based application. This website is actually a selling website in which
products are sold of any type. In olx, there are different categories of products.
Agricultural products are also included in it.

5
`

[CITATION htt4 \l 2057 ]

2.1.4. Comparison Table

Table 2 Comparison of agriculture platform
Website Platform Registration Agriculture C2C Shared Select

Name Related Market Economy Field

Information
PARC Web X ✓ X X X

Agri Punjab Web X ✓ X X X

OLX Web ✓ X X X X

Smart Web ✓ ✓ ✓ ✓ ✓
Agriculture
Platform

2.2. Area of Studies

Area of studies of this project include website development in HTML, PHP, SQL
Databases, Google maps API, Software Engineering, Object oriented analysis and
design. Research live location tracking methods. Learning machine learning
algorithm. After learning these study areas, we are able to develop this platform.

6
`

Chapter 3. Methodology
This chapter of software requirement specification will incorporate a general
overview of all the software development process involved in development of Smart
Agriculture Platform. These processes are used as a bench marks to bring out all
working in different constraints and parameters for the sake of a common goal. Let’s
take a short introduction of general processing models and our selected model with
the reason of adaption.

3.1. Software Development Life Cycle (SDLC) Methodologies

A software development process is a set of stages which are imposed to the
development of a software product and a set of rules for the assembly line of
Software Development Life Cycle (SDLC). There are many different software
development processes and all of them can be applied on any type of software. The
best suited process for a software depends on many issues such as the size and
complexity of software, whether the software might be imposed to some changes,
whether the functional requirements are clear, what the Software is of fix budget
and the platform on which the software will be deployed etc. Each software
development process includes different stages that form the software’s life cycle and
these steps also varies in different software development processes but all leads to
common result”.

3.1.1. Waterfall
The water fall model was the first process model to be introduced. It is also referred
as linear sequential life the next phase can begin. At the end of each phase, a review
takes place to determine whether the project is on the right path or not to continue
or discard the project.”It is very simple to understand and use, in this model each
phase must be completed fully before starting new phase.

3.1.2. V-Model
The v-model is the variation of waterfall model where the testing activities are
related to analyses and design. In v-model against every phase the testing is
performed after completing that particular phase. In this way each Phase is also
tested at the same time. Model is applicable where the project is of sensitive type

7
`

like of Accounts and Military.

3.1.3. Spiral Model

The spiral model is the first model in which more emphasis placed on risk analyses.
The spiral model has four phases:
• Objective setting
• Risk Assessment and Reduction
• Development and validation
• Planning
A software project repeatedly passes through these phases in iterations. In first
phase of Objective setting those requirements are analyzed which will be developed
in current iteration and also the possible risks are also assessed. On next phase of
Risk Assessment and Reduction it is assessed whether the expected risks occur and if
occur then in what why they were fixed. Then in next phase the Requirements are
Developed and validated and in last phase a review is taken to get know how we can
improve the things in next iteration. So, it’s iterative work where each new iteration
also fixes the short comings of previous iteration.

3.1.4. Prototype Model

The Basic idea is that instead of freezing the requirements before a design or coding
can proceed, a prototype is built to understand the requirements. So, in prototype
model the Software is developed on the base of currently known requirements. It is
very helpful where the Requirements are not clear so we can build the system by
having continuous feedback from the stakeholders and users.

3.2. SDLC Techniques

There are two techniques of system Development and these techniques can be used
in any processing models. They are not processing models itself. These techniques
are used after adapting any particular processing model.

3.2.1. Incremental Model

In this technique the whole system is divided in modules and then the modules who
have higher priority than others are developed at first and the System is deployed.

8
`

Then the Remaining Modules are also developed but integrated with the existing
system. In this way the whole system will be developed in a manageable way and
also deployed very quickly.
In this Model the whole system is developed in one attempt but the Modules are
upgraded on the next iteration and then integrated. All changes are also
implemented on the next iteration of the system and in this way a full fledge system
is deployed. Many updates and up gradation in the existing system are also
incorporated in different iterations.

3.3. Adapted Methodology

After analyzing all the processing models according to their size, complexity &
functionality of this System, it is decided to adopt “Prototyping Model (Incremental)”

3.3.1. Reasons for Prototyping Model

As the system which is going to be developed is completely a new system and does
not existed before in its any form and we don’t have fix requirements so all the
requirements can’t be gathered at the time of development. We will start from the
basic requirements and functionalities and later on while development the further
requirements can be implement. We will launch the product’s Beta version in the
market for feedback which can be used as requirement gathering phase and later on
the basis of user’s expectations and interactions changes can be adopted. As this
Product’s requirements are not cleared or too much confusing as the core
requirements are what its users will expect from it; so, we have decided to adopt
Prototyping processing model. In this model we will get basic requirements or
expected functionalities from its users and then after analyzing them we will start
our working on those requirements which are clear to us. Gradually, we will get user
feedback, we will work on them and present the required and expected functionality
in the product in its next update and then again get user feedbacks and on basis of
continuous feedbacks or user expectations, we will keep on upgrading our system in
the next update. This process will be repeated many times and as soon as possible
the requirements are cleared the final software will also be developed. The process
will keep on practiced even after deployment of product for its maintenance and up
gradation.
9
`

3.3.2. Reasons for being Incremental

As all of the modules of our system are dependent on each other, mean one module
requires other module for performing its functionality so it is impossible to divide
them and develop them according to their priority so it is better to develop whole
system in incremental manners to upgrade the modules.

Figure 3.1 Project Planning

3.4. Risk Management
Before Development of the system the Project manager should have to identify the
risks that can occur during the development phases of the system and can be a
hindrance in the development phase.” So, it is very important to identify the
expected risks before formally starting the development phase and provide their
Solutions as well.

3.4.1. Elicitation and Analyses

Risks may arise if the requirements are not cleared or misperceived, any problem in
this phase can become the main failure of the end product.” In this phase a lot of
concentration and professional expertise are required because as much the
requirements will be cleared; more smooth development will be possible. To handle
these risks the interviews of stakeholders are recorded to analyze them laterally.
Smart Agriculture Platform is service oriented architecture which comprises a lot of

10
`

categories for users hence interviews for different categories are recorded for more
clear view of the future product.

3.4.2. Deliverable Period (time)

Enough Time Boxing is done in each phase to complete the defined tasks in defined
timing. It was much important to define the time as software market is dynamic and
a long time of development without management can leads towards primary failure
to the product.

3.4.3. System Failure or Data loss

To avoid this type of risks the Backup of Development data will be taken
continuously on daily bases in a separate external hard drive and on web cloud.
Multiple copies of code make it secure.

3.4.4. Unavailability of Team Member

If unfortunately, any of the member will be unavailable due to connection during the
Development of system then team leader will take over and perform his
responsibilities or in some cases his assigned tasks will be divided in all the team and
in this way this risk will also be compensated.

3.5. Work Division

Work will be divided in two Main Categories. App Development and SRS
Documentation Module
• Front End Designs for System & Design Module
• Backend Coding and UML Diagrams Module
• Testing and Acceptance Analysis of SRS

3.5.1. Final Phase

“System Testing and Acceptance testing of product Validation of system and SRS by
Software Engineer “Finally, the product will be ready to launch in the market”.
Before Development of the system the Project manager should have to identify the
risks that can occur during the development phases of the system and can be a
hindrance in the development phase. So, it is very important to identify the expected
risks before formally starting the development phase and provide their Solutions.

11
`

3.6. Requirement Elicitation

Requirement’s elicitation is the process of seeking, uncovering, acquiring, and
elaborating requirements for under developed systems. It is generally understood
that requirements are elicited rather than just captured or collected. “This implies
there are discovery, emergence, and development elements to the elicitation
process. Requirement’s elicitation is a complex process involving many activities with
a variety of available techniques, approaches, and tools for performing them. There
are literally different techniques and approaches for requirements elicitation. Below
we used only some of those that are more widely used.

3.6.1. Interviews
Interviews are probably the most traditional and commonly used technique for
requirements elicitation. Interviews provide an efficient way to collect large amounts
of data quickly. “We conduct interviews to gather information or requirements
about user’s needs. We conduct meetings with different organizations. In structured
interviews, we conducted using a predetermined set of questions to gather specific
information. We also conducted the most traditional and commonly used technique
that is unstructured interviews for requirements elicitation. In unstructured
interviews, we asked the different questions randomly and make a conversation for
collecting useful information about the system.

3.6.2. Document Analysis

We examined the existing and related documentation and applications as it is very
useful to us for gathering early requirements as well as understanding and capturing
domain knowledge and identification of reusable concepts and components.

3.7. Requirement Analysis

We analyze our requirements by answering some question.
1. What are the expectations of farmer?
• want to sale something
• Easily reachable
• Easy contact with the consumers
• Check his/her published products

12
`

2. What are the expectations of Consumers?

• Easy to access
• Search for specific product
• Easy to contact with farmers
3. What is the reason behind the web development?
• To facilitate the farmers and consumers to fulfill their needs
4. What are planned and existing systems?
• There are few websites related to this project but no one is offering
Shared Economy. Our website has a module of Shared Economy.

3.8. System Requirements

Requirement phase is the most tricky and valuable phase for our system. There are
two types of main requirements that exists.
• Functional Requirements
• Non-Functional Requirements

3.8.1. Functional Requirements

3.8.1.1. Register user

The user makes his account and then allowed to interact further with the system.

3.8.1.2. Select Field

After getting register the user can select his/her field from the map shown on
website.

3.8.1.3. Add new Product in C2C Market

User can add new products in C2C Market to sale his/her products to other users.

3.8.1.4. Add new Product in Shared Economy

User can add new products in Shared Economy to give products on rent to other
users.

3.8.1.5. See products published by other users

Users can see the products that are published by other users.

13
`

3.8.1.6. Connect with other users

User can see the contact number provided by other user and can contact with them
to make a deal.

3.8.1.7. View product history

A user can see his history of products which are published by him/her.

3.8.1.8. View Expert Reviews

User can get benefit from the reviews provided by experts that are shown on the
website.

3.8.1.9. Check health of crops

User can check health of crops by seeing maps that are provided on website.

3.8.1.10. Update product specification

User can update the specification of product that is published by him/her.
Table 3 Requirements of system
Requirement Number (RQ#) NAME

RQ 1 Register user
RQ 2 Select field
RQ 3 Add new product in C2C Market
RQ 4 Add new product in Shared Economy
RQ 5 See products published by other
users
RQ 6 Connect with other users
RQ 7 View product history
RQ8 View Expert Reviews
RQ9 Check Health of Crops
RQ10 Update product specification

3.8.2. Non-Functional Requirements

Nonfunctional requirements that are used to judge the operation of the system
rather than specific behavior.

3.8.2.1. User Interface Specifications

The user interface will be kept simple so that users that are not as knowledgeable

14
`

with computers can use this system. This will be done using labeled buttons and
forms used to drive the system. “We selected a view able color combination with a
sequence of forms with easy steps. Farmer and consumer can easily interact with the
system and use agriculture services within few clicks.

3.8.2.2. Performance
It defines the response time of our website. It also includes the speed with which our
website work. Response time of the website should be no more than 0.2 seconds.
Startup time should be less than or equal to 1 second.

3.8.2.3. Usability
The interface of our website is kept as simple as possible. We have tried our best to
make it understand by every user because the esthetics of every person is different
from each other. They are self-defining and in simpler words that very much easy to
use, use the standard colors, and updated design layout.

3.8.2.4. Accuracy
• Our website tries to achieve 100% accurate results. We have to done a lot of
work for the accuracy of the results that come as an output of our website
because if your website is not generating accurate results then it is of no use.
• The website will show the health of crops accurately.

3.8.2.5. Security
Some organizations want to work in a secure environment. We will provide that type
of environment.

3.8.2.6. Availability
• The website is accessible at any time when the user needs it.
• The website will be available to use 24 hours, seven days each week.

3.8.2.7. Maintainability
A team of developers will be available after the production of website to maintain it
and resolve bugs.

3.9. Use case diagram

Smart Agriculture Platform system use case

15
`

Register User

Select Field

Add Product in
C2C Market

Add Product in
Shared Economy

View Products

Connect
with Others
Farmer

View Product
History

View Expert Reviews

Check Crop
Health

Edit Product
Specification

Figure 3.2 Smart Agriculture Platform use case

3.9.1. Requirement Based Use Case Diagram
This section briefly explains the requirement wise functionalities of Smart Agriculture
Platform that are related to registration module of this system.

16
`

3.9.1.1. User Registration Use Case Diagram

Figure 3.3 describe the registration module. “This requirement describes that how
user (farmer/consumer) get registered with website. In registration procedure,
record of user is validated by using user interface constraints and authenticate by
matching it with database record that it exists previously or not.” If no existence
occurs than record is saved in database.

Figure 3.3 Register Use Case Diagram

3.9.1.2. Select Field Use Case Diagram
This figure describes how user can select field by giving name to field.

Figure 3.4 Select Field Use Case Diagram

17
`

3.9.1.3. Add Product in C2C Market Use Case Diagram

This figure 3.5 describes requirement of user to add item/product in C2C Market.

Figure 3.5 Add Item in C2C Market Use Case Diagram

3.9.1.4. Add Item in Shared Economy Use Case Diagram
Figure 3.6 describes requirement of user to add item/product in Shared Economy.

Figure 3.6 Add Item in Shared Economy Use Case Diagram

18
`

3.9.1.5. View Products Use Case Diagram

This figure 3-7 describes requirement of user to view products that are published by
other users according to month/date, Name or Area.

Figure 3.7 view Products Use Case Diagram

3.9.1.6. Connect With Users Use Case Diagram
User can make his/her profile and can connect with other user by seeing contact
information in details of product of interest.

Figure 3.8 Connect with Users Use Case Diagram

19
`

3.9.1.7. View Product History Use Case Diagram

User can view the product history of products which are published by him/her.

Figure 3.9 Connect with Users Use Case Diagram

3.9.1.8. Change Product Specification Use Case Diagram
User can change specification of specific product which is published by him/her.

Figure 3.10 Change Product Specification Use Case Diagram

20
`

3.9.2. Fully Dressed Use Cases

3.9.2.1. Register User Use Case Table

Table 4 describes fully dressed use case of User Registration in tabular form. Primary
actors of this use case are Farmer and Consumer. Preconditions required for this
action is that user must sign up for new account.
Table 4 Register user
Use case section Comments
Use case name Register user
Scope Smart Agriculture Platform
Level User goal level
Primary actors farmer, consumer

Stakeholder User: User registers himself/herself to further use the

system.
Preconditions Sign up for new account.

Success guarantee Massage received and Dashboard page open.

Main success scenario The user (farmer/consumer) goes to system and sign up
for new account. System asks different questions for
basic requirements e.g., name, date of birth etc. After
that user is given with new account and system opens a
Dashboard page and a massage is received in notification
to user. After that user (farmer/consumer) selects his
concerning event and log out satisfactory.
Extension At any time, The System fails: Restart the system

Login Repeat the process. The parameters entered for

login are not valid. Error message is generated. The user
(farmer/consumer) re-enters the username and
password.
Special requirements User (farmer/consumer) must go to sign up. System
must ask for user info. Dashboard page should be
opened when process complete.

21
`

Frequency of Once
Occurrence

3.9.2.2. Select Field Use Case Table

Table 5 describes fully dressed use case of Select Field in tabular form. Primary
actors of this use case is Farmer. Preconditions required for this action is that user
must be logged in.
Table 5 Select Field
Use case section Comments
Use case name Select Field

Scope Smart Agriculture Platform

Level User goal level
Primary actors Farmer
Stakeholder User: Farmer selects his field from the map that is shown
on website.
Preconditions Login page opens.
Success guarantee Massage shown to the user of sending request.
Main success scenario User (farmer) open login page.
User (farmer) enters id and password. User (farmer) put
his request and a massage will be shown on screen.
Extension The parameters entered for login are not valid. Error
message is generated. The user re-enters the username
and password. 1a. Forget password: Answer the
questions about your basic info.
Special requirements User (farmer) must have id and password.
Frequency of Continuous
occurrence

3.9.2.3. Add Item in C2C Market Use Case Table

Table 6 describes fully dressed use case of Add Item in C2C Market in tabular form.
Primary actors of this use case are Farmer and Consumer. Preconditions required for
this action is that user must be logged in.
Table 6 Add Item in C2C Market
Use case section Comments

22
`

Use case name Add Item in C2C Market

Scope Smart Agriculture Platform
Level User goal level
Primary actors Farmer, Consumer
Stakeholder User Add item in shared economy to sale his/her item.

Preconditions User (farmer, consumer) must be login and authenticated

by the system.
Success guarantee Message is shown upon publication of item.

Main Item is displayed to user after publication.

success scenario
Extension If the system doesn’t respond on request: Login again to
the system.
Again add item in C2C Market.
Special requirements User (Farmer) must have id and password.
Frequency Continuous

of occurrence

3.9.2.4. Add Item in Shared Economy Use Case Table

Table 7 describes fully dressed use case of Add Item in Shared Economy in tabular
form. Primary actors of this use case are Farmer and Consumer. Preconditions
required for this action is that user must be logged in.
Table 7 Add Item in Shared Economy
Use case Comments
section
Use case name Add Item in Shared Economy
Scope Smart Agriculture Platform

Level User goal level

Primary actors Farmer

Stakeholder User: User Add item in shared economy to sale his/her

item.

23
`

Preconditions Login page opens.

Success guarantee Message is shown upon publication of item.

Main success scenario Item is displayed to user after successful publication of

item.

Extension The parameters entered for login are not valid.

Error message is generated.

The user (Farmer) reenters the username and password.

1a. Forget password: Answer the questions

about your basic info.
Special requirements User (Farmer) must have id and password.

Frequency of Continuous
occurrence

3.9.2.5. View Products Use Case Table

Table 8 describes fully dressed use case of View Products in tabular form.
Preconditions required for this action is that user must be logged in.
Table 8 View Products
Use case section Comments

Use case name View Products

Scope Smart Agriculture Platform
Level User goal level
Primary actors User
Stakeholder User: User can view products which are published by
other users.
Preconditions Login to the system.
Success guarantee Products displayed to user.
Main success scenario User log in to system by entering his password and view
products.
Extension At any time, if the System fails: Restart the system
Login

24
`

Repeat the process.

Special requirements N/A

Frequency of Continuous
occurrence

3.9.2.6. Connect With Users Use Case Table

Table 9 describes fully dressed use case of Connect with Users in tabular form.
Preconditions required for this action is that user must be logged in.
Table 9 Connect With Users
Use case Comments
section
Use case name Connect With Users

Scope Smart Agriculture Platform

Level User (Farmer, Consumer) goal level

Primary actors User (Farmer, Consumer)

Stakeholder User: User (Farmer, Consumer) Connect with users by

viewing contact info of other users.
Preconditions Login page opens.

Success guarantee User (Farmer, Consumer) can see the Contact info in
details of product.
Main success scenario User (Farmer, Consumer) open login page.

User (Farmer, Consumer) enters id and password.

User (Farmer, Consumer) search for product.

User (Farmer, Consumer) can see contact info.

Extension
The parameters entered for login are not valid. Error
message is generated. The User (Farmer, Consumer) re-
enters the username and password.1a. Forget password:
Answer the questions about your basic info.
Special requirements User (Farmer, Consumer) must have id and password.

Frequency of Continuous

25
`

occurrence

3.9.2.7. View Product History Use Case Table

Table 8 describes fully dressed use case of View Product History in tabular form.
Preconditions required for this action is that user must be logged in.
Table 10 View Product History
Use case Comments
section
Use case name View Product History
Scope Smart Agriculture Platform

Level User goal level

Primary actors User

Stakeholder User: Can View History of products published by him.

Preconditions Admin must be login and authenticated by the system.

Success guarantee Contact info is displayed on the details page.

Main success scenario User login to the system through his account. User go to
“My Ads” page to view product history.

Extension
If the system doesn’t respond on request: Login again to
the system 2. Again, request for generate cause.
Special requirements User login to system.

Frequency of Near continuous

occurrence

3.9.2.8. Change Product Specification Use Case Table

Table 11 describes fully dressed use case of Change Product Specification in tabular
form. Preconditions required for this action is that user must be logged in.
Table 11 Change Product Specification
Use case section Comments
Use case name Change Product Specification
Scope Smart Agriculture Platform

26
`

Level User goal level

Primary actors Farmer
Stakeholder User: user (Farmer) wants to change specification of
product.
User: user (Consumer) see changes in details of product.
Preconditions Login page opens.
Success guarantee Message shown upon changes in specification.
Main success scenario User (Farmer) open login page.
User (Farmer) enters id and password.
User (Farmer) committed to change and a massage is
displayed on the screen.
Extension The parameters entered for login are not valid. Error
message is generated. The user (Farmer) reenters the
username and password. Forget password: Answer the
questions about your basic info.
Special requirements User (Farmer) must have id and password.

Frequency of Continuous
occurrence

3.10. Design
Systems design is the process of defining the architecture, components, modules,
interfaces, and data for a system to satisfy specified requirements.

3.11. Architecture
The Architectural design can be called the 'solution phase' of the life cycle because it
defines the software in terms of the major software components and interfaces. The
'Architectural Design' covers all the requirements as it establishes the framework of
software.

3.11.1. System Architecture

27
`

Figure 4.11 System Architecture

This figure shows the architecture of our website. This diagram shows that our
website use SQL Database to store and retrieve data of application. All data of
application store in SQL database. SQL Database is also use here to show the maps
and products published by other users. SQL provide real time tracking and upgrading
hence it is also use for communication purpose.

3.12. Design Constraints

There are some design constraints to enhance the usability of system like simple
words, fast and easy-to-use. These constraints are applied by considering about
users of system. As users of our system are mostly illiterate so, we have kept simple
design and used easy wording. So that, everyone can easily use the system. To fasten
the speed of system, animations are not used. In this way, webpage can be load
easily even on low internet connection. There is a trade-off between extraordinary
design and speed of system. In this system, speed is on high priority.

3.13. Design Methodology

Design Methodology adopted in development of “Smart Agriculture Platform” is
Component Based Development (CBD). In CBD, independent of anything else in the
website, each component performs its functionality on its own. After complete
development of system, each component is integrated with each other to function
within the whole.

28
`

Figure 4.12 Component Based Development Diagram

3.14. High Level Design
High Level Design (HLD) is general design of system. HLD refers to the overall design
of the system. Overall architecture of system is described in High Level Design (HLD).
It includes database design, relationship among modules, system description and
services. HLD is created before Low Level Design. Input for HLD is Software
Requirement Specification (SRS). Output of High Level Design is functional and
Database Design. Here are some viewpoints of High Level Design:

3.14.1. Conceptual or Logical view point

Conceptual view point is the presentation of logical functional elements of system.
Each component represents the similar grouping of functionality. In UML, there are
component diagrams to describe the conceptual or logical view point of system.

3.14.1.1. Component Diagram of User Registration

Fig. 4-3 represents the Component Diagram of User Registration which shows that
user must register first to use the system after successful registration, Dashboard is
opened.

Figure 4.13 Component Diagram of User Registration

3.14.1.2. Component Diagram of Shared Economy
Fig. 4-4 represents the Component Diagram of Shared Economy which shows that
user must login first to open Shared Economy after that he/she will be able to view
29
`

products. When user clicks on certain product, details of that product are shown.

Figure 4.14 Component Diagram of Shared Economy

3.14.1.3. Component Diagram of C2C Market
Fig. 4-5 represents the Component Diagram of C2C Market which shows that user
must login first to open C2C Market after that he/she will be able to view products.
When user clicks on certain product, details of that product are shown.

Figure 4.15 Component Diagram of C2C Market

3.14.1.4. Component Diagram of Select Field
Fig. 4-6 represents the Component Diagram of Select Field which shows that user
must login first to open Select Field after that he/she will be able to draw field on

30
`

map.

Figure 4.16 Component Diagram of Select Field

3.14.2. Process View Point
This view is the runtime view of the system. The components are threads or
processes or distributed applications. In UML, this would be a process interaction
diagram or sequence diagram.

3.14.2.1. Sequence Diagram of User Registration

This figure describes that how user (farmer/consumer) register itself. First, he/she
interact with signup interface. Here user enter required detail and after
authentication user can be sign in.

31
`

Figure 4.17 Sequence Diagram of User Registration

3.14.2.2. Sequence Diagram of Select Field
This figure describes that how user sign-in first. Then, he/she interact with select
field interface. Here user draw field on map that is shown on website after that the
selected field is stored in database.

32
`

Figure 4.18 Sequence Diagram of Select Field

3.14.2.3. Sequence Diagram of Add New Item
This figure describes that how user sign-in first. Then, he/she interact with Add New
Item interface of C2C Market or Shared Economy. Here user enters the details of
product after that the item is stored in database.

Figure 4.19 Sequence Diagram of Add Item

33
`

3.14.3. Physical View Point

This view is for distributed systems. The components are physical processors that
have parts of the system running on them. For UML, this would be a deployment
diagram.

3.14.3.1. Deployment Diagram

Smart Agriculture Platform is web based platform. Figure shows deployment diagram
of our website and somehow this picture describe the three tiers of web
architecture.

Figure 4.20 Deployment Diagram

3.15. Low Level Design
Low Level Design (LLD) is component level design process. It is the detailed
description of HLD. LLD includes actual logic of each system component and
describes specification of each module. LLD is create after High Level Design. Input
for LLD is improved High Level Design. Output of Low Level Design is unit test plan
and program specification.

3.16. Database Diagram

Figure 4.21 Database Diagram

34
`

Chapter 4. Results and Conclusion

The next most important and phase after the successful implementation of system
development life cycle is System testing. In this phase the tester should know about
the specification or characteristics of that thing which is going to be tested. In the
terms of software engineering, we should know its specifications before testing and
these specifications are basically the Elicitation and Requirements discovery of that
system from the Stack holders. The most important phase before testing is
verification and validation.

4.1. Verification & Validation

In this phase before testing of the system the requirements of the system are put in
the form of a check list and then the system is executed and compared with the
requirements mentioned on the check list and checked all as the overall functionality
of the system is same as that were documented in the Requirements Phase. In this
way the system is verified and for validation process we had interacted with the
stakeholders and show them the full executable System and compare their
Expectations from the system with the actual operation of the system. Their
Expectations were also same as the system is implemented so in this way the System
is also validated. Now we are able to formally starting the testing phase of system.

4.2. System Testing

The testing performed of this system is Alpha-testing (indoor-testing) as it is
completely tested by the tester of our group so we are responsible of in case of any
defect or error in the system. Two Prominent ways of testing the system are follows:

4.2.1. Black Box Testing

This technique of involves the testing of the system without having any knowledge of
the interior working of the system or how the system is implemented is called black
box testing. It is not mandatory that the tester should be developer as in this
technique no knowledge of coding or programming is required. While black box
testing the tester will only interact with the system’s user interface by providing
inputs and examining corresponding outputs in accordance to the test cases written
before without knowledge that how corresponding outputs are generated.

35
`

Figure 5.22 black box testing

4.2.2. White Box Testing
White box testing is the detailed investigation of the internal logic and structure of
the code of that system which has to be tested. In this technique the tester should
be a developer as well for having a good knowledge about the programming as here
the tester needs to look inside the code for each statement. If code works
appropriately then the tester should have to investigate why & how Code is working
appropriately. And If the Code work inappropriately then the tester should have to
investigate why & how Code is working inappropriately. In White Box testing, two
things are investigated
• Control Flow of System or Module
• Data Flow of system or module.

Figure 5.23 White Box Testing

36
`

4.3. Adapted Methodologies

The system is implemented in terms of pair programming where one developer had
already reviewed the code so there is no need to check the code again through white
box testing.” So according to the size, complexity and type of this system the
methodology adopted for testing is: “Black Box texting”.

4.4. Test Cases against Function Requirements

Test cases are written before implementation of the system according to the
Expected input, Expected output and expected Behavior of the system. At the testing
phase the tester tested all modules and system according to the inputs defined in
corresponding test cases and then the corresponding test case is validated according
to the output of the module. The name of test case is self-explanatory that it
represents the condition being tested in particular test case.“The test cases contain
these parameters:
• Test Case Number (Here is the number of test case will be mentioned)
• Requirement Number (Here is the number of Requirement will be
mentioned)
• Test Scenario (what we want to test is clearly mentioned here)
• Test Steps (what steps are taken is clearly mentioned here)
• Test Data (Here the data provide for test is clearly mentioned)
• Expected Result (on that condition being tested, what should be the
expected result, is clearly mentioned here)
• Actual Result (The actual result is mentioned here)
• Tested by (Who performed the tests is mentioned here)

4.4.1. User Registration/login Test Case

Table 12 is the test case, designed for User Registration/Login module to test that is
this module is working properly or not. In this test case, User Registration/Login
module is tested with invalid data to check if it accepts invalid data or not.
Table 12 User Registration Test Case
Test Case 1
Requirement No. 1
Test scenario: Register user with Invalid data

37
`

Test Steps: Enter invalid mail address

Test Data: Aly00989098@mail.com
Expected Result: User Registration failed
Actual Results: Pass as Expected
Tested by: Team Smart Agriculture Platform

4.4.2. User Registration/login Test Case

Table 13 is the test case, designed for User Registration/Login module to test that is
this module is working properly or not. In this test case, User Registration/Login
module is tested with valid data to check if it accepts valid data or not.
Table 13 User Registration Test Case
Test Case 2
Requirement No. 2
Test scenario: Register user with valid data
Test Steps: Enter valid mail address
Test Data: AAJ@gmail.com
Expected Result: User Registration failed
Actual Results: Pass as Expected
Tested by: Team Smart Agriculture Platform

4.4.3. Add Item Test Case

Table 14 is the test case, designed for Add Item in C2C/Shared Economy module to
test working of module. In this test case, Add Item in C2C Market/Shared Economy
module is tested with valid data to check if it accepts valid data or not.
Table 14 Add Item Test Case
Test Case 3
Requirement No. 3
Test scenario: Add item with valid data
Test Steps: Add item with proper description
Test Data: Russi Tractor
450000

03073029727

Russi Tractor in good condition and

low price

Samnabad Faisalabad
Expected Result: Item Added Successfully

38
`

Actual Results: Pass as Expected

Tested by: Team Smart Agriculture Platform

4.4.4. View Products Test Case

Table 15 is the test case, designed for View Products module to test the working of
this module. In this test case, View Products module is tested by searching the
products with specific location to check if it shows the products of that location or
not.
Table 15 view products Test Case
Test Case 4
Requirement No. 4
Test scenario: View products
Test Steps: View products according to location
Test Data: Samnabad
Expected Result: Relevant products shown successfully
Actual Results: Pass as Expected
Tested by: Team Smart Agriculture Platform

4.4.5. View Item History Test Case

Table 16 is the test case, designed for Show Item Records module to test the
working. In this test case, Show Item Records module is tested by searching the
logged in user’s published items with specific date/month.
Table 16 view item history Test Case
Test Case 5
Requirement No. 5
Test scenario: Show item record
Test Steps: Show history of published items
Test Data: January
Expected Result: Item history shown
Actual Results: Pass as Expected
Tested by: Team Smart Agriculture Platform

4.4.6. Contact Others Test Case

Table 17 is the test case, designed for Contact Others to test the working of module.
In this test case, details of Item is opened to check if it shows the contact info of user
who published that specific product/item.
Table 17 Contact Others Test Case

39
`

Test Case 6
Requirement No. 6
Test scenario: Contact others
Test Steps: Open item details to view contact info
Test Data: View Contact Info in item details
Expected Result: Contact Info Shown
Actual Results: Pass as Expected
Tested by: Team Smart Agriculture Platform

4.5. Devices used for Functional Requirements testing

Table 18 shows the Details of devices on which this system is tested. On many
different devices this system is tested to check the responsiveness of system.
Table 18 Testing Devices Detail
Device name Device Type
Moto G4 Cell phone(virtual)
Pixel 2 XL Cell phone(virtual)
iPhone X Tablet(virtual)
Galaxy Fold Cell phone(virtual)
iPad Laptop(virtual)

4.6. Usability Test Case

4.6.1. Aesthetics Test
Table 19 shows the aesthetic test case designed to test the aesthetic aspects of
system. Different users are asked about aesthetic aspects of system.
Table 19 Aesthetics Test Case
Test Case 1
Test Case name Aesthetics
No. of users 10
Test Steps: Ask users about aesthetic aspects of
website.
Expected Result: Good response about aesthetics.
Actual Results: Pass as Expected
Tested by: Team Smart Agriculture Platform

4.6.2. Ease test

Table 20 shows ease test case designed to test the easiness of system. Different

40
`

users are asked about aesthetic aspects of system.

Table 20 Ease Test Case
Test Case 2
Test Case name Easy to use
No. of users 10
Test Steps: Ask users is this website is easy to
operate.
Expected Result: Good response about application
operations.
Actual Results: Pass as Expected
Tested by: Team Smart Agriculture Platform

4.6.3. Stress Test Case

Table 21 shows stress test case designed to test the working of system under stress.
Different users are asked to use system at same time to check system performance.
Table 21 Stress Test Case
Test Case 3
Test Case name Stress test
No. of users 10
Test Steps: Ask users to use this website at the
same time.
Expected Result: Good response about operations
under stress.
Actual Results: Pass as Expected
Tested by: Team Smart Agriculture Platform

4.7. User Manual

4.7.1. Smart Agriculture Platform Interfaces

This section briefly explains the all interfaces of Smart Agriculture Platform.

4.7.1.1. User Registration Interface

Figure 6.1 describe the registration panel for Users. Mail has to be entered for
registration process after Authentication successfully an account is allocated to user.

41
`

Figure 6.24 User Registration interface

4.7.1.2. User Login Interface

Figure 6.2 shown below is the interface to which user will interact for login.

Figure 6.25 User Login Interface

4.7.1.3. User Dashboard Interface

These figure show functions for farmer and consumer.

42
`

Figure 6.26 User Login Interface

4.7.1.4. C2C Market Interface

Figure 6.4 shows the C2C Market Interface of website.

Figure 6.27 C2C Market Interface

4.7.1.5. Shared Economy Interface

Figure 6.5 shows the Shared Economy Interface of website

43
`

Figure 6.28 Shared Economy Interface

44
`

4.8. References
• Handbook of agricultural economics Gardner, Bruce L., Rausser, Gordon C.,
Pingali, Prabhu L. and Evenson, Robert E.

• Agricultural sector and industrial agglomeration Picard, Pierre M. and Zeng,

Dao-Zhi

• Con cojones y maestría Remmers, Gaston G.A.

• Asian change in the context of global climate change Galloway, James. and
Melillo, Jerry M.
• Natural resources management in African agriculture Barrett, Christopher B.,
Place, Frank. and Aboud, Abdillahi A.
• Genetically Modified Food and Global Warfare Carter, Colin.

• Biotechnology, agriculture and development Phillips, Peter W. B.

• Agent-Based Simulation: From Modeling Methodologies to Real-World
Applications
• Usability and Internationalization. Global and Local User Interfaces Aykin,
Nuray.
• Re-imagining Diffusion and Adoption of Information Technology and Systems:
A Continuing Conversation Radical Technologies Greenfield, Adam.
• The impact of the COVID-19 pandemic on Green societies Chakraborty,
Chinmay., Roy, Swapnila., Sharma, Susmita. and Tran, Tien Anh
• Practising feminist political ecologies Harcourt, Wendy. and Nelson, Ingrid L

• The making of Olympic cities Gold, John Robert. and Gold, Margaret M
• The Impact of the COVID-19 Pandemic on Green Societies Chakraborty,
Chinmay., Roy, Swapnila., Sharma, Susmita. and Tran, Tien Anh
• Sustainable human-nature relations Cirella, Giuseppe Tommaso

• Encyclopedia of sustainability science and technology Meyers, Robert A

• Environmental sustainability in transatlantic perspective Achilles, Manuela.
and Elzey, Dana M
• The making of Olympic cities Gold, John Robert. and Gold, Margaret M.

45