• General information
• Educational opportunities
• Projects and activities
• Jobs and career information
• Publications
• Faculty and staff
• Alumni Connection
• Archives

CHAPTER III

THE METHODOLOGY

Introduction

This chapter describes the methodology, procedures, objectives, limitations and other considerations that were germane to the design of a model system and the conceptual framework. This discussion will begin with the main elements of the methodology, process, and framework that were used for the process of designing the system.

The Design Study Methodology

This investigation used a design study methodology. The goal of the study was to develop a model informatic system that can lead to improvements in the health status of individuals as well as a reduction of the economic burden on organizations and the society as a whole. The design of the health promoting informatic system is intended to be used as a blueprint or framework for this study and as a resource for others such as practitioners and developers who could benefit from the groundbreaking efforts of this research project. The design contains all of the elements and components as well as a definition of the working relationships of the modules of this model system. The research objectives of this design study focused on the process of designing a model system rather than testing hypothesis or evaluating one that was fully operational.

A mixed-methodology approach that allowed for the incorporation of theories, concepts, and principles from multiple domains was deemed to be the most appropriate methodology for this type of design study (Greene et al,, 1997; Friedman et al., 1997). The mixed-methodology study design features inclusive and flexible methods of data collection from multiple data sources such as historical research and trends analysis, interviews with experts from key disciplines, focus groups with potential users and stakeholders of the system, and field testing exemplary systems.

Three distinct yet overlapping elements of the methodology were used to accomplish the objectives of the study. The three fundamental elements of the design study triad were:

• The mixed-methodology design study methodology,
• The Systems Development Life Cycle (SDLC) design process, and
• The Volere Requirements Specification Model framework for the development of the design.

Each of the three elements featured a mixed-methodology approach. Details about the elements are provided in the sections that follow.

The Design Process

The design process followed the seven-phase SDLC model (Kendall et al., 1999). However, since this was a design study the testing and maintenance and the implementation and evaluation phases of the SDLC model were eliminated because they were deemed to be beyond the scope of this study. Although the SDLC model is often represented as a linear step-by-step process, this study followed the dynamic iterative or cyclical process that is more commonly used for projects that develop complex and dynamic systems (Hocking, 1998). The first five phases of the SDLC that were used in this study are:

• Identifying the problems, opportunities, and objectives,
• Determining the information system requirements,
• Analyzing the system needs,
• Designing the recommended system, and
• Documenting the system development and design processes.

Although the evaluation phase of the SDLC process was eliminated from this study, the foundation for an evaluation process of the system has been set and was embedded in each of the first five steps of the process. The specific goals and objectives of the system, performance criteria, system metrics, and fit criteria evaluation are examples of the fundamental building blocks that could be used to evaluate the performance of the system when it is fully developed and deployed. Moreover, specific outcome measures for the health-related behaviors of the users of the system have been mentioned throughout this document.

The Framework for the Design Development Process

The Volere Requirements Process Model that was discussed in Chapter II served as the core of the system design development process (Robertson et al., 1999). The two key elements of the requirements process model for this study were the 27-step Volere Requirements Specification Template and the 13-part Volere Shell Framework. These elements were used for defining and performing tasks related to identifying and specifying the requirements and interrelationships among the components for the proposed model system. The four main clusters of the requirements template are the product constraints, functional and non-functional requirements, and product issues. The 13 parts of the requirement shell are described in the following sections and in the supporting documentation for Chapter IV.

Procedures

The successful completion of this investigation was dependent on the fulfillment of a series of critical tasks from the mixed-methodology study design, the SDLC model, and the Volere Requirements Process Model. The specific tasks from the three elements of the design triad that were used to arrive at the conceptual framework and the model system design are described in this section. Tasks from each of the elements were interwoven into the appropriate phases and steps of the basic SDLC model. Although the tasks are numbered and arranged sequentially, many of the tasks in the process overlap and occurred concurrently because of the iterative nature of the design process. The procedures are presented in and follow the SDLC model format.

SDLC Step #1 - Identifying the Problems, Opportunities, and Objectives

The first phase of the SDLC design process called for an identification and clarification of the problems, opportunities, and objectives. The initial steps for defining the scope and direction of the study were established though this step. The data in this section correspond to and partially fulfill the first four research objectives.

The Problem

The problem was defined through a mixed-methodology data gathering process and during steps one through three of the Volere Requirements Specification Template. The data were collected, framed in the context of this study, and then synthesized into a clear statement of the outcome and the process problems.

A comprehensive review of the literature from all of the appropriate fields, interviews with experts in the field of health promotion and information technology, product testing of exemplary systems, and focus groups were among the methods that were used to define the problem through the mixed-methodology approach. The data about the problem were collected and studied in detail by the researcher and small working groups who were familiar with key aspects of the study. The detailed statement of the problem is located in Chapter IV.

