Requirement		Introduction
Section		1
JIRA Task		EIR-29 - Getting issue details... STATUS

Executive Summary

Epi Info™ 7 is an epidemiological database and analytical platform for x86-based personal computers running the Microsoft Windows operating system. The application is designed for use in remote locations with limited Internet connectivity or access to professional information technology (IT) support. The user has the option of using a remote database (SQL Server, mySQL or PostgreSQL) or a local MS Access database; Epi Info™ 7 works equally well with both. The application can be run independently of the network for all data collection and analytical functions. Internet connectivity is only required for integrating data with geographic information and merging data collected from other sources. There are numerous General Public License (GPL) or open source-statistical packages, but few with the ease of use of Epi Info™. In addition, Epi Info™ is designed to allow public health professionals to systematically collect data from disease outbreaks in remote locations and conduct essential statistical and epidemiological data analysis, all with minimal training in the use of the application.

Epi Info™ covers the four major functions needed to mitigate a disease outbreak in real time. First, clinical and historical information must be collected from individuals in the affected area as accurately and quickly as possible. This requires an interview questionnaire to systematically collect the data while ensuring the highest possible quality; the Form Designer module supports this. It allows the user to drag and drop different data collection widgets—such as selection menus, check boxes, and text-entry fields—onto a canvas and associate the data collected with variables stored in a database. A system of "check codes" allows the form designer to perform logical or mathematical tests to validate the data and disable fields rendered inapplicable by previously entered data. The forms are flexible; new questions can be added during data collection, allowing epidemiologists to pursue new leads in the dynamic environment of a public health emergency. The Enter module supports data entry by using the questionnaires developed in Form Designer to prompt the subject and interviewer for specific data. The systematic collection of data makes it possible for the epidemiologist to analyze those data immediately, in contrast to the unstructured interview in which notes need to be collected and interpreted after the fact.

There are two analytical modules in Epi Info™, Classic Analysis and the Visual Dashboard. These offer similar tools but differ in how they are configured and how results are presented. Visual Dashboard is the newest module and has the most up-to-date and user-friendly interface. It allows the user to select standard statistical tests and specialized epidemiological tools from a menu and configure them using a graphical interface. Once the input data are defined, the tool's output, typically in the form of a graph or chart, is dropped onto a canvas. This process can be repeated with as many analyses as needed, turning the canvas into an analytical "dashboard" that is updated every time new data are entered into the system.

The Map module complements the data collection and analytical modules by allowing the user to plot location data on geographic information system (GIS) base maps or shape files. The locations of individuals can be colored or filtered based on other data such as clinical presentation or risk factors. Maps can be zoomed in and out and overlaid with demographic data and other reference content. The ability to rapidly create views on the distribution of cases in relation to other factors allows an intuitive exploration of data that can then be used to propose testable hypotheses, shaving weeks or months off the hunt for the source of the outbreak. This savings of time and effort can not only reduce the financial cost of mitigation efforts, it can reduce morbidity and mortality.

Purpose

Epi Info™ 7 is a series of tools and utilities packaged for use by public health professionals to conduct outbreak investigations, manage databases for public health surveillance and other tasks, and execute general database and statistics applications. This document is intended to familiarize third parties and new Epi Info™ team members with the purpose of the software and its role in supporting the work of the epidemiologists and public health professionals who depend on it, and to connect this information to the details of its implementation. Because these requirements are being documented retrospectively, they are not intended to drive the development of the current software package (version 7.2). Instead, this documentation will lay the ground work for collaborative development in the future to implement functionality not yet conceived and to solve problems not yet encountered.

Scope

This software requirements specification (SRS) is for the Epi Info™ 7 software package (version 7.2) produced by the Centers for Disease Control and Prevention in Atlanta, GA, USA. Epi Info™ enables physicians, epidemiologists, and other public health officials to complete several tasks essential to their role in identifying, tracking, and mitigating outbreaks of disease or other public health emergencies. A user can rapidly develop a form, questionnaire or survey for collecting demographic, clinical, and geographic information from affected individuals, their family members and contacts, and other individuals in the location of interest. With the user-created form, the data entry process can be customized by adding validation constraints, internal consistency checks, response-dependent question selection, and other internal logic, collectively known as "check code."

