100% found this document useful (1 vote)
60 views

LMS SRS

The document outlines requirements for developing a minimum viable product (MVP) of a learning management system (LMS). Key features of the LMS MVP include user management, quiz/test creation, grading, feedback, randomized question ordering, timers, progress tracking, and a question bank. Functional requirements cover registration, login, assessment tools for instructors, grading automation, and tracking for students. Non-functional requirements specify the technology stack and ensure a user-friendly experience across devices. User stories further define each requirement and acceptance criteria.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
100% found this document useful (1 vote)
60 views

LMS SRS

The document outlines requirements for developing a minimum viable product (MVP) of a learning management system (LMS). Key features of the LMS MVP include user management, quiz/test creation, grading, feedback, randomized question ordering, timers, progress tracking, and a question bank. Functional requirements cover registration, login, assessment tools for instructors, grading automation, and tracking for students. Non-functional requirements specify the technology stack and ensure a user-friendly experience across devices. User stories further define each requirement and acceptance criteria.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

Software Requirements Specification

(SRS) for Learning Management System


(LMS)
MVP
MVP Feature Related Functional Requirement (FR)
FR-1: User Registration
User Management FR-2: User Login
FR-3: Quiz and Test Creation FR-4: Assessment Title, Description, and Time Limit
Quiz and Test FR-5: Multiple Question Types
Creation FR-6: Question Bank
FR-7: Grading and Feedback
Grading and FR-8: Manual Grade Adjustment
Feedback FR-9: Instant Feedback
Randomized
Question Order FR-10: Randomized Question Order
FR-11: Timer Functionality
Timer Functionality FR-12: Timer Display
FR-13: Progress Tracking
Progress Tracking FR-14: Assessment Scores
FR-16: Question Bank
FR-17: Question Bank Categories
Question Bank FR-18: Select Questions from Bank

1. Introduction
1.1 Purpose
The purpose of this Software Requirements Specification (SRS) is to define the functional
and non-functional requirements for the development of a Learning Management System
(LMS). The LMS is designed to facilitate quiz and test creation, automated grading,
feedback, randomized questions, timer functionality, progress tracking, and the creation of
a question bank.
1.2 Scope
This document outlines the key features and functionalities of the LMS, serving as a guide
for the development team to create the Minimum Viable Product (MVP) for this system.
2. System Overview
The LMS will consist of two main user roles: Instructors and Students. Instructors will have
the capability to create assessments, manage a question bank, and review student progress.
Students can access assessments, complete them, and track their scores and progress.
3. Functional Requirements
3.1 User Management
• FR-1: Users can register for the system with a valid email address and password.
• FR-2: Registered users can log in to the system.
3.2 Quiz and Test Creation
• FR-3: Instructors can create assessments, specifying the assessment title,
description, and time limit.
• FR-4: Instructors can add questions to assessments.
• FR-5: Questions can be of multiple types, including multiple-choice, fill in the blanks,
true/false, matching exercises, short answer, long answer, and essay questions.
• FR-6: Instructors can choose questions from the question bank to include in
assessments.
3.3 Grading and Feedback
• FR-7: The system automatically grades assessments based on the selected question
types.
• FR-8: Instructors can manually review and adjust grades if necessary.
• FR-9: Students receive instant feedback after completing an assessment.
3.4 Randomized Question Order
• FR-10: Instructors can enable the randomization of question order in assessments
to ensure uniqueness for each student.
3.5 Timer Functionality
• FR-11: Instructors can set a timer for each assessment.
• FR-12: Students taking assessments see a timer display to manage their time
effectively.
3.6 Progress Tracking
• FR-13: Students have access to a dashboard to track their progress.
• FR-14: Students can view their scores for each assessment.
• FR-15: Instructors can access students' assessment results for evaluation and
feedback purposes.
3.7 Question Bank
• FR-16: Instructors can create a question bank to store questions.
• FR-17: Instructors can categorize and organize questions within the question bank.
• FR-18: Instructors can select questions from the question bank when creating
assessments.
4. Non-Functional Requirements
4.1 Technology Stack – SUBJECTED TO CHANGE
• NFR-1: The system will be developed using HTML, CSS, JavaScript, React for the
frontend, and Node.js with Express.js for the backend.
• NFR-2: The database will be MongoDB.
• NFR-3: User authentication will be handled using JSON Web Tokens (JWT).
• NFR-4: Real-time features (optional) will be implemented using WebSockets or
WebRTC.
4.2 User Experience
• NFR-5: The system will have a user-friendly and responsive design to ensure access
from various devices, including mobile and tablet.
5. Additional Features (Optional for MVP)
• AF-1: User profile management for instructors and students.
• AF-2: Course management and content upload for instructors.
• AF-3: Analytics and reporting for both instructors and students.
• AF-4: Discussion forums or messaging features for communication.
6. Conclusion
This Software Requirements Specification (SRS) outlines the key features, functional and
non-functional requirements for the development of the Learning Management System
(LMS). This document serves as a reference for the development team to implement the
MVP of the LMS and can be expanded upon based on user feedback and future
development needs.

