Template-05 - Project Report (Part-1) - 1

SUPERIOR UNIVERSITY LAHORE
Faculty of Computer Science & IT
Final Year Project

PROJECT REPORT (Part-1)
Share Happiness
Project ID: FYP-BSSE-F18-036
Project Team
Student Name Student ID Program Contact Number Email Address
Adnan Waheed BSEM-F15-198 BSSE 0334-5783257 Malik.hanny1@gmail.com
Imran Siddique BSEM-F15-240 BSSE 0307-4424225 Siddiqueimran1994@gmail.com
Waseem Shah BSEM-F15-199 BSSE 0303-9320769 Waseemsh306@gmail.com
Muhammad Waseem Iqbal

Assistant Professor
Project Report: < Share Happiness>
Project Report
Share Happiness
Change Record
Author(s) Version Date Notes Supervisor’s Signature
1.0 <Original Draft>
<Changes Based on
Feedback from
Supervisor>
<Changes Based on
Feedback From Faculty>
<Added Project Plan>
<Changes Based on
Feedback from
Supervisor>
Faculty of CS&IT, Superior University Lahore, Pakistan ii

APPROVAL
PROJECT SUPERVISOR
Comments: ___________________________________________________________________
_____________________________________________________________________________
Name:______________________________
Date:_______________________________ Signature:__________________________
PROJECT MANAGER
Comments: ___________________________________________________________________
_____________________________________________________________________________
Date:_______________________________ Signature:__________________________
HEAD OF THE DEPARTMENT

Comments: ___________________________________________________________________
_____________________________________________________________________________
Date:_______________________________ Signature:__________________________
Faculty of CS&IT, Superior University Lahore, Pakistan iii

Dedication
This work is dedicated to our hero “Abdul Sattar Edhi”.

Abdul Sattar Edhi was an award-winning philanthropist and humanitarian. Known in Pakistan as
"Angel of Mercy" and "Pakistan's Father Teresa" for his social work that also won international
acclaim,
Faculty of CS&IT, Superior University Lahore, Pakistan iv

Acknowledgements
We would like to express our deepest appreciation to all those who provided us the possibility
to complete this project. A special gratitude we give to our final year project supervisor Mr.
Waseem Iqbal & all teachers whose contribution in stimulating suggestions and
encouragement helped us to coordinate our project especially in writing this report.
Faculty of CS&IT, Superior University Lahore, Pakistan v

Executive Summary
In the whole world, so many people have many extra things that they do not utilize. These thing
are useless for them but are more important to other people. E.g. the home appliances,
electronic devices, books, furniture and the most important thing is food. About 40% of things
we purchase are useless for us after few months. These are important to these people who
can’t afford it.
Keeping all these problems in mind, we have motivation to provide the solution for needy
people. Share Happiness is the first online platform in Pakistan, which gives easy access to the
customers to donate their useless or spare things to the needy people. This platform will be
very helpful to the needy people to fulfill their requirements. We follow Edhi’s philosophy of
contributing to humanitarian crisis all over the world in exceptional circumstances.
Faculty of CS&IT, Superior University Lahore, Pakistan vi

Table of Contents
Dedication .......................................................................................................................................iv
Acknowledgements..........................................................................................................................v
Executive Summary.........................................................................................................................vi
Table of Contents ........................................................................................................................... vii
List of Figures .................................................................................................................................. ix
List of Tables ....................................................................................................................................x
Chapter 1......................................................................................................................................... 1
Introduction .................................................................................................................................... 1
1.1. Background....................................................................................................................... 2
1.2. Motivations and Challenges ............................................................................................. 2
1.3. Goals and Objectives ........................................................................................................ 3
1.4. Literature Review/Existing Solutions ............................................................................... 3
1.5. Gap Analysis ..................................................................................................................... 4
1.6. Proposed Solution ............................................................................................................ 4
1.7. Project Plan ...................................................................................................................... 5
1.7.1. Work Breakdown Structure .......................................................................................... 5
1.7.2. Roles & Responsibility Matrix ....................................................................................... 6
1.7.3. Gantt Chart ................................................................................................................... 7
Chapter 2......................................................................................................................................... 8
Software Requirement Specifications ............................................................................................ 8
2.1. Introduction...................................................................................................................... 9
2.1.1. Purpose ......................................................................................................................... 9
2.1.2. Document Conventions ................................................................................................ 9
2.1.3. Intended Audience and Reading Suggestions .............................................................. 9
2.1.4. Product Scope ............................................................................................................. 10
2.1.5. References .................................................................................................................. 10
2.2. Overall Description ......................................................................................................... 11
2.2.1. Product Perspective.................................................................................................... 11
2.2.2. Product Functions ....................................................................................................... 11
2.2.3. User Classes and Characteristics ................................................................................ 12
2.2.4. Operating Environment .............................................................................................. 12
2.2.5. Design and Implementation Constraints .................................................................... 13
2.2.6. User Documentation .................................................................................................. 13
2.2.7. Assumptions and Dependencies ................................................................................ 14
2.3. External Interface Requirements ................................................................................... 14
2.3.1. User Interfaces............................................................................................................ 14
2.3.2. Hardware Interfaces ................................................................................................... 14
2.3.3. Software Interfaces .................................................................................................... 14
2.3.4. Communications Interfaces ........................................................................................ 15
2.4. System Features ............................................................................................................. 15
Faculty of CS&IT, Superior University Lahore, Pakistan vii

