Sprint 3 · 05/09/2026 – 14/10/2026

• 1. Architecture & Data
  • 1.1 Deployment Diagram
  • 1.2 Component Diagram
  • 1.3 Data Model
• 2. Corporate Image
• 3. Repository
• 4. Video
• 5. Project Management
  • 5.1 Backlog
  • 5.2 Weekly Meetings
  • 5.3 Retrospective
• 6. Sprint Review
• 7. Corrections to Previous Deliverables
  • 7.1 Corrections to Deliverable 2
  • 7.2 Mockups
  • 7.3 Pending Corrections to Deliverable 1

Diagram description:

The diagram illustrates the physical deployment architecture and execution environments of the StudyBank project:

• Client Devices: Users access the application from PC devices (Windows, MacOS) or mobile devices (Android, iOS) connecting via the HTTPS protocol.
• Local Server (Execution Environment): The system is hosted in a Linux environment.
• Base Software: At the operating system level, the programming language (Python), the package manager (Pip), and the version control system (Git) are installed.
• Project Dependencies: Through requirements.txt, the Django framework (version 6.0.7) and necessary libraries such as Pillow 12.3.0, django-storages 1.14.6, boto3 1.43.56, whitenoise 6.12.0, and python-dotenv 1.2.2 are installed in the environment.
• Django Application: The project is modularized into four main applications: accounts, materials, tutoring, and notifications.
• Database: SQLite3 is used as a relational database to persist information for all system models (University, Program, User, Course, Material, Subject, TutorProfile, TutoringRequest, MaterialDownload, MaterialRating, TutoringRating, Notification, TutorAvailability).
• External Storage: The system connects via HTTPS to the Cloudflare R2 service for static and media file management.

Changes from Deliverable 2:

• Added the exact versions of each technology and library in the corresponding nodes of the diagram, taken directly from the project's requirements.txt file (e.g., Django 6.0.7, Pillow 12.3.0, django-storages 1.14.6, etc.) to address the instructor's feedback.
• Added the new notifications application to the components (Apps) block of the StudyBank project.
• Incorporated the new entities/tables into the SQLite3 database resulting from the Sprint 3 functionalities:
  • MaterialDownload and MaterialRating (pertaining to material management and reviews).
  • TutorAvailability and TutoringRating (pertaining to tutor schedule management and session ratings).
  • Notification (pertaining to the new alerts and notifications functionality).

General architecture

StudyBank is a self-contained web application composed of four main functional modules:

User and account management. Study material management. Tutoring management. Notifications.

Users access the system through a web browser. Requests are processed by Django, which communicates with the application models and database before returning an HTML response. Tutoring request state changes emit Django Signals that create notifications for the affected users.

The current application does not expose or consume an external public API.

flowchart LR

U[University Student] --> B[Web Browser]



B -->|HTTP / HTTPS| D[Django Application]



subgraph Django Application

URL[URL Router]

V[Views]

T[Templates]

M[Models]

A[Authentication and Authorization]

S[Static and Media Configuration]

Sig[Django Signals]

end



D --> URL

URL --> V

V --> M

V --> T

V --> A

V --> Sig

Sig -->|Create Notifications| M

T --> B



M --> DB[(SQLite Database)]

S --> W[WhiteNoise Static Files]

S --> L[Local Media Storage]

S -. Production configuration .-> R[Cloudflare R2 Storage]

Module descriptions:

• accounts: manages registration, authentication integration and profile editing. Its main views are register and edit_profile, and its user model is referenced by the other applications.
• materials: manages material upload, detail, search/filter, download tracking, material rating and catalog sorting. Sprint 3 added MaterialDownload and MaterialRating, plus the rate_material flow and rating/download-based sorting.
• tutoring: manages tutor registration and search, tutoring requests, tutor decisions, recurring tutor availability, session completion, tutoring ratings and tutor sorting. Sprint 3 added TutorAvailability, TutoringRating, completed-session handling and rating/popularity ordering.
• notifications: manages the user's notification list and unread count. Django signals observe TutoringRequest creation and status changes to create notifications for tutors and students for RF-19 and RF-20.

