Information System Design Sessional 2013-14 CSE, BUET Group 6 Irfan Alahi Mubassher Islam Arunavo Dey Maruf Hamidi Bejon Sarker

1. E-Learning System
CSE 308: Software Engineering and Information System
Design Sessional (Use-Case)
Group no. : 06
1005062
1005065
1005071
1005072
1005074
1

2. Sub-systems with sub sub-systems
• Exam
– Question Management
– Schedule Management
– Appearing Exam
– Result Management
• Virtual Class Room
• Report and Information
• Forum
• Registration
2

3. 1. Exam Sub-system
1.1 Question Management sub subsystem
1.2 Schedule Management sub subsystem
1.3 Appearing Exam
1.4 Result Management sub subsystem
3

4. 1.1 Question Management
1.1.1 Provide Question
1.1.2 Review Question
1.1.3 Set Exam Pattern
1.1.4 Select Question
4

5. Actors
• Teacher
• Moderator
• Database
5

6. Glossary of Question Management
Actors Acts
Teacher Set and provide questions.
Moderator Mainly review and approve the question. Can also set question.
Database Stores the approved questions.
Use-cases Use
Provide Question Teacher set and submit questions. Moderator can also do so.
Review Question The submitted questions are reviewed and checked by the
moderator
Set Exam Pattern Moderator decides about the type of exam; MCQ or descriptive,
subject, class, number of questions etc.
Select Question From numerous submitted questions moderators choose the
questions for the exam.
6

7. 1.1 Use-case diagram of ‘Question Management’ 7

8. 1.1.1.
Documentation and action flow of
‘Provide Question’ Use-case
8

9. 9
Use-case ID 1.1.1
Use-case name
Provide Question
Description Approved teachers and moderators will provide questions
for the exams.
Priority Essential
Primary actors 1. Teachers
2. Moderators
Secondary actors 1. Database
Trigger The teacher or moderator decides to set question.
Preconditions The designated actors must be signed in to the system
with a valid id.
Post conditions The provided questions are taken and forwarded to the
review use-case.
Conclusion The use-case concludes its functions when the primary
actors submit the question after accomplishment.
Implementation The system will provide the particular actor a suitable
interface to put the question in a definite field.

10. Flow of Actions:
Actor’s action System Response
1. Primary actor will sign in to the
system.
1. System will allow the actor to sign in
if it is a valid id.
2. Primary actor will choose to set
question.
2. System will provide the appropriate
interface for setting questions.
3. Then the actor will set the questions
as per the earlier choices and
attributes.
3. None.
4. After completing the question, the
primary actor will submit them.
4. The system will keep the questions
and wait for the moderators to check
whether they are eligible.
10

11. Alternative Actions:
• 1.a If the primary actor’s id is invalid the system ask him/her
to register.
• 3.a If the questions do not meet the requirement of the
preset question format, the system will prompt the actor to
reset the question.
11

12. 1.1.2.
Documentation and action flow of
‘Review Question’ Use-case
12

13. 13
Use-case ID 1.1.2
Use-case name
Review question
Description Check the questions provided from the ‘Provide Question’ use-
case and approve the eligible questions.
Priority Essential
Primary actors 1. Moderators
Secondary actors 1. Database
Trigger The moderator chooses to moderate the submitted questions.
Preconditions The designated actors must be signed in to the system with a
valid id and there must be pending questions to review.
Post conditions The provided questions are checked and stored in the database if
they are up to the mark and the question provider will be
notified.
Conclusion The use-case concludes its functions when the primary actor
approves or rejects the question.
Implementation The system will provide the particular actor a suitable interface to
review questions.

14. Flow of Actions:
Actor’s action System Response
1. Primary actor will sign in to the
system.
1. System will allow the actor to sign in
if it is a valid id.
2. Primary actor will choose to review
the pending questions.
2. System will provide the appropriate
interface and the pending questions’
list.
3. Then the actor will select the
question and review.
3. None.
4. After completing the action the actor
will give his/her consent.
4. If the consent is YES then the
question is stored into the database.
Otherwise the system will reject it.
14

15. Alternative Actions:
• 1.a If the primary actor’s id is invalid the system rejects the
access request.
• 2.a If there is no pending questions, the use-case will notify
the moderator and terminate.
15

16. 1.1.3.
Documentation and action flow of
‘Set Exam Pattern’ Use-case
16

