NF. Niet-functionele vereisten Dit deel beschrijft de niet-functionele vereisten voor de oplossing. Ze worden opgedeeld in: NF-SL. Service level agreement NF-HO. Hosting en software NF-MO. Monitoring NF-SE. Servicedesk NF- CH. Change en...




Digitaal Podium Ticketingsysteem - NF. Niet-functionele vereisten 15
______________________________________________________________________

NF. Niet-functionele vereisten

Dit deel beschrijft de niet-functionele vereisten voor de oplossing. Ze worden opgedeeld in:

  • NF-SL. Service level agreement

  • NF-HO. Hosting en software

  • NF-MO. Monitoring

  • NF-SE. Servicedesk

  • NF-CH. Change en releasemanagement

  • NF-AC. Toegangsbeheer

  • NF-US. User interface.


Elk hoofdstuk is gelijkaardig opgebouwd:

  • Visie: we lichten onze visie op Digitaal Podium toe

  • Vereisten: vereisten waarbij de dienstverlener in het Antwoordformulier Vereisten en Projecten dient aan te geven of de vereisten nu beschikbaar (1 of 0) zijn in de oplossing, zullen worden ontwikkeld in de oplossing (1 of 0) of dat de kandidaat de vereiste niet opportuun acht (1 of 0). Bij ontwikkelingen dient te worden aangegeven in welke fase (1,2,3,4) de functionaliteit wordt verwacht. Ter verduidelijking kan ook worden verwezen naar een ontwikkelplan of een korte opmerking worden geformuleerd.

  • Kwaliteit van de oplossing: open vragen waar de dienstverlener de kwaliteit van de oplossing of de toekomstige oplossing kan aantonen


In het Antwoordformulier Prijsopgave vragen we om de specifieke kosten per hoofdstuk of deel aan te geven.

In het antwoord op Planning en projectaanpak vragen we om de specifieke planning per hoofdstuk of deel aan te geven voor iedere fase.


(Antwoordformulieren Prijsopgave, Planning en projectaanpak en Vereisten en projecten - in cursief in de tekst - zijn heel specifiek voor de aanbestedingsprocedure Digitaal Podium en weinig relevant als voorbeeld of model, voor meer info neem gerust contact op met xxxxx.xxxx@xxxxxxxxxxxxxx.xx)








NF-SL. Service level agreement

NF-SL-VI. Visie

De aanbestedende dienst is op zoek naar een langetermijnpartner die niet enkel een uitstekende oplossing kan leveren, maar ook diensten op hoog niveau, opleiding en support kan bieden. We verwachten van onze partner(s) dat ze proactief reageren op de behoeften en voorstellen van de klant. Zowel de oplossing als de dienstverlener moeten ook klaar zijn om migraties te ondersteunen en het geboden serviceniveau tijdens een migratie op een productieomgeving te blijven ondersteunen.

NF-SL-MI. Vereisten

1. De dienstverlener voorziet een service level agreement (SLA):

a. dat ten minste voldoet aan de vereisten in dit document.

b. waarin rekening wordt gehouden met de mogelijke groei van het aantal aangesloten kunst- en cultuurhuizen op termijn.

2. De SLA biedt inzicht in de geleverde diensten, hoe de diensten worden gegarandeerd en hoe er verantwoording voor wordt afgelegd.

3. De SLA beschrijft de diensten aan de hand van key performance indicators (KPI’s). Voor iedere key performance indicator is duidelijk:

a. wat de definitie is

b. wat de referentiewaarde is

c. wat de meetmethode is

d. wie aansprakelijk is

e. hoe de rapportage geschiedt

x. xxx de evaluatie geschiedt

4. Elke maand wordt door de dienstverlener een SLA-rapport opgesteld en per kwartaal wordt een SLA-servicemeeting georganiseerd. Het rapport wordt elke eerste week van de maand ingediend.

NF-SE-QU. Kwaliteit van de oplossing

1. Stel een service level agreement (SLA) voor gebaseerd op NF-SL, NF-HO, NF-MO, NF-SE, NF-CH, NF-AC en NF-US met duidelijke key performance indicators en duidelijke escalatieprocedures.

2. Toon aan hoe de oplossing beantwoordt aan de doelen van SLA’s met andere referentie-implementaties. Neem een SLA-rapport op in bijlage.



