Requirements

Functional Requirements

Een functionele eis beschrijft een handeling die het product moet uitvoeren om nuttig te zijn voor de gebruiker — deze eisen komen voort uit het werk dat je stakeholders moeten doen.

• Dingen die het product moet doen
• Specificeert wat het systeem moet doen
• Handelingen die het product moet uitvoeren
• Afgeleid van het hoofddoel van het product
• Geen kwaliteitseigenschap
• Wordt gekenmerkt door werkwoorden

Voorbeelden

• Het systeem moet gebruikers laten inloggen met e‑mail en wachtwoord.
• Het systeem moet een bevestigingsmail sturen na elke bestelling.
• De gebruiker moet producten kunnen zoeken op naam en categorie.
• Het systeem moet maandelijkse rapportages genereren in PDF‑formaat.
• De applicatie moet betalingen kunnen verwerken via Uni5Pay+ en creditcard.
• De student moet zijn cijfers online kunnen raadplegen.

Non-functional Requirements

Niet-functionele eisen zijn eigenschappen of kwaliteiten die het product moet hebben om acceptabel te zijn voor de eigenaar en gebruiker.

• In sommige gevallen zijn niet-functionele eisen — zoals performance, look-and-feel, usability, security en juridische eigenschappen — cruciaal voor het succes van het product.
• Soms zijn het eisen omdat ze het product verbeteren of aantrekkelijker maken.
• Soms zorgen ze ervoor dat het product bruikbaar is.
• Eigenschappen of kwaliteiten die het systeem moet hebben.
• Worden gekenmerkt door bijvoeglijke naamwoorden.
• Checklist:
  • Look-and-feel
  • usability
  • performance
  • onderhoudbaarheid
  • portabiliteit

Voorbeelden

• De website moet binnen 2 seconden laden bij normaal gebruik. (performance)
• Het systeem moet 24/7 beschikbaar zijn met een uptime van minimaal 99,5%. (betrouwbaarheid)
• De gebruikersinterface moet intuïtief en eenvoudig te gebruiken zijn zonder training. (usability)
• Gevoelige gegevens moeten versleuteld worden opgeslagen volgens de ISO richtlijnen. (security, juridisch)
• De applicatie moet onderhoudbaar zijn zodat een ontwikkelaar in < 1 dag een eenvoudige wijziging kan doorvoeren. (onderhoudbaarheid)
• De oplossing moet op zowel mobiele apparaten als desktop goed werken. (portabiliteit / compatibiliteit)

Casus 1

Een buurtbewoner van het district Wanica dient een bewijs van goed gedrag te overleggen voor de aanvraag van een visum. Hij vraagt dit aan bij zijn districtscommissariaat met de vereiste documenten, zoals een ID kaart en een nationaliteitsverklaring. Na de aanvraag kan hij het bewijs na weken persoonlijk ophalen indien goedgekeurd en tegen een specifieke betaling.

Het bovenstaande zal in de toekomst via een website aangevraagd worden. Hij kan de aanvraag online doen en tevens online betalen. Na de online betaling ontvangt hij een bevestiging van de bestelling op zijn ingevulde e-mailadres of mobiele nummer.

Uitwerking

Functionele Eisen

• FR-01 Digitaal Aanvraagformulier: De burger moet online persoonsgegevens kunnen invullen (Naam, Adres in Wanica, Geboortedatum).
• FR-02 Document Upload: De gebruiker moet digitale kopieën van de vereiste documenten (ID-kaart en Nationaliteitsverklaring) kunnen uploaden.
• FR-03 Online Betaling: Het systeem moet een koppeling hebben met een betaalprovider (bijv. lokale banken of wallets) om de specifieke leges direct te voldoen.
• FR-04 Keuze Notificatie: De gebruiker moet kunnen kiezen of de bevestiging via e-mail of via SMS (mobiel nummer) verstuurd wordt.
• FR-05 Orderbevestiging: Na succesvolle betaling moet het systeem automatisch een bevestigingsbericht sturen naar het opgegeven contactadres.
• FR-06 Genereren Ordernummer: Het systeem moet een uniek order-/aanvraagnummer genereren waaraan de betaling en de documenten gekoppeld zijn.
• FR-07 Backoffice Inzage: Medewerkers van het districtscommissariaat Wanica moeten binnengekomen aanvragen inclusief geüploade documenten kunnen inzien.
• FR-08 Betaalstatus Verificatie: Het systeem moet real-time feedback geven aan de gebruiker of de transactie geslaagd of mislukt is.
• FR-09 Validatie Invoer: Het systeem moet controleren of alle verplichte velden zijn ingevuld en of er bestanden zijn geselecteerd voordat de betaling start.
• FR-10 Kwitantie Generatie: De gebruiker moet na betaling een digitaal betalingsbewijs (kwitantie) kunnen downloaden of inzien.

