Attachment_G_-_OLAS_CONOPS_and_High_Level_Requirements.pdf

On-Line Application System:

CONOPS and High-level Requirements

File “OLAS ConOps and High-level Requirements.docx” Modified 12/16/2015 ii

Executive Summary This document describes the concept of operations (CONOPS) and high-level functional requirements description (FRD) for the On-Line Application System (OLAS).

The Concept of Operations (CONOPS) describes how the envisioned solution will support the operations of various award programs. This includes the goals and objectives to be satisfied, the processes to be supported, and users to be served, as well as the functions to be performed and the data to be managed by the system. OLAS consists of two main components:

Application Management and Evaluation/Selection Management. These components enable candidates to complete and submit on-line applications, and enable reviewers to rate, score and select candidates for awards. Application and review functions can be performed on-line using only a web browser, though printing may also be supported.

The OLAS functional requirements are derived from the business needs and functions identified in the award program process. Key functions for application management include the ability to manage opportunities, candidates, and applications. Key functions for evaluation/selection management include the ability to manage reviews and reviewers, as well as the ability to rate, score, and rank candidates.

Technical requirements are mostly typical of those for a “Moderate” federal IT system, though new FedRAMP requirements may apply to hosted solutions. In addition, a good deal of emphasis has been placed on flexibility to ensure that the solution is able to accommodate a variety of programs and changes over time.

iii

Contents 1 Concept of Operations

1.1 Goals and Objectives

1.2 Award Program Process Overview

1.3 Operations Context

1.4 Technical Context

1.5 Key Components

1.6 Key Information

2 Functional Requirements

3 Technical Requirements

4 Appendix

4.1 Information Examples

iv

Preface

Purpose and Scope

This document is the fourth in a series of deliverables for the concept phase of the On-Line Application System (OLAS). The purpose of this document is to provide the concept of operations (CONOPS) and high-level functional requirements description (FRD) for OLAS.

The PWS defines the associated task for this deliverable as follows: “Development of a concept of operations (CONOPS) and High-Level Functional Requirements for the application management processes of the U.S. Presidential Scholars Program, Volunteer Student Internship Program, and Teacher Ambassador Fellows program. Cooperation with the Department’s Office of the Chief Information Officer (OCIO) to coordinate any Departmental or federal policies, regulations or goals into the proposal.”

This document extends the first concept phase deliverable, On-Line Application System:

Review and Evaluation Report, and translates the key functions contained therein from a business process/sequence view to a system functional requirements view. That is, the initial deliverable focused on the overall program functions, while this document focuses more narrowly on the functional requirements of a system that can support the program functions.

Background

The U.S. Department of Education Office of Communications and Outreach (ED OCO) seeks to reengineer, streamline, and reduce costs to the Department with an integrated digital service to facilitate submission and review of applications of Scholars, Teaching Ambassador Fellows, and Volunteer Student Interns. The U.S. Presidential Scholars Program (PSP) currently has a system called PSAonline that is outdated and in need of replacement, and there is no system to process the latter two applicant types. One Online Application System (OLAS) is needed that can be used to process all three applicant types, with the flexibility to easily accommodate other similar ED award programs.

An overview of the three programs can be found on the Web at ED.gov and in the On-Line Application System: Review and Evaluation Report.

Organization of This Document

This document contains two primary sections.

Section 1 “Concept of Operations” describes the ConOps for the system, with emphasis on key functions, changes from current practice, and the tools/technologies that could be employed for each major function. It includes the goals and objectives for OLAS, program processes supported by the system, the operations context, key functional components, and key information managed by the system.

Section 2 “Functional Requirements” enumerates the high-level functional requirements for the system. It includes a priority for each requirement to facilitate implementation phasing and evaluation of alternative solutions that may not satisfy all requirements.

Revision History

Version Date Description of Change

0.01 11/26/13 Initial annotated outline.

v

0.02 12/17/13 Preliminary draft for internal revision.

1.00 12/20/13 Initial draft for review.

1.01 01/06/14 Final draft for delivery. Incorporated review comments. Edited for consistent terminology and completeness.

1.02 01/22/14 Minor updates to functional and technical requirements.

1.03 01/29/14 Accepted all changes for final publication.

1.04 09/26/14 Added technical context diagram for EARB

1.05 10/31/14 Updated requirements to include PAF, TAF, VSIP

1.06 11/26/14 Clarified SaaS expectations and ability rank within group

1.07 12/04/14 Added requirement to support nomination of participants

1.08 12/05/14 Fixed requirement table numbering. Changed accessibility to Critical. Added requirements for web analytics and user feedback. Updated capacity and performance information.

1.09 01/27/15 Added requirement to collect supplemental information and relaxed data loss requirement. Elevated viability to a level one requirement.

1.10 03/15/15 Added requirement to print applications as they come in without printing duplicates.

