In order to successfully complete my project, a number of objectives firstly defined at the start of the project:
- Investigate what the current student information systems of three different university schools are
- Produce a detailed requirement specification for the potential new student information System for general university
- Evaluate and analysis the requirement specification of the potential new student information module.
The minimum requirements of this project have been set in the beginning of the project. They are:
- Conduct a requirement specification from first principles that will be based around the generic requirement of a typical university school
- An investigation of potential customers (university school)
- Business process modelling and information capture requirement
- Providing evidence of investigation
- At least one presentation for summarise requirement specification
In order to deliver a successful and usable requirement specification for generic university schools, all those requirements not only be met but some are exceeded in the project. A detailed system requirement specification was generated eventually on the basis of four current system investigations.
One other successful software development is called RUP (FIGURE 2-1), which provides a central, common process definition that all software development team members can share, helping to ensure clear and unambiguous communication between team members (RUP, 2004). This helps the system developer to play the part expected of him in the project team by making it clear what his responsibilities are. Those tools enable better communication within the system develop team as well as eliminate the ambiguity. Therefore, RUP and UML will be adapted throughout the system modelling process.
CASE STUDIES OF CURRENT STUDENT INFORMATION SYSTEMS
Activities are placed in different permission zones in order to identify the particular users’ privilege of carrying out that activity. Students’ use cases are detailed in the FIGURE 3-2. the detailed use case descriptions see APPENDIX D.
Activities are placed in different permission zones in order to identify the particular users’ privilege of carrying out that activity. Student use cases with Nathan Bodington System are detailed in the FIGURE 3-4. Detailed use case description see APPENDIX E.
SIS is based on a post-greSQL. It is a single database. The main way that Banner interacts with SIS is through the script running automatically nightly. Data is imported from Banner then there is a separated program comparing the difference between those data. If any difference is found, then the data of SIS will be automatically changed to follow the Banner’s. Therefore, any changes made in Banner on students of SoC will update SIS’s records nightly. On the other hand, SIS also informally updates Banner with the exam results. So it appears as a two-way communication in the FIGURE3-6.
GENERIC STUDENT INFORMATION SYSTEM
This system modelling and requirements analysis apply to the university school’s Student Information System, which is going to be developed by Aquilo. The system will be installed and maintained at the university school level. The web based Student Information System will be available for both staff and students of that individual school to browse, and will provide them with different information authorizations from any Internet enabled computer.
As FIGURE 4-3 shows, student users of the new Student Information System must be able to at least view their personal details; they should be able to view the timetable as well. Based on different situations in different school, for example, various formats of the coursework required, they may be able to submit it electronically (if the school accepts electronic version coursework). The other enhancements would be the functions to view coursework results and module results, which will require the system not only recording the individual coursework results but also calculating the final results by combining the coursework and exam results.
The Class Diagram (FIGURE 4-4) shows the system from a technical perspective, allowing software engineers to start developing the system. 9 main classes have been identified which are Timetable, Module, Enrolment, Module Result, Coursework, Course work Schedule, Course work Result, University School and Member. (Student and Acedemic Staff are the sub-class of Member).
This chapter looks at how successful this project has been in terms of meeting the initial objectives and requirements of the study. The final milestone of the report is to evaluate the investigation as well as the new Student Information System for potential university school and suggest areas of further development from these conclusions.
As the objectives indicated, the product of this study is the requirement capture and analysis rather than system design and implementation. Therefore, we cannot judge directly from the outcomes from the first phase of the system development whether the development is success or not. Great a lot of work is left to the future system developers and programmers. A more sensible way of evaluate this kind of product will be assessing the way of carrying out the investigation and analysis in order to find out whether theoretical methodologies are appropriately used in practice and whether it can be improved.
In this Chapter, evaluation was adopted firstly through the product development in terms of meeting the initial objectives and requirements. They have not only been met but some of them are exceeded. Followed by assessing the studies by other three success criteria: user acceptance, functionality and user involvement. A few problems were identified and further enhancement was introduced. The reflections from students, lecturers and Aquilo system development team are positive and very encouraging. To sum up, the first phase of the system development – requirement capture and analysis is successful and the further development is promising.
Source: Leeds University
Author: Jilang Pan