Upload files to "/"

Requirementsdocument vernieuwd

RequirementsNLUUG.md

@@ -0,0 +1,572 @@
+# Specificaties voor de NLUUG ledenadministratie 
+
+Jan Sepp
+
+September 2024
+
+## Aanleiding
+
+De NLUUG is voornemens een nieuwe ledenadministratie in te voeren. Die moet "hetzelfde kunnen als de huidige ledenadministratie" en meer. Dat meer is met name integratie met het boekhoudpakket van de vereniging.
+
+De huidige ledenadministratie heeft een dubbele functionaliteit: een vrij kale ledenadministratie, zij het met veel verschillende types leden, en een donateurs administratie. Bijzonder is dat de contributie van leden betaald kan worden uit de donateursbijdragen. Leden zijn altijd mensen, donateurs zijn altijd organisaties. Donateurs gaan een "Bedrijfsregeling" aan met de NLUUG -- hoewel veel donateurs helemaal geen bedrijf zijn, maar bijvoorbeeld opleidingsinstituten of overheidsinstanties. 
+
+Daarnaast verzorgt de huidige software de registratie van deelnemers aan evenementen, die heel innig verstrengeld is met de ledenadministratie. In de nieuwe software zou de evenementenadministratie ook een aparte module kunnen zijn. In deze specificaties sluiten we ons aan bij de bestaande praktijk en combineren we ledenadministratie en evenementenadministratie.
+
+We hebben in de ledenadministratie behoefte aan het administreren van bestuurs- en commissieleden. We kennen geen elftallen of andere teams.
+
+De NLUUG is een aantrekkelijk doel voor crackers. Beveiliging moet vanaf het begin ingebouwd zijn en integraal in de ledenadministratie verwerkt zijn.
+
+## Inhoud
+
+[TOC]
+
+
+
+# 1 Terminologie
+
+
+
+## 1.1 Definities
+
+- Ledenadministratie: De software en de gegevens die nodig zijn om leden te kunnen inschrijven en uitschrijven en om gegevens van leden te kunnen opvragen. Dat opvragen kan zowel op individueel niveau gebeuren (bijvoorbeeld om een lid in te schrijven voor een evenement), als geaggregeerd (bijvoorbeeld om het actueel aantal leden uit te vragen dat de contributie nog niet betaald heeft.)
+
+- Ledenadministrateur: de mens(en) die de ledenadministratie bijhouden. In praktijk worden zij collectief ook wel aangeduid als "de ledenadministratie", maar om verwarring te voorkomen gebruiken we in dit document de termen zoals hier beschreven. 
+
+- Evenement: een (mede) door de NLUUG georganiseerde activiteit. Bijvoorbeeld: conferentie, Algemene Ledenvergadering, nieuwjaarsborrel
+
+- Evenementenadministratie: De software en de gegevens die nodig zijn om een evenement aan te maken, leden op dat evenement in te schrijven en uitschrijven en om gegevens van evenementen te kunnen opvragen.
+
+- Evenementenadministrateur: de mens(en) die de evenementenadministratie bijhouden. 
+
+- Buro: de term die binnen de NLUUG gebruikt wordt om de gecombineerde functie ledenadministrateur en evenementenadministrateur aan te duiden. Is in ieder geval minder schrijfwerk dan die twee termen.
+
+- Software: de database en de programmatuur die benodigd zijn om de functionaliteit van de ledenadministratie en de evenementenadministratie te kunnen uitvoeren. 
+
+- NAW: Naam, Adres en Woonplaats. Adres is in deze definitie ook e-mailadres en eventuele sociale media-adressen.
+
+- LidID: een unieke code per lid. Historisch gegroeid is dat er een apart ID voor mensen (personID, formaat p[0-9]{4}) en één voor deelnemers aan de bedrijfsregeling (companyID, formaat c[0-9]{4}) bijgehouden wordt. Een eenmaal uitgegeven LidID wordt niet hergebruikt. Dat impliceert dat nieuwe leden en nieuwe deelnemers aan een bedrijfsregeling automatisch het eerstvolgende vrije nummer krijgen. Dat is nu ook al zo. Er is geen reden om dat te veranderen, met dien verstande dat de 4-cijferige codes beginnen op te raken en we dus een 5-cijferige code gaan gebruiken. De huidige leden houden hun LidID maar er komt direct na de p of de c een voorloopnul bij. De nieuwe formaten worden dus  p[0-9]{5}, respectievelijk c[0-9]{5}. 
+
+- LidType: een één- of twee-letterige code die aangeeft om wat voor type lid het gaat. De contributieheffing is verschillend per LidType.  LidTypes worden hieronder nader toegelicht. 
+
+  - Lid: een mens (dus geen bedrijf of organisatie) die persoonlijk lid van de NLUUG is. Thans: LidType L (Lid), E (Erelid) of S (Studentlid). Een lid is contributieplichtig, met uitzondering van een erelid. Een lid kan zich (thans) gratis inschrijven voor een evenement. Leden hebben stemrecht in de ALV. Leden zijn lid voor (de rest van) een kalenderjaar en kunnen zich voor het eind van het jaar uitschrijven. Leden kunnen de over hen bewaarde gegevens inzien en beperkt veranderen.  Verder hebben leden (als ze niet vallen onder de definitie van Actief lid)  geen  bijzondere privileges in de software. 
+  - Introducé: een persoon die één maal gratis aan een evenement kan deelnemen (LidType I). Introducés moeten ermee akkoord gaan dat de NLUUG hun NAW gegevens drie jaar lang bewaart en dat ze op de verzendlijst voor evenementen opgenomen worden .
+  - Geïnteresseerde: een persoon die op de verzendlijst voor evenementen staat (thans eveneens LidType I, later misschien LidType G). Geïnteresseerden komen op de verzendlijst op verzoek en worden ook weer afgevoerd op verzoek.
+  - Introducés (LidType I) en Geïnteresseerden (LidType G (?)) zijn geen lid en niet contributieplichtig. 
+  - Ex lid: een persoon die heeft opgezegd of is geroyeerd (LidType X). Ex leden blijven beschikbaar in de software volgens de regels van de AVG. De reden van opzegging wordt door de ledenadministrateur (hieronder gedefinieerd) wordt toegevoegd aan de gegevens van het ex-lid. De NLUUG heeft belang bij het (drie jaar lang) bewaren van geroyeerde leden en in het verlengde daarvan van opgezegde leden. 
+  - Kantoorlid (LidType K): een persoon die zelf wel of geen Lid is, maar privileges heeft om gegevens over (deelnemers aan) evenementen in te zien en aan te passen. Thans: Debbie Reijnders.
+  - Nieuw lid: een persoon die nog geen lid is maar dat wel wil worden. Heeft vanzelfsprekend geen LidID, noch een LidType.
+  - Deelnemer Bedrijfsregeling: een organisatie die leden kan afvaardigen, en de contributie voor die leden voldoet. Hoeveel leden hangt af van de bijdrage. LidTypes zijn D1, D2, D4, D8 of DP. 
+  - Er bestaat een lidType D0: organisaties die geen contributie bijdragen en (dus) ook geen leden kunnen afvaardigen. Dit LidType word uitsluitend voor administratieve doeleinde gebruikt. Ex deelnemers aan een Bedrijfsregeling krijgen ook status D0. De gegevens daarvan worden maximaal 10 jaar bewaard, omdat de NLUUG er belang bij heeft historische lijsten van evenementen te kunnen bijhouden
+  - Administratief lid (LidType A): vertegenwoordiger van een een deelnemer aan de Bedrijfsregeling. Deze persoon kan zelf wel of geen Lid zijn, maar de gegevens van anderen van hetzelfde bedrijf mag inzien en wijzigen.
+
+- De software voor de ledenadministratie moet in de toekomst gemakkelijk ook andere LidTypen kunnen aanmaken/gebruiken. Zo is er thans binnen de NLUUG discussie over een aparte status (en dus: LidType) voor gepensioneerden.
+
+- Affiliatie: een Lid dat werkt voor een Deelnemer Bedrijfsregeling (inclusief D0). Dat wil niet automatisch zeggen dat het bedrijf ook betaalt voor dat lid.
+
+- CompanyPays: de contributie voor een Lid wordt voldaan uit de bijdrage van een Deelnemer Bedrijfsregeling. (Dus niet een D0 deelnemer, want die betaalt niet.) In dat geval moet het bedrijf een LidType D1 .. DP hebben en moet de affiliatie tussen Lid en Bedrijf gelegd zijn. 
+
+- Factuur is in de ledenadministratie een factuur voor de lidmaatschapsgelden, of een factuur voor deelname aan een evenement. Dus geen factuur voor "spullen" of geleverde diensten. (Of moeten we dat in de toekomst wel kunnen doen?)
+
+- Template: een standaardbrief waarin later NAW gegevens toegevoegd kunnen worden  om een mass-mailing te verzenden
+
+- Een persoon kan van LidType veranderen, bijvoorbeeld van L naar E, of van L naar X, maar behoudt altijd hetzelfde LidID. Iets dergelijks geldt voor deelnemers aan een Bedrijfsregeling
+
+- Wachtwoordzin ("passphrase"): Een zin van tenminste 16 tekens  (maximaal 255 tekens) die gebruikt wordt als wachtwoord. We gebruiken **geen 2-factor authenticatie**, dat zou overkill zijn voor de NLUUG leden-administratie. In plaats daarvan vragen we een sterk wachtwoord. Een zinnetje van tenminste 16 tekens is sterk genoeg, en is gemakkelijker te onthouden dan een wachtwoord.
+
+  
+
+## 1.2 Rollen en privileges
+
+Een Actief lid is (meestal) een Lid dat een **rol** binnen de NLUUG heeft, en uit hoofde van die rol privileges bij de ledenadministratie heeft. Actieve leden ondertekenen (**allen???**) de "geheimhoudingsverklaring NLUUG". Eén lid (LidType L, S, A of E) kan meerdere rollen op zich nemen. 
+
+- Voorzitter: een persoon die zelf wel of geen Lid is, maar verder alle rechten van een Bestuurslid heeft.
+- Bestuurslid: een lid dat zicht heeft op geaggregeerde ledengegevens, en op namen en e-mailadressen van individuele leden. Heeft zicht op geaggregeerde evenementgegevens, inclusief geaggregeerde financiële gegevens. 
+  - Secretaris: een Bestuurslid dat bulk e-mails mag verzenden. Kan templatebrieven opstellen of goedkeuren. 
+  - Penningmeester: Kan financiële gegevens per lid inzien en aanpassen. Kan facturen sturen, betalingen boeken, facturen intrekken (of dat delegeren aan het buro).
+- Buro: een persoon die zelf wel of geen Lid is en administratieve handelingen voor de NLUUG verricht. Verstuurt in opdracht van de secretaris of de penningmeester bulk mailings. Kan gegevens buiten de GUI om rechtstreeks opvragen (maar niet wijzigen) in de database (ad hoc queries). Beheert de templates voor brieven. 
+  De rol evenementenadministrateur en de rol ledenadministrateur worden sinds circa 2010 door dezelfde persoon uitgevoerd onder de naam Buro. Dat hoeft in de toekomst niet zo te blijven. 
+  - Ledenadministrateur: beheert lidgegevens. Schrijft nieuwe leden en nieuwe deelnemers Bedrijfsregeling in, kan die gegevens wijzigen en kan leden en deelnemers bedrijven uitschrijven, op verzoek van dat Lid of die Deelnemer zelf of op verzoek van het bestuur.  Heeft toegang tot alle lid- en bedrijfs-gegevens. Kan (uitsluitend in opdracht van het bestuur) een rol koppelen aan een Lid, en deelt uit dien hoofde privileges uit. Kan gegevens over lden en deelnemers aan bedrijfsregelingen buiten de GUI om rechtstreeks opvragen (maar niet wijzigen) in de database (ad hoc queries).
+  - Evenementenadministrateur: Maakt evenementen administratief aan, stelt de inschrijving open, verleent leden (met name deelnemers aan een bedrijfsregeling) hand- en spandiensten bij de inschrijving, kan lijsten genereren. Heeft read-only toegang tot alle lid- en bedrijfsgegevens. heeft volledige toegang tot alle evenementgegevens. Kan gegevens over evenementen buiten de GUI om rechtstreeks opvragen (maar niet wijzigen) in de database (ad hoc queries). De evenementenadministrateur bemoeit zich (in die rol) niet met de inhoud van evenementen. 
+  
+- Kantoor: heeft toegang tot evenementeninformatie, zowel lezen als schrijven.
+- Administratief lid: heeft toegang tot de gegevens van het bedrijf (Deelnemer Bedrijfsregeling) waar hij/zij de administratie voor doet, voor zover dat de bedrijfsregeling aangaat. Dus: leden toevoegen aan de bedrijfsregeling, leden verwijderen uit de bedrijfsregeling.
+- Commissielid
+  - Programmacommissie: kan deelnamelijsten aan de door hen georganiseerde evenementen opvragen.
+  - Beheer team[Hebben we één privileges set voor alle leden van het beheerteam? Anders: ]
+    - Databeheerder: heeft als administrateur toegang tot de database en de software van de ledenadministratie. Is verantwoordelijk voor continuïteit en integriteit van de ledenadministratie software. (Dus maakt de back-ups) (en kan ze restoren!) Kan gegevens buiten de GUI om rechtstreeks opvragen en wijzigen in de database (ad hoc queries).
+    - Systeembeheerder: heeft als beheerder toegang tot de hardware of de VM waar de ledenadministratie op draait. 
+  - Website: kan de stijl en de teksten in het ledengedeelte van de website aanpassen. Kan/mag niet bij de gegevens van individuele leden, noch bij de betalingsgegevens.
+  - Kascontrolecommissie: heeft geen privileges in de ledenadministratie. Wel kunnen ze de ledenadministrateur (of het buro) verzoeken om lijsten van facturering/betalingen/aanmaningen voor hen uit te draaien. 
+  - Overige werkgroepen (thans filmteam, FTP-beheerteam, PR-team) hebben geen privileges in de ledenadministratie.
+- **Om over na te denken:** Wat doen we met externen - dus niet-leden - die toch in de ledenadministratie (en de financiële administratie) moeten kunnen kijken, zoals de accountant en de Belastingdienst? Voorlopige oplossing: onder begeleiding en op de credentials van de penningmeester? 
+
+
+
+# 2 Functionele specificaties Ledenadministratie
+
+
+
+## 2.1 Processen: Leden zonder rollen
+
+### 2.1.1 Niet-leden
+
+- niet leden hebben geen toegang tot de ledenadministratie 
+- er zijn (dus) geen processen voor hen gedefinieerd
+- kunnen zich via de publieke website aanmelden als Nieuw lid
+
+### 2.1.2 Nieuwe leden
+
+- moeten zich kunnen aanmelden op de **publieke** website
+- de ledenadministratie moet aanmeldingen ontvangen
+- de ledenadministrateur moet nieuwe leden kunnen fiatteren of afwijzen
+- het nieuwe lid moet een bevestiging krijgen
+- het nieuwe lid moet een factuur krijgen
+- het nieuwe lid moet een account krijgen: LidType, LidID, loginnaam en wachtwoordzin. Loginnaam en wachtwoordzin moeten via verschillende media aan het nieuwe lid verstuurd worden.
+
+### 2.1.3 Leden
+
+- hebben LidType L, S of E
+- moeten kunnen inloggen met hun loginnaam en wachtwoordzin
+- moeten kunnen uitloggen of worden uitgelogd na xx minuten inactiviteit
+- moeten hun eigen gegevens kunnen inzien: NAW, overige adressen, affiliatie, companyPays, facturen aan het lid, brieven aan het lid, inschrijving voor evenementen
+- moeten een deel van hun eigen gegevens kunnen wijzigen : NAW, overige adressen, affiliatie
+- moeten hun eigen wachtwoord kunnen wijzigen, waarbij ze eerst het oude wachtwoord moeten invoeren
+- moeten een factuur ontvangen (geldt ook voor LidType E, zij het met nul-tarief)
+- moeten, indien nodig, aanmaningen ontvangen
+- moeten zich kunnen inschrijven voor evenementen
+- moeten zich kunnen uitschrijven voor evenementen, indien van toepassing
+- moeten hun eigen contributiegedrag kunnen opvragen (facturen en betalingen)
+- moeten kunnen opzeggen
+
+### 2.1.4 Ex-Leden
+
+- Een lid dat (zelf) opzegt, of een lid dat geroyeerd wordt , moet als LidType een "X" krijgen
+- De reden van de opzegging moet gelogd worden
+- Ex-leden hebben geen toegang tot de ledenadministratie: loginnaam en wachtwoord moeten verwijderd of onleesbaar gemaakt worden direct na de opzegging.
+- Het LidID verandert niet
+- Ex-leden, personen, moeten na drie **(?)** jaar automatisch uit de ledenadministratie verwijderd worden, inclusief alle loggegevens die over hen bijgehouden worden. Het LidID blijft wel gehandhaafd, zodat we historische lijsten kunnen opmaken
+- Dit heeft tot gevolg dat er op historische ledenlijsten en deelnamelijsten een lidnummer, gevolgd door N.N. zal komen staan
+- Een ex-lid wordt overigens behandeld als een niet-lid
+
+### 2.1.5 Deelnemers Bedrijfsregeling
+
+- hebben uitsluitend toegang tot de ledenadministratie via het Administratief Lid voor dat bedrijf
+- ontvangen facturen en aanmaningen op een administratief bedrijfsadres
+- wijzen een persoon aan als administratief lid
+- betalen voor leden die zijn geaffilieerd voor het bedrijf
+
+### 2.1.6 Ex deelnemers bedrijfsregeling
+
+- Een bedrijf dat deelname aan de bedrijfsregeling beëindigt moet als LidType D0 krijgen. [Noot JS: of iets anders. Nu kunnen we geen onderscheid maken tussen bedrijven die door leden genoemd worden en en ex deelnemers. Zullen we bedrijven ook een DX geven?]
+- Een eventueel Administratief Lid voor dat bedrijf krijgt automatisch LidType L
+- Een Lid (dus een persoon) kan geaffilieerd blijven aan een ex deelnemer bedrijfsregeling
+- Een ex deelnemer bedrijfsregeling zal natuurlijk niet meer voor een lid betalen
+- Leden (LidType S, L, E) (+ A, maar die hadden we al omgezet) die werden betaald uit de deelname bedrijfsregeling moeten bij opzegging daarvan geïnformeerd worden dat hun bedrijf heeft opgezegd en dat zij in het vervolg persoonlijk contributieplichtig zijn. Ze mogen natuurlijk opzeggen.
+- bij het beëindigen van de bedrijfsregeling moet het veld "companyPays" voor alle leden die aan dat bedrijf gelieerd zijn op No gezet worden. Het veld "works4Company" hoeft niet aangepast te worden
+- In verband met het opmaken van deelnemerslijsten aan evenementen etc. blijven de gegevens van ex deelnemers bedrijfsregeling 10 jaar bewaard
+
+### 2.1.7. Geïnteresseerden
+
+- Geïnteresseerden (LidType I en in de toekomst mogelijk LidType G) worden aangemeld door deelnemers aan een Bedrijfsregeling, LidType D2 en hoger en door Bestuursleden
+- Geïnteresseerden zijn geen lid, en hebben dus ook geen toegang tot de ledenadministratie
+- Geïnteresseerden moeten de gegevens die de NLUUG van hen bijhoudt kunnen opvragen bij de ledenadministrateur (dus de mens, niet het proces)
+- Geïnteresseerden worden na drie jaar automatisch uit de ledenadministratie verwijderd
+- De ledenadministratie (het proces, niet de mens) moet bij het inschrijven van een geïnteresseerde aangeven of deze persoon in de afgelopen drie jaar al eerder ingeschreven geweest is. 
+
+
+
+## 2.2 Processen: Leden met rollen 
+
+### 2.2.1 Administratief Lid
+
+- kan Lid zijn, kan ook alleen LidType "A"  hebben
+- als geen lid: moet alles kunnen wat een Lid kan, met uitzondering van zichzelf in- en uitschrijven voor evenementen
+- moet de gegevens van het bedrijf en de gegevens van de Leden die geaffilieerd zijn met het bedrijf kunnen beheren
+- moet Leden, geaffilieerd met het bedrijf, kunnen inschrijven voor evenementen
+- moet het contributiegedrag van het bedrijf kunnen opvragen (facturen en betalingen)
+
+### 2.2.2 Bestuurslid
+
+- is een Lid (mogelijk m.u.v. de voorzitter)  en mag/kan dus alles wat een Lid mag. Daarenboven: 
+- moet geaggregeerde gegevens (kengetallen) kunnen opvragen
+- moet de huidige ledenlijst kunnen raadplegen: LidType, LidID, NAW, e-mailadres
+- moet de deelnemerslijst per evenement (zowel toekomstig als historisch) kunnen raadplegen
+
+### 2.2.3 Voorzitter
+
+- is een Bestuurslid en mag/kan dus alles wat een Bestuurslid mag. Daarenboven: 
+- moet NAW gegevens (inclusief e-mail gegevens) van individuele leden kunnen opvragen
+
+### 2.2.4 Secretaris
+
+- is een Bestuurslid en mag/kan dus alles wat een Bestuurslid mag. Daarenboven: 
+- moet NAW gegevens (inclusief e-mail gegevens) van individuele leden kunnen opvragen
+- moet Templates voor mailings kunnen aanmaken, inzien, wijzigen en verwijderen (of dat delegeren aan het buro)
+- moet lijsten van ontvangers van mailings kunnen aanmaken, inzien, wijzigen en verwijderen (of dat delegeren aan het buro)
+- moet lijsten van ontvangers en templates kunnen koppelen en zo mailings kunnen versturen. Bijvoorbeeld (maar niet uitsluitend) uitnodigingen voor vergaderingen of nieuwsbrieven (of dat delegeren aan het buro)
+
+### 2.2.5 Penningmeester
+
+- is een Bestuurslid en mag/kan dus alles wat een Bestuurslid mag. Daarenboven: 
+
+- moet NAW gegevens (inclusief e-mail gegevens) van individuele leden kunnen opvragen
+
+- moet het historisch betalingsgedrag van individuele leden kunnen opvragen, inclusief ex-leden (LidType X) en ex deelnemers aan de Bedrijfsregeling (LidType D0 of DX) 
+
+- moet de contributietarieven kunnen aanpassen
+
+  - individuele leden (per jaar, per halfjaar)
+
+  - deelnemers bedrijfsregeling (per categorie)
+
+- moet de tarieven voor evenementen per evenement kunnen aanpassen
+
+- mag contributietarieven voor vorige jaren NIET meer aanpassen
+
+- moet templates voor facturen en aanmaningen kunnen aanmaken (of dat delegeren aan het buro)
+
+- moet facturen en aanmaningen kunnen versturen (of dat delegeren aan het buro)
+
+- moet individuele facturen en aanmaningen kunnen invoegen (of dat delegeren aan het buro)
+
+- moet individuele facturen en aanmaningen kunnen aanpassen (of dat delegeren aan het buro)
+
+- moet individuele facturen en aanmaningen kunnen cancelen (of dat delegeren aan het buro)
+
+- moet openstaande facturen op "paid" of "partiallyPaid" kunnen zetten (of dat delegeren aan het buro)
+
+- moet lijsten kunnen opvragen van alle ...
+
+  - te verzenden facturen voor dit kalenderjaar (inclusief mogelijkheid tot aanpassingen)
+  - verzonden facturen per kalenderjaar
+  - betaalde facturen per kalenderjaar
+  - onbetaalde facturen per kalenderjaar
+  - deels betaalde facturen per kalenderjaar
+  - te verzenden aanmaningen voor dit kalenderjaar (inclusief mogelijkheid tot aanpassingen)
+  - verzonden aanmaningen per kalenderjaar
+
+- moet geaggregeerde bedragen kunnen opvragen:
+
+  - totaal betaalde contributie per kalenderjaar
+  - totaal onbetaalde contributie per kalenderjaar
+
+- moet financiële gegevens die niet uit de automatische bank-koppeling komen kunnen invoeren in de ledenadministratie
+
+  
+
+### 2.2.6 Evenementenadministrateur
+
+N.B. De rollen "Evenementenadministrateur" en "Ledenadministrateur" worden sinds 2010 uitgevoerd door één persoon onder de naam "Buro". Maar de rollen zijn verschillend.
+
+Evenementenadministrateur is een ondersteunende rol, die penningmeester, secretaris en met name programmacommissie bijstaat. Uit dien hoofde moet de Evenementenadministrateur ten minste mailings kunnen versturen, en verder facturen kunnen aanmaken en versturen. We kunnen het zo inrichten dat de rol evenementenadministrateur de ledenadministratie mag uitvragen, zowel op individueel niveau als op lijstniveau, maar de ledenadministratie niet mag wijzigen.
+
+Of toch wel? Moet de Evenementenadministrateur bijvoorbeeld de tarieven kunnen aanpassen? Moet de Evenementenadministrateur betalingen kunnen invoeren en cancelen voor de penningmeester?
+
+Hoe dan ook,de Evenementenadministrateur ...
+
+- moet evenementen administratief kunnen aanmaken
+- moet inschrijvingslijsten voor evenementen kunnen aanmaken
+- moet leden kunnen inschrijven voor evenementen. Dit op verzoek van leden zelf of van deelnemers aan een Bedrijfsregeling
+- moet niet-leden (sprekers, invitees) kunnen inschrijven voor evenementen
+- moet brieven over evenementen kunnen versturen
+- moet facturen over evenementen kunnen versturen
+- moet een evenement na afloop van dat evenement kunnen afsluiten
+  - deelnamegelden
+  - inschrijvingen
+
+- moet geaggregeerde gegevens over evenementen (zowel huidige als historische) kunnen verstrekken aan bestuursleden, evenemnetncommissie en kantoor
+
+- moet SQL code kunnen gebruiken om niet-voorgeprogrammeerde lijsten uit te draaien
+
+### 2.2.7 Kantoor
+
+**uitwerken**
+
+### 2.2.8 Ledenadministrateur
+
+N.B. De rollen "Evenementenadministrateur" en "Ledenadministrateur" worden sinds 2010 uitgevoerd door één persoon onder de naam "Buro". Maar de rollen zijn verschillend. 
+
+De Ledenadministrateur ...
+
+- moet nieuwe leden kunnen inschrijven
+  - de software moet behulpzaam zijn bij het voorkomen van dubbele inschrijvingen (wat met de huidige software te vaak voorkomt)
+- moet de gegevens van bestaande leden kunnen wijzigen
+  - NAW gegevens
+  - wachtwoorden
+- moet leden kunnen uitschrijven
+  - op verzoek van het lid zelf
+  - op verzoek van nabestaanden
+  - in opdracht van de penningmeester (royeren)
+- moet nieuwe deelnemers aan een bedrijfsregeling kunnen inschrijven
+  - inclusief het bepalen in welke categorie een deelnemer valt (D0, D1 ... DP)
+- moet de gegevens van bestaande deelnemers aan een bedrijfsregeling kunnen wijzigen
+  - naam en afdeling
+  - adresgegevens
+  - factuurgegevens
+  - administratief contactpersoon
+  - upgrade (bijvoorbeeld van D2 naar D4) en downgrade
+- moet deelnemers aan een bedrijfsregeling kunnen uitschrijven
+  - op verzoek van het bedrijf
+  - wegens bedrijfsbeëindiging
+  - in opdracht van de penningmeester (royeren)
+- moet leden (als in: mensen) kunnen koppelen aan deelnemers aan een bedrijfsregeling, en kunnen ontkoppelen
+  - affiliatie met een deelnemer aan een bedrijfsregeling
+    - op verzoek van een lid
+    - op verzoek van een (contactpersoon van) een deelnemer aan een bedrijfsregeling
+  - bedrijf betaalt voor een lid / bedrijf betaalt niet (meer)
+    - eenmalig bij inschrijving
+    - jaarlijks, automatisch n.a.v. contributiebetaling door de deelnemer aan een bedrijfsregeling
+  - bovenstaande houdt in dat de leden die staan ingeschreven uit hoofde van de contributie van de deelnemer aan een bedrijfsregeling op de factuur vermeld staat. Dat is met de huidige software niet mogelijk.
+- moet voorgeprogrammeerde lijsten kunnen uitdraaien
+  - op criteria
+  - met sortering
+- moet SQL code kunnen gebruiken om niet-voorgeprogrammeerde lijsten uit te draaien
+- moet een jaarafsluiting kunnen uitvoeren
+  - jaarrapportage (ledenaantal per 1/1, ledenaantal per 31/12, aantal nieuwe leden, aantal opgezegde leden, aantal leden dat contributie niet betaald heeft, idem voor deelnemers aan een bedrijfsregeling, meer ... )
+  - alle Leden die langer dan drie jaar geleden hebben opgezegd verwijderen
+  - per lid vernieuwen veld bedrijf betaalt
+- moet een jaaropening kunnen uitvoeren
+  - nader te bepalen
+- moet alle taken die worden gedelegeerd door de secretaris kunnen uitvoeren
+- moet alle taken die worden gedelegeerd door de penningmeester kunnen uitvoeren
+
+### 2.2.9 Programmacommissie
+
+- Buiten de software om:
+  - Communiceert de data (als in "datums") van evenementen met het Buro
+  - Verzoekt het Buro om de inschrijving voor een evenement open te stellen
+  - Verzoekt het Buro om sprekers en andere Invitees op de deelnemerslijst in te schrijven
+  - Verzoekt het Buro om een evenement af te sluiten
+- Moet deelnemerslijsten (ook van voorgaande evenementen) kunnen inzien
+
+### 2.2.10 Beheer
+
+uitwerken
+
+
+
+
+
+
+
+## 2.3 Koppelingen met andere administraties
+
+Er moet een read-mostly koppeling zijn tussen de **ledenadministratie** en de **financiële administratie**:
+
+- tenminste IDeal betalingen, voor zover die contributie of evenementskosten betreffen, moeten automatisch doorgevoerd kunnen worden in de ledenadministratie.
+- liefst ook een koppeling met het gebruikte boekhoudpakket (thans: een spreadsheet, dus dat wordt knap lastig) waardoor de relevante rubrieken in de boekhouding automatisch doorgevoerd kunnen worden in de ledenadministratie.
+- Het allermooist is het als facturen die in de ledenadministratie aangemaakt worden automatisch worden doorgezet naar de boekhouding. Vandaar: read-mostly.
+
+
+
+
+
+
+
+## 2.4 Optional requirements
+
+(indien mogelijk ... dan zal)
+
+### 2.4.1 financieel
+
+De ledenadministratie moet zo ver mogelijk geïntegreerd worden met de financiële administratie, voor wat betreft contributiebetalingen en kwijtschelding daarvan. Hetzelfde geldt voor de evenementenbetalingen. Dat houdt in dat de ledenadministratie moet kunnen interfacen, nu en in de toekomst, met het gebruikte boekhoudpakket. 
+
+### 2.4.2 geen elftallen nodig
+
+De meeste ledenadministratie pakketten zullen software bevatten waarmee elftallen, zeventallen of wat dan ook worden bijgehouden. De NLUUG heeft dat niet nodig -- maar het zit ons ook niet in de weg. Als we die functionaliteit kunnen gebruiken om de bemensing van onze commissie bij te houden is dat goed. Maar liever zien we aparte functionaliteit (inclusief beveiliging) om leden van commissies te registreren.
+
+
+
+### 2.4.3 Manual override
+
+De huidige software is vaak té slim. Soms moet de ledenadministrateur facturen of brieven sturen naar een ander adres dan die van het lid zelf. (Bijvoorbeeld een lid dat een ander persoon een lidmaatschap cadeau wil doen.) Dat is thans een moeizaam proces of, in enkele gevallen, niet mogelijk. Het zou heel prettig zijn als een gebruiker/official In het nieuwe systeem de mogelijkheid heeft om brieven en facturen die normaal vanuit een template verstuurd worden eerst te kunnen aanpassen, inclusief de adressering. En dat dus binnen de web-gebaseerde GUI. (Dit is een forse eis, die we zo tussen neus en lippen door introduceren: het vraagt een editor in de GUI. )
+
+## 
+
+
+
+
+
+
+
+## 2.5 Unwanted behavior
+
+(het programma mag niet ...)
+
+### 2.5.1 Geen boekhouding
+
+De ledenadministratie is geen volwaardige financiële administratie, noch een boekhoudpakket. We zoeken dus ook GEEN boekhoudpakket met bijbehorende ledenadministratie, maar een volwaardige ledenadministratie die kan interfacen met de boekhouding. 
+
+### 2.5.2 Geen webshop
+
+Mocht de NLUUG ooit besluiten een eigen webshop of winkel ("verenigings stand") te begonnen, dan valt de administratie buiten de ledenadministratie en moet daar dus eigen software voor komen.
+
+### 2.5.3 Geen uren- of materiaalregistratie
+
+De NLUUG is een vrijwilligersorganisatie. De ledenadministratie voorziet niet in een urenregistratie. En in het verlengde daarvan al helemaal niet in een voorraad- of materiaalregistratie
+
+### 2.5.4 Geen CRM
+
+Hoewel je in de specificaties voor een "Customer Relationship Management" programma (CRM) een aantal van dezelfde wensen en eisen tegen zult komen al in de eisen voor dit ledenadministratieprogramma, is het NLUUG ledenadministratieprogramma beslist geen CRM. We hoeven geen bezoekegistratie, recente verkopen of afspraken bij te houden.  Daarentegen hebben we een aantal functionele specificaties (bijvoorbeeld contributies factureren en registreren) die in een CRM niet standaard voorhanden zullen zijn. 
+
+
+
+
+
+
+
+
+
+
+
+# 3 Data
+
+Zie  bestand NLUUG-Data-Description.png
+
+### 
+
+
+
+
+
+
+
+# 4 Niet-functionele specificaties
+
+## 4.1 Open Source
+
+Deze specificaties zijn zoveel mogelijk los van producten opgesteld. Pas na het vaststellen van de specificaties gaan we kijken of er programmatuur is te vinden die aan (het merendeel van) onze specificaties tegemoet komt. Gezien de aard van de NLUUG -- het bevorderen van de Open Source gedachte -- ligt het voor de hand om daarvoor naar Open Source programmatuur te kijken. Dat geldt zowel voor het programma als voor de data-opslag
+
+Als er geen passende open source programmatuur te vinden is moeten we zoeken naar proprietary software die aan onze eisen voldoet.
+
+Als ook dat geen bevredigend resultaat heeft dan moeten we zelf de programma's schrijven. Dat is veel werk, maar geen raketwetenschap. En die moeten we natuurlijk als Open Source beschikbaar maken, al dan niet met support van onze leden.
+
+## 4.2 Data in eigen beheer
+
+- De gegevens uit de ledenadministratie zijn privacy gevoelig. De leden moeten erop kunnen vertrouwen dat de hun persoonlijke gegevens niet in handen van derden komen -- tenzij de ALV daarop een uitzondering heeft gemaakt. 
+
+- In bijzondere gevallen mogen derden de gegevens van de NLUUG inzien. We denken hier met name aan Debbie Reijnders of, meer in het algemeen, de rol Kantoor (LidType K). LidType K vereist dus ook dat de rolhouders de "geheimhoudingsverklaring NLUUG" ondertekend hebben.
+- Data-opslag (zowel de actieve database als backups daarvan) moet zodanig gebeuren dat derden die data niet kunnen inzien. Dat betekent dat een eventuele Cloud Provider (of, meer in het algemeen: Hosting Provider) afdoende garanties moet kunnen bieden omtrent de privacy van onze gegevens. 
+
+## 4.3 Geen voorkeur voor Cloud of Edge
+
+De NLUUG heeft geen voorkeur voor enige vorm van hosting. De programmatuur en de data mogen in de Cloud resideren, met inachtneming van bovenstaande (en onderstaande) voorwaarden, maar het is geen vereiste. Een zelf-gehoste lokale (virtuele) enkelvoudige server is afdoende. De applicatie is te insignificant om op te splitsen in microservices. "Cloud-native" is voor het ledenadministratieprogramma geen vereiste. Het mag, maar het hoeft niet.
+
+### 4.3.1 Geen API's
+
+Er is in eerste instantie geen communicatie nodig tussen de ledenadministratie en andere software. Er is geen behoefte aan API's waarmee externe software kan communiceren met de ledenadministratie.
+
+Vanzelfsprekend moet de ledenadministratie wel kunnen communiceren met derde partijen die data aanbieden die relevant zijn. We denken daarbij met name aan bankiers-software. 
+
+## 4.4 User interface
+
+Er moeten veel rollen, en veel rollen tegelijk, van de ledenadministratie gebruik kunnen maken. Het ligt veruit het meest voor de hand omdat browser gebaseerd te laten doen. Dat betekent dat de ledenadministratie als een webservice aangeboden moet worden.
+
+Er zijn twee **uitzonderingen**: de ledenadministrateur moet naast alle web-based programma's ook ad-hoc gegevens kunnen opvragen, dus die moet read-only CLI toegang tot de database hebben. De database beheerder moet storingen en data-conflicten kunnen verhelpen, dus die moet read-write CLI toegang tot de database hebben.
+
+
+
+## 4.5 Role-based beveiliging
+
+Er zijn technisch heel veel gradaties van beveiliging mogelijk. Laten we eerst even ons risico in kaart brengen: als we gehackt worden, dan weten de hackers de namen en e-mailadressen van de leden en deelnemers aan de bedrijfsregelingen van de NLUUG. We zouden bijna zeggen: *good luck to you*. (Sorry. Er volgt nog veel meer Engels. Inherent aan het onderwerp.)  Weliswaar moeten we zo’n inbreuk netjes melden aan de leden, maar er worden niet of nauwelijks gegevens bekend die niet ook al bij de Googles, Meta’s en Amazons van deze wereld bekend zijn – en die verhandeld worden. 
+
+We zijn er ook van overtuigd dat een cracker beduidend gemakkelijker kan inbreken via *social engineering* (zelfs bij de leden/officials van de NLUUG) dan via een technische crack. We moeten natuurlijk waken voor de bekende aanvallen als *cross-site scripting* of een *man in the middle attack*. Maar wederom geldt: hoe aantrekkelijk zijn wij nou helemaal als doel om te cracken?
+
+In het verleden hebben mensen gefilosofeerd over LDAP als beveiliging voor de leden- en evenementenadministratie. Naar ons gevoel is dat overkill en veroorzaakt het nodeloos dataverkeer – dat natuurlijk ook weer doel zou kunnen zijn van een aanval.   
+
+Kortom, wij geloven dat er  niet méér nodig is dan lange wachtwoorden die goed versleuteld zijn en **binnen de database** beheerd worden. We geloven wèl in *security in layers*: een gewoon lid mag natuurlijk niet rechtstreeks bij de Tabel “password” kunnen komen, anders dan onder programma controle. Maar dat geldt ook voor bestuursleden. De uitzondering is, denken wij, alleen de database beheerder. En dus zullen we **rollen** moeten definiëren, met de bijbehorende privileges. De rollen en privileges zullen we nog verder moeten uitwerken. Ze vallen in grote lijnen natuurlijk samen met de rollen die we in Hoofdstuk 2 identifice
+
+Het uitgangspunt daarbij zijn het unieke personID en het unieke roleID. Die worden aan elkaar gekoppeld in een tabel "official" . En zo kan één lid  meerdere rollen op zich nemen - en dus ook meerdere sets privileges hebben. 
+
+Hoe houden we de database beheerder in het gareel? 
+
+## 4.6 Audit trail
+
+- De datum en tijd van de *laatste* login moet voor ieder lid (in het ledenrecord) bijgehouden worden. (Dus niet alle logins, dat is overkill.) Bij het inloggen worden datum en tijd van de vorige login getoond.
+- De datum en tijd van de laatste wijziging van het wachtwoord moet voor ieder lid (in het wachtwoordrecord) bijgehouden worden, ook als die wijziging door de ledenadministrateur is uitgevoerd.
+- Alle leden die (met een privilege) handelingen uitvoeren op de gegevens van andere leden worden gelogd. Dus toevoegen, wijzigen, verwijderen, inschrijven/uitschrijven voor een evenement, factuur cancelen enzovoorts. Dit log vormt een *audit trail*, zodat we bij problemen kunnen terugzoeken wie welke handeling verricht heeft. 
+- Omdat het log potentieel (bij voorbeeld bij forensisch onderzoek) door derden ingezien kan worden gebruiken we geen namen maar alleen LidDs, zowel voor het subject als voor het object. 
+- Dit log kan potentieel snel vollopen, dus er moet een automatisch proces (een cron job) komen dat log rotation kan uitvoeren. De gecomprimeerde oudere logs worden off-site bewaard, zodat ze veranderen bemoeilijkt wordt. 
+- Dit systeem biedt geen controle op de twee rollen die de database rechtstreeks kunnen benaderen: de ledenadministrateur en de database beheerder.  Daar moeten we een oplossing voor vinden.
+
+
+
+## 4.7 Compatibility
+
+De NLUUG stelt geen bijzondere compatibiliteits-eisen aan de software, afgezien van de eerder genoemde eis dat het programma wat betreft betalingen van facturen moet kunnen koppelen met onze bankgegevens, en liefst ook met een in de toekomst te gebruiken boekhoudpakket.
+
+Aan het eind van het leven van het programma moet de data relatief gemakkelijk te transponeren zijn naar wat we tegen die tijd voor pakket kiezen. Dat betekent dat we een een toekomstvast data formaat moeten eisen. (Hieronder stellen we een ANSI SQL compliant  formaat voor.)
+
+
+
+## 4.8 Maintainability	
+
+De ledenadministratie die de NLUUG thans gebruikt is ontwikkeld rond 2010, door de toenmalige ledenadministrateur. Die kon natuurlijk zijn zelfgebouwde systeem prima onderhouden en waar nodig uitbreiden. Maar sinds we in 2023 een nieuwe ledenadministrateur hebben is die automatische koppeling tussen de gebruiker en de programmeur verbroken. 
+
+We moeten ons al NLUUG realiseren dat, als we niet opnieuw kiezen voor ontwikkeling in eigen huis, het doorvoeren van wijzigingen in de ledenadministratie tijd en geld gaat kosten. We hebben als kleine organisatie waarschijnlijk niet de  hoogste prioriteit bij de leverancier. De kans is groot dat de NLUUG zich zal moeten voegen naar het pakket, en niet omgekeerd.
+
+Als we wel weer kiezen voor ontwikkeling in eigen huis zijn we wederom maximaal flexibel ... zolang de ontwikkelaars tijd en kennis en 'zin' hebben om het programma te onderhouden. In dat geval moeten we kiezen voor onderliggende software waarvoor we als organisatie voldoende kennis in huis hebben. Dat betekent mainstream pakketten. Om maar man en paard te noemen: natuurlijk "een" Linux dialect, een algemeen bekend en goed gedocumenteerd database management systeem (DBMS) en een algemeen bekende en goed gedocumenteerde programmeertaal, bijvoorbeeld Python of PHP.  Overigens geldt juist voor de database dat er keus genoeg is in Open Source oplossingen. (Een persoonlijke noot van Jan Sepp: Qua programmeertaal ben ik zelf altijd erg huiverig voor ontwikkelsystemen als Laravel of Jupyter Notebooks die een extra laag van abstractie én een extra laag van expertise én een extra laag van  incompatibiliteit met zich meebrengen.)
+
+Als we kiezen voor een bestaand Open Source pakket zullen er mensen moeten zijn die zich daarin willen verdiepen en die bereid zijn de software aan te passen naar onze wensen. Ook in dat geval moeten we ons realiseren dat de NLUUG zich zal moeten schikken in het keurslijf van de software en niet andersom.
+
+### 4.8.1 Conversie
+
+Het moet mogelijk zijn om te converteren vanaf de thans gebruikte ledenadministratie. Ik (Jan Sepp) heb een Proof of Concept geschreven dat de backup van de huidige ledenadministratie converteert naar de datastructuur  die beschreven staat in paragraaf 3. Dat werkt in grote lijnen goed, maar daarna is wel een dag *tweaken* noodzakelijk.  Dat programma vertaalt ook de LidIDs van de viercijferige code (p|s[0-9]{4})  naar een vijfcijferige code (p|s[0-9]{5}).
+
+Mocht de NLUUG beslissen voor een andere datastructuur dan moet daar een conversieprogramma voor geschreven worden. Dat zal in geen enkel geval een standaardoplossing zijn.
+
+## 4.9 Reliability
+
+Over de betrouwbaarheid van de toekomstige software kunnen we kort zijn: er mogen geen fouten optreden. We hebben met de huidige software té gemakkelijk te maken met doublures en ghost-accounts, dat moet in de toekomst vermeden worden. 
+
+## 4.10 Recoverability
+
+dus geen proprietary formaat. escrow?
+
+data en programmatuur uiteen houden. Data in een DBMS - en met de geëigende tools een backup maken en terug kunnen zetten. Programmatuur ...
+
+Uitwerken
+
+## 4.11 Availability
+
+### 4.11.1 geen hardware redundancy
+
+De ledenadministratie is bedrijfskritisch voor de NLUUG, maar de NLUUG kan best enkele uren of zelfs dagen zonder de ledenadministratie. We hebben geen behoefte aan dubbel uitgevoerde hardware. Beschikbaarheid van het programma van 20 x 6 is onder normale omstandigheden ruim voldoende.  (20 uur per dag, 6 dagen per week).
+
+### 4.11.2 back-ups
+
+Natuurlijk hebben we behoefte aan back-ups. Er moet een dagelijkse back-up van de database beschikbaar komen, die wordt opgeslagen op een een andere host (en liefst in een ander rekencentrum) dan waar het programma draait. De NLUUG moet binnen een termijn van enkele uren een back-up kunnen terugzetten (of laten terugzetten) .
+
+De leverancier van het programma moet het programma aantoonbaar onderhouden en moet een release en versie schema kunnen overleggen. Het programma moet na iedere wijziging een back-up krijgen. Het moet mogelijk zijn om terug te vallen op vorige versies, als nieuwe versies fouten bevatten. Een publieke GIT oplossing heeft onze voorkeur. 
+
+### 4.11.3 disaster recovery, RPO en RTO
+
+Gezien bovenstaande eisen voor redundancy en back-ups moeten we rekening houden met een Return Point Objective (RPO) van 24 uur: bij een crash mag maximaal de data die de afgelopen 24 uur is ingevoerd verloren gaan. Daarnaast willen we een Return Time Objective (RTO) van 48 uur: twee volle dagen na een crash van het systeem moet de ledenadministratie weer functioneel zijn. 
+
+We houden geen rekening met "echte" rampen: als half Nederland onder water staat of als de stroomvoorziening voor langere tijd uitvalt hebben we wel wat anders aan ons hoofd dan de NLUUG ledenadministratie. Wel moet na de opheffing van een noodtoestand de ledenadministratie opnieuw opgebouwd kunnen worden. Het RPO van 24 uur blijft daarbij een streven.
+
+## 4.12 Geen fault tolerancy, type DBMS
+
+De ledenadministratie is in onze ogen een eenvoudig kameralistisch programma. Er vinden geen "atomic" transacties in plaats en er is geen behoefte aan een afgedwongen methode van "fault tolerancy". 
+
+Kortom, een simpel RDBMS als MySQL Community Edition of MariaDB is voor de data-opslag voldoende. Meer màg (bijvoorbeeld ProgresSQL of Apache Derby), maar is niet nodig. SQLight is te licht voor de hoeveelheid tabellen en interfaces die we voorzien. 
+
+NoSQL databases (bijvoorbeeld MongoDB) lijken minder van toepassing, omdat de leden-gegevens sterk gestructureerd zijn. We zien in het huidige NoSQL database systeem dan ook zeer veel data redundancy  optreden, met alle gevolgen voor fouten van dien.
+
+
+
+## 4.13 Kosten
+
+Wat willen we uitgeven aan een ledenadministratie systeem? Eenmalig? Als abonnement? Uitwerken.
+
+
+
+
+
+
+
+
+
+# 5 Hoe verder?
+
+We stellen voor deze requirements eerst binnen de NLUUG te bespreken en scherper te stellen. Op grond daarvan kunnen we dan een leveranciersselectie starten.