-
Notifications
You must be signed in to change notification settings - Fork 0
Software requirements specification
The document is a public SRS for the Lohfinder app. Everybody can access and read the document. The development team is the target audience for the document.
The development team used the document to create, design, develop and test the Lohfinder application.
Business goals for the app are:
- complete a class on "Modern software development technologies."
- Develop PoC of a service to connect people who want to be volunteers with organizations that look for volunteers.
The service users can be split into two groups: possible volunteers and organizers.
Volunteers need to access a list of events of interest. Also, they want to get event details. Volunteers need to apply to the event and check whether the application is approved.
Organizers want to
- create events
- manage application forms for the event
- get a list of accepted volunteers.
The team develops a web application that consists of a client web app built with Flutter/Dart technology and a back-end service made with Python programming language. FastAPI will be used as a back-end framework. Also, we use a bunch of external service dependencies:
- Firebase for different client needs.
- A primary PaaS cloud service provider to host our applications (GCP/Azure/AWS).
- Github as a git server and documents storage.
- Atlassian Jira as a kanban board.
Users should be able to register in the application. Volunteers should have options to register with basic credentials and OAuth 2.0 clients.
- It should safely store user-related data (please mark that this refers to storing sensitive user data).
- It should provide a robust encryption mechanism so any hacker attacks can not steal users' data.
- User service should communicate with the Firebase that preliminary has been chosen to use for user registration and authorization.
- User sign-in/sign-up/log out
- Displaying and managing user profile
This component is responsible for storing and accessing events data.
- Navigating the user through all events, giving him the ability to filter them, sort, find whatever keyword he needs.
- Work with the single event: creating it, modifying, etc.
- Applying for an event as a volunteer.
For personal users:
- List all events future events
- List all events future events near the user's location
- List all events of organizer
- List past events of the user
- Getting event info
- List all events in a certain category
For organizer:
- Creating an event
- Modifying his event
- Deleting his event
- Getting his event info
For admin:
- Deleting event
- Modifying event
- Deleting all events of a certain category
- Creating category
- Merging categories.
Event organizers might want possible volunteers to answer some questions before considering them a volunteer. This component is responsible for managing these forms.
- Event organizers should have CRUD access to the forms.
- Volunteers should be able to fill the form.
- User applies to event and proceeds to application form screen. They complete the form and complete the form. Then, the service receives a topic to create a record in DB.
- An event organizer goes through a list of possible volunteers. Then, he decides to open a volunteers form to check their responses.
- A volunteer deletes their account. Then, all their responses are deleted from the service.
- An organizer deletes an event. All responses are deleted.
- An organizer creates an event. After filling in info about an event, the user proceeds to the application form and creates a custom form for volunteers to apply.
- An organizer edits a form and saves a new form. The microservice saves the new form, and when a new volunteer applies to an event, they will work with the updated form.