2.4.1. System Feature 1 ........................................................................................................ 16

2.4.1.1. Description and Priority .......................................................................................... 16
2.4.1.2. Stimulus/Response Sequences ............................................................................... 16
2.4.1.3. Functional Requirements ........................................................................................ 16
2.4.2. System Feature 2 ........................................................................................................ 17
2.4.2.1. Description and Priority .......................................................................................... 17
2.4.2.2. Stimulus/Response Sequences ............................................................................... 17
2.4.2.3. Functional Requirements ........................................................................................ 17
2.4.3. System Feature 3 (and so on) ..................................................................................... 18
2.5. Other Nonfunctional Requirements .............................................................................. 20
2.5.1. Performance Requirements ....................................................................................... 20
2.5.2. Safety Requirements .................................................................................................. 20
2.5.3. Security Requirements ............................................................................................... 20
2.5.4. Software Quality Attributes ........................................................................................ 21
2.5.5. Business Rules............................................................................................................. 21
2.6. Other Requirements....................................................................................................... 22
Chapter 3....................................................................................................................................... 23
Use Case Analysis .......................................................................................................................... 23
3.1. Use Case Model .............................................................................................................. 25
3.2. Fully Dressed Use Cases ................................................................................................. 26
Chapter 4....................................................................................................................................... 33
System Design ............................................................................................................................... 33
4.1. Architecture Diagram ..................................................................................................... 34
4.2. Domain Model ................................................................................................................ 35
4.3. Entity Relationship Diagram with data dictionary ......................................................... 36
4.4. Class Diagram ................................................................................................................. 37
4.5. Sequence / Collaboration Diagram ................................................................................ 38
4.6. Operation contracts ....................................................................................................... 39
4.7. Activity Diagram ............................................................................................................. 40
4.8. State Transition Diagram................................................................................................ 42
4.9. Component Diagram ...................................................................................................... 43
4.10. Deployment Diagram.................................................................................................. 44
4.11. Data Flow diagram [only if structured approach is used - Level 0 and 1] ............. Error!
Bookmark not defined.
Chapter 5....................................................................................................................................... 45
Implementation ............................................................................................................................ 45
5.1. Important Flow Control/Pseudo codes .......................................................................... 46
5.2. Components, Libraries, Web Services and stubs ........................................................... 46
5.3. Deployment Environment .............................................................................................. 47
5.4. Tools and Techniques ..................................................................................................... 47
5.5. Best Practices / Coding Standards.................................................................................. 48
5.6. Version Control .............................................................................................................. 48
Appendices.................................................................................................................................... 49
Appendix A: Information / Promotional Material ........................................................................ 50
Faculty of CS&IT, Superior University Lahore, Pakistan viii

Reference and Bibliography .......................................................................................................... 53

Index.............................................................................................................................................. 55
List of Figures
1.1 Caption of first figure of first chapter 6

1.2 Caption of second figure of first chapter 7
2.1 Caption of first figure of second chapter 14
2.2 Caption of second figure of second chapter 22
2.3 Caption of third figure of second chapter 26
5.1 Caption of first figure of fifth chapter 49
5.2 Caption of second figure of fifth chapter 49
Faculty of CS&IT, Superior University Lahore, Pakistan ix

List of Tables
1.1 label of first table of first chapter 6

1.2 label of second table of first chapter 7
2.1 label of first table of second chapter 14
2.2 label of second table of second chapter 22
2.3 label of third table of second chapter 26
5.1 label of first table of fifth chapter 49
5.2 label of second table of fifth chapter 49
Faculty of CS&IT, Superior University Lahore, Pakistan x

