Medlemsdatabase/kravspesifikasjon

Se også Medlemsdatabase.

Denne artikkelen tar for seg krav til funksjonalitet for et medlemsdatabasesystem.

Grunnleggende mål

Gjennom en sentral medlemsdatabase ønsker vi:

• unngå manuelt arbeid, i den grad det er mulig
• gjøre det enkelt for folk å bli medlem
• Ha én sentral, autorativ database for brukerkonti til alt av verktøy

Sikkerhet og risiki

Kompromitering vs brukervennlighet

Medlemsregisteret inneholder konfidensielle opplysninger, det er svært viktig at medlemsregisteret er godt sikret mot spionasje, lekkasje og publisering.

Samtidig må f.eks. sekretariatet og lokallagsstyrene ikke bli hindret i å få tak i den informasjonen de trenger, raskt og effektivt, samt ha verktøy for å vedlikeholde informasjonen.

Informasjonstap

Medlemsregisteret er også noe av det mest verdifulle vi har i organisasjonen, og vi ønsker ikke å måtte be medlemmene om å registrere seg på nytt igjen, eller fylle inn manglende data etter registrering.

Det er essensielt at vi har gode backuprutiner.

Det er essensielt at vi unngår produktinnlåsing. Det skal for alle praktiske formål være lett å få ut databasen dersom vi bytter systemer.

Det er essensielt at vi har sånn nogenlunde kontroll på hvilke data vi skal be om før vi produksjonssetter systemet, slik at vi slipper å be medlemmene registrere flere opplysninger senere.

Udokumentert spaghetti, personavhengigheter

Vi må ikke ende opp med en registerløsning som er for obskur, for kompleks, for lite dokumentert. Det skal ikke være slik at vidreutvikling, vedlikehold eller avvikling avhenger av at bestemte personer (eller bestemte tredjepartsfirmaer) tar tak.

Lover og regler

Det er viktig å se til at alle lover og regler mtp personvern er oppfylt.

Det er et skille mellom personer med verv/roller og "vanlige medlemmer"; vanlige medlemmer er underlagt beskyttelse fra personvernloven, mens folkevalgtes opplysninger er av en mer offentlig karakter.

Ifølge partiloven og partilovforskriften skal personer som registreres som medlem av det utøvende organ og kontaktperson registeres, inneholdende opplysning om navn, bostedsadresse og fødselsnummer eller D-nummer. For øvrige medlem skal det kun lagres nødvendig informasjon for å gjennomføre det nødvendige arbeidet. Ved årets begynnelse og slutt skal det opplyses om partiets årsverk til SSB. Ved utmeldelse fra Partiet skal personopplysningene slettes så fort som mulig, dersom det ikke er juridisk grunnlag for å holde ved informasjonen over lengre tid. Informasjonen samlet inn skal arkiveres i henhold til reglement, men er også underlagt personvernloven. Antall betalende medlemmer ved årets begynnelse og slutt skal bokføres.

GDPR må også vurderes.

Medlemsdatabase som aldri blir produksjonsklart

Arbeidsgruppa som jobber med prosjektet må ha klare mål og klare tidsfrister å forholde seg til. Man må evaluere prosjektet regelmessig, og dersom det drar ut og prosjektet aldri blir klart til å produksjonssettes, så er det essensielt at man ser på muligheten for å reboote prosjektet og starte fra scratch med en ny gruppe.

Prosjektet behøver imidlertid ikke være noe som blir bygd i ett stykke og helt ferdigstilt før produksjonssetting; så lenge sikkerheten og stabiliteten er god nok må man gjerne ha delmål som produksjonssettes fortløpende. Erfaringsmessig er risikoen for at et prosjekt går galt stor dersom man satser på å først jobbe lenge med utvikling og ferdigstille et større prosjekt før det rulles ut i produksjon, ref "The Cathedral and the Bazaar".

Medlemsdatabaseprosjektet har ligget brakk siden juletider 2015 og frem til 5. ordinære landsmøte pga mangel av motivasjon i kjølvannet av møte med generalsekretæren i oktober 2015.

