...
| Page Properties |
|---|
| Target release | MVP release (beta Beta 1 (MVP 0.1) |
|---|
| Epic |
|
|---|
| Document status | |
|---|
| Document owner | |
|---|
| Designer | |
|---|
| Developers | |
|---|
| QA | |
|---|
|
Goals
- Provide a first release, the first step in providing a minimal viable product (MVP).
- Provide a stable starting point to reflect and plan future incremental development upon.
- Provide a first attempt at delivering a system that can replace the current intranet
- When the MVP this release is done, the further requirements to replace the current intranet (ie. MVP requirements) should be identified.
- Have some working, showable show-able results!
Background and strategic fit
This is the first stepping stone in a more long term development process of providing AEGEE (and other NGO's) with a sustainable and usable Online Membersship System. See the project plan for more information.
Assumptions
- The term 'minimum' is based on the requirements of the organization AEGEE-Europe.
- Every member of the organization has a linked (possibly anonymous) object in the system.
- For each member there exists at least 1 user that can relate the real world member (person) to the (anonymous) member object in the system.
Requirements
| # | 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 | - 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 | Must have | Who should check this?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 marely merely making use of: the second could be sort of archiving the older data, providing limited access to it
|
User interaction and design
|
| 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.
|
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 | - Probably require Name of every member (maybe even hashed)
- Enable voluntary signup for more features + editing your profile.
|
Future releases
- Events and financial management
- Integration with other services (Office 365, Statutory events, online voting, SU website etc.)
- Document upload and sharing
Not Doing