Chapter 1
Introduction
Chapter 1: Introduction
This is a social application designed to provide the necessary information for people to take the
initiative and support each other. This application allows their users to search based on their
location for the nearest people in need according to the type of help they could provide.
On the other hand, it also allows other people to share information about their needs and ask
for help in a modern and less embarrassing way. This software will make it easier for anyone to
donate anything they want in a simple way and the least troubling way, because it shows the
nearest possible people who need help. Some might ask, if a person is actually in need, they
won’t have access to the modern technologies. My answer to that is that anyone can create a
profile for these people, by simply provide their location and their contacts. Again, this might
not be the case for some families; however, this project is designed to help those who can’t
help themselves, and also get people to take the initiative, either donating or by creating
profiles for people they know who might need help.
Background
As we know that Pakistan is one of the countries in the world which is facing internal and
external crisis. In this scenario it is quite difficult to help poor and needy people, So we as a
team decided to make such application which will help poor and needy peoples. we decided to
make the app which will help users to donate waste are spare stuff within no time. Keeping all
these problems in mind, we have motivation to provide the solution for needy people. The
Food and Agriculture Organization of the United Nations (FAO) estimates that, each year, one-
third of all food produced for human consumption in the world (around 1.3 billion tons) is lost
or wasted. And the other side over 7.6 billion people in the world who don’t have food to eat.
Therefore, our online platform help these needy or hungry people.
Faculty of CS&IT, Superior University Lahore, Pakistan 2

.1. Motivations and Challenges

More than 60 percent population of Pakistan consist of youngsters and majority of them have
access to mobile phone so targeting them with the model we describe above is not difficult so
we decided to make app. The main challenge is to fit our app in to the Play store, For that
reason we have study the android studio and others tools and try to learn the trends of Android
application market trends.
Next step was making such app which attracts customers and charity organization. So we set
the application interface according to market trend.
.2. Goals and Objectives

Goal:
 The share happiness System is for the charity organizations to reduce the market gap.
 Improve the procedures of donating waste and useless thing to the needy and poor
peoples.
Objectives
 Our main objective is to create a Charity application than can run on android devices, by
the app creating tool called android studio. To help the charity organizations.
 Saved waste material like food, cloths & books etc. by donate to the needy or poor
peoples.
 Contributing to humanitarian crisis all over the world in exceptional circumstances.
.1. Literature Review/Existing Solutions

As we know there are many charity organizations are working similarly. But the important fact
of our application is that we saved the wasting material for the help of poor/needy people. In
current situation we think there is no such platform available yet to support the needy people.

.2. Gap Analysis

Since the major concern of our application is to make Pakistan’s NGO’s more effective.
As NGO’s is rapidly growing in Pakistan. On the other hand, these organization facing several
problems.
By market analysis there is no organization that gave access donor to donate directly to the
needy or poor people. The organizations collect stuff from donor and their self give to the poor
and needy people
There are many NGO’s that have online platform but on their website the user sees only donate
option but there is no option for user to search for a thing that he wants.
.3. Proposed Solution

We proposed an online platform in which the people can donate their useless Stuff to the
needy people. The people simply take pictures of Stuff and select category like home
appliances, furniture, books, food etc. give some detail like contact number, address and
description of stuff they want to donate. In addition, we have connected with charity
organization these organizations collect Stuff from donor and donate by self to the needy/poor
people.
After taking these steps, Insha’Allah in Pakistan and all over the world the ratio of the hungry &
needy people is less. And people who sleeps hungry is less. The hunger problem in the world
decrease rapidly.

.4. Project Plan

Project Plan includes two things.
 Work breakdown structure (WBS)
 Gantt chart consisting of Timeline with milestone.
.4.1. Work Breakdown Structure

.4.2. Roles & Responsibility Matrix

WB WBS Deliverable Activity # Activity to Complete Duration Responsible Team
the Deliverable (# of Member(s) & Role(s)
S#
Days)
1 Planning Purposal Proposal defence 10 days Waseem Shah

Imran Siddique
Adnan Waheed
2 Design App Asset App setup 30 day Imran Siddique
Waseem Shah
3 Coding Java Scripting of 60 day Imran Siddique
application Adnan Waheed
4 Testing & App test Testing the app 14 day Waseem shah
Debugging Imran siddique
5 Implementation Implement Develop the app 20 day Imran siddique

app Adnan Waheed
6 Documentation report Making report 20 day Imran, Siddique

Adnan Waheed
Waseem Shah

.4.3. Gantt Chart

Chapter 2
Software Requirement
Specifications

Chapter 2: Software Requirement Specifications

.1. Introduction
.1.1. Purpose
About 40% of things we purchase are useless for us after 6 months. These are important to
these people who can’t afford it.
Since the absolute prospects of its flourishment is evident and we need a proper technology-
oriented system for the charity organizations. The present tech-systems don’t cater all of the
requirements whereas the system we are proposing has all those functionalities that would
lessen gap between the donor and acceptor.
 No paper work required.
 No fear of loss of data.
 It is Time saving.
 All records are store at one place.
.1.1. Document Conventions

This project is based on charity organization and it is restricted within the University premises.
This has been implemented under the guidance of university faculty. This document follows
Calibri format and the font size is 11. Bold-faced text has been used to emphasize sections and
italicized text is used to label and recognize diagrams. And the all text is Justified
.1.2. Intended Audience and Reading Suggestions

The document is mainly created for the approval of our Final Year Project of Software
Engineering and hence the main intended audience is the approval panel of the Superior
University that will declare the status of our project. Also, the documentation may help the
team members (Adnan, Imran & Waseem shah) to keep a track of all aspects (features,
processes used, model used, risks identified, risks reasons, processes used to remove risks) of
the application and that will help for future improvements and updating in the application and
may also be essential when the team members may create a similar project. It may also help
the user to understand the project in detail.

.1.3. Product Scope

 Our application provides direct access to the donor and accepter, where the donor donate
stuff that they want to donate after registration, And the acceptor can easily search stuff
in specific category that he/she wants.
 If the users want to send their pin location, they also can but this is not compulsory for all
to add their pin location.
 The process will follow these steps. First of all, donor create an account and select a
category of stuff that he/she want to donate. Post picture of that stuff, add some info
about it, Post address and contact details. The donor can remove the stuff from there
account that are being donated.
 The accepter doesn’t need any account for search stuff. The acceptor can easily search
thing in specific category that they want.
.1.1. References
 IEEE Software Engineering Standards Committee, “IEEE Std 830-2016, IEEE Recommended
Practice for Software Requirements Specifications”, October 20, 2016.
 Edhi Foundation’s official website http://www.edhifoundation.com/
 Alternate website http://edhi.org/
 https://www.news.bbc.co.uk. (2018 Pakistan’s Savior of the Desperate’, by BBC News.
[online] Available at http://news.bbc.co.uk/1/hi/world/south_asia/1221986.stm

.1. Overall Description

.1.1. Product Perspective
While our project “Share happiness”, itself is not a continuation of any predecessor, its
implementation is made possible through the app development tool android studio and its
ability to compile and build updation for use on Android devices. Although it’s not a
continuation, but inspired by Edhi’s foundation & Falah-e-Insaniyat Foundation (FIF).
Since smartphones these days are full of tons of applications therefore, one of our goal while
designing the app is to be able to let the user understand the app at the first look no matter
how often and how least he opens the game, we are achieving this by showing the control
guide screen every time at the beginning of the app.
.1.2. Product Functions

Following Are the Major Features of the product:
 Donate Stuff:
The donor can donate stuff directly to the needy or poor people. There are no other
person involved. But in some cases the third are involved for the help of people that
don’t have a smart phone and don’t know about our application.
 Select between different Categories:
The donor selects the category of the thing that he wants to donate and the needy or
poor people can also select category of thing with the help of this the searching stuff is
very easy or fast
 Alerts Generation:
The donor gets alert when the new message is coming on the application. With the help
of alert generation, the donor notified when someone want to talk about stuff he want
to donate.
 User details:
The application is keep all the record of the user

 Past History Record:

The system keeps all the previous records of donor which are store in to the history. For
example it keeps all the previous donation of user. This is helpful when the donor post
new add the rating of the user are shown that are show the user past donation. The
rating is given by the other user that are collect stuff from the user before.
.1.3. User Classes and Characteristics

Admin:
 He would be able to control and see all the records and only he’d have authority to
access his account.
 He would be able to check on every record, and user details.
 Access to database and access to the admin menus.
Clients
 Clients would be able to operate the system only, and cannot make any substantial
 changes, whereas they’d be known about their details
 A user can check his adds details, he can place adds.
 He can contact the admin, and can give feedback that what needs to be changed
.1.4. Operating Environment

 Operating system: Android
 Database: SQL
 Platform: Android Studio
 Client/Server system

.1.1. Design and Implementation Constraints

Design:
 The Application is being developed by using Android studio.
 Data is managed with the help of SQLite.
 The purpose behind using Android for the development of share happiness application
is the ease and usability factor.
 This platform provides us with various options: Development of android applications,
SQL connectivity, and many more multiple functionalities.
 This software will be operable on android device.
Tools:
 Android Studio
 Draw.io or Visio.
 Corel Draw
Constraints:
 Security is the more important factor for the system. Each record must be secure and
manage. There is no loss of data.
 The system must be available at 24/7 so everyone access the system.
 The system should be scalable enough
 The user first has to register himself. If he is not registered the error message is
generated.
 Only authorize user use the application.
User Documentation:
 User manual files and also other help pages will be providing.
 If the user wants to add more features or queries there is also the contact page, through
which he can contact for the addition of more queries.
 There is also a page named complaints where the user can send their complaints.

.1.2. Assumptions and Dependencies

No special assumptions or dependencies have been identified for our charity project. else these
basic two, which are the assumptions / dependencies that can affect our Software
Requirements:
 Project member availability and performance: There can be some important or
emergency cases that can make one our team unavailable, this can have an influence on
the performance of development.
 Budget Limitations: Although the idea of developing a charity application eliminates the
need for expensive hardware and it does not require a big team to develop application.
but any failure in laptops/mobile device can cause the budget to a get influenced.
.2. External Interface Requirements
.2.1. User Interfaces

 Front-end: Xml
 Back-end: SQLite