Once the form and underlying check code are complete, the form can be used in the field to collect data, typically during face-to-face interviews with the subjects. The data entry process populates a tabular data structure that serves as input to the data analysis and mapping modules. There are two analysis modules, "Classic Analysis" and "Visual Dashboard," which have similar sets of tools but differ in how tools are chosen and how their results are displayed and stored. The Classic Analysis module has the advantage of creating a script of operations in text format, which the user can edit and execute using a command interpreter. The Visual Dashboard allows the user to select tools from a menu and store the resulting tables and graphs on a visual canvas. Once the Dashboard is created, the displayed results are updated as additional data are added to the project. Finally, primary data and results from the analytical tools can be displayed as layers on a geographical map along with political, civil, or geophysical metadata using the Map module.

Requirements Overview

This SRS has been developed according to IEEE 830-1998 Recommended Practice for Software Requirements Specifications.^[1] This standard provides a prototype SRS outline (Figure 1^[1]) and a description of its components, which the IEEE Software Engineering Standards Committee considers essential for a good SRS. A good SRS should be complete, consistent, unambiguous, correct, and verifiable. The organization of this SRS is based on the outline prototype and has been adapted for use here. The outline can be found just below the root page for the Epi Info™ 7 Requirements space. The specific requirements are organized into the external interface requirements followed by the requirements for the six major system components (modules): Form Designer, Enter (for data entry), Classic Analysis, Visual Dashboard, StatCalc, Map, and System Configuration. This organization corresponds to that recommended in Annex A of the IEEE-830 Standard, Section A.5, "Template of SRS Section 3 organized by Feature." A Feature is defined as, "an externally desired service [provided] by the system that may require a sequence of inputs to effect the desired result." This definition aligns well with the functionality provided by the Epi Info™ program modules. Each feature can be described in a sequence of stimulus-response pairs. The sequences can be organized hierarchically, from the highest level of abstraction down to individual user-interface interactions, and, ultimately, to the code that implements the response.

Specific Requirements

This section (section 3) is the largest part of the SRS and the most important to system developers and testers, as well as those seeking to extend the functionality of Epi Info™ 7 and understand its operational details. Because different requirement types lend themselves to description with different devices, an organizational unit consisting of four components has been adopted. This framework consists of a User Story describing a particular task, a Stimulus/Response Sequence describing how the User interacts with the system to complete the task, a list of Functional Requirements the system must meet to complete that Sequence, and a "data table". If the User Story is very specific, it may not be appropriate to include the fourth component. However, it is often desirable to create a more generic User Story, one with a common workflow surrounding a single step that can be modified systematically to yield different (but related) results. In this case, adding a table, which contains the details of all the ways that step can be modified, enables a clearer and more succinct statement of the requirements for those variations.

Definitions, Acronyms and Abbreviations

This sub-section contains a list of acronyms and abbreviations that appear in this document and their associated descriptions.

Table of Acronyms and Abbreviations

Acronym	Description
ANSI	American National Standards Institute
BA	Business Analyst
BABOK	Business Analyst Body of Knowledge
CA	Classic Analysis (Epi Info™ module)
CMS	Content Management System
CSS	Cascading Style Sheet
EPLC	Enterprise Performance Life Cycle
GIS	Geographic Information System
GPL	General Public License (GNU)
GUI	Graphical User Interface
HIPAA	Health Insurance Portability and Accountability Act of 1996
IEEE	Institute of Electrical and Electronics Engineers
IIBA	International Institute of Business Analysts
JSON	JavaScript Object Notation
KML	Keyhole Markup Language
MS	Microsoft Corporation, Inc.
PHI	Protected Health Information (HIPAA Administrative Simplification Provision)
REST	Representational State Transfer (alternative to SOAP)
SOAP	Simple Object Access Protocol (XML protocol)
SRS	Software Requirements Specification
UI	User Interface
URL	Uniform Resource Locator (aka Universal Resource Locator)
VD	Visual Dashboard (Epi Info™ module)
XML	Extensible Markup Language

Glossary

A list of common English words with specialized meanings in the context of information technology.

argument. a constant, variable, or expression used in a call to a software module to specify data or program elements to be passed to that module^[3].
parameter. a constant, variable, or expression that is used to pass values between software modules^[3].

References

The content and organization of this software requirements specification is based on IEEE 830-1998 ^[1], with modifications suggested by IEEE 29148-2011 ^[2].

ISO/IEC/IIEEE 830-1998 Recommended Practice for Software Requirements Specifications
ISO/IEC/IIEEE 29148-2011 Systems and software engineering -- Life cycle processes --Requirements engineering.
ISO/IEC/IEEE 24765:2010 Systems and software engineering--Vocabulary.

Browser not supported