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

Note: this page corresponds to the SDLC analysis and it leads to the final product in the Appendices. The numbering sequence here follows the Volere analysis, however, the numbering pattern has changed in the final document.

This page is divded up into major two sections. The first section, In a nutshell, is a bulleted listing and summary of the major points for this step. A complete presentation of the data for this step is featured in the second section.

In a nutshell

The functional requirements of the system are the specifications about what the system needs to do in order to satisfy the uses of the system. The functional requirements for the system emerged from the first two steps of the system development process including outlining the problem, opportunities, mission and goals and the definition of the system requirements.

Several of the most important functional requirements for the system were established. The system must be able:

• To empower users by allowing them to control their relationship to the system, control access to and use of their data, and be afforded levels of privacy, security, and confidentiality that are consistent with their wishes;
• To promote health-enhancing lifestyles among users by providing proactive tailored content and services to the users;
• To promote linkages, efficient communication, and illicit feedback among users and the agents and entities of care who are part of the healthcare supply chain;
• To promote efficiency and streamlining through a fully integrated healthcare supply chain;
• To be universally accessible;
• To adapt to the diversity of the users and stakeholder groups;
• To service multiple stakeholder groups;
• To the best extent possible allow low barrier and tailored interfaces, multiple technology windows, channels, medium, and tools on the basis of the skill level, preferences, and tastes of each user;
• To the greatest extent possible prevent harm to the system user and eliminate data and system-related errors;
• To enable data from multiple formats and storage systems to be accessed, managed, and exchanged across distributed networks and systems;
• To feature the best and evidence-based practices of the health domain and the behavioral and informatic sciences; and
• To enable agent and intelligent technologies to perform duties for users, entities, and the system.

The technical requirements listed below are based on the functional requirements of the system and they reflect the consensus or standards of the industry. The system must be designed:

• To conform to standards, protocols, and procedures that will maintain the highest standards of security, privacy, and confidentiality;
• To support full interoperability in an open systems environment and to be flexible enough to change, migrate, or upgraded dynamically and seamlessly when appropriate;
• To conform to the standard programming conventions for portable and interoperable code, source, and language environments;
• To enable data to be accessed queried, managed, and stored in common or universal formats including distributed relational and object-oriented databases;

The whole thing - a draft of the whole text for this stage

Introduction to Analysis of the System Needs

SDLC Step 3 - Analysis of the System Needs

III. The System Needs

1. Introduction to the Needs Analysis

The goal of step 3 in the SDLC process was to arrive at a recommended set of specifications for the technical and functional needs of the proposed system. This study followed the traditional practice of analyzing and then comparing the technical and functional characteristics and needs of several highly rated systems with the proposed system. The systems were ranked according to their fit with the system requirements that were established in SDLC step #2 and their value for two stakeholder groups.

The system needs are the specifications for the technical and functional requirements that satisfy the eight requirements criteria that were established in SDLC step #2. Those requirements are deemed necessary in order to address the problems that were identified in Chapter 1 and step #1 of the SDLC process.

2. The Needs Analysis

Three types of information systems were chosen for the needs analysis. The three types of systems represent a diverse set of approaches to addressing the needs of the consumer as well as very different levels of technology complexity and integration. The first type of system, Internet websites, is the most popular and most basic type of information system. The websites dispense information and offer a diverse set of services and options to consumers. The highest volume websites among these sites are the commercial sites, the biggest of which have recently evolved into "web portals". Three web portals were chosen for the comparison exercise. The web portals were chosen on the basis of their ratings for volume of web traffic per month. In the summer of 2000, three of the most popular and respected health-related websites were Mayo Health Oasis, Healtheon/WebMd, and Yahoo Health.

The second group of systems are primarily theory-based and non-profit research projects. Each of the three systems received notoriety for their work in their field of heath informatics. The three systems that were chosen were the OneLife from the American Heart Association, CHESS from the University of Wisconsin-Madison, and HealthMedia from the University of Michigan.

The final option under consideration was the advanced informatic system that is being designed though this study. This system is of the same genre as the Guardian Angel project from the group from MIT and the Health Informatics Initiative from the Koop Foundation.

