De kwaliteit van software: hoe bepaalt u de vereisten?

Uw klant wil een nieuwe softwaretoepassing, en u hebt alle functionele vereisten genoteerd. U weet wat de toepassing moet doen. Maar weet u ook hoe nauwkeurig de toepassing moet zijn, en wat uw klant verwacht op het vlak van leerbaarheid en installeerbaarheid? Ook de niet-functionele vereisten moeten worden gedocumenteerd, anders ontstaan er misverstanden. Een nuttige leidraad hierbij is de norm ISO 9126 voor de kwaliteit van software.

Bij het overleg met uw klant gaat de meeste aandacht waarschijnlijk naar de functionele vereisten; zo loopt het meestal. Maar de klant heeft ook bepaalde verwachtingen op andere vlakken. Daar kan u best expliciet naar vragen, anders blijven het onuitgesproken wensen. Blijkt achteraf dat de toepassing niet voldoet aan de impliciete verwachtingen van de klant, dan komt er ruzie van. Beide partijen zijn gebaat met duidelijke, expliciete, eenduidige en meetbare vereisten.

ISO (International Organisation for Standardisation) is een niet-gouvernementele organisatie die instituten van standaardisaties uit 158 landen verenigt. Het centrale secretariaat is gevestigd in Genève in Zwitserland. De standaard ISO 9126 beschrijft algemene kwaliteitsattributen waar de makers van software aan moeten denken. De standaard vertelt niet wat het niveau is waaraan software voor die verschillende attributen moet voldoen, maar vormt wel een nuttige checklist. Voor deze standaard is ook geen sprake van een certificaat.

De standaard bestaat uit vier delen: quality model, external metrics, internal metrics, en quality in use metrics. Deel 1 van deze standaard (ISO 9126-1) beschrijft een kwaliteitsmodel dat voor softwareproducten kan worden toegepast. Dit kwaliteitsmodel defi nieert een aantal kwaliteiten, of kwaliteitsattributen, onderverdeeld in zes categorieën.

– functionaliteit (functionality)
– betrouwbaarheid (reliability)
– bruikbaarheid (usability)
– efficiëntie (efficiency)
– onderhoudbaarheid (maintainability)
– overdraagbaarheid (portability)
We bekijken ze één voor één.

FUNCTIONALITEIT
De toepassing moet alles doen wat de gebruiker nodig heeft. Maar wat is alles? Welke functies moet de toepassing bevatten? Hoe moet ze precies werken?

De toekomstige user waarmee u spreekt, gaat uit van zijn of haar persoonlijke ervaring met software. Heeft hij bijvoorbeeld gewerkt met een softwaretoepassing die elk ingegeven BTW-nummer valideerde, dan denkt hij dat dit standaard deel uitmaakt van de ‘intelligentie’ van computers, en hij zal het misschien niet expliciet vermelden als een vereiste voor de nieuwe toepassing.

Andere vragen. Hoe nauwkeurig moet de toepassing zijn? Moet ze samenwerken met andere toepassingen? Wat is daarvoor nodig? Zijn er bepaalde afspraken uit conventies, standaarden, regelgevingen, wetten enzovoort die moeten worden nageleefd?

Het mag niet mogelijk zijn voor een onbevoegd persoon om de software of de gegevens te gebruiken – wat zijn de vereisten op het vlak van beveiliging?

BETROUWBAARHEID
De toepassing mag nooit uitvallen. Of toch wel, maar niet te lang. Hoe lang mag ze buiten gebruik zijn voor uw klant hinder ondervindt?

Gaat het om een facturatietoepassing, dan is het misschien geen drama als ze twee dagen buiten gebruik is. Gaat het echter om een toepassing die deel uitmaakt van de productieketen van een krant, dan kan een uitval van minder dan een uur er al voor zorgen dat de deadline van de drukker niet gehaald wordt – een ramp.

Wat moet er gebeuren na het herstarten? Moeten er gegevens gerecupereerd worden? Als iemand een fout begaat, valt de software uit. Of mag dat niet? Welke fouten moeten worden opgevangen? Wat als een onderdeel van de software faalt?

BRUIKBAARHEID
De software moet gebruiksvriendelijk zijn. Hoe gebruiksvriendelijk? Wat verwachten de users van deze software op dat vlak?

Sommige gebruikers typen veel gegevens in. Ze hebben er een hekel aan om hun toetsenbord te moeten loslaten, en verplicht te worden hun muis te gebruiken. In dat geval is het best om in de user interface voor elk muiscommando een alternatief commando te voorzien dat met het toetsenbord gegeven wordt.

De software moet gemakkelijk te leren zijn. Maar wat is gemakkelijk? Zonder handleiding? Met een handleiding, maar zonder cursus? Het is best dit te preciseren. De software werd bovendien gebouwd op basis van bepaalde concepten. De toekomstige gebruiker moet die kunnen begrijpen. Hoe moet dat gebeuren?

De gebruiker moet de toepassing gemakkelijk kunnen hanteren. Als hij of zij weet wat hij wil, moet hij zijn idee vlot in de praktijk kunnen brengen. Hoe vlot?

EFFICIËNTIE
De software moet effi ciënt zijn. Maar hoe effi ciënt? Al naargelang de omgeving kunnen de eisen sterk uiteenlopen. Hoe snel moet het programma reageren op input van de user? Hoe lang mag de batchverwerking duren? Wat is goed, wat is aanvaardbaar, wat is slecht? Als de klant het niet specifi ceert, hebt u er het raden naar.

