System Design And Human Factors In Mobile Phone-Based System For Hypertension Patients

Background of Human-Computer Interaction

A system is made up of components that work as a unit to achieve a certain objective or goal while design is a representation of the any object in form of a drawing (Buede, D.M. & Miller, W.D. 2016,3). System design is associated with a plan of the real system that defines its components and modules to meet certain prerequisites that have been specified in advance by the user of the system (Buede, D.M. & Miller, W.D. 2016,3). There are some steps that are involved when designing a system including determining of system requirements, system design, implementation of the system, testing and system maintenance. Some of the factors that affect system design include the functionality of the system, high technology growth rate, the requirements of the user and availability of skilled designers. This paper will focus much on the human factors (Proctor, R.W. and Van Zandt, T. 2018). The aim of this paper is to evaluate the functioning of the mobile phone-based system that was developed to enhance the interaction between health professionals and hypertension patients.

Background of Human-Computer Interaction

 Most of the systems are controlled by human beings including the automatic systems. There is a challenge to separate computer related work and that of human beings during system planning and designing (Grudin, J. 2017). Initially, work was allocated to human beings and machines basing on the rate of production. Participation of people in carrying out some tasks was replaced gradually by machines as it required some technical know-how. For instance, there was invention of computer soft wares that were used to solve mathematical problems such as MATLAB and SPSS (Castro et al. 2018). Currently, there are many languages that have been developed to communicate with the computers by programmers such as java, C++, C and python (Alvin, C. 2017). These languages are used to build desktop applications that are more friends and easily used by computer users with a lot of comfort.     

Part One: Mobile Phone-Based System for Hypertension Patients and its users

Following an increase of the number in patients that were diagnosed with hypertension, it became necessary for the physicians to design a system that can provide an interface to interact with patients and people at large. Studies revealed that proper management of Blood Pressure(BP) can lead to a decrease of the number of people that were infected with kidney diseases (Hallberg et al. 2018). The aim of developing this system is to enhance the interaction between the patients and the physicians. Patients are advised how to take care and control themselves as a way of reducing the BP level using this system. Apart from the control of BP, the study also revealed that day-to-day activities of the patients can lead to the rise of BP level. The main users of this system are physicians and the patients. This system is patient-oriented.

Part One: Mobile Phone-Based System for Hypertension Patients and its users

This technology is adopted gradually by health professions. Adoption depends on the capability of the patients to comprehend the way this system is used. Messages and texts are sent to the patients using this system. The content of these messages includes motivations and encouragements. In addition, patients are also advised to follow physician’s prescriptions to the latter (Hallberg et al. 2018). This system is made up of three components and processes which include the mobile phone where the messages and texts are sent, a gadget for measuring BP level and the reports on the BP measurement.

Part Two: User Cases

The mobile phone-based system was introduced to enhance the interaction between health care professionals and hypertension patients. It provided patients with the chance of measuring their BP level using BP measurement gadgets and sharing the result and report to the physician using the mobile phone-based system (Hallberg et al. 2018). Subsequently, the physicians can comment on the report using the same system. Following these developments, the health professions can then motivate and advise their patients on the way of adjusting their BP level to normal such as daily exercise. Therefore, patients can develop positive attitude to hypertension hence reducing stress (Hallberg et al. 2018). Besides, more complications that are resulted from high BP level such as heart failure can also be managed.    

Part three: Evaluation Methodology

The Requirements of the System

Determining prerequisites that were used in developing the proposed system is the initial stage or the initial step of designing the system and can assist in evaluating the developed system. The evaluators can ascertain whether the proposed system has been developed basing on the prerequisites that were specified by its users. The purpose and the objectives of the systems are determined by the suggestions of the system users (Bahill, A.T. and Madni, A.M. 2017,376). These suggestions are referred to as the system specifications. There is an introduction of Requirements engineering (RE) that verify the prerequisites for the system to be developed (Dick, J., Hull, E. and Jackson, K. 2017,2). There are five stages that are involved in RE which includes requirement analysis, requirement specification, verification and validation, requirement elicitation, and management (Maheshwaran et al. 2017,742). Elicitation is the initial stage of RE that involves consulting consumers and management with an aim of getting to the root of the problem that needs to be solved by the system while analysis is associated with analyzing the prerequisites that were collected during elicitation stage (Maheshwaran et al. 2017,742).

Part Two: User Cases

On the other hand, specification requirement gives more information about the proposed system. Additionally, requirement validation and verification ascertain that the specifications provided can satisfy the demands of the consumers. Lastly, management requirement is used in maintenance of the system (Ouhbi et al. 2015, 120). Also, the modifications of the system can be done at this stage. Feasibility study is also one of the major activities that are carried out by RE. This study ascertains the fact that the proposed system can be developed in a specified period by the programmers. In addition, this study also concentrates in determining whether the company or an organization can be able to meet the cost of the proposed system. Economically, this study compares the cost of the proposed system to its objectives and performance to ascertain that     

the money used in developing the system is somehow reasonable (Dick, J., Hull, E. and Jackson, K. 2017,5)

There have been many researches that have been undertaken to study and comprehend these stages of RE over a decade. For instance, there is a model that has been suggested to be used in RE. There are 8 steps that must be followed with this model. The first step is the use of Joint Application Development (JAD) as a way of gathering system information about the stakeholders and the consumers of the products. JAD is made about of about 25 people (Yousuf, M. and Asger, M. 2015,11). All the processes that are required to develop the proposed system are taken care of by JAD. For instance, every member of JAD has different responsibilities ranging from system planning to the system maintenance. Then, the reliability of the prerequisites is enhanced by analyzing the collected data from JAD (Yousuf, M. and Asger, M. 2015,11).  The requirements are organized basing on their importance of developing the proposed system as well as the ejection of the unnecessary details from the collected data.

 Furthermore, the requirements are to be recorded in the relevant documents. Development of the prototypes is one of the major challenges that the programmers face when designing the systems (Tang, T. 2017). The duties and roles of the system are specified as the initial steps of developing prototypes. Then, prototypes are validated. The process of validating the prototype is very simple as it only requires the comparison of the specifications that were recorded and the functionality of the system by the customers. The system is validated only if it can satisfy the needs of the customers. The programmers will move to the stage of requirement management for system modifications in case the prototype is found defective by the consumers. Prerequisites are divided into three basing on the classification technique that was proposed to RE model (Maheshwaran et al. 2017,742). This technique focuses on the need to modify the system as requested by the consumers. These three classes include the static prerequisites, prerequisites that are likely to be modified and prerequisites that are unlikely to be modified.

Part three: Evaluation Methodology

Study Setting and the Participants

There were 20 participants that were selected to participate in the process of evaluating the system from a group of 50 participants (Hallberg et al. 2018). The study of this system took exactly 2 months. The following criteria was used to select the participants:

1. Capability of comprehending Sweden language.
2. An adult with not less than 30 years.

• Participants who have been diagnosed currently with hypertension.

            The participants were asked the following questions:

• Have you been following the physician’s prescription?
• How old are you?
• Have you been employed?
• Have you been practicing physical exercises daily?
• When is the last time that you consulted physician about BP level?
• What strategies have you been applying to avoid stress?
• How long have you been living with hypertension?

Afterwards, the following table was to be filled by a physician to summarize all the answers that were provided by the participants.

Method of Information Gathering

The first procedure of system evaluation is focused on getting the required information and the source of the problem to be solved regarding the developed system. The information was obtained through interviewing both the physicians and hypertension patients, although there are many ways in which this information can be collected from the relevant users such as facilitated sessions, using questionnaires, complains of the system users and requesting for suggestions of stakeholders and the consumers. To begin with the interviewing, some questions are prepared by the developer to be answered by the interviewee (Cox, K.A. 2016). The questions are asked orally. Creating a list of queries that the interviewee can be asked is one of major guidelines of conducting a successful interview. Therefore, developers can record important details from the interviewee that can act as the draft for making some corrections to the developed system.

 The information can also be gathered by using questionnaire, although it’s an informal method of collecting data. A questionnaire is like an interview method except the questions are not answered orally (Brace, I. 2018,2). Basically, a questionnaire consists of a series of questions that are written on a piece of paper. Users of the system can be required to fill the questions on paper and submit their views to the system designer. This method is very cheap compared to other methods of collecting data (Brace, I. 2018,2). Afterwards, questionnaires are analyzed by system designers. This can form a basis of system errors that needs to be corrected.

