Latest

COMSATS University Islamabad (CUI)
Software Design Description

(SDS DOCUMENT)
for
See Through My Eyes

Version 1.0
By
Beenish Shakeel SP20-BCS-017
Noor-ul-Ain SP20-BCS-080
Supervisor
Mr. Muhammad Rashid Mukhtar
Bachelor of Science in Computer Science (2020-2024)

Software Design Description for See Through My Eyes Page ii
Table of Contents
Revision History............................................................................................................................iii
Application Evaluation History...................................................................................................iv
1. Introduction..............................................................................................................................1
1.1 Modules........................................................................................................................................1
2. Design Methodology and Software Process Model...............................................................2
3. System Overview......................................................................................................................2
3.1 Architectural Design.....................................................................................................................3
4. Design Models...........................................................................................................................4
4.1 Activity Diagram:.........................................................................................................................4
4.2 Data Flow Diagram:...................................................................................................................28
4.3 State Transition Diagram:...........................................................................................................33
5. Data Design.............................................................................................................................35
5.1 Data Dictionary...........................................................................................................................35
6. Human Interface Design........................................................................................................36
6.1 Screen Images.............................................................................................................................36
6.2 Screen Objects and Actions........................................................................................................39
7. Implementation......................................................................................................................40
7.1 Algorithm....................................................................................................................................40
7.2 External APIs/SDKs...................................................................................................................41
7.3 User Interface.............................................................................................................................42
7.4 Deployment................................................................................................................................45
8. Testing and Evaluation..........................................................................................................45
8.1 Unit Testing................................................................................................................................45
8.2 Functional Testing......................................................................................................................52
8.3 Business Rules Testing...............................................................................................................56
8.4 Integration Testing......................................................................................................................58
9. Plagiarism Report..................................................................................................................60
Software Design Description for See Through My Eyes Page iii
Revision History
Name Date Reason for changes Version
Version 1.0 12/05/2023 First Version 1.0
Software Design Description for See Through My Eyes Page iv
Application Evaluation History
Comments (by committee) Action Taken

*include the ones given at scope time both in doc and
presentation
Formatting issue in the document Formatting issues resolved
Use case needs to be checked and use case tables Use case diagram updated and tables filled
needs to be filled completely
Voice based operations should be included Module added of Voice based operations for
(alarm, time, date, phone call, message) (alarm, time, date, phone call, message)
Supervised by
Mr. Muhammad Rashid Mukhtar
Signature______________
Software Design Description for See Through My Eyes Page 1
1. Introduction
The “See through My Eyes” is a smartphone application for blind and visually impaired persons.
Firstly, the blind will start the application by shaking his/her phone. Then, the app asks the blind for
the type of help he/she wants whether it is volunteer based or GPS based. If the help required is of
some GPS based, then the application provides some predefined assistance. If the help is volunteer
based, then the app asks the user for the confirmation to initiate the request for volunteer.
On volunteer’s end, the app will show notification when a request comes. The volunteer will be able
to accept or decline the request. The volunteer will be able to capture static shots during live camera
feed if he/she needs to focus on something in particular. The life of the shots taken will be up-to the
duration of the call to maintain good privacy standards. After the call, both the blind and the
volunteer will review the other party’s performance. This will help to improve the subsequent
volunteer searches.
1.1Modules
1.1.1 Module 1: Software as a Service

FE-1: Register the service in android OS to ping the app upon shake
FE-2: Wake up the phone on shake and bring the app to foreground for blind to speak in to
FE-3: Remove the app from foreground and run as background process to save battery
1.1.2 Module 2: Voice Based Control

FE-1: Listen for and process user’s audio to extract understandable transcripts
FE-2: Process audio transcription to extract commands and take appropriate action
FE-3: Allow the user to select and interact with the language of choice
1.1.3 Module 3: User Profile Management

FE-1: Users can Create Account
FE-3: Users can review, modify, and delete profile settings
FE-4: Admin can view and delete the users
FE-5: Segregate functionality based on user’s role and permissions
FE-6: Send volunteer invites
1.1.4 Module 4: Volunteer Search

FE-1: Find volunteers based on the users’ ratings and language
FE-2: Find volunteers as near as possible to a blind person
FE-3: Ask a contact to help
1.1.5 Module 5: Video Call

FE-1: Establish a secure one-to-one good quality video call
FE-2: Capture static image from a live camera feed that won’t be available after the call ends
FE-3: Allow the volunteer to zoom in remotely into the blind’s live camera feed
FE-4: Allow the blind to switch camera
FE-5: Turn off the blind’s video feed on button press
1.1.6 Module 6: GPS based help management

FE-1: Keep record of live location of the users
FE-2: Share live location within video call
FE-3: Speak directions to some destination from current location
1.1.7 Module 7: Review System

FE-1: Take review from volunteer using multi-option feedback and rating stars
FE-2: Take review from the blind using voice input
FE-3: Evaluate user ratings using the reviews
FE-4: Rate, review and suggest features
1.1.8 Module 8: Voice based Operations

FE-1: Record notes and saved them to the database
FE-2: Listen to these notes whenever needed
FE-3: Natively call a contact through network
FE-4: Natively send a text message over the network composed with voice
FE-5: Schedule an alarm
FE-6: Speak current time and date
2. Design Methodology and Software Process Model

