Prepared by Leyla & Deo a.k.a twins

1. Software Requirement Specification for UDOM Students Academic Information System(SAIS) Presented by:- Leyla H.Liana Deo Shao

2. Introduction In recent years, the number of students admitted at the University of Dodoma has increased to almost twice as much, enrolling to various programmes ranging from certificates to higher degrees. This increased the need and the risk of managing student’s records. These could be mitigated through the use of a proper Management Information System for academics and admission. The system will offer registrars, managers, administrators, and lecturers the ability to easily retrieve, store, or report.

3. Problem Statement The increased number of students’ admission has led to inefficient organization and management of students’ records. The collectively processing of examination results has been tedious. Due to disorganization of the records, the timeliness of delivering examination results has been poor. The management of the interrelation between students and courses is tiresome in the current situation. The current system lacks privacy and integrity of records as the files can easily fall on the hands of a third party while exchanging and transmitting records.

4. Justification for the acquisition of the system The University of Dodoma Strategic Plan: To create a place where knowledge will be transferred from one generation to another. Goal: To the contribution of higher education in Tanzania’s attainment of economic growth, reduction of poverty and improved social wellbeing of Tanzanians through increased access to higher education, technological innovation, generation and application of knowledge. Vision: To become a center of Excellence that offers value added training, research and public services. IT Department Plan: To be an ICT Hub of East Africa

6. ROI=(Gain from investment-Cost of investment)/(cost of investment) From the above facts, we see that having this MIS for academics and admission is inevitable.

7. THE PROPOSED SYSTEM ARCHITECTURE

8. REQUIREMENTS CAPTURE AND ANALYSIS Requirements capturing tools Group Interview Most of these requirements will be collected using the Group Interviewing of the Admission office staffs, Examination office staffs, Lecturers of different colleges and students. The discussion will be done by the analysts, each asking different questions as possible to find out what are the requirements of the system. Studying of some of the used documents Some of the requirements will be collected through studying of some of manual files and reports, examination regulations, university strategies, missions and plans to get overview of the reality of what is required.

9. Actors of the system Vs Roles

10. Functional Requirement The system shall be able to register all new admitted students in each academic year The system shall be able to report individual students profile on bases of academic records The system shall be able to allow lectures and instructors to upload results of examinations The systems shall be able to manage coarse roaster for different study programmes The system shall be able to handle different grade scales for different study levels

11. Functional Requirements The system shall be able to generate different reports required by different examination approving boards including transcripts for published student's results. The system shall be able generate the yearly students admission book. The system shall be able to send examination reports to students through SMS. The system shall be able to generate student registration number.

12. Functional Requirements The system shall provide an interface for a lecturer to upload the students examination results for his/her respective course, that is CA and UE The system shall provide an interface for a student to view and/or print his/her results The system shall calculate and display GPA, grade and remarks for students’ results

13. Functional Requirements The system shall provide an interface for a lecturer to edit results before the results are approved by the University senate. The system shall allow students to see the grades of their course upon completion of the semester. Upon completion of the degree program the system will compute the overall GPA and process the transcript.

14. Non functional requirements The system will require 99.999% uptime to ensure maximum reliability Students should be able to view results via the web and through phones. The system shall provide an interface for administrator to manage users that is adding new users, disabling users and give respective privileges to users.

15. Non functional Requirements The system shall not allow students admission after the specified period is over The system shall not allow display of unpublished examination results The system shall not allow modification of published results The system shall not allow students to opt a course that is not in his/her curriculum The system shall not allow lectures to upload results before examination period is over

16. Non functional Requirements The system shall not allow students to views examination results of other student The system shall not allow students enroll for academic year after the limited number of years has reached The system should be adapt changes of curriculum without affecting the previous records Shall control the account of students and be able detect and lock the account when s/he graduates unless s/he repeats a year

17. Non functional Requirements The system will require students should have mobile phones so as be able to receive examination results in SMS form. The system will require to exchange information with SMS gateway server

18. Non functional Requirements The system shall be able to generate examination transcripts and provisional results The system should be able to manage courses offered by different colleges The system shall be able to manage students admission and enrollment in each academic year

19. USE CASES Student Use Case

20. USE CASES Registrar Use Case

21. USE CASES Examination office Use Case

22. USE CASES SMS Gateway Use Case

23. USE CASES System Administrator Use Case

24. USE CASE DESCRIPTORS

25. USE CASE DESCRIPTORS

26. USE CASE DESCRIPTORS

27. USE CASE DESCRIPTORS

28. Recommended approach The proposed MIS system has been divided into internal and external parts where by the internal part will be the overall system modules that will be hosted in UDOM servers, and the external part will be the SMS gateway module that will be dealing with mobile functionality of the system. In ensuring maximum efficiency in terms of economy and other facts we recommend different approaches to each part of the system.

29. Recommended approach Developing in-house is suggested acquisition method for the internal part of the system. Lease is suggested acquisition method of the external part.

30. Reasons of In-house Development Although it is expensive to develop the MIS from scratch in-house we suggest it as a method for acquisition for the core part of the system simply because the University of Dodoma is still growing daily and many changes to the systems to accommodate the growing are expected and un-avoided.

31. Reasons of In-house Development If the system will be developed in-house it will be easy to modify or adding some components of system with low maintenance cost. Having low maintenance cost is economic efficiency in the context of software development as it is usually said maintenance cost is always high than development cost.

32. Reason for Leasing The mobile application part is not the core part of the system therefore leasing will free the organization from the complexity of managing it and allow organization to deal much on managing the core part of the system. This will introduced the following key advantages Low total cost of ownership Easy and fast application deployment Help university on strategic use IT

33. METHODOLOGY During development of this system we will employ RAD (Rapid application design) approach in almost the whole project. This is because this system is huge and therefore needs much time in coding, therefore as planning, analysis and designing are delicate and sensitive stages of developing this system we would like to do it perfectly without rush before we come into codes where RAD will help us to simplify our job by minimizing time and compensate time spent in early stages. Therefore using RAD will help us to balance time and be within project time boundary.

34. Conclusion Based on the University of Dodoma strategic plan, goal, mission, vision and its IT Department plan, we see that the procuring of the MIS for academics and admission is an inevitable and vital decision to make. Examination of the Cost-Benefit Analysis using the Return On Investment shows that it’s economically feasible to acquire such a system. Thus the expected MIS for academics and admission should cater for the current problems and any challenges in the future.