Understanding Systems Engineering Concepts

This assignment delves into fundamental concepts of systems engineering. It emphasizes understanding actors – both human users and interacting systems – within a designed system's context. The focus extends to exploring constraints, limitations that influence system behavior. Use case diagrams are introduced as a valuable tool for visually representing these interactions and defining system boundaries.

Table of Contents
Introduction...........................................................................................................................2
Non-Functional Requirements...............................................................................................2
Usability..........................................................................................................................................2
Reliability........................................................................................................................................2
Performance....................................................................................................................................2
Supportability.................................................................................................................................3
System Interfaces...................................................................................................................3
System Constraints of My Health Record..............................................................................4
Review - Cloud Based Solutions.............................................................................................4
SDLC......................................................................................................................................5
Predictive SDLC.............................................................................................................................5
Adaptive SDLC...............................................................................................................................5
Recommendations & Conclusions...................................................................................................6
References.......................................................................................................................................6
1

Headspace – Proposed automated system
Introduction
With the advancement in time and technology, various transformations have taken place in the
field of healthcare. This field has not restrained itself from getting advanced by adopting changes
in technology and also remain innovative. In this report, an automated system is proposed to
designed for the organization – Headspace. The organization provides mental related services.
The proposed system is cloud-based and in this report, analysis of non-functional requirements
along with adaption of appropriate SDLC approach has been analyzed.
Non-Functional Requirements
The system requirements are of three types: functional, non-functional and user requirements.
Non-functional requirements are those requirements which pertain to system qualities like
reliability, supportability, usability and performance.
Usability
One of the key non-functional requirements is usability of the proposed system. The proposed
system should provide an interface which will allow end-users i.e. staff, doctors, patients and
other medical staff members to perform required tasks. Absence of any such non-functional
feature may lead to issues which may create bottlenecks by hampering user interface of the
system. Hence, it can be inferred that system usability should be maintained and include
functional aspects. The proposed system should adhere to the design principles and must only
provide simple local and global navigation (Lauesen & Younessi, 2016).
Reliability
The proposed system should be reliable i.e. all data provided by the system should be accurate
and correct. The organization cannot bear any loopholes in the system because the data is a
critical aspect of patients (Chung, 2016). There is a set of data in Healthspace system – patient’s
data, doctor’s inputs, etc. which is required to be sent in correct format and accurate to the
requesting users. Any incorrect information may have devastating results for the patients and
alos for medical staff.
2

Headspace – Proposed automated system
Performance
The proposed system should generate responses without much delay because automated system
is designed in such manner to be quick. There should not be any delays in data or request
processing. Healthspace requires to respond to patient’s queries very quickly as they may pertain
to emergency situations. Hence, in such cases, system performance has an important role in
generating timely alerts and notifications (Malan & Bredemeyer, 2010).
Supportability
Technical aspects of the systems are changing rapidly with time. There are new techniques
available in the market which are highly dynamic in nature. Same may happen with the proposed
system of healthspace. The involving infrastructure and internal system should support new
technologies and be open for any advance modification. Hence, the system should have key
elements of scalability and supportability on the system (Shaikh & Misbahuddin, 2016).
System Interfaces
User Interfaces of Healthspace
 HEALTHSPACE must provide a responsive interface for users to remain connected
 The application should neither have too jazzy or dull colours but a balance should be
created that gives a soothing feeling.
 The UI elements like text, buttons and labels must acknowledge user actions by changing
colours, highlighting sections or using shadows.
 Different users prefer different colours and thus, flexibility would be provided for
changing colour schemes (Fosse & Delp, 2016).
 All elements in application must have consistency in layouts and colours.
 The application has several screens including login, health report and summary. These
screens must not be loaded with navigation elements but have sufficient elements to
move from one screen to other easily.
 Consistency needs to be maintained in the text including font, size and colours.
 The application would provide the summary of medical reports uploaded by practitioners
and experts to the patients who would be able to download the summary as well as the
customized reports
3