NF-HO. Hosting en software

NF-HO-VI. Visie

De oplossing zal een groep van kunst- en cultuurhuizen en diens medewerkers en klanten moeten ondersteunen. Ze zal in eerste instantie moeten voorzien in een aanbod van 5.000 evenementen en de verkoop van ongeveer 150.000 tickets per jaar per pilootgroep, met uitstekende prestaties en ruimte voor groei in de toekomst. Duizenden klanten en tientallen medewerkers verwachten een hoge beschikbaarheid en snelle responstijd van het systeem.


Als er toch fouten optreden, dient de dienstverlener ze snel en nauwkeurig op te lossen. De oplossing dient voldoende beveiligd te zijn om gegevens te beschermen tegen ongeoorloofde toegang en diefstal en dient een mechanisme te bieden voor back-up en herstel van gegevens. Het systeem dient ook te draaien in een hosting omgeving die het mogelijk maakt om bijkomende kunst- en cultuurhuizen op het systeem aan te sluiten.


Verder dient de software-architectuur van het systeem voldoende open te zijn om in de toekomst vernieuwingen door te voeren en het systeem te verbinden met andere toepassingen.

NF-HO-MI. Vereisten

1. De hosting van de oplossing voldoet aan state of the art technologie volgens moderne normen. Dat betekent dat ze betrouwbaar (beschikbaar en herstelbaar), schaalbaar, veilig, onderhoudbaar en performant is en beschikt over uitstekende technische ondersteuning en klantenservice.

2. De oplossing wordt in een cloud gehost.

3. De oplossing wordt in een datacenter in Europa gehost.

4. De provider van het datacenter beschikt over een ISO-27001-certificaat of gelijkwaardig.

5. Naast de productieomgeving worden afzonderlijke omgevingen gebruikt om de ontwikkeling en het testen van software en het opleiden van personeel te ondersteunen. Alle omgevingen worden frequent gesynchroniseerd met de productieomgeving.

6. De software van de oplossing voldoet aan state of the art technologie volgens moderne normen. Dat betekent dat ze betrouwbaar (beschikbaar en herstelbaar), veilig, schaalbaar, onderhoudbaar en performant is en beschikt over uitstekende technische ondersteuning en klantenservice.

7. De software kan communiceren met randapparaten zoals ticketprinters, scanners en betaalterminals.

8. De oplossing is betrouwbaar doordat ze voldoet aan de volgende beschikbaarheidsvereisten:

a. De oplossing is tijdens de openingsuren van kunst- en cultuurhuizen (alle dagen van 8-24u) 99,8% van de tijd beschikbaar.

b. Daarbuiten is de oplossing 99,5% van de tijd beschikbaar.

c. Geplande onderbrekingen dienen minstens 7 dagen op voorhand te worden meegedeeld en mogen niet tijdens de openingsuren van kunst- en cultuurhuizen vallen.

9. De oplossing is betrouwbaar (reliable) doordat ze volledig herstelbaar is (bv. dankzij dagelijkse back-ups).

10. De oplossing is schaalbaar (scalable): ze kan goed blijven functioneren en voldoen aan de vereisten van het project ook wanneer de omvang of het volume ervan (of van haar context) wordt gewijzigd.

11. De oplossing is veilig (secure); ze wordt zowel fysiek als digitaal beveiligd tegen ongeoorloofde toegang. De opdrachtgever heeft het recht een security audit uit te voeren.

12. De oplossing kan worden onderhouden (maintainable): ze is modulair genoeg om eenvoudig te worden onderhouden en voortdurend te worden verbeterd.

13. De oplossing is performant en efficiënt (performance efficient). De responstijd van de oplossing is voor 95% van alle acties maximaal 3 seconden.

NF-HO-QU. Kwaliteit van de oplossing

Algemeen

1. Beschrijf de voorgestelde hosting oplossing tijdens de verschillende fasen van het project.

2. Beschrijf de complete technologiestack van de software.

Browsertoepassing

3. Beschrijf hoe de interactie tussen de gebruikers en de oplossing verloopt. Beschrijf alle systeemvereisten voor de toepassing (bv. besturingssysteem, CPU, geheugen, schijfruimte). In welke browsers en browserversies draait de toepassing?

4. Beschrijf hoe de toepassing communiceert met randapparaten zoals ticketprinters, barcodescanners, betaalterminals ... Hoe ondersteun je de installatie van de randapparaten?

Betrouwbaarheid

5. Beschrijf welk soort geplande downtime of ‘quiet time’ de oplossing vereist en vermeld daarbij de frequentie, de duur en het doel.

6. Beschrijf hoe de oplossing business disruption minimaliseert en de beschikbaarheid van het systeem maximaliseert. Welk soort uptime biedt de oplossing doorgaans? Wat zijn de grootste risico’s die de oplossing inhoudt, op het gebied van beschikbaarheid (bv. stroomonderbrekingen, netwerkstoringen, gegevensbeschadiging, softwarefouten, afhankelijkheid van externe partners) en hoe worden deze risico’s beperkt? Geef voorbeelden van grote storingen die zich hebben voorgedaan, hoe lang ze duurden en hoe je ze hebt opgelost.

7. Beschrijf hoe de oplossing tijdens verschillende perioden omgaat met pieken in de werkbelasting. Wat zijn de typisch pieken in de werkbelasting?

Schaalbaarheid

8. Hoe kunt u aantonen dat de hardware en software schaalbaar zijn en hoe kunt u garanderen dat het mogelijk is om de oplossing met zo weinig downtime mogelijk omhoog te schalen? Beschrijf hoe de oplossing tegemoetkomt aan de behoefte om op termijn nieuwe kunst- en cultuurhuizen toe te voegen en omgaat met de vereiste – vaak onmiddellijke en grote – toename in bediende en beheerde gebruikers en evenementen die daarmee gepaard gaat.

Beveiliging

9. Beschrijf in welke mate de oplossing ontworpen is om te voldoen aan wet- en regelgeving inzake de opslag en het gebruik van beveiligde gebruikersgegevens, met name de algemene verordening gegevensbescherming (Verordening (EU) 2016/679 van het Europees Parlement en de Raad van 27 april 2016).

10. Wanneer data doorgegeven of opgeslagen worden (in de cloud, servers) buiten de EEA of in de UK, waarop geen adequaatheidsbesluit van de Europese Commisie van toepassing is, moet een data transfer impact assessment worden uitgevoerd (Xxxxxxx II en Brexit). Geef aan of data doorgegeven of opgeslagen worden buiten de EEA of in de UK en indien dat het geval is, voeg dan de desgevallend in dat kader afgesloten geschikte en door de Europese Commissie actueel goedgekeurde standaardcontractbepalingen toe. Voeg een data transfer impact assessment toe, met vermelding van de noodzakelijke aanvullende maatregelen (“supplementary measures”) die daar desgevallend uit voortvloeien.

11. Welke beveiligingsprotocollen zijn vastgesteld voor ongeoorloofde toegang tot of bekendmaking van vertrouwelijke gegevens?

12. Beschrijf hoe het werken met een bewaartermijn voor persoonsgegevens van bv. 2 jaar wordt beheerd in de oplossing.

13. Beschrijf hoe de oplossing beveiligingsprotocollen gebruikt en ondersteunt om data-in-transit te beveiligen.

14. Beschrijf de ondersteuning die de oplossing biedt voor versleuteling van data-at-rest in back-ups en replicasets.

15. Stel een verwerkersovereenkomst voor voor de oplossing. Hierin moeten de bepalingen uit Deel 3 Algemene contractvoorwaarden (art. 17) opgenomen zijn.

Onderhoudbaarheid

16. Beschrijf hoe de oplossing kan omgaan met wijzigingen in de hardware, software of andere operationele omgevingen, bv. upgrades van het besturingssysteem, de databank, middleware, overstappen op een andere hostingpartner …

17. Beschrijf op welke manier de oplossing afhankelijk is van software van derde partijen en hoe ze ermee samenwerkt.

18. Licht de algemene principes toe welke keuzes voor systeemprofilering en -configuratie globaal worden toegepast, en welke keuzes kunnen worden toegepast per zaal, huis of groep van huizen.

Prestatie-efficiëntie

19. Beschrijf eventuele gekende problemen met response times van uw systeem en geef daarbij concrete voorbeelden (bv. Kan een medewerker verschillende modules van het systeem openen zonder prestatieverlies? Beïnvloedt het verzamelen van statistieken bijvoorbeeld de prestaties van de rest van het systeem? ).

