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.
• 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 administrator will be able to create, update, and delete programs in the system.
• The administrator will be able to review student applications and shepherd them through various phases in the application process.

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. The user with username "admin" is the administrator of the system. Defined by fields:
   • Username: An alphanumeric user name. Unique. Required.
   • Display name: The real name of the user (e.g. "Tyler Bletsch"). For the special admin user, this is "Administrator". Required.
   • Password: The password required to login; stored securely (req 1.4). Required.
   • Email address: An email address associated with the user. Required.
5. Student: A user other than the administrator.
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. 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.
     • 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.
8. Application status: Captures the state of a student's relationship to a program. Possible values include:
   • Applied: Student has submitted basic application materials
   • Enrolled: Student is formally enrolled in the program
   • Canceled: The administrator has removed the student from the program
   • Withdrawn: A student has ended their application/particiation in the program
   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".
   • If at any time the student doesn't complete their obligations (e.g. non-payment), the 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, the adminstrator could shepherd it to another status (e.g. "enrolled") as above.

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. Student accounts are created via self-registration (req 6.1).
   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 or register (req 6.1).
   4. Stored passwords must be kept in a secure manner (i.e., salted and hashed at minimum).
   5. Users may change their own password using the customary two-matching-blinded-inputs approach commonly seen.
   6. All communication between the clients and server must be encrypted.
      Tip: For web-based solutions, this means using HTTPS.
   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.
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 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 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 administrator 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).
      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 administrator 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.
      3. It should be possible to filter this view by a keyword search that covers title and faculty lead(s).
      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 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 administrator should also see these controls, but the "Apply" button, if present, should be disabled.
   3. Administrator program detail: The administrator may view a detail view of a program showing all fields (including full description) and applicants to the program. From there, the administrator 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.).
      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", "enrolled", or "cancelled".
   4. Program creation: The administrator 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.
      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 administrator may modify an experiment 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 administrator 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.
      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" 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".
   4. Administrator view of application: This is the interface presented to the administrator 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", "enrolled", or "cancelled".
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.
6. User management
   1. Student self-registration: Students new to the system may register an 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. 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.

---

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?