Heeft de gebruiker van de toepassing een klant aan de lijn, of voor zich in de winkel, dan verliezen zowel de klant als het personeelslid tijd terwijl ze wachten op een antwoord van de toepassing. Werkt de toepassing met services, dan is het best de verwachte performance concreet af te spreken, op een meetbare manier. Want de architectuur moet worden aangepast aan de vereisten, en dat heeft zijn weerslag op de kostprijs van het project.

Wat verwacht uw klant op het vlak van resource behaviour? Wat moeten de database, het geheugen, de schijf aankunnen?

ONDERHOUDBAARHEID
Uw klant is van plan de software lange tijd te gebruiken. De vereisten zullen veranderen, de toepassing moet dus kunnen worden gewijzigd. Wat zijn de vereisten op het vlak van onderhoudbaarheid? Als er een probleem is in de toekomst, moet de programmeur van dat moment in staat zijn de plaats in de toepassing te vinden waar het fout loopt; debugging moet mogelijk zijn, foutboodschappen moeten kunnen. Een kleine wijziging mag ook maar een kleine inspanning vragen.

Als een wijziging te veel tijd en dus geld kost, is ze niet meer de moeite waard. En ook testen moet mogelijk zijn. Als het programma niet getest is, werkt het ook niet.

Het duidelijkste voorbeeld op dit vlak is het probleem van het jaar 2000. Programmeurs zochten de datumvelden in de programma’s, om ze aan te passen. Als ze ze niet vonden, konden ze de programma’s niet wijzigen, en moest de hele toepassing weggegooid worden, wegens niet onderhoudbaar.

Dit probleem kan vermeden worden door het gebruik van programmatiestandaarden, voorschriften voor de structuur van de programma’s en de naam van de variabelen.

PORTABILITEIT / OVERDRAAGBAARHEID
Misschien komt de toepassing in de toekomst op een ander platform terecht. Dat moet kunnen. Of niet? Ontwikkelen uw mensen in Java, dan hoopt u de afgewerkte toepassing zonder veel moeite te kunnen overdragen naar een andere omgeving. De Java Virtual Machine wordt geacht de verschillen op te vangen. Toch is dit niet altijd zo simpel.

Hoeveel moeite mag het kosten om de software te installeren in een bepaalde omgeving? Zijn er strikte eisen op dat vlak? Zijn er standaarden, conventies of afspraken met betrekking tot de portabiliteit van de software die nageleefd moeten worden? Hoe vervangbaar moet uw software zijn? Misschien moet de interface van uw toepassing voldoen aan bepaalde standaarden. Hoe groot moet het aanpassingsvermogen van uw software zijn? Verwacht uw klant een toepassing die aangepast kan worden door het instellen van parameters? Wil uw klant de toepassing laten aanpassen door zijn programmeurs?

ANDERE OMGEVING, ANDERE EISEN
Verschillende klanten hebben verschillende verwachtingen; verschillende sectoren hanteren verschillende normen. Enkele voorbeelden:

– Voor berekenings- en simulatiesoftware zijn nauwkeurigheid en het gedrag in de tijd doorslaggevend. Dat is ook zo voor veel machinest
uringen.

– In embedded toepassingen voor consumenten zijn naast bruikbaarheid ook aspecten als herstelbaarheid en efficiëntie belangrijk. Doordat deze producten het vaak moeten stellen met geringe rekenkracht en beperkt energievermogen, krijgt het gedrag in relatie met de aangewende middelen extra aandacht.

– De ontwikkelaars van een bankterminal zullen veel aandacht besteden aan de aspecten betrouwbaarheid en bruikbaarheid. De nationale wetgeving kan bovendien verplichten dat bepaalde richtlijnen, standaarden en wetten worden nageleefd.

– Voor bedrijfskritische systemen is nauwkeurigheid van groot belang, maar ook stabiliteit en tijdsgedrag. Software die in een call center wordt gebruikt, moet de operator in staat stellen zoveel mogelijk oproepen af te handelen. Een fout zoals een verkeerde tabvolgorde in de gebruikersinterface kan tijdverlies veroorzaken, en dus geld kosten. Vandaar dat ook hier bruikbaarheid een belangrijke factor is.

– Een B2B-applicatie biedt één of meerdere interfaces aan waarmee externe applicaties kunnen interageren met de B2B-applicatie. Omdat die applicaties gebouwd worden door verschillende leveranciers, zullen naleving van interfacestandaarden, interoperabiliteit en foutbestendigheid een belangrijke rol spelen.

Wilt u op het einde van het ontwikkeltraject een tevreden klant hebben, dan is het best om voldoende aandacht te hebben voor alle requirements, niet alleen de functionele requirements maar ook de niet-functionele. Het is nodig te bepalen welke kwaliteitsaspecten belangrijk zijn voor uw softwaretoepassing, en hoe streng de eisen van uw klant zijn. Gezien de implicaties op het vlak van ontwikkeltijd en -prijs, mag u dit niet over het hoofd zien.

Christiane Vandepitte is zelfstandig consultant.
Dit artikel steunt in grote mate op artikels die verschenen op Agoria Online en op WTCM
Techniline.