The researcher carefully analyzed the features and options available through each of the three types of systems. The systems were evaluated on how well they met the eight requirement criteria that were established in SDLC step #2. The eight requirement types are; legal and ethical (consent, privacy, and security), harm prevention and error reduction, data and knowledgebases (proactivity, tailoring, and best practices), user centric (dynamic and intelligent), linking affiliated systems, data, and system elements, open systems environment, efficiency of care and communication among agents of care, affiliated systems, and evidence based, and meets the objectives of the system.

The researcher assigned a rating for functional ability (specifications about what the must system do) and technical capacity (specifications for what the system is technically capable of) for each of the systems. For functional ability, the systems were rated on a 1-5 scale on how well the system met the eight criteria. The criteria for the scale was 1=any or some, 2=low, 3=medium, 4=high, 5=exemplary. A 0-3 scale was used for the technical capacity measures. The criteria for the scale was 0= not met, 1= very basic 2=some or medium, 3=high. Ratings were given the "benefit of doubt" or rounded up when a score could have been argued either way. Scores were given for two stakeholder groups, the consumers and users (cons.) and the practitioners and agents of care (pract.) on how well the system could addressed their needs. The scores for each of the systems were tabulated, averaged, and summarized in table 3.1 and 3.2.

A. Needs Analysis - Functional requirements of the system (what it must do vs. how it does it)

The functional requirements of the system are the specifications about what the system needs to do in order to satisfy the uses of the system. The functional requirements for the system emerged from the first two steps of the system development process including outlining the problem, opportunities, mission and goals and the definition of the system requirements.

Several of the most important functional requirements for the system were established. The system must be able:

• To empower users by allow them to control their relationship to the system, control access to and use of their data, and be afforded levels of privacy, security, and confidentiality that are consistent with their wishes;
• To promote health-enhancing lifestyles among users by providing proactive tailored content and services to users;
• To promote linkages and efficient communication and illicit feedback among users and the agents and entities of care who are part of the healthcare supply chain;
• To promote efficiency and streamlining through a fully integrated healthcare supply chain;
• To be universally accessible;
• To adapt to the diversity of the users and stakeholder groups.
• To service multiple stakeholder groups;
• To the best extent possible allow low barrier and tailored interfaces, multiple technology windows, channels, medium, and tools on the basis of the skill level, preferences, and tastes of each user;
• To the greatest extent possible prevent harm to the system user and eliminate data and system-related errors;
• To enable data from multiple formats and storage systems to be accessed, managed, and exchanged across distributed networks and systems;
• To feature the best and evidence-based practices of the health domain and the behavioral and informatic sciences; and
• To enable agent and intelligent technologies to perform duties for users, entities, and the system.

Table 3.1 - Needs Analysis - Performance ratings for functional ability

System Type	Ideal		Research systems (AHA, CHESS, Healthmedia)				Commercial portals (Mayo, Healtheon/WebMD, Yahoo)
Requirement Type	Cons	Pract.	Cons	Avg.	Pract.	Avg.	Cons	Avg.	Pract.	Avg.
Legal and ethical (consent, privacy, and security)	5	5	4,5,4	4.33	3,3,2	2.66	3,3,2	2.66	2,2,1	1.66
Harm prevention and error reduction	5	5	3,3,2	2.66	3,3,2	2.66	2,3,2	1.66	2,2,1	1.66
Data and knowledgebases (proactivity, tailoring, and best practices)	5	5	4,1,4	3	3,3,3	3	1,1,1	1	1,1,1	1
User centric (dynamic and intelligent)	5	5	2,1,2	1.66	2,2,2	2	2,2,2	2	1,1,1	1
Linking affiliated systems, data, and system elements	5	5	2,1,1	1.33	3,2,1	2	1,1,1	1	2,2,1	1.66
Open systems environment	5	5	4,3,3	3.33	3,2,2	2.33	3,3,2	2.66	3,3,2	2.66
Efficiency of care and communication among agents of care, affiliated systems, and evidence based	5	5	4,3,2	3	4,3,2	3	1,1,1	1	2,2,1	1.66
Meets the objectives of the system	5	5	3,3,3	3	3,2,2	2.33	2,2,2	2	2,2,1	1.66
Average-all requirements	5	5		2.78		2.49		1.75		1.62

