[Taak] Valideren van non-functionele eisen voor component Referentiearchitectuur

[markbacker]

Sprint

Sprint 3

Beschrijving

Valideren of de component Referentiearchitectuur voldoet aan de in het PvE gestelde non-functional eisen.

Niet alle eisen zijn voor alle componenten relevant

Checklist

Toegankelijkheid

• 102 - Feedback na fout
  • Als gebruiker wil ik op een juiste manier geïnformeerd worden door het systeem wanneer er een fout optreedt en wat de oorzaak hier van is, zodat ik op basis van deze informatie de juiste actie kan inzetten. (Eis)

Betrouwbaarheid

• 87 - Beheerorganisatie
  • De Leverancier borgt dat altijd binnen 2 kalenderdagen en tegen marktconforme tarieven expertise beschikbaar is voor ondersteuning bij onder meer het voorbereiden van een mogelijk wijzigingsverzoek (Wens)

Werkwijze

• 103 - Testen
  • De opgeleverde software wordt door de ontwikkelpartij eerst getest volledig getest, zodat bij oplevering alle (eerder) ontwikkelde functionaliteit werkt. (Eis)

Overdraagbaarheid

• 99 - Aanpasbaarheid Softwareplatform
  • De Softwarecatalogus wordt gerealiseerd met open source software componenten
  • De gebruikte ‘technologie stack’ bestaat uit gangbare componenten met een levendige community
  • Er wordt altijd gebruik gemaakt van door de community supported versies. (Wens)
• 101 - OTAP omgeving
  • Voor de softwarecatalogus is een ontwikkel, test, acceptatie en productie-omgeving (OTAP) ingericht waarbij VNG en gemeenten toegang hebben tot de acceptatie en productieomgeving. (Eis)
• 100 - Installeerbaarheid
  • Componenten zijn out-of-the-box geschikt voor installatie binnen een gestandaardiseerde (cloud-)infrastructuur platform (bijvoorbeeld Haven[1]).
  • De componenten zijn geautomatiseerd te testen en deployen middels een CI/CD pipeline
  • Het doorlopen van de pipeline duurt max 1 uur
  • De voorziening dient als container op (bijvoorbeeld een kubernetes) infrastructuur te kunnen worden gedeployed (Eis)

Bruikbaarheid

• 88 - Gebruikersvriendelijk
  • De gebruikersinterface moet intuïtief en eenvoudig te gebruiken zijn, zodat gebruikers zonder uitgebreide training of technische kennis zelfstandig kunnen navigeren en taken uitvoeren. Het ontwerp moet consistent zijn met gangbare UX-principes, met duidelijke visuele feedback en logische workflows, en mag geen onnodige complexiteit bevatten. Voorkomen gebruikersfouten
  • De Softwarecatalogus valideert de invoer van metadata
  • Bij fouten worden aanwijzingen gegeven hoe de fout hersteld kan worden (Eis)