20. Beschrijf de maximale load die de oplossing aan kan aan de hand van aangetoonde referenties (bv. piekverkoop) of loadtesten voor de 5 drukst bevraagde functionaliteiten in de medewerkerstoepassing en de webshop, en de 5 drukst bevraagde endpoints in de API.



NF-MO. Monitoring

NF-MO-VI. Visie

De aanbestedende overheid verwacht dat de dienstverlener de volledige controle heeft over de betrouwbaarheid, beveiliging en prestatie-efficiëntie van de oplossing, doordat hij professionele procedures en technische mechanismen aan de dag legt om het systeem te monitoren, die toegepast worden door uitstekende medewerkers met actuele kennis van de infrastructuur. Het systeem moet eenvoudig te auditen zijn en de resultaten van de audits dienen duidelijk en overtuigend te zijn.

NF-MO-MI. Vereisten

1. De dienstverlener biedt monitoring van de oplossing en ten minste van de betrouwbaarheid, beveiliging en prestaties van het systeem. De dienstverlener kan de volgende logboekinformatie verstrekken, die minstens 6 maanden goed wordt bijgehouden:

a. Raw web logs

b. Application server logs

c. Referrer logs

d. Error logs

e. Security event logs

f. Administration logs

2. De dienstverlener bewaart de logging informatie van alle activiteiten waarbij query’s naar persoonsgegevens worden uitgevoerd minstens 6 maanden online en 10 jaar offline.

3. Voor de activiteiten in het systeem kan worden getraceerd vanaf welke account ze werden uitgevoerd.

NF-MO-QU. Kwaliteit van de oplossing

1. Beschrijf hoe de oplossing de betrouwbaarheid, beveiliging en prestaties van het systeem monitort en erover rapporteert. Geef ook referentiegegevens of, in voorkomend geval, screenshots als voorbeeld van de feedback die deze monitoring oplevert. Is er een beheerportal met toegang tot site metrics (bv. systeemstatus, netwerkgebruik enz.)?

2. Beschrijf hoe de oplossing de capaciteit monitort en capaciteitsoverbelasting signaleert (bv. CPU-geheugen en schijfgebruik van de hele oplossing). Beschrijf eventuele proactieve monitoring van de oplossing door uw organisatie en eventuele communicatie naar de klant die daaruit voortvloeit, op basis waarvan maatregelen kunnen worden genomen. Waarschuw je de klant bijvoorbeeld wanneer bepaalde systeemlimieten dreigen te worden bereikt?

3. Geef een gedetailleerd overzicht van alle beschikbare logging informatie.

4. Beschrijf hoe de oplossing traceability ondersteunt. Voor welke acties kan de unieke gebruiker worden getraceerd die ze heeft uitgevoerd?

NF-SE. Servicedesk

NF-SE-VI. Visie

We zoeken een partner die een professionele servicedesk organiseert, bemand door mensen die goed communiceren, duidelijk omschreven procedures volgen, het systeem en de lokale context door en door kennen, vertrouwd zijn met het serviceniveau dat van hen wordt gevraagd en vloeiend Nederlands (eerstelijns of tweedelijns) of Engels (tweedelijns) spreken. De dienstverlener biedt een eerstelijns en tweedelijns servicedesk aan en noodsupport. De aanbestedende dienst kan er eventueel voor kiezen om de eerstelijnsservicedesk zelf te organiseren. Om ondersteuning te bieden en weloverwogen beslissingen te nemen over de uitvoering van het project heeft de aanbestedende dienst toegang nodig tot de complete en actuele documentatie van de oplossing.

NF-SE-MI. Vereisten

1. De servicedesk biedt eerste- en tweedelijnsondersteuning.

2. De servicedesk is bemand met mensen die goed communiceren, duidelijk omschreven procedures volgen, het systeem en de lokale context door en door kennen, vertrouwd zijn met het serviceniveau dat van hen wordt gevraagd en vloeiend Nederlands (eerstelijns of tweedelijns) of Engels (tweedelijns) spreken.

3. De servicedesk biedt noodsupport voor incidenten met prioriteit 1.

4. De respons op en de oplossing van incidenten beantwoorden aan de volgende prioriteitentabel:


Prioriteit 1

Een incident waarbij de volledige dienst of een onderdeel ervan onbeschikbaar is voor meerdere gebruikers.

Respons: 30 minuten