.1.1. Hardware Interfaces

The hardware interfaces are the mobile or tab devices that will make users to be able to use the
application.
 Android Phones:
The game will be available for the Android phones users, hence will be available on Play
Store.
 Android Tabs:
As described above, the game will be available on Play Store, also the resolution and
graphics will be in a wise that will make able to run efficiently on big screens Android
Tabs too.

.1.1. Software Interfaces
Software used Description
We have chosen android operating system for its best support and
Operating system user-friendliness.
To save the waste things record and user records we have chosen
Database SQLite for database.
To implement the project we have chosen Xml for its interactive
Front end display.
Back end To fulfil the requirement we use java to perform its functionality
.1.2. Communications Interfaces

Following are the means of communication with our users:
 Our users will able to rate our application or give a written feedback through the Play
Store.
 The users will be allowed to directly email us to give a feedback or report an issue on
our email address that will be provided on apps store when downloading our application
and also in the application (by clicking on “contact us” button).
.2. System Features

<This template illustrates organizing the functional requirements for the product by system
features, the major services provided by the product. You may prefer to organize this section by
use case, mode of operation, user class, object class, functional hierarchy, or combinations of
these, whatever makes the most logical sense for your product.>

.2.1. System Feature 1

Posting add of waste and spare stuff
.2.1.1. Description and Priority
The application has the feature that allow user to post a add of that specific thing he
wants to donate. For post an add the user want to give some detail about stuff he want to
donate and a picture of that thing. As the app is regarding to the charity app that’s why,
post add are the most and having high priority.
.2.1.2. Stimulus/Response Sequences
To post an add the new user must sign up on our application through mobile number.
which will help the user to post the add. After posting the add, that user got the
confirmation message on their mobile number that registered on our application.
.2.1.3. Functional Requirements

Feature Requirements: Post an add
REQ-SF1-1:
Feature Name: Post an add
Description: This feature shall allow the user to post thing that he wants to donate.
REQ-SF2-2:
Feature Name: Delete the add.
Description: This feature shall allow the user to delete the add.
REQ-SF3-3:
Feature Name: Update the add.
Description: The feature shall allow the user to make some change in add.


Select between different Categories

The app has the feature to allow user to choose between different categories like if user
want to donate some book he can select the category of book. With the help of this
searching stuff is very easy and in less time.

To search stuff between different categories, the user must be registered on our
application. which will help us to improve the security. this will help in fast searching.

Feature Requirements: Select between different Categories
REQ-SF4-4:
Feature Name: search in different category
Description: This feature will help user to select specific category that he/she want to
donate or he/she needs


Alerts Generation:

This feature will help the donor when someone send message to the donor the donor get
notification alert of received message. We use this feature for better response and fast
response from the donor.

Stimulus: new message sends by the needy people.
Response: donor get alert of new message.
Stimulus: donor reply to the message.
Response: the needy also get notification of new message.

Feature Requirements: Alert’s Generation:
REQ-SF5-5:
Feature Name: Alerting the user about the new message.
Description: This feature will alert the donor about the new message related to the stuff
REQ-SF6-6:
Feature Name: Alerting the acceptor about the response from donor.
Description: This feature will notify the needy people when the donor replied to their
message.


Users Record:
Share Happiness System keeps all the records of the users. For example, their Name, CNIC,
Salary, their Contact numbers and all the personal details.

Stimulus: Add the Name, CNIC, contact number and city of all users.
Response: System will add the information of all users.
Stimulus: User requests to update its information.
Response: The records of that user will be updated by the system
Feature Requirements: User Record Management
REQ-SF7-7:
Feature Name: Add the user’s information
Description: This feature will store all the user’s information.
REQ-SF8-8:
Feature Name: Updating the employee’s information.
Description: This feature will allow the user to update his/her information.

.1. Other Nonfunctional Requirements
.1.1. Performance Requirements

 The application performance should be optimized, and response time should be
minimized
 The Share Happiness system must be very efficient
.1.2. Safety Requirements

 All the data of the user will remain safe and secured.
 In case if the user forgets his password or wants to change the password, the option of
“forget password” is available through which he can reset his password and all the
backups are available of his account that are used for his account recovery.
.1.3. Security Requirements

The system should be highly secure since only authenticated users can have access to the
server. It should respect the 3 aspects:
 Confidentiality:
 The user shall ensure who gets to see their information
 Integrity:
 Editing data shall be authorized only to owners of the accounts.
 Availability:
 The application shall be available at all times

.1.4. Software Quality Attributes

These are some of the most imperative quality factors that can affect the whole system:
 Availability:
App should be available at 24/7 hours and provides services to clients.
 Efficiency:
App should have efficiency in its performance/response time.
It can work properly without any failure.
 Flexibility:
App should be flexible enough to adapt the new changes with the passage of time.
If any change is required in feature, it should be able to manage the changes gracefully.
 Security:
App should be secure enough that no one can access personal data.
Security of the system is improved by installing firewalls and authorization processes.
 Portability:
App should be portable enough that it can easily be install on any android device.
 Usability:
App should be user-friendly and easy to understand.
Clients should be fully satisfied with it performance and its functionality.
 Maintainability:
App should be self- maintained and efficient.
It can maintain the new changes.
It can maintain all the records.
 Reusability:
App components/features should be designed in such a way that they can be used in other
applications too.
Reusability reduces the time and complexity.

Business Rules
 In requirement phase all the requirements are gathered and understand. User can also
change the requirements but there comes a point when all the requirements are freeze
i.e. no changes in requirements occur this phase is called the crystal requirements.
 Each develop conduct the meeting before implementing the functionality.
 Each developer must document after each phase.
 Hybrid approach follows i.e. waterfall and agile model.
 After each module implementation unit testing occurs.
 User satisfaction must be fulfill.
 Review meeting occurs in which problems and errors are identifying and fix.
.1. Other Requirements

Other requirements depend on the user with the time in near future. Because we all know that
user requirements changes continuously with the time.

Chapter 3
Use Case Analysis

Chapter 3: System Analysis

Share Happiness system is developed for the NGO’s. It can manage all the records. and also
describe the current status of poverty & needy peoples. The system have the multiple
functionalities which can be better understand through use case models. Each functional
requirement is describing through use case model which can describe its working in a better
way and is more understandable.

3.1. Use Case Model

Following use case diagrams, that are the graphic depiction of the interactions among the
elements of the application and actors of the application:
3.1.1 Use Case Diagram Share Happiness

3.1.2 Use Case Diagram Select Categories

3.1.3 Use Case Diagram Donor detail

3.2. Fully Dressed Use Cases

The following are the Fully Dressed Use Cases of the app of Share Happiness, that means, this
completes all the sections of the use case specifications i.e. the basic flow, the alternative flow,
special requirements, Pre/Post specifications are also described
Tittle Share Happiness
Primary Actors User
Secondary Actors Admin
Stake Holders Manager, Coder, User
Pre-conditions  The user must possess Android Phone/Android
Tablet.
 The user must download application from
PlayStore.
 The user must install the application after it is
downloaded.
Post-conditions  The application has been use by the user.
Status Under Development

Basic Flow  The app is being opened by the User and
Introduction starts.
 The application adds appears.
 User edit the post after login.
 User Delete the post.
 User report the bad ads.
 User view the ads no login require.
 Donor post the ads.
 Accepter(user)accept the thing after contact
the donor
 User exit the application

Alternate/Extended Flow 1. The game is being opened by the User and

Introduction starts.
1.2 The USER skips the introduction.
2: The application ads appear.
2.1 User clicks Rate Us.
2.2 User exit the application.
2.3 The User clicks Setting.
3: User Set Notifications.
4:user select the category and location then related
item display.
5: After selection the item user contact the donor.
If donor response “yes” than accepter accept he item
Otherwise return the ID:4
6: again this process.
7: if user any item post so login require.
8:If user does not do it, he will go back ID:2
9: If user do it, he will go back post ID.
10: After the post Donor not require logout the
application.
11: User logout the application
11.1 If user click “No”, flow transfers to Process
ID:2
11.2 If user click “Yes”, logout the application.

Tittle Select Categories

Primary Actors User
Stake Holders Manager, Coder, User, Play store
Tablet.
 The user must download application from Play Store.
downloaded.
 DONER and ACCEPTER must be login.
Post-conditions  Selected categories item/product available/not
available.
Basic Flow  The categories selection screen appears that select
the item.
 Item selection just like foods; Home Appliance,
shoes, cloths etc.
 After item selection accepter find the donor
location.
 After find location accepter contact the donor.

Alternate/Extended Flow 1. If categories selected
1.2 Selected item is not available.
1.3 Selected item is available.
2 If find the location
2.1 Item is available this location.
2.2 Item is not available this location
3.If accepter contact the donor

3.1 donor active
3.2 donor deactivate

Tittle Donor info

Primary Actors User
Stake Holders Manager, Coder, User
Tablet.
downloaded.
 Accepter must be contact the donor.
Post-conditions  Accepter contact the donor via SMS or phone call.

Basic Flow  After select the item accepter contact the donor
 Phone call
 Sms
 Chat
 After this process get location/address
Alternate/Extended Flow 1: If select the item accepter contact donor

1.2: call
1.3 sms
1.4 chat
2: If the call accepter to donor
2.1: Available
2.2: not available
3: If accepter send SMS to donor
3.1: Receive SMS
3.1: Not receive SMS/network problem

Chapter 4
System Design

Chapter 4: System Design

