User Tools


STUDENT REGISTRATION MODULE

System Requirements Specifications(SRS)

1. INTRODUCTION

1.1. Purpose

This purpose of this document is outlining required features and acceptance criteria of MU Student Registration System which DICT has tasked to design and develop.This document facilitates assessing deliverable and quality assurance of system to be developed.

1.2. Scope

MU Online Students Registration System will be a web based platform which will be used for managing students registrations tasks at all campuses of Mzumbe university.

1.3. System Overview

For some time now Mzumbe University has been using the SARIS system in the registration of students. This system enabled generation of students’ registration number and has been used by the Income Section for various reconciliation of tuition fees. The system however, was not configured yet to capture registration of students by enabling students to register themselves electronically rather it required so much manual work to be used. Therefore, there has been a cry from the admissions office and other offices that deal with various students’ data to have a fully operational system that will deal with registration of students and which will help in facilitating smooth registration of new and continuing students. Generally, there is a need to have a system that will track: -

  1. Total number of enrolled students in each Semester
  2. Students with special needs/disability
  3. Foreign students (students with foreign nationalities)
  4. Total number of students on field study
  5. Approved postponement of studies
  6. Approved postponement of examinations
  7. Total number of students who completed Tuition fees and hence eligible for examinations
  8. Students with partial payment of tuition fee
  9. Deregistered students
  10. Discontinued students
  11. Students living with campus hostels and those housed at off campus
  12. Students whose studentship has expired by reasons of expiry of years
  13. Students who completed their studies successfully.

To address above challenge,DICT through its Department of Software Development and Application, has tasked to develop an online student registration system which will help students on campuses, off campuses and out of country to easily and inexpensively take advantage of registration services provided by admission offices,Faculty and schools which today require users to be on campus during business hours.

1.4. Intended Audience

This system will be used by new admitted and ongoing students of Mzumbe University.It will also be used by authorized staff from various units of University from Campuses,Schools,Faculty and Directorates.

1.5. Intended Use

Management of various aspects of students registrations at Mzumbe University which inludes and not limited to:

  1. registration of new students
  2. registration of continuing students
  3. registration of credit –transferred students
  4. handling requests for postponement of studies
  5. resuming studies after postponement of studies
  6. handling requests for postponement of examinations
  7. handling requests for waiver of a minimum amount of Tuition fee for registration
  8. deregistering students for various reasons
  9. discontinuation of students

1.6. Definitions and Acronyms

Term Description
SRS Software Requirements Specification.
MU Mzumbe University.
DICT Directorate of Information and Communication Technology.
SARIS Students Registration Information System.
New Student Student admitted in First semester for the first time to one of the programme at Mzumbe University.
Continuing students Student who were admitted and are going with studies in various semesters.
SFR Students Functional Requirements
AFR Admission officer Functional Requirements.

1.7. References

2. OVERALL DESCRIPTION

2.1. System Perspective

This system is designed to be accessed via variety of devices from Personal Computers,Laptops,tablets and Mobile phones.It is also OS independent,that is it will run on various operating systems such as Linux, Mac OS and Windows. The only requirement for the user is a web browser (Google Chrome,Safari, Firefox or Internet Explorer) with an active internet connection. MU Online Registration system stores the following details: Students details: Among others,this system stores students details which includes:students names,registration number,programme,semister,nationality,academic year.It also gives various reports such as total number of enrolled students in each Semester,discontinued students,deregistered students,students who completed their studies successfully,students with special needs/disability and total number of students who completed Tuition fees and hence eligible for examinations.

Staff details: Among others,this system stores staff details which includes:PF number,names,unit,department,title and role.

Programme details: It stores the following programmes details:Programme name,code and campus.

2.2. System Features

This Online Student Registration system is expected to capture and offer the following features:

  1. User Management.
  2. Registration
  3. Post-pond
  4. Resume studies
  5. Deregistration
  6. Online Payment.

2.3. Design and Implementation Constraints

System Architecture: This System will be built using two main architectural patterns:Model-View-Controller (MVC) architectural pattern and Three Tier Client/Server Architecture.

Framework: System will be implemented using a popular Python Framework called Django.

Database: PostgreSQL relational Database management system will be used for data PostgreSQL is open source and general purpose and object-relational database management system.

Interoperability: This system is expected to retrieve information from other systems such as NACTE,NECTA and Banking operations through Government Payment Gateway.Thus the design has considered this interoperability scenario.

Scalability: This system will be designed to scale once new demands will arise such as adding accommodation module.

2.4. User Characteristics

This system will have many users classified into following categories:System administrator,student,admission officer,lecturer,bursar and proctor(supervisor).Each user has different level of privileges from another.

Admin-This is an MU employee. This person can perform all privileged tasks includes: add new user,perform various system settings,view various reports.