Oplossing: binnen 1 uur

Prioriteit 2

Een incident waardoor een specifieke functionaliteit niet beschikbaar of onbruikbaar is voor meerdere gebruikers. De specifieke functionaliteit levert verkeerde of geen resultaten op (en er is geen tijdelijke oplossing om dezelfde functionaliteit te bieden).

Respons: 30 minuten

Oplossing: binnen 4 (werk)uren

Prioriteit 3

Een incident waardoor een element zich hinderlijk, foutief of niet ergonomisch gaat gedragen, maar zonder invloed op de functionaliteit.

Respons: 1 dag

Oplossing: binnen 1 week

Prioriteit 4

Informatieve vragen over een bestaande of gewenste functionaliteit.

Respons: 1 week

Oplossing: binnen 2 weken

5. De servicedesk is op werkdagen van 9:00 tot 17:00 uur bereikbaar via de telefoon en e-mail.

6. Noodsupport is bereikbaar via telefoon en de servicedeskwebsite:

a. Op weekdagen van 8:00 tot 21:00 uur

b. Op zaterdag, zondag en Belgische feestdagen van 10:00 tot 21:00 uur

7. De servicedeskwebsite is de klok rond (24/7) beschikbaar en biedt de mogelijkheid om de status van je eigen tickets of tickets van je organisatie te raadplegen.

8. De documentatie van de oplossing is compleet, actueel en online beschikbaar.

NF-SE-QU. Kwaliteit van de oplossing

1. Beschrijf uw model voor de servicedesk en klantondersteuning in detail. Gaat u in op servicedeskvragen van om het even welk personeelslid of enkel van aangewezen vertegenwoordigers? Stelt u een of meerdere primaire contactpersonen ter beschikking voor een gegeven klantenaccount of biedt u ondersteuning per geografische regio of per specialiteit (bv. ticketing, klantenbeheer, rapporten)?

2. Beschrijf uw servicedesktool.

3. Beschrijf hoe u incident management aanpakt. Is er een intern alertsysteem dat proactief incidenten meldt en hoe gaat u om met een melding van het alertsysteem? Is er een webservice of statuspagina die de status van het incident en de oplossing aangeeft aan de gebruikers? Is er een automatische melding via mail of sms aan de getroffen gebruikers?

4. Beschrijf hoe u problem management aanpakt (wanneer incidenten problemen worden) en hoe problem management verband houdt met change en release management (zie NF-CH).

5. Beschrijf de inhoud van documentatiesets voor beheerders en voor eindgebruikers, hoe ze geleverd worden (contextafhankelijk, online, knowledgebase enz.) en hoe frequent ze worden bijgewerkt. Beschrijf ook de beschikbaarheid van content die door de gebruiker wordt aangemaakt, zoals communities of wiki's. Geef, indien beschikbaar, URL’s op.

6. Is het mogelijk om op bepaalde momenten buiten de vermelde uren toch noodsupport of extra waakzaamheid te bieden, bv. bij de seizoensstart, verwachte piekverkoop, enz.? Beschrijf hoe u daarmee omgaat en wat de modaliteiten zijn (bv. een maximum afgesproken aantal standby-momenten per huis, een standaardaanbod van 24/7 support)?





NF-CH. Change en releasemanagement

NF-CH-VI. Visie

We willen samenwerken met een partner die een sterke visie heeft op toekomstige ontwikkelingen, in staat is om die te vertalen naar een realistische roadmap en daarbij een goed evenwicht kan bewaren tussen ontwikkeling en softwareonderhoud, om het systeem technisch gezond te houden. Het is voor ons uitermate belangrijk dat releases en wijzigingen aan het systeem worden doorgevoerd in overeenstemming met architecturale principes en regels en worden gepland en uitgevoerd binnen duidelijk gedefinieerde ontwikkelings- en onderhoudsprocessen.

NF-CH-MI. Vereisten

1. De dienstverlener draagt de verantwoordelijkheid om de levenscyclus van alle wijzigingen te controleren. De dienstverlener geeft regelmatig een nieuwe versie van de software vrij. Wijzigingsbeheer moet het in de eerste plaats mogelijk maken om wijzigingen aan te brengen, met minimale verstoring van de dienstverlening.

