Software Requirements Specification Document

1.0. Introduction

1.1. Purpose
The purpose of this document is to present a detailed description of the Student Management Information System. It will explain the purpose and features of the system, the interfaces of the system, what the system will do, the constraints under which it must operate and how the system will react to external stimuli. This document will be submitted to the institute and stakeholders for approval.

1.2. Scope of Project

This software system will be a Student Management Information System for CDAC institute. It will be designed to alleviate the administration’s work load by providing tools to assist in updating the students’ information and other processes, which would otherwise have to be performed manually. It will also enable the administration to hold details of their students’ attendance, the courses, exams and assignments matters together with details of payments. Hence, the system will be able to offer a better personalized service and meet the institute’s needs while remaining easy to understand and use.

1.3. Glossary

1.4. References

IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society, 1998.

1.5. Overview of Document

The next chapter, the Overall Description section, of this document gives an overview of the functionality of the product. It describes the informal requirements and is used to establish a context for the technical requirements specification in the next chapter.
The third chapter, Requirements Specification section of this document, is written primarily for the developers and describes in technical terms the details of the functionality of the product.
Both sections of the document describe the same software product in its entirety, but are intended for different audiences and thus use different language.

2.0. Overall Description
2.1 System Environment

The Student Management Information System has three active actors. They access the entire system directly.

Lecturers:
They will teach the respective students their different modules. The lecturers will insert the students’ attendance. Next, they should insert any relevant works, skills, assessments, points or any progress of each student.

Administration:
The administration deals with the day to day running of the institute. They will attribute lab to the lecturers, they will keep a list of all the student will their related details of the CDAC Institute, they will have to search the records for payments due and inform each student about it. In addition to these, they are the one responsible to insert records concerning any formal marks obtained by the students; their exams grade (pass or failures), final term and year grade and comments.
They will then mail all these information to the respective lecturers and managers to keep them updated for them to make a follow up of the students’ progress and regularities in their payments respectively.
It should be noted that it is not the administration who deals with the payments transactions but indeed, they get inform from the University Of Mauritius Head Office where all payments are done. The CDAC administration will only receive tracks of the payments made by the students according to their months due and current months.

Program Coordinators:
As far as the program coordinators are concerned, they will remain in contact with the University of Mauritius. They are to get all the necessary and important information of all that goes on within the institute; starting from the attendance, the student profile, tracks of payment and all the exams day, date, time, modules, assignments topics and results.

2.2 Product Features
Dataflow Diagram








The proposed system will:
o Enable administration register, delete and find student records.
o store details about the students actually studying in the CDAC institute, including their personal details, whether they are full-time or part-time students, a progress sheet where information about their exams marks will be will be recorded and
o include all essential data on the courses offered; the modules and the respective lecturers, the different batches of the courses will also be available,
o keep payments follow ups up-to-date.
o Allow lecturers to record attendance of the students.
o Enable the lecturers to insert progress of students as their assignments marks.
o display exams, date and time scheduled, assignments title and markings.
o allow program officers to validate students’ results.
o also included a list of classes schedules created by the administration.
o Produce reports as:
. List of student progress
. List of exams schedules
. List of exam results
. List of attendance
. List of payments follow-up
. List of results statistics
. List of the assignments marks
. List of batches
. List of classes
. List of debtors
. List of lecturers
. List of modules to be accessed by both the administration and the program coordinator
o give access rights to the different actors.

Eventually, the new system will enable the lecturers and the administration to save time because the proposed system will consist of a shared database to allow all the people involved to access it so as to insert, retrieve, delete and view all the information needed. There will be individual input of the information at a specific time of the day so as all the information is updated as efficiently as possible.
2.3 User Characteristics
The staff is expected to be Internet literate and be able to use the email with attachments. They are also expected to be Windows literate and to be able to use button, pull-down menus, and similar tools.

The main screen of the SMIS will have the following options:
1. Administration
2. Lecturer
3. Program Officer
4. Exit Program
To choose an option, just click on the desired one and the respective menu will be displayed.

