SRS v4
BeakPeek aims to grow the bird watching community in South Africa by making it easier to find, identify and predict the occurrence of bird species. BeakPeek allows users to see which bird species can be found in their area and provide conservationists with an estimate of the current population of bird species informing them when a population drops below 25 000 individuals.
The primary user of the application, birders can use the application to view all kinds of birds in South Africa and where to find them using SABAP2’s public database. Birders can view what birds can be seen in the pentad they are currently in. They can view the list of birds that they have seen and add their sighting to the database if they want to. Birders can identify birds by taking a photo of it. Birders can identify birds through specialised filters. They can also listen to what a bird sounds like.
Conservationists can use the data uploaded by users and by SABAP2 to receive an indication of what a specific bird population is doing, more sightings than expected could indicate an increase in the birds’ population and vise versa.
Manually confirms Conservationists authenticity and will interact with the administrative systems.
- Only a mobile application will be developed.
- Only South African Bird data through SABAP2 will be available.
- The application will only be available in English.
- Application requires internet connection at least once to download bird information for offline use.
- Application will only be published on the Google App Store.
An Asterix(*) indicates an optional requirement.
1.1. Register an account using either their email or Google account.
1.2. Login into their account using social sign-in (Google account) or their normal details.
1.3. Manage their profile.
1.4. Manage their life-list. (all the birds they’ve seen)
2.1. Display an Interactive South African map.
2.2. Show user’s current location.
2.3. View bird species by pentad.
2.4. View the percentage chance that the user has of seeing a specific bird in a specific pentad.
2.5. View likely bird species near the user.
2.6. View a heatmap of the birds’ locations.
3.1. Search for a specific birds’ location data.
3.2. View Pentad information of bird sightings.
3.3. View birds near you.
4.1. Play a bird quiz minigame*.
4.2. View all text-based information regarding a birds’ location.
4.3. See what a bird looks like*.
4.4. Hear what a bird sounds like*.
5.1. Earn experience points based on the rarity of the bird sighted to increase their level.
5.2. Earn special badges based on challenges.#
5.3. Participate in daily, weekly, and monthly challenges.
6.1. View endangered birds population sizes.
6.2. Filter birds by area.
6.3. Compare populations to previous years.
7.1. Rank birds by rarity*.
7.2. Ingress of data from SABAP2.
7.3. Process data from SABAP2.
8.1. Authorise new admins.#
8.2. Manage database systems.#
- User Profile Creation and Management
- Interactive Map
- Identify Birds
- Enrich User Knowledge
- Allow Users to Compete
- Specialised Data View for Conservationists
- Manage and Process Data from Database
- Administrative System and Users
1.1. The system should be easy to use.
• An extensive usability test has been performed before launch aiming to ensure all best practices are met through user feedback. This test includes users form a diverse range of ages and technical expertise.
1.2. The system should be easy to navigate.
• Consistent navigation patterns are used.
• Well known material metaphors are used for icons.
1.3. The system should be easy to understand.
• Help buttons are used to provide contextual help.
• Clear descriptive labels for UI elements are used.
1.4. The system should be easy to learn.
• A brief tutorial is given to first time users, guiding them through the application.
2.1. The system should be able to handle concurrent users.
• Managed by Microsoft Azure, implements load balancing.
2.2. The system should be able to handle concurrent authentication.
• Uses asynchronous message queues to handle concurrent authentication.
2.3. The system should be able to handle low network speeds.
• Offline functionality, such as downloaded maps. Data is also compressed when sent.
2.4. There should be no more than a two second response time.
• Implements caching on client- and server-side.
• Database queries are optimised from raw data, not SABAP2.
3.1. The system should be available 20/7 (Four-hour maintenance window is acceptable between 22:00 and 02:00).
• Azure has redundant servers to ensure availability.
• Major App maintenance will be done only during the allowed window.
• Almost all futures will continue to work even if the servers are down.
3.2. Should be able to recover from crashes and failures.
• Automate Restore Processes.
• Separation of functionality ensuring one system failing does not affect the whole application.
• Robust error handling and crash reports from users are sent to administrators.
3.3. The system must survive upgrades and device migration.
• Rollback implementation to previous versions.
• Development for Android devices.
• User data is stored online with Azure.
3.4. The system should be scalable past 10 000 active users per month*.
• Azure credits will be used to cater for the use of multiple servers.
• If Azure servers are shut down the app will still function but will not receive regular data updates.
• Azure load testing has been performed to ensure the server can sustain up to 50 active users per minute.
3.5. The system must function with low bandwidth.
• Most sub-systems can be used fully offline if the user has downloaded the appropriate data.
4.1. The system should be easy to debug.
• GitHub is used for version control.
• Testing ensures bugs can be found efficiently.
• Separation of concerns allows errors to be found quickly.
4.2. Be able to be updated without affecting the user experience.
• CI/CD pipelines for automated deployment.
• For large updates users will have to update their application before being able to continue using it.
4.3. Retrieve updated SABAP2 data without affecting users.
• New SABAP2 data automatically loaded the next time a user connects to the internet.
• SABAP2 data ingress is updated automatically on a monthly basis.
4.4. The system should be easy to maintain.
• The system is well abstracted with a modular architecture.
• Tests are automated.
Our security standards are achieved through the use of Microsoft Azure, Microsoft Identity and Google’s Mobile Application Security Assessment. Data integrity is ensured through the use of checksums. Audits logs are created to track administrator’s activity.
5.1. Be able to protect user data from unauthorised access.
5.2. Be able to protect user data from unauthorised modification.
5.3. Be able to protect user data from unauthorised deletion.
5.4. Be able to protect user data from unauthorised disclosure.
6.1. The system should not drain more than 5% battery per hour.
• Idle processing is optimised.
• Most processing is outsourced to the server.
(For Future Versions of the Class Diagram we plan to take a more Domain Driven approach.)
-
Management for systems personal to each user.
a. Achievements and Experience
b. Profile and User Settings
c. Life List -
Integrated Map.
a. Map
b. View Area Birds.
c. Heat Map. -
User Login / Sign-up.
a. User Sign Up
b. User Login
c. Guest Login -
Search for a specific bird. (Birder)
For our architectural design we chose to combine a Model View Controller (MVC) with an Event Driven Architecture (EDA) and a Domain Driven Design (DDD). Our decision was based on the following reasoning:
MVC – We considered MVVM and MVC for our offline model yet decided on MVC as we prioritise useability above testing ease, and we believe MVVM would have been overkill for our simple UI. Databinding is easier in a MVVM model, however, MVC has more existing features in the ASP.NET framework, these features have made our back-end development process far more efficient and reliable. The model component also provides an easy access point for our event queue to be created that links the MVC model with our Event Driven Architecture.
EDA – This was an easy choice as EDA lends itself perfectly to our quality requirements, it not only allows us to easily incorporate parallel processing by splitting up the event queue received from the offline model to the proper destination domain where our DDD can then efficiently process the request, but it works as a perfect separation between the online and offline models. Should an action need to be performed offline it is redirected to the MVC, but if the user has an internet connection the request is instead sent to server hosted by Azure where the actions can be completed by more powerful hardware. Events that always require an internet connection can remain in the queue until the user connects to the internet again at which point they are automatically executed. This greatly boosts the applications performance and allows for real time response from the system.
Furthermore, the heterogeneous pathways improve our fault tolerance as should a system in our online model go down it can be attempted to be performed offline and the applications other systems will still be reachable, and it avoids continuous polling.
The use of EDA does lead to event duplication in our DDD but we believe the pro’s greatly outweigh this.
DDD – By using a DDD we mainly aim to satisfy our maintainability and reliability quality requirements. With clear domain borders separating back-end components testing and integration of new components becomes easier. Should one domain’s system fatally error our other domains would be able to keep functioning thus increasing the reliability of the application.
Our industry mentor is also considering turning the application into a white-collar application. By using a DDD it allows for a more flexible application where certain domains can be easily swapped out by simply connecting to the correct event stream from the EDA with the new system. This flexibility greatly increases the applications maintainability and lends itself to more organised code.
The client shall provide access to the Azure framework required for the software that Millennium will develop. Millennium will produce a working, user-friendly application that can show the pentad location of where South African birds can be located and what the percentage chance is of location each bird listed in that pentad. This data will be sourced from SABAP2 and its accuracy and functionality relies on the continued maintenance of SABAP2.
The mobile application will be developed using Microsoft Azure for user management and the storage of bird data. The Dot Net framework will be used to communicate with the bird information database on Azure. Flutter will be used for all front-end development and communicated directly to Azure for user authentication and authorisation.
For the duration of the project an agile methodology will be adopted. A weekly meeting will be held with the industry mentor and university mentor to provide progress reports and sprint reviews; this aims to ensure efficient development of the mobile application that will not only meet but surpass the clients’ requirements. Team members will meet every weekday briefly to discuss progress and any problems that may have been encountered and to implement changes to the sprint plan should any be necessary.
Azure implements form validation as developed by Microsoft. Users will not be able to access SABAP2 data directly: through the MVC model users will always be separated from the main database systems by the controller. User bird sightings are separated into their own database that will be indicated as untrustworthy and users will have the option to include it in the data they view.
The mobile application will comply with South African regulations, specifically provision will be made to comply to laws such as the POPI Act; ensuring that user data is secured. A user agreement policy allowing BeakPeek to store their data will be made and user data will not be made publicly available unless specifically stated that it will be (for example usernames).
We chose Flutter for its robust cross-platform capabilities and extensive library of packages and integration tools. Unlike competitors such as React Native and Angular Ionic, which are built on top of web development frameworks, Flutter is purpose-built for cross-platform development. This results in superior performance, as reflected in benchmarks favouring Flutter.
Microsoft Azure was selected due to its comprehensive range of services and integrations, particularly its seamless integration with the .NET framework. This synergy is facilitated by both being developed and maintained by Microsoft. Azure offers advantages over AWS in areas such as .NET framework integration and services like Azure Active Directory B2C (Microsoft Entra Identity), which is invaluable for user management.
We opted for .NET ASP.NET Core because it facilitates rapid development of Web APIs and provides excellent integration with databases via the .NET Entity Framework. This ensures consistency in data types between the frontend and database, streamlining our data pipeline. It was chosen over alternatives like FastAPI due to its strong typing and better compatibility with our technology stack.
Microsoft SQL Server was selected for its seamless integration with .NET and Microsoft Azure. Its stable environment is well-suited for handling large datasets, and its lack of extraneous features aligns well with our use of .NET and other tools, avoiding the complications introduced by additional features found in databases like PostgreSQL.
We chose GitHub Actions for its extensible YAML-based workflow configurations, which simplify the creation and management of workflows for various tools and automations. Its built-in nature within GitHub and extensive support for numerous tools, including Microsoft Azure, make it a superior choice over other test automation tools.