17. 17
Use-case ID 1.1.3
Use-case name
Set Exam Pattern
Description Moderators will decide the pattern of the exam
Priority Essential
Primary actors 1. Moderators
Secondary actors 1. Database
Trigger The moderator decides to set exam pattern.
Preconditions The designated actor must be signed in to the system with
a valid id.
Post conditions The provided exam pattern is taken and stored in the
database.
Conclusion The use-case concludes its functions when the primary
actor submits the exam pattern after accomplishment.
Implementation The system will provide the particular actor a suitable
interface to define the pattern in a definite field.

18. Flow of Actions:
Actor’s action System Response
1. Primary actor will sign in to the
system.
1. System will allow the user to sign in if
it is a valid id.
2. Primary actor will choose to set exam
pattern.
2. System will provide the appropriate
interface for setting questions.
3. Then the actor will set the exam
pattern for a particular exam.
3. None.
4. After setting the pattern, the primary
actor will submit them.
4. The system will store the pattern in
the database.
18

19. Alternative Actions:
• 1.a If the primary actor’s id is invalid the system refuses
him/her to access the system.
• 3.a If the pattern does not meet the requirement of the
preset exam pattern format, the system will prompt the actor
to fill necessary fields properly
19

20. 1.1.4.
Documentation and action flow of
‘Select Question’ Use-case
20

21. 21
Use-case ID 1.1.4
Use-case name
Select Question
Description Moderators will select the questions for the scheduled
exams.
Priority Essential
Primary actors 1. Moderators
Secondary actors 1. Database
Trigger The moderator
Preconditions The designated actors must be signed in to the system
with a valid id.
Post conditions The questions will be preserved for the upcoming exam
and its access will be restricted.
Conclusion The use-case concludes its functions when the primary
actors select all the questions.
Implementation The system will provide the particular actor a suitable
interface to select from the approved questions.

22. Flow of Actions:
Actor’s action System Response
1. Primary actor will sign in to the
system.
1. System will allow actor to sign in if it
is a valid id.
2. Primary actor will choose to select
question
2. System will provide the appropriate
interface for selecting questions.
3. Then the actor will select the
questions as per the upcoming exam.
3. None.
4. After completing selecting the
questions, the primary actor will submit
them.
4. The system will store the questions
and restrict the viewing of question
until the scheduled exam.
22

23. Alternative Actions:
• 1.a If the primary actor’s id is invalid the system ask him/her
to register.
• 3.a If the selected question set do not meet the requirement
of the preset question pattern, the system will prompt the
actor to reset the question set.
23

24. 1.2 Schedule Management
1.2.1 Set Schedule
1.2.2 Update Schedule
1.2.3 View Schedule
1.2.4 Registration
24

25. Actors
• Student
• Moderator
• Database
• All
25

26. Glossary of Schedule Management
Actors Acts
Moderator Mainly review and approve the question. Can also set question.
Students They can register for a exam at a definite schedule
Database Stores the schedule
All All can view the schedule. It is an open use-case.
Use-cases Use
Set Schedule Moderator will set schedule
Update Schedule If necessary, moderators can update and reset the schedule
View Schedule Any one can view the schedule. This use-case is open for all.
Registration The students will register for a exam schedule.
26

27. 1.2 Use-case diagram of ‘Schedule Management’ 27

28. 1.2.1.
Documentation and action flow of
‘Set Schedule’ Use-case
28

29. 29
Use-case ID 1.2.1
Use-case name
Set Schedule
Description Moderators will set schedule for the exams.
Priority Essential
Primary actors 1. Moderators
Secondary actors 1. Database
Trigger The moderator decides to set schedule.
Preconditions The designated actors must be signed in to the system
with a valid id.
Post conditions The provided schedules are taken and respective teachers
and students will be notified.
Conclusion The use-case concludes its functions when the primary
actors submit the schedule after accomplishment.
Implementation The system will provide the particular actor a suitable
interface to set the schedule in a definite field.

30. Flow of Actions:
Actor’s action System Response
1. Primary actor will sign in to the
system.
1. System will allow the actor to sign in
if it is a valid id.
2. Primary actor will choose to set
schedule.
2. System will provide the appropriate
interface for setting schedule.
3. Then the actor will set the schedule
and submit it.
3. System will keep the schedule and
notify teachers and students.
30

31. Alternative Actions:
• 1.a If the primary actor’s id is invalid the system ask him/her
to register.
• 3.a If any field of the schedule format is not filled system will
request the primary actor to setting it properly.
31

32. 1.2.2.
Documentation and action flow of
‘Update Schedule’ Use-case
32

