Non-Functional and SDLC Requirements Report
Non-Functional
and SDLC
REQUIREMENTS
DOCUMENT
MY HEALTH RECORD PROJECT
Implementation Collaborative
On behalf of
The Commonwealth Government of Australia
May, 2017
Developed by:
<Name of Author(s)>
Charles Sturt University
2017 Session 1: ITC548 - System Analysis PG
Non-Functional and SDLC Requirements Report
FUNCTIONAL REQUIREMENTS DOCUMENT
TABLE OF CONTENTS
Page #
1.0 GENERAL INFORMATION.....................................................................................................1-1
1.1 Background............................................................................................................................1-1
1.2 Purpose...................................................................................................................................1-1
1.3 Scope.......................................................................................................................................1-1
1.4 Project References..................................................................................................................1-1
2.0 Current SYSTEM SUMMARY..................................................................................................2-2
3.0 NON-FUNCTIONAL REQUIREMENTS................................................................................3-2
3.1 Usability..................................................................................................................................3-3
3.1.1 User Interface Requirements...............................................................................................................3-3
3.2 Reliability...............................................................................................................................3-3
3.2.1 Critical System Qualities.....................................................................................................................3-3
3.3 Performance...........................................................................................................................3-3
3.3.1 System Interfaces.................................................................................................................................3-3
3.4 Security...................................................................................................................................3-4
3.4.1 System Constraints..............................................................................................................................3-4
4.0 Summary of Cloud Based Solutions..........................................................................................4-4
4.1 Strengths.................................................................................................................................4-4
4.2 Weaknesses.............................................................................................................................4-5
5.0 System development life cycle (sdlc)...........................................................................................5-5
5.1 Predictive SDLC....................................................................................................................5-5
5.1.1 Pros......................................................................................................................................................5-5
5.1.2 Cons.....................................................................................................................................................5-6
5.2 Adaptive SDLC......................................................................................................................5-6
5.2.1 Pros......................................................................................................................................................5-6
5.2.2 Cons.....................................................................................................................................................5-6
5.3 Recommended SDLC...............................................................................................................5-6
2017 Session 1: ITC548 - System Analysis PG
Non-Functional and SDLC Requirements Report
1.0GENERAL INFORMATION
1.1 Background
The Commonwealth Government of Australia is launching ‘My Health Record’ a secure online
summary of an individual’s health information.
Available to all Australians, My Health Record is an electronic summary of an individual’s key
health information, drawn from their existing records and is designed to be integrated into existing
local clinical systems.
The ‘My Health Record’ is driven by the need for the Health Industry to continue a process of
reform to drive efficiencies into the health care system, improve the quality of patient care, whilst
reducing several issues that were apparent from the lack of important information that is shared
about patients (e.g., reducing the rate of hospital admissions due to issues with prescribed
medications). This reform is critical to address the escalating costs of healthcare that become
unsustainable in the medium to long term.
Individuals will control what goes into their My Health Record, and who is allowed to access it.
An individual’s My Health Record allows them and their doctors, hospitals and other healthcare
providers to view and share the individual’s health information to provide the best possible care.
1.2 Purpose
The purpose of this non-functional and system development life cycle (SDLC) requirements
document is to provide documentation to consider various aspects of cloud based solutions such
as; data security, which includes data ownership (by Department of Health, the young person,
medical professionals, the Emergency Department etc.), as well as other relevant aspects of cloud
solutions, to implement and operate the Commonwealth Government ‘My Health Record’ project.
1.3 Scope
This Non-Functional and System Development Life Cycle (SDLC) Requirements Document will
outline the non-functional, critical system qualities, system interfaces, user interface requirements,
and system constraints requirements identified by The Commonwealth Government of Australia as
the proposed information system solution for the Commonwealth Government ‘My Health
Record’ project.
1.4 Project References
Key documents needed as supporting references to this document are listed below and must be
taken into consideration by prospective solution providers while responding to the details outlined
in this document:
A Guide to Implementing Cloud Services – Better Practice Guide, September 2012
2017 Session 1: ITC548 - System Analysis PG
Page 1 of 6
Non-Functional and SDLC Requirements Report
2.0CURRENT SYSTEM SUMMARY
The Commonwealth Government of Australia does not currently have a country-wide data
collection system. The project is considering cloud based solutions which should be investigated.
Funding has been approved and the following user case model has been developed for the
information system.
3.0NON-FUNCTIONAL REQUIREMENTS
This section specifies the qualities/non-behavioral requirements that can be used to judge the operation
of the system. The information provided serves to demonstrate breadth and depth of understanding and
provide insight and awareness of deeper more subtle aspects of cloud computing.
2017 Session 1: ITC548 - System Analysis PG
Page 2 of 6
Non-Functional and SDLC Requirements Report
3.1 Usability
Usability refers to the ease and learnability of an object. The project involves multiple users across the
country with different use cases dependent on their locations and specialties.
3.1.1 User Interface Requirements
The system will provide a consistent user interface to reduce training, customer support, and alteration
costs for customers. The system will provide the following requirements (Microsoft, 2017):
Support standard system size, color, font, and input settings
Provide clear directions to guide users through the system
Have connectivity to a databank of FAQs and search engine
Logic set to record data and require all necessary fields to be completed
Basic data logic warnings (i.e., Gender: Male with Pregnancy status: Y)
3.2 Reliability
Information needs to be able to and from the system at all times for doctors and patients. Data entry and
retrieval will be available to process at all time.
3.2.1 Critical System Qualities
The system will continue to operate and save data at all times, including but not limited to:
If a system component fails
Multiple people are on the system at once
System lags due to slow connection
One system resource is being over utilized
3.3 Performance
Performance of the system must be fast and smooth without interruptions for data and users. It is essential
that the system performs consistently and above reproach.
3.3.1 System Interfaces
Because the new Health Record project will interface with the existing health care system used in Australia,
the interface is highly sensitive and must be protected as such (Castiglioni & Crudele, 2014).
Manage user loads by horizontal scaling, system ordered commands at same instance
Leverage updated technology to promote compatibility in present and future settings and support
existing infrastructure
Hold service provider to an SLA, committing to no more than 2% downtime and a backup server
3.4 Security
Security is imperative for a business entrusted with private data and confidentiality. The system will
employ numerous data security techniques, including but not limited to:
Physical security
Network security
2017 Session 1: ITC548 - System Analysis PG
Page 3 of 6
Non-Functional and SDLC Requirements Report
Application security
Internal systems security
Third-party certifications
3.4.1 System Constraints
The system will require internal security techniques, including but not limited to:
Secure internal policies and procedures
Data backup system for disaster recovery
Hardened security to prevent hacking
Core commands to lock down data at the hint of intrusion
Least privilege based on roles and permissions
4.0SUMMARY OF CLOUD BASED SOLUTIONS
In April 2011, the Australian Government released a formal policy on cloud computing, so that
agencies could choose to use cloud computing services where they provide value for money and
adequate security, within the published Australian Government Cloud Computing Strategic
Direction Paper (the Strategic Direction Paper)(AGIM, 2012). Benefits such as scalability,
flexibility, availability and productivity make cloud-based services attractive for both businesses
and government services. While cloud-based computing provides many benefits, the service also
comes with complexities and risks (AGIM, 2012). Since the policy was released in 2011, cloud-
computing has become more secure and the options to ensure confidentiality, integrity, and
availability of information have improved with continuous updates and control creation.
In this section, the strengths and weaknesses of using a cloud-based system have been identified.
4.1 Strengths
Since gaining attention in 2010 and becoming a hot topic in 2011, cloud computing has come a
long way, but the strengths remain the same (Viswanathan, 2017):
Cloud computing is cost efficient in terms of maintenance and upgrade. Because the cloud
is externally managed and owned by a pay-as-you-go company, businesses no longer need
to pay out maintenance costs for software upgrades or licensing fees.
Cloud computing storage is limitless. Since the cloud is not maintained on a hard drive
system, businesses don’t have to worry about running out of storage space or needed to
increase storage by purchasing additional hardware.
Cloud computing offers customization and quick deployment. Through the ability to
customize the options for software integration and updates up front, time is never lost due
to waiting for patches and downloads to be incorporated by the business as it happens
automatically without additional time on maintenance spent by the business.
Cloud computing is accessible anywhere with a Wi-Fi connection. The cloud exists
through the internet, so information from cloud storage can be accessed by business
associates at any time.
2017 Session 1: ITC548 - System Analysis PG
Page 4 of 6
Non-Functional and SDLC Requirements Report
4.2 Weaknesses
Though a popular method for businesses to house their data to benefit from cloud computing
strengths, with the ease of use follows weaknesses (Viswanathan, 2017):
Cloud computing requires a strong internet connection to be logged into the cloud storage
server continuously.
Cloud computing is subject to outages and other technical issues on a frequent basis
though maintained and held to a high standard regarding connectivity through service
contracts.
Cloud computing adoption does mean that all business information will be in the hands of
a third-party (cloud service providers) and could be hacked and stolen at any point in time.
Even the best service provider isn’t 100% safe from data theft.
Cloud computing can open the business up to external hack intrusions and threats should
the hackers get through the service provider and hack into the business’ stream
connection.
5.0SYSTEM DEVELOPMENT LIFE CYCLE (SDLC)
There are only two types of system development life cycle approaches: predictive and adaptive. A
project’s success of development completion to expectation is dependent on the methodical tasks and
activities completed to ensure the final product meets requirements. A system development life cycle is the
process of building, testing, deploying, using, and updating an information system (Satzinger, Jackson, &
Burd, 2016).
5.1 Predictive SDLC
The predictive SDLC is an approach that assumes the project is basic, a cookie cutter, and can be planned
out ahead of time with the understanding that the new system can be developed according to the plan
without expected deviation. This approach is good for projects that are well understood and low risk. An
example of a predictive SDLC is a waterfall model (Satzinger, Jackson, & Burd, 2016).
5.1.1 Pros
The system will employ numerous data quality assurance techniques, including but not limited to:
Focus on one big project
Small wins after each phase is closed
Quicker turn around for delivery
5.1.2 Cons
Lack of flexibility
Cannot revisit a phase
No overlap of phases for turnover determination
No ability for resources to multitask and participate in more than one role
2017 Session 1: ITC548 - System Analysis PG
Page 5 of 6
Non-Functional and SDLC Requirements Report
5.2 Adaptive SDLC
The adaptive SDLC is an approach that assumes the project requires flexibility and needs to be watched
closely for possible changes to the plan. This approach is good for projects that are not understood very
well and are high risk due to unpredictability. An example of an adaptive SDLC is a spiral model
(Satzinger, Jackson, & Burd, 2016).
5.2.1 Pros
Breaks down phases into manageable mini-projects
Working prototype through each phase for testing and user evaluation
With smaller scope, able to concentrate and cause less rework upon change in circumstance
5.2.2 Cons
Time allotted for project is longer than predictive SDLC
Limited scope, only delivering project in increments
Repetition of combing back through each phase upon each phase’s completion
5.3 Recommended SDLC
Though it takes a longer time to complete, for this sensitive project, it would be best to use the adaptive
SDLC approach. This would allow complete focus on developing a sound information system and cause
fewer change requests to be required. Because a spiral model project cycles repeatedly through the
development activities, a working prototype is available as a preliminary model for testing and user
evaluation and becomes a more complete version with the new cycle (Satzinger, Jackson, & Burd, 2016).
My Health Project requires sensitivity, concentration, and a commitment to complete the project on time
and meet the requirements given by The Commonwealth Government of Australia.
2017 Session 1: ITC548 - System Analysis PG
Page 6 of 6
Non-Functional and SDLC Requirements Report
References
AGIMO. (2012). A Guide to Implementing Cloud Services: Better Practice Guide (Australia, Department
of Finance and Deregulation, Australian Government Information Management Office).
Chahal, P., & Saroha, V. (2016). Cloud Computing: A Survey Report. International Journal Of Recent
Research Aspects, 3(2), 139-142.
Guterman, Z. (2013, May 29). Next Step in Cloud Computing: Target the User. Retrieved May 24, 2017,
from [Link]
targets-the-user#axzz4i1UxB4qM
IOVAN, Ş., & IOVAN, A. A. (2016). CLOUD COMPUTING SECURITY. Fiability & Durability /
Fiabilitate Si Durabilitate, (1), 206-212.
Janco Associates. (2017). Cloud Computing Requirements and Best Practices: Best practices are defined
by top CIOs. Retrieved May 24, 2017, from [Link]
Johnson, D. W. (2010, November). Waterfall or Agile? Differences between predictive and adaptive
software methodologies. Retrieved May 24, 2017, from
[Link]
and-adaptive-software-methodologies
Kalaiselvi, R., Kousalya, K., Varshaa, R., & Suganya, M. (2016). Enhanced Secure Sharing of Personal
Health Records in Cloud Computing. Gazi University Journal Of Science, 29(3), 583-591.
Liang, S., CEO, & Ulander, P., CMO. (2010, December 21). 7 Requirements for Building Your Cloud
Infrastructure. Retrieved May 24, 2017, from [Link]
computing/[Link]
Microsoft. (2017). Chapter 3. User Interface Fundamentals. Retrieved May 25, 2017, from
[Link]
Satzinger, J. W., Jackson, R. B., & Burd, S. D. (2016). Systems analysis and design in a changing world
(6th ed.). Retrieved May 24, 2017, from
2017 Session 1: ITC548 - System Analysis PG
Page 7 of 6
Non-Functional and SDLC Requirements Report
[Link]
pdf
Viswanathan, P. (2017, February 01). What You Should Know Before Moving to the Cloud. Retrieved May
24, 2017, from [Link]
Ward, S. (2017, April 03). 5 Reasons the Cloud Might Not Be Good for Business. Retrieved May 24,
2017, from [Link]
2017 Session 1: ITC548 - System Analysis PG
Page 8 of 6