Cross-validation of the definition of the problem was achieved by working through steps one through three of the Volere Requirements Specification Template. The magnitude and characteristics of the problem were framed so that they included the importance and perspectives of multiple stakeholders, agents, or actors who were discussed in Chapter I and deemed to be the primary beneficiaries and audience of this study.

The Opportunities

A host of potential benefits and opportunities that have been associated with the components, systems, and technologies that can be used to address the health problems in the United States were mentioned in Chapter I and II. That set of opportunity data was added to through the various sources that were used in the mixed-methodology data collection process.

All of the opportunity data were analyzed to help to define the positive and negative aspects of those opportunities for the multiple stakeholder groups that were identified in step #2 of the Volere Requirements Specification Process. The data were examined for the potential for leveraging the technologies and for possible synergistic effects. The opportunity data were synthesized and it has been presented in Chapter IV. In the later stages of the design process, the opportunity data were used for evaluating and making decisions about the possible alternatives to the proposed system design and the conceptual framework that is featured in this study.

The Objectives

The third part of the SDLC process for this step focused on developing and defining the objectives for the system. The objectives evolved from the overall mission and goals of the system as well as the considerations that are related to the various stakeholder groups. During each phase of the design process, the interrelated objectives were used as a basis for making decisions about which options, elements, and features to include in the proposed system.

SDLC Step #2 - Determining the Information System Requirements

The second phase of the design process was devoted to identifying and defining the requirements for an effective system. The analysis from this step was used to help establish and clarify the relationship between the problem and the needs of users and various stakeholder groups. The data were collected, categorized, and used to define the type and scope of system that would be necessary to address the problems and to fulfill the third and fourth research objectives.

Data Gathering

Two data-gathering methods were used to identify the requirements data. The primary data-gathering method was the Volere Requirements Specification Template along with the Requirements Shell. It was supplemented with mixed-methodology information-gathering techniques such as the review of the literature, product testing and reviews, scenario development, and interviews with experts and others that are knowledgeable in the field. A generic scenario that would fulfill the objectives of the system was developed to provide a framework for the requirement definition process (SDLC #2 in the Appendices or Appendices as a pdf file).

The purpose of the 27-step Volere Requirements Specification Template and the 13-part Requirements Shell was to help formulate a clear "big picture" of all aspects of a model system as well as the unique perspectives of each of the various constituency groups. The system requirements were translated into the technical specifications and functional needs for the system during the third stage of the SDLC process.

The five system requirement types from the 27-step Volere template are the product drivers, constraints, functional requirements, non-functional requirements, and project issues. The number and type, event/use case number, description, rationale, source, fit criterion, customer satisfaction and dissatisfaction, conflicts dependencies, supporting materials, and history are the 13 parts of the Volere Shell Framework.

Data Synthesis

The data were synthesized during the process of progressing through the Volere Requirements Template and the Shell Framework. The synthesized requirements were described in the narratives and represented in graphical illustrations in "object-oriented" terms. The system requirements are contained in Chapter IV and the supporting documentation in the Appendices Appendices or Appendices - as a pdf file or SDLC #2 and (Studach, 2000).

SDLC Step #3 - Analyzing the System Needs

Two major tasks were required to complete phase three of the SDLC process. The first task called for translating the problem requirements for the proposed system into a set of technical needs and functional specifications that were needed to address the problems as stated in SDLC step 1. The second task required a decision-making process about whether the proposed system or one of several alternative systems would be better suited for meeting the requirements as stated in SDLC step 2. The data in this section correspond to and partially fulfill the third and fourth research objectives.

Technical and Functional Specifications

The raw and synthesized data from the Volere Requirements Specification Template and Shell and the mixed-methodology data gathering process were used to identify the technical needs and functional specifications for the proposed system. Targets for the functional, non-functional, and performance requirements for the system were established, and several important design parameters were identified by probing the data from the Volere template and shell. The technical needs and functional specifications for the system elements and data system were further refined through systems analysis techniques such as functional decomposition (Robertson et al., 1999; Magrab, 1997). The technical specifications and requirements of each of the system parts were defined and cross-referenced to check for compatibility and potential functional conflicts.

The design, technical, data, and core components and modules of the system were the four categories of technical needs and functional specifications that emerged from step #3 of the SDLC process. The specifications from these four categories were used to define the fundamental building blocks of the conceptual framework and the system design process in SDLC step #4. The list of key elements for each of the categories is included in Chapter IV.

The Decision-Making Process and Strategies

Part two of this phase of the SDLC process calls for a three-part operation; a comparison of the systems, a risk-strategy assessment analysis, and a decision-making process about the relative benefits of the proposed system compared to several systems alternative. In order to provide a structure for the comparison and decision-making process, a set of summary data and decision support tables that are based on the systems analysis work of Rob and Coronel and Kendall and Kendall were constructed (Kendall et al., 1999; Rob et al., 1997). The data Appendices or Appendicesas a pdf file Table 11) for the four system planning options for the three types of systems were summarized and presented in Chapter IV. The data in Table 11 are based on responses to four key questions that were posed by Rob and Coronel - should the existing system be (1) continued, (2) modified, or (3) replaced, and (4) is it feasible? (Rob et al., 1997 p. 322).

