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.
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

	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	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	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	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 Microservice dependent.
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	The standardization microservices requirements can be found here.
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

Question	Outcome
How is a cross-cutting concern such as the access restriction, which is present in nearly every requirement, done?	Standardized microservice requirements have been defined, problems such as the permission system are tackled and standardized through here.
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