The design methodology being followed in this project is Procedural Programming. The reason is
that we will be developing this app in React Native using its feature of functional components along
with React hooks which is effective and simpler as compared to classes with states. Since we will
not be working with classes or entities, the procedural paradigm is more appropriate than Object
Oriented Paradigm.
The software process model being used in the development of this project is an Incremental Model.
This model allows us to develop the system in increments. A basic model containing the basic
functionalities will be developed first. Then other features can be added in multiple iterations. The
benefit of this process model is that we have a working model of the system very quickly and it is
easier to test in a single iteration.
3. System Overview
The “See through My Eyes” application is designed to provide assistance to blind and visually
impaired persons using their smartphones. The application offers two types of help: volunteer-based
or GPS-based. The user can access the application by shaking their phone, and they will be
prompted to select the type of assistance they require.
If GPS-based assistance is selected, the app will provide predefined assistance. In contrast, if
volunteer-based assistance is required, the user will be prompted to confirm their request, and a
notification will be sent to available volunteers. The volunteer can accept or decline the request and
will have access to a live camera feed to assist the blind person. If necessary, the volunteer can take
static shots during the call to focus on particular items.
To maintain privacy standards, the shots taken during the call will have a limited life span and
expire when the call ends. After the call, both the blind user and the volunteer will have the
opportunity to review each other's performance, which will help to improve subsequent volunteer
searches.
Overall, the “See through My Eyes” application offers an innovative and practical solution to help
blind and visually impaired persons navigate their environment with the assistance of volunteers.
3.1 Architectural Design
The application follows a modular design and consists of 8 major modules which are illustrated in
the diagram below. Users Management module is responsible for creating, modifying and deleting
users accounts. It also allows for sending invites to potential users. All the subsequent modules of
the app are dependent on this module to provide the user’s identity.
The Software as a Service module is responsible for enabling the app to become active on the event
of shake once the user is logged in. It also registers the shake event the first time app is started, if
the OS allows it. This, then, enables the app to keep running in the background for it to be able to
detect shakes whenever they happen while draining as less battery as possible. Now, with the app
open and running, The Voice Based Control module takes the user’s audio input, converts it in to
meaningful commands that can be executed by the app. It also allows the user to select the language
of choice. The commands can be of calling a volunteer, getting location based guidance or of some
predefined system related function too.
When a command to call a volunteer is processed, the Volunteer Search module looks up a
volunteer depending upon the criteria specified which is also extracted from the command itself.
The criteria can be nearest location, rating or to find volunteers that are already in the contact list of
the user. If and when a volunteer is found, Video Calling module helps in establishing a 1-1 good
quality video call. This module also provides functionalities during the video call such as taking
temporary static images, remotely zooming in and out, switching the camera and also turning off the
camera at all.
Apart from the above, the GPS based help management module can help users with the location
based guidance by directing to locations with audio instructions and also by saving the locations to
be used again later. Review System is responsible for managing all sorts of feedbacks, be it blind to
volunteer, volunteer to blind or any user to the app. The Voice Based Operations module is
responsible for acting upon the user’s demand of the basic functionalities of the system such as
asking for the time, date or setting an alarm, etc.
Figure 1: Box and Line Architecture Diagram
4. Design Models
4.1 Activity Diagram:
4.1.1 Shaking phone and open the app

To open the phone on shake, user has to register the service on background. After it, when user
shakes his phone, the app will get open and ask the user to speak what action he wants to perform
Figure 2: Activity diagram to open app on shake

4.1.2 Run app on Voice command

System will start the instruction ask blind which service he wants. Blind speak the service and then
the system will provide him that particular service
Figure 3: Activity diagram to run the app on voice commands

4.1.3 Sign Up for Volunteer

Volunteer will enter all the credentials and then click on sign up system verify all credentials
according to certain criteria and allow volunteer to get registered.
Figure 4 Activity Diagram for Volunteer Sign up:

4.1.4 Sign Up for Blind

System will ask blind to speak his phone number and then get him register into the database
Figure 5: Activity diagram For Blind sign up

4.1.5 Volunteer Login

By providing email and password user can sign in and avail system functionalities and services
Figure 6: Activity diagram For Volunteer Login

4.1.6 Volunteer update profile

Volunteer can update his profile by providing all credentials and then pressing update profile and
system will update the volunteer profile.
Figure 7: Activity diagram For Volunteer update profile

4.1.7 Volunteer Delete profile

Volunteer can delete his profile by clicking on delete profile option pop up will appear by selecting
yes he can delete his profile and by selecting no his profile remain undeleted
Figure 8: Activity diagram For Volunteer delete profile

4.1.8 Admin can delete Volunteer

Admin can delete the volunteer by selecting the volunteer he wants to delete then click on delete
accept confirmation popup the volunteer is deleted from the system
Figure 9: Activity diagram For Admin delete Volunteer

4.1.9 Admin/Volunteer share the App

Admin volunteers can share the app by selecting share option and then choosing media platform app
links will be shared over social media with the person admin and volunteer wants
Figure 10: Activity diagram For Sharing App

4.1.10 Volunteer Search

