Upload
doanngoc
View
217
Download
0
Embed Size (px)
Citation preview
Mooroolbark Real Estate Agency
System Proposal
Published by Customer Relations Technology
Version Number 3.0
Last Revised
Prepared by Alexander Davies, Lisa Elkner, Li-
Sing Chung, Lee Trevena
1
1. Executive Summary
This report was commissioned to offer a proposal for a new system that will address the
identified issues faced by Mooroolbark Real Estate Agency’s current system. Based on what
Group 1 pty ltd learned from the compilation of the initial Business Requirements Document
(BRD), there has been a shift in focus from traditional structured approaches to an object-
oriented (OO) modelling approach.
Outlined in this report are the various methods of analysis including fact finding techniques
pertinent to this line of inquiry, such as:
Observation of the work environment, present system, and its users in action.
Examination of existing documentation, databases, and relevant literature.
internal vs external development considerations
Market trends and sustainability
Budget and time constraints
Feasibility
Modelling Techniques
In addition, a Joint Requirements Planning (JRP) approach was implemented in order to
accelerate the analysis process, by inviting all system stakeholders to a facilitated session for an
open system analysis.
The report found a rapid growth in cloud solutions were being adopted within the customer
relationship management (CRM) sector due to the benefits of pre-packaged solutions. These
include: cost-effectiveness, ongoing support, specialisation, training, scalability, real-time
delivery, upgrades, mobility, reduced building and deployment times. It found that these external
platforms would resolve the identified issue in the initial BRD and prove to be far more
economical in value than an exclusively internal development approach.
In order to, not only resolve the present problems but improve sustainability and
competitiveness, it is recommended, that the Mooroolbark Real Estate Agency adopts a Cloud-
based solutions that is capable of:
Real-time with drag-and-drop functionality giving property managers the capacity to
directly and securely share information.
Automation of industry standard reporting for auditing, accounting etc.
Interactive real-time reports that deliver key insight into the activity of users
Transferring sensitive information only through secure protocols
Centralizes and shares data for all stakeholders, according to access levels
Assists in the preparation of all pertinent documentation to free a portfolio of
underachieving assets.
TABLE OF CONTENTS
Tasks ...................................................................................... Error! Bookmark not defined.
Team Members .................................................................... Error! Bookmark not defined.
1. Executive Summary ............................................................................................................ 1 2. Table of Figures................................................................................................................... 1 3. Introduction ......................................................................................................................... 2
3.1. Purpose of Document ................................................................................................................ 2 3.2. Background ............................................................................................................................... 2 3.3. Object Oriented Approach ........................................................................................................ 2 3.4. Data Collection Process ............................................................................................................ 3
4. System Analysis ................................................................................................................... 3 4.1. Key System Functions .............................................................................................................. 3 4.2. System Automation Boundaries and Intended Users ................................................................ 3 4.3. User Interactions with the System............................................................................................. 3 4.4. System Objectives ..................................................................................................................... 3
4.4.1 Functional Requirement ........................................................................................................ 4 4.4.2 Non Functional Requirements .............................................................................................. 5
4.5. System Constraints .................................................................................................................... 6 4.5.1 Reliability and Availability Constraints ................................................................................ 6 4.5.2 Performance Constraints ....................................................................................................... 7 4.5.3 Development Constraints ...................................................................................................... 7 4.5.4 Legal constraints ................................................................................................................... 7
4.6. Analysis of potential issues from the systems development process ........................................ 8 4.6.1 Complexity ............................................................................................................................ 8 4.6.2 Stakeholder ........................................................................................................................... 8 4.6.3 System Theory ...................................................................................................................... 9 4.6.4 Sustainability ......................................................................................................................... 9
5. Project Management ......................................................................................................... 10 5.1. Project Feasibility ................................................................................................................... 10
5.1.1 Budget ................................................................................................................................. 10 5.1.2 Timeframe ........................................................................................................................... 10 5.1.3 Feasibility analysis .............................................................................................................. 10
5.1.3.1 Is the need significant enough to justify the proposed project? ...................... 11 5.1.3.2 Will the need still exist by the time if the project is complete?....................... 11 5.1.3.3 Are there alternative means of satisfying the need? ........................................ 11
5.1.3.4 What are the technical impacts of the need? ................................................... 11 5.1.3.5 What are the economic impacts of the need? .................................................. 11
5.1.3.6 What are the organizational impacts of the need? ........................................... 11 5.2. Overall assessment of feasibility ............................................................................................. 12 5.3. Required Resources................................................................................................................. 12 5.4. Time Schedule......................................................................................................................... 12
6. System Recommendation ................................................................................................. 12 6.1. Class Diagram ......................................................................................................................... 12 6.2. Use Case Diagram ................................................................................................................... 12 6.3. Sequence Diagram .................................................................................................................. 12 6.4. Activity Diagram..................................................................................................................... 12 6.5. State Chart Diagram ................................................................................................................ 12
7. Suggested Development Strategy..................................................................................... 12
1
7.1. Internal versus External Development .................................................................................... 12 7.2. Proposed Solution ................................................................................................................... 14
8. References .......................................................................................................................... 15 9. Appendix A ........................................................................................................................ 18
9.1. Work Breakdown Structure .................................................................................................... 18
Mooroolbark Systems Development .............................................................18 9.2. Gantt Chart .............................................................................................................................. 19 9.3. Combined Fishbone analysis and five why for root cause analysis ........................................ 21 9.4. Feasbility Analysis Matrix ...................................................................................................... 21 9.5. System Development Decision Matrix ................................................................................... 22 9.6. System Development Characteristics Matrix .......................................................................... 23 9.7. Class Diagram ......................................................................................................................... 24 9.8. Use Case Diagrams ................................................................................................................. 25 9.9. Sequence Diagrams ................................................................................................................. 31 9.10. Activity Diagrams ................................................................................................................... 34 9.11. State chart diagrams ................................................................................................................ 37
2. Table of Figures Figure 1 - fishbone diagram ................................................................................................................................. 21 Figure 2- Use case diagram property listing ......................................................................................................... 25 Figure 3 - Use case diagram property search ........................................................................................................ 26 Figure 4 - Use case diagram client detail .............................................................................................................. 27 Figure 5 - Use case diagram inspections ............................................................................................................... 28 Figure 6 - Use case diagram maintenance processing .......................................................................................... 29 Figure 7 - Use case diagram Rental payment........................................................................................................ 30 Figure 8 - Sequence diagram create new client .................................................................................................... 31 Figure 9 - Sequence diagram search properties .................................................................................................... 32 Figure 10 - Sequence diagram create new listing ................................................................................................. 33 Figure 11 - Activity diagram create new client ..................................................................................................... 34 Figure 12 - Activity diagram search property ....................................................................................................... 35 Figure 13 - Activity diagram create new listing .................................................................................................... 36 Figure 14. State chart new listing ......................................................................................................................... 37 Figure 15. State chart search property ................................................................................................................. 38 Figure 16. State chart create new client ............................................................................................................... 39 Table 1- Functional Requirements ......................................................................................................................... 5 Table 2 - Non Functional Requirements ................................................................................................................. 6 Table 3 - Reliability and Availability Constraints .................................................................................................... 6 Table 4 - Performance Constraints ......................................................................................................................... 7 Table 5 - Development Constraints ........................................................................................................................ 7 Table 6 - Advantages and Disadvantages of Internal and External Development ................................................. 13 Table 6 - Work breakdown structure (WBS) ......................................................................................................... 18 Table 7 - Feasibility Analysis Matrix ..................................................................................................................... 22 Table 8- System Development Decision Matrix .................................................................................................... 23 Table 9 - System Development Characteristics Matrix ......................................................................................... 23
2
3. Introduction
3.1. Purpose of Document
The purpose of this document is to provide a system proposal for the Mooroolbark Real Estate
Agency (Agency). Prior work was undertaken to evaluate the 'As-Is' state of the firm. This report
outlines and illustrates the functional and non-functional requirements of the firm in generating a
'future-state' system model.
3.2. Background
Group 1 Pty Ltd has been commissioned by the Agency to evaluate the firm’s current
information systems and processes and to provide recommendations for the development and
implementation of a new real estate management system. As a real estate agency, the firm deals
with a large number of individuals and third party organisations e.g. owners, tenants, contractors,
residential tenancy tribunal et cetera. As both a transactional facilitator, mediator and asset
administrator the Agency needs to continually store vast amounts of data and process it quickly
to generate useful information.
As the Agency has grown in size the demands on its current system have outpaced its ability to
meet its needs. Much time is spent on manual work arounds. This creates large inefficiencies and
distracts staff from their primary goal of customer engagement.
In phase 1 of the system recommendation Group 1 Pty Ltd used process and data modelling
techniques to map the current system, its stakeholders, data and processes (Davies et al. 2016,
pp.1-28). The object oriented data modelling techniques is used in this report through the
adoption of UML (unified modelling language) standards in order to develop a logical design of
the new Mooroolbark real estate management system.
3.3. Object Oriented Approach
Object oriented modelling is a natural fit with logical design production as it simplifies the
transition through to physical design. The primary benefits of designing a system using object
orientation are:
Visual depiction of actors and the elicitation of use case requirements making it easier for
business representatives to interpret and understand (Avison & Fitzgerald 2006);
Reduced cost through reusability of objects (Kendall & Kendal 2011);
Representation of real world objects i.e. data and methods are contained within a single
entity (Avison & Fitzgerald 2006);
Reusable design structure for physical design (Avison & Fitzgerald 2006); and
Easy to maintain the underlying code base: i.e. changes made to one object will have very
little impact on other objects (Kendall & Kendal 2011).
For these reasons the object oriented approach is used in the following report. The UML
diagrams that will be presented include: class, use case, sequence, activity and state diagrams.
3
3.4. Data Collection Process
Joint Requirements Planning (JRP) was undertaken in order to quickly gather crucial information
about the Agency’s current systems, issues, opportunities for improvement, requirements and
development prioritises. This process involved meeting with the current system owner (Agency
Manager), end users (staff) and the development team (Group 1 Pty Ltd).
Group 1 Pty Ltd also reviewed current policy and procedural documentation, as provided by the
Agency, in relation to its current processes. A walkthrough (observation) of current processes
was also undertaken by the development team.
4. System Analysis
4.1. Key System Functions
The proposed system is intended to deliver the following functions for key users:
Create, publish and notify clients (via a website interface) of a new property listing
Search for property listings
Store details of tenants, owners, and potential clients
Manage the inspection process, record inspection details, generate Property Inspection
Reports
Support maintenance requests, store and notify of maintenance details (inclusive of
costs), automating the generation of maintenance reports
Automate rental payment invoices, reminders, status updates and rental default and
tribunal notifications.
4.2. System Automation Boundaries and Intended Users
The system is intended for internal use by administrative, rental/sales and accounting/finance
staff. External users (i.e. tenants, owners and potential clients) will be able to interface with
subset of the data within the system via an external website (refer to Use Case diagrams). The
system is used primarily for the capture/automation of internal data flows and reporting,
processes such as physical property inspections, liaisons with maintainers for property
maintenance sit outside of the system. These automation boundaries are captured within the Use
Case whereby all processes sitting outside of the automation boundary are excluded from the
diagrams.
4.3. User Interactions with the System
Internal agency staff will store property listing, client, maintenance, inspection and rental
payment in the system. Administrative staff will primarily interact with the system to compile
and generate reports, add and update client records, update/retrieve information on rental
payment, default and tribunal statuses. Rental and sales staff will use the system to store, search
and update property listing information. Property owners, tenants and potential clients interact
with the system via an external website (refer to Use Cases).
4.4. System Objectives
Broad objectives of the system include improving reporting, data centralisation, accuracy and
integration and organisation performance through greater coordination between departments
4
which in turn will improve customer satisfaction and market position. These objectives will be
realised through the functional and non-function specifications as per the following sections and
as shown in the diagrams in Appendix A.
4.4.1 Functional Requirement
FID* Use case
description
Requirement
1 New listing The system shall:
Enable sales / rental staff to create a new property record
Enable sales / rental staff to send request for property
information request to owners via an external website
Enable upload and storage of property photos
Enable owners to review and approve listing information via
an external website
Publish approved property listing information to an external
website
Push notifications of relevant new listings to interested clients
via the external website
2 Search
properties
The system shall:
Enable sales / rental staff and external users (via an website
interface) to search for properties by property detail fields (e.g.
location, no. of rooms)
Generate a list of suitable properties filtered by search criteria
Capture property characteristics of interest to clients.
3 Store client
details
The system shall:
Store client information received from the external website
Enable staff to capture owner and tenant name, address,
contact and property details
4 Inspections The system shall:
Enable potential seller / owners to request for property
inspections via the external website
Enable rental and sales staff to book inspections and record
inspection details
Enable administrative staff to auto generate a Property
Inspection Report from recorded inspection details
Auto trigger a request for maintenance activities when a
5
maintenance requirement is flagged in the inspection details
Calculate bond returns for properties based on inspection
outcome
5 Maintenance The system shall:
Capture requests for maintenance via an external website
Store maintenance date and cost records in the system
Push maintenance date and cost information to tenants/owners
via the external website
Generate reports on maintenance costs for each property
6 Rental payment
(and rental
default)
The system shall:
Capture information on rental start date, rental due date, rental
rate and rental payment status in system;
Generate rental payment reminders for tenants (sent via
external website)
Store details of tribunal dates, involved parties and outcomes
Push notifications for properties with rental default status to
property owners via the external website
Send overdue payment reminders to tenants via the external
website
Table 1- Functional Requirements *Functional Requirement Identification Number
4.4.2 Non Functional Requirements
Non-functional requirements were previously identified in Phase 1 of the project and remain
unchanged (Davies et al. 2016, pp. 8-9) with exception of the budgetary constraint. These are as
stated below.
Requirement
Type
Requirements
Performance
Throughput: ~13kpbs
Response time: system response <=0.1 second
Queries must return in < 3 seconds
Error rate < 5%
Information Input, processing and output: see ERD for required data storage and
process models for input, processes and output.
Information currency: currency is dependent on timeliness of sources,
including the bank and processing speed of staff.
External system interface: the system must interface with the company’s
website and bank.
6
Economy Cost reduction: The system must reduce the $FTE (Full Time Employee)
by 25% through the reduction of manual work.
Budgetary limits: The system must be developed for <$60,000.
Development schedule: The timetable for the completion of the systems
development is 8 weeks post vendor confirmation.
Control Security: Access to the system and the underlying data will be governed by
roles and passwords. The hardware the system is reliant on must be stored
in a lockable room.
Privacy: The system must provide the ability to hide/mask personal or
sensitised information and restrict access to this information.
Data backup: The database must be backed up weekly and backups stored
in a lockbox in a cool, dry location.
Efficiency
Processes: The system should eliminate at least 15% of currently manual
work.
Sustainability: The system must reduce the environmental and waste
footprint of the firm by 10%.
Duplication: Data must not be duplicated in multiple locations unless
referential integrity is enforced.
Service Users: The system must be accessible by all employees of Mooroolbark.
Access must be available in office and remotely via the internet.
Reliability and availability: The system must be available 24 hours a day
7 days a week. Any system down time must occur outside of the hours of
8am-6pm Monday to Saturday.
Distribution of the system should be via a web application viewable
through a web browser so as to be over flexibility and portability.
Documentation: Detailed hand over documentation will include the
systems underlying code base, development docs, functional specs,
database diagrams, data dictionary and detailed user manuals.
Table 2 - Non Functional Requirements
4.5. System Constraints
As with any system there are technical and environmental system constraints that need to be
taken into consideration. The following presents the technical, performance and environmental
constraints of the proposed Mooroolbark system (Weisart 2009).
4.5.1 Reliability and Availability Constraints
Availability The system will be available 24 hours a day 7 days
a week.
Unscheduled availability for system maintenance
will be no more than 12 hours between the hours of
7pm and 7am AEST.
Detected Failure No more than one instance of data capture failure
resulting in less than 2 hours of rework biannually.
Table 3 - Reliability and Availability Constraints
7
4.5.2 Performance Constraints
Online Transaction Processing Maximum of 20 users simultaneously using the
system.
Data Volume Only current customers (owner, tenant) contact
information to be maintained; historical contact
information to be over written.
Transactional information to be maintained in the
operational system for 7 years, after this date data
will be cleansed but maintained in backup files.
Table 4 - Performance Constraints
4.5.3 Development Constraints
Database Management System
(DBMS)
The database for the system will run on the open
sourceMySQL DBMS. The MySQL DBMS is
compatible with multiple operating systems.
Data Migration Existing data relating to individual entities such as
owner and tenant details will be migrated into the new
system. Historical transactional data will not be
migrated due to large changes to the data structures.
Operating System The new system will be compatible with Microsoft
Windows Vista (circa 2007) and newer.
Network Deployment The system will be deployed on a local intranet. Data
can be access through web application queries but
direct access to the system requires the user to have
access to the Local Area Network.
Commercial Off the Shelf
(COTS) Product
As will be discussed at the end of this report, a decision
has been made to purchase a COTS product which will
be configured to meet Mooroolbark’s specific
requirements.
Table 5 - Development Constraints
4.5.4 Legal constraints
There are two major legal constraints that have a material impact on the new system
for Mooroolbark. These are:
The Privacy Act 1988 (Australian Government 1988): This legislation relates to the
acquisition, storage and distribution of personal information. As the Agency deals with a
large client base on which it collects a range of private and sensitive personal information
it is imperative that the handling of this information is compliant with the Privacy Act
1988 and that information is stored securely; and
The Residential Tenancies Act 1197 (Victorian Government 2010): This state based
legislation governs the nature of the relationship between a landlord and a tenant. It
covers such things as bonds, rents, other charges, general duties of tenants and landlords,
repairs and maintenance, rights of entry, et cetera. System rules must enable the Agency
8
and its participating entities to comply with the responsibilities outlined in this
legislation.
4.6. Analysis of potential issues from the systems development process
In creating a new Rental Property System, the Agency must consider how to identify and
mitigate potential issues/risks arising from system changes. Potential issues are discussed from
several different perspectives in the following sections.
4.6.1 Complexity
One potential issue for systems development arises from the complexity of the environment in
which the system exists. Modern systems need to be able to adapt to dynamic, rapidly changing
environments to ensure success. The complex nature of internal and external interactions makes
outcomes unpredictable (Burnes 2005, p.78); small, seemingly insignificant events can produce a
snowball effect (Benn & Bolton 2011, p. 281). Incorrectly defining one class carried through to
programmatic implementation could inhibit the ability of the system to meet basic end user
requirements and reduce or even eliminate proposed systems benefits. Further, attempts to codify
the complexity into a system are almost bound to fail. The automation of processes is a difficult
task in and of itself, when extreme complexity (represented through the scope of the business
requirements) is added, this task becomes even harder.
To negate the negative effects that system complexity can have, simplicity is proposed (Pirmin,
2013, p.67). Relatively short shelf life of information systems renders the effort of trying to
develop a ‘perfect system’ that meets all requirements irrational. An overarching goal of
simplicity helps resolve the common problem of conflicting requirements.
4.6.2 Stakeholder
Another potential issue is user adoption and conflicting stakeholder interests/concerns. A
perfectly design system is of little value if the system is not adopted and utilised by relevant
stakeholders. In encouraging system adoption, the development process needs to take into
account the interests and concerns of various stakeholder groups (Donaldson & Preston 1995,
p.67), appropriately identifying relevant change management and communication activities
required to bring stakeholders on the journey. Issues may also arise if the development of the
system is linked to negative impacts for key stakeholders. An example of this is the proposed
headcount reduction that can be realised from system/process efficiencies which may negatively
impact staff. Likewise, automating current processes and reporting requires a change in existing
processes, requiring the application of change management practices and provisioning of
relevant training to appropriately address the people impacts of the system changes.
There is also a need to consider the interests of external stakeholder groups (Donaldson &
Preston 1995, p. 69) such as tenants and owners who indirectly interface with the system via a
website as lack of adoption from that perspective will also impact on the success of the system.
Like stakeholders in the broader community also need to be considered. For example, proposed
system functionality includes storage of client tribunal details within the system. Government
bodies have interest in the storage and disposal of this information from a legislative perspective.
9
Legal issues can arise without due consideration of these elements within the Agency’s system
access settings, privacy policies and storage and retention policies and processes (Balzan, Lynch
& Blakey 2014, p.481).
4.6.3 System Theory
From the perspective of Systems Theory, successful technical systems development require
alignment with the Agency’s processes, structure and underlying business direction (Kadry 2014,
p.198). The technical system (i.e. the Rental Property System) is effectively embedded within a
broader organisational ecosystem, and inadequate consideration of how systems development
will impact on or interact with this broader ecosystem can result in issues during development
and implementation whereby the intended value of the system is not released or there are delays
in development/deployment. The proposed changes to the Agency’s systems require the
following to be in place for successful development and implementation:
Embedded process changes (shifting from paper-based interactions and processes to
digitised processes);
Cultural changes (whereby data storage, accuracy and timeliness is of increased
importance);
Changes in the way internal Agency staff interact with the system and with each other;
Changes in the focus of the work (reduction of manual activities enable Agency staff to
focus activities that increase business value); and
Relevant training and upskilling to interaction with the system, and potentially upskilling
to engage in value add activities (e.g. analytics of property rental/sales trends et cetera).
4.6.4 Sustainability
From a sustainability perspective, the Agency needs to consider the sustainability of the
proposed solution from both an internal perspective and a broader environmental perspective.
Quinn and Norton (2004, p. 6) note,
there is no easy sustainability blueprint applicable to all companies. Each must develop
its own vision, explore opportunities and potential changes within its own operations
and markets, and come up with its own action plan.
Internally, sustainability can be considered from several different perspectives inclusive of
(Baltzan, Lynch & Blakey 2014, p. 302):
Ongoing software maintenance requirements and costs;
Software flexibility and agility to adapt to strategic and/or environmental changes; and
Ongoing storage and infrastructure costs for increasing data storage and network
requirements.
Without sufficient consideration for these elements, issues can arise whereby the system no
longer achieves business goals and/or financial costs of maintaining the system exceed the
10
business value that can be realised from the system. These need to be considered upfront when
assessing the feasibility of different options to mitigate potential risks. Likewise, consideration
also needs to be given to how the system fundamentally changes the social dynamic between
staff members or staff and clients. Issues may arise if automation of processes/reports and system
generate automated communications decrease the quality of social interactions and consequently
the relationship between/with key stakeholders.
From a broader perspective, it is also important to consider issues that may arise from lack of
consideration for the environmental impact of deployed systems. These include considerations of
required consumption of natural resources to support the system and its associated processes
alongside environmental impacts of consumption and eventual disposal of required hardware and
infrastructure (Baltzan, Lynch & Blakey 2014, p. 314).
5. Project Management
5.1. Project Feasibility
In assessing this project’s feasibility, consideration was given to the budget, timeframe, project
need and project impacts on economic, technical and organizational factors.
5.1.1 Budget
The estimated budget for this project is $50 000.
5.1.2 Timeframe
The estimated timeframe for this project is under 4 months. See Appendix A, Table 6 – Work
Breakdown Structure and Appendix A, 9.2 – Gantt Chart for more detailed information on the
timeframe.
5.1.3 Feasibility analysis
Burke and Jarratt (2004, p.126) state that small and medium-sized enterprises do not
characteristically conducted extensive strategic analysis but, rather change is opportunistic or
instinctive and occurs through an ‘emergent planning process’. This Agency is small and root-
cause analysis (see Appendix A, Figure 1 Combined Fishbone Analysis) identified that, to date,
this Agency has not sufficiently planned for future business growth and need. To that end, as
Sewell (1994, p.23) noted, agencies need to be prepared to ‘meet and exceed the ever-changing
needs of their clients, [otherwise] they will not survive’. An opportunity exists for this Agency
to give greater consideration to its strategic objectives and to make real and necessary changes to
meet and exceed the needs of its clients.
There are a number of key questions that should be answered as part of need analysis. As
suggested by Bardiru (2011, pp.68-69), the following questions were used to assist in the need
analysis process:
Is the need significant enough to justify the proposed project?
Will the need still exist by the time if the project is complete?
Are there alternative means of satisfying the need?
What are the economic, technical and organizational impacts of the need?
11
A Feasibility Analysis Matrix which includes a summary of the technical, economic and
organisational impacts is contained in Appendix A, Table 8 – Feasibility Analysis Matrix.
5.1.3.1 Is the need significant enough to justify the proposed project?
Currently there are a number of manual processes within the Agency. This is causing a number
of problems including complaints from customers and duplication of effort. This is significant as
customer dissatisfaction impacts on the overall success and viability of the firm as a whole. That
is, without clients there is no Agency. Also, duplication of effort is costly and time consuming.
In some instances, staff are producing the same reports (manually) which is not an efficient or
effective use of their time.
Therefore, the need is significant enough to justify this project.
5.1.3.2 Will the need still exist by the time if the project is complete?
Yes. This need will continue to exist, and potentially get worse, if left as is.
5.1.3.3 Are there alternative means of satisfying the need?
Yes. The need to better market properties and enable clients to search for property information
can be improved by making changes to the current website. This will not address duplication of
effort or some of the issues identified by clients (in Figure 1 Fishbone analysis) such as untimely
reporting.
Although there are alternative means of satisfying the need, they will not address all needs and as
such, this project is still necessary.
5.1.3.4 What are the technical impacts of the need?
Technical feasibility considers whether current technology can be taken advantage of and also
factors in the technical capability of staff (Badiru 2011, p.67). As will be discussed in section 7,
a commercial off the shelf (COTS) product is the most feasible option for this Agency. This
Agency should take advantage of a COTS product as it standardizes business practices, can be
deployed quickly, are upgraded frequently and are simple to use (Beaubouef 2009, pp.216-18).
5.1.3.5 What are the economic impacts of the need?
Using a COTS product reduces project time and therefore cost to the Agency and will also bring
the Agency in line with its competitors. These are both positive economic factors for the Agency
and it is within the Agency’s long-term best interest to proceed with the project.
5.1.3.6 What are the organizational impacts of the need?
A recent study of job satisfaction in service industries found that the least satisfying aspects of
service jobs were the pay, job security and career prospects (Bednarska & Szczyt 2015, p.599).
Another study found that workplace enhancements significantly improved staff satisfaction and
retention (Mansell, Brough & Cole 2006, p.84). Given this is a small, owner operated business,
it is possible that staff are concerned about these factors, in particular job security and career
prospects. These are directly affected by the current state of the agency, which can simply be
described as outdated. Management has an opportunity to make improvements to business
process and to give further consideration to its future. If it does not, then job security, career
12
prospects, staff satisfaction and retention are likely to decline. This is clearly not in the
Agency’s, or its staff, best interest. For these reasons, the Agency should support this project.
5.2. Overall assessment of feasibility
It is clear from the project feasibility analysis that this project should be endorsed by the Agency.
There are a number of economic, technical and organization benefits that this proposed project
would bring, including increase profitability, modernization, sustainability and improved staff
and customer satisfaction.
5.3. Required Resources
See Appendix A, Table 6 – Work Breakdown Structure.
5.4. Time Schedule
See Appendix A, 9.2 -Gantt Chart. Project phases are reflective of Minkiewicz’s (2005, p.17)
best practice recommendations for successful implementation of COTS projects.
6. System Recommendation
6.1. Class Diagram
See Appendix A, Figure 2 – Class Diagram.
6.2. Use Case Diagram
See Appendix A, Figures 3 to 7 – Use Case Diagrams.
6.3. Sequence Diagram
See Appendix A, Figures 8 to 10 – Sequence Diagrams.
6.4. Activity Diagram
See Appendix A, Figures 11 to 13 – Activity Diagrams.
6.5. State Chart Diagram
See Appendix A, Figures 14 to 16– State Chart Diagrams.
7. Suggested Development Strategy
7.1. Internal versus External Development
System development relates to system construction and implementation, including building,
testing and installing a system. Some or all of these tasks can be internally or externally
developed. In order to determine which course of action is most appropriate for this Agency,
consideration was given to the Feasibility Analysis Matrix, System Development Decision
Matrix and System Development Characteristic Matrix, Appendices Tables 7 to 9 in Appendix
A.
13
The sections within the matrix that are shaded indicate the current position of the Agency. Based
on this assessment, the Agency’s best option is a packaged system. This is based on the business
need, timeframe, budget, skills and experience of current staff.
Using a packaged system means that the development of the system will be largely external.
There are both advantages and disadvantages to this approach and they have been compared to
internal development for context. These are outlined in Table 1 below.
Table 1: Advantages and Disadvantages of Internal and External Development
Internal Development External Development
Advantages
Customized to Agency’s exact needs
Lower up-front costs
Complete control over investment in
updates and enhancements
Unique solution that can be turned
into competitive advantage
Can be designed to support existing
systems
Disadvantages
Longer development times
Higher likelihood of faulty code and
thus costly downstream fixes
High costs to design, develop, test,
and deploy software
Lack of flexibility
Training/upskilling costs for staff to
develop software
Resource availability to support
required software maintenance (as
software support is not part of the core
role of staff)
Challenges supporting integration
with future systems
Advantages
Flexible / scalability
Tested and proven product
Lower development costs
Upgrades / enhancements through
vendor
Faster deployment
Minimal time impact on staff
members
Ongoing support
Training material provided
Ease of use
Increased reliability
Development against industry
standards
Better infrastructure and security
controls
Disadvantages
Additional unnecessary features or
potential for missing features
Potential higher upfront cost for
system purchase
Ongoing contract/licensing costs
Licensing options may not be suitable
for the Agency
Potential integration issues
Table 6 - Advantages and Disadvantages of Internal and External Development
(Avison & Fitzgerald 2006, p.130; Cincom 2008, p. 1; DeGiacomo 2013, p. 2; Li 2016; Mango n.d.).
The advantages of external development far outweigh the advantages of internal development. It
should be noted however, that the Agency needs to further develop its internal IT capabilities to
stay abreast of technological, organizational and economic factors to ensure that the Agency
remains competitive within the market.
14
7.2. Proposed Solution
In order to, not only resolve the present problems but improve sustainability and
competitiveness, it is recommended, that the Mooroolbark Real Estate Agency adopts a Cloud-
based COTS product that has the following features:
Real-time with drag-and-drop functionality giving property managers the capacity to
directly and securely share information.
Automation of industry standard reporting for auditing, accounting etc.
Interactive real-time reports that deliver key insight into the activity of users
Transferring sensitive information only through secure protocols
Centralizes and shares data for all stakeholders, according to access levels
Assists in the preparation of all pertinent documentation to free a portfolio of
underachieving assets.
8. References
Australian Government, Australian Privacy Act, Office of the Australian Information
Commissioner, viewed 20 February 2016, <https://www.oaic.gov.au/privacy-law/>.
Avison, D & Fitzgerald, G 2006, ‘External Development’, in Avison, D & Fitzgerald, G (eds),
Information systems development: methodologies, techniques and tools, McGraw Hill
Education, Berkshire, pp. 127-138.
Avison, D & Fitzgerald, G 2006, Information systems development: methodologies, techniques
& tools, 4thedn, McGraw-Hill, New York, pp.274-288.
Badiru, Adedeji B. 2011, Project Management: Systems, Principles, and Applications, e-book,
accessed 10 February 2016, <http://SWIN.eblib.com.au/patron/FullRecord.aspx?p=1686361>.
Baltzan, P & Lynch, K & Blakey, P 2014, Business Driven Information Systems, 2nd
edn,
McGraw-Hill, North Ryde, NSW.
Beaubouef, Grady Brett 2009, Maximize Your Investment 10 Key Strategies for Effective
Packaged Software Implementations: Accelerate Packaged (COTS) Software Implementations,
Increase Returns on Investment, and Reduce Implementation Costs and Customizations, e-book,
accessed 18 February 2016, <http://SWIN.eblib.com.au/patron/FullRecord.aspx?p=945570>.
Benn, S & Bolton, D 2011, Key concepts in corporate social responsibility, Sage, London.
Burke, G. I., & Jarratt, D. G. (2004). The influence of information and advice on competitive
strategy definition in small- and medium-sized enterprises. Qualitative Market Research, vol. 7,
no. 2, pp. 126-138. Retrieved from
<http://search.proquest.com.ezproxy.lib.swin.edu.au/docview/213350358?accountid=14205>.
Burnes, B 2005, 'Complexity theories and organizational change', International Journal of
Management Reviews, vol.7, no.2, pp.73-90.
Chiong, R 2016, ‘Lecture 3’, INF60003 Systems Development, Learning materials on
Blackboard, Swinburne University of Technology, 28 December, viewed 21 February 2016.
Cincom 2008, To Build or Buy? A Question of Application Development for Compliance and
Quality Systems, viewed 23 May 2015, < http://www.cincom.com/pdf/CM071218-1.pdf>.
Davies A, Chung, L, Trevena, L & Elkner, L 2016, Assignment 2: Project – Business
Requirements Document, pp. 1-36.
DeGiacomo, A 2013, Selecting Business Application Software: Build vs. Buy, viewed 23 May
2015, < http://www.kavi.com/wp-content/uploads/2014/11/BvbArticle-web.pdf>.
16
Dennis, A, Wixom, BH & Roth, RM 2012, Systems analysis and design, 5th edn, John Wiley &
Sons, Inc, United States of America.
Donaldson, T & Preston, LE, 1995, ‘The Stakeholder Theory of the Corporation: Concepts,
Evidence, and Implications’, The Academy of Management Review, vol. 20, no. 1, pp. 65-91.
Gelbard, R, Teeni, D, Sade, M 2010, ‘Object-Oriented Analysis: Is It Just Theory?’, IEEE
Software, Vol.27, no.1, pp.64-71.
Kadry, S 2014, ‘On the Evolution of Information Systems’, In F Miranda (ed), Systems Theory:
Perspectives, Applications and Developments, Nova Science Publishers, New York, pp.197-
208.
Kendall, KE & Kendal JE 2011, Systems analysis and design, 8th edn, Pearson Education,
pp.309-344.
Li, V 2016, ‘Lecture 4’, INF60003 Systems Development, Learning materials on Blackboard,
Swinburne University of Technology, 1 February, viewed 1 February 2016.
Mango, B n.d., To Build or To Buy: Comparing Custom and Off-The-Shelf Software
Applications, viewed 21 May 2015, <http://www.3csoftware.com/to-build-or-to-buy-
comparing-custom-and-off-the-shelf-software-applications/>.
Mansell, Angela, Brough, Paula, Cole, Kevin 2006, “Stable predictors of job satisfaction,
psychological strain, and employee retention: An evaluation of organizational change within
the New Zealand Customs Service”, International Journal of Stress Management, Vol. 13, no.1,
pp. 84-107, <http://dx.doi.org/10.1037/1072-5245.13.1.84>.
Marlena A. Bednarska , Malgorzata Szczyt , (2015) "Variations in job satisfaction in service
industries: comparative international analysis", Foresight, Vol. 17, no. 6, pp.599–615.
Minkiewicz, A E 2005, ‘Six Steps to a Successful COTS Implementation’, The Journal of
Defense Software Engineering, vol. 18, no. 8, pp. 17-21.
Pirmin, P 2013, Managing Complexity of Information Systems the Value of Simplicity, Wiley,
Hoboken, pp. 20-100.
Sewell, P 1994, A business success formula, Chartered Accountants Journal of New Zealand,
vol. 73, no.6, pp.23-24. Retrieved from
<http://search.proquest.com.ezproxy.lib.swin.edu.au/docview/209677815?accountid=14205>.
Victorian Government, Residential Tenancies Act 1997, Victorian Government, viewed 20
February 2016,
<http://www.legislation.vic.gov.au/domino/web_notes/ldms/pubstatbook.nsf/edfb620cf7503d1a
ca256da4001b08af/c7f3c6d8118d4bcaca256e5b00213c3d/$file/97-109a.pdf>.
Weisart, C 2009, Specifying Constraints, Information Disciplines Inc, viewed 20 February
9. Appendix A
9.1. Work Breakdown Structure
Task name Duration Start Finish Resource names
Mooroolbark Systems Development
360 days Mon 1/02/16 Fri 16/06/17
Plan Scope 3.5 days Mon 1/02/16 Thu 4/02/16 Project Manager, management
Analyse software requirements
18 days Thu 4/02/16 Mon 29/02/16 Group 1 consultants, management
Evaluate and Select COTS solution
27 days Tue 1/03/16 Wed 6/04/16 Project Manager, Analyst, Management
Negotiate vendor terms 6.5 days Fri 1/04/16 Mon 11/04/16 Software vendor, Analyst, Project Manager,
Management
Implement COTS solution 48 days Tue 12/04/16 Thu 16/06/16 Software vendor, Testers (including functional
testers from staff members),
Maintain and Upgrade software
263 days Thu 16/06/16 Mon 19/06/17 Software vendor
Maintain Licence & Subscription
262 days Thu 16/06/16 Fri 16/06/17 Management
Table 7 - Work breakdown structure (WBS)
9.3. Combined Fishbone analysis and five why for root cause analysis
Figure 1 - fishbone diagram
Sources: Davies et al. 2016, p.4.
9.4. Feasbility Analysis Matrix
Feasibility Criteria Weight External Development Internal Development
Technical
Technology. Availability of current
technology.
Expertise. Staff skills.
30%
Current COTS product is
mature, having been released
5 years ago. Vendor provides
technical support at minimal
cost and can assist with
testing. Training provided.
Limited technical skills to
support the development and
installation of this product.
Score: 95 Score: 60
Economic
30%
Approximately $50 000 Approximately $150 000
Cost to develop / purchase.
Score: 95 Score: 60
22
Organization
Staff retention and satisfaction if the
change is not implemented. 30%
Change management process
will need to be developed to
ensure staff buy-in.
Management to ensure
culture of the Agency
supports not only this change,
but ongoing change. If no
change is made, problems
will persist.
Same as external development.
Score: 50 Score: 50
Schedule 10% Less than 4 months. 12-18 months.
Score: 95 Score: 80
Ranking 100% 81.5 59
Table 8 - Feasibility Analysis Matrix Source: Tian & Chiong 2015, p.211.
9.5. System Development Decision Matrix
When to Use Custom Development
When to Use a Packaged System
When to use outsourcing
Business need
The need of the
business is
irreplaceable.
The need of the
business is common.
The need of the
business is not central
to the business.
In-house experience
Internal technical and
functional experience
exists.
Internal functional
experience exists.
Internal technical or
functional experience
is absent.
Project skills
Business wants to
develop internal
skills.
The skills are not
strategic.
The reason to
outsource is a tactical
decision.
Project management
There is an
experienced and
skilled project
manager with proven
methodology.
There is a project
manager able to
coordinate vendor’s
efforts.
Experienced and
skilled project
manager at the level
of the business that
bring into line the
scope of the
outsourcing
agreement.
23
Time frame There is flexibility
with timeframe.
There is a
tight timeframe.
A short or
flexible timeframe.
Table 9- System Development Decision Matrix
9.6. System Development Characteristics Matrix
Source: Tian & Chiong 2015, p.209.
Characteristic External Development Internal development
Proportion of system computerized
COTS package would be purchased and configured to suit the needs of the Agency.
Data capture in relation to properties and client and create of standardized forms for reporting.
Benefits Can be quickly implemented because it is a purchased product.
Designed to meet the precise specifications of the Agency.
Software tools needed MS Visual and MS Access to configure and integrate product.
Same as external development.
Application software Packaged solution. Custom solution.
Output devices Current business multifunction printer (1) is adequate.
Same as external development.
Input devices Keyboard and mouse. Same as external development.
Storage devices Server with 50GB storage. Same as external development.
Table 10 - System Development Characteristics Matrix
9.7. Class Diagram
**Please open the embedded PDF for a clearer scalable version
Adobe Acrobat
Document
TENANT
-tenantID: string
+getTenant()+setTenant(newTenant : string)
OWNER
- ownerID: string
+getOwner()+setOwner(newOwnerID: string)
EMPLOYEE
- Role: string- startDate: date-endDate:date
+getRole()+getstartDate()+getEndDate()
setRole(newRole:string)+setStartDate(newDate:date)+setEndDate(newDate:date)
PERSON
- Name: string- DOB: date- Gender: string- address: string- phoneNumber: string-BankAccountNum: double-BankAccountBSB: double
+ getDOB(): string {readonly}+ getPhoneNumber(): string+ getName() : string+ getAddressd(): string+ setName(newName: string) : void+ changeAddress(newAddress : string) : void+ changeBankAccountNum(newBankNum : double)+ newBankAccountBSB(newBankAccount : Double)
Department
- departmentName: string-departmentDescription: string
+getDepartmentName()+getDepartmentDescription()
+setDepartmentName(newName: string)+setDepartmentDescription(newDesc: string
<<belong>>
<<belong>>
<<belongs>>
PROPERTY
- address: string- photos: jpg-availability
+ getAddress(): string+updatePhoto(newPhoto:jpg)
InspectionReport
-DateofInspection: date- Condition: string
- CondionNotes: string -maintenance_required: boolean
+getDateofInspection()+getCondition()
+getConditionNotes()+getMaintenanceRequired
+setDateofInspection()+setCondition(newCondition : String)
+setConditionNotes(newConditionNotes : string)+setMaintenanceRequired(MaintResonse:boolea
n)
SALE
- dateOfsale: date- saleValue: double
- commissionPercent: decimal
+getdateOfSale()+getSaleValue()
+getCommissionPercent():+setsaleValue(newValue : double): +setDateofSale(newDate : date):
+setCommissionPercent(newPercent : decimal)
+calculateCommission(saleValue : double, commissionPercent: decimal)
RENT
- termOfLease: string-perMonthCost: double
-paymentFrequency: double-Availability: string
-Bond: double
+gettermofLease()+getperMonthCost()
+getPaymetFrequency()+getAvailability()
+getBond+changeTermOfLease(newLease : string)
+changeMonthCost(newCost : string)+changedPaymentFreq(newFreq:
double)+setAvailability(newAvailability: string)
+setBond(newBond:double)
Valuation
- propertyValuation: double
+getPropertyValue()+changePropertyValue(newAddress : string)
<<undertake>>
<<conduct>>
<<belong>>
<<belong>>
<<employees>>
<<own>>
<<rent>>
<<reside>>
Requirements
-houseType: string-bedroomNumber: int-bathroomNumber: int
-location: string-costUpper: double-costLower: double
+getHouseType()+getBedrooms()+getBathrooms()
+getLocation()+getCostUpper()+getCostLower()
+setHouseType(newType: string)+setBedrooms(NewNumBed: int)
+setBathrooms(NewNumBath: int)+setLocation(newLocation: string)
+setCostUpper(newCostUpper: double)+getCostLower(newCostLower: double)
Listing
-listDate: date-listValue: value
-listDescription: string
+ getlistDate()+ getlistValue()
+ setlistDate(newDate: date)+ setlistValue(newValue: value)
+seListDescription(newDesc:string)
<<advertised>>
Maintenance
-maintenanceRequestID: string-dateOfrequest: date
-statusOfRequest: string-scheduledDateofRepair: date
costOfrepair: double
+ getMaintenanceRequestID()+getdateofRequest()
+getStatusofRequest()+getscheduledDateofRepair()
+getcostOfRepair()+ setMaintenanceRequestID(newId: string)
+setdateofRequest(newDate: date)+setStatusofRequest(newStatus: string)
+setscheduledDateofRepair(newDateRepair: date)+calculatecostOfRepairn(newCost: double)
<<request>>
<<requests>>
0..1
1
1
1
0..*
1
0..*
0..1
1
0..*
1..*
1
1
1..*
1
0..1
TRIBUNAL
-initiatedBy:string-initiatedDate:date
-incidentDescription: string-attendanceDate: date
-courtRuling: string-remediationRequired: boolean
+getinitatedBy()+getinitiatedate()
+getincidentDescription()+getattendanceDate()
+getcourtRuling()+getRemediationRequired()
+setinitatedBy(newPerson: string)+setinitiatedate(newDate: date)
+setincidentDescription(nesDesc: string)+setattendanceDate(newdate: date)+setcourtRuling(newRuling: string)
+setRemediationRequired(newRemediation: boolean)
1
0..1
1
0..1
0..*
1
25
9.8. Use Case Diagrams
Sales Staff
Website
Create new listing
Check existing records
Request property information
Upload property photos
Publish property listing
Approve listing informationRental Staff
<<include>>
Review listing information
<<include>>
New listing notification
Check client requirements
<<include>>
<<include>>
<<extend>>
<<include>>
Notes: 1)It is assumed that owners, tenants and potential clients access relevant information and notifications via an external website. Access to relevant information is controlled for via login accounts on the website.
2) Use cases that occur outside the system are not captured within the diagram.
Figure 2- Use case diagram property listing
26
Sales Staff
Rental Staff
Website
Enter search details
Generate property listing
Check property availability
Register properties of interest
<<include>>
Save resigistered properties
Contact Agent
Notes: 1)It is assumed that owners, tenants and potential clients access relevant information and notifications via an external website. Access to relevant information is controlled for via login accounts on the website.
2) Use cases that occur outside the system are not captured within the diagram.
Figure 3 - Use case diagram property search
27
Sales Staff
Website
Create new record
Check existing records
Request client information
Rental StaffUpdate record
Admin Staff
<<include>>
Notes: 1)It is assumed that owners, tenants and potential clients access relevant information and notifications via an external website. Access to relevant information is controlled for via login accounts on the website.
2) Use cases that occur outside the system are not captured within the diagram.
Figure 4 - Use case diagram client detail
28
Rental Staff
Sales Staff
Website
Request inspection
Admin Staff
Book inspection time
Record inspection details
Upload property photos
Compile Property Inspection Report
<<include>>
Send Property Inspection Report
Calculate bond return<<extend>>
Create maintenance trigger
<<extend>>
Notes: 1)It is assumed that owners, tenants and potential clients access relevant information and notifications via an external website. Access to relevant information is controlled for via login accounts on the website.
2) Use cases that occur outside the system are not captured within the diagram.
Figure 5 - Use case diagram inspections
29
Request maintenance
Admin Staff
Create maintenance trigger
Create maintenance record
Calculate maintenance costs
Notify maintenance costs
Notify maintenance time
Generate maintenance report
Website
<<include>>
<<include>>
Maintenance Staff
<<include>>
Notes: 1)It is assumed that owners, tenants and potential clients access relevant information and notifications via an external website. Access to relevant information is controlled for via login accounts on the website.
2) Use cases that occur outside the system are not captured within the diagram.
Figure 6 - Use case diagram maintenance processing
30
Accounting / Finance Staff
Create rental payment schedule
Website
Check monthly rental payment status
<<include>>
Notify rental default status
<<extend>>
<<include>>
Send monthly payment reminder
Notify rental default action
Send monthly payment invoice
Send overdue payment notice
<<include>>
<<include>>
Record tribunal status
<<extend>>
Store payment record
Admin Staff
Notes: 1)It is assumed that owners, tenants and potential clients access relevant information and notifications via an external website. Access to relevant information is controlled for via login accounts on the website.
2) Use cases that occur outside the system are not captured within the diagram.
Figure 7 - Use case diagram Rental payment
31
9.9. Sequence Diagrams
Sequence Diagram –�create new client
Admin staff
:Owner
Get DOB
Set DOB
Set phone number
Get name
set name
get address
set address
receive change request
Check existing records
Get phone number
Make changes
Display updated record
Figure 8 - Sequence diagram create new client
32
Sequence Diagram –�search properties
Sales and
Rental staff
:Property
Get address
Display property details
:Listings
Get list description
Figure 9 - Sequence diagram search properties
33
Rental and Sales Staff
Get list description
:Property
Set list description
:Listing
Set list value
Get list date
Set list date
Check existing records
Upload property photos
Update listing
Display new listing
Get list value
Sequence Diagram –�create new listing
Figure 10 - Sequence diagram create new listing
34
9.10. Activity Diagrams
Start
End
Get name Get DOB Get address
Get phone number
Existing listing?
Display updated client
Update customerCreate new customer
NoYes
Check fields completed and data types correct
Data correct?
Reject customer detailsIncorrect data error
message
Yes
no
Activity Diagram –�create new client
Figure 11 - Activity diagram create new client
35
Enter search details
Property match?
Return property details
Yes Repeat for each property in properties
Valid address
Yes
Return �no property found
No
Return error message
End
No
Start
Activity Diagram –�search property
Figure 12 - Activity diagram search property
36
Enter search details
Property match?
Return property details
Yes Repeat for each property in properties
Valid address
Yes
Return �no property found
No
Return error message
End
No
Start
Activity Diagram –�create new listing
Figure 13 - Activity diagram create new listing