Headspace – Proposed automated system
Device Interfaces of Healthspace
 Patients would be able to exchange emails with medical practitioners using Simple Mail
Transfer Protocol (SMTP)
 There would be many file transfers between different entities or users which would be
done through application using File Transfer Protocol (FTP)
 As all the application functions are dependent on the capabilities of the network, the
network connectivity is important which would be established through User Datagram
Protocol (UDP) and Transmission Control Protocol
(TCP).
 For supporting teleconferencing over application, various communication standards and
technologies would be used including Real Time Protocol (RTP), JPEG2, and MPEG4.
 Patients would use medical instruments to update health records and thus, both should be
compatible (Conde et al., 2010).
 Security protocols would ensure that information remains safe (Wheatcraft, 2010).
System Constraints of My Health Record
 HealthSpace app would have a front-end that would provide the end-users with an option
to interact with it.
 HealthSpace app would also have a backend that would be needed to store the bulk of the
data and these would be done with the help of NoSQL and MongoDB.
 HealthSpace app would be processed through different testing activities that would be
carried out and any bugs would be resolved and logged using Bugzilla. (Dettmer, 2016).
Review - Cloud Based Solutions
Cloud based solutions would have a major impact on HealthSpace app. This is because the app
would be deployed on cloud based platforms and would utilize several cloud based technologies
to get up and running. There are in total three types of cloud based delivery models. These
includes PaaS, SaaS and IaaS. PaaS stands for Platform as a service, SaaS stands for Software as
a service and Infrastructure as a service respectively. In the case of this app, PaaS would be the
ideal platform of choice. The app cannot be hosted on a SaaS model because the app itself is a
4

Headspace – Proposed automated system
service and it would either need an infrastructure and a platform. The reason to opt out of
Infrastructure as a service is because infrastructure as a service is a complex platform and it
would essentially involve hiring full-time experts and teams that would help get the
infrastructure up and running and it would result in high up-front costs as well. As a result, the
platform as a service is the perfect option for the app as all the base hardware and the entire
infrastructure in fact, is already setup, configured and secured at the same time. At the same
time, there are two types of cloud; private cloud and public cloud. The key difference between
the two is that private cloud remains entirely private and highly-secured and at the same time,
public cloud remains exposed on a public cloud solutions provider. Hence, the public cloud is
exposed with security issues and other vulnerabilities, therefore private cloud is the right way
forward.
SDLC
SDLC is a practice of software development methodology wherein a set of guides, principles,
techniques and methods are used for software development resulting in a robust and planned
software development with minimal bugs. There are several different sub-methods already
defined within SDLC, but majority of them can be classified into two: Predictive and Adaptive
methods.
Predictive SDLC
Predictive SDLS is an approach which the steps and phases are pre-defined for the software
project and they have no scope of alteration during the course of the project. All basis and
procedures are already fixed. At the same time, patterns and behaviours of the project are
predicted and estimated well in advance. In the case of HealthSpace app, the requirements are
already clearly specified. With Predictive SDLC approach, the top level management would have
all kinds of set processes to follow the guidelines for the project. However, a major drawback
associated with the project mentioned previously remains wherein the project would not be able
to handle any requirements inflations as the risk of the project may increase.
Adaptive SDLC
Adaptive SDLC on the other hand is exactly the opposite of predictive SDLC approach and is
also much suited for the HealthSpace app. In this approach certain ad-hoc processes are followed
5