Blind will ask for the volunteer on the basis of some criteria (rating, location or contact list). The
app will search respectively and connect the blind with the appropriate blind in a Twilio room.
Figure 11: Activity diagram For Volunteer Search

4.1.11 Connect Blind and Volunteer in a Call

A private room is created after volunteer search and the blind and volunteer will connect to it and
the call initiates.
Figure 12: Activity diagram for establish video call

4.1.12 Capture Static Image

During the call, the volunteers’ capture the static images by pressing the capture icon and these
images will be discarded after the call ends
Figure 13: Activity diagram for capture static image

4.1.13 Zoom In / Zoom Out the Screen:

The Volunteer zoom in/ out in blinds camera feed by pinching the finger tips. Twilio signals the
blind app to zoom in /out the camera. The camera view then gets zoomed in / out accordingly.
Figure 14: Activity diagram for zoom in/ zoom out

4.1.14 Switch Blind Camera

During the video call, the blinds asks for switching cameras by pressing both volume keys
simultaneously. The camera gets switched.
Figure 15: Activity diagram for switch camera screen

4.1.15 Turn off Blind Camera

During the video call, the blinds asks for turning off the camera feed by pressing the appropriate
key. The camera feed gets off
Figure 16: Activity diagram for turning off video feed

4.1.16 GPS Guidance

When blind ask for GPS guidance system will get blind current location ask him for destination and
start voice based directions.
Figure 17: Activity diagram for GPS guidance

4.1.17 Get blind current location

In order to start guidance system needs to fetch user current location automatically also incase there
an emergency this location can be shared with volunteer.
Figure 18: Activity diagram for getting blind current location

4.1.18 Blind Rating

After the video call, the app asks the blind to share his experience by rating through voice input.
The blind then rates the call with voice input that gets stored then.
Figure 19: Activity diagram for blind rating

4.1.19 Volunteer Rating

After the video call, the app asks the volunteer to share his experience by rating by rating and
feedback. The volunteer rates the call and provide feedback that gets stored then.
Figure 20: Activity diagram for volunteer rating

4.1.20 Offline Notes help

Blind can fetch the notes he saved from database and can listen to them also he can save new notes
to database.
Figure 21: Activity diagram for offline notes help

4.1.21 Offline Native Call

System will provide blind the facility to call the person from his contact list just speak the name of
person and speak call system will launch the call to that person.
Figure 22: Activity diagram for offline call help
4.1.22 Offline Native SMS

System will provide blind the facility to SMS the person from his contact list just speak the name of
person and speak SMS system will launch the call to that person
Figure 23: Activity diagram for offline SMS help

4.1.23 Offline Alarm service
System will provide blind the facility to set the alarm by providing date and time for which he
wants to set the alarm.
Figure 24: Activity diagram for offline alarm service

4.2 Data Flow Diagram:

4.2.1 Level 0 DFD
This diagram explains major functionalities of “see through my eyes” App. This diagram illustrates
external entities and system interfaces. This app helps blind person in a way that they can make
video call to Volunteers and specialist person these Volunteer guide blind person in every possible
way so they can perform their daily task easily. Furthermore, blind also avail voice-based GPS
guidance using see through my eyes. Admin will manage Volunteer and Blinds accounts.
Figure 25: Context Diagram DFD for See through My Eyes

4.2.2 Level 1 DFD
This diagram gives a more detailed view of the data flow and connections between the modules. It
is one level deeper view than the context diagram. Now it also explains the database interconnection
and details the communication happening between the modules by enlisting the possible actions
Figure 26: Diagram 0 DFD for the order system

4.2.3 Level 2 DFDs
These diagrams now explain the flow among each module individually.
Figure27: Diagram 1 DFD for User Profile Management

Figure 28: Diagram 1 DFD for Volunteer Search
Figure 29: Diagram 1 DFD for Video Calling
Figure 30: Diagram 1 DFD for GPS based help management

Figure 31: Diagram 1 DFD for Voice based operations

4.3 State Transition Diagram:
Diagram 1:
This state diagram explains blind sign-up flow.
Figure 32: State diagram for Authentication For blind
Diagram 2:
This state diagram explains User profiling and their rights as Admin and Volunteer
Figure 33: State diagram for Authentication for Volunteer/Admin

Diagram 3:
This state diagram explains one to one call generation between Volunteer and Blind
Figure 34: State diagram for Authentication for Volunteer Blind Video call
Diagram 4:
This state diagram explains services provided to blind by our app like GPS and other voice base
operations
Figure 35: State diagram for Authentication for Volunteer search
5. Data Design
For the permanent storage of Volunteer, Blind and Admin record firebase database is being used.
Firebase offers a real-time database that allows developers to build applications that update data in
real-time. Also, it allows efficient querying and structuring of data.
5.1 Data Dictionary

Table 1: Volunteer Data Dictionary
Sr. No Data Type Description
1 ID Integer The identifier for Volunteer
2 Name String Name of Volunteer
3 Email String Unique Email Address for Volunteer
4 Password String Password for Volunteer
5 Phone Number Integer Phone Number of Volunteer
6 Language String Language that Volunteer can speak
Table 2: Blind Data Dictionary

1 ID Integer The identifier for Blind
2 Name String Name of Blind User
3 Phone Number Integer Phone Number of Blind User
Table 3: Admin Data Dictionary