Note on dependencies: The dashed lines in the component diagram indicate that specific workflows and complete modules require a valid user session. Specifically, the entire tutoring and notifications modules depend on the login function of accounts. Additionally, within the materials module, specific interfaces such as upload, material_detail, and download_material have explicit dependencies mapped to the login function, indicating that these specific actions are restricted to authenticated users, while other interfaces in the module remain public or are handled differently. Finally, there is an explicit dependency mapped from notifications to tutoring, illustrating that the notifications module relies on tutoring events (via Django Signals) to generate alerts.

Changes from Deliverable 2 (Sprint 3):

• Added the notifications application and its dependency on TutoringRequest events.
• Added material download tracking and material ratings for RF-13 and RF-14.
• Added tutor availability management for RF-15.
• Added completed tutoring-session ratings for RF-17.
• Added tutor sorting by rating/review count for RF-18.
• Added notification flows for RF-19 and RF-20.
• Confirmed the materials module includes the search_materials flow used by RF-05 and RF-06.
• Updated the tutoring module to include request completion as a prerequisite for rating a session.

Changes from Deliverable 2:

Click the diagram to open it in full size.

Changes from the previous version: extended the relational model with the material feedback flow (materials_materialdownload for RF-14 and materials_materialrating for RF-13), the tutoring scheduling and feedback flow (tutoring_tutoravailability for RF-15 and tutoring_tutoringrating for RF-17/RF-18), and the notifications module (notifications_notification for RF-19/RF-20). The tutoring_tutoringrequest entity now carries the full session lifecycle (scheduled_at, mode, message, status, timestamps).

accounts_university represents an institution available in StudyBank. A university may offer multiple academic programs, be associated with multiple users, and be associated with multiple study materials.

accounts_program represents an academic program or major offered by a university. Each program belongs to one university, while one university may offer multiple programs.

accounts_user represents a registered person on the platform. StudyBank uses the institutional email as the authentication identifier instead of a username. A user may belong to a university and a program, upload materials, have one tutor profile, submit tutoring requests as a student, rate and download materials, rate completed tutoring sessions, and receive notifications. university and program may remain empty when the account is created.

materials_course represents a course associated with study materials (e.g. Calculus I, Databases, Operating Systems). A course may be associated with multiple materials.

materials_material represents a study resource uploaded by a user (notes, exams, summaries, lab reports, documents or images). A material belongs to one uploader, one course, and one university. It may be downloaded and rated by multiple users.

materials_materialdownload records that a user downloaded a material. It enables the "Most Downloaded" ranking and gates the ability to rate a material. Each (material, user) pair is unique; repeated downloads update the counter and timestamp instead of creating new rows.

materials_materialrating stores a 1-to-5 star rating a user gives to a material. Each user may rate a given material only once; the rating can be updated afterwards.

tutoring_subject represents a subject that a tutor can offer (e.g. Calculus, Programming, Physics). Maintained as a fixed catalog through the Django administration panel.

tutoring_tutorprofile extends a registered user with tutoring capabilities. Each tutor profile belongs to exactly one user (one-to-one), may offer one or more subjects, defines weekly availability slots, holds an approval status, and is hidden from tutor searches until approved.

tutoring_tutorprofile_subjects is the junction table that implements the many-to-many relationship between tutoring_tutorprofile and tutoring_subject. Each row links one tutor profile to one subject, and the pair must be unique.

tutoring_tutoravailability represents a recurring weekly time slot during which a tutor is available. Each slot belongs to one tutor profile. Slots must be unique per tutor, day and time range.

tutoring_tutoringrequest represents a session request sent by a student to a tutor for a specific subject. It belongs to one student (accounts_user), one tutor (tutoring_tutorprofile), and one subject (tutoring_subject, on_delete=PROTECT, so a subject cannot be deleted while tutoring requests reference it).

tutoring_tutoringrating stores the rating and feedback a student leaves after a completed tutoring session. It is tied one-to-one to a tutoring request, and references the student and the tutor profile involved.

notifications_notification represents an in-app notification delivered to a user (e.g. a new tutoring request, a status change, or a system message). It always targets one recipient and may optionally reference the tutoring request that triggered it.