User Stories :

User Story 1: User Registration (FR-1)


As a new user, I want to register for the LMS, so that I can access the system.
Acceptance Criteria:
• The registration form includes fields for email and password.
• Users must provide a valid email address.
• Passwords should meet minimum security requirements (e.g., at least 8 characters,
including letters, numbers, and symbols).
• Users receive a confirmation email upon successful registration.
• The system must securely store user credentials.
• Registration is accessible from both desktop and mobile devices (NFR-5).

User Story 2: User Login (FR-1)


As a registered user, I want to log in to the LMS, so that I can access my account.
Acceptance Criteria:
• Users can access the login page from the main landing page.
• Users must enter their registered email and password to log in.
• The system validates the user's credentials.
• Successful login redirects the user to their dashboard.
• Login is accessible from both desktop and mobile devices (NFR-5).

User Story 3: Quiz and Test Creation (FR-3)


As an instructor, I want to create assessments, so that I can test my students.
Acceptance Criteria:
• Instructors can access the "Create Assessment" page.
• The system allows instructors to provide a title, description, and time limit for the
assessment.
• Instructors can add questions to the assessment, including multiple-choice, fill in the
blanks, true/false, matching exercises, short answer, long answer, and essay
questions (FR-5).
• The system must provide an option to select questions from the question bank (FR-
6).
• Assessments can be saved and edited later.

User Story 4: Grading and Feedback (FR-7)


As the system, I want to automatically grade assessments, so that students receive
immediate feedback.
Acceptance Criteria:
• The system accurately grades multiple-choice, fill in the blanks, true/false, matching
exercises, and other question types as specified (FR-5).
• Instructors can manually review and adjust grades if needed (FR-8).
• Students receive immediate feedback upon completing an assessment (FR-9).

User Story 5: Randomized Question Order (FR-10)


As an instructor, I want to enable randomized question order in assessments, so that each
student receives a unique assessment.
Acceptance Criteria:
• Instructors can activate the randomization feature for an assessment.
• When students access the assessment, questions and/or answer choices are
presented in a random order.
• The system ensures that the order is truly randomized.
User Story 6: Timer Functionality (FR-11)
As an instructor, I want to set a timer for each assessment, so that students manage their
time effectively.
Acceptance Criteria:
• Instructors can define the time limit for an assessment.
• Students taking the assessment see a timer display during the assessment (FR-12).
• The timer accurately counts down from the specified time limit.

User Story 7: Progress Tracking (FR-13)


As a student, I want to track my progress and view my assessment scores, so that I can
monitor my performance.
Acceptance Criteria:
• Students have access to a dashboard where they can see their completed
assessments.
• For each assessment, students can view their score, time taken, and a summary of
correct and incorrect answers (NFR-5).

User Story 8: Question Bank (FR-16)


As an instructor, I want to create a question bank to store questions, so that I can easily
select questions for assessments.
Acceptance Criteria:
• Instructors can access the "Question Bank" page.
• The system allows instructors to create categories or topics for organizing questions
(FR-17).
• Instructors can add, edit, and delete questions in the question bank.
• When creating assessments, instructors can select questions from the question bank
(FR-18).
These user stories provide a detailed breakdown of each functional requirement, including
acceptance criteria and consideration of relevant business rules and non-functional
requirements. They can serve as a basis for development and testing.

You might also like