1 ID Integer The identifier for Admin
2 Name String Name of Admin
3 Email String Unique Email Address for Admin
4 Password String Password for Admin
5 Phone Number Integer Phone Number of Admin
6. Human Interface Design

6.1 Screen Images
Figure 36: Sign Up Screen Figure 37: Login Screen

Figure 38: Blind Main screen Figure 39: Video call Screen
Figure 40: Volunteer search Screen Figure 41: GPS Voice Guidance Screen
6.2 Screen Objects and Actions
Figure 36: It is the sign-up screen of our app where user will enter all credentials and when click
sign up system will match all the entered fields and if they are valid system will register the user
into the system.
Figure 37: It is the sign in screen of our app. User have to provide email and password. If the email
is registered and password is correct user will sign in and he can avail the functionalities of app
Figure 38: It is the Blind side main screen of our app which will appear when blind shake the
phone system will generate voice commands and blind will response back in audio commands
system will process blind audio and provide him demanded service.
Figure 39: It is the video call main screen. This screen will appear when 1-1 secure call is
generated between volunteer and blind. Volunteers can guide blind people and help her to do daily
life tasks easily.
Figure 40: It is the Volunteer search screen. when blind ask for video call the system will search for
nearest possible volunteer then this screen will be pop up in the app.
Figure 41: It is the GPS voice-based guidance screen. When Blind ask for GPS voice-based
guidance system will fetch blind location ask him/her for destination and start guiding blind using
voice commands
7. Implementation
1.1 Algorithm
Following are the major algorithms used in implementing the functionality of the system developed
so far.
Algorithm 1 findNearestVolunteer
Input: locblind: a tuple containing latitude and longitude of the blind, locs volunteers: an array with latitudes
and longitudes and user IDs of all the volunteers with same language and city i.e. (user_id, latitude,
longitude)
Output: Volunteer Id if a volunteer is found, null otherwise
1: Initialize distances variable with an empty Hashmap
2: nearest_volunteer ← null
3: minimum_distance ← inifinity
4: latblind ← locblind[0]
5: longblind ← locblind[1]
6: foreach volunteer in locsvolunteers:
7: latvol ← volunteer[1]
8: longvol ← volunteer[2]
9: distance ← acos(sin(lat vol) * sin(latblind) + cos(latvol) * cos(latblind) * cos(longblind – longvol)) *
6371
10: if (distance < minimum_distance) then
11: minimum_distance ← distance
12: nearest_volunteer ← volunteer[0]
13: end if
14: end foreach
15: return nearest_volunteer, distance
Algorithm 1.1 findGoodRatedVolunteer

Input: ratings: an array with ratings and user IDs of all the volunteers with same language and city i.e.
(user_id, rating), exclude: an array of user IDs of the volunteers to not consider
1: max_rating = 0
2: rated_volunteer = null
3: foreach (volunteer_id, rating) in ratings:
4: if (! exclude.contains(volunteer_id) && rating > max_rating) then
5: max_rating = volunteer[1]
6: rated_volunteer = volunteer[0]
7: end if
8: end foreach
9: return rated_volunteer, max_rating
Algorithm 1.2 findContactVolunteer

Input: contacts: an array of user IDs of the volunteers that are in blind’s contact list
exclude: an array of user IDs of the volunteers to not consider at the moment
1: Initialize considerable_volunteers as an empty array
2: foreach volunteer in contacts
3: if (! exclude.contains(volunteer) ) then
4: Append volunteer in considerable_volunteers
5: end if
6: end foreach
7: selected_volunteer = Pick a random volunteer from considerable_volunteers
8: return selected_volunteer
Algorithm 2 evaluateUserRating
Input:
cumulative_rating: a numeric value that indicates the mean rating of a user
no_of_ratings: Number of people who have given a rating
current_rating: Rating from current user
Output: New cumulative rating
1: total_ratings = cumulative_rating * no_of_ratings
2: return (total_ratings + current_rating) / (no_of_ratings + 1)
1.2 External APIs/SDKs
The table below show the external APIs used by the system. It also describes the rationale behind
using the API, its description, and the function in which it is used:
Table 1 Details of APIs used in the project

Name of API Description of API Purpose of usage List down the API
and version endpoint/function/class in which
it is used
Twilio Api Video calling We will use this api for File:
integration api video calling between Video.js
blind and volunteer
Google Maps Maps integration We will use this api to File:

Api integrate google maps to Map.js
provide gps based help
and to search volunteer
based on proximity
1.3 User Interface
1.3.1 Sign-up screen 7.3.2 Sign in Screen

Sign up screen for Volunteer from where Sign in screen where Volunteer can
he can get register for this app enter email password and avail the app
Figure 42: Sign Up Screen Figure 43: Login Screen

7.3.3 Blind Main Screen 7.3.4 Blind Main Screen

When the blind shake the phone this screen will This screen is showing 1-1 video call between
Pop up Volunteer and Blind person
Figure 44: Blind Main screen Figure 45: Video call Screen
7.3.5 Volunteer Search Screen 7.3.6 GPS voice guidance Screen

