Versions Compared

Version Old Version 3 New Version Current
Changes made by

Derk Snijders

Derk Snijders

Saved on

Key

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

...

  • 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

#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
  • 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
9Accept memberA ??? should be able to accept new membership applicationsMust have
  • Who should check this?
    • Medium
    • System membership, not body membership
    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
    • 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.
    12Export informationA user should be able to export information of the system?Low
    • 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 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
    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?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 lawMust haveMedium
    • 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 have
    • What should such a guest see?


    23AccessabilityThe system should be accessable for all the members of AEGEELow
    • Low priority for now
    • What devices should it support? (and prioritize?)

    ...

    • 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
    26Identify standardizationThe system should have (microservice) standardization requirements in place where necessary (cross-cutting concerns)Must have
    27Standardize rolesEach microservice in the system should abide the standardized microservice requirementsMedium
    • 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:

    QuestionOutcome
    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

    ...

    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