APPENDIX A
FUNCTIONAL and SYSTEM REQUIREMENTS
TEST DELIVERY SYSTEM
The following section provides background information on the technical priorities for the system,
instructions for completing Appendix A, and the Appendix A matrix which all Vendors are required to
complete. If necessary, Vendors may add additional descriptions of how they will meet requirements in
Appendix A. However, Vendors should not exceed the 250-page limit.
A.1 Overview of Key Technical Priorities
Given the complex challenges, the CONSORTIUM is seeking a CONTRACTOR that will provide
innovative thinking to address the following key priorities.
a. Open-Licensing. The CONSORTIUM is committed to open-licensing and open-source
technology standards and applications that support interoperability, innovation, and a lower
cost of ownership. Yet it recognizes the current limitations in available open-licensing software
and in certain situations may accept the use of proprietary components as long as there is a
future roadmap towards open-licensing technology.
b. Highly Available and Scalable System. The Test Delivery System must support high
availability and scalability and perform under periods of high usage and high processing loads.
Although most schools have testing periods from September through June, some states have
schools that are open year-round and may require longer testing periods beyond a traditional
school year.
c.
System and Data Recoverability. The Test Delivery System will need the ability to recover
from a hardware or application failure. It must have built-in redundancy and fail-over
architecture to ensure seamless system recovery. Student progress should be stored in real
time so that, if failure occurs during the testing process, it can be restored so that the student
can resume from the same testing point of an assessment session once the systems are back
online.
d. Data Integrity. The Test Delivery System must provide end-to-end data protections to ensure
no data is lost or corrupted during processing, storage, and transportation between
applications and interfaces.
e. Security. The Test Delivery System must maintain the highest level of security in order to
safeguard the confidentiality of items, student information, and assessment results. The
required security level is comparable to that required by financial institutions to prevent
security breaches.
f.
Minimal Impact on State and Local Systems. The CONSORTIUM’s vision is to minimize the
impact on and required updates to state, district, and local school specific systems (e.g.,
networks, servers, and testing PCs). This includes efforts to minimize the technical footprint
1
required of desktop PCs used for student testing, downloading of new software and add-ons
to servers and PCs, and additional data storage requirements.
g. Member State Cost of Ownership. The CONSORTIUM is committed to building a Test
Delivery System with a low cost-of-ownership model for the member states. To this end, the
CONSORTIUM is planning to spend a large amount of funding for the initial technology buildout, which should translate into a low amount of funding for maintenance and enhancements.
h. Varying Levels of State and Local Technology Capability. Within the CONSORTIUM, there is
considerable variance in technology capability, from low to high levels of capability. Some
states and their associated districts and local schools may not have the ideal processing
power of modern PCs/devices, and LAN and network bandwidth may be limited. A technology
approach must be developed to be able to maximize capabilities for states with high levels of
technology capability, as well as states with the lowest level of technological capability.
With the planned rich content included in the testing items, the Assessment System needs to
be constructed so that the processing through the network and testing delivery system is
efficient and optimized for high-capability states, but does not cause testing disruptions in lowcapability states.
i.
Diversity of Hosting Options. Some states in the CONSORTIUM will want an external provider
to host their full assessment system, while others may plan to integrate the system into their
own infrastructure. The architectural considerations for supporting a variety of implementation
options must be accommodated.
j.
System Flexibility. The Test Delivery System will be composed of a tightly integrated suite of
applications and programs. It must be built with enough flexibility that states can either use the
entire system or be able to integrate and/or replace components with state-specific
applications. This effective use of standards, business rules, security protocols, and
integration architectures will be critical to enabling this level of interoperability. The systems
portal is an example of a potential state-specific component that could be customized.
k.
Data Management—Student Data. The Test Delivery System must support the seamless and
secure sharing of student information with the respective state-specific student information
management systems. This includes both the receipt of student data from the state systems
and the export of student results back to the state systems.
l.
Accessibility. The Assessment System must be in compliance with Section 508 and ideally
with the Web Content Accessibility Guidelines 2.0. The substantive content (e.g., items) must
be associated with meta-data that describes any changes that will be made to the content,
display, or input method necessary to provide appropriate accommodations support to the
student. In addition, the overall approach must leverage the use of computer-based
accessibility tools, driven by an item tagging system that will control and ensure appropriate
application of those tools.
2
A.2 Appendix A Instructions
Vendor shall provide deliverables, services, and staff and otherwise do all things necessary or incidental
to provide the functionality required for SBAC’s business operations, in accordance with the requirements
as set forth below. All requirements and requests for information listed below should be
considered mandatory. The Vendor must respond with whether or not their proposed system complies
with each requirement in Appendix A as follows:
Vendor proposing COTS solution
Note: In order for your bid response to qualify for the selection process, all requirements responses must
be a Yes or a Yes with Modifications.
Vendor must respond in the table below with whether or not their proposed solution complies with
each requirement as follows:
1. Check the box that applies to each requirement in the column labeled Yes, Yes with
Modifications, or No.
a. “Yes” is defined as: The Vendor’s solution complies with all aspects of the requirement and
is currently a standard feature.
In the comment box, the Vendor must describe how its proposed solution complies with the
requirement. If applicable, screenshots may be included as an appendix to show this
functionality.
b. “Yes with Modifications” is defined as: The solution does not currently comply with the
requirement, but the Vendor will modify the solution through configuration, programming,
or source code changes which, in the Vendor’s opinion, would result in its solution
reaching full compliance with the requirement.
In the comment box, the Vendor must describe the modification that will be made and how it
will comply with the requirement. All such modifications are considered to be part of the
solution being proposed and included in the bid price. If the modification will not be
complete by the “go live” date, the Vendor must specify an anticipated date when the
modification would be added to the solution, at no additional cost to SBAC. SBAC reserves
the right to reject the Vendor’s proposed date and consider the solution not in compliance.
c. “No” is defined as: The Vendor’s proposed solution does not comply with all aspects of the
requirement.
In the comment box, the Vendor must describe the impact of not meeting the requirement.
Vendors that fail to meet requirements will NOT be considered for this award.
2. Fill in the column labeled Requirement Response (REQ Response) for each requirement with
an A, B, C, D, or E, as defined below.
A. currently provided as a standard feature
B. not currently provided, but is a planned enhancement and will be added at no additional cost by
the date specified in the comments box, and will be supported in future releases
C. not currently provided, but will be added at the additional cost detailed in the cost proposal and
will be supported in future releases at no additional cost
3
D. not currently provided, but will be added at the additional cost detailed in the cost proposal and
will require additional cost to transfer to future releases
E. not supportable
In the comment box the Vendor must provide any additional information related to the solution.
The Vendor response to each requirement should contain adequate information for SBAC to
evaluate without referencing responses to other requirements.
In the comment box the Vendor must provide any additional information related to the solution.
The Vendor response to each requirement should contain adequate information for SBAC to
evaluate without referencing responses to other requirements.
In the comment box, the Vendor must provide any additional information related to the
solution.
The Vendor response to each requirement should contain adequate information for SBAC to
evaluate without referencing responses to other requirements.
Vendor proposing custom-built solution
Note: In order for your bid response to qualify for the selection process, all requirements responses must
be a Yes.
Vendor must respond in the table below with whether or not its proposed solution complies
with each requirement as follows:
Check the box that applies to each requirement in the column labeled Yes or No.
A. “Yes” is defined as: The Vendor’s solution will comply with all aspects of the mandatory
requirements and will be fully operational at the “go live” date.
In the comment box, the Vendor must reference the section of its proposal that documents
how its solution meets these requirements, or provide information on how it will meet this
requirement.
B. “No” is defined as: The Vendor’s proposed solution does not comply with all aspects of the
requirement.
In the comment box, the Vendor must describe the impact of not meeting the requirement.
Vendors that fail to meet requirements will NOT be considered for this award
4
Vendor proposing custom-built solution
Note: In order for your bid response to qualify for the selection process, all requirements responses must
be a Yes.
Vendor must respond in the table below with whether or not its proposed solution complies
with each requirement as follows:
Check the box that applies to each requirement in the column labeled Yes or No.
C. “Yes” is defined as: The Vendor’s solution will comply with all aspects of the mandatory
requirements and will be fully operational at the “go live” date.
In the comment box, the Vendor must reference the section of its proposal that documents
how its solution meets these requirements, or provide information on how it will meet this
requirement.
D. “No” is defined as: The Vendor’s proposed solution does not comply with all aspects of the
requirement.
In the comment box, the Vendor must describe the impact of not meeting the requirement.
Vendors that fail to meet requirements will NOT be considered for this award
ID #
Requirement
COTS
Development of a new
system
Please describe your approach for providing a solution: (1) utilization of a COTS
product, (2) development of a new custom system.
5
ID #
Requirement
Field
YES
Test (FT
or Pilot
Test
(PT)
YES, WITH
MODIFICATIONS
NO
REQ.
RESPONSE
(A, B, C, D,
E)
Comments
Pg. #
where
additio
nal
informa
tion
can be
found
General / All Components
1. Provide, as a deliverable, a
comprehensive system that meets all of
the functional requirements that will be
provided to SBAC member states with
irrevocable or open-license source
agreement.
PT
FT
2. General requirements: System must be
able to upload file types as required in
the SBAC IT Systems Architecture
(Appendix C) for all components.
PT
FT
Portal
3. System must provide a SSO entry point
for all SBAC applications. See SBAC
IT Systems Architecture (Appendix C).
PT
FT
Shared Services.
4. System must include all of the shared
services components identified in
Figure 4.3 (e.g., program management,
core standards) of the SBAC IT
Systems Architecture (Appendix C).
PT
FT
5. System must be able to support
additional applications or shared
services that may be added at a later
date.
FT
Test Authoring
6. Test Authoring Component meets
requirements detailed in the SBAC IT
Systems Architecture (Appendix C).
FT
Test Packager
7. Test Packager Component meets
requirements detailed in the SBAC IT
Systems Architecture (Appendix C).
FT
Test Spec Bank
8. Test Spec Bank Component meets
requirements detailed in the SBAC IT
Systems Architecture (Appendix C).
FT
Test Item Bank
9. Test Item Bank Component meets
requirements detailed in the SBAC IT
Systems Architecture (Appendix C).
FT
6
ID #
Requirement
Field
YES
Test (FT
or Pilot
Test
(PT)
YES, WITH
MODIFICATIONS
NO
REQ.
RESPONSE
(A, B, C, D,
E)
Comments
Pg. #
where
additio
nal
informa
tion
can be
found
Adaptive Test Engine
10. System must be able to load all test
algorithms for each respective test as
defined by the CONTRACTORS for
RFPs 5, 9 and 20.
FT
11. System must track student item
presentment such that each student
can take the same type of test more
than once without receiving any
duplicate items.
FT
12. System must be able to calculate
preliminary scores using the raw scores
produced from the machine scoring
component and associated item score
statistics from the Item Authoring and
Pool application.
FT
Scoring
a.
Humanb.
Scoring
13. System must able to deliver rubrics to
the Human Scoring Component and be
able to transfer data received to the
Data Warehouse. Please refer to
System Architecture Figure 4.3 for an
illustration of this data transfer.
PT
FT
Machine Scoring
14. System must be able to score objective
test items and transfer the data back to
the Data Warehouse.
PT
FT
15. System must be able to insert unscored
items into tests and log them
accordingly for research purposes.
PT
FT
Distributed Scoring
16. System must be able to transfer
student responses to, and from, the
Distributed Scoring component, and
relay data back to the Data
Warehouse. Please refer to the System
Architecture in Figure 4.3 for an
illustration of this data transfer.
PT
FT
Interim Scoring
17. System must allow teachers to hand
score a constructed-response item that
may also be scored by AI.
FT
AI Scoring
7
ID #
Requirement
18. System must be able to support the AI
Scoring component, which will include
transferring student responses to the
component and relaying data back to
that component. Please refer to the
System Architecture in Figure 4.3 for
an illustration of this data transfer.
Field
YES
Test (FT
or Pilot
Test
(PT)
YES, WITH
MODIFICATIONS
NO
REQ.
RESPONSE
(A, B, C, D,
E)
Comments
Pg. #
where
additio
nal
informa
tion
can be
found
PT
FT
Test Administration
19. System functionality can be granted or
restricted to user groups or entities
including SBAC, state, district, school,
and building level. Groups and entities
can be defined in a flexible, tiered
manner with no preset limit to tiers.
PT
FT
20. System must allow administrative users
to add, modify, or delete state accounts
and information.
PT
FT
21. System must allow administrative users
to define groups and assign
permissions / constraints / functions.
PT
FT
22. System must allow select
administrative users to view aggregate
test information by course, such as
number of tests scheduled (by date),
number of tests being administered
(real-time), number of tests completed,
and number of scoreable tests
completed.
PT
FT
23. System must allow administrative users
to assign testing windows for
Summative and Interim tests.
PT
FT
24. System must allow administrative users
to register each school/district for
testing.
PT
FT
25. System must allow administrative users
to configure various form distribution
plans that result in school districts
automatically receiving the appropriate
assignment of test forms for given test
administrations.
PT
FT
26. System must allow administrative users
to assign testing windows for Interim
tests.
PT
FT
27. System must allow administrative users
to add, modify, or delete teacher and
test administrator accounts and
information.
PT
FT
8
ID #
Requirement
Field
YES
Test (FT
or Pilot
Test
(PT)
28. System must allow administrative users
to print and/or e-mail teacher user ID
and password letters.
PT
FT
29. System must allow administrative users
to add and edit school information (e.g.
site code, school name).
PT
FT
30. System must have a robust scheduling
tool to maximize school testing
capacity.
PT
FT
31. System must feature the ability to
search system for users by assigned
identifier.
PT
FT
32. System must feature the ability for
administrative users to add, modify, or
delete school test coordinator accounts
and information.
PT
FT
33. System must allow administrative users
to select specific strands for use within
a test (i.e. performance tasks,
research-based and Interim
assessments).
PT
FT
34. System must allow administrative users
to assign students to a class.
PT
FT
35. System must allow administrative users
to view and/or print class and student
rosters.
PT
FT
36. System must allow administrative users
to monitor the registration.
PT
FT
37. System must allow administrative users
to add, edit, or delete students.
PT
FT
38. System must allow administrative users
to limit testing session length or item
response times for Interim tests.
PT
FT
39. System must allow administrative users
to assign accommodations to students
as appropriate.
PT
FT
40. System must provide tools, including
but not limited to calculator, spell
check, graphing tools, visually based
dictionary, dictionary, thesaurus, text
pop out, measurement tools, electronic
annotation, formula charts, and sketch
pages for Summative, Interim, and
practice tests.
PT
FT
41. System must provide accommodations
for Summative, Interim, and practice
tests.
PT
FT
YES, WITH
MODIFICATIONS
NO
REQ.
RESPONSE
(A, B, C, D,
E)
Comments
Pg. #
where
additio
nal
informa
tion
can be
found
9
ID #
Requirement
Field
YES
Test (FT
or Pilot
Test
(PT)
42. System must support selectedresponse, constructed response,
technology-enhanced items,
performance tasks, and other item
types as defined in the Proposed TEI
Specifications (See Appendix B).
PT
FT
43. System must allow administrative users
to administer a practice test to
students. The practice test must
contain all the functionalities,
accommodations and tools (e.g.
calculator, spell check, graphing tools,
visually based dictionary, dictionary,
thesaurus, text pop out, measurement
tools, electronic annotation, formula
charts, and sketch pads) and range of
Items (e.g. TEIs) that will be available
during the Summative and Interim
tests.
PT
FT
YES, WITH
MODIFICATIONS
NO
REQ.
RESPONSE
(A, B, C, D,
E)
Comments
Pg. #
where
additio
nal
informa
tion
can be
found
44. System must enable students to be
clustered according to classes,
programs, or other groupings for the
purposes of scheduling, monitoring,
reporting.
45. System must allow administrative users
to assign new classes to a teacher.
PT
FT
46. System must allow administrative users
to delete a teacher’s class(es).
PT
FT
47. System must allow administrative users
to access reports detailing system
usage by school and district.
PT
FT
48. System must allow administrative users
to start, stop and resume student test
sessions.
PT
FT
49. System must allow administrative users
to have student level opportunities
control (e.g. provide a second
opportunity to test a student, or give a
specific test to a specific student).
PT
FT
50. System must save student responses
when a test is stopped, paused or
suspended. When the test is restarted,
previously saved student responses
can be retrieved, or removed.
PT
FT
51. System must allow administrative users
to accurately match student data in the
event that it is necessary for a student
to restart the test.
PT
FT
10
ID #
Requirement
Field
YES
Test (FT
or Pilot
Test
(PT)
52. System must have the ability to allow
teachers to administer practice tests
and to collect only specified data.
PT
FT
53. System must have the ability for
administrative users to add and remove
questions for practice tests.
PT
FT
54. System must allow administrative users
to access a report of students tested
and not tested.
PT
FT
55. System must allow test administrators
to select items/tasks for performance
and research-based tests.
PT
FT
56. System must allow test administrator to
complete an electronic Group
Information Sheet to determine how
student results will be returned to the
district (by class, school, district).
PT
FT
57. System must allow administrative users
to view and edit student demographic
information.
PT
FT
YES, WITH
MODIFICATIONS
NO
REQ.
RESPONSE
(A, B, C, D,
E)
Comments
Pg. #
where
additio
nal
informa
tion
can be
found
Test Delivery System
58. System is able to securely deliver
SBAC English language arts and
mathematics tests to students and
proctors.
PT
FT
59. System provides ability to add
additional tests, specifying subject and
grade availability (e.g., science), for
secure delivery to students and
proctors.
FT
60. System is able to collect and store
individual student response times for
each question.
PT
FT
61. System allows a student to review their
answers for some sections or sets of
questions before moving on to the next
section or completing the exam.
PT
FT
62. System is able to check student
computers to ensure that they have the
components necessary to operate the
test.
PT
FT
63. System has the ability to deliver the
test software securely to individual
student workstations / devices with
minimal total cost of ownership and
stability that is buffered against
software updates.
PT
FT
11
ID #
Requirement
Field
YES
Test (FT
or Pilot
Test
(PT)
64. System will be able to deliver TEIs as
defined in Proposed TEI Specifications
(see Appendix B)
PT
FT
65. System supports items/tasks that can
accommodate students with disabilities
(e.g. items/tasks including Sign
Language, refreshable Braille, text-tospeech tags, text magnifying software,
and speech-to-text tags). Braille
support must include contracted, uncontracted and Nemeth Braille.
PT
FT
66. System supports multimedia and
interactive items that are written in
HTML 4 with HTML 5 extensions.
PT
FT
YES, WITH
MODIFICATIONS
NO
REQ.
RESPONSE
(A, B, C, D,
E)
Comments
Pg. #
where
additio
nal
informa
tion
can be
found
67. System automatically logs out after a
period of no activity. For certain users
(e.g. students with accommodations
needs), system can restart after a
period of no activity, and resume the
session where it left off. Activity timing
must be variable based on student
profile and activity required must be
minimal so as not to interfere with
students’ testing.
68. System has the ability to upload and
conduct format integrity checks on files
as necessary to support test
registration, interim assessment
scoring and possible extensions of the
summative assessment.
PT
FT
69. System supports electronic annotation
of items/tasks, and note-taking, as a
part of the item response. Annotations
and note-taking must persist and be
available when a student reviews the
item. For the practice test, the
persistence would last only for the
duration of the current session.
PT
FT
70. System allows test administrators to
print items, stimuli, and necessary
resources to support system
accessibility requirements, with
appropriate security procedures.
PT
FT
71. System allows a student to review and
change their answers according to
specifications identified in RFPs: 5, 9,
and 20.
PT
FT
72. System support tools being tagged to
specific items.
PT
FT
12
ID #
Requirement
Field
YES
Test (FT
or Pilot
Test
(PT)
73. System supports QTI with APIP
extensions protocols.
PT
FT
74. System supports manipulatives (e.g.,
calculator, spell check, graphing tools,
visually based dictionary, dictionary,
thesaurus, text pop out, measurement
tools, electronic annotation, formula
charts, and sketch pads) being tagged
to specific items/tasks during the test.
PT
FT
75. System is able to administer a practice
test with all the functionality of a real
test.
PT
FT
76. System supports tutorials being tagged
to items/tasks, which the student can
access during the practice test.
PT
FT
77. System is able to provide tools /
tutorials to help students during the test
event (e.g. TEI item manipulations)
within the testing environment.
PT
FT
78. System is able to deliver items/tasks
that have been translated into other
foreign languages including languages
that use ASCII- and non-ASCII-based
characters.
PT
FT
79. System is able to function with nonEnglish keyboards.
PT
FT
80. System is capable of displaying
copyrights and attributions.
PT
FT
YES, WITH
MODIFICATIONS
NO
REQ.
RESPONSE
(A, B, C, D,
E)
Comments
Pg. #
where
additio
nal
informa
tion
can be
found
Response Data Store
81. System captures student’s response
data and is available for auditing (e.g.,
key stroke, deleting, and response
deletion).
FT
82. System is able to capture and deliver to
the Response Data store for
psychometric use as specified in RFPs
5, 9, and 20.
FT
83. System includes a suite of alerts to the
test administrator and Consortium
delegates if there appears to be a
testing irregularity.
PT
FT
Test Registration
84. System has the ongoing functionality to
batch upload data from the state SIS
systems using CEDS standards so that
they can gather the student information
PT
FT
13
ID #
Requirement
Field
YES
Test (FT
or Pilot
Test
(PT)
YES, WITH
MODIFICATIONS
NO
REQ.
RESPONSE
(A, B, C, D,
E)
Comments
Pg. #
where
additio
nal
informa
tion
can be
found
and accessibility profile, used by the
Test Administration component.
85. System enables interoperability with
LEA’s and state SIS systems, based
upon specifications defined in the
SBAC IT Systems Architecture
(Appendix C). System automatically
generates and maintains internal
SBAC identifiers.
PT
FT
86. System must feature the ability for
administrative users to hand-enter
student records prior to, or at the time
of testing (when batch upload
functionality is not available).
FT
Reporting
87. System will provide the ability (on/off
system proctor preference) to display
immediate preliminary score feedback
to students at the conclusion of the
test.
PT
FT
Data Warehouse
88. System supports the transfer of scores
from the Test Delivery System to the
Data Warehouse Component.
PT
FT
14
ID #
Requirement
YES
YES, WITH
MODIFICATIONS
NO
REQ.
RESPONSE
(A, B, C, D,
E)
COMMENTS
Pg. #
where
addition
al
informat
ion can
be
found
Additional SBAC Requirements
Systems Architecture
89.
The proposed system shall operate efficiently
with the SBAC’s minimum software and
hardware specifications. SBAC’s minimum
specs will be posted on SBAC’s website in
March.
90.
System is fully self-contained and capable of
being operated by SBAC with no dependency
on Vendor services for its routine operation.
Programming Standards
91.
System supports multi-tenancy.
92.
The Vendor uses coding standards and code
reviews to ensure that the development team
follows these coding guidelines to facilitate the
readability of the source code and to make
software maintenance easier.
93.
System is able to support cloud-based hosting
services
94.
95.
System’s inter-component communication uses
current standards (e.g. SIF, IMS etc.) that
support the SBAC IT System Architecture (see
Appendix C).
System supports the Plugin Binary Transport,
which requires an abstract API to be developed
that components can call with a consistent
interface. The API uses the data format
described by the accepted standard
for that assets domain (i.e. item format, student
information, and student response, etc.).
Security/Access Control
96.
System
ensures that the integrity and
.
confidentiality of data is protected by
safeguards to prevent release of information
without proper consent.
97.
System provides security for all system
components (see Figure 4.3) at database,
workstation, and individual operator levels.
98.
System provides secure access control based
upon single unique user login.
99.
System provides secure unique identifiers for all
users.
100.
System checks each user’s access privileges at
login, and automatically disables or enables
15
Requirement
ID #
YES
YES, WITH
MODIFICATIONS
NO
REQ.
RESPONSE
(A, B, C, D,
E)
COMMENTS
Pg. #
where
addition
al
informat
ion can
be
found
client functions (in real time) based upon the
user’s profile.
101.
System provides federated identity
management capability.
102.
System meets ISO 27001 Standards.
Security/Password Controls
103.
System provides an option to require user
passwords to be automatically prompted for
change after a configurable, defined period has
passed, such as 30, 60, or 90 days.
104.
System provides the option to disable user IDs
for a configurable time frame after a specified
number (configurable) of consecutive invalid
login attempts.
105.
System enters passwords in a non-display field.
106.
System encrypts passwords when they are
routed over the network.
107.
System provides a method of secure login for
students and adults and comprehensive
security for all system components.
Security/Activity Logging
108.
System logs unauthorized access attempts by
date, time, user ID, device, and location.
109.
System maintains an audit trail of all security
maintenance performed by date, time, user ID,
device, and location, with easy access to
information.
Edit and Validation Control
110.
System includes comprehensive field edits to
prevent incomplete or incorrect data from
entering the system.
Environment
111.
For any hosting proposals, the Vendor provides
effective physical security measures for all
proposed equipment sites, all processing and
operations areas, and secured storage areas.
112.
The Vendor has a current annual security rating
from an independent third party auditing firm
that certifies that the Vendor meets federal and
Consortium guidelines for the handling of
confidential data.
16
Requirement
ID #
YES
YES, WITH
MODIFICATIONS
NO
REQ.
RESPONSE
(A, B, C, D,
E)
COMMENTS
Pg. #
where
addition
al
informat
ion can
be
found
System Auditing
113.
Sufficient audits must be available to identify
the source and time of data changes related to
system components.
114.
System must ensure that it logs system activity
necessary to monitor and debug the system in
a timely and accurate manner.
Error Handling
115.
System must ensure that all errors are written
to an error log.
116.
Errors to the end user must be communicated
in plain language with an explanation of
required action.
117.
System must allow for a system administrator to
view, filter, sort, and search the error log.
Backup and Recovery
118.
The application will support recoverability using
commonly available and industry standard
backup applications and approaches, including
the ability to:
119.

120.

121.

provide point-in-time recovery of data to
the last completed transaction.
allow for continued use of the system
during backup.
provide a complete backup and recovery
process for all database tables and system
files.
122.
The backup and archival features of the system
proposed can be initiated automatically or by
manual request.
123.
System uses real-time replication so that testing
is not interrupted during fail-over.
124.
System is able to route data to multiple data
centers distributed across the United States
Availability
125.
System features 24-hour availability on
weekdays with advance notification of
down/times.
17