When the blind asks for video call system This is the screen which will appear when
will search for volunteer and this screen blind ask for GPS base voice guidance.
will pop up in the app.
Figure 46: Volunteer search Screen Figure 47: GPS Voice Guidance Screen
1.4 Deployment
We are making react native mobile app in which Server will be deployed over AWS and the data
will be store/host on Firebase. App will not be hosted either on play store or on any other platform
8. Testing and Evaluation

8.1 Unit Testing
It’s a level of software testing where individual units of a software/component are tested. The
purpose is to validate that each unit of the software performs as designed.
Unit Testing 1: Register the app as background service on first start

Testing Objective: To ensure that the app keeps running until it is closed forcefully
Table 1 : Service as background test case

No. Test case/Test script Attribute and Expected result Result
value
1 Check that the initial Event: App starts The app appears in Pass
start registers a the background
background service apps
Unit Testing 2: Open the app by shaking the phone

Testing Objective: To ensure that phone shake does open the app
Table 2 : App open on shaking test case

No. Test case/Test script Attribute and Expected result Result
value
1 Check that the shake Event: Shake The app comes to Pass
opens the app when the the foreground
phone is unlocked
2 Check that the shake Event: Shake on The phone prompts Pass
asks for the phone’s lock the user to enter
password when opening password to get to
the app when the phone the app
is locked
Unit Testing 3: Find the volunteer’s distance

Testing Objective: To ensure that the app calculates distances correctly
Table 3 : app calculates distances correctly test case

No. Test case/Test script Attribute and value Expected result Result
1 Check that the distance lat1: 14.77 KM Pass

between two points is 33.65187498723733,
calculated correctly long1
73.15657453663331,
lat2:
33.68913630280454,
long 2:
73.00340344256163
Unit Testing 4: Pick from given rated volunteers

Testing Objective: To ensure that the app correctly picks a good rated volunteer
Table 4 : App correctly picks a good rated volunteer test case

1 Check that a volunteer volunteers_ratings: (4, 4.8) Pass

is picked from a rated [(1, 4.5), (2, 5), (3,
list 3.8), (4, 4.8)]
exclude: [2]
Unit Testing 5: Pick from given contact list

Testing Objective: To ensure that the app correctly picks a known volunteer
Table 5 : App correctly picks a known volunteer test case

1 Check that a volunteer contacts: [1, 65, 71, 1 Pass

is picked from the 98, 357]
contact list exclude: [71]
Unit Testing 6: Rating the blind

Testing Objective: Allow the volunteer to rate the blind
Table 6: App Allow the volunteer to rate the blind test case
1 Display rating message Stars: 4 Message: Good Pass

and move to review Review input
field when a rating is focused
selected
2 Display error message Stars: Unselected Please rate the Pass
when no rating is interaction
selected
3 Proceed even if the Review: Empty Rating recorded Pass
review input is empty successfully
Unit Testing 7: Test that the system can successfully listen to and transcribe a given audio input
accurately.
Testing Objective: Listen to all blind audio commands.
Table 7 : App Listen to all blind audio commands test case

1 Blinds speak to start Audio command: Start Video call Pass

video call Video call
2 Blind did not speak Audio command not Please speak your Pass
received desired option
3 Blind speak wrong Review: choose Speak again Pass
option or out of given from given options
features
Unit Testing 8: Test that the system can correctly identify and switch to the user's preferred
language.
Testing Objective: Able to help blind in his/her native language.
Table 8 : Able to help blind in his/her native language test case

1 Blinds speak his desired Urdu Assigned him the Pass

language. language
2 Blind did not speak his Null Please speak your Pass
desired language desired language
Unit Testing 9: Test that the user can successfully create an account with valid inputs.
Testing Objective: Volunteer Able to make his/her account.
Table 9: Volunteer Able to make his/her account

1 User enter all his fields All credentials Sign up successful Pass
and press sign up required for sign up
2 User miss some fields Some credentials are Please enter all Pass
filled fields.
Unit Testing 10: Test that the user can log in to their account after creating it
Testing Objective: Allow user to log in to correct account and avail the app features
Table 10: Allow user to log in to correct account and avail the app features
1 User enter all his fields All credentials Sign in successful Pass
and press sign in required for sign in
filled fields.
3 User enter wrong Wrong password Password does not Pass
password match reenter
password
Unit Testing 11: Test that the user can update his account.
Testing Objective: Allow user to update his account successfully.
Table 11: Allow user to update his account successfully

1 User enter all his fields All credentials Update profile Pass
and press update profile required for update successful
profile
filled fields.
3 User enter unmatched Password and Password does not Pass
password and confirm confirm password match with
password confirm password
re enter
Unit Testing 12: Test that the user can delete his account.
Testing Objective: Allow user to delete his account successfully.
Table 12: Allow user to delete his account successfully.

1 User enter delete profile Just click the button Confirmation Pass
button message asking to
delete profile or
not
2 User click YES on Click yes button Profile Deleted Pass
confirm deletion pop up successfully
3 User Click No button on Click no Button Profile remain un Pass
confirmation popup deleted
Unit Testing 13: Test that the user can share app.
Testing Objective: Allow user to share the app with friends and family.
Table 13: Allow user to share the app with friends and family.
1 User click share app Select the app App link is shared Pass
icon through which he with whom user
wants to share wants
Unit Testing 14:Admin can delete the user he wants.

Testing Objective: Allow admin to delete the user he wants.
Table 14 : Allow admin to delete the user he wants.