33. 33
Use-case ID 1.2.2
Use-case name
Update Schedule
Description Moderators can update schedule for the exams if
necessary.
Priority Conditional, not obvious but will enhance the system
Primary actors 1. Moderators
Secondary actors 1. Database
Trigger The moderator decides to update schedule.
Preconditions The designated actors must be signed in to the system
with a valid id and there must be an existing schedule.
Post conditions The updated schedules are taken and respective teachers
and students will be notified.
Conclusion The use-case concludes its functions when the primary
actors submit the schedule after accomplishment.
Implementation The system will provide the particular actor a suitable
interface to set the schedule in a definite field.

34. Flow of Actions:
Actor’s action System Response
1. Primary actor will sign in to the
system.
1. System will allow the actor to sign in
if it is a valid id.
2. Primary actor will choose to update
schedule.
2. System will provide the appropriate
interface for updating schedule.
3. Then the actor will reset the
schedule and submit it.
3. System will keep the schedule and
notify teachers and students.
34

35. Alternative Actions:
• 1.a If the primary actor’s id is invalid the system ask him/her
to register.
• 2.a If there is no existing schedule the system will prompt for
setting a schedule.
• 3.a If any field of the schedule format is not filled system will
request the primary actor to setting it properly.
35

36. 1.2.3.
Documentation and action flow of
‘View Schedule’ Use-case
36

37. 37
Use-case ID 1.2.3
Use-case name
View Schedule
Description All visitors can view schedule for the exams.
Priority Essential
Primary actors 1. All visitors
Secondary actors 1. Database
Trigger The visitor decides to see schedule.
Preconditions There must be an existing schedule.
Post conditions none
Conclusion none
Implementation The system will provide the particular actor a suitable
interface to view the schedule.

38. Flow of Actions:
Actor’s action System Response
1. Primary actor will choose to view
schedule.
1. System will provide the appropriate
interface for viewing schedule.
38

39. Alternative Actions:
• 1.a If there is no existing schedule the system will notify this.
39

40. 1.2.4.
Documentation and action flow of
‘Registration’ Use-case
40

41. 41
Use-case ID 1.2.4
Use-case name
Registration
Description Registered students of the system will register for the
scheduled exam.
Priority Essential
Primary actors 1. Students.
Secondary actors 1. Database
Trigger The primary actor decides to register for the exam.
Preconditions There must be an existing schedule and primary actor
must be already registered.
Post conditions The student will be notified that he/she is enlisted for the
upcoming exam.
Conclusion When the student submits his registration.
Implementation The system will provide the particular actor a suitable
interface to register.

42. Flow of Actions:
Actor’s action System Response
1. Primary actor will sign in to the
system.
1. System will allow the actor to sign in
if it is a valid id.
2. Primary actor will choose to register. 2. System will provide the appropriate
interface for registration.
3. Primary actor will submit his
registration.
3. System will notify that his
registration is complete.
42

43. Alternative Actions:
• 1.a If the primary actor’s id is invalid the system ask him/her
to register.
• 3.a If any of the registration is not format wise system will
request the primary actor to setting it properly.
43

44. 1.3 Appearing Exam
1.3.1 Sit for Exam
44

45. Actors
• Student
• Database
45

46. Glossary of Result Management
Actors Acts
Students Student will sit for the scheduled exam.
Database Database will store the answer script of the student.
Use-cases Use
Sit for Exam Registered students of the Exam will enter into exam
interface.
46

47. 1.3 Use-case diagram of ‘Appearing Exam’ 47

48. 1.3.1.
Documentation and action flow of
‘Sit for Exam’ Use-case
48

49. 49
Use-case ID 1.3.1
Use-case name
Sit for Exam
Description Registered students of the Exam will enter into exam
interface.
Priority Essential
Primary actors 1. Student
Secondary actors 1.Database
Trigger The primary actor decides to enter the exam.
Preconditions The exam must be started and primary actor must be
already registered.
Post conditions Answers will be stored in database.
Conclusion When the student submits his answer.
Implementation The system will provide the particular actor a suitable
interface to give exam.

50. Flow of Actions:
Actor’s action System Response
1. Primary actor will sign in to the
system.
1. System will allow the student to sign
in if it is a valid id.
2. Primary actor will choose to give
exam
2. System will provide the appropriate
interface for exam if he is registered to
the exam.
3. Primary actor will submit his
answers.
3. System will notify that his submission
has been completed.
50

51. Alternative Actions:
• 1.a If there is no valid id the system will prompt for
registration to the system .
• 2.a If the student is not registered to the exam , system will
reject him. Also if the exam is not started system will say him
to wait.
• 3.a If any question is not answered system will warn him
otherwise system will ask him for confirmation.
51

