Documentation 30 PC

IT- UOG - Project Management Office Version: 1.
0
Final Project Deliverable Guide Date: November 2, 2017
Department of Information Technology
University of Gujrat
Final Year Project Title
Submitted By:
Student Name Touqeer Reg#17181598-001

Haider Awan
Student Name Usman Reg# 17181598-007
Ali
Supervised By:
Supervisor’s Name
Uzma Ijaz
© Department of Information Technology.

1
IT- UOG - Project Management Office Version: 1.0

2
First Deliverable
Chapter 1: Project Feasibility Report
TABLE OF CONTENTS
1.1. 1.1. INTRODUCTION..............................................................................................3
1.2. PROJECT/PRODUCT FEASIBILITY REPORT.................................................................4
1.2.1. Technical Feasibility.........................................................................................4
3
1.2.2. Operational Feasibility......................................................................................4

1.2.3. Economic Feasibility.........................................................................................4
1.2.4. Schedule Feasibility...........................................................................................4
1.2.5. Specification Feasibility....................................................................................4
1.2.6. Information Feasibility......................................................................................4
1.2.7. Motivational Feasibility.....................................................................................4
1.3. PROJECT/PRODUCT SCOPE........................................................................................5
1.4. PROJECT/PRODUCT COSTING....................................................................................5
1.4.2. Project Cost Estimation by using COCOMO’81 (Constructive Cost Model)...5
1.5. TASK DEPENDENCY TABLE.......................................................................................5
1.6. CPM - CRITICAL PATH METHOD..............................................................................6
1.7. GANTT CHART...........................................................................................................7
1.8. INTRODUCTION TO TEAM MEMBER AND THEIR SKILL SET........................................8
1.9. TASK AND MEMBER ASSIGNMENT TABLE................................................................8
1.10. TOOLS AND TECHNOLOGY WITH REASONING.......................................................10
1.11. VISION DOCUMENT...............................................................................................10
1.12. RISK LIST..............................................................................................................10
1.13. PRODUCT FEATURES/ PRODUCT DECOMPOSITION................................................11

4
1.1. 1.1. Introduction

Real Estate is the business of buying, selling, and renting land, buildings, and offices.
Every person wants his house should be best in a location with all facilities. Offices
should be near to market and product unit near to raw material and marketplace. General
companies concentrate on its product and infrastructure are bought from Real Estate
company. Due to competition in this industry, every real estate company wants to deliver
the best service and makes its customer satisfied. Property Management System is a
software which takes care of everything that a real estate company want to do. Property
Management System is developed for real estate Company. It is very strong and easy to
use that makes quick booking and account handling process
1.2. Project/Product Feasibility Report

1.2.1. Technical Feasibility
Smart Predictor for Stock and Crypto-Currency is going to be an android application and
iOS application. It will be built in android studio using Flutter. Project can be developed
in 7-8 months. There is no noticeable technical constraint in it.
It is possible to develop and implement the proposed system with all functionality.
All the group members possess the required technical expertise. The technologies we
are using are commonly used, latest and easily available.
1.2.2. Operational Feasibility
Easy Investment have no operational constraint. User will be able to view property details
and book appointment easily.
1.2.3. Economic Feasibility
Being android and iOS application SPSC will have only one-time cost to upload on
respective store account. So, this project is economically feasible.
1.2.4. Schedule Feasibility
This project is feasible with respect to schedule as whole team is mostly available and
working properly. We are arranging meetings, with our instructor, which helps us
matching up with schedule. It is possible to complete all the amount and scope of work
lying ahead, utilizing the given number of resources, within required period All the
Project Estimation, Gantt & PERT chart and CPM prove that the project can be
completed in scheduled time.
1.2.5. Specification Feasibility
The requirements of this system are very clear as it is a customer’s demanded project.
Project scope and requirements are given by client.
1.2.6. Information Feasibility
Information through this project will be complete, reliable, and meaningful. We will try
to provide real information as much as possible.
1.2.7. Motivational Feasibility
This project is motivationally feasible as project is being develop for a client.
1.2.8. Legal & Ethical Feasibility

5
The project is legal and ethically feasible and there are no infringements or liabilities
raised through this project. We are owed to develop the application that is both
professional and ethical.
1.3. Project/Product Scope

The Easy Investment is android and iOS application developed for Bajas Easy Investment
that help buyers to view different properties and book an appointment to visit the
property. This app provide most efficient and less time consuming way for Bajas Easy
Investment to show case their properties.
This app ensures the service to client 24/7. Clients can view and book their favorite
property online just after few clicks. Easy Investment also will be able to upload any kind
of document for user to view. This app also allow admin to provide site pictures and
videos so that user can have clear view of the properties.
1.4. Project/Product Costing

1.4.2. Project Cost Estimation by using COCOMO’81 (Constructive Cost Model)
Basic COCOMO
Type Effort Schedule
Semi-Detached PM= 3.0 (KLOC)1.12 TD= 2.5(PM)0.35
PM= 3.0 (5)1.12 = 18.2 TD= 2.5(18.2)0.35= 6.9
PM= person-month (effort)
KLOC= lines of code, in thousands
TD= number of months estimated for software development (duration)
People Required = Effort / Duration = 18.2/6.9 = 2
1.5. Task Dependency Table

Activity
Activity Dependencies Duration (Weeks)
Description
A Requirement gathering N/A 1 week
B Proposal making A 2 weeks
Application and database
C B, A 4 weeks
basic schema making
Application interface
D N/A 4 weeks
designing
E Application development D 8 weeks
F Testing D, E 4 weeks
G Improvements D, E 4 weeks

6
1.6. CPM - Critical Path Method

Activity Immediate Predecessor Duration (Weeks)
A None 1
B A 2
C A, B 4
D None 4
E D 8
F D, E 4
G D, E 4
Network Diagram

7
Figure 1.1: Network Diagram
Activity Duration ES EF LS LF TS FS
A 1 0 1 13 14 13 1
B 2 1 3 14 16 13 2
C 4 3 7 16 20 13 4
D 4 0 4 0 4 0 4
E 8 4 12 4 12 0 8
F 4 12 16 12 16 0 4
G 4 16 20 16 20 0 4
The critical path is: D, E, F, G
1.7. Gantt chart

8
1.8. Introduction to Team member and their skill set

Name Skill set Task
Usman Ali iOS developer, Analysis of Documentation,
Documentation, Testing Testing and Developing
Application
Touqeer Haider Awan Android developer, Front- Application Front-End

End Developer development, Analysis of
Expertise in UI/UX Documentation
1.9. Task and Member Assignment Table

Task Duration (weeks) Dependencies Members
T1 2 M1, M2,
T2 2 M1
T3 4 T1 M2
T4 1 T3 M1
T5 9 T3, T4 M1, M2
T6 4 T5 M1, M2
T7 4 T6 M1, M2

9
Task durations and dependencies
Activity Bar Chart
Allocation of People to Activities:

Task Engineer
T1 Usman, Touqeer
T2 Usman
T3 Touqeer
T4 Usman
T5 Usman, Touqeer
T6 Usman, Touqeer
T7 Usman, Touqeer

10
Staff Allocation:
1.10. Tools and Technology with reasoning

Android Studio Android is best IDE out there to code
Flutter To develop a cross platform app (Android and iOS)
Microsoft Visio Will be use to draw different diagrams and structures
Microsoft Project To create timeline or event related work and diagrams
1.11. Vision Document

Our vision is to make an android and iOS application that will help our client to perform
day to day business activities. This application will enable buyers to view property details
and get an appointment on a button click, thus reducing the waiting time and hassle to
view and buy property.
1.12. Risk List

 Improper time management
 Deadlines fulfillment
 Not identification of hidden risks

