Study Abroad Logistics Management System:
Evolution 3

Tyler Bletsch, Duke University
March 2, 2025

Introduction and Use Cases

Your client, Hypothetical City College (HCC), is a public community college. They offer a variety of study abroad opportunities, including faculty-led study abroad. Unlike direct-enrollment and exchange programs, faculty-led study abroad programs are fully administered by HCC. They currently use a mishmash of emails, google forms, and spreadsheets to allow students to apply, process applications, and keep track of enrolled students enjoying programs around the world. They would like a unified system to replace these highly manual procedures to allow for less human error, greater efficiency, easier communication with students, and insights into trends over time.

This system will serve the following use cases:

Definitions

  1. Implementor: Refers to you, the software developer. Items described as “at the implementor's discretion” or similar indicate free choices. However, “free choice” does not mean all choices are of equal merit; your overriding goal must be software quality.
  2. Unique: Requirements may describe a given field (or combination of fields) as unique. This means that there may be at most one record with that value (or combination of values). Attempts to violate uniqueness should generate an error, unless otherwise specified in the requirements.
  3. Extra credit: Some requirements are left up to the implementor's discretion and are labeled “extra credit”. Naturally, you don't have to do these. Further, you can choose when to do them: you will receive the awarded extra credit points in just the evolution in which the feature first appears. Exact values of extra credit are not given, but as with all credit, will be commensurate with the scope of work anticipated.
  4. User: An account able to login and access the system. Users may be local (self-registered) or logged in via Single Sign-on (SSO). SSO users are recognized by the system upon first login via Duke NetID. The user with username "admin" is the special, permanent administrator of the system. When shown as a reference in the system (e.g. for faculty leads), users should be displayed as "<Display Name> (<Username>)" (e.g., "Tyler Bletsch (tkb13)"). Defined by fields:
    • Username: An alphanumeric user name. Unique. Required. For SSO users, this is the Duke NetID. Usernames for SSO and local users are in the same namespace, so the uniqueness constraint is enforced between them: e.g., if an SSO user of a given username has previously logged in, then a local user by that name cannot be registered, and if a local user of a given username has been registered, then an SSO user of the same username cannot login for the first time.
    • Display name: The real name of the user (e.g. "Tyler Bletsch"). For the special admin local user, this is "Administrator". For SSO users, this comes from the central authentication server. Required.
    • Password: The password required to login; stored securely (req 1.4). Required for local users, but unspecified for SSO users.
    • Email address: An email address associated with the user. Required. For SSO users, this comes from the central authentication server.
    • Administrator permission: A Boolean flag indicating if this user has administrator privilege. Required. For the special admin local user, this is always true.
    • Role(s): Indicates level of access. A user may have zero or more of the following roles: {administrator, reviewer, faculty}. For the special admin local user, this is always {administrator, faculty}. Users with none of the listed roles are regarded as student accounts. Required.
  5. Student: A user with no administrator, reviewer, or faculty privilege roles.
  6. Program: A faculty-led study abroad program administered by HCC. A program is defined by the fields:
    • Title: A short name for the program (<80 characters). Required.
    • Year and semester: A reference to a year and semester (Fall, Spring, or Summer) that credit is applied for participants in this program. Displayed as e.g. "2025 Spring". While in many cases this could be derived from start/end dates, it is input separately because some programs span semester boundaries. Required.
    • Faculty lead(s): One or more references to existing user accounts for the faculty members leading this program, such users must be administrators have the faculty role. Users listed as faculty leads for a program gives them access to review and manage student records for that specific program. Therefore, if a requirement says a "faculty lead" can take an action, this is referring to a faculty lead for the program in question, not just any user listed as faculty. Required.
    • Description: A multi-paragraph description of the program written in a manner to entice students as well as communicate all details and requirements. Required.
    • Key dates: The program is governed by the following dates. The values of these dates must be monotonically increasing in the order listed below (e.g., start date cannot be after end date, but they may potentially be equal).
      • Application open date: The system will only accept applications on or after this date. The program is still visible in this system before this date, however. Required.
      • Application deadline: The system will only accept new applications or changes to applications on or before this date. Required.
      • Essential document deadline: Students must submit essential documents (see definition 7) by this date. Note: this deadline is a "soft" deadline, and the system will accept documents submitted after it. Required.
      • Start date: The date on which the actual program starts. Required.
      • End date: The date on which the actual program ends. Required.
    • Questionnaire: A set of one or more questions to be asked of applicants to this program. Each question is simply defined as a one-line string that will serve as a text prompt during the application process. During program creation, this defaults to the list from Appendix A.
  7. Application: All records relating to a student's connection to a particular program. Consists of:
    • Basic facts: Provided by the student. These are:
      • Date of birth: Date of birth of the student. To prevent errors, must be at least 10 years before today. Required.
      • GPA: A decimal number between 0 and 4, inclusive. Required.
      • Major: A short text field indicating student's academic major. Required.
    • Questionnaire answers: Multi-paragraph answers to the questions listed in Appendix A configured for this program. All are required.
    • Confidential notes: Zero or more notes added by an administrator or other user with appropriate permission. These notes will only be visible to administrators or other user with appropriate permission, never to students. Each is defined by fields:
      • Author: A reference to the user account who authored the note. Required.
      • Timestamp: The date and time at which the note was saved. Required.
      • Content: A multi-paragraph text field written by the author. Required.
    • Essential documents: A set of documents that the college requires all students to have completed prior to participating in a program. Blank versions of these forms are available here. These include:
      • Assumption of risk form: A document waiving HCC's liability for student participation in the program. The student must sign this to participate.
      • Acknowledgement of the code of conduct: A document reviewing the code of conduct, and attesting to student's understanding and commitment to abide by same. The student must sign this to participate.
      • Housing questionnaire: A set of questions about housing preferences to be reviewed by the faculty lead(s) to help with assigning housing. The student must fill this out.
      • Medical/health history and immunization records: A high-level summary of health status and attestation regarding immunizations. This document in particular is covered by HIPAA (definition 11). The student must fill out and sign this.
    • Letters of recommendation: A set of zero or more requests for letters of recommendation, possibly with responses from the letter writers. Letter writers need not have an account on the system. Each is defined by fields:
      • Name: Part of the student's request. The full name of the requested letter writer. Required when a student makes a letter request.
      • Email address: Part of the student's request. The email address of the requested letter writer. Required when a student makes a letter request.
      • Uploaded letter: Part of the writer's response. The actual letter of recommendation, uploaded in PDF format. Required when a writer fulfills a letter request.
      • Letter timestamp: Part of the writer's response. The date/time at which the uploaded letter was received. Recorded when a writer fulfills a letter request.
      As a practical matter, not all programs will require letters of recommendation, and those that do will simply say so in the description — as far as the system is concerned, letters of recommendation are always optional.
  8. Application status: Captures the state of a student's relationship to a program. Possible values include:
    • Applied: Student has submitted basic application materials
    • Eligible: Student's application has been reviewed by an administrator and they meet all basic pre-requisites; the student next needs to interview with a faculty lead
    • Approved: Student has completed their interview with a faculty lead for the program; the student next needs to submit all essential documents (tracked by the system) and payments (not tracked by the system)
    • Enrolled: Student has submitted the essential documents and payment and is formally enrolled in the program
    • Canceled: An administrator has removed the student from the program
    • Withdrawn: A student has ended their application/participation in the program
    • Completed: The enrolled state is instead shown as completed after the program end-date.
    A student may have a different status in multiple programs (e.g. "applied" to program 1 and "withdrawn" from program 2). To summarize the workflow related to these statuses, the process for a student to participate in a program is summarized below:
    • A student applies to a specific program and fills out application questions. A student can apply to more than one program, but each application is entirely separate and done one at a time. Upon completion of the application, the student's status in the program is "applied". The student can also issue requests for letters of recommendation starting at this time.
    • If the student issued requests for letters of recommendation, emails are sent to the writers with a special link to allow them to upload their letters. Letters are ideally submitted before the application deadline, but the system will not reject letters submitted later than that.
    • An administrator, reviewer, or faculty lead for this program will review the application, and if the basic application responses are acceptable and they meet pre-requisites, the administrator that user will set the status of the student in that program to "eligible" and contact them to schedule an interview with a faculty lead for the program.
    • The student meets with the faculty lead, who is an administrator has access to manage students in their program and will mark the student as "approved". An administrator could also mark a student as "approved". Letters of recommendation, if present, are likely reviewed at this step.
    • The student must submit essential documents (definition 7) and submit necessary payments (which are not tracked by the system) by their respective deadlines. If this is done, an administrator will set their status to "enrolled". Note that this deadline is "soft": the system will accept forms indefinitely, and it's up to an administrator to decide (by means of how they change the application status) if it's truly too late.
    • If at any time the student doesn't complete their obligations (e.g. non-payment), an administrator can set the status to "canceled", removing them from the program.
    • A student may withdraw their application to a program at any time, changing their status to "withdrawn". If the student changes their mind, they can un-withdraw, changing the status to "applied" (no matter what the status was originally). At this time, an administrator could shepherd it to another status (e.g. "enrolled") as above.
    As implied above, certain user roles are allowed to alter applicant status only in specified ways. This privilege is additive, so if a user is an administrator and a faculty lead, then that user can make all the changes of an administrator. The approved status changes conferred by roles, in descending order of privilege, are:
    • Administrators can change an applicant's status at-will to {"applied", "eligible", "approved", "enrolled", "cancelled"}.
    • Faculty leads can change an applicant's status among {"applied", "eligible", "approved"}. This power extends only to student applications to a program for which the user is a faculty lead for.
    • Reviewers can change an applicant's status among {"applied", "eligible"}.
    • Students (users with no specific role) can change their own application status from any other than "canceled" to "withdrawn", and from "withdrawn" to "applied".
    The term among above means that such users cannot change the status if it is not currently one of the ones listed (e.g., a reviewer cannot change the status of a student who is currently set to "approved"). The figure below summarizes the flow of statuses and which roles can cause status transitions.
  9. Administrator: A user with administrator permission the administrator role.
  10. Known faculty leads: The set of all users listed as faculty lead in one or more programs (past, present, or future).
  11. HIPAA and FERPA: The "Health Insurance Portability and Accountability Act" (HIPAA) is a U.S. law that ensures the protection of individuals' medical records and personal health information. The "Family Educational Rights and Privacy Act" (FERPA) is a U.S. law that protects the privacy of student education records. Despite different domains, both establish standards for the security and confidentiality of covered data and mandate safeguards to prevent unauthorized access or disclosure. The full breadth of these laws is beyond our scope, but relevant highlights include the following:
    • Data Encryption: Ensure data is encrypted both at rest and in transit.
    • Access Controls: Implement role-based access controls to limit who can view or modify medical data.
    • Audit Trails: Maintain logs of user activity to track access to sensitive information.
    • Authentication: Use strong authentication methods (e.g., multi-factor authentication), and user sessions have automatic timeouts.
    • Data Integrity: Ensure data is accurate and protected from tampering or corruption.
    • Backup and Recovery: Implement secure backup and recovery procedures for medical data, ideally with geographic redundancy, a disaster recovery plan, and clearly defined Recovery Point Objective and Recovery Time Objectives (RPO/RTO).
    • Vulnerability Management: Regular updates and patches to address security vulnerabilities.
    • Incident Response: Capability for quick detection and response to security breaches or data breaches.
    Note: as a practical matter in this course, I'm not requiring full HIPAA/FERPA compliance. Some aspects of the above will appear in the requirements, either as normal items or as extra credit. Given the limited timeline, it is not recommended to try to speculatively fulfill these ahead of their inclusion in the formal requirements.
  12. Faculty: A user with the faculty role.
  13. Reviewer: A user with the reviewer role.
  14. Push- and pull-based backups: Push-based backups are when the production server is the entity that sends ("pushes") data to the backup server. Pull-based backups are when the backup server is the entity that requests ("pulls") data from the production server.

