42
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

Mooroolbark Real Estate Agency System Proposal Real Estate Agency System Proposal ... Use Case Diagrams ... realised through the functional and non-function specifications as per the

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

17

2016, <http://www.idinews.com/life-cycle/constraint.html>.

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.2. Gantt Chart

20

Assignment 3 project

plan.mpp

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

37

9.11. State chart diagrams

Figure 14. State chart new listing

38

Figure 15. State chart search property

39

Figure 16. State chart create new client