11
1.13. Product Features/ Product Decomposition

 Admin panel
 Client panel
 Property details
 Appointment booking
 User management
 Investment option
 Mapping

12
Second Deliverable For Object Oriented Approach
Chapter 2: System Requirement Specification
2.1 Introduction:
Requirements engineering process provides the appropriate mechanism for understanding
what the customer wants, analyzing need, assessing feasibility, negotiating a reasonable
solution, specifying the solution unambiguously, validating the specification and

13
managing the requirements as they are transformed into an operational system. The task
of capturing, structuring, and accurately representing the user's requirements so that they
can be correctly embodied in systems which meet those requirements (i.e. are of good
quality).
 Requirements elicitation
 Requirements analysis and negotiation
 Requirements specification
 System modeling
 Requirements validation
 Requirements management
Here, requirements specification is to be discussed. Requirements specification would

lead to the following four steps:
 Identify external interfaces

14
 Development of context diagram

 Capture “shall statements
 Allocate requirements
 Prioritize requirements
 Development of requirements traceability matrix
2.1.1 Systems Specifications
The following are the clauses that must be included while describing the system
specifications.
Introduction
Real Estate is the business of buying, selling, and renting land, buildings, and offices.
Every person wants his house should be best in a location with all facilities. Offices
should be near to market and product unit near to raw material and marketplace. General
companies concentrate on its product and infrastructure are bought from Real Estate
company. Due to competition in this industry, every real estate company wants to deliver
the best service and makes its customer satisfied. Property Management System is a
software which takes care of everything that a real estate company want to do. Property
Management System is developed for real estate Company. It is very strong and easy to
use that makes quick booking and account handling process.
Existing System
 Existing doesn’t provide multiple language.
 The system doesn’t user friendly interface.
 Lack of security.
 The system doesn’t provide document about property.
Organizational Chart
Scope of the System

Easy Investment is a mobile application that target the business in every field to manage
the property.
Phase 1:

15
 Admin Account.
 Customer Account.
Phase 2:
 Property Records.
 Property Management.
 Newsletter.
 Payments
Summary of Requirements: (Initial Requirements)
An abstract is necessary at this stage to give an understanding of the initial requirements
of the system. This will show what high level requirements the proposed system must
address. This abstract will act as a foundation for the future analysis of the system.
2.1.2. Identifying External Entities
The Identification of External Entities is done in two phases.
a. Over Specify Entities from Abstract:
 Admin
 Customer
 Property Management.
 Newsletter.
 Location
 Payments
b. Perform Refinement:
 Admin.
 Customer.
 Database.
 Payments.
2.1.3. Context Level Data Flow Diagram:
2.1.4. Capture "shall" Statements:

Para Initial Requirements

16
#
1.0 Registration
1.1 A admin “shall” register himself to the system.
1.2 An user “shall” register himself to the system.
1.3 Admin “shall” login to the system.
1.4 User “shall” login to the system.
1.5 Admin “shall” update his personal details.
1.6 User “shall” update his personal details.
1.7 Admin “shall” process different types of updating e.g. updating of his personal
details, updating his password or upgrading his managements.
2.0 Manage
2.1 Admin “shall” manage their property.
2.2 Admin “shall” manage property location.
2.3 Admin “shall” manage newsletter.
2.4 Customer “shall” manage the payments.
3.0 Action
3.0 An action event "shall" be generated for a corresponding administrator when a
property are to be sale.
4.0 NON- Functional Requirements:
4.1 System shall be easy to recover.
4.2 System will show rapid response, there shall be no delays for the Property to be fetch
from Database.
4.3 System shall consistently performs the specified functions without failure.
4.4 System shall be able to expand its processing capabilities.
4.5 System shall be modifiable to adopt to different environments.
4.6 System shall be able to point out faults and fix them
2.1.5. Allocate Requirements:

Para # Initial Requirements Use Case Name
1.1 A admin “shall” register himself to the UC_Admin_SignUp
system.
1.2 An Customer “shall” register himself to the UC_Customer_SignUp
system.
1.3 Admin “shall” login to the system. UC_Admin_Login
17
UC_Password_Verification
1.4 Customer “shall” login to the system. UC_ Customer _Login
UC_Password_Verification
1.5 Admin “shall” update his personal details. UC_Admin_Update_Profile
1.6 Customer “shall” update his personal details. UC_ Customer _Update_Profile
1.7 Admin “shall” process different types of UC_Update_Password
updating e.g. updating of his personal
details, updating his password or upgrading
his managements.
2.1 Admin “shall” manage their property. UC_Property_Management
2.2 Admin “shall” send newsletter. UC_Newsletter
2.3 Admin “shall” manage to sale the property UC_Property_Sale
2.4 Admin “shall” manage the payments. UC_Payment

3.1 An action event "shall" be generated for a UC_Admin_Action
corresponding administrator when a property
are to be sale.
.
2.1.6. Prioritize Requirements:
Pa Rank Initial Use Use Case Name

ra Requirements Case
# ID
1.0 Highest A admin “shall” UC_1 UC_Admin_SignUp
register himself
to the system.
1.0 Highest An customer UC_2 UC_ Customer _SignUp
“shall” register
himself to the
system.
1.0 Highest Admin “shall” UC_3 UC_Admin_Login
login to the UC_4 UC_Password_Verification
system.
1.0 Highest Customer “shall” UC_5 UC_ Customer _Login
login to the UC_6 UC_Password_Verification
system.
2.0 Highest Admin “shall” UC_7 UC_Property_Managemnet

18
manage their
property.
2.0 Highest Admin “shall” UC_8 UC_Newsletter
send newsetter
2.0 Highest Customer “shall” UC_9 UC_Appointment_Generation,
generate mail to
get appointment
2.0 Highest Admin“shall” UC_10 UC_Payment
manage the
payments.
1.0 Medium Admin “shall” UC_11 UC_Admin_Update_Profile
update his
personal details..
1.0 Medium Customer “shall” UC_12 UC_Customer_Update_Profile
update his
personal details
1.0 Lowest Admin “shall” UC_13 UC_Update_Password
process different
types of updating
e.g. updating of
his personal
details, updating
his password or
upgrading his
managements.
3.0 Lowest An action event UC_14 UC_Admin_Action
"shall" be
generated for a
corresponding
administrator
when a Property
are to be sale.
2.1.7. Requirements Trace-ability Matrix:
Sr# Para Initial Bui Use Case Name Category

# Requirements ld
1 1.0 A admin “shall” B1 UC_Admin_SignUp Business
register himself
to the system.
2 1.0 An Customer B1 UC_ Customer _SignUp Business
“shall” register
19
himself to the
system.
3 1.0 Admin “shall” B1 UC_Admin_Login Business
login to the UC_Password_Verification
system.
4 1.0 Customer “shall” B1 UC_ Customer _Login Business
login to the UC_Password_Verification
system.
6 1.0 Admin “shall” B1 UC_Admin_Update_Profile Business
update his
personal details..
7 1.0 Customer “shall” B1 UC_ Customer _Update_Profile Business
update his
personal details
8 1.0 Admin “shall” B1 UC_Update_Password Business
process different
types of updating
e.g. updating of
his personal
details, updating
his password or
upgrading his
managements.
9 2.0 Admin “shall” B1 UC_Property_Management Business
manage their
property
10 2.0 Admin “shall” B1 UC_Newsletter Business
send newsletter.
11 2.0 Admin “shall” B1 UC_Location Business
manage their
property
location.
12 2.0 Admin “shall” B1 UC_Property_Payment Business
manage their
property payment
13 3.0 An action event B1 UC_Admin_Action Business
"shall" be
generated for a
corresponding
administrator
when a Property
are to be sale.

20
2.2.10. High Level Usecase Diagram:
Figure: 2.2.10

