CHAPTER THREE

SYSTEM MODEL, ANALYSIS AND DESIGN

3.0 INTRODUCTION

The suggested system will be analyzed and tested. The functional and non-functional
requirements of the proposed system will also be stated. Harry J. Rosenblatt defined system
analysis and design as a step-by-step process for developing high-quality information systems.
(Rosenblatt, 2014). Software development life cycle has to do with different phases (and forms)
that a software under development undergoes, in order to have a complete deployable software
product.

3.1 PROCESS MODEL

The software development process model to be used in the development of this project is the
Verification and Validation (V-shaped) process model. The V-model is a type of SDLC model
where process executes in a sequential manner in V-shape. It is also known as Verification and
Validation model. It is based on the association of a testing phase for each corresponding
development stage. Development of each step directly associated with the testing phase. The
next phase starts only after completion of the previous phase i.e. for each development activity,
there is a testing activity corresponding to it.

3.1.1 V-shape Model Verification: It involves static analysis technique (review) done
without executing code. It is the process of evaluation of the product development phase to
find whether specified requirements meet.

3.1.2 V-shape Model Validation: It involves dynamic analysis technique (functional, non-
functional), testing done by executing code. Validation is the process to evaluate the software
after the completion of the development phase to determine whether software meets the
customer expectations and requirements. V-Model contains Verification phases on one side of
the Validation phases on the other side. Verification and Validation phases are joined by
coding phase in V-shape. Thus, it is called V-Model.
The phases in the V-Shape model listed sequentially are:
i. Design Phase:

 Requirement Analysis: This phase contains detailed communication with the

customer to understand their requirements and expectations. This stage is known as
Requirement Gathering.
 System Design: This phase contains the system design and the complete hardware
and communication setup for developing product.
 Architectural Design: System design is broken down further into modules taking
up different functionalities. The data transfer and communication between the
internal modules and with the outside world (other systems) is clearly understood.
 Module Design: In this phase the system breaks down into small modules. The
detailed design of modules is specified, also known as Low-Level Design (LLD).

ii. Testing Phases:

 Unit Testing: Unit Test Plans are developed during module design phase. These
Unit Test Plans are executed to eliminate bugs at code or unit level.
 Integration testing: After completion of unit testing Integration testing is
performed. In integration testing, the modules are integrated and the system is
tested. Integration testing is performed on the Architecture design phase. This test
verifies the communication of modules among themselves.
 System Testing: System testing test the complete application with its functionality,
inter dependency, and communication. It tests the functional and non-functional
requirements of the developed application.
 User Acceptance Testing (UAT): UAT is performed in a user environment that
resembles the production environment. UAT verifies that the delivered system
meets user’s requirement and system is ready for use in real world.
 Figure 3.1: V-Shape development process model.

3.1.3 Industrial Challenge: As the industry has evolved, the technologies have become
more complex, increasingly faster, and forever changing, however, there remains a set of basic
principles and concepts that are as applicable today as when IT was in its infancy.

 Accurately define and refine user requirements.

 Design and build an application according to the authorized user requirements.
 Validate that the application they had built adhered to the authorized business
requirements.

3.1.4 Principles of V-Model:

 Large to Small: In V-Model, testing is done in a hierarchical perspective, For
example, requirements identified by the project team, create High-Level Design,
and Detailed Design phases of the project. As each of these phases is completed the
requirements, they are defining become more and more refined and detailed.
 Data/Process Integrity: This principle states that the successful design of any
project requires the incorporation and cohesion of both data and processes. Process
elements must be identified at each and every requirements.
  Scalability: This principle states that the V-Model concept has the flexibility to
accommodate any IT project irrespective of its size, complexity or duration.
 Cross Referencing: Direct correlation between requirements and corresponding
testing activity is known as cross-referencing.
 Tangible Documentation: This principle states that every project needs to create a
document. This documentation is required and applied by both the project
development team and the support team. Documentation is used to maintaining the
application once it is available in a production environment.

3.1.5 Why preferred V-Shape Model?

 It is easy to manage due to the rigidity of the model. Each phase of V-Model has
specific deliverables and a review process.
 Proactive defect tracking – that is defects are found at early stage.