materials_course and tutoring_subject are maintained as separate catalogs:

• materials_course is used by the study materials module.
• tutoring_subject is used by the tutoring module.

This separation lets both modules be developed independently. A future refactor may unify both entities if the team determines that they represent the same academic concept.

The following tables are currently implemented:

• accounts_university
• accounts_program
• accounts_user
• materials_course
• materials_material
• materials_materialdownload
• materials_materialrating
• tutoring_subject
• tutoring_tutorprofile
• tutoring_tutorprofile_subjects
• tutoring_tutoravailability
• tutoring_tutoringrequest
• notifications_notification

The following table is implemented in a feature branch and not yet merged into main:

• tutoring_tutoringrating (RF-17 / RF-18)

Implementation status is tracked through GitHub Issues, Pull Requests, and the project board.

Colors currently defined in the project's stylesheet (static/css/styles.css, :root block):

Swatch	Color	CSS variable	Hex	Use
	Ink	--ink	#1a1d24	Main background
	Ink soft	--ink-soft	#242832	Surfaces and cards
	Paper	--paper	#f5f2e9	Main text
	Paper dim	--paper-dim	#a8a89c	Secondary text
	Amber	--amber	#e0a458	Accent and highlights
	Amber deep	--amber-deep	#c47f2e	Accent hover state
	Line	--line	#333744	Borders
	OK	--ok	#7fa88a	Success states
	Danger	--danger	#c96b6b	Error states

Typography: Fraunces for headings and the brand name; Inter for interface text. Both are loaded from Google Fonts in base.html (Fraunces 400/600/900, Inter 400/500/600).

The following screenshots show how the StudyBank logo, slogan and color palette are applied consistently across the web application.

Evidence 1: Logo, slogan and color palette in the application.

Evidence 2: Logo, slogan and color palette in the application.

Evidence 3: Logo, slogan and color palette in the application.

Evidence 4: Logo, slogan and color palette in the application.

• Repository: svasquezs1/StudyBank-web
• Instructions to run the project: README
• Required libraries: requirements.txt
• No new libraries were added in Sprint 3; requirements.txt is unchanged.

Commits by member — Sprint 3 (05/09/2026 – 14/10/2026), merged into main:

Pull requests merged in Sprint 3: #62 (materials list fix), #63 (RF-19), #64 (RF-20), #65 (RF-13), #66 (RF-14), #67 (footer and slogan), #68 (RF-15), #69 (RF-17, includes #70 RF-18), #71 (RF-16), #72 (navbar) and #73 (UI consistency).

Automated tests: 73 tests pass in main (python manage.py test): 17 in notifications, 53 in tutoring (including test_rf16.py, test_rf17.py and test_rf18.py) and 3 in materials.

The video (4–5 minutes) follows the structure requested in the template, and the three members appear on camera:

Videos links: https://drive.google.com/file/d/1FedOQCn6UPHSz9tBCfbXw8_MWEvMzVf5/view?usp=sharing https://drive.google.com/file/d/10hFn7xa1VH2TYCUFj6UCL7Vd5IS6BN0O/view?usp=sharing https://drive.google.com/file/d/1qt_t_AZIU98ylJWAWaVkNNsvP6nIh0Fg/view?usp=sharing https://drive.google.com/file/d/1vYWSz3HFYFLwgUgqafCoG0W-fMRQWIQ7/view?usp=sharing

⚠️ como hemos tenido problemas para la edición del video debido a percances de varios miembros del equipo, se adjuntan los links de algunos videos individuales como prueba de que ya se hizo la grabación pero falta unificarlos. En bien esté listo el video final se adjuntará.

• Project Board
• Requirements — status, sprint, and responsible person for every requirement.

Requirements planned for Sprint 3 — 8 of 8 completed and merged into main:

The acceptance criteria of each requirement are in its GitHub issue.

Tasks per requirement:

See Weekly Meetings — Sprint 3.

🔄 PARTIAL:

• Samuel completed his individual answers for Sprint 3 (10/09, 17/09, 24/09, 01/10 and 08/10). Sebastián and Gisel still need to complete their individual answers using the questions required by the template.
• Meetings with the Product Owner must be recorded (required by the template).
• Follow-ups with the project managers, including the traffic-light status meeting, with its real date.