2. De dienstverlener zal alles in het werk stellen om de negatieve effecten van wijzigingen te voorkomen. Alle wijzigingen die de beschikbaarheid en kwaliteit van de dienst beïnvloeden, dienen op voorhand door de aanbestedende dienst te worden goedgekeurd.

3. De dienstverlener draagt tevens de verantwoordelijkheid om het releasen naar faserings- en productieomgevingen te organiseren, te plannen en te controleren (alle configuratiewijzigingen en releases worden bijvoorbeeld eerst geïmplementeerd op een testomgeving). Releasebeheer moet in de eerste plaats zorgen dat de integriteit van de productieomgeving wordt beschermd en dat de juiste componenten worden vrijgegeven.

4. Releases worden getest en gedocumenteerd door de dienstverlener voordat ze op de staging omgeving wordt vrijgegeven overeenkomstig een testplan. De aanbestedende dienst krijgt een onderling overeengekomen testperiode in de testomgeving voordat ze de implementatie van de release in de productieomgeving goedkeurt.

5. Configuraties worden getest door de dienstverlener en worden pas na goedkeuring gereleased in de productieomgeving, overeenkomstig een testplan.

6. Incidenten die moeten worden opgelost met een softwarepatch krijgen een hotfix binnen de oplostijd in de prioriteitentabel in het service level agreement. Indien nodig kan de dienstverlener zich beroepen op een procedure voor een emergency release om de functionaliteit te herstellen door middel van een fix.

NF-CH-QU. Kwaliteit van de oplossing

1. Beschrijf het proces voor productverbetering en de rol die klanten typisch spelen bij het bepalen van en het toekennen van prioriteiten aan nieuwe functies en verbeteringen. Beschrijf eventuele wijzigingen of updates die je in het afgelopen jaar hebt doorgevoerd in de oplossing als een direct gevolg van klantenfeedback. Beschrijf ook je typische softwareontwikkelingsproces.

2. Beschrijf de frequentie en het toepassingsgebied van zowel grote als kleine releases. Hoe lang blijft u ondersteuning bieden voor een grote release nadat hij is vervangen door een nieuwe versie?

3. Beschrijf het proces om een nieuwe versie van de software te testen en de technieken die gebruikt worden om het testen eenvoudiger, sneller en betrouwbaarder te maken (bv. geautomatiseerde tests).

4. Beschrijf hoe u omgaat met change requests die slechts een deel van het gebruikersbestand ten goede komen (bv. kunst- en cultuurhuizen in een specifieke regio die een specifieke functionele behoefte hebben). Onder welke omstandigheden kan aan deze change requests gevolg worden gegeven (bv. als de aanbestedende overheid een jaarlijks budget voor change requests voorziet)?





NF-AC. Toegangsbeheer (medewerkers)

NF-AC-VI. Visie

De oplossing zal een grote populatie van medewerkers ondersteunen. De identiteiten en de toegangsrechten van deze populatie moeten duidelijk en eenvoudig te beheren zijn. De oplossing moet het mogelijk maken om beheer en functies op meerdere niveaus te autoriseren: per medewerker, per locatie/zaal, per huis, voor enkele huizen, voor de hele groep huizen of op centraal niveau (Cultuurconnect). Ze moet ook een manier bieden waarop een aantal kunst- en cultuurhuizen flexibel kunnen samenwerken (zie F-CO). Voor toegangsbeheer van klanten, zie het hoofdstuk Webshop bij de Functionele vereisten (F-WE).

NF-AC-MI. Vereisten

1. De identiteiten van medewerkers zijn uniek in het systeem, ongeacht het aantal locaties/zalen, huizen of groepen waaraan ze verbonden zijn.

2. De toegangsrechten kunnen worden beheerd door de aanbestedende dienst (voor de hele populatie) of door de groep of door de huizen zelf (enkel voor hun deel van de populatie).

3. Toegangsrechten kunnen worden gegroepeerd en collectief aan medewerkers worden toegewezen (bv. aan de hand van sjablonen). Op die manier kan de toegang tot een functionaliteit worden gesegmenteerd.

4. Door de inhoud van een groep te wijzigen, worden de toegangsrechten van alle medewerkers in die groep gewijzigd.

5. Er kunnen verschillende autorisatieniveaus worden geconfigureerd (bv. normaal, geavanceerd, expert, beheerder).

NF-AC-QU. Kwaliteit van de oplossing