This chapter defines architecture, relationship & interface of the application to satisfy the needs
of user. This chapter emphasize on the application logic. Following diagrams are used to
emphasize the system design
4.1. Architecture Diagram

4.2. Domain Model

4.3. Entity Relationship Diagram with data dictionary

4.4. Class Diagram

4.5. Sequence / Collaboration Diagram

4.6. Operation contracts

Contract CO1: Share Happiness
Operation Share happiness

Name
Cross Reference Use Cases: share happiness
Pre-conditions  The user must possess Android Phone/Android Tablet. The user
must download application from Play Store.
 The user must install the application after it is downloaded.
Post-conditions  The application has been use by the user.
Contract CO2: Categories

Operation Name Categories
Cross Reference Use Cases: Categories
Pre-conditions  The user must possess Android Phone/Android Tablet/ The user must
download application from Play Store.
 DONER and ACCEPTER must be login.
Post-conditions  Selected categories item/product available/not available.
Contract CO3: Contact Donate

Operation Name Contact Donate
Cross Reference Use Cases: Contact Donate
Pre-conditions  The user must possess Android Phone/Android Tablet.
 Accepter must be contact the donor.
Post-conditions  Accepter contact the donor via SMS or phone call.

4.7. Activity Diagram

Admin Side activity diagram

User side activity diagram

4.8. State Transition Diagram

4.9. Component Diagram

4.10. Deployment Diagram

Chapter 5
Implementation

Chapter 5: Implementation
This is the most important chapter in which we describe how the project is implemented. We
all know that Developing tools and techniques are more important for a software engineer. In
this chapter we will discuss the developing environment, tools and techniques etc.
5.1. Important Flow Control/Pseudo codes

1.The application is being opened by the User and Introduction starts.
1.2: ELSE the user skips the introduction.
2.The categories Menu and ads options appears.
3: if Accepters select the any category
3.1: else select the location.
3.2: else find the item.
3.3: else details this item and contact the doner.
3.4: else the user click Rate us.
3.5: else user logout the application.
3.6: else the user click on sittings.
3.6.1: else if user set notifications.
4: if donor post the any donate ads.
5: Donor login than ads post otherwise post cancel.
6 if donor set the all details related to post
6.1: contact number and location
7: If accepter contact the Donor than Donor donate the product.
8: if donate the products than related product post deleted.
8.1: else post editing and save
9: user logout the application
10: IF user click “No”, flow transfers to Process ID:2 categories.
10.1 IF user click “Yes” app closed.
5.2. Components, Libraries, Web Services and stubs

[Paragraph Text 12 pt, Calibri, 1.5 Line Spacing, Justified]

5.3. Deployment Environment

Since our project Share Happiness is a mobile application, hence in deployment environment,
there will be
-a cell phone Android Phone or Android Tablet
 with our Application Share Happiness Installed in it.
 The app will be downloaded from the play Store.
5.4. Tools and Techniques

TOOLS:
 Android Studio
 Corel draw
 Draw.io or Visio
Languages
 Xml
 Java
 C++
 SQLite

5.5. Best Practices / Coding Standards
 Comments and documentation makes the code easy to understand.
 Code must be readable.
 Code must be reusable which saves a lot of time.
 Avoid the hard-code that cannot be understandable.
 Conform to the coding standards and user requirements.
 Use of IDE’s drop-down menu.
 Pair programming and code review is also an efficient way.
 Backup and save the data. So there is no fear of loss of data.
5.6. Version Control

Team Foundation Server (TFS) is used for version control which is the Development software
by Microsoft which includes revision control.

Appendices

Appendix A: Information / Promotional Material

We can promote our system through different ways i.e. digital marketing like Facebook etc.,
Gorilla marketing and also use another ways like attractive logo etc. that can promote our
system.
A.1. Broacher
A.2. Flyer
A.3. Standee
A.4. Banner

A.5. First Level heading [16 pt, Calibri, Bold, Left aligned]
A.5.1. Second level heading [14 pt, Calibri, Bold, Left aligned]
A.1.1.1. Third level heading [12 pt, Calibri, Bold, Left aligned]

Appendix [no.]: Appendix Title

[Between 4 to 8 lines describe what is this chapter all about]
A.1. First Level heading [16 pt, Calibri, Bold, Left aligned]
A.1.1. Second level heading [14 pt, Calibri, Bold, Left aligned]
A.1.1.2. Third level heading [12 pt, Calibri, Bold, Left aligned]

Reference and
Bibliography

Reference and Bibliography
 IEEE Software Engineering Standards Committee, “IEEE Std 830-2016, IEEE Recommended
Practice for Software Requirements Specifications”, October 20, 2016.
 Edhi Foundation’s official website http://www.edhifoundation.com/
 Alternate website http://edhi.org/
 https://www.news.bbc.co.uk. (2018 Pakistan’s Savior of the Desperate’, by BBC News.