2.4 Non-Functional Requirements
The physical machine to be used will be determined by the Institute. The speed of the Internet connection of the Institute will depend on the hardware used rather than characteristics of this system.
The Program Officer will run on the Institute’s PC and will contain an Access database. Access is already installed on this computer and so is a Windows operating system.
3.0 System Features

3.1 Register Students

3.1.1 Description and Priority

A student may want to enroll for a particular course and administration will carry out the registration process. After registration the student may want to cancel or change his enrollment if necessary.
Priority = HIGH.

3.1.2 Stimulus/Responses Sequence

3.1.3 Functional Requirements
1) On request of students, administration will access the system for registration.
2) The system will ask for student information, such as student id, name, address, phone number, email, etc.
3) Errors will occur if some information is omitted.
4) The system will again ask for complete information.
5) On completion, system will display student has been enrolled.

3.2 Schedule Class

3.2.1 Description and Priority
Administration will schedule class or lab for each lecturer for a particular module. Priority = HIGH.

3.2.2 Stimulus/Responses Sequence

3.2.3 Functional Requirements
1) Administration will choose to search by lecturer id, lecturer name, module id, module name, batch id and name.
2) The system will display the resulted search.
3) Administration will do the necessary scheduling of classes in either lecture room or lab.
4) The system will generate an error if lecture room or lab already taken for another lecturer.
5) Then the system will ask for re-scheduling.

3.3 View/Print Report

3.3.1 Description and Priority

Administration may need to view reports such as exam details, payments and print them. Priority = HIGH.

3.3.2 Stimulus/Responses Sequence

3.3.3 Functional Requirements
1) Administration will search for exam details and payments details.
2) The system will display the requested report.
3) Administration will either view it or print it using the print command provided by the system.
3.4 Insert Exam Details

3.4.1 Description and Priority

Administration will enter details for each exam depending on module being examined for and which batch is taking the exam. Priority = HIGH.

3.4.2 Stimulus/Responses Sequence




3.4.3 Functional Requirements
1) Administration will choose to search by batch id, module id.
2) The system will display the resulted search.
3) Administration will enter exam time, date and location.
4) If one of the above information is omitted, the system will prompt administration for complete information.
5) On completion the system will generate report about exam details.

3.5 Insert Lecturer Details

3.5.1 Description and Priority

Administration will enter details for lecturers if new lecturer or will make changes to lecturers’ details. Priority = HIGH.

3.5.2 Stimulus/Responses Sequence
3.5.3 Functional Requirements

1) If a new lecturer is joining the institution, administration will enter details such as id, name, address, module conducted, etc.
2) The system will save the details if all information are correct and complete.
3) Administration may also need to change certain details for existing lecturers, for example address or phone number.
4) The system will then do the necessary updates.

3.6 Deals with payments

3.6.1 Description and Priority

Administration will deal with payments of students and will also account for those students who have not yet paid. Priority = HIGH.

3.6.2 Stimulus/Responses Sequence

3.6.3 Functional Requirements
1) Administration will search for student id making payments.
2) The system will display the resulted search and make the necessary updates, that is, record that student which has paid.
3) Then the system will generate a report for already made payments.
4) A report for students who have not yet paid will be generated also.

3.7 Insert Batch Details

3.7.1 Description and Priority

The program coordinator will insert batch information on creation of new batch. Changes can also be made for existing batches. Priority = HIGH.

3.7.2 Stimulus/Responses Sequence

3.7.3 Functional Requirements
1) For a new batch the program coordinator will have to enter batch details such as batch id, name, full time or part time, etc.
2) The system will save the recently entered details if complete and accurate.
3) Changes can also be made for existing batches which will then be updated by the system.

3.8 Validate Students’ Results

3.8.1 Description and Priority

The program coordinator will cross check students’ results and validate them. Priority = HIGH.

3.8.2 Stimulus/Responses Sequence

3.8.3 Functional Requirements
1) The program coordinator will choose to search by student id, name, batch id, module id. He can also view the exam results report.
2) The system will display the resulted search.
3) The program coordinators will then cross-check the results and enter either valid results or invalid results.
4) The system will then generate report about valid and invalid results.

3.9 View/Print Report

3.9.1 Description and Priority

The program coordinator can view reports (exam results, payments) and print it if necessary. Priority = MEDIUM

3.9.2 Stimulus/Responses Sequence



3.9.3 Functional Requirements
1) The program coordinator will choose which report he needs.
2) The system will generate the report and display the result.
3) The program coordinator will either view it or print it.

3.10 Insert Attendance

3.10.1 Description and Priority

The lectures will access the system to record the attendance of students. Priority = HIGH.

3.10.2 Stimulus/Responses Sequence



3.10.3 Functional Requirements
1) The lecturer chooses to search by student id, batch id, part time or full time students, module id.
2) The system will display the search results.
3) The lecturer collects the attendance and this is updated by the system.
4) The system can then generate report about attendance.

3.11 Insert Progress

3.11.1 Description and Priority
The lecturer will be able to insert progress of students as their assignments marks. Priority = HIGH.

3.11.2 Stimulus/Responses Sequence



3.11.3 Functional Requirements
1) Lecturer will search by student id, name, batch id, batch name, module id and module name.
2) The system will display the search and necessary insertion will be performed about progress.
3) The system will then generate report about progress sheet.

4.0 External Interface Requirements

4.1 User Interfaces

UI-1: The Student Management Information System screen displays shall conform to screens designed using Microsoft Access 2003.
UI-2: The system shall provide a menu form where users of the system can navigate throughout the whole system.
UI-3: The submenus shall permit complete navigation and information selection, insertion and deletion using the keyboard alone, in addition to using mouse and keyboard combinations.

4.2 Hardware Interfaces

As such, the software modules under development do not need to account for hardware interfaces. All interactions between hardware and software are in conjunction with DBMS and a server on the LAN.

4.3 Software Interfaces

The modules will utilize Microsoft Access 2003 from Microsoft Office Package which is also the suggested development tool. Apart from that users will be able to use Microsoft Word to type letters and internet explorer to access the internet for emailing purposes.

4.4 Communication Interfaces

Interfaces with network protocols will be handled by a LAN connection together with a network interface card connected to each and every terminal. Communication will be based on a request-response paradigm, that is, request to the server form the client and response to the client from the server.

5.0 Other Nonfunctional Requirements
5.1 Performance Requirements
Performance is a key issue in the design and development of a software. It is of utmost importance as this requirement will affect the other requirements of the system.

· The software is to be designed in Microsoft Access, both the front End, i.e. the forms and the back End, the database, so that performance level is not affected while trying to connect front end and back end together as it would be in 2 different software.

· The software must be designed in a way such that response time is minimal and the software reacts quickly to its environment.

5.2 Safety Requirements
Safety is another key factor in the design and development of the system.

· The product must be safe to use without resulting in any injury of any kind to the user.

· The software must provide safety measures so as to recover any data loss.

· Loss of data of any kind should not result in the use of the software.

· The software must meet the safety requirements specified in the IEEE standards.

5.3 Security Requirements
Security is an important aspect to take into considerations while designing and implementing software.

· The software must have security features so as to protect itself and the system on which it is going to be operated.

· Physical mechanisms as well as logical mechanisms should be implemented.

· Software must provide means for verification and authorization of users, for e.g use of IDs and passwords.

· Sensitive data should be accessed only by users with top priorities.

5.4 Software Quality Attributes
Program must also have key attributes which will make it a good software such as the following.

· Adaptabilityà Software must be adapted to work in any environment.
· Correctnessà Software must be correct so as not result into any harm to the system
· Flexibilityà Software must be flexible to accommodate for change.
· Interoperabilityà Software must be able to interact between other software.
· Maintainabilityà Software must be maintainable.
· Portabilityà The ability to transport the software on different systems.
· Reliabilityà A reliable program on which the client can count on.
· Reusabilityà Codes or parts of this program may be used in other software.
· Robustnessà The capacity to restart after failure.
· Usabilityà It must be user friendly.


6.0 Other Requirements
Other requirements are also necessary for the proper operation of software.

· International standards. Software must comply with international norms and standards.

· Privacy Laws. Software must be protected by the law.

· Software must be reusable. Must make use of object oriented methods.