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:

• Students will be able to create an account by self-registering on the system.For most students, the system will support single sign-on (for us, this will be integration with Duke NetID). However, HCC supports several types of non-traditional students that will not have SSO accounts (continuing ed students, cross-registration students from Hypothetical Tech, etc.) -- such students will still be able to create an account by self-registering on the system.
• Students will be able to browse programs and to apply to one by answering a series of questions through on online application wizard.
• Students will be able to monitor the state of their application and subsequent involvement in the program.
• The administratorAdministrators will be able to create, update, and delete programs in the system.
• The administratorAdministrators will be able to review student applications and shepherd them through various phases in the application process.
• Some accounts will be marked as administrators; such accounts will be the ones to manage programs and applications as well as assigning/removing administrator privilege to other accounts.
• Administrators will be able to record confidential notes within student applications.
• The inclusion of additional application phases allows program faculty leads to have a specific point in the process to perform student interviews and record their findings.
• Students will submit essential pre-departure paperwork (medical records, liability waivers, etc.) to the system.
• As the system stores both medical information (covered by HIPAA) and academic data (covered by FERPA), the system will implement robust security and document these in a separate security guide.

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, than 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.
5. Student: A user other than the administratorwith no administrator privilege.
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): A short free-form text field indicating the faculty member(s) leading this program. One or more references to existing user accounts for the faculty members leading this program, such users must be administrators. 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.
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.
   • Questionaire: Multi-paragraph answers to the questions listed in Appendix A. All are required.
   • Confidential notes: Zero or more notes added by an administrator. These notes will only be visible to administrators, 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.
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: TheAn administrator has removed the student from the program
   • Withdrawn: A student has ended their application/particiation in the program
   • Complete Completed: The enrolled state is instead shown as complete 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 administrator will review the application, and when all administrative tasks are complete, set the status of the student in that program to "enrolled".
   • An administrator will review the application, and if the basic application responses are acceptable and they meet pre-requisites, the administrator 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 and will mark the student as "approved".
   • 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), thean 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, thean adminstrator could shepherd it to another status (e.g. "enrolled") as above.
9. Administrator: A user with administrator permission.
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.

Requirements

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. StudentOther accounts are created via self-registration (req 6.1) or auto-creation upon first SSO login. New accounts are not administrators 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 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. UsersLocal 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 elect to pursue one 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.
       1. (Extra credit) 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) 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) 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.
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 the 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 the 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: The administratorAdministrators 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 and faculty lead(s). 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).
   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. The administratorAdministrators 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 and faculty lead(s). 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. The administratorAdministrators should also see these controls, but the "Apply" button, if present, should be disabled.
   3. Administrator program detail: The administratorAdministrators may view a detail view of a program showing all fields (including full description) and applicants to the program. From there, the administratoradministrators may request to modify (req 3.5) or delete (req 3.6) the program. The 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".
      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.
   4. Program creation: The administratorAdministrators 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.
      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.
   5. Program modification: The administratorAdministrators may modify an program to change editable fields in a manner similar to creation (req 3.4).
      1. Changes to key dates will effect 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.
   6. Program deletion: The administratorAdministrators 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.
      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).
   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 "complete 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. If today's date is within the application window and their status is "applied", then they may modify their answers as they see fit, 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 the administratoradministrators 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. 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".
      4. All confidential notes should be visible in reverse chronological order (newest first), with author and timestamp.
      5. The administrator 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 should be able to view if each essential document has been submitted, its most recent timestamp, and to review each.
         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. 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.
   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.
6. User management
   1. Student self-registration: Students new to the system who don't have an SSO account may register ana 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 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 to user accounts other than their own. The admin account is special and cannot lose adminstrator privilege. If the user being demoted 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. If the demotion 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".

---

Appendix A: Standard questionnaire prompts

The standard 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?