Professional Documents
Culture Documents
The candidate confirms that the work submitted is their own and the appropriate credit has
been given where reference has been made to the work of others.
I understand that failure to attribute material which is obtained from another source may be
considered as plagiarism.
(Signature of student)
Acknowledgements
The completion of this project owes a great deal to the help, advice and assistance given by
numerous people along the way. Primarily, I must thank my supervisor, Mr. Owen Johnson,
who has been unfailingly helpful and always available to assist me with my problems.
Secondly I would like to thank everybody with School of Computing, Leeds University
Business School and Shanghai University of Finance and Economics whom I interviewed or
received information from. They are:
Dr Les Proll
Dr Sarah Fores
Mr. Jonathan Ainsworth
Mr. Owen Johnson
Dr John Stell
Miss Millitza Callinan
Mr. Nicolas Forsans
Mr. Tony Jones
Mr. Paul Wheatley
Mrs. Haiying Zhao
Miss Ye Gong
Miss Jin Xu
Jilang Pan
April 2004
II
Summary
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
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.
III
Table of Content
Acknowledgements ......................................................................................................... II
Summary ............................................................................................................................. III
Chapter 1 Introduction....................................................................................................1
1.1 Introduction of the project ................................................................................................1
1.2 Objectives, Requirement and Scope of this studies..........................................................1
1.3 What is a Student Information System .............................................................................2
1.4 Why do university schools need Student Information System? .......................................2
1.5 Structure and Milestone of the project .............................................................................3
References...........................................................................................................................38
Appendix A ........................................................................................................................39
Appendix B Interview Scripts ..................................................................................41
Appendix C Requirement Specification for New Student Information System
..................................................................................................................................................48
Appendix D Requirement Specification of SIS ...............................................73
Chapter 1 Introduction
This chapter explains the project objectives and the scope of the investigation. The problem domain is
described, the key terms are introduced and the structure and format of this report are briefly
summarised.
Investigate what the current Student Information Systems of three different university schools
are. Those chosen systems are: School Information System (SIS) in School of Computing
(SoC), System in Leeds University Business School (LUBS), Student information System in
Shanghai University of Finance and Economics (SUFE).
Produce a detailed requirement specification for the potential new Student Information System
of general university school
Evaluate and analysis the requirement specification of the potential new Student Information
System
Within those objectives, the scope of the project has been set. Those three Student Information
Systems will be carefully investigated. Due to the vague boundary and relation between university
schools sub-system and university wide system in China, the system in SUFE will also be
covered in the investigation to generate a more interesting comparison of three Systems and
hopefully, some useful mutually improvement recommendations can be made eventually.
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
In order to deliver a successful and usable requirement specification for generic university schools, the
modelling of those three targeted Student Information Systems and their comparison and evaluation
will be critical to the success of this intention.
Student information system literally means the general information systems for maintaining and
providing student information. It exists in all the schools, colleges, universities and any other
education institutions. However, those information systems vary. Some of them are paper based;
heavily manual work is involved in managing and maintaining information such as student personal
records files. However, recently, most schools, even down to the very smallest, utilize computers in
some way or anther. The uses to which the computers are put vary enormously, ranging from word
processing and spreadsheet through to worldwide on-line access, complicated user access permission
system and vast functionalities.
The overall objectives of the study can be broken down to produce a set of milestones that become
achievable as the project progresses. The first milestone will be the background research phase which
clears which system develop methodologies will be used throughout the system requirement modelling
and how this can be achieved (all dealt with in Chapter 2). The next milestone is the actual system
requirements capture phase (Chapter 3). Then comes the outcome phase to show the product of the
project (Chapter 4). Last comes the analysis phase, which dealt with the systems analysis as well as
the outcome evaluation (Chapter 5). Detailed project schedule see APPENDIX A
In contrast to "Waterfall" method, RAD methodology (also known as the Spiral or Iterative methods)
breaks the development process in cycles each containing multiple development phases (Stapleton,
1997). For example, often, 80% of the system functionality can be accomplished with 20% of the
development effort during the first project cycle. The remaining functionality and improvements can
be implemented during subsequent cycles. The advantages of RAD methodology include greater
flexibility for scope changes, being able to identify limitations earlier in the development process, and
to deliver partial functionality sooner than with "Waterfall" method.
OO Approach :
Object-Oriented (OO) technology has been heralded as a solution to the problems of software
engineering. The claims are that OO technology promotes understandability, extensibility,
resolvability, reusability, and maintainability of systems, and that OO systems are easy to understand
and use (Bennett, 2002). It has been applied widely in the past for mapping from real-world problem
to abstractions from which software can be developed effectively. Moreover, the object-orientation
Waterfall
development method
Iterative/prototyping
method
Object Oriented
method
SSADM
RAD
Unified Process
(UP)
uses
UML
FIGURE 2-1
RUP
Criteria
of
Comparison
Responsiveness
to
environment
Team dynamic and
creativity
Final
product
determination
Completion date
Project flexibility
Communication in
the team
Probability
success
of
Waterfall Method
RAD
OO Approach
Throughout the
project
Unlimited during
iterations
Set during project
Throughout the
project
Unlimited during
iterations
Set during project
Semi-structured
Communication
during each iteration
Flexible
UML enables sharing
of information
High
High
Limited
Determined during
planning
Determined during
planning
Structured
Follow the plan
rather than
communicating
Low
As the table shows, OO approach gets many better features than the others, though waterfall and RAD
are also widely used system approaches. In this project, I am undertaking requirement analysis phase
rather than the entire system development; therefore, the flexible OO approach will definitely be more
suitable. However, the RAD theory of MoSCoW rules (Stapleton, 1997) will also be adapted during
the common user requirements selection. Method will be detailed in Chapter 4.2.6 Business context.
The whole study will also take advantages of the SSM to involve users in the development phase in
order to increase user acceptance eventually.
Another reason for choosing OO approach is that OO approach is also associated with various
development tools. UML could be a very good example that can be applied in various system
development environments.
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.
The second part of the information required addresses the objectives of this project. In order to review
the proper strengths of each existing system followed by applying the improvement to the new student
information system, researches into system analysis and system failures will be required. A
comparison of the existing system is also vital for generating the generic system requirements
Where possible, hands on the system gives the actual perception from the user s point of view.
Personal use of the systems will be used to help identify the current functionalities available to that
2.4.1.2 Interviews
Interviewing is probably the most widely used fact-finding technique; a well-structured interview with
a right member of staff will enable the necessary facts to be gathered. It can provide required
information from staff s perspective. If I can find the staff who manages the current system, some
system s technical details may also be gathered. However, it is also the one that requires the most skill
and sensitivity, therefore, enough preparation before the interview is crucial to the success. Guidelines
should also be followed. Bennett et al (2002) provide useful and detailed guidelines for interviewer to
adopt before, at the start of, during and after the interview. Due to the distance barriers, some
interviews should also be done through e-mail or telephone. Core questions will be asked, answered
and understood for each system. Details about interviewees who were involved in the system
investigation as well as the questions asked will be provided in appendix B interview scripts
3.1 Introduction
In this chapter, the investigations of those three chosen systems will be presented respectively. During
the unfolding of each system, details of technology, architecture, business requirement strength
weakness etc will be listed. That information is mainly gathered from personal use and interviews.
Technology: Dynamic web information system provides updated and accurate information to both
students and staff. Modern IT technologies are used within the system integration and database
management to provide as much information as the system can to the end users.
Architecture
Ingres
MySQL
Student Handbook
Access
Students
Access
Placements
Access
Access
Perl scripts
Undergraduate admissions
Access
MSc admissions
Access
Word
Research Publications
Access
Room booking
Microsoft Schedule+
User Environment:
The user will be accessing the system via a connection to the Internet. This is most likely to be from
home or Lab, which are the excellent baseline, as this category includes the slowest types of Internet
connection. However, the staff may normally use the system at work from the university s PCs and
network while they are working.
Person
Log On
Member of School
General Staff
Coursework Marking
Online Report
Administration zone
Administration Staff
Update Timetable
Student zone
Student
FIGURE 3-1
11
detailed
student use
case diagram
in SIS
<<include>>
View Timetable
Student
<<include>>
<<include>>
FIGURE 3-2
The student information of LUBS is the third system that I investigated. The reason I discuss it here
after SIS is because they have some similarities that I do not need to repeat myself.
12
Name
Architecture
Admission database
Gent
Microsoft Access
UG student database
Microsoft Access
Microsoft Access
Microsoft Access
Microsoft Access
Exam system
13
Log On
General Staff
Coursework Marking
<<semi-automated>>
Administration Staff
Update Timetable
FIGURE 3-3
14
<<include>>
student
<<include>>
bulletin boards
FIGURE 3-4
3.4 Case Study 3 - System at Shanghai University of Finance and Economics (SUFE)
All members of the university have been issued a username and password to get access to the internal
university information system through http://www.shufe.edu.cn/. The system provides a university
level administration due to the Chinese university structure, which will be detailed in APPENDIX F.
In contrast to those school level Student Information Systems, SUFE s shows its speciality as a
university level system which also provide some high level services such as module selection, major
changing etc. Since all local system development should always match the pace of the central system
development, the understanding of the university level system of SUFE is also necessary in designing
the new Student Information System for school users
Each student of SUFE was issued a student account when they first registered. Currently the system
provides more than 16000 student accounts. The student information system does not only provide
student general information (e.g. personal details, module details etc) but also enable student to select
15
1176 staff of the university access the system from a different interface, which is dedicated for
admission; they can get access to all student data. This part of the system is relatively standard in
China, since there are only two versions of staff admission systems in the market currently.
The system in Shanghai University of Finance and Economics is more flat than the general Student
Information System in UK. In UK, most university manages their student records in two levels: school
level (or department, faculty level) and university level (e.g. Banner), whereas in China it is simply
managed by one big system. There are a few advantages and disadvantages with this kind of data
management system, which will be discussed in 3.4.5 SWOT analysis.
Architecture
Admission system
Access
MSc admission
Access
Module selection
Major change
PHP
16
Person
Log On
Coursework Marking
General Staff
Administration Staff
Update Timetable
Module selection
Student
Change Major
FIGURE 3-5
17
SIS
LBUS
SUFE
Staff information
Tutorial support
Electronic reporting system (e.g. equal opportunity report, self-checking report. etc.)
SWOT analysis
The strength, weakness, opportunity and threat will be illustrated in the following table, by analysis
and compare three systems, I will try to develop the generic student information systems on the basis
of their strengths and correct the weaknesses.
18
SWOT
Strengths
SoC
LUBS
SUFE
Weaknesses
Opportunities
19
Threats
20
First of all, it is found out throughout the investigation that most of the university schools
within University of Leeds are using quite similar systems as LUBS does. From the
conversations with some students from other departments such as school of sociology, school
of mathematics, and school of biochemistry, etc, it is found that most schools are using the
university web facilities (such as Nathan Bodington System) as their main interface with
students rather than developing their own systems on the local databases. The resources from
the central databases are so limited that they cannot be specified to school level (for example,
it cannot provide coursework schedules and timetable for individual department)
Secondly, as the functionality analysis table showed in section 3.5, it is clear that LUBS s
system is relatively rough since some business processes are still semi-automated and it is
lack of functionality. Therefore, those individual school systems are categorized as an
average whereas SIS is functionally better.
SUFE shows its speciality as a university level system, which also provide some high level
services such as module selection, major changing etc. Its special strengths can be learnt and
built on top of other strengths discovered in the investigations.
21
Taking a student of SoC as an example, the system deployment diagram (FIGURE 3-6) shows
the systems interactions between SIS, Banner and Bodington facility
FIGURE 3-6
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.
22
3.7 Summary
This chapter is concentrated on the 3 case studies, which illustrate the scope of each system,
technology they used, system requirement and functionality, and the SWOT analysis of each.
An extra system investigation of Nathan Bodington System is also showed. From those case
studies, we can see that each system got its own characteristics which different from others.
SIS is definitely functionally better than LUBS s. The one of SUFE s is quite special as a
university level system, but its distinctive functions my also be learnt and applied in the future
school Student Information System such as the online module selection. Although those
systems illustrate three totally different architectures in different education systems, some
basic functions remain the same and most of common academic activities are covered, which
will be the basis to generate the generic student information system for the potential
university schools.
23
4.1 Introduction
This chapter explains the technical architecture and requirement specification for Student
Information System within potential university schools. As a product of this project, how it is
generated from the previous investigations will be further discussed and followed by the
evaluation.
123445678
8
9
7
87
7
9
9
7
8723445678
1
9
8
4
4
81
7
9
8
8
79
78
9
7
829
58
7
9
8
4
4
8
7
7
9
8
---Interface
The Student Information Database and Dynamic Web page Generation System will interface
with a number of existing systems, including university central student information
management system (e.g. Banner), and school s local existing systems.
24
Efficiency and quality of web based service; the Student Information System will provide a
reliable information service to the students and staff within that university school based on a
central, powerful relational database with data updated frequently by other systems such as
university s central student records system (e.g. Banner)
Name
Head of the School
Represents
University School
Database Administration
and Software development
Manager
Director of UG studies
UG teaching staff
Project Manager
Role
Responsible for project funding approval, and
monitoring progress of the project.
Ensures that the system is integrated with the
database effectively, upholding data integrity.
Also involved with providing content, and
developing and updating the System, as well as
site maintenance.
Responsible for all the under graduation studies
affairs including the student records approval
Primary role is integration of the different facets
of the development project.
User Summary
Name
Student of School
Director of UG studies
General Administration
General staff
Database Administration
Description
Uses the system via a web
browser to access student Info.
Uses the system to manage
coursework results and
generate staff workload report
Use the system to help
acceptance and clearance
process. Coursework schedule
and timetable updating
Access any student records
Involved with data integrity
and database performance
issues, allowing seamless use
of system.
Stakeholder
Head of University School
Self-represented
Director of UG studies
Director of UG studies
Database Administration Manager
25
In order to achieve flexible system access and broader range of information at the same time,
web based system interface was chosen. However, issues of compatibility between different
computer types still exist, although testing of the web site will have to be carried out over a
number of different web-browsers. (e.g. Netscape, IE)
User Needs
Need
Priority
Concerns
Current Solution
High
Mass Information
management is
difficult and time
consuming
Require intensive
data entry by staff
and paper work.
High
Information accuracy
High
Medium
The wrong
information may
result in serious
mistake (e.g. wrong
classification)
Flexible access
whenever and
wherever you are
Proposed Solutions
User Self Service
approach using Internet
based central database
information
distribution system.
Firewall and virus
software, coupled with
regular data backup,
use of mySQL and
sound internal
password management
schemes.
Update daily from
Banner No body can
change them while they
are in system except
certain position staff.
24/7 system access
provide by the system
26
FIGURE 4-1
Users will be required to input their username and password in order to access the system.
The university central student record system will update student records regularly. Therefore
the student records in school student information system are monitored and refreshed which
any change has been made.
27
Supporting Features
Student and staff of the school can access the webserver of system anytime from any place. Server request
central relational database to retrieve user requested
information.
Centralized relational database holds information on
almost all aspect of student and school.
Fast intranet upload to the database through web
interface
Coursework results update as soon as it is recorded.
Cost saving in human resource management.
Interface Type
Human System
Student to System
Human System
Staff to System
Human System
Administrator to
System
Human System
Database to dynamic
web-page
School student records
database to university
central database
General student
information database to
student coursework
database
System System
System System
System - System
28
Costs associated with staff required in help desk or reception can be reduced,
moreover, cost of paper work will be significantly reduced.
Integration of the existing system (e.g. university central student admission system -Banner) will make sure the information is updated as soon as any changes occur.
In the following user requirements defining part, I will adopt the RAD theory of MoSCoW
rules (Stapleton, 1997) to distinguish between what the users needs in a system and what
the users would like . User requirements are divided into four categories depending on their
relative importance and practical use in the proposed system. The first category is must have
requirements which states are fundamental to the system. They are all the common use
cases from the 3 case studies. The second category is the should have requirements, which
are important requirements, but the system would still be useful and usable without them. The
third category is the could have requirements, which would add value to a proposed system,
which could be left out of the basic development process. The fourth category is want to
have but will not have this time around. This is less vital to this particular project because the
size of the final system would mean that all requirements probably could be met which has
been demonstrated in the first three categories.
Business Use Case Diagram
The following diagrams (FIGURE 4-2, 4-3) show the main users involved in the system and
the major activities carried out by them. Detailed use case description and the sequence
diagrams of how each activity takes place will be presented fully in the Appendix C.
29
Person
Log On
Member of School
Coursework Marking
Online Report
Administration Staff
Update Timetable
Student
Update records
FIGURE 4-2
30
Student
<<include>>
View personal information
<<include>>
FIGURE 4-3
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.
Class Design
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, ModuleResult,
Coursework, CourseworkSchedule, CourseworkResult, UniversitySchool and Member.
(Student and AcedemicStaff are the sub-class of Member).
1
31
Class Diagram
Student Information
System
Jilang Pan
10/04/04
Timetable
Enrolment
1
Module
1
1..*
has
Coursework
Schedule
has 1
Module Result
Coursework
mark
has
1
1
provides
Coursework
Result
*
Student 1
AcademicStaff
has
Member
University
School
FIGURE 4-4
4.3 Summary
This Chapter shows the detailed requirement specification of the new Student Information
System. It is built on the strengths of those investigated and trying to correct current system s
weakness. The final product of the project will be the foundation of the future Student
Information System development. It provides detailed user requirements as well as system
architecture, which ease the further development work to be carried out.
32
Chapter 5 Evaluation
5.1 Introduction
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.
All objectives and minimum requirements are covered --go through the project,
whether the outcomes of the project have matched the initial objectives and minimum
requirements.
User acceptance present the product to the potential end users as well as the system
develop team (Aquilo), get advices and suggestions from them in order to make
system enhancement
User involvement crucial part as discussed in chapter 2 (SSM), exam whether this
success criteria has been satisfied throughout the requirement analysis phase and
advices on continues adopting both hard and soft system development methodologies.
33
The extra system investigation of Nathan Bodington System suddenly came out my mind
after all those scheduled researches. I felt the necessity of understanding this university level
education facility system while I was analyzing the captured system requirements. As
explained earlier (Chapter 3.5), most schools make use of Nathan Bodington System as their
main interaction mediate with students.
Found in Appendix C, a detailed system requirement specification for the potential new
Student Information System for general university school is produced. A detailed system
architecture and initial class design are also introduced. This will be a useful basis on which
the further system development will be carried out.
34
All of them are very happy to see the system to be developed, web-based system interface is
very desirable among the students, and they are expecting the system to provide them more
information about both school and themselves. Lecturers are more interested in the
timetabling and electronic coursework schedule and submitting. One suggestion has been
made by one of the student is that: the timetable interface can also link to the module web
site. When you click on the module code in the timetable, the correlated module information
will be displayed. Therefore, there can be an integration of module information, timetabling
and coursework schedule to corresponding module.
Another problem was identified by my assessor during the progress meeting that, if more
current systems investigations were undertaken, it will result in less use cases in common and
more difficult to group those use cases into Must have Should have and Could have
categories. It is true in reality that those system functionalities greatly differ, however, their
serving purposes are always the samemake the process more effective and efficiently. The
process differences doesn t mean the use cases differ, therefore, as long as the project not
exceeding the time constraints, the more systems you investigated, the better results turn up.
Finally, the requirement specification has been sent to the Aquilo system development team
for their evaluation. Positive feedback was given and they are quite happy to take it as a basis
to develop an actual Student Information System on. The acceptance of Aquilo which is also
a part of the project requirements has been achieved.
5.2.3 Functionality
As the first phase of system development, system strengths should be built from the
beginning. The functionality analysis was presented in the following table, which containing
the comparison of the average (discussed in Chapter 3.5) Student Information System
currently used within the University of Leeds and the New system for potential users.
35
Average New
Staff information
Tutorial support
Electronic reporting system (e.g. equal opportunity report, self-checking report. etc.)
Those shaded functions with a show the flexibility of the new Student Information System
that varies with the different university school s different requirements. It could also be the
further enhancement of the system development.
From the analysis above, it is clear that the new Student Information System is functionally
better than the current system in University of Leeds. Those flexible functional options can be
applied depend on the potential user requirements.
36
5.3 Summary
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.
37
References
Avison, D & Fizgerald, A (2002)Information systems development: methodologies,
techniques and tools, McGraw-Hill.
Avison D.E & Shah H.U. (1997) The information systems development life cycle: a
first course in information systems, McGraw-Hill.
Stapleton J. (1997). DSDM, Dynamic Systems Development Method. AddisonWesley.
Bennett, S. McRobb, S and Farmer, R (1999) Object-Oriented Systems Analysis and
Design using UML McGraw-Hill.
Bull, M (1989) Systems Development using Structured Techniques, Chapman and
Hall Computing.
Checkland, P. B. (1981) System Thinking, Systems Practice john Wiley and Sons
Ltd, Chichester, West Sussex.
Dix A, Finlay J, Aboud G & Beale R, (1998)Human Computer Interaction,
Prentice Hall Europe.
Fores, S Title from Previous Years http://www.comp.leeds.ac.uk/fyproj/previousyears.html [10/12/03]
Hughes, B and Cotterell, M (1999) Software Project Management, McGraw-Hill.
Laudon, K. C. and Laudon, J. P. (2002) Management Information System: managing
the digital firm, 7th Edition, Prentice Hall.
Johnson, O (2002) University of Leeds, IS21-Topic1 course Notes UK.
Lucas, H (1995) Information System Concepts for Management 3rd Edition,
Macmillan Publishing, New York.
Martin, C and Powell, P (1992) Information System: a management perspective,
McGraw-Hill.
Rational Unified Process (RUP)(2004)
C:\ProgramFiles\Rational\RationalUnifiedProcess\index.htm SoC, University of
Leeds, UK. [10 January 2004]
Sauer, C (1993) Why Information Systems Fail: A Case Study Approach Alfred
Waller Ltd, Henley-on-Thames, Oxfordshire.
Simon Bennett, John Skelton, Ken Lunn.(2002) Schaum s outline of UML. UK.
38
Appendix A
The project offers me a first chance to put my theoretical knowledge into actual system
developing which give me a great sense of achievement after completing the project. It has
also been an interesting experience for me to undertake such a large-scale investigations. I am
pleased with the outcomes as well as experiencing the duration of solving encountered
problems.
The project as a whole went well. The initial project plan and schedule turned out to be
suitable for the project undertaken. Looking back on the project after completion, I have
gained substantial knowledge in system modelling and in putting RUP into practice.
I have learnt a lot through completing this project and have a number of relevant pieces of
advice for student wishing to complete a similar project using similar methodology.
1. Since this project is heavily relied on the findings of the investigations, getting the
permissions of the potential system users you want to investigate are very important
due to some information of the current system is highly confidential
2. Don t be put off by the rejections from interviewees, try the others, they may be
helpful and friendly
3. System modelling is like talking in another language (in this case I am talking all the
project through using UML) in order to present it to the assessors outside the system
developing team, make sure they understand what you are talking about
4. Planning is crucial to the success of the project due to its size and time constraints.
Estimating how long you will spend on each section is extremely important and can
be a great motivator, but try to stick to it. As I was advised at the beginning of the
project, a well constructed Gantt chart will help informing yourself all the time
5. Time management is another success criteria. Do not leave everything to the last
minute since you never know whether you have underestimated the time taken to
finish each part of your project.
39
Project Commitments
Project Schedule
Non-Project Commitments
Deliverables
27/04
20/04
13/04
06/04
30/03
23/03
April 2004
16/03
09/03
02/03
23/02
Mar 2004
16/02
09/02
02/02
26/01
Feb 2004
19/01
12/01
05/01
29/12
Jan 2004
22/12
15/12
08/12
24/11
Dec 2003
17/11
10/11
Task Description
03/11
Task
ID
Nov 2003
Background Phase
1
2
3
4
5
Analysis Phase
12
13
Outcome Phase
14
15
16
Exam Revision
Exam Period
Deadlines
17
18
20
21
40
41
2. To define the requirements of the SIS modelling in the School of Computing, the
following questions were answered after a meeting with Jonathan Ainsworth.
Q: What is the overall aim of SIS?
J: SIS stands for School Information System, which covers wide range of information requirements ruling of
school of computing.
A part of SIS does is student records (undergraduate, taught postgraduate and research students)
Staff information
Performance statistics (how many students are currently registered in the school, how many research
publications we have got, how much research grand we got, etc)
The most basic things about SIS is the link with Banner. Banner imports student data nightly to update the
student records in SIS. This may cause many events such as new student records creation (usually at the
beginning of the academic year), module registration change, change of personal details (such as address) etc.
As well as that, much information is direct inputted into SIS. That information includes:
A detailed module list which is comprised of teaching staff, assessors and external examiners who are
responsible for each module as well as the students registered on that particular module.
SoC Module Review Back System. Once every year, all academic staff need to fill in a module review
form and send back to the central student office as a university rule. That information can be sent by SIS with the
web based form to be filled in.
Student project information. All those information is recorded by SIS as well as the allocation of the
student (supervisors and assessors list)
Tutorial support. The information for each tutor of the tutees (includes contact details, personal details,
photos etc)
Coursework Schedule
Module timetable
Module catalogue
Module registration
Assessment
Timetabling
Coursework scheduling
42
Project administration
Reporting
43
There is a current testing application of SIS, which is to help tutors. The purpose of the application is to check
whether student has met the requirement of the program he/she has registered. If anything fails (such as less then
120 credits), system will e-mail both student and his/her tutor. It is trying to make the administration as easier as
possible.
Q: As a Information System Support Officer, what is your responsibility of the system?
J: I am responsible for looking after day-to-day operations, checking whether the overnight script works
properly. Checking database as well as identifying any problems with the data, for example, if anything wrong
with the taught undergraduate student module registration, I will notify Kevin.
I am also responsible for the day-to-day software maintenance. Identifying the errors as well as fixing them.
Finally, I am greatly responsible for the development of SIS. I make major decisions on either creating or
changing of the system.
44
Undergraduate database system, which can be further divided into exam system and admission system.
Q: What activities can those systems cover?
T: The users of the system are only those office staff. They set the data either in Banner or our local system. The
data that belongs to Banner should always be entered into Banner, however, some local information such as
tutorial group allocation and exam results are always stored in our local database.
Secondly, comes the undergraduate application admission, while the university receives the UCAS form, they
will record some basic information in the central database, which will then be sent to LUBS through the ODBC
link. The paper form of the application comes at the same time as well. Then we will put that information into
our local admission database and inform the applicant when he/she will receive an offer. And we send open day
invitation letter as well.
45
46
11
Q: Who is responsible for the development of Bodington System? What are the current developments?
P: The Bodington system is developed by the recently formed "Bodington.org". The software is open source and
originates at the University of Leeds. It is now used and developed at other institutions like Oxford, Manchester
and the Uni of the Highlands and Islands.
47
1
1
2
3
1
4
5
6
7
8
9
6
8
5
1
123456789
5648345
2548338
375 75
96
57
3754
53
2357
359343
5
482774
5
5 3
76983
5
2345 44
5 5
45 75 5 482775 25
25 88445 35 3
45
35 3
85
46
5 3
5 5
45 5 7363
5
235 94
5 65 4476
5 125 95 7745
75
25945345
258
3565383
5575765
57537
3758844
5 77
57
5
25
4
96
!
45748
53
5475
45873
587947"
549
3
3
56549
45828"
3
524
575
254
53
5245
2
5
57"
7657
565456
334
3757844
5
5
2
3
2
1
7
8
1
2
3
1
8
5
12345 '
34375 (
789
5 345
75
25 9343
5 48277!
45
96
5 7
375 4
5 23825 345
73
5
75 5
67655)
#
937
512544
535534
6565
3
365
5
254827755
25
259343
5125
5465
96
57
3754
535535757
254
565 4
96
4575
2
53633695482775
75
74
565357365
2
53
2563
537
3759
273*
37457
55
56587
9
5
5
5
5
'
5
7
6
1
"
8
8
#
$
1
5
6
9
5
6
1
'
5
7
6
1
5
6
7
#
1
5
"
8
8
#
$
1
4
5
8
7
6
8
5
1
6
1
6
9
5
6
1
5
8
7
6
8
5
1
5
%
6
5
&
1
6
1
6
1
5
5
5
5
5
5
5
5
5
5
5
5
5
85
(
5
1
7
1
5
5
5
125
96
5 7
375 (
45 65 (
385 $
5
5 +
375 4
5 35 3
85 3
25 5 9
5 75
,
34
3
544
4
538963
59343
58
54
96
537
375
544
5
3"
5
56548277!
45
785,
34
3
544
55
5
2
3
1
5
6
8
5
1
7
8
5
1
5
9
1
7
6
8
5
1
4545
25+
744
5
5
2
3
1
7
5
5
3
75
5.
725"
7
5/
5&
9
50
829
!
4579
3575%
&
!
51
2
2
3
%
/
5
827757587
9
3
5%
343
575&
64
50
4
1
3
17383
5879454
7
4!
51
2
2
1
5%
/
5
2
3
1
7
!
5
123456789
56
345
25#
93
456548338
37575
25
96
57
3754
575%
343
5
82774
5
5
53
55'
3437555 5
5555+
573575
2575
8
5
51
55
943445 763
5555(
483
3757594344587
,
57544
5
56
554
58755555555555(
483
37575
45
7556765547
5
5
57
558
#
93
4555 55554
579
5656483
37575784445
2
53578895
58254
5
59
55(
43
5 5
5555(
365
7657544
57
55
8238548
3
5
48
3
1
8
6
8
5
5
&
1)1
7
8
#
1
6
6
5
6
1
1253
575
2544
5345
755
259343
54827745
757365557543845
757
254
5654
96
45
7
5 23825
25 7965 3
5 12345 389645 5 ,
435 4
96
5 37
375 8844
5 23825 73645 4
96
5
475 6
34
5 87947"
5 4826945 65 49
4
5
7695 6
34
5
3
45
8
5 :493
5
2
5 4
96
45 65
4
5 5 5 37
6
5 125 44
5 475 4
745 65
3
345
25 4
96
5 37
375 45 5 45 87947"
5
2382585638
5698557
57"
785376
55
5
:38385 65 #
93
5 75 5 465 438;
5
25 4
96
5 37
375 44
5 35 7365 5 35 37
375
4385
75
25 4
96
45 65 4
5 3
235
2
5 9343
5 482775 465 75 5 8
5 795
375 6
45
3
256
596
65#
9
557
2544
4549825459343
!
458
54
96
58764544
5
5
1
3
1
6
*
"
8
#
9
7
1
5
9
1'
7
1
7
6
8
5
1
3
1
6
*
"
8
#
9
7
1
7
1
1
+
1
64
6
6
8
44
6
7
5
6
1
%
343
582775
7
36
2523
2456
5
6
4
6
4
56
5
6
(
45)
6
3
5)
65
7
567
5
1
5
72
84
64
6
639
236
5%
+
5
823
54
5
4
86
5
6
)
#
937544
5675
1
5
8
#
1
8
474357575
8
5963
57
565
73
73
57
44575
2575
8
5
:4945
2
5
2544
53453
653
25
25
6
458
3
592763
56
53
3
5
)
47537653
257363
587
565
673
56596
3
5
254
545545
43
5
3
8
5
8
47435755
25965
69
3754
96345
34538963
5
254
96
58764575
3
5753453
37575
2563
58
45
75
2567
575
8
5
5
1
1
3
1 '
7
1
7
1
+
1
9
564
6
8
44
6
72
84
64
6
639
236
5
6
2523
24566
5
63
6
7
36
2523
2456
1
1
7
6
8
5
1
%
445
2544
53555
745
75884454
96
5
7
55
%
445
2544
5
75
5
87947"
549
4565
54
57"
7657
5
%
45
2544
5
7525
88
8565885
7844
5=
7947"
5482695
65
3
596
3
5
)
8844554
96
587645
7653
256
53
3
5
656
457
85
34494
573
54
445945
7544
5
6
*
"
8
#
9
7
1
<
6575%
343
582775
4
65
(
38
7575%
+
54
96345
(
38
7575%
+
54
96345
(
45)
6
334
375
5
3
1 '
7
1,
5
7
8
5
5
6
1
49
3
1
1
6
*
"
8
#
9
7
1.
1'
7
1+
9
1
+
9
1
7
8
7
6
1
/
8
5
7
5
1
,
6
1
5
9
1
,
5
6
1
6
9
5
6
1
5
8
7
6
8
5
1
9
5
6
7
6
8
5
1
(
&
"
1
6
14
5
6
&
7
6
1 (
&
"
1
5
9
1
5
6
1
#
6
3
1
4
5
8
7
6
8
5
1
7
11
4457
375
5345
63389
565
3
5
8749
3
55
(
585574
5
695
754893
5
824
53
75
6
45643
5
65265
39
5
(
&
"
1
1257
5
37
375
5
49
535437945
34
"
5
5
7
5
844338
37
5
1(
8
7
14
5
6
7
5
6
1
0
9
1 >
,
3588445
16
8
1
6
9
5
6
1
2565
5
8
7
6
8
5
1
6
1
257955
7
7
5
6
1
8
#
6
8
5
1
7
8
8
9
1
8
#
6
8
5
1
58
#
9353
435
%
450
538!
5
6
5
554
5 7825943
5
6557"
5
5465
8
56
45
37
375
634
39
37544
5
>
35653945
>
35653945
6
8
37547
5 47
587965
3
25
956
5
8"
9
594575
?
&
56547965
3
544765
5
482
4
5
<
9
56
539
5
%
6
56357
5
6558765
54
7576585
44
53745
82
5
2
5235
8
3529
5
2553544
5
34
"
5
,
8
58
35
743
3754
5
<
6577"
575
75
75 1
7
@
A
544
588445
25482775
73655
25
8
375
44
5
3
1
1
#
6
7
5
6
1
5
9
1/
8
6
6
8
5
1
12 1234526789
49
86
389424867286462737486728647224
94323
242344
684324
788462253894945
5264
267894
12
348672864945
5264
267894384324263
947778948
4
4
5
6
1
6
7
5
&
6
"
B
55
>
,
358844333
565
9825765
57537
375855
365
55
3
5
555555555555555555
5
<
34
738587645855
36543
5
6
12
*
5
B
555 77529
53
8
37
53
3
654385
47
5#
954
3565
75
75
279
2525
64"
5
555555
5
5
1823859
57545656
453565
756579
87
4
5
555555555555555
5
&
7457544765
565
7599
273*
658844
5
5
5
3
1
7
8
9
6
1
7
!
1
3
2
1
7
8
9
6
1
7
6
5
12544
535436575554
523825354656
5
75944575#
94
535
25$
765$
365$
5512345
35 5 3
65 3
25 5 (
45
5 23825 245
75 6
44
5C
5 75 4
73
5 37
375 75
9
2
5
4
96
4;
548254
96
4
54825
4
54
56
3443745#
9334
565
7695
8
5
257
25753459465
754
7658
738587947"
56587947"
5
"
4
512553
3"
6
527
575
2534
57573645
37
375
75
25 4
96
5
279
25 6
385 5
5
375 245
25 48765 75 345 8736
35 65
4
57
5
50
3
1
7
18
1/
#
6
1
6
8
7
13
5
6
1
!
6
49
63"
3
6
88336
6
5
64
6#
5
4
2456
$
3%
6&
28256
9
26
'
36(
39
36
&
8454
286
8
7
6
5
&
14
6
7
1
96
5654
575
254827758588445
25
457544
5
3
57
558
55
#
94
58
5
3756
45
75
35945
#
94
6537
37
5
=
3*
65
3756
452764537
37575
74
5548
5754
96
56548277
5
>
4
53
59765
75
256
45
279
255
3
85
=
7947"
549
4596
5454775453
53458766
5
=
74
543
53529
547985
5
3
5
7
5
"
557
5757"
785
75
5
254
96
5
87645
9
5
3
1
6
8
5
1
5
9
1
5
9
5
1
1
6
6
6
6
6
6
6
6
6
6
6
6
6
6
6
6
6
6
3
3
5878
537
3753549
553
5387385
75
2594
5
(
385 $
5 =
375 4
5 7
445 35 665 75 4
96
5 87645 (
45
87
375
3
4853
5
5
51
)
9325336
4
25
6
1
3
5
1/
8
5
6
%
6
1
5
827754
96
537
37544
53456765
75736523
2537
3754385
754
96
45
654
575
2
5
38959343
548277
55
5
+
5
79
57537
37535
=
3*
65
3756
454
745
5
79
57537
3755
)
889
537
375
%
6
565828"
655
76956
5
44
596
5483
5
75495
256
5
87434
853
259343
58
56
45
>
,
3537
37588445
1
7
@
A
55
3
558
5
8
69857
3*
657"
765
4
5
457"
7657
56525
6
3443757844
55
)
884457
5
2587
7
57527
5
'
35878
375
75$
765$
365$
5
5
=
74
4544783
653
254
5#
9365352564"
5758
3758556986
5
77
5874
5
7557"
535543
338
56986
5
7
3756
334
375657"
5355
33
3*
6
53
256
3457594454
76535
87
9
56
44
5
37575
25,
34
3
544
5
59343
58
54
96
56
34437544
55
5
35
"
5495
2537
37534596
6545477545582
457889
5
5
25773
5945#
93
45633
5
553567
5
25 7=
7$
5945
7
53
D
D
A
5
75
634
3
93425
5 2
5
25 9445 0
64!
5 35 5 44
5 65 2
5
25 9445 0
7965 3"
!
5%
45
#
93
4556336653
757958
7345663
575
235
353
7
85658
385945
35
257746544
512534
58
753450
94
52!
5#
93
45238254
45E
596
5
75
25 44
F
5 125 48765 8
75 345
25 0
427965 2!
5 #
93
4
5 23825 5 3
7
5
#
93
4
59
5
2544
579654
3559495659453
279
5
2
5125
23658
75345
25
0
87965 2!
5 #
93
4
5 23825 7965 665 95
75 5 77465 44
5 23825 87965 5
5 79
5 75
25 4385 67
5 7844
5 125 79
25 8
75 345 0
5
75 2!
5 9
5 35 7
5 25
2345
3
5
796
5123453454453
5
75
2345
389575
8
58945
2543*
575
253544
57965
5
2
5
5#
93
4575879655
52382524556
74
6535
2534
5
258
734
5
5
1
1
1
1
5
1'
1/
1
&
7
1
125 773
563
542745
25
35 9445376535
25 44
565
25
5
758
33
3458365
79
55
2
5
52
Person
is a kind of
Log On
Member of School
Coursework Marking
Online Report
Administration Staff
Update Timetable
Student
Business actor
Update records
53
Submit coursework
<<extend>>
Student
View Timetable
<<include>>
1
3
5
1
5
6
1
&
7
1
Business object
Public page
Business
worker
Person
Staff page
Web server
Student page
General staff
Student
Member of school
Coursework database
Admission staff
54
1234563
5648345
25
578445
2
525255945884454827754
96
5
37
37544
5438
55
)
3565:,
8
375
24554756346
5
Activity diagram
Student and staff access the system
Student Information System
Jilang Pan
29/03/04
Access school
site
View personal
information
Raise validation
exception
[not log in]
[login fail]
force to login
[ log in ]
[login success]
[student]
[staff]
Select student
view student
information
6
6
6
6
55
6
"
3
6
84
6
,
#
5
6
14
5
1
8
1
"
3
56549
45
5
(
45
3
85
3
56587947"
5482695
5
C
357
5
,
#
5
6
1
6
18
1
8
1
769548
375
:
3544
5
5
:
453
235
25487575
234544
538965
274534
6
523825653
2548
4575
2543845
7364554
96
537
37544
5 1234538964587947"
549
3
3
5354
96
5475
6
34
5
3
5
5 65 87947"
5
5)
6865 98
373
5 735 7
5
238258553
6
59
535755
7665
5
254
8
5535
234548338
37
5
5
4
5
6
7
1
4
5
6
7
16
1
4
5
6
7
1
7
6
8
5
1
0
6
"
8
9
1
)
5758535482775938537
37535
)
5343
75
754
5
<
9
5G54
5
$
5745
55745943
55
5878
37
5
96
453525544765
757
53
75
25
$
5745
96
5
754
5
<
9
5G54
5
44
5
25
258588445
254827753
5
657
35
4
96
5479845
53525544765
757
53
75
2544
5
$
5745
5
754
5
<
9
5G54
5
25
2585884458736
354
575
657
35
4798456543845
$
5745 )
6
334
7453525
2523
2533
575
)
6
334
75
754
5 <
9
5G54
5
657
3575 4
96
587947"
56
45
3
85455
638
57
35
45
3
57587947"
548269596
5
%
3#
95
458558
657
5
25
(
45
756
385
55
4
5G54
5
6
457363
5
537
375
75
5
483
5
3633695945
827754
96
587645
%
343
56
45
9596
45
25785
5C
(
=
5
4
5G54
5
6
45
759343
5
6
454954
96
56
587434
8565
3"
5
8
56
45
37
3753
3
5
125475
7525
74
656
445345
+
54
96
5
754893
587854554545756
45
37
3756
45
75
4
554
5
5
3
8
51258
7385437575
4
96
587947"
5
87947"
53554
76535
2587947"
5
6
45
6
4575
"
3
5
5
6
6
6
6
6
6
6
56
6
(
*
92
536
No1.
* Use Case Name:
Primary Actor:
R Other Actors:
R Value Proposal to
Actor(s)
R Basic Course of
Events:
(The Normal Flow)
Alternative Paths:
(Other paths through the use case
which result in a successful
outcome typically variations to
the basic course of events,
determined by the actor and their
needs).
Exception Paths:
(Other paths through the use case
which result in an unsuccessful
outcome typically when
something goes wrong)
The user gave a wrong URL in the first try. The Web
server of the system is Down. Those hyperlinks are
incorrect.
Assumptions:
The user gave a correct URL and the Web server is not
down
The user must have the correct URL of the school s
homepage or he must click on the correct link.
The website would prompt a interface showing the
various school information on the screen
B01, B05
Pre-conditions:
Post-conditions:
Related Business
Rules:
(Reference to your Business Rules
list)
*
*
*
Related NonFunctional
requirements
Usability,
Performance, Security:
NF01
NF02
NF03
NF04
NF05
Project:
Author:
Date:
57
No.2
*
Primary Actor:
Log in
Member of the school
R Other Actors:
R Value Proposal to
Actor(s)
Visitors
Provide the authorized user the accessibility of further and
detailed school s confidential information
R Basic Course of
Events:
(The Normal Flow)
Alternative Paths:
(Other paths through the use case
which result in a successful
outcome typically variations to
the basic course of events,
determined by the actor and their
needs).
Exception Paths:
(Other paths through the use case
which result in an unsuccessful
outcome typically when
something goes wrong)
The user gave a wrong password in the first try. The Web
server of the system is Down.
Assumptions:
Pre-conditions:
Post-conditions:
Related Business
Rules:
(Reference to your Business Rules
list)
Related NonFunctional
requirements
Usability,
Performance, Security:
NF01
NF02
NF03
NF04
NF05
*
*
*
Project:
Author:
Date:
58
No.3
*
Primary Actor:
R Other Actors:
R Value Proposal to
Actor(s)
(the goal of the Use Case from the
Actor s perspective)
R Basic Course of
Events:
(The Normal Flow)
Alternative Paths:
(Other paths through the use case
which result in a successful
outcome typically variations to
the basic course of events,
determined by the actor and their
needs).
Exception Paths:
(Other paths through the use case
which result in an unsuccessful
outcome typically when
something goes wrong)
The user gave a wrong password in the first try. The Web
server of the system is Down.
Assumptions:
Pre-conditions:
Post-conditions:
Related Business
Rules:
(Reference to your Business Rules
list)
Related NonFunctional
requirements
Usability,
Performance, Security:
NF01
NF02
NF03
NF04
NF05
*
*
*
Project:
Author:
Date:
Primary Actor:
Update Timetable
Administration staff of the school
R Other Actors:
R Value Proposal to
Actor(s)
(the goal of the Use Case from the
Actor s perspective)
R Basic Course of
Events:
(The Normal Flow)
Alternative Paths:
Exception Paths:
(Other paths through the use case
which result in an unsuccessful
outcome typically when
something goes wrong)
The user gave a wrong password in the first try. The Web
server of the system is Down. The database is not linked
with the system.
Assumptions:
Pre-conditions:
Post-conditions:
Related Business
Rules:
(Reference to your Business Rules
list)
Related NonFunctional
requirements
Usability,
Performance, Security:
NF01
NF02
NF03
NF04
NF05
*
*
*
Project:
Author:
Date:
60
No.5
* Use Case Name:
(The name as it appears in the
Use Case Model)
Primary Actor:
R Other Actors:
R Value Proposal to
Actor(s)
(the goal of the Use Case from the
Actor s perspective)
R Basic Course of
Events:
(The Normal Flow)
Alternative Paths:
Exception Paths:
(Other paths through the use case
which result in an unsuccessful
outcome typically when
something goes wrong)
Assumptions:
Pre-conditions:
Post-conditions:
Related Business
Rules:
(Reference to your Business Rules
list)
Related NonFunctional
requirements
Usability,
Performance, Security:
NF01
NF02
NF03
NF04
NF05
*
*
*
Project:
Author:
Date:
61
No.6
* Use Case Name:
Primary Actor:
R Other Actors:
R Value Proposal to
Actor(s)
(the goal of the Use Case from the
Actor s perspective)
R Basic Course of
Events:
(The Normal Flow)
Alternative Paths:
(Other paths through the use case
which result in a successful
outcome typically variations to
the basic course of events,
determined by the actor and their
needs).
Exception Paths:
(Other paths through the use case
which result in an unsuccessful
outcome typically when
something goes wrong)
Assumptions:
Pre-conditions:
Post-conditions:
Related Business
Rules:
The user gave a wrong password in the first try. The Web
server of the system is Down. The database is not linked
with the system.
The user gave a correct password and the Web server is
not down and the user has the privilege to modify the
timetable details in database
The user must provide the correct username and password
in the log in screen and click the right link afterwards
The website would prompt a screen confirms the
modification
B01, B02,
B03, B07
*
*
*
Related NonFunctional
requirements
Usability,
Performance, Security:
NF01
NF02
NF03
NF04
NF05
Project:
Author:
Date:
62
No.7
* Use Case Name:
Primary Actor:
R Other Actors:
R Value Proposal to
Actor(s)
R Basic Course of
Events:
(The Normal Flow)
Alternative Paths:
(Other paths through the use case
which result in a successful
outcome typically variations to
the basic course of events,
determined by the actor and their
needs).
Exception Paths:
(Other paths through the use case
which result in an unsuccessful
outcome typically when
something goes wrong)
Assumptions:
Pre-conditions:
Post-conditions:
Related Business
Rules:
*
*
*
Related NonFunctional
requirements
Usability,
Performance, Security:
NF01
NF02
NF03
NF04
NF05
Project:
Author:
Date:
63
No. 8
* Use Case Name:
(The name as it appears in the
Use Case Model)
* Primary Actor:
R Other Actors:
R Value Proposal to
Actor(s)
(the goal of the Use Case from the
Actor s perspective)
R Basic Course of
Events:
(The Normal Flow)
Alternative Paths:
Exception Paths:
Assumptions:
Pre-conditions:
Post-conditions:
Related Business
Rules:
*
*
*
Related NonFunctional
requirements
Usability,
Performance, Security:
Project:
Author:
Date:
Coursework marking
Academic staff of the school
Administration staff
The staff will mark all the student coursework and submit
the results to the provisional database waiting for the
module leader s final confirmation. Then the results will
be upload to the student coursework database
This use case begins when a staff marked student s
coursework (either electronic version or paper version).
He/she then input the results in to the provisional database
from the system interface. The module leader will get a
full view of the coursework marks then after his final
check; the results will be uploaded to the coursework
database.
If student coursework results are stored as paper version.
The staff can put down individual marks in paper and
send it to the module leader. With the recheck and
confirmation from the module leader, the results can be
finally input into the database or stored as paper version
files.
The user doesn t have the correct username and password.
He/she doesn t have the privilege to access the marking
process. The web server is down. The results cannot be
uploading to the database.
The user gave a correct username and password and the
Web server is not down the user have the privilege to
access the coursework marking process.
The user must provide the correct username and password
in the log in screen and click the right link afterwards. The
module leader should have the privilege to access both
provisional database and write the results to the
coursework database.
The website either prompt a screen for staff to submit
coursework marks to the provisional database and the
module leader will have a screen of all the student results
and make the final confirmation to them. Then the results
will be finally written to the database.
B01, B02,
B03, B07
NF01 NF02 NF03
NF04 NF05
No.9
* Use Case Name:
Submit coursework
Primary Actor:
R Other Actors:
R Value Proposal to
Actor(s)
(the goal of the Use Case from the
Actor s perspective)
R Basic Course of
Events:
(The Normal Flow)
Alternative Paths:
Exception Paths:
Related Business
Rules:
Related NonFunctional
requirements
Usability,
Performance, Security:
NF01
NF02
NF03
NF04
NF06
Assumptions:
Pre-conditions:
Post-conditions:
*
*
*
Project:
Author:
Date:
1
3
5
1
#
1
7
5
17
6
1
4
4!45784465358876853
25
256
5495
8
!
453
2
45
4
"
4!45"
5457
599
273*
658844
58836
574457564
98
374
4
2
6
5 5
25 3
2
5 75 88445 75 4
5 65 4
96
45
75 475 6
5
2
5
5
75
2
5 265 35
87
9
3*
65 44
45 475 389645 0
7
3*
6!
5
95 33
5 44
45 3
235 6
4
5 43845
65 258 5
4
2
7
55
96
45
94
5495
2
554756
573665
75
25%
343
55889
56595
75
6
5
5
2
9
55495
2
5537
375
2
573665544
5345889
56595
756
5
5
2
H
5G54895754
96
56
5
48
375498254587947"
549
3
3
5
5
2
A
55)
54
5
652573
54
96
4
5
94
5625
75%
343
5738565
93634575
6
54893
565483385
94
5495
2
B
5
54756
523825
2527655"
54895
475 37
375 345 7
5 63487465 3
25 75 75 35 3
3
5 75 35 5 7
25
5
3
375757
2345
75599
273*
65
2365
5
5
5
+
8
5
)4
5
6
8
5
#
1
8
7
5
6
1
7
5
17
6
1
5
#
$
4%4&
2!732475
'
4
7
3757366575
2544
5543
5
94
559
3
9794
5
4
#
$
"
4%4(
7'
4384724
12544
5427965545
759456593563
54
5654
96
4!
564
5
4
#
$
)
4!4(
29'
4
125475#
93
5884454657365548277544
5545
4
#
$
*
4!4(
23
24
1257
37573655
2544
542796559495
75
2594
5
4
#
$
+
4%454384
324
12537
375753
2587947"
5
"
45757
256
5427965596
654547754574435
75
7365949537
375
5
NF06Security
66
9
5
7
#
1
5
8
7
6
8
5
1
7
8
18
16
"
1
6
1:
!
"
5
1
1
7
18
1
"
8
8
#
1
1
6
"
1
6
;
1
:w e b p a g e s ys te m :
<P ro ce s s N a m e >
:Me m b e r o f s ch o o l :
<Acto r N a m e >
:s ch o o l s tu d e n t in fo rm a tio n
d a ta b a s e : < P ro ce ss N a m e >
lo g in ( )
va lid a te p as s wo rd
Ge n e ra l in fo rm a tio n
a cce s s p ro ce s s b y a
m e m b e r o f s ch o o l
d is p la y( )
re q u e s t(s tu d e n t d e ta il )
re q u e s t( re co rd s )
re a d ( re co rd s )
d is p la y( )
/
8
7
!
8
7
*
1
7
*
5
&
1:
#
6
7
8
5
1
7
8
5
;
1
1
w e b p a g e s ys te m :
<P ro ce s s N a m e >
s tu d e n t co u rs e w o rk d a ta b a s e :
<P ro ce s s N a m e >
C o u rs e w o rk m a rkin g
(e le ctro n ic ve rs io n
co u rs e w o rk)
re a d (co u rs e w o rk)
d is p la y(co u rs e w o rk)
m a rkin g
e n te r m a rks
p o s t m a rk s
r eco r d m a r k (p r o vi s io n a l)
co n firm a tio n
d is p la y
67
7
!
8
7
*
1
7
*
5
&
1:
7
1
7
8
5
;
1
1
web p age s ys tem :
<Proces s Nam e>
1
1
1
6
1
8
7
!
8
7
*
1:
#
6
7
8
5
1
7
8
5
;
1
1
1
1
Web page s ys tem :
<Proces s Nam e>
s tudent : <Actor
Nam e>
1
1
1
1
1
1
1
1
1
1
68
7
!
8
7
*
1
"
9
#
1
We b pa ge s ys tem :
<Proces s Nam e>
1
1
1
1
12745 4#
985 63
45 42745
25 37
375 75 75 5 43
5 8
33
5 48
3
5 23825 7965
35
25 675 5
5 365 75 275 #
94
5 745
279
25
25 44
5 65 275 5 #
94
5 345
4
3436
5
6
6
6
6
6
6
6
6
6
6
6
6
6
6
6
6
6
69
6
732
56
6
1
7
6
8
5
1
1
125
96
57
3754
535755
45755482775
7588445
2548277537
37
5
>
75 4
96
5 3
5 85 7365 4
96
5 475 6
34
5
3
5 87947"
5 48269
5 87947"
5
49
4
587947"
549
3
3
5
769549
45657
25
7695
6547984
5>
75
54
5
3
58559465
75
73
75
257
44575
2536336954
96
5588443
554
96
58764
5125
44
53454759465
75
"
587947"
545545
5
2549
4
55
5
125 63
45 75 4275
45 75
25 44
5 7
5 63
5 48
4
5 5 125 (
7
5 (
3
5
42745
252438593
453
235
2544
53
25878
374
5593
746575
7575
2455
25
363369587
7
4
565
23566834575757
2
5
1
1
6
1
#
8
5
6
1
&
7
1
70
/
#
1
&
7
1
125=
445(
3
542745
2544
57
55
8238548
3
573
547
5
345
75
4
5673
5
2544
5
5
5
5
Class Diagram
Student Information
System
Jilang Pan
10/04/04
Timetable
Enrolment
1
Module
1
1..*
has
Coursework
Schedule
Module Result
Coursework
mark
has 1
has
1
1
Coursework
Result
provides
*
Student 1
AcademicStaf
f
Member
has
University
School
6
6
6
6
6
6
6
71
433
"
6
4
1
827757
3754
5$
23825
45
253
5758277575=
7
9
3
5
5
8
/
1
8277575=
7
9
3
5359343
575&
6455
5
,
9
1
12587947"
5
"
3
544
5354827757587
9
3
5
5
3
5
5
7
1
%
343
575&
64!
58
54
96
56
334
37544
5
5
/
1)1
7
8
5
#
1/
8
6
7
1
=
7
9
593
53674
573
3546575
5
8277
55
5
1
'
7
5
1
5
9
1
!
8
7
9
1
12594
5654476573655
2582775753
45
5
5
5
5
12
1
&
19
5
7
6
8
5
1
)
55
5355
6525#
94
655594
57
537
375
"
57
5
256
4
5
5
7
+
1
&
785)
54
7"
5G5
653
235874
3
457559363
5758744558
945
3
3
65
7
2385
5
5
7
7
1
<
3
2576587
9
5
2
54
7456
57588445874455
7"
5
5
6
1
1256
54
7
575
3
33
5658763
54
96
537
37545545
257
256
575
48277
5
5
6
/
.
4
1
7
5
9
5
2
587
9
45945
7587
938
587445
25
5
5
'
0
7
1
%
3365 763
5&
9
5
5
2
2
2
1
$
765$
365$
5
72
73