1.11 07/27/15 Updated PSP capacity requirement based on new program info.

1.12 10/28/15 Clarified FedRAMP requirement.

1.13 12/16/16 Raised priority of custom domain to “high” because of approval hurdles for exceptions.

References

U.S. Department of Education Performance Work Statement: Online Application System for U.S. Presidential Scholars Program, Teaching Ambassador Fellowship Program, and Volunteer Student Internship Program: Concept Phase. Provides background on the programs as well as the requirements for this deliverable.

On-Line Application System: Review and Evaluation Report. Captures the strategic drivers and business needs for OLAS. Contains an overview of the three ED award programs, strategic drivers, key business needs, gap analysis, and IT compliance and security considerations.

IEEE Std1362-1998 Guide for Information Technology—System Definition—Concept of Operations (ConOps) Document. Defines the recommended structure and content of a ConOps document, to include a statement of goals and objectives; strategies, policies, and constraints; organizations and interactions; responsibilities and authorities;

operational processes; and lifecycle processes.

IEEE/ANSI 830-1998 IEEE Recommended Practice for Software Requirements Specifications. Describes the desired characteristics of a software requirements document. Also defines the recommended structure and content of a software requirements document, to include a general description (product perspective, product functions, user characteristics, general constraints, and assumptions and dependencies) along with specific functional and non-functional requirements.

PSAO v9.0 Requirements. Describes the enhancements and bug fixes including in the July 2013 release of PSAonline.

vi

Presidential Scholars Application Online Systems Requirements, Version 2.3, November 17, 2006. Describes the complete baseline system requirements for the PSAonline system.

U.S. Presidential Scholars Program Support Services Contract: Performance Work Statement, September 2013. Defines the work performed to support “back office” functions of the PSP including identifying and selecting candidates, helping applicants, managing travel, and assisting with orientation.

