Software Requirements Specification

TODO:

• Adjust ConOps sections according to Prof. Hornof's feedback.
• Update all requirements to reflect what we have actually aimed to do since then

Authors	Key
Ryan Gurnick	rg
Joseph Goh	jg
Samuel Lundquist	sl
Mason Sayyadi	ms
Owen McEvoy	om

1. SRS Revision History

Date	Author	Description
02/13/2020	om	created initial document
02/13/2020	om/jg	created first version of the Concept of Operations
02/13/2020	jg	added more operational scenarios
02/14/2020	rg	moving changes over from gd
02/15/2020	om	modified Concept of Operations, began working on Specific Requirements
02/18/2020	jg	elaborated on input requirements according to SRS template
02/19/2020	ms	editing SRS document for language and consistency
02/19/2020	rg	adding to conOps, and changing 'transcript' to 'degree audit'
02/19/2020	om	updated conOps and external interfaces
02/20/2020	jg	updated ConOps with discussion of major/minor planning and Degree Guide's limitations
02/20/2020	rg	Proof-reading...
02/20/2020	jg	Revamped performance requirements section and made general formatting improvements
02/20/2020	jg	Added brief descriptions and actors to use cases
02/20/2020	jg	Re-categorized/Re-wrote performance and usability requirements as appropriate
02/20/2020	sl	Grammar check and clarity revision
02/27/2020	om	Modified ConOps and began creating new use cases
02/28/2020	jg	Unified spelling of the word 'adviser'
02/28/2020	jg	Updated Cases C and E and marked B and D as 'to be deprecated'
03/01/2020	jg	Updated use cases to reflect current implementation decisions including deleting deprecated use cases
03/05/2020	jg	Made updates and corrections to all use case flowchart diagrams
03/07/2020	jg	all mentions of regTools changed to Registration Tools
03/08/2020	om	Updating sections to match the current functionality of the system
03/08/2020	om	Updated use cases & use case diagrams

2. The Concept of Operations

2.1 Current System or Situation

It is currently time consuming and difficult for advisers at the University of Oregon to provide solutions to CIS students who are seeking assistance with their registration. Advisers can see up to ten students a day, each with their own unique interests and needs. For each student, an adviser must diligently read through that student's transcript as well as that student's major requirements. To successfully evaluate that students current situation, the adviser must then determine which of the requirements the student has or hasn't satisfied.

It should be acknowledged that the Degree Guide, a tool that assesses a student's completion of major/minor and general degree requirements and their completion, is already available to both advisers and students on Duckweb. However, Degree Guide can only categorize and list course requirements. It cannot provide information on what classes are prerequisites for other classes, which classes satisfy a specific requirment that the student is yet to fulfill, nor can it recommend a sequence or priority list of courses for the student to take based on a long-term plan. Due to the Degree Guide's limited scope, advisers must handle these tasks themselves.

In addition to the Degree Guide's limitations, it is difficult for advisers to access information on courses that the student may want to take in the future due to the fact that the university only publishes courses one term in advance. If the student is already aware of which classes they would like to take or is seeking a two year plan, advisers can inspect the university's class website of years past in order to make predictions on the future schedule. This requires a lot of tedious work for the adviser, taking up a lot of the limited time that could be better used for actually advising the student. Due to this, some advisers opt to give students a suggested schedule by simply suggesting classes that seem to follow a sequence or fulfill a requirement. This process can result in an inefficient solution in the event a class is not offered in the suggested term, potentially delaying the students progress towards graduation and thus costing them thousands of dollars.

2.2 Justification for a New System

As stated in the previous section, advisers at the University of Oregon help students determine which classes they need to take in order to progress towards graduation. During class registration periods, advisers can only see about ten students per day resulting with students having to wait up to two weeks to for an appointment. Therefore the majority of students are unable to successfully schedule an advising appointment at an appropriate time and are forced to register for classes unadvised. This can lead to a student registering for classes which they do not have to take, which may not only delay their graduation but can also end up costing them thousands of dollars.

Part of the reason each advising session takes so long, is the repetetive and tedious work advisers do such as checking the student's degree guide, trying to predict the availability of classes for a given term, and figuring out which requirements a student should aim to satisfy without overwhelming them. Registration Tools will automate these steps, decreasing the amount of time for each advising session. As a result, advisers will be able to meet with more students in a given day, thus significantly decreasing the wait time students experience when scheduling an advising appointment. Additionally, this will also decrease the number of students who end up registering for classes which they do not need to take.

