Project Description & Software Specification
SourceForge Project Page


This is a software specification for the development of a modular, district-level Student Information System. This plan covers development of a core database and web-based interfaces for student/family data, and staff data. In addition, this specification includes the first module, a homeroom-based attendance.  This version of the plan assumes that work begins with a partially completed project (60%).

General Information

This project shall implement a central database for all existing student records and provide secure, web-based means to manipulate and view those records. The project will be designed for use at a school district level, such that multiple schools, student transfers among schools/buildings/homerooms, and school-based reports are possible and easy to implement. The web-based user interface shall be simple, uncluttered, and functional.

Collegium Charter School shall retain all intellectual property rights for software developed during this project and shall license the software to the public under the GNU General Public License.

Design Goals

theSIS shall be designed and coded under the following guidelines:


The project shall be designed with four levels of security utilizing PostgreSQL users and groups:

Access to forms, menu items, buttons, and other screen items will be rendered as appropriate for the security level of each logged in user. Apache should probably be configured to only allow https communications for all theSIS users.


The project shall be constructed in a modular manner, with the student information located in the core component. A single module, attendance, is included in the project. The project will be designed to allow easy addition of other modules in the future, including student health records, grade/report cards, etc. System configuration will include a mechanism to enable or disable individual modules.  

The database schema shall be described and documented to allow other developers to easily add features and modules to the project. All scripts shall be liberally commented to allow other developers to understand and modify code.

User interface text will be located in separate language tables (or files, if necessary), to facilitate simple multi-language implementations and modifications without making code changes. Thus, UI text is entirely separate and distinct from PHP, and text items for screen display are fetched as needed rather than coded in-line.

Where possible, code should be written so as not to exclude porting to other databases, particularly MySQL, though design should utilize features available in PostgreSQL such as transactions where appropriate to enhance stability and reliability.


Student and staff photographs are an integral and necessary part of theSIS. For security purposes, it is necessary to implement theSIS with photographs stored in the database as secured object fields. Otherwise, they are flat files easily harvested from a web server. The application should be capable of uploading a photograph from the user's local filesystem and incorporating it into the database. It should also be possible to strictly define the size of the photos displayed in the browser.

User Interface

The user interface must be intuitive and make use of links wherever possible (mailto, other views, etc.). The navigation bar must offer instant access to major functional areas. Enumerated types will be drawn from tables defined by the superuser. High-end graphics design is not a requirement for this initial version of the project. Simple text links in the navigation frame are adequate. We are interested mainly in functionality and can replace basic HTML setup with nicer graphics at a later date. While the interface should be intuitive, uncluttered, and businesslike, it does not have to be "pretty." A frames-based approach is desired for the user interface. Three frames will be used:

Core Component

The core component of theSIS shall include the database with all district information, student records, student photos, and staff/homeroom assignments, a mechanism to load comma-separated-value data and photos (or photo file names for web server retrival) into the database, and a web-based user interface to enter additional data and to view/manipulate existing data, freeform query capabilities, and reports. The core component will maintain a unique identifier for students, which will become the student's identification number. This identifier will not be related to any student data.

The core component will allow teachers to view student data by room (their assigned homeroom by default) or by specific student. The homeroom page will offer teachers a table of thumbnail student photos of all students assigned to her homeroom. This table will be static, with photos on the left and basic contact information on the right, with one student per row.  The intent is to offer the teacher a single-page view of all necessary contact information about her students. Displayed information will include address, parents/guardians, email addresses, teacher notes, etc. An edit button will provide the teacher access to the notes field. She will not have write access to any other student data in the core component.

The core component must provide accurate data and immediate access to comply with Pennsylvania Department of Education requirements on reporting, in accordance with these forms:

The core component shall include an automated cron-based mechanism to dump all configuration, security, user, and student data to an external file for daily backup. The backup data must give root the ability to completely restore the database, user account and group information, and all theSIS functionality after reinstallation of theSIS script files of correct version.

