Requirements

Let's re-imagine our Online Exam Portal. It's more than just a place for taking tests; it's an adaptive learning environment. We want to create a robust and flexible system that allows instructors to easily create and manage exams, students to take those exams, and the system to provide real-time feedback and analysis. Imagine a scenario where thousands of students are simultaneously taking exams. Our system needs to gracefully handle this load, ensuring data integrity and a smooth user experience. We are going to focus on the core components of the exam taking and grading process. This is not a full-fledged LMS, so features like course creation and student enrolment are out of scope. # Requirements ## Functional Requirements 1. **Exam Creation:** * Instructors should be able to create exams with different question types (Multiple Choice, True/False, Short Answer, Coding). * Each question should have associated metadata (difficulty level, topic). * Instructors must be able to set time limits for the entire exam or individual sections. * Instructors should be able to define the passing score for each exam. * Questions should support rich text formatting (bold, italics, lists). * Instructors should be able to preview the exam as a student. 2. **Exam Taking:** * Students should be able to view the exam instructions and questions. * The system should track the time remaining for the exam. * Students should be able to answer questions and review their answers before submitting. * For coding questions, provide a basic code editor with syntax highlighting and the ability to compile and run (limited execution time and memory). * The system should automatically save student progress periodically. * The system must handle concurrent access from multiple students taking the same exam. 3. **Grading and Results:** * Automatic grading for Multiple Choice and True/False questions. * Manual grading for Short Answer and Coding questions. * Instructors should be able to provide feedback on individual answers. * The system should calculate the final score and determine if the student passed or failed. * Students should be able to view their results, including their score, answers, and instructor feedback. * Provide aggregate statistics on exam performance (average score, question difficulty). 4. **Question Management:** * Instructors should be able to create, edit, and delete questions. * Questions should be organized into categories or topics. * Support importing questions from a standard format (e.g., CSV, JSON). * Questions may be reused across different exams. 5. **Concurrency and Data Integrity:** * Ensure that concurrent exam submissions from multiple students don't corrupt the data. * Implement appropriate locking mechanisms to prevent race conditions when updating exam status or student scores. ## Non-Functional Requirements 1. **Thread Safety:** The core data structures (Exam, Question, StudentAnswer) must be thread-safe to support concurrent access. Consider using immutable objects where appropriate and thread-safe collections (e.g., ConcurrentHashMap) when mutability is necessary. Analyze potential race conditions in the grading and submission process. 2. **Extensibility:** The system should be easily extensible to support new question types and grading algorithms. Employ the Strategy pattern to decouple question types and grading logic. Use interfaces to define clear contracts between components. 3. **Modularity:** The system should be composed of loosely coupled modules, making it easier to maintain and test. Use Facades to simplify complex interactions between modules. 4. **Testability:** The code should be designed for unit testing. Use dependency injection to facilitate mocking dependencies. 5. **Maintainability:** Adhere to SOLID principles. Keep methods short and focused. Write clear and concise comments. 6. **Scalability (Class Level):** While this is an LLD, think about how your data structures and algorithms will scale as the number of questions, students, and exams grows. Consider using efficient data structures and algorithms (e.g., caching frequently accessed questions, optimizing grading algorithms). ## Core Entities 1. **Exam:** Represents an exam with its questions, duration, and other settings. 2. **Question:** Represents a single question in the exam. This is an abstract class with concrete implementations for different question types (MultipleChoiceQuestion, TrueFalseQuestion, ShortAnswerQuestion, CodingQuestion). 3. **Answer:** Represents a student's answer to a question. This is also an abstract class with concrete implementations specific to the question type. 4. **Student:** Represents a student taking the exam. 5. **ExamSession:** Represents a student's session while taking the exam. Tracks time remaining, progress, and answers. This is a *critical* entity for handling concurrency. 6. **Grade:** Represents the grade a student receives on an exam. 7. **GradingStrategy:** An interface defining the strategy for grading different question types (Strategy Pattern). 8. **QuestionBank:** A repository for storing and managing questions.

Design Online Exam Portal.

Requirements

Interview Simulation

Functional Requirements

💡 Interview Tip

Non-Functional Requirements

Core Entity Identification

Premium Content