inclui.2.mp4
Welcome to the documentation pages of Inclui!
This Software Development Report, tailored for LEIC-ES-2024-25, provides comprehensive details about Inclui, from high-level vision to low-level implementation decisions. It’s organised by the following activities.
Contributions are expected to be made exclusively by the initial team, but we may open them to the community, after the course, in all areas and topics: requirements, technologies, development, experimentation, testing, etc.
Please contact us!
Thank you!
- Diana Magro (up202305465@up.pt),
- Joana Carvalhal (up202306568@up.pt),
- Martim Cadilhe (up202307833@up.pt),
- Pedro Araújo (up202306606@up.pt),
- Simão Barbosa (up202306609@up.pt)
Business modeling in software development involves defining the product's vision, understanding market needs, aligning features with user expectations, and setting the groundwork for strategic planning and execution.
For individuals seeking inclusive and accessible places, who need to find establishments that embrace diversity, Inclui is a mobile application that allows users to rate establishments based on accessibility features, such as wheelchair ramps, Braille menus, and other inclusivity aspects, helping people find places that meet their needs. Unlike general review apps that allow you to rate places based on your personal preferences, our product focuses specifically on accessibility, ensuring users can easily identify welcoming and accommodating establishments.
- Accessibility-Focused Search - Allow users to search for places based on specific accessibility features
- Place Reporting System - Enable validated users to report accessibility issues at establishments
- Interactive Map View - Visualize nearby places with their accessibility issues
- User Authentication - Secure account creation, login, and profile verification system
- Detailed Place Profiles - View comprehensive information about establishments' accessibility features
- Personalized Accessibility Filters - Filter map icons based on individual accessibility needs
- User Review Management - Enable users to track and delete their submitted reports
- Multiple Accessibility Categories - Support for various accessibility features including wheelchair access, Braille menus, elevators, and pregnancy accommodations
Imagine arriving at a restaurant only to discover you can't enter because there's no wheelchair ramp, or needing a Braille menu that isn't available. For millions with mobility or sensory challenges, this uncertainty is a daily reality. Inclui is a community-powered mobile app that transforms how people discover accessible spaces. Users can find and report places with specific accommodations like wheelchair access, Braille menus, or elevators—turning unpredictable outings into reliable experiences. While traditional solutions involve asking friends or taking chances, Inclui provides verified, crowd-sourced accessibility information exactly when needed. By connecting those with accessibility needs to welcoming establishments, we're not just helping people find accessible places—we're building a more inclusive world where everyone belongs.
- As a user, I want to search for places that accommodate specific accessibility requirements, so that I can get a list view of suitable locations.
- As a validated user, I want to report an accessibility issue at a location, so that others are informed.
- As a user, I want to search for a specific place, so that I can view it's accessibility issues.
- As a registered user, I want to access my profile page, so that I can view and update my preferences.
- As an unregistered user, I want to create an account and log in, so that I can filter results based on my accessibility needs.
- As a user, I want to view accessibility issues in nearby places in a map view, so that I can identify unsuitable locations.
- As an unvalidated user, I want to verify my profile, so that I can report accessibility issues.
- As a verified user, I want to access my review history so that I can view past reviews and delete outdated ones.
- User: Represents an individual who can report accessibility issues for various places. A user can only report each place once, and they must be validated before submitting any reports.
- Place: A physical location (e.g., restaurant, store) that can have multiple reports associated with it. Each place can have various accessibility issues reported by different users.
- AccessibilityIssue: A predefined category of accessibility problem, such as missing wheelchair ramps or lack of Braille menus. Multiple places can share the same accessibility issue type, but each report can contain multiple instances of these issues.
- Report: A user-submitted record documenting the accessibility issues found at a particular place. A report can include multiple accessibility issues and is tied to both a specific user and a specific place.
The Package Model below provides a high-level overview of the system's logical structure, illustrating the key packages and their interactions.
- Application: The core of the system, containing three main packages: User Interface, Business Logic, and Data Management.
- User Interface: Contains the application's primary screens, such as the HomePage, SearchPage, ReportPage, and LoginPage. It also includes MapView, which is part of the HomePage and is used to visually display places and accessibility issues. The User Interface interacts with Business Logic to process user actions and with Authentication & Authorization to manage authentication.
- Business Logic: Handles the core functionalities of the system, such as Search, Report, AccessibilityIssue, and Place management. It processes user inputs, retrieves relevant data, ensures the correct execution of business rules, and communicates with external services such as Google Maps when additional data is required.
- Data Management: Responsible for data storage and retrieval. It contains DatabaseHandler, which manages database operations. The Business Logic layer depends on this package for data persistence and retrieval.
- External Programs: A collection of external services that the application relies on. It contains two sub-packages: Google Maps e Firebase.
- Firebase: Provides authentication, authorization, and database management functionalities. It contains Authentication & Authorization, which manages user authentication, profile validation, and interaction with Data Management to validate user credentials. It also includes Database, responsible for storing application data.
- Google Maps: Provides mapping and location-based services. It contains GoogleMapsAPI, which allows the application to fetch location-based information and display places on the MapView. The Business Logic layer communicates with this API when necessary.
This deployment diagram illustrates the architecture of a Flutter and Dart based mobile application, distributed as the Inclui.apk file, deployed on an Android smartphone. It communicates with an authentication service to validate user credentials to ensure secure access to the application's features. Additionally, it features the Google Maps Host to provide real-time location data features, enhancing navigation and accessibility. The architecture is designed to be robust, scalable, and user-friendly.
To validate our technological choices, we developed a vertical prototype integrating Firebase and location services.
For data management, we set up a Firebase Realtime Database, allowing the app to store, display, and clear entries dynamically. Authentication was implemented using Firebase Auth, enabling user sign-in, account creation, and session management with error handling. Additionally, location services were integrated using the Geolocator package, ensuring proper permission handling and displaying the user’s coordinates within the app.
The following video demonstrates these features in action.
verticalPrototype.mp4
Start of Sprint 1:
End of Sprint 1:
Retrospective: In Sprint 1, we were overly ambitious and selected too many user stories, underestimating how busy school would be. Despite that, we managed to complete everything thanks to a strong team effort. Moving forward, we’ll be more mindful of our schedules when planning and choose user stories more carefully.
Start of Sprint 2:
End of Sprint 2:
Retrospective: In Sprint 2, we chose our user stories more carefully, which helped us complete everything we planned without unnecessary stress. We'll keep this thoughtful approach in future sprints.
Start of Sprint 3:
End of Sprint 3:
Retrospective: In Sprint 3, the development was smooth and stress-free.