Student - This is admitted or continuing students who pursuing various degree and non-degree in one of MU offered programmes. Student will login on the system using given credentials:once loggen in,he/she can verify his/her particulars,edit some details except those retrieved by the system from other sources such as NECTA and NACTE, register for particular semester by completing all needed registration steps including uploading birth certificate,academic certificate and medical report for new admitted students..

Admission Officer- This is an MU employee.This person can log into the system, upload the list of all selected candidates , view and approve information and documents submitted by students for registration.

HoD-This is MU academic staff who has officially appointed as Head of a particular department in academic Unit.Among other roles,This user will be able to views various students inquiries such as postponement of studies,approve and forward them to responsible managerial personnel in the Unit.

Bursar-This is an MU employee working in Directorate of Finance.This person has various roles on the system including bill creation and approves various payments made by students.

Apart from above mentioned categories of users,the following officers will have access and different privileges to the system for various management decisions:

  • The Vice Chancellor and Deputy Vice Chancellors.
  • Principals/Deans/Directors.
  • Principal Admission Officer.
  • Principal examination officer.
  • Head of Income Section.

2.5. User Documentation

User documentation will be made available as user manual once the system will be deployed.This manual will include:

  • how to use this system.
  • Various features of system for end user.
  • FAQs.
  • Contact for support.

3. SYSTEM FEATURES AND REQUIREMENTS

This part specifies the requirements for MU Online Registration System.These requirements have collected from various stakeholders.Thus they are grouped by their stakeholders, and functional and non-functional requirements. The stakeholsers for this system are classifies as:

  • New Students.
  • Continuing Students.
  • Admission Officers.
  • Income section
  • MU Administration
  • System Administrator

3.1. Functional Requirements

3.1.1. Functional Requirements for New Student

Requirement Number Description
SFR1: The system shall enable students to login and verify his or her particulars such as .
SFR2: The system shall enable students to edit some particulars such as Gender and date of birth.Student should not be able to edit the programme.
SFR3 The system shall be able to let students upload academic certificates and other documents such as birth certificate,medical report,and picture(passportsize).
SFR4 The system shall enable verified students to get control number for payment of tuition fee.
SRF5 The system shall alert students on registration status.
RSF6 The system shall send notification emails or SMS to students on registration confirmation or rejection.
SRF7 The system shall allow student to request postponement of studies.

3.1.2. Functional Requirements for Continuing Student

Requirement Number Description
SFR1 The system shall enable students to log into their respective accounts which they created in their first year of studies.
SFR2 The system shall enable verified students to get control number for payment of tuition fee.
SRF3 The system shall alert students on registration status.
SRF4 The system shall send notification emails or SMS to students on registration confirmation or rejection.
SRF5 Student should be able to register for a semester upon payment of initial prescribed amount within registration period.
SRF6 The system shall not allow student who was deregistered/discontinued in the previous year/semester to register himself/herself.

3.1.3. Functional Requirements for Admission officer

Requirement Number Description
AFR1 The system should enable the admission office, that is, the Principal Admission Officer or any such other officer that will be duly authorized to upload the list of all selected candidates in the system in order to facilitate the start of registration. Only candidates who are in the list of selected candidates will be allowed to register.
AFR2 The system shall enable admission officer/any authorized registration officer to verify the uploaded certificates and confirm if the candidate duly qualifies for the programme so selected.
ARF3 The system shall enable admission officer/registration officer to inform the candidate if there is any missing document that need to be uploaded.
ARF4 In event the candidate does not qualify for the programme selected, The system shall enable the admission officer/any authorized registration officer to inform the candidate and offer to the candidate an opportunity to change the programme if that is possible.
ARF5 The system shall enable admission officer to Confirm student registration.
ARF6 The system shall enable admission officer to upload into the system the details of all accepted inter-university transfer requests to allow them to login into their respective account and continue registration process.

3.1.4. Functional Requirements for Income section

Requirement Number Description
IFR1 The system shall enable Income section to see and verify the payment to enable student to move to next stage.
IFR2 The system shall enable income section to create bills for tuition fee payment.
IFR3

3.1.5. Functional Requirements for System administration

Requirement Number Description
SAFR1 Total number
SAFR2
SAFR3

3.1.6. Functional Requirements for MU Management

Add Content here

3.1. Non-Functional Requirements

3.2. External Interface Requirements

4. ACCEPTANCE CRITERIA

4.1. Validity Check

4.2. Consistency Check

4.4. Completeness Check


Basic Concepts

Project

Project is a top-level element stored as a single file (.mdj). Modeling a software system requires describing multiple models because it is not enough to describe the system with a single perspective, so we typically make multiple models such as Use-Case Model, Design Model, Component Model, Deployment Model, or others in a Project. Typically Project is organized as a set of UMLModels, UMLPackages, or UMLSubsystems. If you want to know more about UML Elements, please refer to OMG UML Specification.