2.3 Operational Features of the Proposed System

The proposed system, Registration Tools, is being created with the intent of providing advisers at the University of Oregon with quick and reliable assistance during registration periods and with long term planning of major requirements.

• The system allows advisers to add new students and their academic information into the database
  • Advisers will be able to easily update each student's academic information
• The system will allow advisers to easily collect new class information based on a subject, term, and year
• The system will display a student's progress towards completing their major's requirements

2.4 User Classes

The target user for Registration Tools is advisers at the University of Oregon, although it has the potential to be expanded to other educational institutions

2.5 Modes of Operation

In this system, the adviser use mode is the primary mode of operation.

• adviser use mode provides the adviser with all of the tools they need to successfully advise their students. In this mode, the adviser will be able to easily add new student, update a student's academic information, view and collect new information about classes, and view which requirements the student has or hasn't completed.

2.6 Operational Scenarios (Also Known as “Use Cases”)

Case A: First Meeting

Figure 2.6.1 Dynamic flowchart diagram of Case A

Brief description: This use case describes the first-time an adviser is meeting with a student.

Actors: An adviser (the user).

Preconditions: An adviser at the University of Oregon has a scheduled meeting with a student for the very first time. Before the student arrives, the adviser logs in to DuckWeb and opens the student's Degree Audit.

1. The user launches Registration Tools and is brought to the main menu.
2. The user is prompted to choose the student's profile listed by name or other identifier.
3. As expected the user notices the student does not appear in their list of students and clicks the Add Student button
4. The user enters the student's name, clicks Add, and is returned to the main menu
5. The user sees the newly added name in their list of students, clicks on it, and is brought to the Class Management page
   1. In the event the user entered the name incorrectly they may click on the student's name and then click the d key to delete the student
6. The user enters the term and year the class was taken in, as well as the subject of the class
   1. ex: Term: Spring, Year: 2020, Subject: CIS
7. A list of relevant classes is displayed and the user clicks on the one taken by the student
   1. The recently selected class now appears in the Taken Classes list displayed on the screen and is saved in the database
   2. In the event the user selected the wrong class, they may click on the newly added class in the Taken Classes list to remove it
8. The user repeats steps 6-7 until all of the students taken classes have been added
9. The user may return to the main menu or exit the program

Postconditions: The student's data is saved by the system in a database and is readibly available upon the next use.

Case B: Updating a student's academic information

Figure 2.6.2 Dynamic flowchart diagram of Case B

Brief description: This use case describes an adviser updating a student's course history data in the system database so that they may be able to generate an up-to-date degree roadmap.

Actors: An adviser (the user).

Preconditions: The student being advised has finished new courses since first completing Case A or last completing the actions in this scenario.

1. The user launches Registration Tools and is brought to the main menu.
2. The user clicks on the name of the student they are meeting with and is brought to the Class Management page.
3. The user selects the term and the year the classes were taken in as well as the subject of the recently taken class
4. ex: Term: Spring, Year: 2020, Subject: CIS
5. A list of relevant classes is displayed and the user clicks on the one taken by the student
   1. The recently selected class now appears in the Taken Classes list displayed on the screen and is saved in the database
   2. In the event the user selected the wrong class, they may click on the newly added class in the Taken Classes list to remove it
6. The user repeats steps 3-4 until all the recently taken classes have been added
7. The user may return to the main menu or exit the program

Postconditions: The student's updated data is saved by the system in a database and is readibly available upon the next use.

Case C: Viewing major/degree progress and potential roadmaps

Figure 2.6.3 Dynamic flowchart diagram of Case C

Brief description: This use case describes an adviser using the system to generate and browse potential degree roadmaps for a combination of majors or minors that are a part of the student's saved profile.

Actors: An adviser (the user).

Preconditions: The student has an up-to-date course history in their profile (Case A/Case B). The user has selected and loaded the student's profile.

1. The user launches selects the 'degree roadmap' option.

2. The system initially displays a list of degree requirements that have been met and are yet to be met by the student being advised.

3. The user selects the 'create roadmap' option and the system asks the user to input conditions and constraints such as term to graduate by, maximum and minimum number of major courses per term, maximum and minimum credits per term. The user may also choose a different combination of majors and minors from what is stored in the student's profile.

4. The system generates multiple potential roadmaps for the student containing courses that the student will need to take and which terms they should be able to take them.

   (Information on which courses are offered during which term will be predicted using past data and may not be accurate.)

