|
| 3 | Join body | A member can join a body | Must have | - A member should be able to join multiple bodies
|
| 4 | Body board | A body has a board, a member can become a board of a body | Must have | - Board meaning 'admin' of that body, having special rights
|
| 5 | View members | A user can see details of a member | Must have | - Roles should be taken into account
|
| 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 | - Any guest should be able to get an account, even when not a member of AEGEE yet.
- Using this account the AEGEE membership can be requested
|
| 9 | Accept member | A ??? should be able to accept new membership applications | Medium | - System membership, not body membership
|
| 10 | View body | A user should be able to view information of a body | Must have | - Body information, as well as members within the body
- Roles should be taken into account
|
| 11 | Restrict Access | A user should be restricted access to actions depending on their roles | Must have | - For example, a board member should only have special rights over the members of the body the member is board of, not any other members.
- See permission system requirements.
- Also present in the standardization requirements.
|
| 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 | - Updating profile information goes in the member attached to the user (if the user is a member(person))
|
| 14 | Data migration | The system should be able to make use of the old data from the previous system | Low | - Difference can be made between migrating and merely making use of: the second could be sort of archiving the older data, providing limited access to it
|
| 15 | Scale-ability | The system should be able to scale up to 15.000+ members | Must have | - Further scaleability requirements should be set (concurrent users? speed?)
|
| 16 | Live deployment | Once running, the system should be able to upgrade with relative ease and minimum downtime | Low | - For now this is a low priority
|
| 17 | Security | The system should handle sensitive information with care and anticipate upon users with malicious intents | Medium | - The anticipation part can be further tackled in future releases
|
| 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 | - What would be acceptable uptime? 99%?
|
| 20 | Dependence | The system dependence on other (third-party) software should respect the laid out rules for usage of third party software. | Medium | - Privacy, security and other requirements are also in place for third party software.
- Rules split between crucial elements and 'fun' elements.
- Crucial elements are elements that are vital for the correct functioning of the system. The entire core microservice can be considered crucial
- 'Fun' elements are elements that add extra functionality that is not strictly necessary: A couch surfing microservice could fall in this category.
- Crucial element requirements:
- The software must be open-source
- We need to be able to have copies of the code, in case the software is no longer publicly available
- The software should have an active user base
- Similar alternatives are a plus
- Fun element requirements:
- Abide the rules of the software
- Should comply with the crucial element requirements
|
| 21 | Privacy | The system should respect the privacy rules as specified in the CIA, the countries law and the European law | Medium | - Should probably contact JC / MedCom about this
- Maybe just Belgium's law?
|
| 22 | Guests | A non-AEGEE member should be able to access (parts of) the system | Must have |
|
| 23 | Accessability | The system should be accessable for all the members of AEGEE | Low | - Low priority for now
- Prioritize desktop mainly
|
| 24 | Search | The system should allow searching for entities on certain fields | Must have | - Entities: Members, Bodies
- Fields: Name, email, all?
|
| 25 | Filter | The system should be able to filter a set of entities based on certain fields | High | - When viewing lists of entities, but also internally for future development
|
| 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 | - Should anticipate for it, yet details can be postponed.
|