Three different types of systems were used for the systems comparison and risk assessment portion of the needs analysis. The systems were chosen because they reflect three major and distinct types information systems strategies for addressing the needs of users as outlined in Table 3 in Chapter I. Three highly rated commercial "health portals" (The Mayo Clinic, Healtheon/WebMd, and Yahoo), three award-winning theory-based research systems (OneLife from the American Heart Association, CHESS from the University of Wisconsin, Madison, and HealthMedia from the University of Michigan), and the proposed system were used for the comparison analysis. The researcher assigned scores for each of the systems on the basis of how well they fulfilled the eight fundamental system requirements as stated in SDLC step #2. The average and total scores for the three systems in each of the three classes were used for comparison and decision making purposes Appendices or Appendices as a pdf file) Tables 9 - 11).

The data from the comparison and planning process tables were used to complete the second and third part of the decision making process. The data were analyzed for the relative value and risk of the three options, and a decision about which system and which planning option should be adopted was proposed. The decision-making process and data about how and why the proposed should be developed in SDLC step #4 are described in greater detail in SDLC step #3 and in Chapter IV.

SDLC Step #4 - Designing the Recommended System

The intended outcome of this phase was a narrative description and schematic representations of the model system. The design of the model system was based on the data that were collected from the previous stages. The goal of this stage was to translate the analysis of the needs, requirements, and technical specifications into a model for a system and a conceptual framework that can address the problem in a highly effective way. The data in this section correspond to the fulfillment of the fourth research objective.

The Design Process

The SDLC and the Volere development process framework provided the structure for the design process. The data from the previous steps in the SDLC process and the Volere requirements specification process were used to define the fundamental building blocks, core components and concepts, and the interrelationships of the elements of the system. Comments and reactions from experts in the field who critiqued the model during the development stage were considered in the design process and incorporated into the process documentation.

The steps that were followed in the system design process were:

• Establish, as the foundation of the system, the mission and goals that are designed to address the problem as stated in SDLC step #1,
• Define the stakeholders and beneficiaries of the system as identified in SDLC step #1 and #2,
• Establish the scope of work and boundaries for the system as stipulated in SDLC step #2 and steps 1 - 6 of the Volere requirements template,
• Establish the flow of work for the system as outlined in steps 7 - 20 of the Volere requirements template,
• Through a mixed-methodology process, identify the most appropriate and state-of-the-art technologies and the best practices from the informatic and design domain that should be featured in the system design, and
• Develop the system design model according to the parameters that are stated in SDLC step #3.

Narrative descriptions with illustrations were used to portray the system model design that is presented in Chapter IV. Additional information for the system is included in the Appendices and the technical and process development documentation from SDLC step #5.

The Design Tools

Several graphical and modeling design software applications such as Visio, Visible Analyst, PhotoShop, and Dreamweaver were use to produce the system design, the user interfaces, and the illustrations of the system.

SDLC Step #5 - Documenting the System Development and Design Process

The documentation for the system development and design process is a rich repository of data on all aspects of the conceptual framework, the system design, and the decision-making processes. The three purposes of this stage are: to provide a historical record of all of the data and knowledge that were accumulated during the system design process, to provide technical documentation on the modules of the system and how they would work, and to provide the reader with an account of the criterion and process that were used for the decision-making processes. This step fulfills the fifth research objective.

The documentation is divided into two parts. A description of the technical, process, and decision documentation from SDLC step #5 is provided below.

Technical Documentation