See Retrospectives — Sprint 3.

✅ DONE: Sprint 1, Sprint 2 and Sprint 3 retrospective answers are documented on Retrospectives, using the three required questions.

The Sprint Review is presented in class:

1. Pitch presented by a single member (Sebastián).
2. Demo of the Sprint 3 requirements by each member, prioritising the ones with the highest value for the final product: tutor profile with average rating (RF-16), notifications (RF-19, RF-20), material and tutor ratings (RF-13, RF-17) and sorting (RF-14, RF-18).

Corrections requested by the instructor on Deliverable 2, applied during Sprint 3.

Wireframes of the views where the Sprint 2 requirements are reflected. Each mockup answers: What? (main content groups), Where? (structure of the information), and How? (user interaction).

• What?

  • Global navigation bar at the top.
  • View header with the "Materials" title and a brief description.
  • Main text search bar.
  • Filter section with four dropdown menus and an action button.
  • Result cards displaying the study materials.

• Where?

  • The navigation menu is located at the top margin, with the logo on the left and links on the right.
  • The title and instructions are in the top-left area of the main content section.
  • The search bar extends horizontally right below the descriptive text.
  • The filter selectors (University, Program, Course, and Topic) are aligned in a horizontal row alongside the "Filter" button.
  • Search results appear at the bottom organized in card format, showing the document title, author, format (e.g., PDF), rating, and the download button.

• How?

  • The student can type directly into the search bar to find a material by its name.
  • The user can use the dropdown menus to narrow the search hierarchically (for example, exclusively selecting Universidad EAFIT, followed by their academic program, course, and specific topic).
  • The user clicks the yellow "Filter" button to apply the criteria and update the results.
  • The user reviews the materials and clicks the "Download" button on the corresponding card to download the file to their device.

• What?

  • Global navigation bar at the top.
  • View header with the title "Study material" and a descriptive subtitle.
  • Primary action button labeled "Upload material".
  • Search and filter area containing a text input field, a course dropdown menu, a "Search" button, and a "Clear" option.
  • Dynamic text indicator showing the number of search results found.
  • Result cards displaying the study materials with labels for document type, title, course, university (Universidad EAFIT), uploader email, and an action button.
  • Footer containing the platform name and academic project details.

• Where?

  • The navigation menu is horizontally aligned at the top edge of the screen.
  • The section title and its description are located in the top-left area of the main content section.
  • The "Upload material" button is positioned directly below the descriptive text on the left.
  • The search bar, course dropdown, and search controls are aligned horizontally on the right side, opposite the main title.
  • The results count message is placed centrally, just above the material cards.
  • The material result cards are arranged in a grid layout in the lower central area.
  • The footer is placed at the very bottom margin of the page.

• How?

  • The student clicks the "Upload material" button to navigate to the resource submission form.
  • The user types keywords into the search input and selects a specific course from the dropdown menu to filter the content.
  • The user clicks the "Search" button to execute the query, which updates the view and displays a confirmation message with the active search parameters.
  • The user clicks the "Clear" text link next to the search button to reset all active filters.
  • The user clicks the "View Details" button on a specific card to access the full information of that particular document or exam.

This flow is composed of two main views: finding a tutor and filling out the request form.

• What?

  • Global navigation bar at the top.
  • Header with the section label "TUTOR SEARCH", the main title "Find a tutor", and a brief description.
  • Search controls featuring a "Subject" dropdown menu and a "Search" button.
  • A result card displaying an approved tutor.
  • The tutor result card contains the tutor's email address ([email protected]), the subject they teach ("Calculo 3"), and a "Request tutoring" action button.

• Where?

  • The navigation menu is horizontally aligned at the top edge of the screen.
  • The search form and results are enclosed within a large, centered dark card.
  • Inside the main container, the title and subtitle are located at the top left.
  • The subject dropdown and the "Search" button are horizontally aligned directly below the subtitle.
  • The tutor result card is nested inside the main container, positioned below the search controls.
  • Inside the result card, the tutor's email is aligned to the left, the subjects to the right, and the action button spans the bottom.

