Sprint 1

This page shows the project as it was delivered at the end of Sprint 1. Corrections made after the instructor's feedback are documented in Deliverable 2.

• 1. Introduction
  • 1.1 Product Perspective
  • 1.2 Product Functions
  • 1.3 User Characteristics
  • 1.4 Limitations
• 2. Specific Requirements
  • 2.1 Functions
  • 2.2 Usability Requirements
  • 2.3 Logical Database Requirements
  • 2.4 Non-Functional Requirements
• 3. Video
• 4. Project Management
  • 4.1 GitHub Project and Sprint 1 Requirements
  • 4.2 Weekly Meetings
  • 4.3 Retrospective
  • 4.4 Class Assignments

StudyBank is a standalone and self-contained web application. It is not a component of an existing Universidad EAFIT system and does not currently depend on integration with university platforms or third-party academic systems.

The application follows Django's Model-View-Template architecture and is accessed through a responsive web interface.

a) System interfaces

StudyBank is a standalone system; it is not part of a larger system.

b) User interfaces

Users interact with StudyBank exclusively through a responsive web application accessible from modern desktop and mobile browsers.

The interface follows the shared visual design defined by the team:

• Dark background.
• Amber accent color.
• Fraunces typography for headings.
• Inter typography for general text.
• Consistent navigation bar and footer. c) Hardware interfaces

StudyBank has no direct hardware dependency. Users only need:

• A device capable of running a modern web browser.
• An internet connection. d) Software interfaces

The project uses the following software components:

• Django as the web framework.
• SQLite as the relational database during the current development stage.
• WhiteNoise for serving static files.
• Cloudflare R2-compatible storage for production file storage when configured.
• Local file storage during development when external storage credentials are not available. e) Communications interfaces

Communication between the browser and the server takes place through standard HTTP or HTTPS requests.

f) Memory

⚠️ FALTANTE: no existía en la wiki del Sprint 1. Se agregó en el Sprint 2 como corrección → va en Deliverable 2.

g) Operations

⚠️ FALTANTE: no existía en la wiki del Sprint 1. Se agregó en el Sprint 2 como corrección → va en Deliverable 2.

h) Site adaptation requirements

The application is configured through environment variables, including:

• SECRET_KEY
• DEBUG
• ALLOWED_HOSTS
• Optional Cloudflare R2 credentials This allows the project to run in local and production environments without modifying the source code.

StudyBank is a standalone web application designed to centralize academic study materials and connect university students with tutors.

The platform is divided into two main functional areas:

Study material sharing

Registered users will be able to:

• Upload study materials.
• Associate materials with a subject, university, and file type.
• Search and filter available materials.
• View material details.
• Download academic resources.
• Rate downloaded materials. Tutoring

Registered users will be able to:

• Register as tutors.
• Select the subjects they are able to teach.
• Search for approved tutors by subject. Additional tutoring functions, such as requesting tutoring sessions and accepting or rejecting requests, are planned for later requirements and are not part of the currently implemented functionality.

MVP scope

The Minimum Viable Product includes or plans to include the following core capabilities:

• User registration using an institutional email.
• User login.
• User profile management.
• Uploading study materials.
• Searching and filtering study materials.
• Viewing and downloading study materials.
• Rating study materials.
• Ranking materials based on ratings.
• Tutor registration.
• Tutor search by subject. Tutoring requests and their management are part of the broader product scope, but should only be presented as completed once their corresponding requirements have been implemented.

Out of scope

The following features are outside the current MVP:

• Online payments.
• Internal messaging.
• Integrated video calls.
• Artificial intelligence features.
• Integration with university information systems.
• Support for institutions other than Universidad EAFIT.

StudyBank is intended primarily for university students at Universidad EAFIT who:

• Need academic study materials.
• Want to share their own study resources.
• Need tutoring support for difficult subjects.
• Want to register as tutors and offer academic help to other students. Educational level, experience and technical expertise: users are expected to have basic familiarity with web browsers, file uploads, and standard online forms. No specialized technical knowledge or training is required.

Disabilities: accessibility support is currently limited to responsive design and semantic HTML.

