Versions Compared

Version Old Version 8 New Version 9
Changes made by

Anonymous

Derk Snijders

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

#TitleUser StoryImportanceNotes
1MembersThe system should contain a set of membersMust have


2BodiesThe system should contain a set of bodies Must have  
3Join bodyA member can join a bodyMust have
  • A member should be able to join multiple bodies
4Body boardA body has a board, a member can become a board of a bodyMust have
  • Board meaning 'admin' of that body, having special rights
5View membersA user can see details of a memberMust have
  • Roles should be taken into account
6Edit bodyA board of a body should be able to edit the details of a bodyMust have
7Create bodyThe Comité Directeur should be able to create a bodyMust have
8Register memberA guest should be able to register as a memberMust have
  • Should a Any guest should be able to join without any bodies? Or apply for body directly?get an account, even when not a member of AEGEE yet.
    • Using this account the AEGEE membership can be requested
9Accept memberA ??? should be able to accept new membership applicationsMedium
  • Who should check this?
  • System membership, not body membershipQuestionable if this is necessary
10View bodyA user should be able to view information of a bodyMust have
  • Body information, as well as members within the body
  • Roles should be taken into account
11Restrict AccessA user should be restricted access to actions depending on their rolesMust have
12Export informationA user should be able to export information of the systemLow
  • Members list
13Account managementA user should be able to manage his account, ie change/reset/request login credentialsMust have
  • Updating profile information goes in the member attached to the user (if the user is a member(person))
14Data migrationThe system should be able to make use of the old data from the previous systemLow
  • 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
15Scale-abilityThe system should be able to scale up to 15.000+ membersMust have
  • Further scaleability requirements should be set (concurrent users? speed?)
16Live deploymentOnce running, the system should be able to upgrade with relative ease and minimum downtimeLow
  • For now this is a low priority
17SecurityThe system should handle sensitive information with care and anticipate upon users with malicious intentsMedium
  • The anticipation part can be further tackled in future releases
18MaintainabilityA developer should be able to maintain the system with relative ease, meaning documentation of design and processes should be includedMust have
19AvailabilityThe system's uptime should be as high as possibleMedium
  • What would be acceptable uptime? 99%?
20DependenceTODO?
  • What third-party software/libraries/frameworks/services are allowed?
  • Crucial elements should be 'independent'
    • Independent probably means open source
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
21PrivacyThe system should respect the privacy rules as specified in the CIA, the countries law and the European lawMedium
  • Should probably contact JC / MedCom about this
  • Maybe just Belgium's law?
22GuestsA non-AEGEE member should be able to access (parts of) the systemMust haveWhat should such a guest see?


23AccessabilityThe system should be accessable for all the members of AEGEELow
  • Low priority for now
  • Prioritize desktop mainly
    • Microservice dependent.
24SearchThe system should allow searching for entities on certain fieldsMust have
  • Entities: Members, Bodies
  • Fields: Name, email, all?
25FilterThe system should be able to filter a set of entities based on certain fieldsHigh
  • When viewing lists of entities, but also internally for future development

...