The core component will offer views/screens by student and adult (“manage students”, “manage domiciles”, “manage adults”). Domiciles and adults listed in the student view will be links to their respective views. Students listed in the domicile and adult views will be links to their respective views. That is, the user must be able to easily click their way through the students' adult and domicile relationships without navigating menus or starting at the top of the hierarchy. Adult views must show all students associated with the adult. Domicile views must show all students associated with the domicile.

The project is designed from the school district point of view.   A top-level district is defined. Schools are assigned to the top-level district. Buildings are assigned to schools. Homerooms are assigned to buildings. Students and teachers are both assigned to homerooms. Views showing students or homerooms should also show the appropriate teacher, and vice versa.

All configuration information is stored in the database.

Attendance Module

The Attendance module will be used both by Teachers and by office staff. Upon login to theSIS in the morning, teachers will start the attendance function where they will have a table of student thumbnail photos. Unlike the student information table in the core component, this table will fit in a single data frame. Each photo will have beside it a radio-button set, by default set to P (present). For those students who are absent, the teacher will select A (absent). When all missing students are marked, she will press a submit button, after which the table will be refreshed with a red border around each missing student photo. The teacher will be able to amend this attendance view until a set attendance deadline (say, 8:45AM).

The attendance table will be updated with a new timestamped entry for the student.

Each thumbnail photo in all teacher views shall be a hyperlink to the student's detailed information, attendance record (query to the attendance table) and contact information.

After the attendance deadline, attendance data for the day will be changed by administrator-level personnel only. A new screen, similar to the table presented to teachers during the attendance function, will be available to administrators. This screen will show the thumbnail photos of all students reported absent by teachers, and will include a different radio-button set:

Students arriving late will be marked tardy by administrative staff only, not by teachers. All daily attendance exceptions (tardy & absent, and excused status) will be part of the student's permanent record and will appear on various reports.

After the deadline, all teachers will have access to all homeroom attendance records in a static view much like the attendance screen with red borders around pictures, so they can see which students are not in school and thus can be prepared for missing students all day.

Before and after the deadline, administrators will also have a report showing which classroom teachers have not yet submitted attendance for the morning, to allow administrators to call and remind them to report.

The attendance system must provide accurate data and immediate access to comply with Pennsylvania Department of Education requirements on reporting, in accordance with these forms:

PDE forms and their instructions are available here:


Enumeration tables will be used wherever possible to make data consistent across the DB, allowing meaningful queries (for US states or ethnicity, for example).  See schema dump for progress to date. Enumeration tables will be edited solely by the superuser.


As stated earlier, all variable data in theSIS, including configuration, photographs, and data are to be stored in the database. Only PHP and HTML are to be stored in flat files on the server. The core component features these ideas:

The homeroom attendance module includes these additional items:

User Screens & Information

All HTML output will be called "screens" for purposes of this document. Each bullet item below lists a screen name and description. Screens are genreated using the navigation frame widgets.

Once users are logged in, they will be presented with the frames-based user screen, populated according to the user's access priviledges as defined by the security level assigned to the user.

Viewers (all users)

This is the lowest security level.

Teacher Screens

All "viewers" screens, plus:

Administrator Screens/Capabilities

All "Teacher" plus:

Root Screens/Capabilities

Some of these may be combined into overall configuration screens, as appropriate. All "Administrator" plus:

Reports & Queries

Reports are to be available at the administrator and root security levels. An initial group of reports are defined here. Reports will be rendered in PDF format for viewing in the browser, and printing if desired. The following definitions are assumed:

Standard Reports

Standard Queries

Ad-Hoc Query Form

A Query Form will be provided to users with teacher-level access and above to create their own ad-hoc queries. This form will offer drop-down lists for enumerated types and open fields to match database fields. The result of the Submit button in the form will be a SQL statement and the results viewed in the Display Frame.

Contact Information

Jeff Dean
Director of Technology
Collegium Charter School
West Chester, PA, USA, 19380
610-738-6940 x131