...
# | Title | User Story | Importance | Notes |
---|---|---|---|---|
1 | Mandatory collection of members' data. | When a user creates an account, the system should require the following information for communication and statistics purposes:
If a user fails to fill in name, email, exact date of birth, their account can exist but needs to be suspended. If a user fails to fill in the AEGEE local, year of birth, nationality, field of studies, gender, the account cannot be created. If the user attempts to empty these fields, the change shall not be saved. | Must have |
|
2 | Optional collection of members' data | The user can decide to provide additional information, such as home address or social network/messenger identifiers. The Comité Directeur may specify further which optional data fields are desired. | Must have |
|
3 | Processing deletions | When a data subject wants to delete their account, or withdraws their permission to store its personal data, they are suspended. AEGEE local, year of birth, nationality, field of studies, and gender are not deleted from their anonamised profile. | Must have | |
4 | Filtered permissions for personal data visibility | AEGEE officials (CD,commissioners) do not need insights into nationality, field of studies or gender. AEGEE officials need only see contact information and information that the data subject gave permission for publishing this information internally. Local boards need only insights into contact | Good to have |
|
5 | User consent (membership) | User needs to see different check-boxes when creating or updating their account. Users should be able to give consent for:
| Partly must have
|
|
6 | Finishing accounts on first logon | If it is possible for a user to be generated without their own doing (e.g. by a board member or through some API), the user should be asked for consent and missing information on their first log-on. | Must have? | |
7 | User consent (events) | User needs to see different check-boxes when creating or updating their account. Users should be able to give consent for:
| Partly must have
|
|
8 | Internal visibility of AEGEE members to AEGEE members | All AEGEE members (Members of AEGEE Antennae and Contact Antennae) can be allowed to see other members' information, of users that have given their consent to be internally visible. What is visible for others should depend on the consent given under 5.3. | Good to have |
|
9 | Export all data belonging to one data subject | A data subject (AEGEE member) has the right to request all its personal data that is stored. It would be nice to have a feature to extract that information by the member themselves, as well as a possibility to extract such information by an official (e.g. CD/DPC) | Nice to have |
|
10 | Contracts of confidentiality. | A regular administrator wants to give additional rights to another person. In order to activate those rights, they have to upload a signed contract of confidentiality before they are granted access to the databases. Alternatively, the person has to sign an equivalent of such a contract in the system before the rights are activated. It should be possible for CD and other privileged organs to later review the agreement and its meta-data. | Nice to have |
|
11 | Automatic account reminders | Our members have a responsibility to keep their data up to date and make the needed changes when necessary. It would be pretty cool if we could send out an automated message to all active accounts to ask them to review their membership data. This could e.g. be a yearly reminder in September | Bonus |
|
12 | Privacy policy | Any platform-specific privacy policy needs to be readable to the user. There also should be a human readable version of the DPPS and applicable privacy policy, and a link to the entire DPPS. | Must-have | User can already read simple legal info. Simple legal info needs to be adjusted to DPPS and complex info needs to be added. |
User interaction and design
Questions
Below is a list of questions to be addressed as a result of this requirements document:
...