52. 1.4 Result Management
1.4.1 Evaluation
1.4.2 Descriptive Exam Evaluation
1.4.3 MCQ Exam Evaluation
1.4.4 View Result
1.4.5 Ask for Scrutiny
1.4.6 Scrutiny
52

53. Actors
• Student
• Teacher
• Moderator
• Database
53

54. Glossary of Result Management
Actors Acts
Students Can view respective results and can request for scrutiny if any problem
Teacher Will assess the descriptive exams’ answer scripts
Moderator Approve the scrutiny request issued by the student
Database Stores the evaluation results.
Use-cases Use
Evaluation System Evaluates the students’ answer as per the provided answers of the questions.
Descriptive Exam
evaluation
System sends the descriptive answers to all the question setters of the exam and they
evaluate the descriptive answers.
MCQ Exam evaluation System automatically evaluates answers.
View Result Students will see their results of exams they have appeared earlier.
Ask for Scrutiny If the students see any discrepancy in their result then they can issue the request for a
further scrutiny.
Scrutiny Moderator reviews the result and the answer script of the student who ask for a
scrutiny.
54

55. 1.4 Use-case diagram of ‘Result Management’ 55

56. 1.4.1.
Documentation and action flow of
‘Evaluation’ Use-case
56

57. 57
Use-case ID 1.4.1
Use-case name
Evaluation
Description System Evaluates the students’ answer as per the
provided answers of the questions.
Priority Essential
Primary actors -none-
Secondary actors 1. Database
Trigger System itself triggers the use-case after the test finishes. It
is automated.
Preconditions The scheduled exam must be finished.
Post conditions Depending on the type of exam the system extends this
use-case.
Conclusion The use-case concludes its functions when the system
identifies the appropriate exam pattern.
Implementation It is a background process implemented by the system.

58. Flow of Actions:
Actor’s action System Response
1. The secondary actor, database will
serve the answers of a particular
student
1. None
2. The database also gives the info
about the type of exam.
2. The system invokes either the ‘MCQ
Exam Evaluation’ or ‘Descriptive Exam
Evaluation’ as per the info.
58

59. Alternative Actions:
• 1.a If there is no answer set of certain exam i.e. no student
participated in the exam, the use-case terminates.
59

60. 1.4.2.
Documentation and action flow of
‘Descriptive Exam Evaluation’ Use-
case
60

61. 61
Use-case ID 1.4.2
Use-case name
Descriptive Exam Evaluation
Description System sends the descriptive answers to all the question
setters of the exam and they evaluate the descriptive
answers.
Priority Conditional, would enhance the system but if absent
won’t make the system unacceptable.
Primary actors 1. Database
Secondary actors 1. Teacher
Trigger ‘Evaluation’ use-case initiates this use-case if the exam
type is descriptive.
Preconditions The particular exam must be descriptive.
Post conditions The teachers evaluate the answers and the mark is stored
in the database for calculation.
Conclusion This event cease to functioning with the teachers’
finishing of evaluation.
Implementation The system provides the teacher an interface and the
answer in a certain field.

62. Flow of Actions:
Actor’s action System Response
1. Database sends the answer to the
teacher.
1. System notifies the teachers involved
to evaluate the answer.
2. Teacher signs in and chooses to
evaluate the scripts.
2. The system provides an interface to
the teacher to show the script.
3. Teacher evaluates the script and
submits marks on the basis of quality of
answer.
3. System stores the marks of the
particular answer in the database.
62

63. Alternative Actions:
• 1.a If there is no answer set of certain exam i.e. no student
participated in the exam, the use-case terminates.
• 2.a If the signing in id is invalid the system ask to register
properly.
63

64. 1.4.3.
Documentation and action flow of
‘MCQ Exam Evaluation’ Use-case
64

65. 65
Use-case ID 1.4.3
Use-case name
MCQ Exam Evaluation
Description System automatically evaluates answers.
Priority Essential
Primary actors -none-
Secondary actors 1. Database
Trigger This is an automatic process. System triggers the use-case
immediately after the exam if it is an MCQ exam.
Preconditions The particular exam must be MCQ type.
Post conditions System evaluates the answers as per the pre stored
answer and store the result in the database.
Conclusion Use-case concludes with the finishing of evaluation.
Implementation This is a background process implemented by the system.

