COMP523_TEAM L - D1. Specifications

Specification

1. User Stories

User 1 - Mental Health Provider

As a Mental Health provider, I want to sign up after an invite from an admin or a superadmin and log in, so that I can access the provider portal and submit data.
As a Mental Health provider, I want to fill and submit surveys, so that I can provide necessary data.
As a Mental Health provider, I want to access my past surveys, so that I can keep a record of them.
As a Mental Health provider, I want to edit past surveys, so that I can correct any mistakes.
As a Mental Health provider, I want to view only my own data, so that client privacy is protected.

User 2 - Administrator

As an Administrator, I want to sign up and login as an evaluator, so that I can access data provided by Mental Health Providers.
As an Administrator, I want to access the data provided by Mental Health Providers, so that I can perform calculations and evaluations on each patient.
As an Administrator, I want to invite Mental Health providers and create provider teams, so that they can provide patient data to analyze.
As an Administrator, I want to set up review in the system, so that I can assign Mental Health providers to enter data.
As an Administrator, I want to have access to the review I set up or am a part of, so that I have a structured format to refer to when working with data.

User 3 - Super-Administrator

As a SuperAdmin, I want to invite new users with specified roles, so that they can join with the correct access.
As a SuperAdmin, I want to view and edit any survey, so that I can correct mistakes.
As a SuperAdmin, I want to create provider teams, so that I or other administrators can set up reviews for the provider teams to fill out.
As a SuperAdmin, I want to view all provider and administrator data, so that I can make sure everything is working accordingly.

2. Requirements

Functional Requirements

Definite

Application allows new user to sign up from email invitation for an account.
Application allows existing user to sign in and sign out.
Application enforce requirements for user-entered password to ensure password strength.
Application allows the user to reset their password if they forgot their password.
Implement a dashboard/portal page.
Make the website more aesthetically pleasing.

Perhaps

Implement a profile page to allow users to manage their account.
Implement functionalities to allow superadmin/admin to set up reviews for providers.
Implement functionalities for provider teams management, such as adding, editing and deleting.
Application enforces access restrictions for different pages or functionality based on the user's role.

Improbable

Implement review-specific login.
Add formulas that can format and process providers data.

Non-Functional Requirements (FURPS+)

Definite

The user interface must be easy to use and intuitive.
Documentation should be provided for troubleshooting and future developers.

Perhaps

Maintain data integrity and privacy.
Deploy the application on a server.

Improbable

None.

Platform Selection

Note: Our project was inherited from previous semesters, so the platform was already selected.

Frontend – Angular and TypeScript
Backend – MongoDB Atlas, Express, NodeJS and TypeScript
Alternatives:
- React. React has a rich ecosystem of third-party libraries and is generally easier to pick up. It allows more freedom for structuring an application. Since the project already uses Angular and it provides an out-of-the-box solution for most needs, we're sticking to Angular. The two-way data binding feature is particularly beneficial for the data-heavy nature of this project. Also, migrating to React would require a significant overhaul of the current codebase.
- Javascript. Previous teams have attempted using JavaScript for the backend but eventually decided to use TypeScript as it fixed some bugs that JavaScript introduced. We are sticking with TypeScript because its static typing provides early detection of errors, and we can maintain consistent syntax, language features, and paradigms throughout the application.
- Python. Our team has more experience using Python for the backend. However, rewriting the logical code was, again, too much work to consider switching.

Page updated

Google Sites

Report abuse

Specification

1. User Stories

User 1 - Mental Health Provider

As a Mental Health provider, I want to sign up after an invite from an admin or a superadmin and log in, so that I can access the provider portal and submit data.

As a Mental Health provider, I want to fill and submit surveys, so that I can provide necessary data.

As a Mental Health provider, I want to access my past surveys, so that I can keep a record of them.

As a Mental Health provider, I want to edit past surveys, so that I can correct any mistakes.

As a Mental Health provider, I want to view only my own data, so that client privacy is protected.

User 2 - Administrator

As an Administrator, I want to sign up and login as an evaluator, so that I can access data provided by Mental Health Providers.

As an Administrator, I want to access the data provided by Mental Health Providers, so that I can perform calculations and evaluations on each patient.

As an Administrator, I want to invite Mental Health providers and create provider teams, so that they can provide patient data to analyze.

As an Administrator, I want to set up review in the system, so that I can assign Mental Health providers to enter data.

As an Administrator, I want to have access to the review I set up or am a part of, so that I have a structured format to refer to when working with data.

User 3 - Super-Administrator

As a SuperAdmin, I want to invite new users with specified roles, so that they can join with the correct access.

As a SuperAdmin, I want to view and edit any survey, so that I can correct mistakes.

As a SuperAdmin, I want to create provider teams, so that I or other administrators can set up reviews for the provider teams to fill out.

As a SuperAdmin, I want to view all provider and administrator data, so that I can make sure everything is working accordingly.

2. Requirements

Functional Requirements

Definite

Perhaps

Improbable

Non-Functional Requirements (FURPS+)

Definite

Perhaps

Improbable

Platform Selection