In addition, information can also be collected through Request for Proposals (RFPs). This method is commonly used by the suppliers. RFPs is simply a document that is sent to the supplier of the commodities from one of their customers inquiring about the availability of some commodities (Venter, M.L. 2016). However, the requested commodity may not be available. Also, customers can send some documents in form of suggestions rather than requests to the supplier. These requests can be compiled and form a basis of system errors that need to be corrected.  

Part Four: Evaluation of the System using the Grounded Theory

People have developed many theories that have been incorporated into the system evaluation processes. Such theories include the grounded theory. A theory is the description of any phenomenon basing on the proved ideas and facts. The ground theory is focused on how developers and programmers can design and develop a well-functioning system that meets the requirement of its users (Adolph, S., Hall, W. and Kruchten, P. 2011,490). It was invented by Barney Glaser and Anselm Strauss. This theory is concerned with how a theory can be produced basing on the data provided to the system by its users. The grounded theory results in substantive theory where by the actions of the users are studied in advance. The inventors of the theory named it “grounded” because any theory is developed with the data that is provided by the users repeatedly to produce the similar outcomes each time the data is tested basing on a specified algorithm (Adolph, S., Hall, W. and Kruchten, P. 2011,490). Over the years, many researchers have been using grounded theory to collect the data, and afterwards generate a substantive theory using the data collected.

 Ground theory explains the way people solve problems and how they behave under different circumstances and situations. It also focuses on how people understand how various activities are carried out. Also, this theory is applicable in discovering the new ideas and concepts regarding a certain activity and to the areas that were not studied early on. The application of ground theory to the system evaluation is very crucial as it enhances generation of theories from the collected data in contrary to what’s happening (Adolph, S., Hall, W. and Kruchten, P. 2011,491).

The Overview and the Version of the Grounded Theory

The initial stage of the ground theory is marked by the process of gathering information on a specific system by the evaluator. The data gathered is then arranged and classified into different classes basing on their similarities. The data in different classes are compared to the data of other classes of the same category that were collected early on. Following this development, the nature and characteristics of these classes are developed (Adolph, S., Hall, W. and Kruchten, P. 2011,493). Afterwards, the classes are examined to determine the core class among the classes. The core class is the class that has the most inconsistency data after comparing it with the previously collected data. The process is repeated till all the classes become saturated. Saturated classes are those classes that does not change even if another data is added onto them.  

 The substantive theory is then developed from saturated classes. Furthermore, the substantive theory is compared to other theories that have been defined in the field of literature. The researcher records his ideas and findings that has been generated throughout the whole process. However, there is a misconception of version of grounded theory that should be used by researchers. There are there theories bearing the same name “grounded theory”. The original theory was published by Glaser and Strauss in their book titled “The Discovery of Grounded Theory” (Adolph, S., Hall, W. and Kruchten, P. 2011,490).   Afterwards, another book titled “Basics of Qualitative Research” was published by Juliet and Strauss in 1990. In addition to these two books, Kathy Charmaz published the third book titled “Constructing Grounded Theory”. These three versions of grounded theory were related, although with little modifications. Among these three theories, the original theory is the most preferred and very reliable.  

Grounded Theory Analysis Model

This theory uses the model of Concept-Indicator. In this model, indicators are compared repeatedly to one another. Indicators are simply the actual words of the users or stakeholders that have been recorded in the relevant documents. The existing indicators are compared to the new indicators. The researcher develops some concepts basing on the comparison of the new and existing indicators. These concepts are used to explain how to overcome problems and challenges (Adolph, S., Hall, W. and Kruchten, P. 2011,494).   

The following table summarizes the report that was filled by physician after the study of the mobile-based system using the grounded theory.

Part Five: The Findings of the evaluation

