Requirements - svasquezs1/StudyBank-web GitHub Wiki
Requirements
This page consolidates the current StudyBank requirements using the structure requested in the course template. It also records validation criteria, priority, sprint, responsible person, and implementation status.
1. Purpose
StudyBank is a web platform for the EAFIT academic community that centralizes study materials and peer tutoring in one place. The system allows authenticated users to share and discover academic resources, register as tutors, search for tutors, request tutoring sessions, manage tutor availability, rate completed interactions, and receive notifications related to tutoring requests.
The purpose of this specification is to define functional and non-functional requirements in a verifiable form so that each requirement can be implemented, tested, and traced to project work.
2. Scope
The current MVP covers four application areas:
- Accounts: registration, login, logout, and profile editing.
- Materials: upload, search, filter, detail, download, rating, and catalog sorting.
- Tutoring: tutor registration, tutor search, tutoring requests, request decisions, tutor availability, session completion, ratings, and tutor sorting.
- Notifications: notifications to tutors when a request is created and to students when a request is accepted or rejected.
The MVP is focused on EAFIT users and institutional accounts. Requirements marked Won't have (this time) remain outside the current implementation scope.
3. Definitions
| Term | Definition |
|---|---|
| StudyBank | Web platform developed for sharing study resources and coordinating peer tutoring. |
| RF | Functional Requirement. |
| RNF | Non-Functional Requirement. |
| TutorProfile | Profile that identifies a registered user as a tutor and associates the tutor with subjects. |
| TutoringRequest | Request created by a student for a tutoring session with a tutor. |
| TutorAvailability | Recurring day/time slot in which a tutor is available to receive requests. |
| MaterialRating | Rating from 1 to 5 stars assigned to a material by a user who downloaded it. |
| TutoringRating | Rating from 1 to 5 stars assigned by a student after a completed tutoring session. |
| MoSCoW | Prioritisation method: Must, Should, Could, Won't. |
| Validation criterion | Observable condition used to confirm that a requirement has been satisfied. |
4. References
- StudyBank repository
- Project Board
- Deliverable 1
- Deliverable 2
- Deliverable 3
- Weekly Meetings
- Retrospectives
- Project README and
requirements.txtin the main repository.
5. External Interfaces
5.1 User interface
StudyBank is accessed through a web browser. The interface provides forms, search controls, cards, status indicators, navigation links, and feedback messages for the main workflows. Protected operations require an authenticated session.
5.2 Software interfaces
- Django authentication/session framework for account authentication and protected views.
- Django ORM for persistence and relationships between application models.
- SQLite as the configured relational database in the current project settings.
- Django storage API for uploaded materials. Local media storage is used when external object-storage credentials are absent; an S3-compatible storage backend can be enabled through the configured environment variables.
- WhiteNoise for static-file delivery.
5.3 Communication interfaces
The application uses HTTP/HTTPS requests between the user's browser and the Django web application. No public external API is required for the current MVP.
6. Functional Requirements
Priority keywords follow the course rule: Must → SHALL, Should → SHOULD, Could → COULD, Won't → WON'T.
6.1 Accounts
| ID | Requirement | Priority | Specification | Validation criterion | Sprint | Responsible | Status |
|---|---|---|---|---|---|---|---|
| RF-01 | User registration | Must | THE system SHALL PROVIDE visitors WITH THE ABILITY TO register an account using a unique institutional email ending in @eafit.edu.co. |
A valid new @eafit.edu.co email creates one account; a duplicate or non-institutional email is rejected. |
Sprint 1 | Sebastián | Implemented |
| RF-02 | User login | Must | THE system SHALL PROVIDE registered users WITH THE ABILITY TO log in using institutional email and password. | Valid credentials create an authenticated session; invalid credentials do not. | Sprint 1 | Sebastián | Implemented |
| RF-03 | User profile editing | Must | THE system SHALL PROVIDE authenticated users WITH THE ABILITY TO update their profile data, including university, program, and profile picture. | Saving valid changes persists them and they are displayed on the next profile load. | Sprint 2 | Sebastián | Implemented |
| RF-21 | Session logout | Must | THE system SHALL PROVIDE authenticated users WITH THE ABILITY TO end their current session. | After logout, the session is invalidated and protected views require authentication again. | Sprint 2 | Sebastián | Implemented |
| RF-22 | Password recovery | Could | THE system COULD PROVIDE registered users WITH THE ABILITY TO recover access when they forget their password. | A recovery flow can reset the password for an existing account and the new password can be used to log in. | Backlog | Unassigned | Backlog |
| RF-23 | Public user profile view | Could | THE system COULD PROVIDE registered users WITH THE ABILITY TO view another user's public profile information. | Opening an existing user's public profile displays only fields defined as public. | Backlog | Unassigned | Backlog |
6.2 Study Materials
| ID | Requirement | Priority | Specification | Validation criterion | Sprint | Responsible | Status |
|---|---|---|---|---|---|---|---|
| RF-04 | Upload study material | Must | THE system SHALL PROVIDE authenticated users WITH THE ABILITY TO upload study material associated with a course, university, file type, title, and file. | A valid upload creates one material record and stores the file; invalid files are rejected by validation. | Sprint 1 | Sebastián | Implemented |
| RF-05 | Search study materials | Must | THE system SHALL PROVIDE authenticated users WITH THE ABILITY TO search study materials by keyword. | A keyword query returns materials whose title, description, or course matches the query. | Sprint 2 | Gisel | Implemented |
| RF-06 | Filter materials by subject | Must | THE system SHALL PROVIDE authenticated users WITH THE ABILITY TO filter study materials by course/subject. | Selecting a course returns only materials associated with that course. | Sprint 2 | Gisel | Implemented |
| RF-07 | View material details | Must | THE system SHALL PROVIDE authenticated users WITH THE ABILITY TO view the details of a selected material. | Opening a valid material shows its metadata and available actions. | Sprint 1 | Gisel | Implemented |
| RF-08 | Download material | Must | THE system SHALL PROVIDE authenticated users WITH THE ABILITY TO download an available study material file. | A valid material download returns the stored file with attachment headers. | Sprint 1 | Gisel | Implemented |
| RF-13 | Rate material | Should | AFTER downloading a material, THE system SHOULD PROVIDE authenticated users WITH THE ABILITY TO assign a rating from 1 to 5 stars. | A user who downloaded the material can create or update one rating in the 1–5 range; a user without a download cannot rate it. | Sprint 3 | Gisel | Implemented — PR #65 |
| RF-14 | Rank materials by rating | Should | THE system SHOULD PROVIDE authenticated users WITH THE ABILITY TO sort materials from highest to lowest average rating. | Selecting “Highest Rating” orders rated materials by descending average rating and places unrated items after rated items. | Sprint 3 | Gisel | Implemented — PR #66 |
| RF-24 | Edit uploaded material | Could | THE system COULD PROVIDE the uploader WITH THE ABILITY TO edit metadata for a material they uploaded. | The owner can save valid changes; another user cannot modify the material. | Backlog | Unassigned | Backlog |
| RF-25 | Delete uploaded material | Could | THE system COULD PROVIDE the uploader WITH THE ABILITY TO delete a material they uploaded. | The owner can remove the material; another user cannot delete it. | Backlog | Unassigned | Backlog |
| RF-26 | Filter materials by university | Could | THE system COULD PROVIDE authenticated users WITH THE ABILITY TO filter study materials by university. | Selecting a university returns only materials associated with that university. | Backlog | Unassigned | Backlog |
| RF-29 | Most-downloaded materials panel | Could | THE system COULD PROVIDE authenticated users WITH THE ABILITY TO view materials ordered by total number of downloads. | The view orders materials by the stored/aggregated download count from highest to lowest. | Backlog | Unassigned | Backlog |
| RF-31 | Report inappropriate material | Won't | THE system WON'T PROVIDE a material-reporting workflow in the current release. | No report-material workflow is included in the current sprint scope. | Future | Unassigned | Won't have this time |
| RF-33 | Top-rated materials report | Won't | THE system WON'T PROVIDE a per-subject top-rated-material report in the current release. | No dedicated top-rated-per-subject report is included in the current sprint scope. | Future | Unassigned | Won't have this time |
6.3 Tutoring
| ID | Requirement | Priority | Specification | Validation criterion | Sprint | Responsible | Status |
|---|---|---|---|---|---|---|---|
| RF-09 | Register as a tutor | Must | THE system SHALL PROVIDE authenticated users WITH THE ABILITY TO register as tutors and select one or more subjects they can teach. New tutor profiles SHALL require approval before appearing in tutor search. | A valid registration creates one tutor profile with selected subjects and is_approved=False; only approved tutors appear in search results. |
Sprint 1 | Samuel | Implemented |
| RF-10 | Search tutors by subject | Must | THE system SHALL PROVIDE authenticated users WITH THE ABILITY TO search approved tutors by subject. | Selecting a subject returns approved tutors associated with that subject and excludes unapproved tutors. | Sprint 1 | Samuel | Implemented |
| RF-11 | Request tutoring session | Must | THE system SHALL PROVIDE students WITH THE ABILITY TO request tutoring from an approved tutor by selecting subject, future date/time, mode, and an optional message. | A valid request within tutor availability creates one pending request; invalid tutor, past date/time, or unavailable schedule is rejected. | Sprint 2 | Samuel | Implemented |
| RF-12 | Accept/reject tutoring request | Must | THE system SHALL PROVIDE approved tutors WITH THE ABILITY TO accept or reject their pending tutoring requests. | The owner tutor can change a pending request to accepted or rejected; unrelated users cannot manage it. | Sprint 2 | Samuel | Implemented |
| RF-15 | Tutor availability | Should | THE system SHOULD PROVIDE approved tutors WITH THE ABILITY TO create, edit, and delete recurring availability slots. | Valid non-overlapping slots with end time after start time can be saved; overlapping or invalid ranges are rejected. | Sprint 3 | Samuel | Implemented — PR #68 |
| RF-16 | Tutor public profile | Should | THE system SHOULD PROVIDE authenticated users WITH THE ABILITY TO view a tutor profile that includes tutor information, offered subjects, and average rating. | Opening a tutor profile displays the tutor data, subjects, and calculated average rating when ratings exist. | Sprint 3 | Sebastián | Implemented — PR #71 |
| RF-17 | Rate tutoring session | Should | AFTER a tutoring request is marked completed, THE system SHOULD PROVIDE its student WITH THE ABILITY TO rate the session from 1 to 5 stars and optionally submit feedback. | Only the owning student can rate a completed request, and each request can have at most one rating. | Sprint 3 | Samuel | Implemented — PR #69 |
| RF-18 | Rank tutors by rating | Should | THE system SHOULD PROVIDE authenticated users WITH THE ABILITY TO sort approved tutors by average rating. | Selecting rating sort orders tutors by descending average rating, uses review count as a tie-breaker, and places unrated tutors last. | Sprint 3 | Samuel | Implemented — PR #70 (merged through #69) |
| RF-19 | Notify tutor of new request | Should | AS SOON AS a tutoring request is created, THE system SHOULD notify the corresponding tutor. | Creating a tutoring request creates exactly one notification for the tutor with a link to incoming requests. | Sprint 3 | Sebastián | Implemented — PR #63 |
| RF-20 | Notify student of decision | Should | AS SOON AS a tutor accepts or rejects a tutoring request, THE system SHOULD notify the requesting student. | Changing a request from pending to accepted or rejected creates one notification for the student; repeated saves do not duplicate it. | Sprint 3 | Sebastián | Implemented — PR #64 |
| RF-27 | View tutoring request status | Could | THE system COULD PROVIDE students WITH THE ABILITY TO view the current status of their tutoring requests. | The student's request list displays each request and its current status. | Backlog | Unassigned | Available as part of current request list |
| RF-28 | Cancel tutoring session | Could | THE system COULD PROVIDE students WITH THE ABILITY TO cancel an eligible tutoring session. | The owning student can cancel an eligible request and the updated state is persisted. | Backlog | Unassigned | Backlog |
| RF-30 | Tutor activity statistics | Could | THE system COULD PROVIDE tutors WITH THE ABILITY TO view summary statistics about their tutoring activity. | The tutor statistics view reports values derived from that tutor's sessions only. | Backlog | Unassigned | Backlog |
| RF-32 | Most-searched trends dashboard | Won't | THE system WON'T PROVIDE an administrator trends dashboard in the current release. | No trends dashboard is included in the current sprint scope. | Future | Unassigned | Won't have this time |
7. Non-Functional Requirements
The following wording removes subjective terms and uses measurable verification criteria.
| ID | Requirement | Priority | Specification | Verification criterion |
|---|---|---|---|---|
| RNF-01 | Usability | Must | THE system SHALL allow a first-time authenticated user to complete the main material-search and tutor-search flows using visible labels and controls. | In a usability check with representative users, at least 80% complete both flows without assistance. |
| RNF-02 | Responsive layout | Must | THE system SHALL render the main navigation, forms, and content cards without horizontal page scrolling at viewport widths of 375 px, 768 px, and 1440 px. | Manually verify the registration, materials, tutor search, and tutoring-request views at the three target widths. |
| RNF-03 | Response time | Must | THE system SHALL return the main authenticated HTML views within 2 seconds for at least 95% of requests in the agreed test environment with up to 20 concurrent users. | Execute a timed test of the main views and confirm the 95th percentile is at or below 2 seconds. |
| RNF-04 | Password protection | Must | THE system SHALL store user passwords using Django's configured password hashing mechanism with PBKDF2. | Inspect stored password values and confirm Django identifies the configured PBKDF2 hasher; authentication tests must pass with hashed credentials. |
| RNF-05 | Restricted access | Must | THE system SHALL require authentication for protected resources, including material upload, material browsing, tutor registration, tutor search, tutoring management, ratings, and notifications. | An unauthenticated request to each protected view redirects to the configured login page. |
| RNF-06 | Browser compatibility | Must | THE system SHALL support the current stable desktop versions of Chrome, Firefox, Edge, and Safari for the main user flows. | Execute registration/login, material search/download, tutor search, and tutoring-request flows in each target browser without blocking functional errors. |
8. Performance Requirements
- The main authenticated HTML views target a 95th-percentile server response time of 2 seconds or less in the agreed test environment with up to 20 concurrent users.
- Search and sort operations must return deterministic results for the same stored data and query parameters.
- Database queries used for lists should use filtering, annotations,
select_related, orprefetch_relatedwhere appropriate to avoid unnecessary per-row queries. - File downloads must stream the stored file rather than loading the entire file into an HTML response.
9. Design Constraints
- The application is implemented with Django and follows Django's Model-View-Template structure.
- The custom user model uses institutional email as the authentication identifier.
- The current project configuration uses SQLite as its relational database.
- Uploaded materials are restricted by the application's configured file extensions and maximum file size.
- Secrets and deployment-specific values are read from environment variables rather than hard-coded in source control.
- Sprint work is managed through GitHub issues, pull requests, the project board, and the project Wiki.
10. MoSCoW Summary
| Priority | Requirements |
|---|---|
| Must have | RF-01, RF-02, RF-03, RF-04, RF-05, RF-06, RF-07, RF-08, RF-09, RF-10, RF-11, RF-12, RF-21 |
| Should have | RF-13, RF-14, RF-15, RF-16, RF-17, RF-18, RF-19, RF-20 |
| Could have | RF-22, RF-23, RF-24, RF-25, RF-26, RF-27, RF-28, RF-29, RF-30 |
| Won't have (this time) | RF-31, RF-32, RF-33 |