-

Non functional requirements bepalen succes internetprojecten

Veel internetprojecten, of het nu eenvoudige websites zijn of de opzet van een selfcare omgeving voor een grote organisatie, hebben baat bij goede non functional requirements voordat de uitvoering start. Het slagen van een project valt of staat er namelijk mee.

Non functional requirements zijn alle eisen en wensen die aan een website of internetapplicatie gesteld moeten worden, maar niets te maken hebben met wat de gebruiker allemaal kan in het dagelijkse gebruik van de site. Het gaat om de randvoorwaarden die goed ingevuld moeten worden omdat een gebruiker anders niets of weinig heeft aan het resultaat van het project. Denk aan gebruiksgemak, veiligheid en snelheid van de applicatie. Vul je dit niet goed in, dan zal het project mislukken. Al is het idee nog zo sterk.

Performance
Een goede performance is van essentieel belang voor een succesvol internetproject. Het formuleren van haalbare, goede performance requirements is erg lastig. Performance wordt namelijk beïnvloed door de hele keten heen; van de computer van de websitebezoeker en zijn internet verbinding tot de bedrijfsapplicatie die gegevens ontsluit (en de onderliggende hardware). Binnen internetprojecten is het advies om voor de te beïnvloeden performance harde requirements af te spreken die gehaald moeten worden. In de testfase dient hier op getoetst te worden. Neem bijvoorbeeld klantinformatie die op een bepaalde webpagina opgehaald moet worden uit een achterliggend CRM-systeem. Een requirement kan zijn dat dat ophalen van gegevens met een ADSL lite-verbinding en een bepaalde browser binnen vijf seconden moet lukken. Dit geval kan eenvoudig getest worden als de software is opgeleverd aan het testteam.

Neem als uitgangspunt altijd de ervaring van de gebruiker, al is dat nooit helemaal te beïnvloeden. Bij een doorsnee breedbandverbinding zijn wachttijden van een tot twee seconden voor de opbouw van een regulier scherm gemiddeld. Langer dan acht seconden wil een klant niet wachten.

Beschikbaarheid
Naast performance is de beschikbaarheid van een nieuwe dienst op het internet ook belangrijk om goed te definieren. Beschikbaarheid is de kans dat de dienst ook daadwerkelijk functioneert als een gebruiker deze op een willekeurig moment gaat gebruiken. Zeker als internetapplicaties gebruikmaken van meerdere losse systemen die bijvoorbeeld informatie verstrekken of opslaan, kan beschikbaarheid een gevaarlijke valkuil blijken. Als er bijvoorbeeld vier achterliggende systemen nodig zijn om een aankoop op internet af te handelen en deze systemen allemaal maar in 97 van de 100 gevallen operationeel zijn, dan is de hele dienst voor de eindklant maar 0,97*0,97*0,97*0,97 = 88,5 procent beschikbaar (!). Een uptime van 99,8 procent of zelfs 99,9 procent voor professionele internetapplicaties is een goede richtlijn. Als de IT-keten achter de website niet boven de 98 procent beschikbaarheid uitkomt, stel jezelf dan de vraag of de architectuur wel klopt met het medium internet.

Gebruikersvriendelijkheid
Het goed toegankelijk maken van internettoepassingen voor klanten is een vak op zich. Een goed voorbeeld van een toegankelijke website is een site die zowel door blinde mensen als door oude mensen even goed te gebruiken is als door het overige publiek. Door van tevoren na te denken welke doelgroepen de te maken applicatie of website eenvoudig moeten kunnen gebruiken, zorg je voor focus hierop tijdens het project. Een ander voorbeeld is de snelheid waarmee bepaalde typen gebruikers bepaalde informatie moeten kunnen vinden of een bestelling moeten kunnen doen. Het beste is om naast het formuleren van deze requirements daarna ook echt met de doelgroepen te testen zodra dat kan.

Gebruikersvriendelijkheid is goed te testen met gebruikerspanels en technieken als bijvoorbeeld eyeball tracking waarin gebruikers opdrachten krijgen en gemeten wordt hoe snel gebruikers begrijpen wat ze moeten doen op een site. Zet een gespecialiseerd bureau in om de juiste keuze in meetmethode te maken en doe ook echt wat met de resultaten, zelfs als die tegen de oorspronkelijke opzet ingaan.

Security
Natuurlijk moet de applicatie veilig zijn; het gaat hier echter om de precieze invulling. Veiligheid gaat niet alleen over de technische veiligheid van de applicatie maar ook om vraagstukken als wie in je bedrijf bijvoorbeeld de wachtwoorden kan inzien van je klanten en hoe deze naar de klanten gecommuniceerd worden als ze vergeten zijn. Processen zijn minstens een zo groot risico als lekken in (internet)applicaties en verdienen net zoveel aandacht in een goed internetproject.

Laat bij risicovolle projecten of echt gevoelige informatie die ontsloten gaat worden op internet een IT-audit doen door een onafhankelijk gespecialiseerd bedrijf. Alleen echte hackers kunnen de ultieme securitytest uitvoeren en zelfs dan heb je nooit honderd procent garantie.

Tot slot; een projectmanager dient te bewaken dat de non-functional requirements meegenomen worden bij de start van een project of dat er op zijn minst bewust voor gekozen wordt ze niet mee te nemen. Vraag kritisch door om de redenen achter de wensen scherp te krijgen en stel reële requirements op die passen bij het doel van het project.  

)* Dit artikel is geschreven door Remco Tomei, Online Projectmanager & Consultant bij Seventy3

Deel dit bericht

2 Reacties

Arno Naafs

Goed artikel. Het is inderdaad zeer belangrijk de non-functional requirements in beeld te brengen. Alleen vind ik de requirements die je noemt ‘gebruikersvriendelijkheid, beschikbaarheid, security en performance’ nog wel een behoorlijk ‘functionele smaak’ hebben.

Ik versta onder non functionele requirements juist meer zaken als:
– organisatorische requirements: wat moet er door de organisatie zelf allemaal geregeld worden om het internetproject succesvol te lanceren en succesvol te houden? Wie is waarvoor verantwoordelijk? Hoeveel tijd en capaciteit moet worden ingeruimd?
– content requirements: wat zijn eisen aan de content? Denk aan tone of voice, veel/weinig beeld, etc.

Ook dat zijn belangrijke voorwaarden waar aan gedacht moet worden!

Mark

Mooie term voor wat bij mij bekend staat als de basis van een moderne internet applicatie.

Toevoeging: locale database met taal, timezones, metriek… En nog 1001 en andere zaken die laten zien of je technische partij echt technisch is

Tone of voice vind ik content immers geen tone of voice zonder content.

Wat betreft het wachtwoorden verhaal in je artikel, dat is werkelijk waar een teken dat jouw veiligheid advies te wensen over laat. Immer wachtwoorden dien je te hashen met een zogenaamde salt zodat niemand ze kan lezen. Wachtwoorden reset je, je geeft een gebruiker nooit zijn wachtwoord terug dat hoor je immers niet te weten, niemand binnen de organisatie en dat is technisch simpel te realiseren zonder process problemen

Plaats een reactie

Uw e-mailadres wordt niet op de site getoond