-
Notifications
You must be signed in to change notification settings - Fork 0
Software Requirements
General
Project Goal
Requirements Gathering Process
Glossary
Functional Requirements
- For New Users
- Initial Setup
- User Dashboard - Basic and Advanced functions
- User Dashboard - Display of module details in planner
- User Dashboard - Graduation Requirements
- Study Plan Dashboard - Management of all Study Plans
- Study Plan Dashboard - Viewing Study Plans
Non-Functional Requirements
- To assist any CS student with planning their 4-year study in the NUS School of Computing (Computer Science).
- Provide decision support for students in module selection for upcoming semesters, based on required module prerequisites and module recommendations.
- Allow students to have more ease of mind and convenience in the study planning process.
These requirements were created through many rounds of discussion, user surveys and user interviews.
User interviews were conducted on an approximately equal proportion of Year 1, 2, 3 and 4 students and sought to understand their pain points whenever they had to plan their modules. Each of us from RainbowHead Studios spent 10 minutes conversing with our interviewees to understand how they usually plan their modules and what we can do to make that process less painful.
You will find the summarized list of requirements we have for NUS Oracle down below. We're open for any sort of feedback, so please feel free to send us a comment or message for any suggestions! Thank you!
| Term | Meaning |
|---|---|
| User/Student | CS student interacting with our NUS Oracle |
| The system | NUS Oracle web application |
| The system administrator | NUS SoC official in-charge of ensuring module info and grad requirements are updated for all users/students |
| Academic cohort | Defined as the year in which a student first matriculated into NUS (eg. AY14/15 would mean he or she follows the AY14/15 graduation requirements) |
| Exemption list | Defined as a list that contains all modules a student is not required to take and not converted to UEs. |
| Waived list | Defined as a list that contains all modules a student is not required to take but have to be converted to UEs. |
| Completed list | Defined as a list that contains all modules a student have completed before entering NUS in Year 1 Semester 1. |
| Active study plan | Refers to a student’s current active study plan - the one that he/she has last edited |
| Invalid modules | Refers to modules which are not offered in the current mounting plan AND/OR prerequisites/corequisites not fulfilled |
Key user: Any student from the NUS School of Computing Computer Science curriculum.
The system: NUS Oracle web application.
The system administrator: System administrators are the people who ensure NUS Oracle's module information and graduation requirements are up-to-date and checked by a school official.
Students should be able to:
1.1. Sign up with an NUS email account (e.g. A1234567B@u.nus.edu).
1.2. Sign up with a custom password.
System should be able to:
1.3. Prompt users when they are typing in their passwords to use at least 6 characters, 1 digit, 1 symbol and at least 1 upper or lowercased letter.
1.4. Show an error if user inputs a password that does not have the required type of symbols (as listed in 1.3), telling the user what symbols were not used in the password.
Students should be able to:
1.5. Login with their NUS email account and password.
1.6. Sign out of NUS Oracle.
System should be able to:
1.7. Prompt user to recover password if they made more than 5 guesses.
Students should be able to:
1.8. Prompt the system to reset their lost password by entering their NUS email account.
1.9. Receive an email containing an alphanumeric token in their NUS email account that would give them instructions to reset their lost password.
1.10. Give the system the alphanumeric token to verify that the they are the ones authorized for resetting the password.
1.11. Confirm to set a new password after verification with the alphanumeric token.
System should be able to:
1.12. Void the alphanumeric token that is sent to student’s NUS email address after resetting his/her password.
1.13. Void the alphanumeric token after 24 hours.
1.14. Prevent accounts which have enabled "reset password" to log in with the old password, so that unauthorized people will not be able to access the user's account using an older password.
All JC and Poly students should be able to:
2.1. Select their current academic cohort.
2.2. Select whether they are from Polytechnic or JC or others.
2.3. Select NUS Module(s) that they have completed/exempted already.
2.4. Select a starting study plan template from a list which includes:
---- i. A blank plan where the students can start from scratch.
---- ii. A partially filled plan with only CS foundation modules.
---- iii. Any of the suggested study plans for the various focus area tracks provided by UG Office website.
System should be able to do the following:
2.5. Add a student's exempted modules MCs to the number of MCs they currently have.
Students should be able to:
3.1. Be immediately directed to choose a starting study plan template (blank, partially filled or focus area plans), if they are newly signed up users.
3.2. Be directed to their active study plan, if they are return users, immediately when they login.
3.3. Add modules to any semester in their study plan.
3.4. Delete modules in any semester in their study plan.
Students should be able to:
4.1. View module details of any selected module, e.g. description, number of MCs, prerequisites, preclusions.
4.2. View whether a module is not offered anymore in any particular semester (terms offered).
Students should be able to:
5.1. See the total number of MCs they have accumulated from any study plan.
5.2. See the total number of MCs that they still require to graduate in any study plan.
5.3. See what requirements are left to complete their Core Requirements.
5.4. See what requirements are left to complete their Science Requirements.
5.5. See what requirements are left to complete their University Requirements.
5.6. See what requirements are left to complete their Focus Area(s) Requirements.
5.7. Check from a single list, how many MCs they have not completed yet for their Core/Science/University/Focus Area(s)/UEs requirements.
The system should be able to:
5.8. Verify whether a study plan can allow the student to graduate successfully in real-time.
5.9. Students should be able to report any technical difficulty that they experience in using NUS Oracle via email to the current developers of NUS Oracle at nusoracle@gmail.com.
Students should be able to:
6.1. Create a new blank study plan.
6.2. Duplicate a study plan by copying all of a selected study plan's modules over to the new study plan.
6.3. Delete a study plan.
6.4. Rename a study's plan title.
Students should be able to:
7.1. View all the modules they have selected in their 4-year CS programme in a single study plan.
7.2. View all the study plans they have made.
7.3. Have a tabbed hierarchy system of study plans.
- Students should be able to input required initial setup data (e.g. academic cohort and previous education) within 3 minutes.
- Module information and degree requirements should be updated once every semester, for the current academic semester, to ensure information is reliable and up-to-date.
- One student account should only be allowed to log in once per browser session.
- After every user action that changes his/her study plan, the user's progress should be saved to the database, so that the user can simply continue from where he/she left off in another login session.
- When students add/delete a module to/from their study plan, the action should have a total lag time of at most 100ms before the result of the action appears on the user interface.
- Student accounts should not be allowed administrative privileges to manipulate any part of the database.
- The system should not be vulnerable to data-embedded commands that force it to manipulate the database in unintended ways, e.g. database injection attacks.
- The system should save all students’ passwords in the database using a 128-bit salt, 1-way encryption algorithm with SHA-64, so that no text-based representation of the passwords are ever stored.
Made with love from Team Rainbowhead Studios:
Adrian Chan Ee Ray
Antonius Satrio Triatmoko
Brandon Swee Yee
Natasha Koh Sze Sze
See Wenhan
- Home
- Getting Started
- Software Requirements
- Architecture and Database Diagrams
- UI Design
- Efficiency & Robustness
- Usability
- Work Log