Key: 1=any or some, 2=low, 3=medium, 4=high, 5=exemplary.

The data in Table 3.1 provides a comparison and summary of the three types of systems. The table illustrates how well the three system options would be able to meet the needs of the users and stakeholder groups.

B. Needs Analysis - Technical requirements (specifications for the system is capable of)

The technical requirements of the system refer to details the about the capacity and system-related design and engineering specifications that are needed in order for the system to perform at a level that satisfies the users of the system. The technical requirements are based on the functional requirements of the system. Industry standards, engineering and performance specifications, and technical requirements have been developed for most of the well-established or mature technology-related aspects within the information systems domain.

The technical requirements listed below are based on the functional requirements of the system and they reflect the consensus or standards of the industry. The system must be designed:

• To conform to standards, protocols, and procedures that will maintain the highest standards of security, privacy, and confidentiality;
• To support full interoperability in an open systems environment and to be flexible enough to change, migrate, or upgraded dynamically and seamlessly when appropriate;
• To conform to the standard programming conventions for portable and interoperable code, source, and language environments;
• To enable data to be accessed, queried, managed, and stored in common or universal formats including distributed relational and object-oriented databases.
• To enable systems, devices, and appliances to communicate and interoperate across a common infrastructure that can accommodate multiple systems and platforms;
• To conform to common user interfaces standards and guidelines that are flexible enough to accommodate to diverse groups of users and to adapt to the dynamic preferences and tastes of users;
• To comply with standards that support the use of dynamic, mobile, and intelligent agent technologies;
• To meet standards that allow for streamlining and the reengineering of the workflow and process throughout the healthcare supply chain;
• To promote the linkage and communication among affiliated systems throughout the healthcare network; and
• To fulfill or exceed the performance standards that are set by the designers and required by users of the system.

Table 3.2 - Needs Analysis - Performance ratings for technical capacity

System Type	Ideal		Research systems (AHA, CHESS, Healthmedia)				Commercial portals (Mayo, Healtheon/ WebMD, Yahoo)
Requirement Type	Cons	Pract.	.Cons	Avg.	Pract.	Avg.	Cons	Avg.	Pract.	Avg.
Legal and ethical (consent, privacy, and security)	3	3	2,2,2	2	2,2,2	2	1,1,1	1	1,1,1	1
Harm prevention and error reduction	3	3	2,2,1	1.66	1,1,1	1	1,1,1	1	1,1,1	1
Data and knowledgebases (proactivity, tailoring, and best practices)	3	3	3,0,3	2	2,1,2	1.66	0,0,0	0	0,0,0	0
User centric (dynamic and intelligent)	3	3	1,1,1	1	1,0,1	.66	0,0,0	0	0,0,0	0
Linking affiliated systems, data, and system elements	3	3	2,1,1	1.33	2,1,1	1.33	1,1,0	.66	1,1,0	.66
Open systems environment	3	3	2,2,2	2	2,2,2	2	2,2,2	2	2,2,2	2
Efficiency of care and communication among agents of care, affiliated systems, and evidence based	3	3	2,2,2	2	2,1,1	1.33	1,1,0	.66	1,1,0	.33
Meets the objectives of the system	3	3	2,2,2	2	1,1,1	1	1,1,1	1	1,1,0	.66
Average-all requirements	3	3		1.75		1.37		.80		.63

Key: 0= not met, 1= very basic, 2=some or medium, 3=high

Data from the needs analysis for the three systems will be used to help refine the technical needs and specifications for the model system. The data will also be used by the decision makers to determine which of the systems options is most appropriate and viable.

3. Decision Analysis for the recommended system

An important part of step #3 of the SDLC process is decision analysis. Several methods for making evaluations about the systems under consideration were used including the comparative analysis that is presented in table 3.1, 3.2, and 3.3, and the objective planning process method suggested by Coronel and summarized in table 3.4 (Coronel, 1997). In all cases, the proposed system was the most highly rated system and it would be the one recommended to decision makers for approval and permission to proceed with the design and development process.