• Registration is restricted to institutional email addresses ending in @eafit.edu.co.

• The system currently focuses on Universidad EAFIT students.

• The platform requires a modern browser and an internet connection.

• Local file storage is suitable for development but not for a multi-server production deployment.

• StudyBank is an academic support application and does not process safety-critical or financial information. Security considerations

• Passwords are stored using Django's password hashing system.

• Protected actions are restricted to authenticated users.

• Tutor profiles must be approved before appearing in tutor searches.

• Sensitive configuration values are managed through environment variables.

⚠️ FALTANTE: en el Sprint 1 las limitaciones no seguían los literales a) a k) de la plantilla (el docente lo señaló). La versión por literales se hizo en el Sprint 2 → va en Deliverable 2.

RF-01 — User registration The system SHALL PROVIDE visitors WITH THE ABILITY TO register an account using a unique institutional email address ending in @eafit.edu.co.

RF-02 — User login The system SHALL PROVIDE registered users WITH THE ABILITY TO log in using their institutional email and password.

RF-03 — User profile editing The system SHALL PROVIDE authenticated users WITH THE ABILITY TO edit their profile information.

RF-04 — Upload study material The system SHALL PROVIDE authenticated users WITH THE ABILITY TO upload study material and associate it with the corresponding academic information.

RF-05 — Search study materials The system SHALL PROVIDE authenticated users WITH THE ABILITY TO search for study materials by keyword.

RF-06 — Filter materials by subject The system SHALL PROVIDE authenticated users WITH THE ABILITY TO filter study materials by subject or course.

RF-07 — View study material details The system SHALL PROVIDE authenticated users WITH THE ABILITY TO view the details of a selected study material.

RF-08 — Download study materials The system SHALL PROVIDE authenticated users WITH THE ABILITY TO download available study materials.

Additional planned material requirements. The broader StudyBank product scope also includes the following requirements, which may be scheduled for later iterations depending on the sprint scope:

• Edit study material.
• Delete study material.
• Filter materials by university.
• Rate downloaded study materials.
• Display the highest-rated study materials.

RF-09 — Register as a tutor The system SHALL PROVIDE authenticated users WITH THE ABILITY TO register as tutors and select one or more subjects they are able to teach. A newly created tutor profile SHALL remain pending until it is approved by an administrator.

RF-10 — Search tutors The system SHALL PROVIDE authenticated users WITH THE ABILITY TO search for approved tutors by subject. Only tutor profiles with the approval status enabled SHALL be displayed in tutor search results.

Additional planned tutoring requirements. The broader StudyBank product scope includes the following requirements:

• Configure tutor availability.
• View a tutor profile.
• Request a tutoring session.
• Select whether a tutoring session is virtual or in person.
• Accept or reject tutoring requests.
• Notify users when a tutoring request changes status.
• Rate tutoring sessions.
• Display the highest-rated tutors. The tutoring request entity and its associated workflow are planned requirements and should not be considered implemented until their corresponding issues have been completed.

⚠️ FALTANTE:

1. Criterio de validación: ningún requisito funcional del Sprint 1 tiene criterio de validación (paso 6 de la plantilla). Sigue faltando también en la versión actual.
2. Cantidad mínima: la plantilla pide 27 requisitos funcionales para un equipo de 3. En el Sprint 1 solo 10 estaban redactados con la plantilla; el resto aparecía como lista de "planned requirements" y como historias de usuario en la priorización (sección 4.4). Los 33 requisitos con formato se completaron en el Sprint 2 → van en Deliverable 2.

Usability requirements define measurable effectiveness, efficiency, and satisfaction criteria for university students accessing StudyBank through a web browser without prior training or documentation.

UR-01 — Consistent navigation The system SHALL provide the same navigation bar and footer across all pages. A user who has visited one page SHALL be able to locate the Home, Materials, and Tutors sections from any other page without additional guidance. Verification: A first-time user can navigate from any page to each of the three main sections in a single click.

UR-02 — Registration completion time The system SHALL allow a new visitor with no prior instructions to complete the user registration process in under two minutes. Verification: Three test users unfamiliar with the system complete the registration process, measured from the moment the form loads until successful account creation.

