PowerMax Realty

Section Contents

3.1 Features

3.2 Major Classes of Functions
3.2.1 System Levels
3.2.2 Classes


3.3 Database Design
3.3.1 Table: LISTING
3.3.2 Table: AGENT_INFO
3.3.3 Table: OFFERS


3.4 Possible Implementation

3.5 Algorithms

3.6 Minimalist System and Enhancements

3.7 Things to Ponder

3.8 Structure of Team

3.1 Features

There are a variety of features relating to the project. The system was designed so that there were little movement between different screens. This is done because it would be easier to remember information and less time consuming. Each window has several functions that are easier to navigate between major functions.

1. Search Screen -
   
   When a user enters in search parameters and a search list shows up, they can select that listing and instead of going back to the search screen they can use the NEXT and PREVIOUS buttons to navigate through the found listings.
   
   
   
2. Listing Information Window -
   
   For every pop up window, there is a CLOSE button to close each pop-up window.
   
   
   
3. Search Screen -
   
   the user can easily CLEAR OPTIONS so they can enter in new search parameters.
   
   
   
4. All Screens -
   
   there is a help button that brings up a help window regarding information related to the current screen.
   
   
   
5. Realtor/Administrator Screen -
   
   there is the option to EXIT, where the user can log out from their level of access (Realtor or Administrator) or exit out of the database completely.
   
   
   

This system is designed according to the PowerMax Realty's specification and the system is provided for the 3 groups of people (described in detail in Part I). The first is the Property Buyer or Customer of PowerMax Realty, second is the Realtors (Listing and Non-Listing) that works for PowerMax and third is the Administrator of PowerMax Realty.

3.2.1 System Levels

This system has 3 levels:



1. Buyer -
   
   only has search capabilities of the database. They can view and print out listings of their choice.
   
   
   
2. Realtor -
   
   has functions of the Buyer but can edit listing (if their are the Listing Realtor), create listing, make offers and modify their own personal information.
   
   
   
3. Administrator -
   
   has all the functions of level 1 and 2 but can Reassign and Modify employee info. This is the highest level.
   
   
   

3.2.2 Classes

The system has Two major Classes (screens) with several functions within each screen. They are:



1. Search Catalog System (Buyer's Search Screen)
   
   
   • The users are: The Buyer, Realtor and Administrator.
     
     
   • Search -
     
     This part is capable of searching through a database of listings (properties) available on the market. The user can enter in search parameters and after a search has been initiated, possible listings would show up on the screen. The user can select any of the found listings and another window would show up and give details of that listing.
     
     
   • New Access -
     
     this hidden button (described in Part 2) allows new access to the Realtor / Administrator level via a password (security reasons)
   
   
2. Realtor / Administration Screen
   
   
   
   • Search -
     
     When the user (Realtor/Administrator) gains their access, to this screen they do not have to go back down to the first level to search the database. When the user wants to do a search, a search screen comes up, however it is different from the Buyer's search screen, with one minor difference. There is button to go back to the Realtor / Administration Screen.
     
     
   • Make an Offer -
     
     allows the user (Listing Realtor/Administrator) to enter a reference number (of the listing in the found list) and make offers to a selected listing.
     
     
   • View/Modify Listing -
     
     allow the user (Listing Realtor/Administrator) change the listing information and view the offers of that listing, but for the Non-Listing Realtor, they would just view the general information of that listing.
     
     
   • New Listing -
     
     Allow a Realtor enter in information of a new property, to be placed in the database.
     
     
   • Modify Personal Information -
     
     allow a Realtor to modify their personal information without having to go to the Administrator all the time to make minor changes.
     
     
   • Re-Assign and Modify Employee Information -
     
     allow the Administrator to add, delete and modify employee information. Also this level allows the administrator to reassign realtors to a listing.

3.3 Database Design

All data used by the real estate listing system will be managed by a commercial relational database system (to be determined). The database employed will consist of 4 tables. The tables along with the pieces of information they will hold are detailed below.

For those who are interested, table keys are shown as well:

PK indicates a primary key.
FK indicates a foreign key and the table it references.

The members of a composite key are identified by a vertical series of parenthesis.

      e.g Second Field    )FK SOME_TABLE
          Third Field     )
          Fourth Field


(Primary and foreign keys are used to help ensure the integrity of the information in the database.)





3.3.1 Table: LISTING

Fields: Listing ID Number       PK
        Agent Login ID          FK AGENT_INFO
        Area                    )FK AREAS
        Date Listed
        Date Listing Expires
        Type (Rental/Sale)
        Description
        Price
        Location
        Picture
        Square Feet
        Status (i.e. SOLD, NEW, HOLD)
        Style (i.e. BUNGALOW)
        Lot Size
        Age of House
        Bathrooms
        Number of Rooms
        Appliances
        Garage
        Finished Basement
        Seller Comments
        Seller Name
        Seller City
        Seller Street Address
        Seller Postal Code
        Seller Phone



3.3.2 Table: AGENT_INFO

Fields: Agent Login ID          PK
        Name
        Home Address
        Phone
        Pager
        Fax
        Email



3.3.3 Table: OFFERS

Fields: Offer ID Number         PK
        Listing ID Number       FK LISTINGS
        Agent Login ID          FK AGENT_INFO  (Agent making offer)
        Amount
        Comments

Table:  AREAS

