3. Non-Functionele Requirements & Quality Attributes

Non-Functionele Requirements & Quality Attributes

Dit hoofdstuk beschrijft de non-functionele requirements waaraan het system moet voldoen. Ook zijn de geprioriteerde quality attributes (QA's) in dit hoofdstuk opgenomen

Non-Functional Requirements

De Non-Functional Requirements zijn in onderstaande tabel weergegeven:

Kwaliteitsattribuut (QA) Verduidelijken wat en hoe de QA gebruikt worden binnen het LCM

In het LCM project zijn de onderstaande SEI kwaliteitsattributen* (Quality Attributes, QA) opgenomen en geprioriteerd. De gekozen kwaliteitsattributen bieden een omvattende set binnen de scope van het LCM traject. De prioritering heeft tot doel om focus aan te brengen en te houden m.b.t. de ontwerp beslissingen binnen de scope van het GIS platform. De prioritering is gebaseerd op een inschatting mbt de grootste afwijkingen vanuit de IT ondersteuning als ook de geschatte inspanning die vanuit IVP-GIS moet worden gedaan aangaande de dienstverlening, security en doel architectuur.
*Een kwaliteitsattribuut (QA) is een meetbare of testbare eigenschap van een systeem die wordt gebruikt om aan te geven hoe goed het systeem voldoet aan de behoeften van zijn belanghebbenden, afgezien van de basisfunctie van het systeem. Je kunt een kwaliteitsattribuut zien als het meten van het 'nut' van een product langs een bepaalde dimensie die van belang is voor een stakeholder.

opmerking: de set is gebaseerd op het SEI Quality Model (by Len Bass et. al., 2022) en bestaat uit een totaal van 10 attributen waarbij Deployability, Safety en Energy Efficiency buiten beschouwing zijn gelaten.

Bruikbaarheid

Definitie: Bij bruikbaarheid gaat het om hoe gemakkelijk het voor de gebruiker is om een ​​gewenste taak uit te voeren en het soort gebruikersondersteuning dat het systeem biedt.
Rationale: de geaggregeerde functionele requirements zoals beschreven in [8] en het voorgaande hoofdstuk geven aan dat er behoefte is aan 'self service' functionaliteit binnen het GIS platform. In de huidige implementatie is deze functionaliteit onvoldoende aanwezig en dient dit te worden gerealiseerd binnen het LCM project.

Beveiliging

Definitie: Beveiliging is een maatstaf voor het vermogen van het systeem om gegevens en informatie te beschermen tegen ongeoorloofde toegang, terwijl het toch toegang biedt aan mensen en systemen die geautoriseerd zijn.
Rationale: Het veilig ontsluiten van functionaliteit en gegevens binnen de RWS organisatie is een must-have en dient dan ook bij elke ontwerp beslissing meegenomen te worden.

Interoperabiliteit

Definitie: Interoperabiliteit gaat over de mate waarin twee of meer systemen zinvolle informatie kunnen uitwisselen via interfaces in een bepaalde context.
Rationale: Binnen het GIS platform is het uitwisselen van data/informatie een key-aspect m.b.t. de gevraagde functionaliteit.

Aanpasbaarheid

Definitie: Aanpasbaarheid gaat over verandering, en onze interesse daarin concentreert zich op de kosten en risico's van het doorvoeren van veranderingen.
Rationale: Het GIS (IT) landschap is aan verandering onderhevig en het is dan ook noodzakelijk om hierin mee te kunnen bewegen en/of een leidende rol te kunnen innemen.

Testbaarheid

Definitie: Testbaarheid van software verwijst naar het geval waarin software zijn fouten kan aantonen door middel van (doorgaans op uitvoering gebaseerde) tests.
Rationale: Door in te zetten op vergaande geautomatiseerde deployment, configuration management, monitoring en testen zijn we binnen het GIS platform in staat om snel, voorspelbaar en met een constante kwaliteit functionaliteit te leveren en of wijzigingen aan te brengen.

Beschikbaarheid

Definitie: Beschikbaarheid verwijst naar het vermogen van een systeem om fouten te maskeren of te repareren, zodat de cumulatieve uitvalperiode van de service een vereiste waarde gedurende een bepaald tijdsinterval niet overschrijdt.
Rationale: Historisch gezien is de benodigde/gevraagde beschikbaarheid van het applicatie landschap toereikend en dwingt geen specifieke aanpassingen af. Door de nieuwe architectuur te baseren op de, door de leveranciers, aanbevolen architectuur i.c.m. de best practises van het bestaande GIS-platform kunnen we aan beschikbaarheid requirement voldoen.

Prestaties

Definitie: Prestaties hebben te maken met tijd en het vermogen van het softwaresysteem om aan de timingvereisten te voldoen.
Rationale: Historisch gezien is de benodigde/gevraagde performance van het applicatie landschap stabiel en voorspelbaar. De aanname is dat dit ook voor de korte en midden lange termijn geldt. Hierdoor is er vooraf een goede inschatting te maken wat betreft de benodigde architectuur en capaciteit om aan de prestatie requirement te voldoen.

Architectuur Principes

Operationeel

Back-up en Recovery

Non Run-Time Requirements

Systeem beperkingen

Beperking vanuit de Business

Onbekend tijdens schrijven van dit document.

Technische standaarden

Technische beperkingen