5. The user may show the generated roadmaps to the student being advised so that the student being advised may copy down an ideal roadmap or the user may export a roadmap in a file and send it to the student.

Postconditions: The generated roadmaps are saved by the system until new roadmaps with updated data or different constraints are generated.

3. Specific Requirements

3.1 External Interfaces (Inputs and Outputs)

Inputs

Classes Offered

• Description: This is a website that has all the data pertaining to the class schedule of a term that the system will be scraping data from
• Source of input: https://classes.uoregon.edu
• Destination of Output: A discrete location in the user's Documents directory
• Valid Range of Input: Once the parsing module has been implemented, the website may not undergo HTML structural changes
• Units of Measure: N/A
• Import Data Format: HTML
• Export Data Format: .json file

Major Requirements

• Description: This is a website that has all the data pertaining to the requirements of a specific major
• Source of input: http://catalog.uoregon.edu/majors/
• Destination of Output: A discrete location in the user's Documents directory
• Valid Range of Input: Once the parsing module has been implemented, the website may not undergo HTML structural changes
• Units of Measure: N/A
• Import Data Format: HTML
• Export Data Format: .json file

General Requirements

• Description: This is the website that has the general requirements a student must have in order to be eligible for graduation
• Source of input: https://registrar.uoregon.edu/current-students/bachelors-degree
• Destination of Output: A discrete location in the user's Documents directory
• Valid Range of Input: Once the parsing module has been implemented, the website may not undergo HTML structural changes
• Units of Measure: N/A
• Import Data Format: HTML
• Export Data Format: .json file

Outputs

Student Major Shortlist

