1.
Elicit and Document Requirements
____________________________________________________________________________
________
1.1 Targeted users
The target users for this project are prospective HDB resale buyers, real estate analysts, and
other stakeholders interested in understanding HDB resale trends. The application’s primary
goal is to provide interactive data insights on HDB resale prices across Singapore.
● HDB buyers:
- Eligible buyers at least 21 years old and above applying under the family
schemes (Married couple, family)
- Eligible buyers at least 35 years old applying if he/she still single
● Real Estate Analyst/Agent:
- Understanding market dynamics and the trends of the HDB prices to provide
advice to their clients
- For studying housing affordability, evaluating policies, or preparing reports on
Singapore's property market.
● Stakeholders:
- The trends in the market can provide insights regarding their investment
strategies for private real estate investments.
____________________________________________________________________________
________
1.2 Flow of the project website interaction (SUBJECTED TO
CHANGES)
The user may query the visualizer system through clicking the website link.
The system must show a search bar and prompt the user to search for HDB property via a set
of criterias.
1. it will be the location of the HDB, either by town district or address. 2nd, room type and
3rd followed by price with a minimum and a maximum price range.
2. The room type of the HDB (3-room, 4-room, 5-room type)
3. The desired pricing of the HDB flat with a minimum and maximum price range
After the user enters, and clicks the search button, the website will filter and list the suitable
property that matches the criterias.
There will be a google map displayed side-to-side to the list. List of properties on the right side,
google map on the left side.
There are a few categories to measure the price trends.
1. Users may opt to compare prices between different types of HDB for eg: 3 room vs 4
room in that particular area.
2. Users may opt to compare prices between the same HDB types between 2 different
districts for eg: 4-room flats between Bishan and Tampines.
3. Users may opt to check the median prices of the HDB flats in that particular area.
To do this, there will be two buttons indicating ‘Price trend analysis’ and ‘Median price analysis’
on top of the property list. When the user clicked the first button, there will be two options in the
dropdown list:
1. Compare different HDB type prices in the same area. (Maximum up to 2 types)
2. Compare the same HDB types across several different areas. (Maximum up to 2 areas)
When the user clicks on the second button, the system will generate a chart showing the
median prices of the various HDB types in the selected area over 5 years.
An additional filter will present at the side of the screen to control the number of years for
comparisons. (for eg: 10 years instead of 5 years)
The system will show a line chart regarding the category the user chose in that area over 5
years. The line chart will be presented at the bottom of the list when the user scrolls down.
For interaction in Google maps, a user may choose a location, when a location is selected, a
circular vicinity of 500 metres is selected and the user may click the button ‘Search in this
location’. If clicked, the list of relevant HDB flats matched to the criterias will be shown (if any).
____________________________________________________________________________
________
1.3 Atomization of the flow
1. Users can perform queries in the visualizer system.
1.1. The system must show a search bar divided into 4 separate fields for users to
initiate a query.
1.1.1. The search fields are arranged in the following order: Location, room type,
minimum
price, maximum price.
1.1.1.1. The location field must be longest due to the varying lengths of
location names.
1.1.1.2. The room type field must be shortest, as the input is limited to
predefined categories (e.g., 3-room, 4-room, 5-room).
1.1.1.3. The minimum and maximum price fields must be of medium
length to accommodate both long values.
1.2. The location and room type fields must implement dropdown functionality.
1.2.1. A dropdown list must appear when users click on the location field.
1.2.1.1. The dropdown list must display all town districts or addresses
alphabetically from A - Z (e.g., Ang Mo Kio, Bishan, Canberra).
1.2.1.2. The dropdown list must support scrolling and searching for a
specific location using an integrated search bar.
1.2.1.3. Users must be restricted to selecting only one option from the
dropdown.
1.2.2. When users click on the room type field, a dropdown list must appear.
1.2.2.1. The dropdown list must include predefined room types (e.g., 3-
room, 4-room, 5-room).
1.2.2.2. Users must be restricted to selecting only one option from the
dropdown.
1.3. The search bar must allow seamless user input for all portions.
1.3.1. Placeholder text must guide users on the required input for each portion.
1.3.1.1. The placeholder for location must read “Select town district or
address.”
1.3.1.2. The placeholder for the room type must read “Select room type.”
1.3.1.3. The placeholder for the minimum price must read “Select min
price.”
1.3.1.4. The placeholder for the maximum price must read “Select max
price.”
1.3.1.4. An error message shall prompt the user to enter the missing
information if any portion is left empty after clicking 'Search' or pressing
'Enter'. The error message must be clearly visible, and may be inline next
to the empty portion.
1.3.1.5 An error message shall prompt the user to correctly fill the field if
price fields are filled with non-integer values after clicking 'Search' or
pressing 'Enter'. The error message must be clearly visible, and may be
inline next to the wrong portion.
1.3.1.6 An error message shall prompt the user to correctly fill the field if
the value in the minimum price field is higher than the value in the
maximum price field after clicking 'Search' or pressing 'Enter'. The error
message must be clearly visible, and may be inline next to the wrong
portion.
1.4. The system must process the query and return filtered results.
1.4.1. The search results must display a list of properties matching the criteria.
1.4.1.1 The list must be in alphabetical order.
1.4.2. The results must include the following details for each property in order:
1.4.2.1. The property location (e.g., address or district).
1.4.2.2. The room type of the property.
1.4.2.3. The price range of the property.
2. Search results must include a dual-display layout split equally in half.
2.1. The layout must display the following details:
2.1.1. The left side must display a map zoomed in to the location searched by the
user.
2.1.1.1 The map on the left side must be interactive, allowing users to
click, drag,
and zoom to explore the location.
2.1.1.2 There must be a toggle button hovering at the top titled “Show
price trends”.
2.1.2. A list of matching properties matching the criteria on the right side.
2.1.2.1 There must be 2 clickable buttons above the property list in the
order: Price
Trend Analysis, Median Price analysis.
3. The system must support price trend analysis.
3.1. Users may analyze price trends based on:
3.1.1. Comparing prices of different HDB types in the same area.
3.1.1.1. Users must click on the "Price Trend Analysis" button.
3.1.1.2. Users must select the option "Compare HDB Types" from a
dropdown.
3.1.1.3. The system must prompt users to select two HDB types (e.g., 3-
room, 4-room, 5-room) from a dropdown menu.
3.1.1.4. The system must display a line chart visualizing the price trends
of the selected HDB types in the area.
3.1.2. Comparing prices of the same HDB type in two different districts.
3.1.2.1. Users must click on the "Price Trend Analysis" button.
3.1.2.2. Users must select the option "Compare Districts" from the
dropdown.
3.1.2.3. The system must prompt users to select one HDB type (e.g., 4-
room) from a dropdown menu.
3.1.2.4. The system must provide two additional dropdowns for selecting
the two districts (e.g., Bishan, Tampines).
3.1.2.5. The system must display a line chart visualizing the price trends
for the selected HDB type in both districts.
3.1.3. Viewing the median prices of HDB flats in a selected area.
3.1.3.1. Users must click on the "Median Price Analysis" button.
3.1.3.2. The system must display a search bar beside the button after it is
clicked.
3.1.3.2.1. The search bar must be auto-filled with the location or
area entered by the users during their initial query.
3.1.3.2.2. Users must be able to change the auto-filled option to
another area or district using a dropdown menu.
3.1.3.3. The system must display a chart or table showing the median
prices of various HDB types in the selected area over the past 5 years.
3.1.3.4. The system must provide a filter to adjust the displayed time
range (e.g., 5
years or 10 years).
3.2. The system must display price trends in a line chart when the button on the left side
of page
(map) is toggled to “price trends”.
3.2.1. The chart must show the average price trends over 5 years by default.
3.2.2. Users may adjust the time range for comparisons (e.g., 10 years instead of
5 years).
3.2.3. The line chart must be presented below the property list and be scrollable.
3.2.4. Users must be able to hover over any point on the chart to view detailed
information.
3.2.4.1. The system must display the following data at the hover point:
3.2.4.1.1. The first data displayed must be the Date (e.g., year and
month).
3.2.4.1.2. The hover point must also display the Average Price,
HDB Type, and the District Name in that order.
3.2.5. The line chart must include legends for clarity:
3.2.5.1. The X-axis legend must represent Time Period (Year/Month).
3.2.5.2. The Y-axis legend must represent Average Price in SGD
(Singapore Dollars).
3.2.6. The text in the toggle button must change to “Location Map”.
4. The system must support interactive map features.
4.1. The map must use Google API for functionality.
4.1. Users may interact with the Google Map to select specific locations.
4.1.1. Upon selection, a circular vicinity of 500 meters must be highlighted and clickable
text pops up, stating “Search in this location”.
4.1.2. Users may click text to filter properties within the highlighted vicinity.
4.1.2.1. The list must update to show properties matching the criteria within the
selected vicinity.
4.1.3. The map and the property list must both be updated simultaneously when the
location is selected, allowing users to refine their search without losing context.
4.1.4. When the location selected has no identifiable property within 500m, text pops up,
stating “ No properties detected nearby. Please select a different location.”
4.1.5. When the user drags the map such that Singapore is not in frame, text pops up
stating “Map is outside usable range.”
4.1.5.1 Map automatically refreshes to previous selected location.
____________________________________________________________________________
________
1.4 Functional Requirements:
1.4.1 System Functionality to be Performed
1. Search and Filter Functionality:
○ FR1.1: The user must be able to filter resale price data based on town, flat type,
and date range through a search interface.
○ FR1.2: The system must display filtered results in a dual-panel layout, with the
map on one side and a list of matching properties on the other.
○ FR1.3: The system must support filtering of results in real-time as users interact
with the search bar, dropdowns, or map.
2. Price Trend Analysis:
○ FR2.1: The user must be able to analyze price trends based on different criteria
(e.g., HDB type, district).
○ FR2.2: The system must visualize price trends using interactive line charts,
enabling users to hover for detailed data such as price, HDB type, and district.
○ FR2.3: The system must allow the user to compare price trends for multiple HDB
types in the same district or compare the price trends of a specific HDB type
across different districts.
3. Historical Data Visualization:
○ FR3.1: The system must display historical resale prices in a graphical format,
such as line charts or bar charts, showing price fluctuations over time.
○ FR3.2: The system must enable users to adjust the time range for analysis (e.g.,
5 years, 10 years).
4. Interactive Map and Search Refinement:
○ FR4.1: The system must allow users to interact with an embedded map to refine
their search by selecting a location or vicinity.
○ FR4.2: Users must be able to click a "Search in this location" button after
selecting an area on the map, which will update the property list based on the
selected vicinity.
5. Exporting and Reporting:
○ FR5.1: The system must allow users to export data to CSV and Excel formats for
further analysis or reporting.
○ FR5.2: The system must allow users to generate and export customized reports
containing the filtered property data and price trend charts.
1.4.2 Information to be Processed
1. Resale Price Data:
○ FR6.1: The system must process historical resale price data to generate
graphical representations of price trends.
○ FR6.2: The system must store and process resale price data from external
sources, ensuring real-time accuracy and updates.
2. User Input Data:
○ FR7.1: The system must capture and process user input from the search bar,
dropdown menus, and map to filter and display the relevant property data.
○ FR7.2: The system must validate input to ensure that all required fields are filled
before processing the query.
3. Real-time Data Updates:
○ FR8.1: The system must continuously process and update data for resale prices,
location-based queries, and room types in real time as users interact with the
system.
1.4.3 Interface with Other Systems
1. External Data Fetching:
○ FR9.1: The system must integrate with external APIs to fetch up-to-date housing
resale price data, ensuring accurate and reliable data.
○ FR9.2: The system must allow seamless integration with third-party data sources
to enrich the data for resale price trends, town districts, or property details.
2. Data Export:
○ FR10.1: The system must allow users to export filtered property data and
visualized trend reports in CSV and Excel formats for offline use or further
analysis.
○ FR10.2: The system must ensure that exported reports maintain the integrity of
the visualized data, including charts and tables.
1.5 Non-Functional Requirements:
1. Performance:
○ NFR1.1: The system must process and return the search results within 5
seconds to ensure a responsive user experience.
○ NFR1.2: The system must handle up to 5,000 concurrent users without
performance degradation.
2. Usability:
○ NFR2.1: The user interface must be intuitive, with clear labels, placeholders, and
error messages to guide users through the search process.
○ NFR2.2: The system must allow users to easily filter, compare, and analyze data
without unnecessary complexity.
3. Accessibility:
○ NFR3.1: The search bar, dropdowns, and map must be fully accessible to users
with disabilities, adhering to WCAG 2.1 standards.
○ NFR3.2: All interactive elements (buttons, dropdowns, map) must be usable via
keyboard navigation.
4. Reliability:
○ NFR4.1: The system must maintain 99.9% uptime to ensure reliability in
providing search and trend analysis features.
○ NFR4.2: The data presented in the system must be updated regularly to reflect
the latest available property information.
5. Scalability:
○ NFR5.1: The system must be scalable to accommodate additional data sources
and support future growth in users and features.
○ NFR5.2: The system should be capable of integrating with other data sources for
enhanced property information and price trends.
6. Security:
○ NFR6.1: User data must be encrypted both in transit and at rest to ensure
privacy and data protection.
○ NFR6.2: The system must implement authentication and authorization
mechanisms to protect user data and system access.
7. Cross-Browser Compatibility:
○ NFR7.1: The system must be compatible with major web browsers (e.g.,
Chrome, Firefox, Safari, Edge) to ensure accessibility to all users.
8. Localization and Language:
○ NFR8.1: The system should support English and local language(s) for users in
the region (e.g., Mandarin, Malay).
1.6 Visualize and Refine Requirements with Use Case Models
The following use cases outline how users will interact with the system:
Use Case Diagram:
2.1 Use Case 1: User filters data
● Actor: User
● Precondition: A search query has been performed.
● Flow of Events:
○ User searches on the search bar
○ System allows the user to choose location.
○ System allows the user to choose room type.
○ System allows the user to choose price ranges.
○ User selects the parameters and confirms.
○ System directs user to the next webpage
● Exception: It must be within singapore only
2.2 Use Case 2: Analyze Price Trends
● Actor: User
● Precondition: A search query has been performed.
● Flow of Events:
○ User clicks on the "Price Trend Analysis" button.
○ System displays options for comparison: HDB types or districts.
○ User selects the type of comparison (e.g., Compare HDB Types).
○ System prompts users to select parameters (e.g., two HDB types).
○ User selects the parameters and confirms.
○ System displays a line chart visualizing the comparison.
● Post-condition: Price trend analysis is displayed.
2.3 Use Case 3: Interact with the Map
● Actor: User
● Precondition: Search results are displayed.
● Flow of Events:
○ User clicks on a location on the map.
○ System highlights a 500-meter vicinity around the location.
○ User clicks "Search in this location."
○ System updates the property list to display results within the highlighted vicinity.
● Post-condition: Refined search results are displayed.
Data Dictionary:
Terms Definition
Town A geographical area or region in Singapore
used to categorize and organize HDB (Housing
& Development Board) properties. Users can
select a specific town district when searching
for HDB resale properties. Examples of town
include Ang Mo Kio, Bishan, and Tampines.
District A more specific geographical subdivision
compared to town. For example: Pioneer is a
town in the Jurong West district
Time Range The period over which historical resale price
data is analyzed and displayed. In this case,it
is five years.
Resale Price The price at which an HDB flat is sold in the
secondary market (i.e., not directly from HDB
but from one owner to another).
Minimum Price The minimum price that each resale flat was
sold at within the year range selected by user
Maximum Price The maximum price that each resale flat was
sold at within the year range selected by user
Visualizer System A system that allows users to visualise the
price trends in HDB resale flat prices by
plotting a graph.
Price Trend Analysis A way to compare HDB resale prices to either
the HDBs in the same area or compare the
prices of same HDB types across several
different areas so that users can make better
informed decisions when buying their HDB.
Median Price Analysis A method of analyzing the resale price data by
calculating the median value, which represents
the midpoint of all prices in a selected area or
flat type. It provides insights into market
conditions while minimizing the impact of
outlier prices.
Flat Type The classification of an HDB flat based on its
size and layout (i.e. 3, 4, 5-room flats). Each
has a varying number of bedrooms, living area,
and floor space.
Historical Data Resale price records from past transactions.
The data is used to analyze price trends,
understand market dynamics, and provide
users with insights over a specified time range,
such as 5 or 10 years.
Comparison Data Data used to perform comparative analyses
between different flat types or districts. For
example, users may compare the price trends
of 4-room flats between two districts or analyze
differences between 3-room and 4-room flats in
the same district.
UI Mockups:
HDB type comparison in same area HDB prices in 2 different district
comparison
Login page: Sign up page:
Interactive Map UI: List UI
Homepage:
