| Page Properties |
|---|
| Target release | MVP release (beta 1) |
|---|
| Epic |
|
|---|
| Document status | |
|---|
| Document owner | |
|---|
| Designer | |
|---|
| Developers | |
|---|
| QA | |
|---|
|
Goals
- Provide a first release, the minimal viable product.
- 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 is done, the further requirements to replace the current intranet should be identified.
- Have some working, showable results!
...
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.
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 |
|
| 9 | Accept member | A ??? should be able to accept new membership applications | Must have | - Who should check this?
- 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.
|
| 12 | Export information | A user should be able to export information of the system | ? | |
| 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 | ? | - Difference can be made between migrating and marely making use of: the second could be sort of archiving the older data, providing limited access to it
|
User interaction and design
...
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 |
Not Doing