• Description: This is the file that stores the major(s), as entered by the student in ([Case A](https://github.com/ryangurn/_Registration Tools_/wiki/Software-Requirements-Specification#case-a-first-launch))
• Source of input: User input
• Valid Range of Input: The major must be recognized as an official major by the system
• Destination of Output: A discrete location in the user's Documents directory
• Units of Measure: N/A
• Data Format: .txt file

Completed Class List

• Description: This is the file that stores the classes, as entered by the student in ([Case A](https://github.com/ryangurn/_Registration Tools_/wiki/Software-Requirements-Specification#case-a-first-launch)/[Case C](https://github.com/ryangurn/_Registration Tools_/wiki/Software-Requirements-Specification#case-c-importing-a-new-transcript))
• Source of input: User input
• Valid Range of Input: The classes must be recognized as an official class by the system
• Destination of Output: A discrete location in the user's Documents directory
• Units of Measure: N/A
• Data Format: .txt file

Roadmaps

• Description: This is the file that stores the user's selected roadmaps so that they may be viewed at a later time
• Source of input: User input
• Valid Range of Input: N/A
• Destination of Output: A discrete location in the user's Documents directory
• Units of Measure: N/A
• Data Format: .txt file

3.2 Functions

1. Generate Graduation Path - This function will take a given major from user input and check if it is a valid major at the University of Oregon. If it isn’t, the system will prompt the user to re-enter a valid major. This function will then check the UO web degree requirements of the major(s) and will generate a class hierarchy to determine importance of each class. Once generated for each major/minor, the function will link common classes that share the same importance, and group them based on prerequisite information and quarters offered. The function then displays a visual representation of the classes (color coded) needed each quarter in order to graduate. The student has the option to interact with each class generated in the path, as well as the option to save the current state of their path to load later on.

• Response to abnormal situations: If for some reason a prerequisite class isn’t offered in the class database, or a database isn’t updated, the system will use the last instance of a successfully generated database that will be stored locally with every secure connection.

2. Save Path - Saves the class hierarchy list that was generated from the Generate Graduation Path function with any class complete/incomplete states that the user added/removed. This function is stored in a database for whenever a path wants to be loaded again.

   Response to abnormal situations: There might be a corrupt save, which would in return export the printable ".txt" file for the user instead to use for loading whenever they want to view their graduation path again.

3. Load Path - Loads the class hierarchy list that was saved upon previous use of the system in the database. This function prompts the user to select the previous list from all entries in the saved database, and then returns the list in the same format for the computer to read again to generate the visual path for the user. This will keep in mind the classes the user had previously declared as "finished" as well as unlocks new classes that the user is eligible to take. Resumes the current state that the system was in upon previous use.

   Response to abnormal situations: In the event that the system is unable to load from the program itself, the user can import the generated ".txt" file for the system to parse.

4. Export Plan - The function takes the current state of the system (Assuming the graduation path has been generated), and initially checks to make sure that a path has been generated. The button will be unaccessible until a graduation path has been generated. The software will take the list of classes that were used to create the on screen visual output (generated by the generate graduation path function), and write it to an easy to read “.txt” file for the student to be able to reference. The system will do this to via the use of python’s standard file I/O functions from the python standard library.

   Response to abnormal situations: If for whatever reason there’s an error writing the file, then the system will display an on screen version of what would have been printed, and will give instructions on how to copy and paste the data into a savable document. We don’t expect that to ever be the case, but it’s a nice feature to have if that ever ends up happening.

3.3 Usability Requirements

All functionality of the program must be completely usable through a GUI from startup. At no point should an intended user that is not a developer need to access a terminal or console interface to use the system.

The system must produce text based outputs of its generated information in tandem with its graphical representations.

At any point the student may abort the application without corrupting the application’s existing data such that it cannot be restored upon re-initialization.

The system will periodically scrape data from the course requirements page, as well as UO class data that’s publicly available. This information is stored to a local backup upon every data scrape in the event that there is no connection.

After generating a set of roadmaps, the student will have the option to generate a new set of roadmaps using a different combination of majors and minors and different constraints, all without restarting the system.

The system will allow the student to directly interact with their visually displayed roadmaps. For example, students may be able to click on the classes on their path to add those courses to their watchlist.

3.4 Performance Requirements

The system must startup within approximately 3 seconds of clicking the application icon and display the essential elements of the GUI such as buttons and labels upon startup.

The system must always attempt to achieve its primary functions using the most recent data it can gather. Even if the system fails to gather data automatically or the user does not keep their information up-to-date, the system shall still make use of (potentially outdated) locally stored data whenever possible to provide its functionality.

The student must be able to get a generated class schedule path visually drawn out within 5 seconds, and written to a text file within 3 seconds.

The system shall automatically attempt to gather the most recent course information at startup and require no manual user input for maintaining an up-to-date database other than the student's course history.

3.5 Software System Attributes

Overall, this system must be very user friendly and reliable so that any student, regardless of their technical background, can use it easily and intuitively to check what classes to sign up for.

• The product must not only be easy to use for the students, but it also has to be easily maintainable by any administrative staff that might not have a strong background in programming as well.

• We don’t want to have a situation come up where a student runs into an error due to a scenario that we hadn’t thought of.

This requires extensive troubleshooting on our end, and we plan on rigorously testing this through the following cases:

• The student is undeclared The student doesn’t want to take summer quarters, and the desired classes are full for that particular quarter, and the system can update classes for all quarters. If for whatever reason a user does encounter an error with our system, we want to make it very clear as to why the error had occurred, and prompt them to redo and continue any requirement they might have forgotten to fill out.

Our software is intended to continue to run regardless of any errors a user might encounter such as an invalid degree audit, or an invalid/ unrecognized major/ schedule conflict. Our files will display mappings and timelines of the future courses in app that can be exported as a text file for our users to reflect on when registering for classes.

Security is a very important factor as well. We don’t want someone being able to access the database to release the student’s degree audit information (GPA, Name, Age, etc.).

• We plan on using a variety of encrypting techniques and secure storage techniques in order to ensure that the student’s information is safe, and that unauthorized personnel can’t change the class information with incorrect information.

Because this information is always going to be updated by school administrators, we need it to be easily updatable. This is going to be implemented by having the administrative users being able to change the class information on the main website then having our software have monthly scans that scrape all of the class data for any changes and updates. If there is any change in the way the “UO classes” data is organized, it can easily be changed by an administrator to change how we parse the selected information. This should allow an easy to maintain system that students can reliably use to gain knowledge into what classes they still need to take.

4. References

Krüger, Nico. “How to Write a Software Requirements Specification (SRS Document).” Perforce Software, www.perforce.com/blog/alm/how-write-software-requirements-specification-srs-document.

Vasalli, Kevin. “Collaborative ENotebook Research Testbed Software Requirements Specification.” Team Green Apple, 2005, www.se.rit.edu/~greenapple/docs/example%20SRS.doc.

5. Acknowledgements

This document is built directly upon a template provided by Anthony Hornof, produced by him in 2019. That template itself was built slightly on another document produced by Stuart Faulk in 2017 as well as other publications.