Medlemsdatabase som blir satt i produksjon uten å være produksjonsklart

Vi trenger gode rutiner og automatiserte prossesser for å testing, vi trenger å ha på plass rutiner og metoder for å avdekke feil og begrense risikoen for feil.

Risikoen kan ikke elimineres, den eneste kostnadseffektive måten å finne feil på kan av og til være å produksjonssette produktet, men det er særlig viktig å sikre at eventuelle feil ikke har sikkerhetsmessige konsekvenser.

Potensielle medlemmer

• Potensielle medlemmer må kunne registrere personopplysninger om seg selv via piratpartiets websider.
• Det må være mulig å betale første medlemskontingent vha bitcoins
• Det bør være mulig å betale første medlemskontingent online via andre betalingsløsninger (f.eks. kredittkort)
• Det må være mulig å bestille en faktura slik at medlemskontingenten kan betales per bank
• Personopplysninger bør verifiseres (fysisk adresse og fødselsdato mot folkeregisteret, man bør få bekreftet at vedkommende har tilgang til den oppgitte epostadressen)

Medlemmer

Medlemmer bør ha mulighet til å:

• verifisere egne personopplysninger, f.eks. vha en innloggingstjeneste eller ved å bestille "utskrift" på epost.
• oppdatere egne personopplysninger, f.eks. vha en innloggingstjeneste, en knapp for å hente ny adresse fra folkeregisteret, e.l.
• betale kontingent
• melde seg ut

Alle

Alle skal kunne registrere en konto. Registeret skal ikke bare være et medlemsregister, men skal også være en sentral brukerdatabase for alle verktøy vi setter opp. Det vil være behov for å registrere konti også på folk som ikke har noe ønske om å være medlem, f.eks. folk som ønsker å kjøpe ting fra butikken, donere penger, det kan tenkes at vi ønsker å ansatte ikke-medlemmer, disse må da få de tilgangene de trenger, etc.

Alle donasjoner må regnskapsføres, med fullt navn på den som donerer. Det gir mening å håndtere donasjoner og medlemskontingent i samme system.

Det må være mulig å få opp informasjon om hvem som sitter i sentralstyre, lokallagsstyre, samt personer med andre viktige verv.

Sekretariatet

Generalsekretær og minst ett sentralstyremedlem må ha mulighet til å hente ut opplysninger fra medlemsdatabasen samt oppdatere opplysninger, helst gjennom et enkelt webgrensesnitt.

Regnskap må ha god tilgang til regnskapstallene, helst bør det være noe slags integrasjon mellom betalingsløsningen og regnskapssystemet.

Nøkkelpersoner i lokallagene bør få tilgang til å hente ut og oppdatere opplysninger om sine lokale medlemmer.

Tech

Databasen må være i et lett tilgjengelig format slik at tech enkelt kan integrere nye tjenester mot medlemsdatabasen.

Andre integrasjoner

• Zimbra mailinglister må autooppdateres på bakgrunn av medlemsdatabasen
• Vi trenger systemer for "Single Sign-On" (f.eks. OpenID og/eller LDAP), det bør ikke være nødvendig å opprette brukerkonti på alt vi har av tjenester, alt av tilganger bør være direkte styrt fra medlemsdatabasen.
• Bank - kontingenter innbetalt over bank bør registreres automatisk. Adresseinformasjon bør sjekkes.
• Websidene skal vise sanntidsoppdatert informasjon om antall medlemmer
• Eksisterende database må kunne importeres lett, dersom vi bytter databasestruktur

Informasjon som skal lagres

