...
# | Title | User Story | Importance | Notes | ||
---|---|---|---|---|---|---|
1 | Members | The system should contain a set of members | Must have | |||
2 | Bodies | The system should contain a set of bodies | Must have | |||
3 | Join body | A member can join a body | Must have |
| ||
4 | Body board | A body has a board, a member can become a board of a body | Must have |
| ||
5 | View members | A user can see details of a member | Must have |
| ||
6 | Edit body | A board of a body should be able to edit the details of a body | Must have | |||
7 | Create body | The Comité Directeur should be able to create a body | Must have | |||
8 | Register member | A guest should be able to register as a member | Must have |
| ||
9 | Accept member | A ??? should be able to accept new membership applications | Medium |
| ||
10 | View body | A user should be able to view information of a body | Must have |
| ||
11 | Restrict Access | A user should be restricted access to actions depending on their roles | Must have |
| ||
12 | Export information | A user should be able to export information of the system | Low |
| ||
13 | Account management | A user should be able to manage his account, ie change/reset/request login credentials | Must have |
| ||
14 | Data migration | The system should be able to make use of the old data from the previous system | Low |
| ||
15 | Scale-ability | The system should be able to scale up to 15.000+ members | Must have |
| ||
16 | Live deployment | Once running, the system should be able to upgrade with relative ease and minimum downtime | Low |
| ||
17 | Security | The system should handle sensitive information with care and anticipate upon users with malicious intents | Medium |
| ||
18 | Maintainability | A developer should be able to maintain the system with relative ease, meaning documentation of design and processes should be included | Must have | |||
19 | Availability | The system's uptime should be as high as possible | Medium |
| ||
20 | Dependence | TODO | ? | Medium |
| |
21 | Privacy | The system should respect the privacy rules as specified in the CIA, the countries law and the European law | Medium |
| ||
22 | Guests | A non-AEGEE member should be able to access (parts of) the system | Must haveWhat should such a guest see? | |||
23 | Accessability | The system should be accessable for all the members of AEGEE | Low |
| ||
24 | Search | The system should allow searching for entities on certain fields | Must have |
| ||
25 | Filter | The system should be able to filter a set of entities based on certain fields | High |
| ||
26 | Identify standardization | The system should have (microservice) standardization requirements in place where necessary (cross-cutting concerns) | Must have | |||
27 | Standardize roles | Each microservice in the system should abide the standardized microservice requirements | Medium |
|
Questions
Below is a list of questions to be addressed as a result of this requirements document:
Question | Outcome |
---|---|
How is a cross-cutting concern such as the access restriction, which is present in nearly every requirement, done? | A general access restriction requirements list can be found here. TODO
|
Are all the members of AEGEE-Europe in the system, or only members that registered themselves |
|
Not Doing
...
Future releases
- Events and financial management
- Integration with other services (Office 365, Statutory events, online voting, SU website etc.)
- Document upload and sharing