3.1.6 When to use V-Shape Model?

 Where requirements are clearly defined and fixed.

 The V-Model is used when ample technical resources are available with technical
expertise.
3.1.7 Advantages:
 This is a highly disciplined model and Phases are completed one at a time.
 V-Model is used for small projects where project requirements are clear.
 Simple and easy to understand and use.
 This model focuses on verification and validation activities early in the life cycle
thereby enhancing the probability of building an error-free and good quality
product.
 It enables project management to track progress accurately.

3.1.8 Disadvantages:
 High risk and uncertainty.
 It is not a good for complex and object-oriented projects.
  It is not suitable for projects where requirements are not clear and contains high risk
of changing.
 This model does not support iteration of phases.
 It does not easily handle concurrent events.

3.2 ANALYSIS OF THE PROPOSED SYSTEM

The apartment management system will alleviate the problems customers face when they need to
express their feeling and experience on companies’ products or services. These feedbacks help
companies to improve on their product or services the render to the customers. The system will
be a website which will allow customers to send feedbacks online while also providing their
contact details and allow admin to react or reply to the customers feedbacks for possible
solutions.

3.2.1 FEATURES OF THE PROPOSED SYSTEM

The features of the online customer relation management system in addition is a very friendly
user interface;

 A homepage where customers can create a ticket and express is feelings or complaints.
 A login page where a registered customers can login to their account
 A sign-up page for new users
 A centralized database that stores all property listings and user details.
 An inbox where users can view feedbacks made about their complaints

3.2.2 USER REQUIREMENTS

User requirements refers to the functions that can be performed by the users of a system. The
user requirements for the online customer relation management system are:

 Users should be able to login to the system

 User should be able to create a ticket and easily send his/her complaints to the system
 Users should be able to get replies from the admin through the platform.
 Users should be able see the present status of his/her complaints.

3.2.3 SYSTEM REQUIREMENTS

The system requirements give descriptions of the system services. They are our expectations of
the system as a whole. The system requirements for the online real estate property management
system are:

 The system should enable only registered Admin and Customers to login
 The system should enable logged-in customers to create a ticket for their complaints
 The system should allow admin to reply to each and every customer complaint.
 The system should enable user to view all their complaints ticket list and their status

3.3 THE DESIGN MODEL

3.3.1 USE CASE DIAGRAM

A use case diagram shows the functionalities of a system represented as use cases in terms of
actors, their goals and any dependencies between them. It shows the functionality that an end
user can perform on the system when developed.

Figure 3.3.1a: Customer use case diagram

 Figure 3.3.1b: Admin use case diagram

3.3.2 ENTITY RELATIONSHIP DIAGRAM

Entity Relationship Diagram, also known as ERD is a diagram that displays the relationship of
entity sets stored in a database. ER diagrams help to explain the logical structure of databases.
ER diagrams are created based on three basic concepts: entities, attributes and relationships.

Figure 3.3.2: CRM Database Entity relationship Diagram

3.4 THE DEVELOPMENT TOOLS

The Development tools consists of the applications and programming languages to be used in
implementing the online real estate property management system. The development tools to be
used are:

I. Hypertext Markup Language(HTML): It will be used for structuring the different

webpages that will be created for this project and the tags will help to generate links that
will connect the pages together or different pages to one another.
II. Cascading Style Sheets(CSS): It will be used to add styling to the HTML pages.
III. Hypertext Preprocessor(PHP): It is a scripting language that will be used to allow the
webpages to be more interactive and allow communication between the browser and the
system
IV. X.A.M.P.P (Cross platform, Apache, MySQL, PHP and Perl): It will be used to create a
local server, host the database and server on the computer to be used for development.
V. MySQL: It will be used as the Database Management System
VI. Atom: The text editor that will be used

3.5.1 HARDWARE REQUIREMENTS

 Hard disk capacity: at least 20 GB.

 RAM size of 2GB

3.5.2 SOFTWARE REQUIREMENTS

 Operating system: Microsoft Windows 10.

 JavaScript-enabled web browsers: Mozilla Firefox (most suitable), Internet Explorer,

Google Chrome were used.