21
2.2.11. Analysis Level Usecase Diagram:
Figure: 2.2.11
2.2.12. Usecase Description

While technically not part of UML, use case documents are closely related to UML use
cases. A use case document is text that captures the detailed functionality of a use case.
Such documents typically contain the following parts:
Registration
Use Case ID 1
Use Case Name UC_Admin_SignUp
Description The system registers a Admin
Primary Actor Admin
Precondition Admin use a Mobile App

22
Scenario / Basic Flow Actor System
1. Enter the necessary 2. Verify information and create

information. Account
Post condition Admin account will be created

Alternative Scenario 1. If Admin credentials are invalid, highlight invalid entries and prompt
the admin to enter correct information.
2. If record already exists in the database, show error message.
Customer Registration
Use Case ID 2
Use Case Name UC_Customer_SignUp
Description The system registers a Customer
Primary Actor Customer
Precondition Customer a Mobile App
1. Enter the necessary 2. Verify information and create

information. Account
Post condition Customer account will be created

Alternative Scenario 1.If Customer credentials are invalid, highlight invalid entries and
prompt the admin to enter correct information.
2.If record already exists in the database, show error message.
Admin Login
Use Case ID 3
Use Case Name UC_Admin_SignIn
Description The App Login an Admin
Primary Actor Admin
Precondition Admin should be registered
1. Registered Admin will 2. Show login console

select “LogIn” option
3.Enter the Username and 4.Authenticate the details
Password.

23
5.Click on “LogIn” Button 6.Show actor’s Main Menu
Post condition Admin will be logged in

Alternative Scenario 1.If username and password doesn’t match, the system will show an
error message and prompt the user to re-enter valid information.
Customer Login
Use Case ID 4
Use Case Name UC_Customer_SignIn
Description The App Login an Customer
Precondition Customer should be registered
1. Registered Customer will 2. Show login console

select “LogIn” option
3.Enter the Username and 4.Authenticate the details
Password.
5.Click on “LogIn” Button 6.Show actor’s Main Screen
Post condition Customer will be logged in

Alternative Scenario 1.If username and password doesn’t match, the system will show an
error message and prompt the user to re-enter valid information.
Password Verification
Use Case ID 5
Use Case Name UC_Password_Verifcation
Description The App authenticates the login information
Primary Actor App
Precondition The user/dietician enters username and password for logging in

24
1. Click on “LogIn” button 2. Find username in the database

and match the password
Post condition Username and password will be authenticated

Alternative Scenario 1.If password doesn’t match, the system prompts the user to re-enter
password and continue the login process.
2. If the username is not found in database, the system shows an
error and redirects the user to “SignUp” page.
Property Management
Use Case ID 6
Use Case Name UC_Property_Management
Description The app screen to select Property manage
Primary Actor Admin
Precondition Admin should be select the option.
1. From main_screen select 2. Request to system

Property management
3.Get response from system 4.Admin should be able to apply
CRUD operation.
Post condition Admin can use the system
Alternative Scenario Nill
Newsletter
Use Case ID 7
Use Case Name UC_Newsletter
Description The App screen to select send newsletter
Primary Actor Admin
Precondition Admin should be select the option.

25
1. From main_screen select 2. Request to system

send newsletter
3.Get response from system 4.Admin should be able to send
newsletter
Post condition Admin can use the system
Update Admin Profile

Use Case ID 8
Use Case Name UC_Update_Admin_Profile
Description Admin will update their profile
Primary Actor Admin
Precondition Admin must be logged in
1. Select “Profile” option 2. Get information from database

and display details
3. Click on “Edit” button 4. Show profile console menu
5. Enter new details 6. Authenticate the details
7. Click on “Save” button 8. Update database and display

updated profile details
Post condition Profile will be updated and new details will be shown
Alternative Scenario 1. If Admin enters invalid data, system will highlight the invalid
entries and prompt the Admin to enter correct information.
2. If Admin clicks on “Cancel” button, system cancels the
updating process and redirects the Admin to his profile.
Update Customer Profile