[online] Available at http://news.bbc.co.uk/1/hi/world/south_asia/1221986.stm

Index

Index
[A]
Assumptions and Dependencies
Architecture Diagram
Activity Diagram
[B]
Background
Business Rules
Best Practices
[C]
Communication Interfaces
Class Diagram
Component Diagram
Components
Comments
[D]
Document conventions
Design and Implementation Constraints
Description and Priorities
Deployment Diagram
Data Flow Diagram
Deployment Environment
[E]
Executive Summary
External Interface Requirement
[F]
Functional Requirement

[G]
Goals and Objectives
Gap Analysis
Gantt Chart
Good Programming Practices
[H]
Hardware Interfaces
[I]
Introduction
Intended Audience and Reading Suggestion
Implementation
[J]
[K]
[L]
[M]
Motivations and Challenges
[N]
Naming Conventions and Standards
[O]
Overall Description
Operating Environment

Other Non-Functional Requirements

Operation Contracts
[P]
Proposed solution
Project Plan
Purpose
Product Scope
Product Perspective
Product Functions
Performance Requirements
Pseudo Code
Programming Practices
[Q]
Quality Attributes
[R]
Roles and Responsibilities Matrix
Reference
Reference and Bibliography
[S]
Software Requirements and Specifications
Software Interfaces
System Features
Safety Requirements
Security Requirements
Software Quality Attributes

System Design
Sequence Diagram
State Transition Diagram
[T]
[U]
User Classes
User Documentation
User Interfaces
Use Case Analysis
Use Case Models
[V]
[W]
Work Breakdown Structure
[X]
[Y]
[Z]

Template-05 - Project Report (Part-1) - 1

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Template-05 - Project Report (Part-1) - 1

Încărcat de

Drepturi de autor:

Formate disponibile

SUPERIOR UNIVERSITY LAHORE

Faculty of Computer Science & IT

Final Year Project

Project ID: FYP-BSSE-F18-036

Muhammad Waseem Iqbal

Faculty of CS&IT, Superior University Lahore, Pakistan ii

HEAD OF THE DEPARTMENT

Faculty of CS&IT, Superior University Lahore, Pakistan iii

This work is dedicated to our hero “Abdul Sattar Edhi”.

Faculty of CS&IT, Superior University Lahore, Pakistan iv

Faculty of CS&IT, Superior University Lahore, Pakistan v

Faculty of CS&IT, Superior University Lahore, Pakistan vi

Faculty of CS&IT, Superior University Lahore, Pakistan vii

2.4.1. System Feature 1 ........................................................................................................ 16

Faculty of CS&IT, Superior University Lahore, Pakistan viii

Reference and Bibliography .......................................................................................................... 53

1.1 Caption of first figure of first chapter 6

Faculty of CS&IT, Superior University Lahore, Pakistan ix

1.1 label of first table of first chapter 6

Faculty of CS&IT, Superior University Lahore, Pakistan x

Faculty of CS&IT, Superior University Lahore, Pakistan 2

.1. Motivations and Challenges

.2. Goals and Objectives

.1. Literature Review/Existing Solutions

Faculty of CS&IT, Superior University Lahore, Pakistan 3

.2. Gap Analysis

.3. Proposed Solution

Faculty of CS&IT, Superior University Lahore, Pakistan 4

.4. Project Plan

.4.1. Work Breakdown Structure

Faculty of CS&IT, Superior University Lahore, Pakistan 5

.4.2. Roles & Responsibility Matrix

1 Planning Purposal Proposal defence 10 days Waseem Shah

5 Implementation Implement Develop the app 20 day Imran siddique

6 Documentation report Making report 20 day Imran, Siddique

Faculty of CS&IT, Superior University Lahore, Pakistan 6

.4.3. Gantt Chart

Faculty of CS&IT, Superior University Lahore, Pakistan 7

Faculty of CS&IT, Superior University Lahore, Pakistan 8

Chapter 2: Software Requirement Specifications

.1.1. Document Conventions

.1.2. Intended Audience and Reading Suggestions

Faculty of CS&IT, Superior University Lahore, Pakistan 9

.1.3. Product Scope

Faculty of CS&IT, Superior University Lahore, Pakistan 10

.1. Overall Description

.1.2. Product Functions

Faculty of CS&IT, Superior University Lahore, Pakistan 11

 Past History Record:

.1.3. User Classes and Characteristics

.1.4. Operating Environment

Faculty of CS&IT, Superior University Lahore, Pakistan 12

.1.1. Design and Implementation Constraints

Faculty of CS&IT, Superior University Lahore, Pakistan 13

.1.2. Assumptions and Dependencies

.2. External Interface Requirements

.2.1. User Interfaces

.1.1. Hardware Interfaces

Faculty of CS&IT, Superior University Lahore, Pakistan 14

.1.1. Software Interfaces

Software used Description

Operating system user-friendliness.