1 Admin click delete user Just click the button Confirmation Pass
button message asking to
delete user or not
2 Admin click YES on Click yes button User Deleted Pass
confirm deletion pop up successfully
3 Admin Click No button Click no Button User remain un Pass
on confirmation popup deleted
Unit Testing 15: Verify if the system currently achieve user current location.
Testing Objective: Allow system to get user current location.
Table 15 : Allow system to get user current location.

1 Blind selected to get Get the user current System will able to Pass
GPS voice guidance location get user current
location
Unit Testing 16: Verify if the system can share the location with Volunteer during video call.
Testing Objective: Allow Volunteer to get Blind location.
Table 16 : Allow Volunteer to get Blind location

1 Blind started the video Blind current System will be able Pass
call and wanted to share location to share blind
location with Volunteer current location
with Volunteer
Unit Testing 17: Test that the system can provide correct GPS Voice base Guidance.
Testing Objective: Allow Blind to avail GPS voice-based guidance.
Table 17 : Allow Blind to avail GPS voice-based guidance.

1 Blind started the GPS Blind current System will be able Pass
voice base guidance location and guide Blind person
destination to his destination
using Voice
commands
Unit Testing 18: Test that the Blind fetched the notes correctly from the database.
Testing Objective: Allow Blind to get notes from the database.
Table 18 : Allow Blind to get notes from the database.

1 Blind get the notes from Blind tell which note System will be able Pass
the database he want to fetch fetch the blind

correct note which
he want
Unit Testing 19: Test that the system is playing the note for blind person.
Testing Objective: Allow Blind to listen to those notes.
Table 19 : Allow Blind to listen to those notes.

1 Notes that blind wants is Notes fetched from System will be able Pass
playing the database play the notes for
blind
Unit Testing 20: Test that the system generate the call to person blind wants.
Testing Objective: Allow Blind to natively call anyone from his contact.
Table 20 : Allow Blind to natively call anyone from his contact.

1 Blind will able to call Person Contact from System will be able Pass
anyone from his contact contact list call the person
list
Unit Testing 21: Test that the system generate the SMS to person blind wants.
Testing Objective: Allow Blind to natively SMS anyone from his contact.
Table 21 : Allow Blind to natively SMS anyone from his contact.

1 Blind will able to SMS Person Contact from System will be able Pass
anyone from his contact contact list SMS the person
list
Unit Testing 22: Test that the system can set an alarm for blind person
Testing Objective: Allow Blind to set alarm.
Table 22: Allow Blind to set alarm.

1 Blind will able to set Date and time System will be able Pass
alarm to set an alarm for
that date and time
8.2 Functional Testing

Functional Testing 1: Search for volunteer
Objective: To ensure that a volunteer is found
Table 1 :Functional test case to ensure that a volunteer is found

No. Test case/Test Attribute and value Expected result Actual result Result
script
1. Find a nearest Search Type: Nearest (2, 33.47, 65.05) (2, 33.47, 65.05) Pass
volunteer Volunteers: [(1,
33.57, 65.15), (2,
33.47, 65.05), (3,
33.67, 65.25)]
Blind: (33.43, 65.07)
2. Find a nearest Search Type: Nearest Null Null Pass
volunteer when Volunteers: [(1,
no one is 33.57, 65.15), (2,
available or no 33.47, 65.05), (3,
one accepts 33.67, 65.25)]
Exclude: [1, 2, 3]
Blind: (33.43, 65.07)
3 Find a good Search Type: (4, 4.8) (4, 4.8) Pass
rated volunteer Rating
volunteers_ratings:
[(1, 4.5), (2, 5), (3,
3.8), (4, 4.8)]
exclude: [2]
4 Add the Search Type: Exclude: [2, 1] Exclude: [2, 1] Pass
volunteer in Rating
exclude array if volunteers_ratings:
he / she rejects [(1, 4.5), (2, 5), (3,
the request
3.8), (4, 4.8)]
exclude: [2]
5 Check that a contacts: [1, 65, 71, 1 1 Pass
volunteer is 98, 357]
picked from exclude: [71]
the contact list
6 Add the contacts: [1, 65, 71, Exclude: [71, 1] Exclude: [71, 1] Pass
volunteer in 98, 357]
exclude array if exclude: [71]
he / she rejects
the request
Functional Testing 2: Setup video call

Objective: To ensure that a video call is setup
Table 2 :Functional test case To ensure that a video call is setup

script
1. Establish a Room type: Private Video call is setup Video call is setup Pass
video call Max participants: 2
Max quality allowed:
HD
2. Establish a Room type: Private Message: System at Message: System at Pass
video call when Max participants: 2 full capacity. Please full capacity. Please
capacity is Max quality allowed: try again later try again later
reached HD
3. Close the room Participants: None Room closed Room closed Pass
once both
participants
leave
4. Close the room Participants: Room closed Room closed Pass
if the blind Volunteer
leaves
Functional Testing 3: Secondary functions during call

Objective: To ensure that the volunteer can make the best out of limited accessibility
Table 3 : Functional test case To ensure that the volunteer can make the best out of limited accessibility
script
1. Capture a static Call progress: A snapshot of the A snapshot of the Pass

