Repository navigation
Deliverable 1
Sebastian Cañon Cuartas edited this page Oct 6, 2026
·
3 revisions
Local Sports is a lightweight web application designed to help people organize and participate in recreational sports matches more efficiently. The platform allows users to create matches, join existing ones, coordinate schedules, confirm attendance, and manage participants from a single place, replacing the inefficient use of WhatsApp groups and social media.
The application is developed using Python, Django, and Bootstrap, following an agile development process based on Scrum. Future versions will include a statistics-based matchmaking system capable of recommending compatible matches according to player preferences and historical participation.
| Item | Description |
|---|---|
| Deployment context | Runs in any Python 3.12 environment using Django. It can be deployed locally or inside a Docker container. |
| System interfaces | Responsive web application accessible through modern web browsers. |
| User interfaces | HTML, CSS, JavaScript, and Bootstrap responsive interface. |
| Hardware interfaces | Desktop computers, laptops, tablets, and smartphones with Internet access. |
| Software interfaces | Django framework, PostgreSQL (production), SQLite (development), Git, and GitHub. |
| Communication interfaces | HTTP/HTTPS protocol. |
| Operations | Users interact with the platform through a web browser to create, manage, and participate in sports matches. |
| Site adaptation requirements | Compatible with modern browsers such as Chrome, Firefox, Edge, and Safari. |
- User registration and authentication.
- Create recreational sports matches.
- Configure match details (sport, date, time, location, number of players, and skill level).
- Browse available matches.
- Filter matches by date, location, and skill level.
- Join and leave matches.
- Accept or reject join requests.
- Confirm attendance before a match.
- View the list of participants.
- Cancel matches.
- Manage waiting lists for full matches.
- Receive automatic replacement suggestions.
- View player profiles.
- Receive notifications about match updates.
- View match history.
- Future statistics-based matchmaking recommendations.
The primary users of Local Sports are people who regularly participate in recreational sports and need an easy and organized way to coordinate matches.
Typical users include:
- University students.
- Amateur athletes.
- Groups of friends.
- Community sports players.
- Match organizers (captains).
Users are expected to have basic knowledge of web browsing and mobile or desktop applications. No technical expertise is required.
| Item | Description |
|---|---|
| Security | Only the information required for user authentication and match organization is stored. Passwords are encrypted. |
| Connectivity | An Internet connection is required to access the application and synchronize match information. |
| Scope | The MVP focuses on organizing recreational sports matches. Statistics-based matchmaking, advanced analytics, and third-party integrations are planned for future iterations. |
| Performance | Designed to support approximately 100 concurrent users during the MVP stage with fast response times under normal usage conditions. |
| Sports supported | The first release focuses on football (soccer). Additional sports will be incorporated in future versions. |
| External integrations | No payment systems or sports facility reservation services are included in the MVP. |
| ID | Priority | Sprint | Requirement |
|---|---|---|---|
| FR1 | Must | Sprint 1 | WHEN a registered player submits the match creation form, THE Local Sports System SHALL create a new football match. |
| FR2 | Must | Sprint 1 | WHEN the match organizer creates or edits a football match, THE Local Sports System SHALL store the match details, including date, time, location, skill level, maximum number of players, and match visibility. |
| FR3 | Must | Sprint 1 | WHEN a player accesses the available matches section, THE Local Sports System SHALL display all football matches with available slots. |
| FR4 | Must | Sprint 1 | WHEN a player requests to join a football match that requires organizer approval, THE Local Sports System SHALL send the join request to the match organizer. |
| FR5 | Must | Sprint 1 | WHEN a player requests to join a public football match with available slots, THE Local Sports System SHALL add the player to the participant list. |
| FR6 | Must | Sprint 1 | IF a participant leaves a football match before it starts THEN THE Local Sports System SHALL remove the player from the participant list and update the available slots. |
| FR7 | Must | Sprint 2 | WHEN a participant receives an attendance confirmation request, THE Local Sports System SHALL record the player's attendance confirmation before the match starts. |
| FR8 | Must | Sprint 2 | WHEN a player opens the details of a football match, THE Local Sports System SHALL display the list of registered participants. |
| FR9 | Must | Sprint 2 | WHEN the match organizer cancels a football match, THE Local Sports System SHALL cancel the match. |
| FR9.1 | Must | Sprint 2 | WHEN the match organizer cancels a football match, THE Local Sports System SHALL send a push notification to all registered participants. |
| FR10 | Must | Sprint 2 | WHEN a player attempts to join a football match that has reached its maximum number of participants, THE Local Sports System SHALL add the player to the waiting list. |
| FR11 | Must | Sprint 2 | WHEN a participant leaves a football match with a waiting list, THE Local Sports System SHALL assign the available slot to the first player on the waiting list. |
| FR12 | Must | Sprint 2 | WHEN a player searches for football matches, THE Local Sports System SHALL filter the available matches by date, location, and skill level. |
| FR13 | Should | Sprint 3 | WHEN a player accesses the match history section, THE Local Sports System SHOULD display the player's completed football matches. |
| FR14 | Should | Sprint 3 | WHEN a football match is updated, THE Local Sports System SHOULD send a Email notification to all affected participants. |
| FR14.1 | Should | Sprint 3 | WHEN a football match is canceled, THE Local Sports System SHOULD send a Email notification to all affected participants. |
| FR15 | Should | Sprint 3 | WHEN the match organizer selects players to invite, THE Local Sports System SHOULD send an invitation to the selected players. |
| FR16 | Should | Sprint 3 | WHEN the match organizer requests a shareable invitation, THE Local Sports System SHOULD generate a shareable invitation link for the football match. |
| FR17 | Should | Sprint 3 | WHEN a player marks another player as a favorite, THE Local Sports System SHOULD save the selected player in the favorites list. |
| FR18 | Should | Sprint 3 | WHEN a player reports another player, THE Local Sports System SHOULD record the report and the selected reason. |
| FR19 | Should | Sprint 4 | WHEN a player searches for football matches, THE Local Sports System SHOULD recommend matches based on the player's statistics and playing history. |
| FR20 | Should | Sprint 4 | WHEN a football match is completed, THE Local Sports System SHOULD update each participant's performance statistics. |
| FR21 | Should | Sprint 4 | WHEN a football match is completed, THE Local Sports System SHOULD allow participants to rate other players. |
| FR22 | Should | Sprint 4 | WHEN a participant submits a comment after a football match, THE Local Sports System SHOULD publish the comment on the match page. |
| FR23 | Should | Sprint 4 | WHEN a player views another player's profile, THE Local Sports System SHOULD display the player's statistics and ratings. |
| FR24 | Should | Sprint 4 | WHEN the match organizer requests automatic team generation, THE Local Sports System SHOULD generate balanced teams according to the players' ratings. |
| FR25 | Could | Backlog (Post-MVP) | WHEN a participant selects the Add to Calendar option, THE Local Sports System COULD export the football match information to the player's calendar. |
| FR26 | Could | Backlog (Post-MVP) | WHEN the match organizer selects a football field while creating a match, THE Local Sports System COULD display the field's availability. |
| FR27 | Could | Backlog (Post-MVP) | WHEN participants open the football match chat, THE Local Sports System COULD provide a real-time chat. |
| FR27.1 | Could | Backlog (Post-MVP) | WHEN participants open the football match chat, THE Local Sports System COULD display live match statistics. |
| FR28 | Won't | Out of Scope | THE Local Sports System WON'T provide an in-app payment system for field reservations. |
| FR29 | Won't | Out of Scope | THE Local Sports System WON'T provide integration with smartwatches. |
| FR30 | Won't | Out of Scope | THE Local Sports System WON'T provide AI-generated match highlights or video analysis. |
| ID | Requirement |
|---|---|
| UR1 | IF a new user accesses the Local Sports System for the first time THEN THE Local Sports System SHALL allow the user to complete the registration process in no more than 5 minutes. |
| UR2 | IF a registered player searches for football matches THEN THE Local Sports System SHALL display the search results within 4 seconds under normal operating conditions. |
| UR3 | AS SOON AS a critical user action is completed (such as match creation, joining, or cancellation) THEN THE Local Sports System SHALL display a visual confirmation feedback message. |
| UR4 | IF a user submits a form with invalid or incomplete information THEN THE Local Sports System SHALL display clear validation messages indicating the fields that require correction. |
| UR5 | IF a player performs a primary task, such as creating a match or joining a match THEN THE Local Sports System SHALL allow the task to be completed using no more than five user interactions after accessing the corresponding page. |
| UR6 | IF a user navigates through the Local Sports System THEN THE Local Sports System SHALL provide a consistent layout, navigation menu, and visual components across all pages. |
| ID | Requirement |
|---|---|
| LDR1 | A User stores id, first_name , last_name, email (unique), password, skill_level profile_picture (optional), and created_at. |
| LDR2 | A Match stores id, organizer_id (FK -> User), title , date_time (DateTimeField), location, skill_level (choices: 'Beginner', 'Intermediate', 'Advanced'), max_players, and visibility (choices: 'Public', 'Approval_Required'). |
| LDR3 | A MatchParticipant stores id, match_id (FK -> Match), player_id (FK -> User), status (choices: 'Pending', 'Accepted', 'Rejected', 'Waiting_List'), attendance_confirmed (boolean, default=False). |
| LDR4 | A JoinRequest stores id, player_id (FK -> Player), match_id (FK -> Match), request_date, and request_status (pending, accepted, or rejected). |
| LDR5 | Completed and canceled football matches, participation records, attendance confirmations, and join requests shall be retained in the database for historical consultation and reporting purposes. |
| LDR6 | The combination of (player_id, match_id) in MatchParticipant shall be unique. A player shall not appear more than once in the same football match. |
- Hold weekly Scrum meetings.
- Keep the Product Backlog updated.
- Use GitHub Issues to track progress.
- Review requirements before implementation.
- Standardizing Django project folder structures and code conventions early before coding begins.
- Keep the Product Backlog updated.
- Use GitHub Issues to track progress.
- Review requirements before implementation.
- Working on large features without first discussing the design.
- Delaying Git commits until the end of the week.