Table 3.3 - Needs Analysis - Ratings of Functional and Technical Needs

	Functional Needs		Technical Needs
System type	Consumers	Practitioners	Consumers	Practitioners
Commercial portals	.35	.32	.26	.21
Research/Theory	.56	.50	.58	.46
Proposed system	1	1	1	1

The data for the two needs measurements is summarized in Table 3.3. The ratings have been converted to common units for purposes of comparison for all of the categories.

Table 3.4 - Objective Planning Process

Ques.	Com.	Funct.	Tech.	Res.	Funct.	Tech.	Model	Funct.	Tech.
1. Should it be continue - Is it broken?	It is fine for what it does with a limited scope of work.	It relies on providing generic information to change behavior. There is no use of behavioral science, tailoring, or proactive techniques. Little or no linkages with affiliated systems.	It is mostly open systems, because it is web-based, but the scope of work is very limited. Few technology windows are open. The drive is to consolidate the resources in one "portal"	The data-driven tailoring aspects of the system provide it with a sound theory base, improvement over the commercial products.	The use of psychographic data for tailoring is the basis for the system	Generally open systems, and sophisticated databases. Open communication protocols, and some multiple windows for users.	Yes, the development process.	Intelligent, user-centric, open, and fully connected supply chain.	Advanced database system, object orientation, with IA's
Should it be modified?	General modifications would not render significant improvements.			The framework is there but the modifications would be significant.			In the design phase.
Should it be replaced?	No, it's just not capable of all of the functionality and woefully underachieving. It meets only x of the 8 requirements	In it's current form, only generic content is possible.	It uses a generally common infrastructure and access channel.	No, it is a good step forward.	The tailoring is an important foundation.	The open systems and standards are good, and a good place to begin prototyping.	No, it needs to come in as a full concept.	It is designed to not need replacing, only upgrading.	It will have to conform to new standards and specifications.
Is it feasible?	Too much work, better to start over.	The information side could function properly, but not the other aspects.	It would have to migrate over to a new set of standards.	Yes, but it may be better to use the present systems as prototypes or start again with a bigger model.	The tailoring is a good start but the other areas need to be expanded.	Very possible with the open systems concepts, but OO would be better.	Yes, but it will require a significant amount of development resources, time and advancements in technology.	The system is designed to interoperate	The open systems and standards approach allows the elements to work together.

.

An interesting alternative method that is based on the work of Deeming, the analytic hierarchy process (AHP) was not used because it is beyond the scope of this investigation. In the AHP weights for the attributes for the system are assigned on the basis of the value or importance of the characteristic to the system and users. Because of the complexity and the size of investment that would be required to build the proposed system and level of risk if the system were to actually be developed and tested, use of a more advanced decision making process would be warranted.

4. Technical specifications for the proposed system

The following is a description of the most prominent elements and attributes that are needed for the proposed system. The specifications will be used to help to define the fundamental building blocks of the system that will be featured in the system design process in step #4 of the SDLC. As the proposed system has been described as a model system, all of the standards and specifications have been chosen only if they meet or exceed the highest standards for the industry. However, the exact details of the specifications and standards have not been included because that degree of detail is beyond the scope of this study.

Design

• Environment - open techniques and environment that provide for compliance, portability, scalability, and interoperability in areas such as for programming, communications, networking, system management, presentation, system services, and interfaces between applications and system services (Berson, 1996 p. 18) (For more details see Open Software Foundation, IEEE, WWW Consortium, International Organization for Standardization, Corporation for Open Systems, Object Management Group, American National Standards Institute etc.)
• Architecture - the structure should be modular, multilayered, N-tiered, and conforming to the seven OSI layers (For more details see ISO reference model etc.)
• Object oriented - uses a design and modeling process that allows for encapsulated packages of data and functionality among the elements of complex systems. Unified Modeling Language (ULM) is a common approach that is used. (For more details see Knapik, Gamma etc. )
• Development- follow a strategic, staged, and incremental methodology and use techniques for complex systems e.g. prototyping, iterative designs etc. (See Kendall, Jacko etc.)
• Interface - presents a look and feel that conforms to and accommodates to the user and features elements and attributes including mulitmodal, GUI, single system image, CCOW desktop interfacing middleware (For more details see Shneiderman, Neilsen etc.)

