ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Vendor ResponseComments
2
System Architecture:
3
The system is 100% web-based allowing the entire system to be accessed via a web browser.
4
The system is one fully integrated system not separate systems linked together.
5
The system must support the use of standard industry browsers (Chrome Firefox, Safari) for all transactions and online via District-wide area network, via internet connections, via Microsoft Windows workstations, via Apple MAC workstations
6
The system should not require specific plug-ins for browsers to utilize its core functions
7
Data is only entered once in the system and then is available in real time throughout the entire District. For example: Addresses and parent records are not duplicated within the system, rather they are entered once and then linked to the appropriate students.
8
The system is deployed using a District-wide approach so that all data across the District is stored in a single SQL database with real time update for all online transactions.
9
The system supports various methodologies for movement from screen to screen within the application, including but not limited to: Traditional Menu-Based Access, Wizards or work flow based processing, integrated quick access to most common next screen functions.
10
The system provides the ability to establish new data fields.
11
A comprehensive data dictionary complete with database schema and data mappings is provided.
12
If new customizations are supported, new customizations will survive all new application releases.
13
Custom data fields may be included on existing screens.
14
User has control of custom field types such as numeric, date, check box and text fields.
15
User has control over field definitions including field size.
16
User has control over presentation sequence on screen.
17
User defined fields may be marked as required for data entry purposes.
18
Users may enter lists of valid values for pop-up selection during data entry.
19
User defined fields are available for reporting purposes.
20
Interactive help text may be defined with new data fields.
21
The system provides on screen indications of students with alerts or other notations on file.
22
The system has specialized teacher-level access that maintains security specifically to functions that may be performed by teachers.
23
The system should allow full school level control of parameters managing operational policies. This includes parameters such as attendance, scheduling and grading. Schools should not have to share processing rules
24
The system is fully normalized, integrated and real time. For example, the updating of any data element is done only once, and is then reflected throughout all applications.
25
The application software should be fully normalized for input purposes. All data, including family, contact and address data should be entered only a single time.
26
The system supports real-time registration of students at either the school or District level.
27
The system supports online registration of students.
28
The system allows withdrawn student records to be immediately available for record transfer to other schools.
29
The system maintains an unlimited number of school years of history for all student activity.
30
All modules within an application program should provide a common look and feel in command structure, navigation, functionality, etc.
31
The system must accurately handle attempts by two or more users to update the same record at the same time, but must not restrict any number of users to access the same record concurrently.
32
Error messages are easily comprehensible by the user and are displayed in an online manner.
33
The system has the capability for displaying pictures of students.
34
The system provides an on-line pull-down list of all valid values for each validated field.
35
The system must include non-proprietary open database connectivity (ODBC or JDBC) to allow for interface access between database systems and different marketplace tools.
36
The system should be capable of supporting multiple views of the database for different sets of users. (For example, limiting specific views to admins and. teachers)
37
The application provides user managed support to export data to other systems in a variety of formats such as: ODBC, MS RTF, standard text, MS Excel, XML, CSV, etc.
38
The application should provide a fully integrated query capability which uses a graphical interface employing such functions as point and click, drag and drop, graphical displays, etc.
39
The system accommodates "school within a school."
40
The system has built in spell check abilities in all free writing areas.
41
Security Architecture:
42
The application must support a broad set of security policies to manage general security settings. Security policy must be able to be varied for administrative staff, by teacher and for external access by parents/students.
43
Security policies must allow the District to determine the length of the passwords.
44
Security policies must allow for the ability to store the user password in an encrypted format.
45
Security policies support active directory.
46
Security policies support system generation of a random password that may be used for a single login by users prior to their setting their own password.
47
Security policies prevent all administrative and support staff from seeing a user’s password.
48
The system supports role based security which includes the ability to manage the screens or pages that users in a specific role may access.
49
The system supports role based security which includes the ability to manage fields that users in a specific role may access.
50
The system supports role based security which includes the ability to manage the functions (add, change, delete and inquire) on each screen that a user in a role may perform on each screen that may be accessed.
51
The system fully supports the definition of user groups, allowing controlled access to various school data by user group.
52
The system fully supports the definition of user groups, allowing any number of users to be assigned to a user group
53
The system allows a user to be assigned to multiple user groups and roles when appropriate.
54
The security system should have the ability to automatically sign off dormant users from the system after a user defined time period.
55
The system should maintain a record of the last user time that each data record is changed. This record must include at least the user making the change as well as the time and date of the change.
56
The system has the ability to restore changed data.
57
Security is based on unique usernames and passwords.
58
System supports field level security.
59
The system provides teachers with access to student records for only the students enrolled in their classes.
60
The system security restricts school site users from changing District-defined tables.
61
The system provides access to users and the ability to define if that user can add, change, delete, or have no access to specific screens.
62
The system provides the ability to update user security available online.
63
The system provides the ability to allow District control of District identified tables.
64
The system provides the ability to use an external authentication system such as Active Directory.
65
The system provides the ability to define user/group/school level profiles across schools/District.
66
The user session will timeout after a specified period of inactivity.
67
The system displays a warning message before an automatic log off due to inactivity.
68
The system has received the iKeepSafe recognition.
69
The system provides the ability to produce and print auditor reports of specified audited field information.
70
Capacity Requirements:
71
The system supports an unlimited number of fields within the system (including user defined fields).
72
The system supports an unlimited number of tables.
73
The system supports an unlimited number of entries within a table.
74
The system supports an unlimited number of screens.
75
The system supports an unlimited number of user defined reports.
76
The system supports an unlimited number of students.
77
The system supports an unlimited number of schools and support departments.
78
The system supports an unlimited number of simultaneous users on the system.
79
The system supports an unlimited number of registered users.
80
The system supports an unlimited number of user groups.
81
The SIS provider has current customers using the current version of the system being proposed in this RFP, with a student population larger than 30,000 students, K-12, and alternative sites.
82
Calendar Requirements:
83
The system supports unique calendars for each school.
84
The system supports unique calendars for each track within a school.
85
Calendars must be interactively used by all functions throughout the student system.
86
The system supports the ability to designate special days (inclement weather days for example) for each calendar.
87
The system supports year-round calendars.
88
The system supports user defined calendar day codes, such as instructional day and non-instructional day.
89
The system maintains all prior year calendars indefinitely.
90
End of Year/New Year Processing Requirements:
91
The system supports ending enrollments for students individually and in mass.
92
An End Date can be mass assigned.
93
An End Status can be mass assigned.
94
A Diploma Date can be mass assigned.
95
The system supports the automatic promotion of students to the next grade level.
96
The system supports the automatic enrollment of students into the next school based upon student zoning information. Additionally, the system supports the automatic enrollment of students into the same school regardless of zoning information. An example would be students on granted variances or school choice selections if the school knows the student will be returning the following year. Also has the ability to create rules on how and where students should be rolled over (i.e., students on IDT will return to same school, whereas students on Overflow will go back to school based upon student zoning information.)
97
Students can be excluded from being automatically promoted based upon District-defined criteria, for example, if a student has been flagged to be "retained".
98
The system supports the automatic rolling forward of scheduling data, including calendars, term schedules, period schedules, grade levels, courses, sections with section placement, teacher assignments, room assignments, grading credits, scheduling rules, attendance codes, scheduling teams.
99
Document Management:
100
The system provides the ability to upload District forms such as permission slips, court papers, and health forms into the application.