Beta 1 (MVP 0.1) Requirements

Target release	Beta 1 (MVP 0.1)
Epic
Document status	DRAFT
Document owner	Derk Snijders
Designer	Derk Snijders
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 this release is done, further requirements to replace the current intranet (ie. MVP requirements) should be identified.
Have some working, 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.

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	?	Members list
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
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	TODO	?	What third-party software/libraries/frameworks/services are allowed?
21	Privacy	The system should respect the privacy rules as specified in the CIA and the European law	Must have	Should probably contact JC / MedCom about this
22	Guests	A non-AEGEE member should be able to access (parts of) the system	Must have	What should such a guest see?
23	Accessability	The system should be accessable for all the members of AEGEE	Low	Low priority for now What devices should it support? (and prioritize?)

User interaction and design

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

Not Doing

The following features are not included in this release, they might be included in future releases.

Events and financial management
Integration with other services (Office 365, Statutory events, online voting, SU website etc.)