1. De oplossing laat toe om medewerkers aan een groep kunnen toevoegen en vervolgens op basis van groepslidmaatschap rechten en bevoegdheden te kunnen beheren. Beschrijf hoe uw oplossing omgaat met machtigingen op basis van groepslidmaatschap.

2. Beschrijf het granulariteitsniveau van de toegangscontrole voor medewerkers (volgens het principe van ‘least privilege’). Kunnen bepaalde gegevens bv. alleen-lezen worden gemaakt voor sommige medewerkers en kan bewerken worden ingeschakeld voor anderen?

3. Beschrijf hoe beheerdersrechten in het systeem worden toegekend. Kunnen beheerdersrechten aan zowel groepen als gebruikers worden toegekend? Kunnen beheerdersrechten met de oplossing per huis of groep worden gecompartimenteerd?

4. Beschrijf of en hoe u authenticatie- en autorisatie-oplossingen ondersteunt die single sign-on voor medewerkers mogelijk maken (bv. Auth0, Xxxxx, SAML, ...).

5. Beschrijf het beheer van wachtwoorden en logins voor de medewerkers. Kunnen medewerkers het wachtwoord van hun account zelf wijzigen?

NF-US. User interface

NF-US-VI. Visie en context

Medewerkers van kunst- en cultuurhuizen gebruiken het systeem dagelijks en misschien wel urenlang. De user interface moet er daarom voor zorgen dat de interactie met het systeem prettig is en voldoening schenkt, en dat het systeem eenvoudig en efficiënt te bedienen en te beheren is. Dat betekent dat er niet te veel informatie op één scherm mag worden weergegeven, dat je niet door lange lijsten met opties hoeft te scrollen, dat taken met een minimaal aantal acties worden uitgevoerd en dat er toegang is tot een uitstekende helpfunctionaliteit. Hetzelfde geldt uiteraard voor de user interface van de webshop. Onze vereisten zijn gebaseerd op de 10 algemene principes voor interaction design van Xxxxx Xxxxxxx (xxxxx://xxx.xxxxxxx.xxx/xxxxxxxx/xxx-xxxxxxxxx-xxxxxxxxxx/).

NF-US-MI. Vereisten

1. Met de user interface wordt een responsetijd van 0,1 seconde nagestreefd voor alle taken in de user interface die worden uitgevoerd met behulp van gebruikersbesturingselementen (bv. keuzerondjes, vervolgkeuzelijsten, tabs). Als de responsetijd meer bedraagt dan 0,1 seconde, zal de user interface duidelijk aangeven dat de toepassing is ingeschakeld om de taak uit te voeren, bv. doordat de cursor verandert in een spinner. De limiet voor dit soort responsetijd is 1 seconde.

2. Met de user interface wordt een responsetijd van 1 seconde nagestreefd voor taken waarbij de gebruiker door de toepassing navigeert (bv. doorklikt naar een andere pagina) of informatie wordt verzonden of ontvangen via een formulier. Als de responsetijd meer bedraagt dan 1 seconde, zal de UI duidelijk aangeven dat de toepassing de taak aan het uitvoeren is, bv. doordat de cursor verandert in een spinner. De limiet voor dit soort responsetijd is 3 seconden.

3. In overleg kan de dienstverlener taken voorleggen die langer duren dan 5 seconden en kan worden bepaald hoe de user interface de gebruiker zal informeren over de duur van de taak. Het doel voor deze taken is echter maximaal 10 seconden. De gebruiker kan de taak ook ten allen tijde annuleren als ze te lang duurt.

4. De oplossing dient de gebruiker altijd op de hoogte te houden van wat er aan het gebeuren is door binnen een redelijke tijdspanne de nodige feedback te bieden (Nielsen nr.1: zichtbaarheid van de systeemstatus).

5. De oplossing moet de taal van de gebruiker spreken, met woorden, uitdrukkingen en concepten die de gebruiker kent in plaats van systeemgerichte termen of codes. Volg de conventies die in de fysieke wereld gelden, zodat informatie in een natuurlijke en logische volgorde verschijnt (Nielsen nr. 2: overeenkomst tussen het systeem en de fysieke wereld)

6. Gebruikers selecteren vaak per ongeluk een systeemfunctie en hebben een duidelijk aangegeven ‘nooduitgang’ nodig om de ongewenste omgeving zonder uitgebreide dialoog te verlaten. Ondersteun ongedaan maken en herhalen. (Nielsen nr.3: de gebruiker heeft controle en vrijheid)

7. De gebruiker zou zich niet hoeven af te vragen of verschillende woorden, situaties of acties hetzelfde betekenen. Volg de conventies voor platformen. (Nielsen nr.4: consistentie en normen)

8. Nog beter dan goede foutberichten is een zorgvuldig ontwerp dat voorkomt dat een probleem zich in de eerste plaats stelt. Vermijd foutgevoelige voorwaarden of controleer het systeem erop en vraag de gebruiker om bevestiging voordat hij een actie uitvoert. (Nielsen nr.5: fouten voorkomen)

9. Maak objecten, acties en opties zichtbaar zodat de gebruiker zo weinig mogelijk een beroep hoeft te doen op zijn geheugen. De gebruiker zou geen informatie uit één deel van de dialoog hoeven te onthouden om ze in een ander deel te gebruiken. De gebruiksinstructies voor het systeem moeten zichtbaar of eenvoudig op te roepen zijn wanneer nodig. (Nielsen nr.6: herkennen i.p.v. onthouden)

10. Sneltoetsen – die de beginnende gebruiker niet ziet – versnellen vaak de interactie voor gevorderde gebruikers zodat het systeem tegemoetkomt aan zowel onervaren als ervaren gebruikers. Sta gebruikers toe om frequente acties aan te passen, bv. met toetsenbordsneltoetsen. (Nielsen nr.7: flexibiliteit en gebruiksefficiëntie)

11. Schermen en dialoogvensters mogen geen informatie bevatten die niet relevant of zelden nodig is. Elk stuk extra informatie in een scherm of dialoogvenster concurreert met relevante informatie en vermindert de relatieve zichtbaarheid daarvan. (Nielsen nr.8: esthetisch en minimalistisch design)

12. Foutberichten moeten in gewone taal worden uitgedrukt (geen codes), precies aangeven wat het probleem is en constructief een oplossing voorstellen. (Nielsen nr.9: help de gebruiker fouten te herkennen, problemen vast te stellen en ervan te herstellen)

13. Ook al is het beter als het systeem kan worden gebruikt zonder documentatie, toch kan hulp en documentatie soms nodig zijn. Deze informatie moet eenvoudig op te zoeken zijn, afgestemd zijn op de taak van de gebruiker en concrete stappen opsommen die moeten worden uitgevoerd. Ze mag ook niet te uitgebreid zijn. (Nielsen nr. 10: help en documentatie)

14. De teksten in de interface en de helpteksten zijn in het Nederlands.

15. De lay-out van de user interface kan worden aangepast aan de voorkeuren van de gebruiker (bv. standaardinstellingen, sorteren, filteren, venstergrootte).

16. De user interfaces verbergen de functionaliteit waar een gebruiker geen toegang toe heeft.

17. De user interface is geschikt voor slechtzienden (bv. grote lettertypen, goed contrast …).

NF-US-QU. Kwaliteit van de oplossing

1. Beschrijf hoe de bruikbaarheid van de oplossing deel uitmaakt van het ontwikkelproces van de software. Bestaat de functie van usability expert binnen je bedrijf? Maak je systematisch gebruik van inzichten uit gebruikersonderzoek om de bruikbaarheid van je oplossing te verbeteren?

2. Beschrijf de navigatie- en informatiearchitectuur van de user interface van de oplossing. Wanneer vond de laatste grote update van de user interface plaats? Omvatte die onderzoek en gebruikerstesten?

3. Beschrijf hoe de oplossing hulp en documentatie biedt. Deze informatie moet eenvoudig op te zoeken zijn, afgestemd zijn op de taak van de gebruiker en concrete stappen opsommen die moeten worden uitgevoerd. Ze mag ook niet te uitgebreid zijn.

4. Beschrijf hoe de oplossing kan worden gebruikt op kleinere schermen zoals smartphones en tablets. Maak een onderscheid tussen de ticketing administratie, de box office en de webshop.

5. Beschrijf of en hoe de lay-out van de user interface kan worden aangepast aan de voorkeuren van de gebruiker (bv. standaardinstellingen, sorteren, filteren, venstergrootte).


Document Metadata

Filed: January 19th, 2023