Explanations of the Actors and Use Cases

student: A student who will take quizzes, and maybe also create and edit quizzes for his/her own use
teacher: A teacher who will create and edit quizzes for students to take. A teacher might take a quiz to check it, so it wouldn't be wrong to add a connection from teacher to "take quiz", but we've taken the view that a teacher taking a quiz is temporarily acting the role of a student.

open quiz file: reads a quiz file and stores the questions internally
take quiz: student takes the quiz, receives a score, and optionally repeats questions that were missed
answer a question: student answers a single question
answer multiple-choice question: student chooses the correct answer from a list
answer short answer question: student types in an answer
answer true/false question: student choose "true" or "false"
view feedback for a question: student is told whether her answer was correct or incorrect and is shown the correct answer in case of an incorrect answer to a multiple-choice or true/false question
view score for quiz: program displays the number of correct answers after the user has taken a quiz
edit quiz: make changes to the quiz currently stored internally
add question: add a question to the quiz currently stored internally
delete question: delete a question from the quiz currently stored internally
modify question: change a question in the quiz currently stored internally
change question text: change the text of a question in the quiz -- i.e. the string that is shown when asking the question
change correct answer: change the correct answer that is stored for a question and used to judge whether a user's answer is correct
add or delete item from multiple choice list: add or delete one of the choices for a multiple choice question

Note: The amount of detail you put into a use case diagram like this can vary. As an example, we could have broken down "add question" further into a use case for each of the three types of questions, since each will probably require a different dialog and procedure. In the other direction, we could have stopped at "modify question" and refrained from breaking it down any further. Either of these would have been acceptable. The exact amount of detail is a matter of taste and would depend on the situation. However, if your use cases are too vague you may lose points for not being thorough enough. For example, "edit quiz" is too general and should be broken down to specify what kinds of edits can be made.

Last modified: