Nice-to-Haves:
N1: Communication
N3: Code execution
N4: Syntax Highlighting
N6: Generative AI
N7: Cloud Deployment
Functional Requirements
N1: Communication
| Functional Requirement |
Acceptance Criteria |
Priority |
| N1. Communication |
|
|
| WebSocket Session |
Backend creates and manages WebSocket sessions for users when they connect, maintaining session data (e.g., users, messages). |
H |
| Message Handling |
Backend processes "chatSendMessage" events, stores the message, and broadcasts it to all connected clients. |
H |
| Session Join/Leave |
Backend listens for "sessionJoin" and "sessionLeft" events and broadcasts to all clients when a user joins or leaves the session. |
H |
| User Identification |
Each message sent to the backend includes the userId and sessionId for correct message attribution and user identification. |
M |
| Redis Integration |
Messages are temporarily stored in Redis (not MongoDB) for the duration of the session to support real-time chat functionality. |
H |
| WebSocket Connection (Frontend) |
User connects to the WebSocket session upon being redirected to the collaboration page. |
H |
| Session Information |
Session information (session members, chat messages) is managed by the SessionContext.tsx component. |
H |
| Message Sending and Updating |
Users can send a message using the handleSendMessage function, which emits a "chatSendMessage" event to the backend with necessary data. After the backend processes the message, the frontend updates the message status (sent, failed) accordingly. |
H |
| Rejoining Session |
User’s session information (avatars, prior messages) is updated when they refresh or rejoin the session. |
M |
| Chat UI |
Chat interface is responsive and rendered using CSR and SSR to optimize performance and maintainability. |
H |
N3: Code Execution
| Functional Requirement |
Acceptance Criteria |
Priority |
| N3. Code Execution |
|
|
| Code Execution Processing |
Backend validates incoming code execution requests, accepting parameters: code, language, input, and timeout. Ensures execution completes within the specified timeout and captures output, error details, and runtime. |
H |
| Secure Execution Environment |
Each code execution request is run in an isolated Docker container to ensure security. Limits are set on memory (500 MB) and CPU (1 CPU per container) to prevent resource exhaustion attacks. |
H |
| Error Handling and Output |
If execution fails, error details (stderr) are captured and returned in the response. Each test case runs independently, so one failure does not affect the execution of other test cases. |
M |
| Trigger Code Execution (Frontend) |
Adds a submit button to the coding interface, allowing users to execute their code. Button triggers a backend request to the code-execution service with the required parameters. |
H |
| Display Execution Results |
Displays the code output, error messages, and runtime metrics in a structured format. Includes indicators for pass/fail status for each test case. |
H |
| Test Case Orchestration |
Collaboration service retrieves test cases from the question service and sends them to the code-execution service. Executes all test cases concurrently using Promise.all and aggregates results. |
M |
| Real-Time Execution Feedback |
Notifies users in the session when code execution is in progress and upon completion. Displays execution results in real-time via WebSocket updates from the collaboration service. |
M |
N4. Syntax Highlighting
| Functional Requirement |
Acceptance Criteria |
Priority |
| N4. Syntax Highlighting |
|
|
| Language Support |
Highlighting should support multiple programming languages. |
H |
| Dynamic Updates |
Syntax highlighting should update dynamically as users type or edit the code. |
H |
| Language Detection |
Auto-detect the language or allow manual selection for syntax highlighting. |
M |
| Code Elements |
Ensure correct highlighting of code elements like keywords, operators, and strings in different colors. |
L |
N6. Generative AI
| Functional Requirement |
Acceptance Criteria |
Priority |
| N6. Generative AI |
|
|
| Code Review Processing |
Backend validates and processes incoming code snippets, while adding extra metadata to facilitate prompt effectiveness. |
H |
| Structured Response Generation |
Generates structured responses in JSON format, separating explanatory text from code correction snippets. |
H |
| Response Formatting |
Sends formatted feedback to the frontend, ensuring distinct fields for explanatory text and syntax-highlighted code. |
H |
| Trigger Code Review (Frontend) |
Adds a button to the main coding interface that allows users to initiate an AI-powered code review. |
H |
| Response Display |
A panel is displayed to show the code review response in a clear and readable format. |
H |
| Segregation of Response |
Explanatory text and code suggestions are separated using different display strategies. |
L |
| Real-Time Feedback Synchronization |
Ensure fast and seamless feedback integration from backend to frontend, with a response target time of less than 10 seconds to maintain usability. |
M |
N7. Cloud Deployment
| Functional Requirement |
Acceptance Criteria |
Priority |
| N7. Cloud Deployment |
|
|
| Setup Backend Services in GKE |
All backend services are successfully deployed within the GKE cluster and can enter Running status. No k8 deployment or service terminated unexpectedly. |
H |
| Service Discovery within Cluster |
Services can discover other services required for its operations through defined service names. Services can complete operations that require requests sent and responses received from other services. |
H |
| Ingress and Load Balancer |
Configure Google Cloud Load Balancer routes external traffic to Ingress, which directs traffic to the appropriate backend service. Ingress and Load Balancer are correctly configured to handle HTTP and WebSocket connections. |
M |
| Redis for Pub/Sub Service |
Ensure redis cache is accessible to matching-service and collaboration-service for pub/sub mechanism. |
H |
| Frontend Deployment on Vercel |
The frontend is successfully deployed and accessible to end-users via Vercel. Initial load times under 10 seconds to ensure seamless access to the application. |
H |
| Frontend Access to Backend APIs |
Frontend can successfully make authenticated requests to backend REST APIs via JWT tokens. Frontend can establish and maintain WebSocket connections for real-time interactions with backend services, allowing for data updates and interactive features. |
H |
| MongoDB Atlas Connectivity |
All relevant services (e.g., user-service, question-service, collaboration-service) can read and write to MongoDB Atlas. Data consistency is maintained across all services interacting with MongoDB Atlas. |
H |
| Secure Access to External Services |
Secure credentials and access tokens are used for all connections to external services like MongoDB Atlas and SSO login providers. Unauthorized access attempts are logged, and alerts are triggered. |
H |
@rickkoh @jmsandiegoo @evanyan13 @Jajared @shavonneg