Use Case ID 9
Use Case Name UC_Update_Customer_Profile
Description Customer will update their profile
Precondition Customer must be logged in
26
1. Select “Profile” option 2. Get information from database

and display details
3. Click on “Edit” button 4. Show profile console menu
5. Enter new details 6. Authenticate the details
7. Click on “Save” button 8. Update database and display

updated profile details
Post condition Profile will be updated and new details will be shown
Alternative Scenario 1. If Customer enters invalid data, system will highlight the invalid
entries and prompt the Customer to enter correct information.
2. If Customer clicks on “Cancel” button, system cancels the
updating process and redirects the Customer to his profile.
Appointment
Use Case ID 10
Use Case Name UC_Appointment
Description Customer should manage his/her appointment
Precondition Customer must be logged in to manage his/her appointment
1. Enter the date get his/her 2. Set information about his/her

appointment appointment
Post condition Customer can send mail to get appointment to view property

27
Chapter 3: Design Document
3.1. Introduction:
Third deliverable is all about the software design. In the previous deliverable, analysis of
the system is completed. So we understand the current situation of the problem domain.
Now we are ready to strive for a solution for the problem domain by using object-
oriented approach. Following artifacts must be included in the 3rd deliverable.
28
1. Domain Model
2. System Sequence Diagram
3. Sequence Diagram
4. Collaboration Diagram
5. Operation Contracts
6. Design Class Diagram
7. State Transition Diagram
8. Data Model
Now we discuss these artifacts one by one as follows:
3.2. Domain Model

29
Figure: 3.2
3.3. System Sequence Diagram

30
The UML system sequence diagram (SSD) illustrates events sequentially input from an
external source to the system. The SSD will define the system events and operations.
System sequence diagrams are a timeline drawing of an expanded use case. Events are
related by time with the top events occurring first. System events are the important items.
These are events that cause a system response.
Figure: 3.3
3.4. Sequence Diagram

31
A Sequence diagram depicts the sequence of actions that occur in a system. The
invocation of methods in each object, and the order in which the invocation occurs is
captured in a Sequence diagram. This makes the Sequence diagram a very useful tool to
easily represent the dynamic behavior of a system.
Figure: 3.4.1

32
Figure: 3.4.2
Figure: 3.4.3
Figure: 3.4.4

33
Figure: 3.4.5
Figure: 3.4.6

34
Figure: 3.4.7
3.5. Collaboration Diagram

A collaboration diagram describes a pattern of interaction among objects; it shows the
objects participating in the interaction by their links to each other and the messages that
they send to each other.

35
Figure: 3.5
3.6. Operation Contracts

A UML Operation contract identifies system state changes when an operation happens.
Effectively, it will define what each system operation does. An operation is taken from a
system sequence diagram. It is a single event from that diagram. A domain model can be
used to help generate an operation contract.
Name Register()
Responsibilities Register an Admin and Customer to the system
Cross References UC_Registration
Preconditions There is an Admin and Customer willing to register himself to the
System
Postconditions
Admin and Customer was associated with a database
Admin and Customer was assigned with a username and a password.
Admin and Customer was registered successfully.
Exceptions Admin and d Customer details are invalid
Table: 3.6.1

36
Name LogIn()
Responsibilities User logins to the system
Cross References UC_Login
Preconditions User must be registered
Postconditions Username and password were entered by the user.
Entered credentials were matched with the database.
User was logged in successfully.
Exceptions User entered wrong credentials
Table: 3.6.2
Name AddProperty()
Responsibilities Admin adds a product to the system
Cross References UC_Property_Management
Preconditions Admin is logged in
Postconditions An add Property instance was created
Property was assigned a unique ID.
Property was associated with a database.
Property was added successfully.
Exceptions None
Table: 3.6.3
Name SearchProperty()
Responsibilities Admin search a product to the system
Postconditions Property was searched by unique ID.
Property was Search with a database.
Exceptions None
Table: 3.6.4
Name DelProperty()
Responsibilities Admin delete a product to the system

37

Postconditions A del Property instance was created
Property was Delete by unique ID.
Property was deleted with a database.
Property was deleted successfully.
Exceptions None
Table: 3.6.5
Name UpdateProperty()
Responsibilities Admin a product to the system
Postconditions An add Property instance was created
Property was edit by unique ID.
Property was edit with a database.
Property was edit successfully.
Exceptions None
Table: 3.6.6
Name Newsletter()
Responsibilities Admin a send a newsletter
Cross References UC_Newsletter
Postconditions An Admin add newsletter.
Admin send the newsletter
Exceptions None
Table: 3.6.7
Name Appointment()

38
Responsibilities Customer a send a appointment

Cross References UC_Appointment
Preconditions Customer is logged in
Postconditions An Customer add appointment.
Customer send the appointment
Exceptions None
Table: 3.6.8
3.7. Design Class Diagram

39
Figure: 3.7
3.8. State chart diagram

For some operations, the behavior of the operation depends upon the state the receiver
object is in. A state machine is a tool for describing the states the object can assume and
the events that cause the object to move from one state to another. State machines are
most useful for describing active classes. The use of state machines is particularly
important for defining the behavior. An example of a simple state machine is shown
below:

40
Figure: 3.8
3.9. Data Model

The data model is a subset of the implementation model, which describes the logical and
physical representation of persistent data in the system.

41
Figure: 3.9
Chapter 4: User Interface Design
4.1. Introduction
A user interface design consists of three main parts:

42
Page elements should be visualized on paper before building them in the computer. Just
as you draw a site map to plan the site, use cartoons and storyboards to begin blocking
out the site’s appearance and navigational scheme.
1. Site maps
2. Storyboards
3. Navigational maps
4. Traceability Matrix
4.2. Site Maps

A site map's main benefit is to give users an overview of the site's areas in a single glance
by dedicating an entire page to a visualization of the information architecture. If designed
well, this overview can include several levels of hierarchy, and yet not be so big that
users lose their ability to grasp the map as a whole. Some of the site maps we studied
stretched over six screens on a standard 800x600 monitor. This is much too much. We
recommend keeping the site map short; it should be no more than two-and-a-half times
the window size most common among your users.
The greatest failures in our study came from site maps that attempted to lure the user into
a dynamically twisting and expanding view, rather than presenting a simple, static
representation of the information architecture. The site map's goal is to give users a single
overview of the information space. If users have to work to reveal different parts of the
map, that benefit is lost.
Dynamic site maps are basically an alternative way of navigating through the information
space using a set of non-standard interaction techniques. For example, one site used a
hyperbolic tree, where users had to click and drag clusters of links around the screen to
expand areas of interest. Nobody could do this well.
A site map should not be a navigational challenge of its own. It should be a map.
As we have found again and again, users hated non-standard user interfaces that forced
them to learn a special way of doing things for the sake of a single website. Site maps
should be simple, compact layouts of links, and they should show everything in a single
view.
If your site is large and complex, it is a good idea to include and index or site map that
provides an outline of our site's content. This concept is something that we are all
familiar with in the print world and it is very useful on the Web. An index is usually an
alphabetical listing of key words that link to the appropriate pages in the site or it can be
more like a table of contents. A site map is a graphical representation of the site's
content. It doesn't usually have as much detailed information as the index has.
As web sites get more complicated, an index or site map is going to become more and
more valuable and essential to the navigation of a good site.
4.3. Story boards

A storyboard is a sequence of single images, each of which represents a distinct event or
narrative. It is also a visual representation of the script illustrating the interaction between

43
the user and the machine. It can also be imagined as a film in visual-outline form. There
are different attributes involved in story boards to represent our system describe below
 Environment:
The mobile application “Easy Investment” is used in business center like property
management. (UI ID #1)
Figure: 4.3.1
 Visual cues:
There is a dashboard provided for every user in which he/she can view their profile and
the functions they can be performed.
o First users will login themselves on the system.
o User enter the accurate information and get access to their dashboard.
o If user will enter the unvalid information he would be ask to try enter the correct
information again. In case if he forget his password he will also be able to recover
it.
After validation of user’s data , they will get access to system. (UI ID #2)

44
Figure: 4.3.2

45
o Login: (UI ID #3)
Figure: 4.3.3

46
o Admin Dashboard: (UI ID #4)
Figure: 4.3.4

47
4.4. Navigational maps:

The next step is of navigational maps. In these maps, the storyboards are used as an input.
The different display buttons or action buttons show the navigation from one screen to
the other.
There are basic modules of the system
o Add Property:
Figure: 4.4.1

48
o Newsletter:
Figure: 4.4.2

49
4.5 Trace-ability Matrix
Following columns are involved in the trace-ability matrix.
Feature: Lists system features based on which use case are

built.
Use Case ID: Write the ID of the use case for easy lookup.
UI ID: Write the user interface ID for this use case.
Priority: Give an appropriate rating to each use case
according to its priority
Use Case Cross Ref: rite the related use cases separated with commas.
DB Table Id: write the relevant DB table ID’s
Elaborated Use-case ID: Elaboration of the related Use Cases separated by
commas.
Dependent Classes: List of Classes separated by commas which are
involved in achieving the Feature.

50

Documentation 30 PC

Uploaded by

Document Information

Original Description:

Original Title

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

Documentation 30 PC

Uploaded by

Copyright:

Available Formats

IT- UOG - Project Management Office Version: 1.

Department of Information Technology

Final Year Project Title

Student Name Touqeer Reg#17181598-001

© Department of Information Technology.

© Department of Information Technology.

1.2.2. Operational Feasibility......................................................................................4

© Department of Information Technology.

1.1. 1.1. Introduction

1.2. Project/Product Feasibility Report

© Department of Information Technology.

1.3. Project/Product Scope

1.4. Project/Product Costing

1.5. Task Dependency Table

© Department of Information Technology.

1.6. CPM - Critical Path Method

© Department of Information Technology.

Figure 1.1: Network Diagram

The critical path is: D, E, F, G

1.7. Gantt chart

© Department of Information Technology.

1.8. Introduction to Team member and their skill set

Touqeer Haider Awan Android developer, Front- Application Front-End

1.9. Task and Member Assignment Table

© Department of Information Technology.

Task durations and dependencies

Activity Bar Chart

Allocation of People to Activities:

© Department of Information Technology.

1.10. Tools and Technology with reasoning

Flutter To develop a cross platform app (Android and iOS)

Microsoft Visio Will be use to draw different diagrams and structures

Microsoft Project To create timeline or event related work and diagrams

1.11. Vision Document

1.12. Risk List

© Department of Information Technology.

1.13. Product Features/ Product Decomposition

© Department of Information Technology.

Second Deliverable For Object Oriented Approach

Chapter 2: System Requirement Specification

© Department of Information Technology.

Here, requirements specification is to be discussed. Requirements specification would

© Department of Information Technology.

 Development of context diagram

Scope of the System

© Department of Information Technology.

2.1.4. Capture "shall" Statements:

© Department of Information Technology.

2.1.5. Allocate Requirements:

2.4 Admin “shall” manage the payments. UC_Payment

2.1.6. Prioritize Requirements:

Pa Rank Initial Use Use Case Name

© Department of Information Technology.

2.1.7. Requirements Trace-ability Matrix:

Sr# Para Initial Bui Use Case Name Category

© Department of Information Technology.

2.2.10. High Level Usecase Diagram:

© Department of Information Technology.

2.2.11. Analysis Level Usecase Diagram:

2.2.12. Usecase Description

© Department of Information Technology.

Scenario / Basic Flow Actor System