• How?

  • The user interacts with the "Subject" dropdown menu to filter the list of tutors.
  • The user clicks the "Search" button to execute the query and display matching tutors.
  • The user clicks the "Request tutoring" button on a specific tutor's card to proceed to the session request form.

• What?

  • Global navigation bar at the top.
  • Main container card for the tutoring request form.
  • Header featuring the label "TUTORING REQUEST", the title "Request tutoring", and text specifying the target tutor's email address[cite: 3].
  • Form fields including a "Subject" dropdown, a "Preferred date and time" picker, a "Tutoring mode" dropdown, and a "Message for the tutor" text area.
  • Primary action button labeled "Send request".

• Where?

  • The global navigation menu remains at the top margin.
  • The entire form is enclosed in a dark container centered on the screen.
  • The titles and target tutor information are located at the top of the container.
  • The input fields (Subject, Date/Time, Mode, Message) are arranged vertically below the header text.
  • The "Send request" button is located at the bottom left of the form area.

• How?

  • The student uses the "Subject" dropdown to select the specific class they need help with.
  • The student interacts with the date and time picker inputs to set their preferred schedule for the session.
  • The student selects the "Tutoring mode" from the provided dropdown list.
  • The student types specific details or questions in the "Message for the tutor" text box.
  • The student clicks the yellow "Send request" button to submit the application to the selected tutor.

• What?

  • Global navigation bar at the top.
  • Header featuring the section label "MY TUTORING REQUESTS" and the main title "My requests".
  • System feedback message confirming the successful submission: "Tutoring request sent successfully. Your request is waiting for the tutor's response."
  • A list of request cards displaying the details of the student's tutoring requests.
  • Each card contains the subject ("Calculo 3"), the target tutor's email, date and time, tutoring mode, current status ("Pending"), and the attached message.

• Where?

  • The global navigation menu remains at the top margin.
  • The title and success message are located at the top of the main central container.
  • The request cards are vertically stacked below the success message within the container.
  • Inside each card, the session details are organized into a two-column grid layout.

• How?

  • Upon submitting a request, the student is automatically redirected to this view to see the confirmation message.
  • The student reviews the details of their submitted requests and verifies that the status is set to "Pending" while awaiting the tutor's response.

• What?

  • Global navigation bar at the top.
  • Header with the section label "TUTORING REQUESTS", the main title "Incoming requests", and a brief descriptive subtitle.
  • A detailed request card displaying information about a pending tutoring session.
  • The card data includes the subject ("Calculo 3"), the requesting student's email, date and time, tutoring mode, current status ("Pending"), and a specific message from the student.
  • Action buttons to respond to the request, labeled "Accept" and "Reject".

• Where?

  • The navigation menu is positioned horizontally at the top edge of the screen.
  • The main title and description are located in the top-left area of the main content container.
  • The pending request card is placed centrally below the header text.
  • Inside the card, the session details are organized into a two-column layout.
  • The "Accept" and "Reject" buttons are vertically stacked in the bottom-left corner of the request card.

• How?

  • The tutor reviews the session details, schedule, and student message directly on the card.
  • The tutor clicks the primary yellow "Accept" button to approve the tutoring session.
  • Alternatively, the tutor clicks the secondary "Reject" button to decline the student's request.

Corrections from the instructor's feedback on Deliverable 1 that remained open.

✅ DONE (SAM-1 — Samuel): functional requirements were rewritten in the requested template structure on Requirements, each with a validation criterion and the correct MoSCoW keyword (SHALL / SHOULD / COULD / WON'T). RF-21 to RF-33 were converted from user-story wording and RF-26 now uses COULD.

✅ DONE (SAM-1 — Samuel): non-functional requirements were rewritten on Requirements using objective wording and explicit verification criteria. Subjective expressions and the negative password-storage statement were removed.

Frequency of use of the logical database requirements (item "b) Frequency of use" of the template, missing in Deliverable 1):

✅ DONE (SAM-2 — Samuel; shared with GIS-5): Requirements now includes Purpose, Scope, Definitions, References, External Interfaces, Performance Requirements and Design Constraints.