66. Flow of Actions:
Actor’s action System Response
1. Database provides the pre stored
correct MCQ answers of the questions.
1. None
2. Database then serves the stored
exam data of the participated students.
2. System then evaluates the students’
answers as per the correct answers.
3. None. 3. System stores the marks in the
database after finishing evaluation.
66

67. Alternative Actions:
• 1.a If there is no answer set of certain exam i.e. no student
participated in the exam, the use-case terminates.
67

68. 1.4.4.
Documentation and action flow of
‘View Result’ Use-case
68

69. 69
Use-case ID 1.4.4
Use-case name
View Result
Description Students will see their results of exams they have
appeared earlier.
Priority Essential
Primary actors 1. Student
Secondary actors 1. Database
Trigger Student decides to see their result.
Preconditions The evaluation must be finished and the student must
sign in to the system from a valid id.
Post conditions Result is shown to the student as per the request.
Conclusion Use-case concludes with the showing of result to the
student.
Implementation System will return an interface consisting of a chart of
correct and wrong answers and total mark obtained.

70. Flow of Actions:
Actor’s action System Response
1. Student signs in from a valid id. 1. System allows the student to access
the system.
2. Student chooses the particular exam
he appeared, to see his/her own result.
2. System searches the database and
find the result.
3. None. 3. System displays the result to the
student.
70

71. Alternative Actions:
• 1.a If actor tries to sign in from an invalid id system prompt
error.
• 2.a Student chooses the wrong exam or the exam he/she
didn’t participated
• 2.b System prompt an error and ask to choose the right exam
• 2.c The correct exam chosen by the student but its
evaluation is not finished
• 2.d System prompt the student to wait and to check after a
certain time
71

72. 1.4.5.
Documentation and action flow of
‘Ask for Scrutiny’ Use-case
72

73. 73
Use-case ID 1.4.5
Use-case name
Ask for Scrutiny
Description If the students see any discrepancy in their result then they can
issue the request for a further scrutiny.
Priority Conditional, this use-case will be inclined with the
implementation of descriptive exam system. MCQ exam system is
fully automated.
Primary actors 1. Student
Secondary actors -none-
Trigger Student issue a scrutiny request if he/she see any problem with
his/her result.
Preconditions The evaluation must be finished and the student must sign in to
the system from a valid id.
Post conditions Use-case request waits for the approval of the moderator.
Conclusion Use-case terminates with the submission of the student’s scrutiny
request.
Implementation Primary actor will just prompt the designated option for the
scrutiny request from his/her profile with a valid exam info.

74. Flow of Actions:
Actor’s action System Response
1. Student signs in from a valid id. 1. System allows the student to access
the system.
2. Student chooses the particular exam
he appeared, found anomaly and
request for review of his/her answer
script.
2. System accepts the request and
conveys the request to the ‘Scrutiny’
use-case.
74

75. Alternative Actions:
• 1.a If actor tries to sign in from an invalid id system prompt
error.
• 2.a Student chooses the wrong exam or the exam he/she
didn’t participated
• 2.b System prompt an error and ask to choose the right exam
• 2.c The correct exam chosen by the student but its
evaluation is not finished
• 2.d System prompt the student to wait and to check after a
certain time
75

76. 1.4.6.
Documentation and action flow of
‘Scrutiny’ Use-case
76

77. 77
Use-case ID 1.4.6
Use-case name
Scrutiny
Description Moderator reviews the result and the answer script of the
student who ask for a scrutiny.
Priority Conditional, this use-case will be inclined with the
implementation of descriptive exam system. MCQ exam
system is fully automated.
Primary actors 1. Moderator
Secondary actors 1. Database
Trigger The moderator decides to view the scrutiny request.
Preconditions There must be some scrutiny requests.
Post conditions The requested exam script is scrutinized.
Conclusion Use-case terminates with the submission of the student’s
scrutiny request.
Implementation Primary actor will be provided with a suitable interface for
scrutinizing the answer script.

78. Flow of Actions:
Actor’s action System Response
1. Moderator signs in from a valid id. 1. System allows the student to access
the system.
2. Moderator decides to view the list of
pending scrutiny request(s).
2. System shows the desired contents.
3. Moderator chooses the any request
to scrutinize.
3. System finds from the database, the
selected answer script corresponding to
the request.
4. Then the moderator scrutinizes the
script manually and submits the result
after finishing.
4. System replaced the reviewed and
revised result in the database.
78

79. Alternative Actions:
• 1.a If actor tries to sign in from an invalid id system prompt
error.
• 2.a If no scrutiny request, use-case terminates
79

80. 80