UR-03 — Material upload completion time The system SHALL allow an authenticated user to upload a study material in under three minutes, including selecting the file and submitting the form. Verification: Three test users complete the upload flow and the average completion time is measured.

UR-04 — Clear form error feedback The system SHALL display a specific field-level error message whenever a form submission fails validation. Examples include: invalid institutional email, password mismatch, missing required fields, unsupported file type. Verification: All validation errors tested in the registration, login, and material upload forms display a message associated with the field that failed.

UR-05 — Responsive layout across devices The system SHALL render its pages without horizontal scrolling or overlapping interface elements on viewport widths between 375 pixels and 1920 pixels. Verification: Each page is manually tested using browser developer tools on at least two viewport sizes.

UR-06 — Learnability of the tutoring flow The system SHALL allow an authenticated user to locate a tutor by subject without external instructions, using only the navigation and labels provided on the screen. When the tutoring request functionality is implemented, the same principle SHALL apply to submitting a tutoring request. Verification: At least 80% of three test users complete the supported tutoring flow without assistance.

DBR-01 — Unique institutional email The system SHALL enforce uniqueness on the User.email field at the database level. No two user accounts SHALL be created with the same institutional email address. Type of information: User identity data. Integrity constraint: Unique index on User.email.

DBR-02 — University-Program hierarchy The system SHALL store each Program with a foreign key reference to one University. Each university MAY offer multiple programs. Data relationship: One-to-many relationship from University to Program. Integrity constraint: Each program must be associated with an existing university.

DBR-03 — Material classification domain The system SHALL restrict the Material.file_type field to a predefined set of values: Exam, Summary, Notes, Lab Report. Type of information: Categorical metadata. Integrity constraint: The selected value must belong to the supported file type enumeration.

DBR-04 — Material-Course-University association The system SHALL require every Material record to reference one Course and one University. This association SHALL allow materials to be searched and filtered by academic subject and institution. Data relationships: Many materials may belong to one course; many materials may belong to one university. Access capability: Foreign key fields support efficient filtering and retrieval.

DBR-05 — Tutor profile uniqueness The system SHALL allow a maximum of one TutorProfile for each User. A user SHALL NOT be able to register as a tutor more than once. Data relationship: One-to-one relationship from User to TutorProfile. Integrity constraint: Unique one-to-one constraint on TutorProfile.user.

DBR-06 — Tutor-Subject relationship The system SHALL allow each tutor profile to be associated with one or more subjects. A subject MAY be offered by multiple tutors. Data relationship: Many-to-many relationship between TutorProfile and Subject.

DBR-07 — Tutor approval status The system SHALL store an approval status for every tutor profile. Tutor profiles SHALL be created with approval disabled by default. Only approved tutor profiles SHALL appear in tutor search results. Integrity constraint: Boolean field TutorProfile.is_approved.

DBR-08 — Uploaded file retention The system SHALL retain uploaded study material files until they are explicitly removed by the uploader or by an administrator. No automatic expiration or deletion policy applies in the current scope. Development storage: Local filesystem. Production storage: Cloudflare R2-compatible object storage when configured. Data retention rule: A file remains available while its corresponding database record exists.

⚠️ FALTANTE: la plantilla pide cubrir "b) Frequency of use". Ningún DBR del Sprint 1 lo menciona.

RNF-01 — Intuitive user interface The system SHALL provide an intuitive and easy-to-use interface so that university students can use the platform without specialized training.

RNF-02 — Responsive design The system SHALL provide a responsive design that adapts to desktop and mobile devices.

RNF-03 — Fast page loading The system SHALL load the main platform pages and tutor search results within an acceptable response time under normal operating conditions.

RNF-04 — Secure password storage The system SHALL store user passwords securely using Django's password hashing mechanism. Passwords SHALL NOT be stored as plain text.

RNF-05 — Restricted access The system SHALL restrict protected functionality to authenticated users. Protected functionality includes, among others: uploading study materials, registering as a tutor, searching for tutors, and requesting tutoring sessions when that functionality is implemented.