Web accessibility guidelines and style guides (e.g., http://www.ed.gov/internal/styleguide).

U.S. Department of Education Federal Student Aid Lifecycle Management Methodology, FSA_TO_GUID_QM.NA_001.

ED’s Production Site Configuration and Services. Describes the hardware and software in ED’s production server facility.

http://www.ed.gov/internal/styleguide

1 Concept of Operations The Concept of Operations (CONOPS) describes how the envisioned solution will support the operations of various award programs. This includes the goals and objectives to be satisfied, the processes to be supported, and users to be served, as well as the functions to be performed and the data to be managed by the system. The CONOPS also serves as a stepping-stone to the FRD, translating sequence-oriented business processes into function-oriented system components.

1.1 Goals and Objectives

The purpose of OLAS is to support award programs at the Department of Education. More specifically, OLAS will manage information related to nomination, application, evaluation, and selection of Scholars, fellows, and interns. The goal is to enable award programs to efficiently and effectively identify the most qualified candidates. Key objectives related to this goal include the following:

Functionality. Provide functions to support the award program process from nomination through selection/award, involving geographically dispersed applicants and reviewers.

Flexibility. Provide flexibility to accommodate the various and evolving needs of multiple award programs, including the ability to easily change processes, the information captured, and evaluation criteria.

Cost. Provide the required functionality and flexibility needed at a lower lifecycle cost than the existing systems and services (e.g., substantially less than $500K to acquire and $200K/year to operate).

Performance. Support thousands of applicants and dozens of reviewers using the system within narrow, deadline-driven windows.

Usability and Operability. Provide intuitive interfaces that can be used by candidates with no training and by reviewers and program administrators with minimal training.

Implementation Timeline. Provide a solution to meet the needs of award programs as soon as practical, with a manageable level of effort and implementation risk.

Viability and Supportability. Provide the needed functions over the long term, with needed support and desired enhancements to accommodate technology evolution.

IT Compliance and Security. Provide compatibility with the ED and end-user environment (including the ability to access the system with only a web browser), and comply with federal security and accessibility requirements.

1.2 Award Program Process Overview

While each award program has its own process, all generally follow a sequence of steps that include providing program information, identifying candidates, obtaining candidate information, evaluating candidates, and managing awards. This section describes those steps in the generalized award program process, and identifies which of them are expected to be supported by OLAS. The purpose is not to precisely define the business process and workflow, but to characterize the scope of the system in terms of the business process that it is expected to support.

There are five main steps in the award program process. Only two (“Obtain candidate information” and “Evaluate candidates and select individuals”) are expected to be supported by

OLAS.

1. Provide program information. Each award program provides information about the program itself, including a program description, application procedures, and a link to the on-line application system. This step is currently supported primarily by general office software and the ED.gov website, and secondarily through a variety of outreach activities. OLAS is not necessarily expected to support this step since an adequate solution currently exists.

2. Identify/solicit candidates. All programs actively seek out qualified candidates, though the means and criteria they use may be vastly different. Because this step is so variable, it is not expected to be supported by OLAS. For invitation-only programs such as PSP, nominees are currently identified by standardized test scores, Chief State School Officer (CSSO) nominations, and other means. 1 The result is a list of qualified nominees that are invited to apply to the program, along with information about each nominee. For open-application programs such as TAF and VSIP, candidates may be solicited through postings on USAJobs and elsewhere.

3. Obtain candidate information. Candidates must submit an application to be considered for award. Information is gathered from the candidate and from other sources. OLAS is expected to support this step. For invitation-only programs such as PSP, the list of nominees is loaded into the system, and the nominees are notified and invited to apply through postal and/or electronic mail. Each candidate then completes and submits an application form. Letters of recommendation and other supporting information are also gathered from third parties. Information is expected to be gathered using electronic forms accessed through a Web browser, though paper submissions may be allowed as an alternative.

4. Evaluate candidates and select individuals. Candidates go through a structured evaluation process, performed by individual reviewers and committees using a variety of objective and subjective criteria. OLAS is expected to support this step. Applications may be automatically assigned to reviewers based on a variety of criteria, such as the candidates’ state of residence. Multiple reviewers may evaluate each candidate, and the results need to be combined so the applications can be scored and ranked.

Conceptually, reviewers should be able to evaluate applications both individually and as a group, using both on-line mechanisms and printed application packages.

5. Manage awards. Selected individuals may receive awards or qualify for placement as an intern or fellow. Because this step is so variable, it is not expected to be supported by OLAS. For honorary award programs, the primary need here is to present the award and maintain a searchable list of awardees. For fellowships and internships, there is a hand-off to departmental hiring processes as well as on-going coordination of fellowship and internship activities.

These steps are depicted in the diagram below. The shaded steps are those expected to be supported by OLAS.

1 In the future, PSP may consider other techniques to identify and qualify nominees that could further reduce the dependency on standardized test scores.

In addition, there are administrative processes to support the application, review, and award steps. As with the primary steps, only two (“Facilitate application process” and “Facilitate review process”) are expected to be supported by OLAS.

6. Facilitate application process. Applicants may require general and individual help with the application process. Some of this (e.g., phone support) is expected to be provided by a helpdesk function outside of OLAS. However, OLAS should provide on-line help and self-service features (e.g., password reset and application status) to reduce the helpdesk burden. In addition, OLAS must provide mechanisms to create accounts for applicants and authorize participant supporters (e.g., parents and recommenders) to enable collection of candidate information. It should also provide mechanisms to support communications between applicants and program administrators (e.g., status notifications and deadline reminders).

7. Facilitate review process. A substantial amount of work is required to coordinate reviews and provide ancillary information needed by reviewers. Some functions in this step, such as administering reviews and providing analysis reports, are expected to be supported by OLAS. Other functions, such as coordinating review and selection meetings, are expected to be provided by a separate event management system/service.

8. Facilitate award process. Award ceremonies, orientations, and other events also require a substantial amount of work to coordinate and conduct. This is expected to be provided by a separate event management system/service.

The process flow through these steps is relatively linear and simple. Within each step, however, there is a need for flexibility to collect information in whatever order it is available or most convenient to provide. Also, it should be possible to allow or disallow individual candidates to proceed from one step to the next before all candidates have completed a given step.

A w ar d

Pr og ra m

P ar ti ci p an t Pa rt ic ip an t In fo rm at io n

So u rc e, Sc h oo l O ff ic ia l, Pa rt ic ip an t

Su pp or te r

R ev ie w er

Provide Program Information

Start Award Cycle

Identify Candidates Obtain Candidate

Information

Facilitate Application Process

Evaluate Candidates and

Select Individuals Manage Awards

End Award Cycle

Facilitate Review Process

Facilitate Award Process

Program Information

Nominee Criteria

Nominees + Info

Candidacy Notification

Application Data

Evaluation Status

Award Qualification

Status

Candidate Info

Candidate Scores

Candidate Info

Request Review Package

1.3 Operations Context

OLAS will be used by a variety of stakeholders associated with the awards programs, including the following:

Program Participants (a.k.a. students, candidates). These are students and educators who go through the nomination, application, evaluation, and award process. They are often referred to casually as “candidates”, although Candidate is technically the title for a qualified participant. In scholastic programs such as PSP, they are commonly referred to as “students”. Participants use the system to provide and receive information relevant to their candidacy.

School Officials. These are recommenders (usually counselors) and principals who use the system to provide and certify information related to a participant.

Participant Supporters. Parents, guests, and advisors who support participants during the application and/or award process. Parents use the system to provide consent to the application. Guests (often other family members or influential teachers) may not use the system during the application process, but may attend award the award ceremony for an awardee (Scholar) and be recognized for their contribution. Similarly, advisors (former Scholars) may not use the system, but may attend the award ceremony to serve as counselors during the award event.

Participant Information Sources. A variety of sources are used to identify nominees and provide information relevant to their candidacy. For example, standardized testing services provide nominee lists based on test scores (using program-defined criteria), and these lists are augmented with nominees from CSSOs and the National YoungArts Foundation. Also, schools provide transcripts and other information. Information from these sources is typically moderated by program administrators or their delegates. That is, there is no expectation for a direct interface to the system. Rather, the information may be entered or bulk loaded by trained administrators.

Candidate Evaluators. Evaluators review participant information to rate and recommend candidates and select awardees. They may do this in both individual and group settings, based on both objective and subjective criteria. Also, there may be multiple rounds or stages of evaluation, with the same or different evaluators at each stage.

Administrative Users. Program admins, system admins, data entry, and support staff who use the system in an administrative or operational support role. Program administrators are staff within the award program office (or their delegated support contractors), who play an integral role throughout the nomination, evaluation, selection, and award process. They use the system to communicate with participants, to facilitate the application and evaluation process, and to manage program records. Data entry staff may manually enter application data on behalf of an applicant. Support staff use the system to produce reports and provide operational support. System admins use the system to perform system operations and maintenance activities.

The diagram below depicts OLAS within the overall operations context.

OLAS also needs to work within the context of other systems and organizations, including the following:

Linked Systems. These are external systems that are linked to and from OLAS to provide a relatively seamless, end-to-end user experience for participants. The ED website provides general program information, along with a link to OLAS. The list of awardees is also published on the ED website. For fellowship and internship programs, there may be links between OLAS and USAJobs and/or agency HR systems.

Candidate Evaluators

Program Participants

On-Line Application System (OLAS)

Linked Systems

USAJobs

ED Website

Application Management

* Manage Opportunities

* Manage Candidates

* Manage Applications

* Screen Candidates

Process Administration

* Manage Reports

* Manage Communications

* Manage Workflow

Prospect / Nominee

Applicant

Semi-Finalist

Finalist (optional)

Scholar / Fellow / Intern

Alumnus

Ancillary Systems

Phone/Web Conferencing

Expense Management

User Support/Helpdesk

Alumni Tracking

Candidate

Off-Line Assessment (People, Paper, Excel)

Administrative Users

Participant Information Sources

Standardized Test Services

Council of Chief State School Officers

Commission on Presidential Scholars

Program Administrator

Presidential Scholars Review Committee

Evaluation & Selection Mgmt

* Manage Reviews

* Manage Reviewers

* Prepare Review Packages

* Evaluate Candidates

* Select Individuals

School Officials

School Systems (via School Official)

Other Reviewers

Meeting/Event Management

System Administration

* Manage User Accounts

* Manage Records

Records Archive

National Archives Participant Supporters

Parent

Principal

Recommender

Guest

Advisor

National YoungArts Foundation

System Administrator

Data Entry Staff

Support Staff

Ancillary Systems. These are external systems that augment OLAS as needed to perform functions including off-line assessment, meeting/event management, alumni tracking, phone/web conferencing, expense management, and user support/helpdesk.

This recognizes the fact that many functions do not need to be tightly integrated into OLAS itself, and can be performed instead using an array of good, affordable commercial solutions.

Records Archive. As official agency records, certain materials generated by the program (particularly awardee lists) must be sent to the National Archives.

OLAS itself may consist of a number of subsystems and components to provide the full suite of required functionality covering application management, candidate evaluation, process support, and system administration. The table below shows the systems/components used to support each step of the awards program process.

Process Supporting System or Component

1. Provide program information Office SW + Linked Systems

2. Identify/solicit candidates Nominee Sources

3. Obtain candidate information OLAS (Application Management)

4. Evaluate candidates and select individuals OLAS (Candidate Evaluation)

5. Manage awards Ancillary Systems

6. Facilitate application process OLAS + Ancillary Systems

7. Facilitate review process OLAS + Ancillary Systems

8. Facilitate award process Ancillary Systems

This mapping serves as a transition from a sequence-oriented process view to a function-oriented system view that will be used to decompose and define the high-level functional requirements.

1.4 Technical Context

OLAS is expected to be implemented using a software-as-a-service (SaaS) model, and accessed using only a web browser with no special plug-ins.

The application data, software application, and application platform (servers, storage, and network infrastructure) will all be located at the service provider’s facility and accessed through the Internet.

A preliminary analysis was done to determine if a turnkey COTS application could satisfy the requirements of the program. The preliminary analysis included the following COTS products:

FluidWare FluidReview, Wizehive Select, Skild, omniSG omniCONTEST and SmarterSelect.

Based on that analysis, the program determined that a turnkey COTS solution could be a feasible option to satisfy the needs of the program.

1.5 Key Components

OLAS has two primary components:

Application Management. This includes managing award opportunities and deadlines, capturing and tracking applications, and screening applications against basic qualification criteria. Applicants are the primary users of this component.

Evaluation & Selection Management. This includes preparing review packages, calibrating/training reviewers, assigning candidates to reviewers, scoring/ranking candidates, and selecting awardees. Reviewers and selection committees are the primary users of this component.

These two functions are quite distinct, and do not necessarily have to be provided by a single integrated product. It is more important that each function be performed well, although the movement of data from the application to evaluation function should be simple and reliable.

Applicant, Reference, Or Reviewer

Vendor Service Firewall

ED Firewall

Internet

Service Administrator

Web Browser

Program AdministratorInternet

In addition, OLAS supports two administrative components:

Process Administration. This includes creating standard and custom reports to provide both summary and detail data on candidates to ensure program goals are being met and support process improvement. It also includes managing the process workflow and communications with participants, including both pre-defined and ad hoc notifications.

Program administrators (and their delegates) are the primary users of this component.

System Administration. This includes basic administrative functions such as user management and records management. System administrators are the primary user of this component.

1.6 Key Information

Most award program processes revolve around the participant, as represented by the participant’s application. The key information that must be managed by OLAS is summarized below.

Application. The information submitted by the applicant for evaluation, which generally contains a variety of structured data and unstructured text. Depending on the program, either the applicant or the application may be considered the subject of evaluation and award.2 o Participant identity and contact information. This information is used to identify and contact participants. This may be linked to the user profile in the account.

o Eligibility information. This includes citizenship/residency, graduation/diploma date, and standardized test scores and date. Eligibility information is similar to (and may overlap with) qualification information, but it typically consists of simple pass/fail criteria that can be evaluated automatically prior to completing more lengthy qualification information.

o Qualification information. This includes standardized test scores, state of legal residence, and gender. It also includes descriptions of activities, plans, viewpoints, contributions, challenges, etc. in both tabular and narrative forms.

Qualification information is used to evaluate candidates.

o Demographic information. This includes information about the candidate, including gender, location, disabilities, race, etc. Some information is voluntary and used to verify diversity in awards. Some demographic information may also be used as eligibility or qualification information. Congressional district is derived from location, and may be used for reporting.

o Resume (TAF). This is generally provided as a document (e.g., PDF or Word).

Resumes often contain qualification information, though typically in a non-standard form.

2 This is a subtle but important distinction. While ED award programs typically allow only one application per candidate, that should be a matter of policy not a system constraint. For example, some programs might allow candidates to re-apply in a subsequent year. Others might allow multiple applications from a single individual (as is common with art and grant programs).

o Supplemental Information. Transcripts, letters of reference, school profiles, and other information submitted by third parties in support of an application.

Supplemental information may contain or substantiate qualification information.

Evaluation Information. Ratings, comments, and other information provided by candidate evaluators, including reviewers and selection committees.

Post-Selection Information. Photographs, biographies, and other information collected from selected individuals to support award presentations and publications.

Award Information. Essential information about each award that is published and retained as an official record. Includes the candidate’s full name, state and city of residence, school, and year awarded and/or fellowship completion date.

Reference Information. Ancillary data needed to support reports and analysis. This includes school contact information, congressional district (by zip code), and congressional representative (by district).

Account. A system account representing an individual stakeholder in the award program process who has been given access to the system.3 Each account includes a user profile with identity and contact information. Accounts may represent participants, participant supporters, reviewers, program administrators, and others.

3 Note that, in some cases, access may be given to the system without an account. This includes public pages that can be accessed by anonymous users, and semi-private pages that can be accessed with a capability token (e.g., a special Web link).

2 Functional Requirements The OLAS functional requirements are derived from the business needs and functions identified in the award program process. They are grouped according to the functional components shown in the operations context diagram. The requirements are described in just enough detail to facilitate evaluation of alternative solutions: detail that might be required for a fully custom development effort has been omitted. Each requirement is assigned a priority (High, Medium, Low), which may be used to derive weights for alternative solution evaluation. High-priority requirements that are especially critical and somewhat unusual are noted as “Critical”.

Requirements are stated declaratively either as system features or functional statements.

Redundant phrases such as “The system shall provide the capability to...” are implicit and omitted for compactness, readability, and re-usability. “Manage” connotes the ability to fully manage the specified item, including the ability to create, view, edit, delete, search, print, and export the item or set of items.

Function Priority

1. Application Management

1.1. Manage Opportunities. Program administrators can manage

opportunities for different award programs and different cycles (e.g., annual) within each award program.

Critical

1.1.1. Create Additional Opportunity. Program administrators can easily create another opportunity similar to an existing opportunity. The new opportunity should inherit the application forms, review forms, and workflow of the existing opportunity.

Note: many programs have annual or quarterly awards.

High

1.1.2. Edit Opportunity Deadline. Program administrators can set the application deadline for each opportunity. The system rejects applications submitted after the deadline.

Critical

1.1.3. Post/Advertise Opportunity. Program administrators can post an opportunity (including description) to USAJobs and other job boards.

Low

1.1.4. Manage Opportunity Data. Program administrators can lock, export, and delete all application and review data associated with a specific opportunity.

High

1.2. Manage School Officials. Program administrators can manage accounts or access for principals, recommenders, and nominators.

High

1.3. Manage Participants. Program administrators can manage

participants and participant supporters. Adding a participant generally creates an account so that participant can manage applications.

Critical

1.3.1. Load Nominee List. Program administrators or system

administrators can create participant entities/accounts from a list provided as a text file. Note: participants at this stage are generally considered nominees.

Critical

1.3.2. Nominate Participant. School officials and program

administrators can nominate participants. Note: this is a supplementary capability to Load Nominee List.

High

1.3.3. Invite Participants. Program administrators can notify Critical individual participants of eligibility. The system can provide notifications by e-mail or postal mail (depending on availability of e-mail information). The notification provides application information including system credentials for the applicant’s account. Program administrators can track candidates and send reminders.

1.3.4. Manage Participant Data. Program administrators can delete all application and review data associated with a specific participant.

High

1.4. Screen Candidates. The system facilitates screening of participants prior to rigorous evaluation.

High

1.4.1. Confirm Eligibility. Participants can provide a limited set of eligibility information, preferably before creating a complete application. The system automatically verifies eligibility and provides an eligibility determination to the participant.

High

1.5. Manage Applications. Candidates can manage their own

applications for a given opportunity. Program administrators can manage applications for their assigned programs. A completed application contains all information needed to evaluate a candidate for an award, including forms and document attachments. Note:

functions related to evaluation and administration of applications are described in those respective sections.

Critical

1.5.1. Manage Application Folders. The system maintains a logical folder of information for each application. Program administrators can manage (add, edit, export, and delete) contents of one or more application folders. Exported folders are in a format suitable for off-line review of applications.

High

1.5.2. Load Application Data. Program administrators can bulk load application data (e.g., standardized test scores) for multiple candidates from a file.

Critical

1.5.3. Edit Application. Candidates can view, edit, and save data in an application form using only a Web browser. Candidates can save incomplete/invalid forms for later editing.

Critical

1.5.4. Auto-Save Application. The system auto-saves form data at regular intervals to protect against data loss.

High

1.5.5. Download Application. Candidates can download a blank

application form in fillable PDF format so they can complete, print, and mail an application. .

Low

1.5.6. Print Application Form. Candidates can print blank

application forms to be completed off-line and submitted by mail. Candidates can also print completed applications for their records.

Medium

1.5.7. Third-Party Information. Candidates and program

administrators can request information from third parties (e.g., recommenders and school officials), and third parties can submit information related to a specific applicant or application.

Third-party information generally is not visible to the applicant.

Critical

1.5.8. Attach Supporting Information. Applicants and third parties can attach documents containing supporting information (letters of recommendation, transcripts, etc.) to an application.

Critical

The attached information may or may not be visible to the applicant depending on program policy.

1.5.9. Validate Application. The system verifies that all mandatory fields have been completed before an application can be submitted.

High

1.5.10. Submit Application. Candidates can submit completed

applications prior to the application deadline for an opportunity.

Submitted applications become eligible for evaluation. After the deadline, applications are blocked or rejected.

Critical

1.5.11. Get Application Status. Candidates and others can view the status of an application.

High

1.5.12. Print Applications. Program administrators can print a batch of applications (e.g., to a printer or PDF file) as they are received without printing duplicates (i.e., without printing older applications that were previously printed).

Medium

1.6. Supplemental Information. Program administrators can request supplemental information (e.g., SSN, photo, biography, etc.) to be provided by applicants at various stages of the process, including after selection.

High

2. Evaluation & Selection Management

2.1. Manage Reviews. Program administrators can manage reviews for their assigned programs. Reviews are scheduled activities in which applications are evaluated by reviewers. Reviews generally have a start and end date/time. Reviews may be conducted sequentially or in parallel.

Critical

2.1.1. Assign Reviewers. Program administrators can assign

reviewers to a review.

High

2.1.2. Assign Applications. Program administrators can assign applications to a review or to a reviewer. Applications can be assigned manually or automatically, including rule-driven assignment based on application data. (Note: programs may assign applications based on state, gender, etc.)

Critical

2.1.3. Show Review Progress. Reviewers and program

administrators can view the progress of a review, such as the number of applications reviewed.

High

2.1.4. Provide Review Packages. Program administrators and

reviewers can export review packages containing the application folder for each candidate.

High

2.2. Manage Reviewers. Program administrators can manage reviewers in the system. Reviewers are human resources that can be assigned to a review or to a specific application in a review.

Critical

2.2.1. Manage Review Team. Program administrators can create

review teams and assign reviewers to teams. Review teams can be used to simplify assignment of application for review.

High

2.3. Evaluate Candidates

2.3.1. Review and Rate Candidates. Reviewers can view

application data and enter candidate ratings and comments for each of the established criteria.

Critical

2.3.2. Normalize Ratings. Program administrators can adjust all ratings provided by a given reviewer. The original ratings are

Medium retained.

2.3.3. Consensus Ratings. Review groups can create consensus

ratings of candidates that take precedence over individual reviewer ratings.

High

2.3.4. Score Applications. The system calculates a score for each candidate/application based on the reviewer ratings and weighted evaluation criteria.

Critical

2.4. Select Individuals

2.4.1. Rank & Select Candidates. The system automatically ranks candidates by their calculated scores. Program administrators can manually adjust the rankings (e.g., based on demographic data and subjective criteria). Reviewers can select candidates/applications for further consideration or award.

Critical

2.4.2. Rank Within Group. The system can rank candidates within groups defined by application data (e.g., state of residence or category of applicant).

Critical

2.4.3. Get Selections. Program administrators can get a list of candidates selected for further consideration or award.

Critical

3. Process Administration

3.1. Manage Programs and Awards. Program administrators can define programs and awards, which have a defined set of static website content, authorized users, application forms, review forms, and workflows.

High

3.1.1. Manage Forms and Workflow. Program administrators can

define the application forms and workflow used for a program or an opportunity. At a minimum, program administrators should be able to pick from pre-defined forms and workflows.

Ideally, program administrators would be able to develop custom forms and workflows without programming.

Critical

3.1.2. Manage Evaluation Criteria. Program administrators can define the evaluation criteria used for each review within each program, and assign weights to each criterion. Criteria weights are used to calculate scores from review ratings.

Critical

3.2. Manage Reports. Program administrators can create reports on participants, applications, reviews, and other information in the system without programming.

High

3.2.1. Get Selection Report. Program administrators can get a report of candidates selected at any stage of the process.

High

3.2.2. Analyze Candidates. Program administrators can get

analytical reports on candidates at any stage of the process.

These reports include statistical analysis of candidates relative to demographic data, evaluation criteria, etc.

High

3.3. Manage Communications

3.3.1. Message Stakeholders. Program administrators can initiate messages for stakeholders (including participants, school officials, and reviewers). Messages may be for a single stakeholder, group of stakeholders, or stakeholders for any group of candidates/applications (e.g., awardees). The notification content is based on a template and personalized as needed for the applicant/application. Notifications can be sent by e-mail and, optionally, postal mail or text message.

3.3.2. Notify Participant. The system sends a notification to participants when the status of their application changes. The notification content is based on a template and personalized as needed for the applicant/application. Notifications can be sent by e-mail and, optionally, postal mail or text message.

High

3.3.3. Remind Participants. The system can send an automatic

reminder e-mail notification to participants based on application status and opportunity dates.

Medium

3.3.4. Send/Get Message. Candidates and program administrators can send messages to each other and view received messages.

Medium

3.3.5. View Communications. Program administrators can view all communications with a given candidate.

Medium

4. System Administration

4.1. Manage Accounts

4.1.1. Create Account. Program administrators and (optionally) candidates can create accounts on the system.

Critical

4.1.2. Assign Third-Party Privileges. Third parties (e.g., recommenders) can be assigned privileges (through an account or capability token) to submit supporting information for a candidate/application.

Critical

4.1.3. Third-Party Identity Verification. The identity of third parties (e.g., recommenders) submitting information on behalf of a candidate is verified through some mechanism. (Note: the current solution achieves this by sending credentials to the third party via postal mail. Some solutions send a link to a known email address. The purpose is to know the source of third-party information.)

Critical

4.1.4. Reset Password. Users can reset the password for their own account. Program administrators and system administrators can reset passwords for participants, reviewers, and other system users.

High

4.2. Manage Records

4.2.1. Export Award Data. Program administrators can export

selected award data in an open format, which may be archived as official agency records. Optionally, program administrators can define specific fields from applications to be included in the export, and select a group of candidates/applications to be exported.

Critical

4.2.2. Delete Records. System administrators can delete working records (including application and review data) according to a records retention schedule. The system does not necessarily implement the records retention schedule itself.

High

4.3. Manage Configuration

4.3.1. Export/Import Configuration. System administrators can export and import the configuration for a program including all customized forms, workflow, and evaluation criteria.

3 Technical Requirements The OLAS technical requirements are driven by business needs and federal IT requirements.

Requirement Priority

1. Flexibility

1.1. Multiple Programs. Provide the ability to support multiple award programs and add future award programs with simple configuration changes.

Critical

1.2. Custom Forms. Provide the ability to easily create and manage custom application and review forms.

Critical

1.3. Scoring. Provide the ability to easily change the weights of criteria used for scoring, and to otherwise specify the scoring algorithm.

Critical

1.4. Ranking. Provide the ability to automatically rank applications, and to easily manipulate/override rankings.

Critical

1.5. Documents. Provide the ability to easily define additional documents to be included in (attached to) an application.

Critical

1.6. Data Fields. Provide the ability to easily create and customize data entry fields, manage the valid values, and adjust features and conditions of each field. On specific forms, provide the ability to control whether fields are mandatory or optional, control visibility by user role, and control whether fields are editable or view only by user role. Provide the ability to specify help text and links for more information about a data field.

Critical

1.7. Workflows. Provide the ability to easily change and manage workflows or processes of each program and assign workflow/task owners.

High

1.8. Query and Reporting. Provide the ability to easily query data according to desired parameters within the system and easily create custom reports and exports.

Critical

1.9. Load Reference Data. Provide the ability to load reference data that can be used in forms, workflow, and notifications.

High

1.9.1. Load educational institution list. Provide the ability to load a list of educational institutions (including ID and name) and use the values as a selection list for a form field.

Critical

1.10. Customize Look. Provide the ability to customize the look, logo, and text of web pages to reflect customer-specific “branding”.

High

1.11. Custom Domain. Provide the ability use a customer-supplied “.gov” Internet domain name.

High

2. Performance & Availability

2.1. System Capacity. Provide sufficient capacity to support peak loads while meeting required response times.

Critical

2.1.1. Capacity for PSP. Support submission and review of ~5,000 applications per annual cycle. Support roughly four users per application (applicant, parent, recommender, principal).

Support 1700 peak concurrent applicants during program application windows (e.g., Jan – Feb) and 20 peak concurrent reviewers during review windows (e.g., Mar – Apr) while meeting required response times.

2.1.2. Capacity for TAF. Support submission and review of ~1,300 Critical applications per annual cycle. Support 430 peak concurrent applicants during program application windows (Dec - Jan), 1200 application submissions on the application deadline day (Jan 15) and 60 concurrent reviewers during peak review windows (Jan - Feb) while meeting required response times.

2.1.3. Capacity for PAF. Support submission and review of ~500 applications per annual cycle. Support 170 peak concurrent applicants during program application windows (Dec - Jan), 450 application submissions on the deadline day (Jan 08) and 20 peak concurrent reviewers during review windows (Jan - Feb) while meeting required response times.

Critical

2.1.4. Capacity for VSIP. Support submission and review of ~750 applications annually. Support 250 peak concurrent applicants during summer program application windows (Feb

– Mar), 50 peak concurrent applicants during other application windows (Jun – Jul, Aug – Sep), and 50 peak concurrent reviewers during review windows (the month following the application period) while meeting required response times.

Critical

2.1.5. Multiple Programs. Support multiple programs (PSP, TAF, PAF, VSIP) while meeting required response times.

Critical

2.2. Response Time. Provide a maximum 3 second response time for trivial user actions and maximum 10 second response time for complex user actions.

Critical

2.3. Scalability. Provide the ability to easily scale resources (and associated costs) up and down to support a varying number of programs and varying load throughout the year.

High

2.4. System Availability. Support an estimated availability of 99% or better during business hours.

High

2.5. Outage Notification. Provide at least two-weeks advance

notification of planned outages.

High

2.6. Data Availability. Limit data loss when filling forms to no more than five minutes.

Medium

2.7. Disaster Recovery. Limit data loss from catastrophic failures to no more than 24 hours. Return to operations following a catastrophic failure within 72 hours.

Low

3. Usability & Operability

3.1. Intuitive Interface. Applicants must be able to easily navigate and complete their on-line application with no training and limited direction. Reviewers and administrators should only require minimal training. Help text should be generally available for most data entry fields.

High

3.2. Long Selection List Handling. Provide the ability to populate a single-item selection form field effectively from list of hundreds or thousands of items (e.g., by providing a pop-up searchable list or autocomplete function).

Critical

3.3. Implementation Timeline. Provide the ability to fully implement the solution with customized application forms and review criteria for a single program within two months and obtain authority to operate within four months (total).

3.4. Technical Support. Provide technical support for reporting and resolution of system issues, with acknowledgement within one business hour and initial response within one business day.

Critical

3.5. System Documentation. Provide sufficient system documentation, including on-line help and training materials, to support use of the system by applicants, reviewers, program administrators, and system administrators.

High

3.6. Web Browser Access. Applicants and reviewers must be able to perform all application and review functions using only a Web browser.

Critical

3.7. Web Metrics. Provide the ability to obtain information on public web page accesses (e.g., by allowing an embedded web analytics link).

Medium

3.8. User Feedback. Applicants and reviewers can provide feedback on their satisfaction with the system and application/evaluation process.

Medium

4. Viability Critical

4.1. Product Viability & Support. Show sufficient vendor, customer, and user community support to ensure the product will…