Headspace – Proposed automated system
in order to execute the activities resulting in achieving of the objectives and goals laid out for the
app. There is no particular flow in this given approach and simultaneously the flow needs to be
designed as well as estimated based on the project’s scenarios as well as requirements. The major
strength of Adaptive SDLC is in dealing with the changing requirements of the project. So in the
case where the requirements of the project keeps on changing or even in scenarios wherein it’s
unknown whether the requirement of the project may remain still or may change in the lifecycle
of the project, the adaptive approach would be better suited.
Recommendations & Conclusions
Based on the two approaches specified earlier, it can be made clear that the choice of method
would be adaptive SDLC rather than the other one. This is because, HealthSpace app is a novel
initiative by the government of autralia and there is a high chance of requirements taking new
course in the future wherein it would not be a problem with Adaptive SDLC. Although, the
downside with Adaptive SDLC is its high cost, it would still not be a problem because the
initiative is backed by the commonwealth government of Australia thereby making it easier to
flex the budget if needed.
References
Bourne, L. (2016). Stakeholder Relationship Management. Retrieved 20 May 2017, from
http://www.mosaicprojects.com.au/PDF_Papers/P128b_Stakeholder_Relationship_Manage
ment.pdf
Chung, L. (2016). Non-Functional Requirements. Retrieved 20 May 2017, from
https://www.utdallas.edu/~chung/SYSM6309/NFR-18-4-on-1.pdf
Conde, J., De, S., Hall, R., Johansen, E., Meglan, D., & Peng, G. (2010). Telehealth Innovations
in Health Education and Training. Telemedicine And E-Health, 16(1), 103-106.
http://dx.doi.org/10.1089/tmj.2009.0152
Dettmer, H. (2016). Systems and Constraints: The Concept of Leverage. Retrieved 20 May 2017,
from http://goalsys.com/systemsthinking/documents/Part-6-SystemsandConstraints.pdf
Fakhroutdinov, K. (2016). UML actor is a role played by a human user of the designed system,
6

Headspace – Proposed automated system
some other system or hardware that interacts with the subject by using services of the
subject.. Uml-diagrams.org. Retrieved 20 May 2017, from
http://www.uml-diagrams.org/use-case-actor.html
Fosse, E. & Delp, C. (2016). Systems Engineering Interfaces: A Model Based Approach.
Retrieved 20 May 2017, from http://www.omgsysml.org/System_Engineering_Interfaces-
IEEE_2013.pdf
Lauesen, S. & Younessi, H. (2016). Six Styles for Usability Requirements. Retrieved 20 May
2017, from http://www.itu.dk/~slauesen/Papers/SixStyles.pdf
Malan, R. & Bredemeyer, D. (2010). Defining Non-Functional Requirements. Retrieved 20 May
2017, from http://www.bredemeyer.com/pdf_files/NonFunctReq.PDF
McAtee, M. (2016). A good compliance system takes the administrating out of managing.
Qualitydigest.com. Retrieved 20 May 2017, from
http://www.qualitydigest.com/nov01/html/paperless.html
Rhyous,. (2011). The 8 Types of Technical Documentation and Why Each Is Important. Rhyous.
Retrieved 20 May 2017, from https://www.rhyous.com/2011/07/21/the-different-types-of-
technical-documentation-for-software-and-why-each-is-important/
Shaikh, A. & Misbahuddin, M. (2016). A system design for a telemedicine health care system.
Retrieved 20 May 2017, from
https://gupea.ub.gu.se/bitstream/2077/10498/1/gupea_2077_10498_1.pdf
Walker, D. (2016). Influence, Stakeholder Mapping and Visualisation. Retrieved 20 May 2017,
from
https://mosaicprojects.com.au/PDF_Papers/P062_Influence_Stakeholder_Mapping_and_Vi
sualisation.pdf
Watt, A. (2016). 5. Stakeholder Management | Project Management. Opentextbc.ca. Retrieved
20 May 2017, from https://opentextbc.ca/projectmanagement/chapter/chapter-5-project-
stakeholders-project-management/
Wheatcraft, L. (2010). Everything you wanted to know about interfaces, but were afraid to ask.
Retrieved 20 May 2017, from
7

Headspace – Proposed automated system
http://spacese.spacegrant.org/uploads/images/UserContributedFiles/
WheatcraftInterfaces110909.pdf
Wick, S. (2016). User Stories and Use Cases - Don’t Use Both!. Batimes.com. Retrieved 20
May 2017, from https://www.batimes.com/articles/user-stories-and-use-cases-dont-use-
both.html
8