This document outlines requirements for an Android-based housing application. It includes: 1. The overall aim is to enable two-way authentication for property uploads, link buyers to lenders, and track legal documents between sellers and buyers. 2. Functional requirements include accessing the app on Android 4.0+, user accounts/authentication, and statistics on occupied/unoccupied rooms. 3. Non-functional requirements encompass data currency, reliability, recoverability, availability, and fault tolerance during high usage.

1. • Ropafadzo Nyikadzino H160018V
• Rutendo Dingembira H160235P
• Julia Mataga H160404E
• Cleophas Ngwenya H160252G
• Charity Chinopangara H160237W
• Michelle Marume H160222F
ANDROID BASED HOUSING APPLICATION
SYSTEM
Submitted in partial fulfilment of the HIT 200/400 presentations.

2. Overall aim &/objective
• Cater for two-way authentication when uploading a
housing property.
• Link buyers with mortgage financers (banks and
micro financers) to source funds for purchasing the
housing property.
• Track the movement of legal documents for acquiring
housing properties (offer letter, title deeds and
agreements of sale) from the seller to the buyer.
• Show statistics in percentage of occupied and non-
occupied rooms when queried.

3. Requirements specifications
(functional & non functional)
Functional requirements
• Accessing the system - The system is to be accessed through
a smartphone device running the Android Operating System,
version 4.0 and above. The application is supported on both
small hand-held devices and tablets.
• Security - There is great need to control access to the data
within the system. This includes controlling who may view and
alter data in the system and this can be achieved through the
use of user accounts with access privileges.

4. Requirements specifications
(functional & non functional)
Functional requirements
• Creating user accounts - Any user (seller or buyer) can create
an account for that they use on the application. The account
creation is a once off process and the user can access and
update their account details. The main parameters for the
account are the user’s email address and password which will
be used to identify the entity within the system.
• User validation - System should be able to verify the user on
sign up and prove authenticity through the email address and
the password.

5. Requirements specifications
(functional & non functional)
Non-functional requirements
• Data Currency - Data currency is a measure of how recent
data in the system is. The data being transacted in the system
should be recent and up to date so that the tenants and
buyers will not be lagging behind on what changes will be
taking place.
• Reliability - Reliability of the system comes from its ability to
process all requests correctly and completely without being
aborted in a single session for a user.
• Recoverability - The system should be able to restore
functions and data correctly in the event of a system failure.

6. Requirements specifications
(functional & non functional)
Non-functional requirements
• System Availability - Access to the system should be 24/7
over all mobile networks broadband. There shouldn’t be any
glitches and delays in accessing the system by the users.
• Fault Tolerance and performance - The system should
partially tolerate operation during a failure. There should be a
quick response time for queries and updates to the system
even when the system is being accessed by several users
concurrently

7. Process modeling

8. Risk analysis and mitigation
RISK MITIGATION
Significant change in user requirements:
This is when the user of the application
deviate from their requirements and if
these changes are not put into
consideration it will result in the gulf of
execution which is the gap between a
user’s expectations and what the system
can actually do.
JAD sessions would be held to discuss and
continuously update the proposed
changes which helps the researchers in
understanding more, the requirements of
the users before coming up with the final
product.
Application crash:
This occurs when the application stops
functioning as expected by the developer
possibly due to data overloading on the
system if many transactions are being
executed at once. The application will be
receiving more transactions than it can
process at a single instance.
• The application developer should have a number
of back-ups for both the documentation and the
software in development since losing data will
result in the product not to be delivered well on
time.
• Developer should also check the stability of the
environment they are working on such that if they
notice any change it will be quickly acted upon
before the changes distract progress.

9. Risk analysis and mitigation
RISK MITIGATION
End users may resist the system:
This is when the users oppose or deny the
system as a result of user requirements
not being met by the development team.
• The system should be developed with
the user-centered approach that is
with the user in mind
• The interface should be user friendly
and be accessed from any device the
user will be using.
Server overloading Backup data in multiple storage areas
(RAID, Cloud)

10. Risk analysis and mitigation
RISK MITIGATION
Unauthorized access
This is a very large threat since if an
unauthorized person gains access to the
application, they could sell properties
which do not belong to them.
• ABHAS will implement use of user
login credentials and password as well
as data encryption.
Application device compatibility Developers should cater for application
backward compatibility.

11. Testing methods used

12. Security – mechanisms e-g for
database protection or overall system

13. Further development

14. conclusions