image Ongoing blind’s camera feed blind’s camera feed
is taken is taken
2. Delete static Call progress: Ended Message: Static Message: Static Pass
images on call images have been images have been
end deleted deleted
3. Zoom in / out Volunteer pinches Blind camera feed Blind camera feed Pass
remotely in / out on blind’s zoomed in / out zoomed in / out
feed
4. Switch off Control buttons Camera turned off Camera turned off Pass
camera pressed
5. Switch cameras Switch buttons Camera switched Camera switched Pass
pressed
Functional Testing 4: Secondary functions during call

Objective: To ensure that the volunteer can make the best out of limited accessibility
Table 4: Functional test case To ensure that the volunteer can make the best out of limited accessibility
script
1. Volunteer Rating: 5 Rating recorded and Rating recorded and Pass

records an Review: Respectful volunteer is taken to volunteer is taken
interaction and polite home screen to home screen
feedback
2. Volunteer skips Rating: None Message: Please rate Message: Please Pass
the feedback Review: None the interaction rate the interaction
3. Blind records Rating: 5 Rating recorded and Rating recorded and Pass
an interaction blind is taken to blind is taken to
feedback home screen home screen
4 Blind skips the Rating: None Rating skipped and Rating skipped and Pass
feedback Review: None blind is taken to blind is taken to
home screen home screen
Functional Testing 5: Audio processing and language processing

Objective: To ensure that the Blind will be able to run app and get help from the app in his own
language.
Table 5: To ensure that the Blind will be able to run app and get help from the app in his own language.
script
1. Volunteer Rating: 5 Rating recorded and Rating recorded and Pass

records an Review: Respectful volunteer is taken to volunteer is taken
interaction and polite home screen to home screen
feedback
Functional Testing 6: System will assign and run the app in the language that Blind select
Objective: To ensure that Blind can avail the whole app using voice commands in his language.
Table 6: Functional test case To ensure that Blind can avail the whole app using voice commands in his language.
script
1. Blind speak the Language: Urdu System assign the System has assign Pass
language he language Urdu to the language Urdu
wants to listen Blind to Blind

commands in
2. System did not Language: Null Message: speak the Message: speak the Pass
select the language language
language
3. System start the Instruction: started System start the System has start the Pass
instruction in instruction in Blind instruction in Blind
Blind choose language language
language.
Functional Testing 7: System will register and sign in the User

Objective: To ensure that User can avail the app.
Table 7: Functional test case To ensure that User can avail the app.
script
1. Volunteer Credentials: All fields System make an System has made Pass
wants to sign required account for an account for
up and make Volunteer Volunteer
his account
2. Volunteer Credentials: missing Message: Enter Message: Enter Pass
missed required fields missing fields. missing fields.
credentials in
the signup
process
3. Volunteers Credentials: Message: Enter Message: Enter Pass
enter Unmatched password matched password matched password
unmatched and confirm and confirm and confirm
password with password password password
confirm
password
4 Volunteer Credentials: Message: Email is Message: Email is Pass
wants to sign in Password and not registered not registered
Incorrect email
5 Volunteer Credentials: Incorrect Message: Incorrect Message: Incorrect Pass
wants to sign in Password and email password password
6 Volunteer want Credentials: correct Message: signed in Message: signed in Pass
to sign in Password and email
Functional Testing 8: System will provide Blind GPS voice guidance

Objective: To ensure that Blind can avail GPS voice guidance
Table 8: Functional test case To ensure that Blind can avail GPS voice guidance
script
1. Blind wants to Credentials: source Message: System Message: System Pass

get voice based missing destination will ask blind to will ask blind to
GPS guidance provide destination provide destination

2. Blind wants to Credentials: source Message: System Message: System Pass
get voice based Incorrect destination will ask blind to will ask blind to
GPS guidance provide correct provide correct
destination destination
3. Blind wants to Credentials: source System will start System will start Pass
get voice based and destination voice guidance voice guidance
GPS guidance
Functional Testing 9: System will provide offline services to Blind

Objective: To ensure that Blind can avail offline services
Table 9: Functional test case To ensure that Blind can avail offline services
script
1. Blind wants to Credentials: missing Message: System Message: System Pass

set an alarm either time or date will ask blind to will ask blind to
provide date and time provide date and
time
2. Blind wants to Credentials: date and Message: System Message: System Pass
set an alarm time will set alarm for will set alarm for
Blind Blind
3. Blind wants Credentials: person Message: Contact Message: Contact Pass
call/SMS name that is in not does not exist does not exist
anyone from his contact list
his contact list
4. Blind wants Credentials: person System will start call System will start Pass
call/SMS name that is in his or deliver SMS to call or deliver SMS
anyone from contact list that person to that person
his contact list
8.3 Business Rules Testing
Business Rule Testing 1: The nearest volunteer search should not take more than 60 seconds and
should not find a volunteer with more than 2 KMs of distance.
 System will search for volunteer for up to 60 seconds maximum.

 System will not return a volunteer if no available volunteer is found in 60 seconds.
Table 01 : Business Rule for search Volunteer

Conditions Rule 1 Rule 2
Volunteer search process T F
within 60 seconds
Find volunteer T F
 System will search for volunteer only within 2 KMs radius

 System will not return a volunteer if it is more than 2 KMs away from the blind
Table 2: Business rule for volunteer not found
Volunteer within 2 KM T F
Find volunteer T F
Now combining above rules
Table 03: Combining above rules

Conditions Rule 1 Rule 2 Rule 3 Rule 4
Volunteer search F T F T
process within 60
secs
Volunteer within 2 F F T T
KM
Actions
Find volunteer F F F T
Business Rule Testing 2: Notes uploading and fetching should not take more than 10 seconds.
 System is trying to upload notes for 10 seconds
Table 4: Business rule to test system notes uploading speed

System is trying to upload T F
notes for 10 seconds
Notes Inserted T F
Business Rule Testing 3: System listen get the audio process it and provide feedback instruction to
blind within 30 to 40 seconds.
 System is trying to process user audio
Table 5 : Business rule to test system audio processing
System is trying to process T F
user audio for 15 seconds
Audio processed T F
 System is trying to play the feedback instructions
Table 6: Business rules for system providing system feedback

System is trying to ready the T F
feedback audio to play for 15
seconds
Feedback audio is ready T F
 Combining above rules

Table no 7: Combining above rules
System is trying to process F T

user audio for 15 seconds
System is trying to ready the F T
feedback audio to play for 15
seconds
Actions
Audio processed and feedback F T
audio played
8.4 Integration Testing
Integration Testing 1: Get help from volunteer

Testing Objective: To ensure that the volunteer help management is being done correctly and the
interface between module ‘Volunteer Search’ and module ‘Video Calling’ is running correctly.
Table 1:Integration testing for help from volunteer

script
1. Call a volunteer Volunteer’s Successfully established a Successfully Pass

availability, blind’s call with both blind and established a
and volunteer’s user volunteer in it call with both
IDs blind and
volunteer in it
Integration Testing 2: Share blind’s location with volunteer

Testing Objective: To ensure that the interface between module ‘GPS based help management’
and module ‘Video Calling’ is running correctly.
Table 2:Integration testing for share blind location

script
1. Share location Location: Blind’s Volunteer will get the Volunteer Pass
latitude and location of the blind will get the
longitude location of
the blind
Integration Testing 3: Rate the volunteer

Testing Objective: To ensure that the user rating is being done correctly and the interface between
module ‘Review System’ and module ‘Voice based control’ is running correctly
Table 3:Integration testing for rating the volunteer

script
1. Rate the Rating: Number of Rating recorded Rating Pass

volunteer stars successfully recorded
successfully
9. Plagiarism Report

Latest

Uploaded by

Copyright:

Available Formats

Latest

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Latest

Uploaded by

Copyright:

Available Formats

COMSATS University Islamabad (CUI)

Software Design Description

See Through My Eyes

Bachelor of Science in Computer Science (2020-2024)

Application Evaluation History

Comments (by committee) Action Taken

1.1.1 Module 1: Software as a Service

1.1.2 Module 2: Voice Based Control

1.1.3 Module 3: User Profile Management

1.1.4 Module 4: Volunteer Search

1.1.5 Module 5: Video Call

1.1.6 Module 6: GPS based help management

1.1.7 Module 7: Review System

1.1.8 Module 8: Voice based Operations

2. Design Methodology and Software Process Model

3.1 Architectural Design

Figure 1: Box and Line Architecture Diagram

4.1.1 Shaking phone and open the app

Figure 2: Activity diagram to open app on shake

4.1.2 Run app on Voice command

Figure 3: Activity diagram to run the app on voice commands

4.1.3 Sign Up for Volunteer

Figure 4 Activity Diagram for Volunteer Sign up:

4.1.4 Sign Up for Blind

Figure 5: Activity diagram For Blind sign up

4.1.5 Volunteer Login

Figure 6: Activity diagram For Volunteer Login

4.1.6 Volunteer update profile

Figure 7: Activity diagram For Volunteer update profile

4.1.7 Volunteer Delete profile

Figure 8: Activity diagram For Volunteer delete profile

4.1.8 Admin can delete Volunteer

Figure 9: Activity diagram For Admin delete Volunteer

4.1.9 Admin/Volunteer share the App

Figure 10: Activity diagram For Sharing App

4.1.10 Volunteer Search

Figure 11: Activity diagram For Volunteer Search

4.1.11 Connect Blind and Volunteer in a Call

Figure 12: Activity diagram for establish video call

4.1.12 Capture Static Image

Figure 13: Activity diagram for capture static image

4.1.13 Zoom In / Zoom Out the Screen:

Figure 14: Activity diagram for zoom in/ zoom out

4.1.14 Switch Blind Camera

Figure 15: Activity diagram for switch camera screen

4.1.15 Turn off Blind Camera

Figure 16: Activity diagram for turning off video feed

4.1.16 GPS Guidance

Figure 17: Activity diagram for GPS guidance

4.1.17 Get blind current location

Figure 18: Activity diagram for getting blind current location

4.1.18 Blind Rating

Figure 19: Activity diagram for blind rating

4.1.19 Volunteer Rating

Figure 20: Activity diagram for volunteer rating

4.1.20 Offline Notes help

Figure 21: Activity diagram for offline notes help

4.1.21 Offline Native Call

Figure 22: Activity diagram for offline call help

4.1.22 Offline Native SMS