• Medlemsnummer
• Fornavn
• Etternavn
• Epost
• Adresse
• Postnummer
• Poststed (kan finnes vha postnummer)
• Kommune (bydel, for de som bor i Oslo) (kan finnes vha postnummer)
• Fylke (kan finnes vha kommune)
• Andre fylkeslagtilknytninger (f.eks., en student kan ha folkeregistrert adresse i hjemstedskommunen, men ønsker å bli oppdatert om ting som skjer i studiefylket)
• Fødselsår (frivillig - nødvendig dersom man ønsker å stå på valglister)
• Fødselsdato (frivillig - nødvendig dersom man ønsker å stå på valglister)
• Valglistekandidatur (indikerer om medlemmet ønsker å være med på valglister)
• Verv (for integrasjon mot mailinglister, websider og wiki - kan kun endres av sekretæriatet)
• Ønsket mengde epost - på en skala fra "absolutt ingen masseutsendte eposter" til "send meg mail så ofte som mulig".
• Innmeldingsdato
• Siste dato for innbetalt kontingent. TODO: uavklart spørsmål: Skal vi lagre historikk over innbetalte kontingenter, eller skal vi bare lagre dato og varighet for sist innbetalte kontingent?

Dette skal fortrinnsvis lagres i en tradisjonel relasjonsdatabase. De fleste feltene over kan være i én og samme tabell, unntakene er spesifisert nedenfor.

Adresse

Addresser kan, men må ikke nødvendigvis lagres i en separat tabell. Informasjonen som kan utledes fra postnummer kan være lagret i en separat tabell; denne tabellen bør i såfall autooppdateres ut fra eksterne databaser.

Andre fylkeslagstilhørigheter - her er det først og fremst snakk om folk som av ulike grunner ønsker å være aktiv i et annet lokallag enn det laget de har folkeregistrert tilknytning til. TODO skal vi tillate flere verdier her, eller skal det bare være tillatt å være med i ett lokallag?

Valglistekandidatur

Man kunne hatt to felter her, ett for stortingsvalg og ett for lokalvalg, men for å holde det enkelt foreslås det å bare ha ett felt her. Utarbeiding av valglister vil trolig aldri bli noen helautomatisert prossess uansett, kandidatene fortjener å bli spurt i forkant og fortjener å få tilbakemelding når listen er levert inn, uavhengig av hva de har valgt her.

Feltet foreslås å være et heltall f.eks. mellom 0 og 256, og gjerne med en korresponderende tabell med tekstfelter, f.eks. slik som dette:

• 8 - jeg ønsker ikke under noen omstendighet å stå på piratpartiets valglister
• 64 - jeg ønsker helst ikke å stille på piratpartiets valglister, men har ikke noe imot å bli spurt
• 96 - før meg gjerne opp på valglister, men da fortrinnsvis så nært bunnen på lista som mulig
• 200 - jeg ønsker en prominent plassering på valglister

(Tabellen med tekstfelter må gjerne ha en boolean for å indikere om en tekststreng er aktuell eller historisk. Med å ha tomrom i nummerrekka kan vi i ettertid redigere lista uten å forkaste de historiske formuleringene, samt fortsatt beholde riktig sortert.

Verv

Verv er en komplisert greie som ikke bare kan løses vha et fritekstfelt i databasen.

Det er det tre forskjellige funksjonaliteter som er tilknyttet "verv": hente ut offentlige lister, styre epostlister og styre rettigheter/tilganger (til IT-systemer o.l.)

Pyntlige lister over hvem som innehar verv: Her bør vi tenke litt bredt, kandidatur på en valgliste er vel også et slags form for "verv", det samme dersom man faktisk representerer partiet i styrende organer.

Tilganger til IT-systemer o.l.: Her bør vi ha det såpass velorganisert at det holder å registrere at et medlem har blitt lokallagsleder, og dermed har medlemmet automatisk tilgang til å sende ut mail til lokallagsmedlemmer samt tilgang til å vise og redigere medlemsdatabasen over lokale medlemmer. På den andre siden må systemet være såpass fleksibelt at man - midlertidig eller permanent - kan fjerne tilganger eller gi ekstra tilganger uavhengig av funksjonaliteten nevnt over.

TODO dette må tenkes mer igjennom og spesifiseres bedre

Annet

Se også verktøyegenskaper.

Vi trenger ikke en programvarepakke som kan løse alle problemene, medlemsdatabasesystemet kan gjerne være satt sammen av flere småverktøy som deler en felles database.