It was revealed that the mobile phone-based system has played many roles in the field of medicine (Hallberg et al. 2018). First and foremost, patients were motivated and encouraged by physicians hence reducing stress by patients. Patients learnt much about the levels of BP such as high, low and normal. Also, they were also able to learn about the ways of controlling and managing hypertension such as better diet and exercising daily. In addition, patients developed a positive attitude to hypertension (Hallberg et al. 2018). For instance, previously before the introduction to the system, the patients perceived hypertension as a vital condition that could lead to death. Their interaction with physicians via this system changed their attitudes to hypertension completely.

Apart from encouraging patients, the system also made it possible for the patients to follow physician’s prescription to the latter. The physicians provided guidance during their interaction with patients which facilitated following of the prescription by patients. Besides, this system also enabled patients to understand the importance of visiting the hospitals for further checking and guidance (Hallberg et al. 2018). Previously, people were not willing to visit physicians for guidance. For instance, patients visited physicians for checking BP level. Therefore, the gap between health care professionals and the patients was reduced.

Challenges for Adopting the Mobile-Based System by Health Care

Professionals

 Inability of the system to achieve its purpose was one of the challenges that professionals encountered while incorporating it into their operation. This is evidenced by the complains that they received from the patients. Patients complained about the inability of understanding the content of the messages. The graphs that were used were very complicated for them to comprehend (Hallberg et al. 2018). Subsequently, they proposed for the re-structuring of the system to meet its objectives and goals. Physicians also proposed for the inclusion of the days of the week into the system to determine differences in BP level from time to time by patients easily.

In addition to the inability of achieving its purpose, the system also increased stress among the patients. This was argued that measuring of BP level from time to time could lead to more stress on the patient’s side. Besides, the patients and physicians complained about inadequate time of checking the BP reports on the computer (Hallberg et al. 2018). Following these developments on the use of this system, the physicians proposed that there should be an application like an alarm to be incorporated into the system so that they can be reminded in case there is a report from the patient that needs to be examined. Besides, elderly people were unable to use the system and understand the graphs. However, these challenges can be corrected by using defect management as discussed below.

The Importance of System Requirement Defect Management in Enhancing the Quality of the System and Solving the System Defects

To develop a system that can satisfy the needs of the relevant stakeholders and users is quite a challenging task. This requires experts or the programmers that are very skilled in the field of system designing and development (Ahmad, S. and Asmai, S.A. 2016). Also, the programmers must be good decision makers to make useful decisions on how the proposed system should be developed. Analysis of the prerequisites is the vital stage of system development because the errors arising from this stage can affect the other stages of system planning and development hence leading to the defection of the whole system. Programmers should be very keen at this stage to avoid developing and designing the system on the wrong purpose that it was not meant for (Ahmad, S. and Asmai, S.A. 2016). Following these developments, there was a need for the introduction of defect management team such as Requirement engineering (RE) that could ensure that the quality system is developed by the experts and programmers that is free from errors and can satisfy the demands of the customers and the relevant stakeholders.     

 In addition, RE also checks the functionality of the system to ascertain that the system can achieve the purpose that it was meant for. However, the system can still be defective despite all the efforts that have been put in place to develop a quality system (Pohl, K. 2016). This is because of collecting the prerequisites using the natural language that can lead to misinterpretation while recording the requirements to the relevant documents. Incompleteness and ambiguity are some of the problems that arises from this misinterpretation. Natural language is the most preferred language that is used by RE. Ambiguity problems occurs where there is more than one interpretation of the same requirement (Pohl, K. 2016). This problem tends to decrease as the programmer develops the system. Most of these problems are solved by system developers without involving the users of the system. In the process of solving these problems, the developer can misinterpret the prerequisites of the system thus leading to some errors in its functionality (Maheshwaran et al. 2017,742).

Furthermore, the system can run without errors, although not able to function correctly basing on the requirements that were provided by the users. However, using some other formal languages rather that natural language in documenting the requirements of the system can solve the problem of ambiguity. For instance, using Unified Modelling Language (UML) that uses both the words and drawings can solve such problems. Also, the use mathematical algorithms and notations can reduce ambiguity (Ahmad, S. and Asmai, S.A. 2016). Learning how to use these special languages like UML is the great challenge. Therefore, a combination of natural language and formal languages will be appropriate.