• 89 - Toegankelijkheid
  • De softwarecatalogus voldoet aan de eisen van digitoegankelijk (https://www.digitoegankelijk.nl/) (Eis)

Informatiemodel

• 93 - Gebruik informatiemodel voorzieningencatalogus
  • De Softwarecatalogus en de Softwarecatalogus API worden gebaseerd op het informatiemodel voorzieningencatalogus (Eis)

Onderhoudbaarheid

• 95 - Herbruikbaarheid
  • Herbruikbaarheid
  • De broncode van (maatwerk)componenten is beschikbaar als open source software met een EUPL-licentie.
  • De broncode is goed gedocumenteerd
  • De broncode wordt beheerd in een git-repository van VNG Realisatie (Eis)
• 96 - Modulariteit
  • Proceslogica en bedrijfsregels zijn los van elkaar en los van de interactie naar gebruikers instelbaar. (Eis)
• 98 - Techniek toekomstvast
  • De techniek (programmeertaal, packages, tooling) die gebruikt wordt voor de ontwikkeling van de nieuwe softwarecatalogus, is toekomstvast. Er zijn in Nederland minimaal 100 ontwikkelaars die deze tooling gebruikt en hier kennis van heeft (Eis)
• 97 - Webstatistieken
  • Als functioneel beheerder wil ik inzicht in het gebruik van de softwarecatalogus door middel van een open source en confrom privacy omgeving ingericht webstatistiekenpakket, zoals Matomo. (Eis)

Informatiebeveiliging

• 90 - Logging activiteiten
  • Inschrijver borgt dat alle activiteiten, ook die van Eindgebruikers en Beheerders worden vastgelegd in audit-/ logbestanden. Dit zodanig beveiligd dat deze bestanden niet zomaar kunnen worden ingezien, gewijzigd of verwijderd door hiertoe niet bevoegd personeel Inschrijver borgt dat een logregel minimaal het volgende bevat:
    1. Waar mogelijk een tot een natuurlijke persoon herleidbare identificatie.
    2. Waar mogelijk de identiteit van het werkstation of de locatie.
    3. Het object waar de handeling op werd uitgevoerd.
    4. Het resultaat van de handeling.
    5. De gebeurtenis.
    6. De datum en het tijdstip van de gebeurtenis. (Wens)
• 91 - nl.internet standaarden
  • De site softwarecatalogus.nl gebruikt alle door https://nl.internet.nl/ geteste internetstandaarden op de juiste manier. In de nl.internet.nl websitetest scoort de domeinnaam Softwarecatalogus.nl 100%. (Eis)
• 92 - Toegangsbeveiliging
  • Voor het beheren van gegevens hebben alleen geautoriseerde gebruikers toegang tot de Softwarecatalogus Inloggen met 2 factor authenticatie
  • Een username, password (iets weten)
  • Een (TOTP) token, gegenereerd met een app op eigen telefoon of laptop (iets hebben) Ondersteuning voor role based access control.
  • Beheerders krijgen toegang tot de beheerschermen op basis van een rol én een organisatie Mogelijke rollen zijn bijvoorbeeld: Aanbod- en gebruik-beheerder, Ciso, … (Eis)

Standaarden

• 86 - NL API strategie standaarden
  • We ontwikkelen API-first in lijn met de NL API strategie en de recent gepubliceerde API standaarden bij het forum standaardisatie.
  • Dit zijn de OpenAPI Specification (https://www.forumstandaardisatie.nl/open-standaarden/openapi-specification) en
  • de REST-API Design Rules (https://www.forumstandaardisatie.nl/open-standaarden/rest-api-design-rules). (Eis)
• 94 - e-mail standaarden
  • De standaarden DKIM en DMARC zijn vereist voor het versturen van e-mails. Bijvoorbeeld voor het ondersteunen van het proces voor als je je wachtwoord bent vergeten
  • DKIM faciliteert van het vaststellen van organisatorische herkomst voor e-mail afkomstig van overheidsdomeinen, als deze over een onbeveiligde, publieke internetverbinding wordt verstuurd wanneer verdere authenticatie ontbreekt. - DMARC is een standaard die het voor organisaties mogelijk maakt om te bepalen hoe e-mailproviders, omgaan met e-mail waarvan niet kan worden vastgesteld dat deze afkomstig is van het eigen domein. Hierdoor kunnen organisaties voorkomen dat anderen e-mails versturen namens het e-maildomein van de organisatie. (Eis)

[github-actions]

Bedankt voor het aanmaken van deze issue! 👋

Voor meer informatie over onze spelregels voor het schrijven van issues, bekijk alsjeblieft onze issues.md documentatie.

Belangrijke punten om te controleren:

• ✍️ Is de beschrijving helder en compleet?
• 📋 Zijn er duidelijke acceptatiecriteria toegevoegd?
• 🎯 Is de context voldoende beschreven?