A full set of documentation for all aspects of the SDLC steps 1 - 5, the Volere steps 1 - 20, and the data that were collected through the mixed-methodology process are part of the technical documentation. The documentation includes all of the historical data for the system design process as well as new data that accumulated since the initial pass thorough the system design process. The data and the other forms of documentation that are related to this study are located in the Appendices, in the accompanying documentation, and on the Website for this dissertation (http://www.american.edu/academic.depts/cas/health/nchf/pubmydissertation.html).

Decision Making and Process Documentation

The documentation of the decision-making process took two forms. The first set is related to the decision-making process from SDLC step #3 about which of the three types of system would be used for the final system design. That documentation is contained in SDLC step #3 in the Appendices and the supporting documentation (Studach, 2000).

Many process-related decisions were reached during the course of this study. The final design reflects the accumulation of the decision points that were made throughout the course of the design process. The documentation that is contained in the Appendices and the supporting materials is provided as a service for individuals who are interested in understanding the system in greater detail and to see when, where, how, and what decisions were made. Alternatively the reader could use the documentation to explore the implications of what would have happened if different decision were made.

Potential Problems

There were several potential problems and threats to this particular methodology and design process. First, this study used a mixed-methodology and a truncated design process. Although there is ample support for the validity and worth of this approach in the literature, deviations from and adjustments to the more well-established protocol and procedures have been known to compromise in the integrity of some studies.

Second, a significant portion of the design process is an "art." Therefore, each reader will have their own opinions about the outcome of the design and those opinions may differ substantially from the researcher.

Third, the potential for problems may be compounded by the fact that the study is being conducted by an individual novice researcher who is working in several very volatile and dynamic fields.

Fourth, the rather nebulous nature of this study and the technology field in particular makes it more difficult to bring clarity to the various aspects of the study. A lack of clarity at any stage may have serious implications for the later stages of the design process as well as any of the subsequent tasks that must be performed.

Fifth, many of the problems, concepts, and issues in this study were very complex. Moreover, many of them are interrelated and they have implications in many other areas and domains. Sifting through the data, bringing clarity to, and condensing the concepts and issues into manageable pieces proved to be a substantial undertaking.

Another problem was related to the various forms of potential investigator bias that could have occurred in this study. First, the bias may have influenced which set of exemplary systems will be selected for examination and comparison. Second, investigator bias in selecting the experts and focus and working groups who provided input and reactions to the various aspects of the conceptual framework and the system design may have had some impact on the final design. Third, the bias of the researcher may influence the perceptions and interpretations of what was said by experts in the field.

Seventh, designs of this scope and complexity are generally undertaken by a team of individuals who have subject matter and area of concentration expertise as well as experience. Therefore, no matter how diligent the researcher may have been, this novice researcher working alone on this project will have undoubtedly missed out on or chosen a less than ideal piece, solution, or option for the system at some time during this apprenticeship exercise.

Limitations

There were several limitations in this study. Many of them are related to the potential problems that were mentioned in the previous section.

There are two formidable limitations that are related to this methodology. The first limitation is related to the deviations from standardized methodology and the mixed-methodology design process that was used for this problem. The theoretical generalizability and applicability of the design may be limited because in this study the design was not actually implemented and subjected to a rigorous evaluation process.

The second limitation is related the scope of the problem and the technologies that were selected to be part of the design. The system was designed for an individualized population-management approach to lifestyle change. The target population for the system is all of the citizens of the United States. Conclusions about how this system might work in real life are limited because of there are so many intervening variables and isolating and controlling for all of them would be very difficult.

There are several other limitations that are worth mentioning. First, there is no way to say whether people would use the system even if it were available. Second, the system is based on a philosophical orientation of health promotion. It is difficult to say whether health promotion strategies would work if they were embodied in such a system. Third, this system is designed with multiple tailored modules. There is a distinct possibility that the algorithms for some of the modules would not work the same for all users and for each situation. Fourth, this study has been limited to primarily the products, problems, and systems from the United States. It is very possible that methodologies and products from other parts of the world would surpass the best solution for this study.

Ethical Considerations

There were no direct risks to individuals or groups because of this study. However, there are several very serious potential risks inherent in the design of such a system such as the security, confidentiality, and privacy of the information and data of the users of the system. Excessive governmental control and the threat of "big brother" are major concerns for some segments of the population.

There are three ethical considerations that are related to this study. First, the potential for direct or indirect harm to individuals who use such a system must be minimized and the users must be appropriately informed of any risk. Second, there is some degrees of risk associated with the fact specific individuals and products have been identified in this study. Third, ethical considerations are associated with the "intellectual property," proprietary products, and copyright issues for the products that have been examined for this study.

Summary

In summary, the methodological approach that was outlined in the previous sections was sound. The logic and rationale for the goals of this study are laudable. Moreover, here is sufficient support for this type of design and approach in the literature. The SDLC and the Volere model provided a sound framework that could be followed during the design phase and threats to the integrity of the methodology and process were identified and minimized.

Some other interesting points that were raised during the course of the study are worth highlighting. First, although the problems and tasks are large, a design study is one of the best ways to "blaze a new trail." Second, the researcher and novices in this field will learn a great deal from this system design process. Third, in the opinion of the researcher, this study will be a significant contribution to the field and for those who share an interest in developing the next generation of health-enhancing information systems. This study and the methodological approach will be extremely useful for others who are interested in working on the next generation of health-promoting systems.

Link to Chapter 4.

This page was designed by John Studach. Last updated on December 29, 2000

You can send e-mail to Me.

Return to the page with my dissertation page, or my papers.