Niet-functionele eisen

• NFR-01 Security (Transacties): De online betalingen moeten voldoen aan strenge veiligheidsstandaarden (zoals PCI-DSS richtlijnen) om fraude te voorkomen.
• NFR-02 Security (Data): De geüploade documenten (ID-kaarten) moeten versleuteld worden opgeslagen (AES-256 encryptie) ivm privacygevoeligheid.
• NFR-03 Mobile Friendly: De aanvraag- en betaalpagina moeten volledig responsive zijn, zodat bewoners via hun smartphone de aanvraag kunnen doen.
• NFR-04 Bestandsgrootte: Het systeem moet uploads accepteren tot maximaal 5MB per bestand om de serverbelasting te beperken.
• NFR-05 Bestandsformaten: Het systeem moet gangbare formaten ondersteunen zoals JPG, PNG en PDF (omdat veel mensen foto’s maken met hun telefoon).
• NFR-06 Beschikbaarheid: De aanvraagmodule moet 24/7 beschikbaar zijn, zodat burgers niet gebonden zijn aan de openingstijden van het commissariaat.
• NFR-07 Snelheid (Notificatie): De bevestigingsmail of SMS moet binnen 1 minuut na de succesvolle betaling verstuurd zijn.
• NFR-08 Gebruiksvriendelijkheid: Het formulier moet zo ontworpen zijn dat het invullen maximaal 5 minuten kost (minimale klikken).
• NFR-09 Browser Compatibiliteit: De website moet werken op de meest gebruikte mobiele browsers in Suriname (Chrome Android, Safari iOS).
• NFR-10 Data Retentie: De tijdelijke aanvraagdata moet conform wetgeving bewaard blijven, maar betaalgegevens mogen niet onnodig lang worden opgeslagen.

MoSCoW

Must have (Essentieel)

• FR-01 (Digitaal Aanvraagformulier)
• FR-02 (Document Upload)
• FR-03 (Online Betaling)
• FR-05 (Orderbevestiging - Cruciaal bewijs voor de burger)
• FR-06 (Genereren Ordernummer)
• FR-07 (Backoffice Inzage - Anders kan de ambtenaar niks verwerken)
• NFR-01 (Security Transacties)
• NFR-02 (Security Data)
• NFR-03 (Mobile Friendly)

Should have (Belangrijk, maar niet cruciaal)

• FR-04 (Keuze Notificatie SMS/Email - Alleen email is voor MVP acceptabel als SMS technisch lastig is, maar de casus noemt beide)
• FR-08 (Real-time Betaalstatus - Feedback is belangrijk voor vertrouwen)
• FR-09 (Validatie Invoer - Voorkomt foutieve aanvragen)
• NFR-05 (Ondersteuning JPG/PNG - Cruciaal voor mobiele gebruikers)
• NFR-07 (Snelheid Notificatie)

Could have (Leuk om te hebben)

• FR-10 (Kwitantie Generatie - De bevestigingsmail kan ook dienen als kwitantie in fase 1)
• NFR-08 (Gebruiksvriendelijkheid < 5 min - Optimalisatie slag)

Won’t Have (Voor nu buiten scope)

• FR-11 Automatische goedkeuring van het gedrag (dit blijft mensenwerk bij justitie/politie).
• FR-12 Thuisbezorging van het fysieke document (casus zegt: “ontvangt bevestiging van bestelling”, het fysieke ophalen/verwerken blijft voorlopig impliciet).