Conclusion

To conclude, human factors have played a vital role in designing of the systems as compared to other factors as evidenced throughout the paper. Besides, they have also been incorporated into various stages of system designing like determining of system requirements and testing of the system. For instance, human skills such as decision making, and creativity skills has influenced greatly how systems are designed. Apart from human skills, the theories that have been developed also plays a crucial role. For example, the grounded theory is used to evaluate developed systems basing on the data that is provided by the user of the system. Following these developments, modern system designers should consider human factors when designing systems. This can enable them to design a system that can meet user’s requirements as a result. Health care professionals should incorporate mobile phone-based system for interacting with hypertension patients.  

References

Alvin, C., 2017. Computer Programming for Beginners: Learn the Basics of Java, SQL, C, C++, C#, Python, HTML, CSS and Javascript.

Ahmad, S. and Asmai, S.A., 2016. Measuring software requirements quality following negotiation through empirical study. International Journal of Applied Engineering Research, 11(6), pp.4190-4196.

Adolph, S., Hall, W. and Kruchten, P., 2011. Using grounded theory to study the experience of software development. Empirical Software Engineering, 16(4), pp.487-513.

Bahill, A.T. and Madni, A.M., 2017. Discovering system requirements. In Tradeoff Decisions in System Design (pp. 373-457). Springer, Cham.

Brace, I., 2018. Questionnaire design: How to plan, structure and write survey material for effective market research. Kogan Page Publishers.

 Buede, D.M. and Miller, W.D., 2016. The engineering design of systems: models and methods. John Wiley & Sons.

Castro, M., De Pino, G., Bocaccio, H., Sanchez, S., Drucaroff, L., Costanzo, E., Wainsztein, A., Guinjoan, S.M. and Villarreal, M.F., 2018. F169. Brain Connectivity During Psychological Stress in Patients with Schizophrenia. Schizophrenia Bulletin, 44(Suppl 1), p. S286.

Cox, K.A., 2016. Conducting the Interview: What to Say. In Strategic Requirements Analysis (pp. 77-108). Routledge.

Dick, J., Hull, E. and Jackson, K., 2017. Requirements engineering. Springer.

Grudin, J., 2017. From tool to partner: The evolution of human-computer interaction. Synthesis Lectures on Human-Centered Interaction, 10(1), pp. i-183.

Hallberg, I., Ranerup, A., Bengtsson, U. and Kjellgren, K., 2018. Experiences, expectations and challenges of an interactive mobile phone-based system to support self-management of hypertension: patients’ and professionals’ perspectives. Patient preference and adherence, 12, p.467.

Kazim Ali, International Journal of Advanced Research in Computer Science, 8 (1), Jan-Feb 2017,15-23

Maheshwaran, P., Kumar, R., Rajeswari, S. and Mungara, J., 2017. A Review on Requirement Engineering in Rapid Application Development.

Ouhbi, S., Idri, A., Fernández-Alemán, J.L. and Toval, A., 2015. Requirements engineering education: a systematic mapping study. Requirements Engineering, 20(2), pp.119-138.

Pohl, K., 2016. Requirements engineering fundamentals: a study guide for the certified professional for requirements engineering exam-foundation level-IREB compliant. Rocky Nook, Inc.

Proctor, R.W. and Van Zandt, T., 2018. Human factors in simple and complex systems. CRC press.

Sadhankar, D. and Sasankar, A., 2018. Study of Factors Affecting Reliability in Software Development Process.

Seetharaman, A., Saucier, D. and Lamperillo, G., Sony Corp and Sony Pictures Entertainment Inc, 2014. Software design and development in a service-oriented environment. U.S. Patent 8,887,130.

Tang, T., 2017. Developing an OEE Prototype.

Venter, M.L., 2016. Request for Proposal (RFP).

Yousuf, M. and Asger, M., 2015. Comparison of various requirements elicitation techniques. International Journal of Computer Applications, 116(4).

Order an Essay Now & Get These Features For Free:

Turnitin Report

Formatting

Title Page

Citation

Outline

Place an Order