Jalz,
First, good for you for taking the initiative and stepping up. People often ask how they can start a career in Business Analysis with no direct experience. What you are doing is how you do it!
You are on the right track and you have two major sources of "requirements". You have an existing system and you have system users.
It sounds like you've done a good job of getting info from the system users. Remember, they are going to highlight the big stuff such as what they really like or don't like. But you need to replace this system so you still need to go through the system, system documentation, and user guides to be sure you have documented ALL of the necessary features.
One word of advice. Requirements should be system agnostic. When you write a requirement DO NOT assume that the system will solve the problem in a specific way. There are often many ways that a system can fulfill a requirement. This is the most difficult aspect of writing good requirements. When you begin documenting which software packages have the right features this will become very important.
Another pointer when documenting requirements is to ALWAYS include the rationale from the users perspective. This is WHY the user needs that requirement. As project continue requirements that once seems clear become confusing when read. Did we me "A" or "B" when this was written. The rationale, or the WHY, helps the reader to understand the intent of the requirement.
Finally, document who needs the requirement. Not the specific person but their role. Roles would be things like Professor, Dean, Parent, Advisor, etc.
Most requirements documentation and categorization are handle with simple spreadsheets.
Also realize that systems have features, and each feature can support multiple requirements. They are not 1:1.
There is no single template for this type of work. Every company uses what work for them. You can also group your requirements in a lot of different ways. But one common way is by user goals (also call use cases). I'll keep calling them user goals/user cases describe what the system should do to provide a specific value back to the user. You cited an example of this "Make inquiry to school". You may want to specify the type of inquiry. I don't know your system well enough to tell you. However that single user goal can fulfilling 5, 10, or more detailed requirements. Each use case can have actors mapped to it. Actors can initiate or kickoff a use case. They also can provide information to the use case.
I don't want to get into to much detail on use cases. There is a lot of information available on them. But I will say you should think about use cases in three parts. The use case name (example: Make Inquiry to School), the use case description (a one to three sentence description of what the use case covers), the use case specification (one to many pages outlining the step by step interaction between a user of the system and the system response). Not all literature uses references these three parts the same way so be careful to understand what they are talking about. Also, for what you are doing I would complete avoid creating part 3, the use case specification. These create a lot of over head and for beginner analyst are more problematic than helpful. There are many project where I choose not to create use case specifications and I've been doing this stuff for over 15 years.
OK, that's probably enough for now ;)