Technical

• Central structure and interfaces - all of the considerations that allow the system and its elements to interoperate, function, and perform as required
• Security - methodologies, protocols, tools, and techniques such as Secure Sockets Layer (SSL), Public Key Infrastructure (PKI), 128 byte level encryption, and electronic signatures that meets the standards of the HIPPA 1996 guidelines, HL7, WWW consortium and other standards and governing bodies (For more details see HIPPA, Netscape etc.)
• Telecommunications - infrastructure that is flexible, scalable, and accommodates the full spectrum electronic and digital options including wireless (microwave, satellite, infrared, spread-spectrum), protocols (TCP/IP, SNA) voice over IP, gateways, hubs, routers, Asynchronous Transfer Method (ATM), H.32x telecommunications protocols (See Mitretek Telecommunications Review etc.)
• Networking - should accommodate and feature flexible and scaleable topologies including LAN's, WAN's, GAN's, etc.
• Programming languages and environments - open and portable such as CORBA, JAVA, Enterprise Java Beans, ActiveX, CCOW, HL7, SNOWMED, XML, (For more details see Knapik, Kendall, Sun Microsystems, WWW consortium etc.)

Data

• Access, control, and management - must allow for integration of all data sources, ensure the security and integrity of the data, and be able to resolve issues such as redundant and missing data, corrupt data, concurrency etc.
• Rights and permissions - the system is user-centric in that users must have control of and grant permissions for their data
• Administration - procedures and systems for issues such as audit trails, fault tolerance, backups, etc.

Components and modules (the core)

• Central structure - the processes, procedures, rules, and the instructions and design of how the system is structured and works, adjusts, and dynamically updates itself (to be formalized in SDLC step #6)
• Devices for input and output - must accommodate a full range of options including computers, peripherals, and communications devices and appliances such as phone, wireless, PDA's, handhelds, optical scanners, electronic and auditory input etc.
• Interface - accommodating, intelligent and dynamic that is user centric and allows communication among the full range of input and output devices, and is mulitmodal so that it can function in several sensory channels including speech synthesis and recognition
• Data and knowledgebases and sources - the main data sources and elements including the universal identifier, the personal data profile, lifestyle, behavior and stage, incentives and motivation databases, the support network, content warehouse communications object, domain knowledgebases, the supply chain repositories, and even some of the emerging ones including Geographical Information Systems (GIS)
• Agents - software agents that perform a variety of automated tasks (see SDLC #2 8-9) and that have characteristics such as mobility, intelligence, dynamicity, object orientation, as well as the ability to accommodate soft computing functionality (fuzzy logic, evolutionary, neural networks)
• Service components - production and delivery of products and services, support networks, incentives and motivation
• Tailoring module - inference engines and knowledgebases for tailoring
• Affiliated systems - the supply chain including practitioners and agents, of care, healthcare providers, surveillance, tracking, and monitoring systems,
• Support - help and technical support tools and systems for users of the system

The technical needs listed above comprise a complete but not totally exhaustive list of specifications for the proposed system. Other elements and a further definition and refinement of the needs will arise as new products and options mature and become available and as the design and development process proceeds. The list of technical is consistent with the problems, opportunities, and objectives, the system requirements, and the system needs that were defined in SDLC step #1 - 3.

4. Summary

The goal of this step was to define the technical and functional requirements for the proposed system and conduct a comparative analysis of the merits of the proposed system relative to the other options that were evaluated. Although a direct comparison of the three types of systems is very difficult because of the major differences in the nature of the systems, given the requirements of the system as stated in step #2, the proposed system is clearly superior to the other options. Therefore, the design of the proposed system should proceed to the next step.

On to SDLC 4 - Determining the requirements for the proposed system

This page was designed by John Studach and is maintained by the NCHF webmaster. Last updated on December 29, 2000.

You can send e-mail to Me.

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