RNF-06 — Browser compatibility The system SHALL be compatible with recent versions of Google Chrome, Microsoft Edge, and Mozilla Firefox.

⚠️ FALTANTE: el docente señaló términos subjetivos y no verificables ("intuitive and easy-to-use" en RNF-01, "acceptable response time" en RNF-03). RNF-04 usa un enunciado negativo ("SHALL NOT"), que la plantilla pide evitar. Ningún RNF tiene criterio de verificación. Esto sigue sin corregir también en la versión actual.

• https://youtu.be/baug_0viDeI The video (approximately 6 minutes) presents StudyBank's project name, the problem it solves, the team, and the proposed solution, with all three members appearing on camera. Sebastián opens and closes the video and presents the solution; Gisel introduces the problem; Samuel introduces the team.

The video also walks through the functional requirements already implemented in Sprint 1: RF-01 and RF-02 (accounts), RF-04, RF-07, and RF-08 (study materials), and RF-09 and RF-10 (tutoring).

• Project Board Issues completed in Sprint 1:

Meeting and project planning, including functional and non-functional requirements, web application design, and assignment of issues to each team member.

• Img 1
• Img 2
• Img 3
• Img 4 Weekly answers by team member: Weekly Meetings — Sprint 1.

🔄 CORRECCIÓN: Samuel (SAM-4) completed his individual Sprint 1 answers on Weekly Meetings. Sebastián and Gisel still need to complete their individual answers.

See Retrospectives — Sprint 1.

✅ CORREGIDO: Sprint 1 retrospective documented on Retrospectives.

Problem statement. University students often struggle to find reliable study materials and access tutors who can help them understand difficult topics. Study resources are frequently scattered across different platforms, personal chats, cloud folders, and informal groups, making them difficult to locate and verify. This situation can increase the time students spend searching for academic support, generate unnecessary academic stress, and negatively affect their learning experience.

Business goals

• Facilitate access to academic study materials.
• Connect students with approved tutors.
• Promote collaborative learning.
• Reduce the time required to find academic resources.
• Improve access to academic support.
• Validate the platform among Universidad EAFIT students.

M = Must have · S = Should have · C = Could have · W = Won't have (this time)

Note: this is the Sprint 1 version. The instructor pointed out that the US-XX numbering had no traceability to the RF-XX requirements, and that log out (US-21) should be Must have. Both were corrected in Sprint 2; see Deliverable 2.

This model describes the main entities of StudyBank and the relationships between them, as of Sprint 1.

erDiagram
    UNIVERSITY ||--o{ PROGRAM : "offers"
    UNIVERSITY ||--o{ USER : "attended by"
    PROGRAM ||--o{ USER : "enrolled in"
 
    UNIVERSITY ||--o{ MATERIAL : "associated with"
    COURSE ||--o{ MATERIAL : "categorizes"
    USER ||--o{ MATERIAL : "uploads"
 
    USER ||--o| TUTORPROFILE : "has"
    TUTORPROFILE }o--o{ SUBJECT : "offers"
 
    UNIVERSITY {
        int id PK
        string name
    }
 
    PROGRAM {
        int id PK
        string name
        int university_id FK
    }
 
    USER {
        int id PK
        string email
        string password
        int university_id FK
        int program_id FK
        image profile_picture
    }
 
    COURSE {
        int id PK
        string name
    }
 
    MATERIAL {
        int id PK
        string title
        text description
        int uploaded_by_id FK
        int course_id FK
        int university_id FK
        string file_type
        file file
        datetime uploaded_at
    }
 
    SUBJECT {
        int id PK
        string name
    }
 
    TUTORPROFILE {
        int id PK
        int user_id FK
        boolean is_approved
    }

Course and Subject are maintained as separate catalogs: Course is used by the study materials module and Subject by the tutoring module, so both modules can be developed independently.

A future version of the domain model may include a TutoringRequest entity connecting a student, a tutor, a subject, a proposed date and time, a session mode (virtual or in person), and a request status (pending, accepted, or rejected).

See Classwork — Pitch version 1.