User Requirements Report
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View User Requirements Report as PDF for free.
More details
- Words: 1,717
- Pages: 8
Departmental Academic Assessment Database – User Requirements Report
Page | 1
Departmental Academic Assessment Database – User Requirements Report
Evaluation of Current System Currently the administrative employees maintain two reports manually using excel. One report details the students overall performance in the course taken (Course Assessment Report as shown in Figure 1). This information includes a detailed breakdown of the percentage weight of the examination, marks allocated to each question and marks achieved by the student for each question. This report also details a similar synopsis for the coursework pertaining to the course. The report shows a final total that the student has achieved for that course which is a sum of the coursework weight x by the mark achieved + the examination weight x by the mark achieved, which gives an overall final total for each student on the course. The other report details an overall breakdown of each course undertaken within the degree programme (Program Assessment Report as shown in Figure 2). This report lists the courses, the weight in units per course and then each student’s final results for each course are recorded as they progress through the programme structure. This report then details the total units taken, the total units achieved, total marks and overall average mark. This is then used to provide a classification summary to show what classification each student has achieved at the end of the programme for example, 1st, 2:1 etc. At the end of the degree programme, the programme assessment report is then printed and assessed and signed off by the head of department and external examiner. This report is then filed in hardcopy format by the administrative employees for the required period and the excel spreadsheets used to generate the reports are reused. There would be a benefit in producing a database in order to store all of the relevant information. This system would then produce automated reports at the end of each course and record the running total of the marks achieved per student. This system would cut down the time spent maintaining multiply forms for each course, each programme based upon intake date. The administrative employees would be able to maintain a single database via an application programme interface (API) to record the necessary information per student per course from which the reports will be generated.
Page | 2
Departmental Academic Assessment Database – User Requirements Report
Figure 1 ‐ Course Assessment Report Exam Title Tutor Exam Diet Taken By Student Name
ID No
Degree Programme
Question Marks
Q1
Q2
Total Exam Marks
Q3
Q4
Standard Deviation Average
For 100%
For 75%
Total Coursework Marks For For 100% 25%
Final Total
Figure 2 ‐ Program Assessment Report Student
Name Signed Signed
Title
Preliminary
Part 1
Part 2, Stage 1
Part 2, Stage 2
Available Modules & Units
Available Modules& Units
Available Modules& Units
Available Modules& Units
15
15
15
15
15
15
15
15
15
15
Head of Department
Chairman Board of Science
Page | 3
15
15
15
15
15
Extra subjects
15
Mark Summary Total units taken
Total credit gained
Classification Summary Total marks
Average marks
First
2.1
2.2
3rd
Pass
Signed (External Examiner) Date
Fail
Recommenda tion
Departmental Academic Assessment Database – User Requirements Report
Initial Data Analysis From the above project brief and analysis of the existing reports that are produce by the administrative employees we can start to see the data fields that will be required. Listed below are the initial data fields that need to be considered throughout the database design: c
Student list including: ■ Department ■ Students name ■ Student ID ■ Courses Student is undertaking
c
Course data include: ■ Students undertaking ■ Course tutor ■ Number of units of credit per course ■ Coursework weight (%) ■ Examination weight (%) ■ Examination description, which should include: z Number of exam questions z Mark allocation for each question z Data standardisation of marks allocated as they maybe different per course examination paper
c
Program data include: ■ Program name ■ Degree type ■ Program leader ■ Maximum number of units required ■ Course name ■ Units allocated per course ■ Student name undertaking
c
Course results which need to include: ■ Coursework results for each student ■ Examination results for each student, based on marks allocated for each question ■ Applying the data standardisation (possibly %) ■ Number of questions ■ Student average
c
Program results need to include: ■ Total units undertaken per student ■ Total units accredited per student ■ Total marks achieved per student ■ Average mark achieved per student ■ Degree classification
Page | 4
Departmental Academic Assessment Database – User Requirements Report
User Requirements Analysis From the given project brief, the initial data analysis and the existing report samples we can see that there will be five main user groups that will interact with either the database or final reports produced by the system. In figure 3 (the user analysis table) we can see the requirements of each of these user groups and the interaction with each data types to be stored in the database. Figure 3 ‐ User Analysis Table
User Group
IT System Administrator Administration Course Tutors Program Leaders External Examiners
View Course Information (Select)
Add Course Information (insert)
3 3 3 3
3 3 3
Delete Course Information (Select)
Set Examination & Coursework Weights (Update)
3 3 3
3 3 3
Add Students to Courses and Programs (Insert/Update)
View Program Information (Select)
Add Courses to Program Information (Select)
Delete Program Information (Select)
Maintain Student Information (Update)
Maintain Student marks and grads (Update)
3
3 3 3 3
3 3 3 3
3
3 3
3 3
3
Generate Reports
3 3 3 3
Interact/View Final Printed Reports Only
3 3 3 3
It must be noted that the user groups should be restricted to certain tasks in the relevant tables, for example the course tutors may only have access to delete contents of their own courses and not in the program table. As the final database structure is currently undecided it is not possible to define the user groups further. As the main user group will be the administration staff the system functionality will be based more heavily on the administration group but not without consideration for the other user groups. It is important to understand the use and interaction of the final reports as such this has been included in the above table, however, this is not an access requirement field for the database or system.
Page | 5
Departmental Academic Assessment Database – User Requirements Report
Identification of Project Scope and Considerations Below is a list of the project considerations that will need to be considered and achieved in order to produce the final product. z
General information c How many units are undertaken by undergraduate, postgraduate diploma and postgraduate students. c What structure should the reports be output into and digitally what program used (PDF, MS word, Excel etc..) c Consideration to user access and usage c Database size should be optimised
z
Data structure c Sample of data and existing system (Microsoft Excel) would be required to provide analysis for ERD then normalisation. c Standardisation of data, mark allocation which can differ by course module examination. c Summery calculations such as determining whether the student has gained a 2.1 or 2.2.
z
Application interface requirements c Users may prefer to enter data manually but there is a requirement for a link to the existing system for import/export c How the API will be structured and what language will be used c User access requirements, who will have the ability to edit the data or modify reports etc, as shown above.
z
User access c Although user access is not a major consideration of this project it will still be a consideration.
z
Database requirements c Entity sets and there attributes c Relationship model and attributes c ER Diagram c Final table structure c Report design c The reports to be generated automatically therefore consideration must be given as to what output format. c The database architecture minimises data duplication and overall database size. c Optimised database table structure
z
Project workflow structure c Initial project plan c Key stage responsibilities c Required deadlines c Work schedules c Regular update meetings c Communication plan c General responsibilities such as meeting minutes
Page | 6
Departmental Academic Assessment Database – User Requirements Report
Project Plan & Approach The project plan has been set out into two sections design and analysis and system implementation. Each section shows the deadlines as well as the individuals that will be responsible for that section of the project. If the section shows the name of the individual then either the team or another individual the first name represents the section leader who is primarily responsible for that section of the project. Please note that the initial project plan maybe subject to change. Figure 4 ‐ Project Plan Design & Analysis
Page | 7
Departmental Academic Assessment Database – User Requirements Report
Figure 5 – Project Plan System Implementation 17 Aug 2008
ID
Task Name
Start
Finish
18
1
Phase One System Implementation
24 Aug 2008
31 Aug 2008
7 Sep 2008
Duration
19/08/2008
04/09/2008
16d
2
Phase one database build
19/08/2008
26/08/2008
7d 4h
3
All notes on database build submitted to PM
01/09/2008
01/09/2008
1d
4
System output reports design
25/08/2008
29/08/2008
5d
5
Phase one system testing
26/08/2008
29/08/2008
4d
6
Progress meeting
02/09/2008
02/09/2008
1d
7
Basic API design
29/08/2008
30/08/2008
1d 4h
8
Meeting with client to present phase one system
03/09/2008
04/09/2008
1d 4h
9
Phase Two System Implementation
05/09/2008
10/09/2008
5d 4h
19
20
21
22
23
24
25
26
27
28
29
30
31
1
2
3
4
5
6
7
8
9
10
11
12
Thileepan and Team Thileepan Jocelyn and Team Team Team PM and Team Team
10
Phase two system tweaking
05/09/2008
08/09/2008
3d 4h
11
Finalisation of system output reports
08/09/2008
10/09/2008
2d 4h
Jocelyn and Team
12
Finalisation of basic API
08/09/2008
10/09/2008
2d 4h
PM and Team
13 Delivery of Working System
09/09/2008
12/09/2008
4d
14
Delivery meeting with team
09/09/2008
10/09/2008
2d
15
Final system demo with client
11/09/2008
12/09/2008
2d
Team
Team Team
Page | 8
Page | 1
Departmental Academic Assessment Database – User Requirements Report
Evaluation of Current System Currently the administrative employees maintain two reports manually using excel. One report details the students overall performance in the course taken (Course Assessment Report as shown in Figure 1). This information includes a detailed breakdown of the percentage weight of the examination, marks allocated to each question and marks achieved by the student for each question. This report also details a similar synopsis for the coursework pertaining to the course. The report shows a final total that the student has achieved for that course which is a sum of the coursework weight x by the mark achieved + the examination weight x by the mark achieved, which gives an overall final total for each student on the course. The other report details an overall breakdown of each course undertaken within the degree programme (Program Assessment Report as shown in Figure 2). This report lists the courses, the weight in units per course and then each student’s final results for each course are recorded as they progress through the programme structure. This report then details the total units taken, the total units achieved, total marks and overall average mark. This is then used to provide a classification summary to show what classification each student has achieved at the end of the programme for example, 1st, 2:1 etc. At the end of the degree programme, the programme assessment report is then printed and assessed and signed off by the head of department and external examiner. This report is then filed in hardcopy format by the administrative employees for the required period and the excel spreadsheets used to generate the reports are reused. There would be a benefit in producing a database in order to store all of the relevant information. This system would then produce automated reports at the end of each course and record the running total of the marks achieved per student. This system would cut down the time spent maintaining multiply forms for each course, each programme based upon intake date. The administrative employees would be able to maintain a single database via an application programme interface (API) to record the necessary information per student per course from which the reports will be generated.
Page | 2
Departmental Academic Assessment Database – User Requirements Report
Figure 1 ‐ Course Assessment Report Exam Title Tutor Exam Diet Taken By Student Name
ID No
Degree Programme
Question Marks
Q1
Q2
Total Exam Marks
Q3
Q4
Standard Deviation Average
For 100%
For 75%
Total Coursework Marks For For 100% 25%
Final Total
Figure 2 ‐ Program Assessment Report Student
Name Signed Signed
Title
Preliminary
Part 1
Part 2, Stage 1
Part 2, Stage 2
Available Modules & Units
Available Modules& Units
Available Modules& Units
Available Modules& Units
15
15
15
15
15
15
15
15
15
15
Head of Department
Chairman Board of Science
Page | 3
15
15
15
15
15
Extra subjects
15
Mark Summary Total units taken
Total credit gained
Classification Summary Total marks
Average marks
First
2.1
2.2
3rd
Pass
Signed (External Examiner) Date
Fail
Recommenda tion
Departmental Academic Assessment Database – User Requirements Report
Initial Data Analysis From the above project brief and analysis of the existing reports that are produce by the administrative employees we can start to see the data fields that will be required. Listed below are the initial data fields that need to be considered throughout the database design: c
Student list including: ■ Department ■ Students name ■ Student ID ■ Courses Student is undertaking
c
Course data include: ■ Students undertaking ■ Course tutor ■ Number of units of credit per course ■ Coursework weight (%) ■ Examination weight (%) ■ Examination description, which should include: z Number of exam questions z Mark allocation for each question z Data standardisation of marks allocated as they maybe different per course examination paper
c
Program data include: ■ Program name ■ Degree type ■ Program leader ■ Maximum number of units required ■ Course name ■ Units allocated per course ■ Student name undertaking
c
Course results which need to include: ■ Coursework results for each student ■ Examination results for each student, based on marks allocated for each question ■ Applying the data standardisation (possibly %) ■ Number of questions ■ Student average
c
Program results need to include: ■ Total units undertaken per student ■ Total units accredited per student ■ Total marks achieved per student ■ Average mark achieved per student ■ Degree classification
Page | 4
Departmental Academic Assessment Database – User Requirements Report
User Requirements Analysis From the given project brief, the initial data analysis and the existing report samples we can see that there will be five main user groups that will interact with either the database or final reports produced by the system. In figure 3 (the user analysis table) we can see the requirements of each of these user groups and the interaction with each data types to be stored in the database. Figure 3 ‐ User Analysis Table
User Group
IT System Administrator Administration Course Tutors Program Leaders External Examiners
View Course Information (Select)
Add Course Information (insert)
3 3 3 3
3 3 3
Delete Course Information (Select)
Set Examination & Coursework Weights (Update)
3 3 3
3 3 3
Add Students to Courses and Programs (Insert/Update)
View Program Information (Select)
Add Courses to Program Information (Select)
Delete Program Information (Select)
Maintain Student Information (Update)
Maintain Student marks and grads (Update)
3
3 3 3 3
3 3 3 3
3
3 3
3 3
3
Generate Reports
3 3 3 3
Interact/View Final Printed Reports Only
3 3 3 3
It must be noted that the user groups should be restricted to certain tasks in the relevant tables, for example the course tutors may only have access to delete contents of their own courses and not in the program table. As the final database structure is currently undecided it is not possible to define the user groups further. As the main user group will be the administration staff the system functionality will be based more heavily on the administration group but not without consideration for the other user groups. It is important to understand the use and interaction of the final reports as such this has been included in the above table, however, this is not an access requirement field for the database or system.
Page | 5
Departmental Academic Assessment Database – User Requirements Report
Identification of Project Scope and Considerations Below is a list of the project considerations that will need to be considered and achieved in order to produce the final product. z
General information c How many units are undertaken by undergraduate, postgraduate diploma and postgraduate students. c What structure should the reports be output into and digitally what program used (PDF, MS word, Excel etc..) c Consideration to user access and usage c Database size should be optimised
z
Data structure c Sample of data and existing system (Microsoft Excel) would be required to provide analysis for ERD then normalisation. c Standardisation of data, mark allocation which can differ by course module examination. c Summery calculations such as determining whether the student has gained a 2.1 or 2.2.
z
Application interface requirements c Users may prefer to enter data manually but there is a requirement for a link to the existing system for import/export c How the API will be structured and what language will be used c User access requirements, who will have the ability to edit the data or modify reports etc, as shown above.
z
User access c Although user access is not a major consideration of this project it will still be a consideration.
z
Database requirements c Entity sets and there attributes c Relationship model and attributes c ER Diagram c Final table structure c Report design c The reports to be generated automatically therefore consideration must be given as to what output format. c The database architecture minimises data duplication and overall database size. c Optimised database table structure
z
Project workflow structure c Initial project plan c Key stage responsibilities c Required deadlines c Work schedules c Regular update meetings c Communication plan c General responsibilities such as meeting minutes
Page | 6
Departmental Academic Assessment Database – User Requirements Report
Project Plan & Approach The project plan has been set out into two sections design and analysis and system implementation. Each section shows the deadlines as well as the individuals that will be responsible for that section of the project. If the section shows the name of the individual then either the team or another individual the first name represents the section leader who is primarily responsible for that section of the project. Please note that the initial project plan maybe subject to change. Figure 4 ‐ Project Plan Design & Analysis
Page | 7
Departmental Academic Assessment Database – User Requirements Report
Figure 5 – Project Plan System Implementation 17 Aug 2008
ID
Task Name
Start
Finish
18
1
Phase One System Implementation
24 Aug 2008
31 Aug 2008
7 Sep 2008
Duration
19/08/2008
04/09/2008
16d
2
Phase one database build
19/08/2008
26/08/2008
7d 4h
3
All notes on database build submitted to PM
01/09/2008
01/09/2008
1d
4
System output reports design
25/08/2008
29/08/2008
5d
5
Phase one system testing
26/08/2008
29/08/2008
4d
6
Progress meeting
02/09/2008
02/09/2008
1d
7
Basic API design
29/08/2008
30/08/2008
1d 4h
8
Meeting with client to present phase one system
03/09/2008
04/09/2008
1d 4h
9
Phase Two System Implementation
05/09/2008
10/09/2008
5d 4h
19
20
21
22
23
24
25
26
27
28
29
30
31
1
2
3
4
5
6
7
8
9
10
11
12
Thileepan and Team Thileepan Jocelyn and Team Team Team PM and Team Team
10
Phase two system tweaking
05/09/2008
08/09/2008
3d 4h
11
Finalisation of system output reports
08/09/2008
10/09/2008
2d 4h
Jocelyn and Team
12
Finalisation of basic API
08/09/2008
10/09/2008
2d 4h
PM and Team
13 Delivery of Working System
09/09/2008
12/09/2008
4d
14
Delivery meeting with team
09/09/2008
10/09/2008
2d
15
Final system demo with client
11/09/2008
12/09/2008
2d
Team
Team Team
Page | 8
Related Documents
User Requirements Report
October 2019 12
User Requirements Validation.docx
August 2019 22
Unit 3 User Requirements
October 2019 11
Business User Requirements Doc
November 2019 19
Consolidated User Requirements
November 2019 10