Fields: Area            PK
        X Coordinate    (used to determine the area of a city map)
        Y Coordinate    (selected by user)




3.4 Possible Implementation

The application will be implemented using a "Fourth Generation Language" (4GL) with a relational database and a Graphical User Interface (GUI), such as Microsoft Access. The GUI is used to present the user with a simple, easy to understand, and easy to use inteface. The use of a 4GL also facilitates fast development and easy modification of the program.

3.5 Algorithms

Because of the nature of the application, most of its functions deal with straight-forward database operations--inserting, updating, and deleting records according to the inputs of the user. The high level algorithms for a couple of the functions may be of interest, however.

Area Selection -


The user can select the area of the city to include in a search by mouse-clicking on an area of a map. In the data base, the x and y coordinates for each "hot spot" are stored along with name of the area associated with that hot spot. When the user clicks on the map, the mouse-pointer's coordinates are noted and compared with those of each area in the database. The name of the closest area is returned.

Archiving -


The record for each listing holds the date the listing expires. The archiving function prepares expired records for writing to an offline storage medium (i.e. tape) and deletes affected records from the database. The process has 3 steps:
1. Write affected records to a flat file (formats vary, but a simple Comma Separated Values (CSV) text file might be used with 1 record per line).
   
2. Copy file to offline storage.
   
3. Delete affected records.
   

3.6 Minimalist System and Enhancements

The system we have described and intend to implement by the end of February is a relational database of property listings, real estate agents, and offers made to rent or purchase properties.

The primary function of the system, and the function any user can use, is to search for and display property listings which match a real estate customer's set of criteria. As it stands, the method by which the criteria can be chosen is fairly simplistic. That is likely the weakest part of the interface to the database, and yet enhancing it might make using the interface too difficult for users unfamiliar with the system.

what we are proposing	what might be desirable
only four regions within a city are defined - the northwest,northeast, southwest, and southeast quadrants	finer map resolution, i.e. more regions available from which to select; perhaps even several levels of map, from quad to neighbourhood
it is possible to select only zero or one region in the city for any one given search	make it possible to select any of the regions independently of any other selection that has been made
it is possible to select only zero or one property style for any one given search	make it possible to select any property style (e.g. bungalow or duplex) independently of other ones
many controls are cryptic in function, having only single words as labels	rename the controls according to a schema that is perhaps further from the Windows standard
searches are static: criteria are entered and then a "search" control is invoked	make searches dynamic: criteria are entered which become real-time constraints on the set of matches


A major consideration when designing the search screen and the search results screen was the fact that they must accommodate completely naive users, and thus be simple and intuitive as opposed to complex and flexible. By contrast, it can be expected that any user who has sufficient privilege to use the other parts of the system will also have experience with real estate terminology if not computer Technology, and thus the screens dedicated to them can be more powerful generally. Nevertheless, the screens for privileged users might be expanded as well:

what we are proposing	what might be desirable
after a user logs in as a realtor or administrator, he or she is brought immediately to the offers/listings screen	after a user logs in as a realtor or administrator, he or she is left in the search window but the "advanced options" button appears
the functionality on the offers screen that is limited to administrators is greyed out if user has insufficient access	the functionality on the offers screen that is currently limited to administrators might be hidden if user is not an administrator
as it stands, the data kept for offers made is very simplistic: only value of offer is stored	add new fields (e.g. buyer name, address, telephone, email) and permit buyers to hold accounts with the company and make offers on distinct properties
it is impossible to define new search types within the system	add a scripting language (ha! dream on! not bloody likely!)




3.7 Things to Ponder

Overall, this system is designed to be used by computer novices rather than computer experts. As such, then, it might be somewhat cumbersome for experts to use. It is certainly not very flexible; for example, though searching on map regions is permitted, searching on (say) strings within addresses is not, and there is no way within the system to create a new search method.

Another consideration is that the system is geared more toward real estate buyers than real estate agents. As computer experts might be frustrated with the rigidity of the dialogue, estate professionals might feel constrained by the limited set of search criteria provided in the system. Nevertheless, we are hoping to make it as universally attractive as possible.

The hardware required to make this system useful is not inexpensive. Colour monitors, scanners, and laser printers are often very costly, maybe more than the computers themselves. If peripherals prices become a consideration, it might be advisable to replace colour graphics with monochrome graphics or even text. Without colour, the pictures displayed will be inferior. Without graphics at all, the system will still be useful as a searching database, but another method of searching on locations than the current system of clicking on portions of a map will have to be defined, and printouts will be so much less exciting.




3.8 Structure of Team

In order to co-ordinate a group of this size (12), a leader was selected and jobs were divided among the groups. The positions given to people are not permanent. Each group member is able to help other group members in their position. For example, for Secretary, several group members would work in this position, not just Mr. Jenkins.

	Leader - David Petriot	

	Chief Editor - Wendy Michaud

	Chief Writer - Coral Burns

	Design Group - Christopher Chan
		     - Coral Burns
		     - Mark Atkins
		     - Michael Lippold
		     - Patrick O
		     - Ray Hermano

	Requirement Group - Not determined at this time.

	Programming Group - Christopher Chan
			  - George Ross
			  - Ivan Lam
			  - Jim Jenkins
			  - Malvin Beer
			  - Mark Atkins

	Secretary - Jim Jenkins
	Web Masters - Patrick O
		    - Ray Hermano