Requirements

A note on requirements: No set of requirements is perfect, and that is certainly true here. I'm sure that contradictions, under-specified behavior, and unintended consequences will be revealed. Your overriding goal should be to produce a quality system; if you believe that goal would be better served if a requirement were altered or interpreted a certain way, ask about it, and get the conclusion in writing. The result may be a variance in a requirement for a specific team, or even modification of this requirements document for all teams. In short, if unsure, ask.

Some requirements have attached an informal tip, motivation, or example; these do not alter the requirements themselves, but are meant to answer likely questions about a requirement.

Note: If a requirement says that an administrator can do something and a sub-requirement simply says that the “user” will do part of that thing, then the word “user” in that context is simply a pronoun referring to the initiating administrator, not just any normal user.

  1. Server
    1. Your software must have a server that supports an arbitrary number of simultaneous users. A web-based solution is preferred; thick client or mobile options are available with instructor pre-approval only.
    2. During the install/setup process, an administrator user called admin is configured. Other accounts are created via self-registration (req 6.1) or auto-creation upon first SSO login. New accounts are not administrators have no roles (and are therefore student accounts) by default.
    3. A user accessing the system prior to logging in should be able to access nothing but the homepage (req 2) and a means to login via SSO or local credentials or register a local account (req 6.1). The structure of these login prompts should encourage SSO login by default, with login/registration by local account de-emphasized as a secondary option. Implementors may, at their discretion, elect to allow users to also browse programs (req. 3.2) prior to login, but not apply or take other actions.
      1. The system will allow all SSO users to login, even if they are not yet known to the system. SSO users logging into the system for the first time will be noted (including importing username, display name, and email address from the SSO system), allowing their permission level role(s) to be edited later (req 6.3).
      2. If a user attempts to login via SSO for the first time, but a local account with the same username already exists, the login attempt should fail with a clear error explaining the situation. Similarly, if a user attempts to register a local account by a username that already exists as an existing user (either local or SSO), this should fail with a clear error explaining the situation.
    4. Stored passwords for local users must be kept in a secure manner (i.e., salted and hashed at minimum). SSO users must not have a password of any kind stored.
    5. Local users may change their own password using the customary two-matching-blinded-inputs approach commonly seen. SSO users should not have access to any such facility.
    6. All communication between the clients and server must be encrypted. Given the HIPAA and FERPA protected content being stored, communication encryption must be AES-256 or stronger, and TLS 1.2 or greater must be used. Tip: For web-based solutions, this means using HTTPS. If you set up your production server using modern tools and didn't do anything weird, you likely meet this requirement already.
      1. The server must receive an 'A' rating from a Qualys SSL Server Test, which examines certificate and encryption parameters. Any changes to the environment that were needed to achieve this grade should be noted in the Security Guide (req 5.4) along with a justification of why they improve security, and the report itself included as an appendix.
      2. (Extra credit) Implementors may elect to ensure the server receives an 'A' rating from the Mozilla HTTP Observatory, which examines HTTP headers and related policies. Any changes to the environment that were needed to achieve this grade should be noted in the Security Guide (req 5.4) along with a justification of why they improve security, and the report itself included as an appendix. Further, this should be noted in the Feature Guide (req 5.3).
    7. The server must maintain state in a persistent fashion. Tip: For web-based solutions, this just means using a database or similar.
    8. Consistency rule: A variety of cross-references are made by the system; the system must maintain internal consistency of these references in all cases. For example: if program X has 5 applicants, then each of those applicant's view of their own programs should include program X.
    9. Assisted selection: A user input is said to be assisted if it is a user-selected reference to an existing record (e.g., program, student, etc.) where the UI provides a listing, inline search, autocomplete, and/or other means to allow easy and efficient selection. Unless otherwise specified in this document, all selections of an existing record should be assisted. For dates, a date picker UI should be displayed.
    10. HTTP-compliant URLs: Web-based systems should use URLs correctly. This means, among other things, that (1) it should be possible to bookmark a URL for a particular view (e.g. a program detail view, req 3.3) and revisit it to see the same view, (2) GET and other "safe" HTTP operations do not have side effects, (3) transactions with side effects are constrained to POST/PUT/DELETE operations, and (4) the browser's natural back button functions correctly. This is sometimes called being "RESTful" (though that term is often used in relation to web-based APIs rather than user-visible URLs). Formally, this means compliance with RFC 7231.
    11. Additional security enhancements: Implementors may must elect to pursue one two or more of the following to move toward full HIPAA/FERPA compliance. For each pursued, the design, merits, weaknesses, and the associated threat model should be documented in the security guide (req. 5.4). Contact the instructor if you need more information. All of these are extra credit. Past completion of requirements from this list for extra credit can be counted against the currently required quota, so if you've already done two or more, you're in compliance now. New feature implementations beyond this will be extra credit.
      1. (Extra credit)(Option) Session timeouts: Login sessions should expire after 15 minutes of inactivity and 24 hours from login regardless of activity. When this happens, a dialogue explaining this should be displayed either immediately upon expiration or when the user attempts to take their next action after it. The user should then be redirected back to the login page.
      2. (Extra credit)(Option) Audit logging: All logins and modifications to data made on the system will be recorded in a single Write-Once Read-Many (WORM) log file. Log entries should be tagged with timestamps, IP addresses, and the user account that undertook them. It should not be possible to otherwise tamper with the log file via the system interface. Implementors may elect to make this log file viewable by administrators via the usual system GUI, or restrict this access to users with login access to the underlying server or another associated system.
      3. (Extra credit)(Option) Multi-factor authentication (MFA): Login to the system via SSO already supports MFA, but implementors may elect to provide their own MFA support for local accounts. Details are left to the implementor, but industry-standard techniques should be employed. Note that SMS-based MFA is generally seen as deprecated and therefore not an industry-standard technique for new deployments.
      4. (Option) System integrity monitoring: Upon deployment, the server (or an associated secondary server) should be configured to monitor the running codebase and related configuration files for unauthorized modifications, e.g. via file hash tracking. If an unauthorized change is made (e.g. via SSH), then an alert should be sent to the implementors so that the system can be inspected for signs of intrusion.
      5. (Option) Security-hardened backups: In order to be resistant to ransomware and similar adversarial attacks, in addition to the core backup requirements (req 7), your backup solution must also do the following. These goals seek to create a scenario where an adversary would have to compromise both the primary and backup servers in order to compromise user data.
        1. Backups are to be performed in a "pull" configuration (def 14).
        2. The backup server should use secure credentials to access the production server, and these credentials must confer just read-only access to production data.
        3. No credential accessible from the production server should provide any form of access to read or govern the backup server.
        4. All data must be encrypted with an AES-based cipher before being sent to the backup server. The key for this encryption should random, and be stored on the production server as well as in the possession of the implementors. It must never reside on the backup server, nor should it be made visible to the backup server by means of the credentials used to take the backup.
  2. Home page
    1. The system should have a friendly home page that expresses what the system is for. If the user is logged in as a student, then this information should be student-focused. If the user has not yet logged in, then a link or interface to login or register (req 6.1) should be shown, and the student-focused information shown. If the user is logged in as an administrator, then this page should orient them to the administrative functions of the system.
    2. (Extra credit) GUI-editable home page: To allow up-to-date announcements to be posted, implementors may elect to include a feature so that an administrator can use a GUI editor to change content shown on the homepage. Further credit will be awarded if this editor allows rich text (headers, bold/italic, etc.). Note: raw HTML input is not acceptable to achieve rich text, both for usability and security reasons.
  3. Program management
    1. Administrator program list: Administrators, reviewers, and faculty will be able to view a table of programs with columns for title, year and semester, faculty lead(s), all dates, the count of applicants in each status ("applied", "enrolled", etc.), and the total count of active applicants (those in any status other than "withdrawn" or "canceled").
      1. The view should be sortable by any of the displayed fields.
      2. It should be possible to filter this view by a keyword search that covers title. This view can also be filtered by selection of faculty lead from a picklist of all known faculty leads (def. 10).
      3. It will be possible to filter the view by time. The options are:
        • Current and future programs (today ≤ end date). This is the default.
        • Programs open to applications (application open date ≤ today ≤ application deadline).
        • Programs in review (application deadline ≤ today ≤ start date).
        • Programs running now (start date ≤ today ≤ end date).
        • All programs regardless of timing.
      4. Users should be able to navigate from this to a detail view for a program (req 3.3).
      5. From this view, it should be possible to begin creation of a new program (req 3.4).
      6. For faculty, this program listing should provide a UI control to filter the view to only programs for which the current user is a faculty lead. This control should be turned off by default.
    2. Student "browse programs": Students will be able to browse programs in a similar manner to req 3.1, with the main difference being that format and available search/filter options. Students will browse a list of programs formatted to inform and entice: clear headers showing title/year/semester, with faculty leads, full description, and all dates listed. Administrators, reviewers, and faculty will also be able to see this view, primarily to preview what students will see in the system.
      1. This view should omit programs whose end date has passed.
      2. This view should be always sorted by application deadline. However, to ensure that the view does not start with a list of programs whose application deadline has passed, implementors should either (a) adjust the sort so that programs whose application deadline has passed are at the end or (b) provide an option to show/hide programs whose application deadline has passed which defaults to 'hide'.
      3. It should be possible to filter this view by a keyword search that covers title. This view can also be filtered by selection of faculty lead from a picklist of all known faculty leads (def. 10).
      4. If the student has already applied to this program, a clear indicator of their current status should be shown ("applied", "enrolled", etc.), and it should be possible to navigate to their application (req 4.3). Otherwise, one of the following UI elements should be shown. For programs whose application window is open, a clear and distinctive "Apply" button should be displayed, which begins the student application process (req 4.1). For programs whose application window is not yet open, a clear visual indicator for this should be shown instead. Similarly, a different clear visual indicator should be shown for programs whose application deadline is passed. Administrators, reviewers, and faculty should also see these controls, but the "Apply" button, if present, should be disabled.
    3. Administrator program detail: Administrators, reviewers, and faculty may view a detail view of a program showing all fields (including full description) and applicants to the program. From there, administrators may request to modify (req 3.5) or delete (req 3.6) the program. Applicants to the program (and all UI options stemming therefrom) should only be visible to administrators, reviewers, and faculty leads for the program currently viewed (i.e., faculty who are not leading this program and who do not have also administrator or reviewer roles cannot view applicants). The For approved users, applicants should be listed in a table with columns for display name, username, email address, each of the basic facts from definition 7, and application status ("applied", "enrolled", etc.). Additional column(s) should indicate which essential documents (definition 7) have been submitted, as well as column(s) that summarize the state of confidential notes, including quantity of notes and the author/date of the most recent note.
      1. It should be possible to sort the applicant table by all shown columns.
      2. It should be possible to filter the applicant table with a drop-down to select status ("applied", etc.).
      3. It should be possible to navigate from the applicant table to a particular student's application (req 4.4).
      4. It should be possible from this view to change an applicant's status to "applied", "eligible", "approved", "enrolled", or "cancelled" based on the current user's role(s) as described in definition 8.
      5. (Extra credit) Housing planner: If the implementor is supporting electronic submission of the housing questionnaire (req. 4.3.5.2), the implementor may elect to allow an export as CSV or XLSX (implementor's choice) of all students' responses, with columns for student display name, username, email address, major, application status, and all responses to the questionnaire. No other columns should be included.
      6. Copy emails: The user should be able to copy to the clipboard a list of email addresses for all applicants matching the current filter. This list should be semicolon delimited for compatibility with Outlook. If the implementor is employing pagination (displaying only some of the total set of records), then this feature should allow copying all email addresses matching the current filters, not just those currently displayed.
    4. Program creation: Administrators will be able to add programs to the system as follows.
      1. The user will input the title, faculty lead(s), description, and all relevant dates. Constraints specified in definition 6 will be enforced. Selection of faculty leads should be assisted (req 1.9) and chosen from the set of all administrators faculty.
      2. (Extra credit) Rich descriptions: Implementors may elect to allow the description to be expressed as rich text (section headers, bold, italic, etc.). If this is done, care should be taken so that the formatting of the description cannot create confusion in the interface (e.g. making it unclear where one program ends and the next begins). Note: raw HTML input is not acceptable to achieve rich text, both for usability and security reasons.
      3. The user will also specify the questionnaire. The interface will default to showing the questions from Appendix A, but the user should be allowed to add, modify, and delete questions, subject to the constraints in definition 6. These questions will serve as the questionnaire prompts shown to applicants.
    5. Program modification: Administrators may modify an program to change editable fields in a manner similar to creation (req 3.4).
      1. Changes to key dates will affect future behavior of the system but have no retroactive effects. For example, if a student had already applied, but the application open date was moved into the future, their application would be unaffected, but other students would not be able to apply until that future date comes.
      2. If there are already applicants to the program, then changes to the questionnaire must be handled as follows:
        1. A prominent and clearly worded warning should be shown that applications are already present.
        2. If a question is modified, then existing responses should remain associated with the now-changed question.
        3. If the user tries to delete a question, a confirmation should first be displayed warning the user that applicant responses associated with the question will be deleted, after which the deletion can be approved or canceled.
        4. If a question is added, then previous applicants will not have a response to it; this is an allowed deviation from the usual 'Required' constraint on questionnaire responses, though such applicants could later fill in the new question as allowed in req 4.3.
    6. Program deletion: Administrators will be able to delete a program as follows.
      1. A highly visible confirmation dialog must be confirmed first. Further, if the program has any applicants, then this confirmation should be significantly more visible, and give the number of student applicants/participants whose records will be lost from this action. Only upon confirmation will the deletion occur.
  4. Application management
    1. Student "Apply to a program" interface: When a student wishes to apply to a program, they will be prompted to provide the basic facts and responses to the questionnaire described in definition 7 configured for this program.
      1. The application is only formally created if all fields are input and recorded successfully. Upon completion, the student's status with the program is set to "applied".
      2. Upon completion, the student is taken to view their application (req 4.3).
      3. Students can issue requests for letter of recommendation at this stage per req 4.5.
    2. Student "My Programs" view: Students may view a table summarizing all programs to which they have previously applied. This table should include columns for title, year and semester, faculty lead(s), all dates, and the student's current application status. Additional columns should indicate which essential documents (definition 7) have been submitted for programs where the application state is "approved", "enrolled", or "completed"; missing documents for such programs should be conveyed visually in a way that suggests the student should take action (e.g. in red).
      1. It should be possible to sort this table by all shown columns.
      2. It should be possible to navigate from this view to the student's application to a program (req 4.3).
    3. Student view of application: This is the interface presented when a student views details of their own application to a given program.
      1. This view will display all information about the program in a manner similar to an entry from "browse programs" (req 3.2).
      2. The student can view all their responses from req 4.1. This includes viewing all requests for letter of recommendation, as well as if they have been fulfilled. Fulfilled requests should be shown distinctively, and indicate the date/time of letter submission. Naturally, as letters are confidential, the student should not be able to view letter content. If today's date is within the application window and their status is "applied", then they may modify their answers as they see fit or add/delete requests for letter of recommendation per req 4.5, otherwise this data is read-only.
      3. The student's application status ("applied", "enrolled", etc.) should be shown prominently.
      4. If the student's current status is anything except "canceled", "completed", or "withdrawn", then they may elect to withdraw their application (after consenting to a warning dialog), thus setting their status to "withdrawn". If the student's current status is "withdrawn", then they may elect to re-activate their application (after consenting to a warning dialog), thus setting their status to "applied".
      5. If the application is in the "approved" or "enrolled" state, then the interface should allow them to provide the essential documents (def. 7). In fact, if one or more documents have not been provided, the interface should strongly and visibly direct them to do so, calling attention to the number of days until (or since!) the essential document deadline. Note: the document deadline is a "soft" deadline, so the system will accept documents even after it has passed. Implementors have their choice of two methods for accepting such documents:
        1. PDF upload: The system will allow students to download blank forms, then allow them to upload a filled-in PDF for each type of essential document. For each type of document, students may re-upload new versions, replacing older ones. The most recent upload's timestamp should be recorded for each document type.
        2. (Extra credit) Electronic submission: Implementors may develop electronic versions of each document type.
          1. The electronic forms should have all the same fields as the originals, but the system need not ask for facts that it already knows (e.g. student name, program name, today's date, etc.).
          2. After answering all needed questions, the student should be allowed to review the full form in its entirety, then the student and/or parent/guardian should be allowed to electronically sign the form. A canvas-based signature pad should be used which supports touchscreens, styluses, and mouse input, and records signatures as a vector-based SVG (preferred) or a high-resolution PNG to prevent quality loss in PDFs.
          3. The system should note the timestamp of submission for each document.
          4. Students should be allowed to check and potentially update such forms over time, updating the timestamp if a document is changed.
    4. Administrator view of application: This is the interface presented to administrators, reviewers, and faculty leads for a program when viewing details of a particular student's application to a given program.
      1. This view will display all information about the program, including full description.
      2. The user can view all the responses from the student's application given in req 4.1. The user can also view all requests for letters of recommendation. Requests that have been fulfilled should be shown distinctively, with the date/time of submission shown, and the user should be able to view the content of such letters. This data is read-only.
      3. The student's application status ("applied", "enrolled", etc.) should be shown prominently. It should be possible from this view to change it to "applied", "eligible", "approved", "enrolled", or "cancelled" based on the current user's role(s) as described in definition 8.
      4. All confidential notes should be visible in reverse chronological order (newest first), with author and timestamp.
      5. The administrator, reviewer, or faculty lead should be able to add a new confidential note from here, writing in a multi-paragraph input box, and recording it with the current user as author and the current time as the timestamp.
      6. Administrators and faculty leads should be able to view if each essential document has been submitted, its most recent timestamp, and to review each. Reviewers should similarly be able to view the existence and timestamp of such documents, but not the content.
        1. If the implementor is supporting PDF upload (req. 4.3.5.1), the student-provided PDF should be able to be viewed and downloaded without modification.
        2. If the implementor is supporting electronic submission (req. 4.3.5.2), for compatibility with existing workflows, the system must be able to export PDF versions of each document with very similar appearance to the original blank forms, including the signature(s) captured at submission time, as well as the recorded timestamp.
    5. Letters of recommendation - requests: A student, either during initial application or as a modification to their application while still within the application window, may manage requests for letters of recommendation as follows.
      1. Add request: The student will submit the name and email address of a letter writer. Upon submission of this data, and a request email is sent to the letter writer (req 4.6.1).
      2. Delete request: The student may request to delete a request. A confirmation dialogue is shown first, and upon approval, deletion proceeds.
        1. If the request has not yet been fulfilled, the delete confirmation should warn the user that the writer has already been contacted but will not be able to submit a letter if the request is deleted. Upon deletion of such a request, a follow-up email to the writer should be sent that explains that the request has been retracted, and the hyperlink included in the original email to the writer should no longer function (req 4.6.2.1).
        2. If the request has already been fulfilled, the delete confirmation should warn the user that the action will irrevocably delete the underlying letter of recommendation from their application. If confirmed, the deletion should remove the uploaded letter accordingly.
      3. A request may not be modified in place (e.g. changing an email address); instead, the student would have to delete the old request and add a new one.
    6. Letters of recommendation - responses: Writers will be able to submit letters of recommendation as follows.
      1. Request email: Upon submission of a request, the system will send the writer an email explaining the request. This email should briefly explain the full context of the situation (name of university, purpose of the system, name of student, name of program, etc.). It should include a prominent hyperlink to allow the writer to use the system to submit their letter (req 4.6.2). This hyperlink should include a token that is unique to the application and writer and not predictable or practically brute-forcible (e.g. it is a random UUID as opposed to encoding the application/writer identities).
      2. Writer interface: Upon visiting the hyperlink, the writer will be presented with an interface on the system that again explains the full context of the situation and provides a means to upload a PDF letter of recommendation (req 4.6.3). Note that this link into the system does not require a login (as the hyperlink itself is the authentication), and is an exception to the usual relevant requirements (reqs 1.3, 2.1, etc.).
        1. If the writer visits a link that is no longer valid (e.g. because the request has been deleted by the student), the system should inform the writer that the request for a letter is no longer active.
      3. Letter upload: Upon uploading the PDF letter, it will be recorded for this application and writer, along with the current date/time. The writer will be thanked, concluding their transaction.
  5. Documentation
    1. Developer guide: A document shall be provided which orients a new developer to how your system is constructed at a high level, what technologies are in use, how to configure a development/build environment, and how the database schema (or equivalent) is laid out.
    2. Deployment guide: A document shall be provided which describes how to install your software entirely from scratch. It should start by describing the platform prerequisites (e.g., Linux distro, required packages, etc.), then mechanically describe every step to deploying your system to production readiness.
      1. In addition to covering how to install the system with “stock” default data, the procedure to install the system from scratch using backed up data should also be included (i.e., disaster recovery).
    3. Feature guide: Optional. If an extra credit requirement is pursued, document its design, benefits, and a walkthrough of how to demonstrate it here. If you pursued extra credit in an earlier evolution, maintain its documentation, modifying it if needed.
    4. Security guide: A document shall be provided which explains specific security features as well as known weaknesses or warnings. References for the exact content needed are attached to a number of other requirements in this document (reqs 1.6.1, 1.6.2, one or more of the features within 1.11), but other features from the implementors can also be included.
    5. Backup admin guide: A document shall be provided which explains the backup solution so that a system administrator unfamiliar with your software could configure it from scratch, restore the database to any given backup, and test a backup for validity. See req 7.
  6. User management
    1. Student self-registration: Students new to the system who don't have an SSO account may register a local account. The user will set a username, display name, email address, and password (using the customary two-matching-blinded-inputs approach commonly seen). Constraints from definition 4 are enforced, including uniqueness between SSO and local users (so a local user cannot be created with the same username as a previously seen SSO user). Upon success, the user account is created, and the user can then login to the new account. It is not necessary to validate the email address by sending a test message that the user must follow a link from, but implementors may do so at their discretion.
    2. User list: Administrators will be able to view a table of all users showing all fields (except password, of course). Users with administrator privilege User roles should be clearly distinguished. Both local and known SSO users should be shown, with the two being visually distinguished.
    3. User modify: Administrators should be able to update user accounts as follows.
      1. Administrators should be able to give or revoke administrator status roles to user accounts other than their own. The admin account is special and cannot lose administrator privilege its standard roles per definition 4. If the user being demoted losing faculty role is listed as a faculty lead for any programs, a confirmation dialog should note this and list the relevant programs, allowing the user to proceed or cancel the change. Upon approval, that user will be removed as faculty lead. If the demotion this change would cause a program to have no faculty lead, then the faculty lead should be set to admin upon modification of the user.
      2. Administrators may reset a local user's password, again using the customary two-matching-blinded-inputs approach commonly seen. Naturally, SSO users cannot have their passwords manipulated by the system.
    4. User delete: Administrators will be able to delete local user accounts other than their own account and the admin account. This should be a rare operation in practice. It should not be possible to delete known SSO users; either the option to do so should be omitted, or an appropriate error should be shown if this is attempted.
      1. A clear confirmation dialog should be shown first. If the user being deleted has applied to any programs or is listed as a faculty lead for any programs, this confirmation dialog should note this and list the relevant programs.
      2. If such deletion would cause a program to have no faculty lead, then the faculty lead should be set to admin upon deletion of the user.
      3. If there are other traces of the deleted user on the system (e.g. as author of confidential notes), the implementor may elect to have these simply shown as before, or to display the author as "Deleted user".
  7. Backups: You must deploy a backup solution for your system's database. Additional requirements from req 1.11.5 may also be pursued in addition to the ones below.
    1. Backups shall be automatic and taken daily.
    2. Backups shall be kept with a staggered retention (7 daily backups, 4 weekly backups, 12 monthly backups).
    3. Backups must be stored on a separate system.
    4. The backup system must require separate credentials to access.
    5. The backup system should report on progress and alert on failure; this could be via email or another directed communication mechanism.
    6. The backup system may be built either out-of-band from the main software (e.g. a background database dump restored manually by a sysadmin) or in-band (e.g. the software itself exporting its database using internal automation).
The following is a preview of a requirement that will be part of Evolution 4, shown early so you can be thinking about it.

Appendix A: Standard Default questionnaire prompts

The standard default program application asks these questions:
  1. Why do you want to participate in this study abroad program?
  2. How does this program align with your academic or career goals?
  3. What challenges do you anticipate during this experience, and how will you address them?
  4. Describe a time you adapted to a new or unfamiliar environment.
  5. What unique perspective or contribution will you bring to the group?