In de wereld van de techniek, met name in de softwareontwikkeling en systeemtechniek, is het begrijpen van het kritische onderscheid tussen functionele en niet-functionele vereisten van fundamenteel belang voor het succes van projecten. 37% van de projecten faalt vanwege onduidelijke of verkeerde eisen, waardoor het essentieel is dat ingenieurs, ontwikkelaars, projectmanagers en stakeholders deze concepten grondig begrijpen. Deze eisen vormen de ruggengraat van het systeemontwerp, en beïnvloeden alles van gebruikerservaring en systeemprestaties tot duurzaamheid en schaalbaarheid op lange termijn.

Deze uitgebreide gids onderzoekt zowel functionele als niet-functionele eisen in detail, biedt praktische voorbeelden, beste praktijken voor documentatie en strategieën voor effectief beheer van eisen. Of u nu een e-commerceplatform bouwt, software ontwikkelt of complexe systemen ontwerpt, het beheersen van deze eisen zal uw projectresultaten aanzienlijk verbeteren.

Wat zijn functionele vereisten?

In software engineering en systeem engineering, een functionele eis definieert een functie van een systeem of zijn component, waarbij een functie wordt beschreven als een samenvatting (of specificatie of verklaring) van het gedrag tussen inputs en outputs. Functionele eisen definiëren de specifieke kenmerken en operaties een systeem moet uitvoeren om te voldoen aan zakelijke en gebruikersbehoeften.

Functionele vereisten definiëren de eigenschappen en functies van een systeem. Met andere woorden, ze beschrijven wat het softwareproduct precies moet doen onder normale omstandigheden om aan de behoeften van de gebruiker te voldoen. Vanuit het perspectief van een ontwikkelaar, zijn dit de functies die moeten worden geïmplementeerd om ervoor te zorgen dat het systeem werkt zoals bedoeld.

Functionele vereisten kunnen berekeningen, technische details, gegevensmanipulatie en -verwerking omvatten, en andere specifieke functionaliteiten die bepalen wat een systeem geacht wordt te bereiken. Ze dienen als basis voor ontwikkelingsteams, met duidelijke richtlijnen over wat er gebouwd moet worden en hoe het systeem moet reageren op verschillende inputs.

Belangrijkste kenmerken van functionele eisen

Functionele eisen hebben verschillende kenmerken die hen onderscheiden van andere soorten eisen:

  • Specificiteit: Ze beschrijven precies gedrag en functies die het systeem moet uitvoeren
  • Testabiliteit: Elke eis kan worden geverifieerd door middel van tests om de implementatie te bevestigen
  • Gebruiker-gefocust: Ze hebben rechtstreeks betrekking op gebruikersbehoeften en zakelijke doelstellingen
  • Actie-georiënteerd: Ze definiëren wat het systeem doet als reactie op input
  • Measurability: Ze hebben gedefinieerde uitkomsten die kunnen worden gemeten, zoals succesvolle login met geldige referenties

Typen functionele eisen

Functionele vereisten kunnen worden ingedeeld in verschillende types op basis van de workflows en gedragingen die zij beschrijven:

Bedrijfsregels en logica

Bedrijfsregels zijn meestal de grootste groep als ze definiëren hoe het systeem reageert op commando's in de belangrijkste gebruikersstroom. Deze vereisten specificeren de kern bedrijfslogica die het gedrag van de toepassing drijft, waaronder berekeningen, besluitvormingsprocessen en workflow automatisering.

Gebruikersauthenticatie en -vergunning

Authenticatie- en autorisatievereisten bepalen hoe gebruikers toegang hebben tot het systeem en welke rechten ze hebben. Deze vereisten geven aan hoe ze inloggen, wachtwoordbeleid, role-based toegangscontrole en beveiligingsprotocollen voor gebruikersidentiteitscontrole.

Vereisten inzake gegevensbeheer

Gegevensvereisten bepalen hoe gegevens moeten worden gemaakt, opgeslagen, gewijzigd en verwijderd. Ze zijn vooral belangrijk als uw product gevoelige gebruikersgegevens verwerkt. Deze vereisten hebben betrekking op database-bewerkingen, gegevensvalidatieregels, gegevensverwerkingsprocessen en gegevensretentiebeleid.

Gebruikersinterfacevereisten

UI eisen specificeren hoe uw gebruikers zullen communiceren met uw product. Ze definiëren ontwerpelementen die navigatie intuïtief maken. Deze eisen beschrijven de visuele elementen, interactiepatronen, navigatiestromen en gebruikersinterfacecomponenten die gebruikers zullen tegenkomen.

Vereisten inzake transacties en verwerking

Deze vereisten definiëren hoe het systeem transacties verwerkt, zaken doet en workflows beheert. Ze specificeren de stappen die nodig zijn om taken te voltooien, de volgorde van operaties en de verwachte resultaten van verschillende processen.

Uitgebreide voorbeelden van functionele eisen

Het begrijpen van functionele vereisten wordt duidelijker door concrete voorbeelden van verschillende industrieën en toepassingen. Hier zijn gedetailleerde voorbeelden georganiseerd per domein:

Toepassingsvoorbeelden voor e-commerce

Een e-commerce-website moet functionele vereisten hebben die definiëren hoe klanten naar items zoeken, hun kenmerken beoordelen, een bestelling maken, betalen en bevestiging ontvangen.

  • Het systeem moet gebruikers in staat stellen om een account aan te maken met behulp van e-mailadres en wachtwoord
  • Gebruikers moeten producten kunnen bladeren per categorie, prijs en merk filters
  • Gebruikers moeten in staat zijn om producten toe te voegen aan een winkelwagentje en de inhoud van uw winkelwagen te bekijken
  • De gebruiker kan items in de winkelwagen te beoordelen, hun nummer te veranderen, of verwijderen voor de kassa
  • De gebruiker kan de promocode toevoegen en een korting krijgen voor de kassa
  • Het systeem moet betalingstransacties veilig verwerken via geïntegreerde betalingsgateways
  • Het systeem stuurt een bevestigingsmail naar de gebruiker nadat ze een vlucht hebben geboekt
  • Gebruikers moeten feedback of tariefdiensten/producten binnen de app kunnen leveren

Banken en financiële systemen

  • Het systeem moet klanten in staat stellen fondsen over te dragen tussen rekeningen
  • Gebruikers moeten de transactiegeschiedenis kunnen bekijken gedurende de afgelopen 12 maanden
  • De toepassing moet het mogelijk maken de betaling van de rekening te plannen met terugkerende betalingsmogelijkheden
  • Het systeem moet maandelijkse rekeningafschriften genereren in PDF-formaat
  • Gebruikers moeten rekeningwaarschuwingen kunnen instellen voor specifieke transactietypes
  • Het systeem moet rekeningsaldo's verifiëren voordat het aanvragen van opnames verwerkt

Gezondheidszorgsystemen

  • Het systeem moet zorgverleners in staat stellen afspraken met patiënten te plannen
  • Medische medewerkers moeten toegang hebben tot medische dossiers van patiënten en deze kunnen bijwerken.
  • De aanvraag moet het beheer van de voorgeschreven geneesmiddelen mogelijk maken en verzoeken om navulling mogelijk maken.
  • Het systeem moet automatisch afsprakenherinneringen genereren via e-mail en SMS
  • Zorgverleners moeten de resultaten van de patiënttests en diagnostische rapporten kunnen bekijken
  • Het systeem moet de integratie van elektronische medische dossiers met externe systemen ondersteunen.

Inhoudsbeheer en sociale media

  • Het systeem moet blog bezoekers in staat stellen zich aan te melden voor de nieuwsbrief door hun e-mail achter te laten
  • Gebruikers moeten in staat zijn om inhoud te maken, bewerken en publiceren met rijke tekstopmaak
  • Het systeem moet inhoud categoriseren met behulp van tags en categorieën mogelijk maken
  • Gebruikers moeten mediabestanden kunnen uploaden en beheren, inclusief afbeeldingen en video's
  • De app kan meldingen naar gebruikers sturen voor updates, herinneringen of promotionele inhoud
  • Het systeem moet zoekfunctionaliteit bieden voor alle gepubliceerde inhoud
  • Gebruikers moeten inhoud kunnen delen op externe sociale mediaplatforms

Systemen voor de planning van de ondernemingsbron (ERP)

  • Hotel management software moet personeel in staat stellen om inkomende reserveringen te beheren, maken en beheren van tariefplannen, accepteren betalingen, genereren rapporten, enz.
  • Het systeem moet de inventarisniveaus bijhouden en automatische herordening van waarschuwingen genereren
  • Gebruikers moeten financiële verslagen kunnen genereren, inclusief winst- en verliesrekeningen
  • De aanvraag moet multi-currency transacties en conversies ondersteunen
  • Het systeem moet het mogelijk maken de tijd van de werknemer te volgen en de loonadministratie te verwerken
  • Gebruikers moeten in staat zijn om leveranciersrelaties en aankooporders te beheren

Mobiele toepassingsvoorbeelden

  • De app moet gebruikers in staat stellen om accounts te maken en in te loggen met behulp van referenties zoals e-mail en wachtwoord of via sociale media integratie
  • De toepassing moet offline modus ondersteunen met datasynchronisatie wanneer de verbinding hersteld is
  • Gebruikers moeten toegang hebben tot diensten en functies op locatie
  • De app moet pushmeldingen voor belangrijke updates en waarschuwingen mogelijk maken
  • Gebruikers moeten in staat zijn om de instellingen en voorkeuren van de app aan te passen
  • Het systeem moet biometrische authenticatie ondersteunen, inclusief vingerafdruk en gezichtsherkenning

What Are Niet-functionele vereisten?[

In systeemtechniek en vereistentechniek is een niet-functionele eis (NFR) een eis die criteria specificeert die kunnen worden gebruikt om de werking van een systeem te beoordelen, in plaats van specifieke gedragingen. Ze worden in contrast gebracht met functionele eisen die specifiek gedrag of functies definiëren.

In grote lijnen definiëren functionele eisen wat een systeem hoort te doen en niet-functionele eisen definiëren hoe een systeem hoort te zijn. Niet-functionele eisen (NFR's) definiëren hoe een systeem moet functioneren, waarbij het zich richt op prestaties, betrouwbaarheid en gebruikerservaring in plaats van specifieke kenmerken. Ze zorgen ervoor dat het systeem efficiënt, veilig en onderhoudbaar is in de tijd.

Niet-functionele eisen worden vaak de "kwaliteitskenmerken" van een systeem genoemd. De algemene eigenschappen van het systeem markeren meestal het verschil tussen het succes van het ontwikkelingproject of het mislukken ervan. Hoewel functionele eisen het systeem garanderen, garanderen niet-functionele eisen dat het goed werkt en voldoen aan de verwachtingen van de gebruiker voor kwaliteit, prestaties en betrouwbaarheid.

Het belang van niet-functionele eisen begrijpen

Het uitsluitend richten op functionele vereisten ten koste van niet-functionele eisen kan grote problemen veroorzaken. Functionele eisen kunnen worden beschouwd als voldaan zelfs als de niet-functionele eisen niet. Een transactie die 20 seconden duurt om succesvol te voltooien kan functioneel zijn ..maar het is zeker niet bruikbaar.

Niet-functionele vereisten hebben direct effect op de tevredenheid van de gebruiker, systeemadoptie en succes op lange termijn. Een systeem dat alle vereiste functies uitvoert, maar langzaam laadt, vaak crasht of beveiligingskwetsbaarheden presenteert, zal uiteindelijk niet voldoen aan zakelijke doelstellingen en gebruikersbehoeften.

Uitgebreide soorten niet-functionele eisen

Informeel worden deze soms de "zieken" genoemd, van attributen zoals stabiliteit en draagbaarheid.Kwalitaties die niet-functionele vereisten zijn .Kan worden onderverdeeld in twee hoofdcategorieën: Executiekwaliteiten, zoals veiligheid, beveiliging en bruikbaarheid, die zichtbaar zijn tijdens de werking (op het werk).Evolutiekwaliteiten, zoals testbaarheid, onderhoudbaarheid, uitbreidbaarheid en schaalbaarheid, die belichaamd zijn in de statische structuur van het systeem.

Prestatievereisten

Prestatievereisten specificeren hoe het systeem moet reageren op zware gebruikersbelasting. Dit houdt in dat metrieken zoals opstarttijd, responstijd, latentie en het maximale aantal gelijktijdige gebruikers die de toepassing kan ondersteunen, gecontroleerd moeten worden.

De prestatie-eisen zijn van cruciaal belang om ervoor te zorgen dat systemen de verwachte werkbelasting zonder degradatie kunnen verwerken.

  • Respons Time: De maximale tijd die het systeem heeft om te reageren op verzoeken van gebruikers
  • Doorvoer: Het aantal transacties of operaties dat het systeem per tijdseenheid kan verwerken
  • Brongebruik: CPU, geheugen en bandbreedteverbruik onder verschillende belastingsomstandigheden
  • Concurrente gebruikers: Het aantal gelijktijdige gebruikers dat het systeem kan ondersteunen
  • Laadtijd: Hoe snel pagina's, schermen of gegevens laden voor gebruikers

Voorbeeld: Een prestatievereiste voor een banktoepassing zou zijn dat het transacties binnen 3 seconden moet kunnen verwerken, zelfs tijdens perioden van hoog gebruikersverkeer.

Beveiligingseisen

Beveiligingseisen bepalen hoe het systeem gegevens beschermt, ongeoorloofde toegang voorkomt en vertrouwelijkheid, integriteit en beschikbaarheid behoudt. Deze eisen worden steeds kritischer in het huidige dreigingslandschap.

De veiligheidsvoorschriften omvatten:

  • Authenticatie: Methoden voor het verifiëren van de identiteit van de gebruiker
  • Authorisatie: Toegangscontrolemechanismen en machtigingsniveaus
  • Gegevensversleuteling: Bescherming van gegevens tijdens de doorvoer en in rust
  • Audit Trails: Logging en monitoring van beveiligingsrelevante gebeurtenissen
  • Kwetsbaarheidsbescherming: Verdedigingen tegen gemeenschappelijke veiligheidsbedreigingen
  • Gegevensprivacy: Naleving van privacyvoorschriften en gegevensbeschermingsnormen

Voorbeeld: Gegevens moeten zowel tijdens de doorvoer worden gecodeerd met behulp van TLS 1.3 als in rust met behulp van AES-256 encryptiestandaarden.

Bruikbaarheidseisen

Gebruikbaarheid gaat in principe over gebruiksvriendelijkheid. Dat betekent dat de productinterface intuïtief en gemakkelijk te navigeren moet zijn, de functies moeten begrijpelijk en gemakkelijk te vinden zijn, en het belangrijkste, het moet voldoen aan de behoeften van de gebruiker.

Gebruiksvereisten:

  • Verlichting: Hoe snel nieuwe gebruikers productief kunnen worden met het systeem
  • Efficiency: Hoe snel ervaren gebruikers taken kunnen uitvoeren
  • Bedenking: Hoe gemakkelijk gebruikers na een periode van niet-gebruik naar het systeem kunnen terugkeren
  • Foutpreventie: Ontwerpkenmerken die gebruikersfouten voorkomen
  • Gevreesd: Hoe aangenaam en bevredigend het systeem is om te gebruiken
  • Toegankelijkheid: Steun voor gebruikers met een handicap en uiteenlopende behoeften

Voorbeeld: Nieuwe gebruikers moeten hun eerste transactie binnen 5 minuten kunnen voltooien zonder externe hulp of documentatie nodig te hebben.

Betrouwbaarheid en beschikbaarheidseisen

In deze reeks NFR's wordt gesteld dat het systeem zo veel mogelijk moet worden gebruikt en dat de stilstand tot een minimum moet worden beperkt. Betrouwbaarheidseisen garanderen dat het systeem in de loop van de tijd consequent en voorspelbaar functioneert.

De belangrijkste overwegingen zijn:

  • Bijgewerkte tijd: Percentage van de tijd dat het systeem operationeel en toegankelijk is
  • Mean Time Between Failures (MTBF): Gemiddelde tijd tussen systeemstoringen
  • Mean Time To Repair (MTTR): Gemiddelde tijd die nodig is om de systeemfunctionaliteit te herstellen
  • Fouttolerantie: Het vermogen van het systeem om door te gaan met werken ondanks storingen van onderdelen
  • Rampenherstel: Procedures en mogelijkheden om te herstellen van catastrofale storingen

Voorbeeld: Het systeem moet 99,9% van de tijd beschikbaar zijn, exclusief geplande onderhoudsramen, wat vertaalt naar niet meer dan 8,76 uur stilstand per jaar.

Schaalbaarheidseisen

De eisen inzake schaalbaarheid bepalen hoe het systeem groeit en zich aanpast aan de toegenomen vraag, of het nu gaat om gebruikers, datavolume of transactieverwerking. Deze eisen zijn essentieel voor systemen die naar verwachting in de loop van de tijd zullen groeien.

  • Horizontale schaalbaarheid: Mogelijkheid om meer servers of nodes toe te voegen om belasting te verdelen
  • Verticaal schaalbaarheid: Mogelijkheid om de middelen op bestaande servers te verhogen
  • Data Schaalbaarheid: Capaciteit om de groeiende gegevensvolumes te verwerken
  • Geografische schaalbaarheid: Steun voor uitbreiding naar nieuwe regio's of locaties

Voorbeeld: Het systeem moet 20 miljoen gebruikers kunnen verwerken zonder verslechtering van de prestaties.

Vereisten inzake instandhouding

Een onderhoudbaar systeem moet gedurende de verwachte levensduur kosteneffectief kunnen worden gehandhaafd en kan aanvullende eisen omvatten, zoals aanpassing, configureerbaarheid, uitbreidbaarheid en interoperabiliteit.

De houdbaarheid omvat:

  • Codekwaliteit: Standaarden voor codeleesbaarheid, documentatie en structuur
  • Modulariteit: Mate waarin de systeemcomponenten onafhankelijk en uitwisselbaar zijn
  • Testabiliteit: Gemak van het testen van systeemcomponenten en functionaliteit
  • Vertrouwbaarheid: Mogelijkheid om systeemgedrag te wijzigen zonder codewijzigingen
  • Uithoudingsvermogen: Gemakkelijk nieuwe functies en mogelijkheden toe te voegen

Naleving en regelgevingseisen

Niet-functionele eisen in de nalevingscategorie geven aan dat softwaresystemen moeten voldoen aan wettelijke en wettelijke voorschriften; de controlebaarheid is meestal ook in deze categorie opgenomen.

De nalevingsvoorschriften verschillen per sector en jurisdictie, maar omvatten gewoonlijk:

  • De betalingsverwerkingsgateway moet PCI DSS-compliant zijn
  • De klinische software moet voldoen aan de HIPAA (Health Insurance Portability and Accountability Act) en de AVG (General Data Protection Regulation)
  • Cloud datacenters moeten voldoen aan de beveiligingscertificering ISO 27001
  • Systemen moeten voldoen aan industriespecifieke normen zoals SOC 2, FISMA of FDA-regelgeving
  • Auditlogging en rapportagecapaciteiten voor naleving van de regelgeving

Verenigbaarheids- en interoperabiliteitseisen

Deze vereisten bepalen hoe het systeem werkt met andere systemen, platforms en technologieën. Ze zorgen voor naadloze integratie en gegevensuitwisseling in verschillende omgevingen.

  • Platformcompatibiliteit: Operating systems and devices the system must support
  • Browsercompatibiliteit: Webbrowsers en versies die ondersteund moeten worden
  • API-compatibiliteit: Normen en protocollen voor systeemintegratie
  • Data Format Compatibiliteit: Ondersteuning voor verschillende dataformaten en standaarden
  • Legacy System Integration: Mogelijkheid om met bestaande systemen te werken

Voorbeeld: Een programma dat draait op Windows 10 moet kunnen draaien op Windows 11 zonder enige verandering in het gedrag en de prestaties.

Capaciteitseisen

De capaciteitseisen specificeren het volume van de gegevens, transacties en gebruikers dat het systeem zowel nu als in de toekomst moet bevatten.

  • Opslagcapaciteit: Hoeveelheid gegevens die het systeem moet opslaan
  • Gebruikercapaciteit: Maximum aantal geregistreerde en gelijktijdige gebruikers
  • Transactievolume: Aantal verwerkte transacties per periode
  • Netwerkbandbreedte: Vereisten inzake gegevensoverdracht

Voorbeeld: De website pagina's moeten worden geladen in 3 seconden met het totale aantal gelijktijdige gebruikers < 5 duizend.

Gedetailleerde vergelijking: Functionele vs. Niet-functionele vereisten

Het begrijpen van de verschillen tussen functionele en niet-functionele vereisten is cruciaal voor een effectief beheer van eisen. Hier is een uitgebreide vergelijking:

Definitie en focus

Functionele vereisten sturen de toepassingsarchitectuur van een systeem, terwijl niet-functionele eisen de technische architectuur van een systeem aansturen. Functionele eisen beantwoorden "wat" het systeem doet, terwijl niet-functionele eisen beantwoorden "hoe goed" het doet.

Documentatiestijl

In het algemeen worden functionele eisen uitgedrukt in de vorm "systeem moet doen," terwijl niet-functionele eisen de vorm "systeem moet " zijn. Dit taalverschil weerspiegelt het fundamentele verschil in wat elk type eis specificeert.

Testbenadering

Functionele eisen worden doorgaans getest door middel van functionele testmethoden zoals unittests, integratietests en gebruikersacceptatietests. Elke functionele eis kan worden geverifieerd door te controleren of het systeem de verwachte output voor bepaalde inputs produceert.

Meet niet-functionele vereisten: Eigenschappen zijn gemakkelijker te testen, maar kwaliteiten zoals bruikbaarheid, schaalbaarheid en betrouwbaarheid zijn moeilijker te meten en valideren. Niet-functionele eisen vereisen gespecialiseerde testbenaderingen, waaronder prestatietesten, beveiligingstesten, gebruiksvriendelijkheidstests en stresstests.

Effect op het succes van het project

Functionele en niet-functionele vereisten zijn twee zijden van dezelfde munt. Samen creëren ze software die compleet en bruikbaar is. Beide types zijn essentieel, maar ze beïnvloeden projecten anders:

  • Functionele eisen bepalen of het systeem de vereiste taken kan uitvoeren
  • Niet-functionele vereisten bepalen of gebruikers het systeem daadwerkelijk willen gebruiken
  • Ontbrekende functionele eisen resulteren in onvolledige functies
  • Ontbrekende niet-functionele eisen leiden tot slechte gebruikerservaring en systeemkwaliteit

Prioriteringsuitdagingen

Functionele vereisten krijgen vaak meer aandacht, terwijl belangrijke aspecten zoals schaalbaarheid, beveiliging of monitoring over het hoofd worden gezien. Deze onevenwichtigheid kan leiden tot systemen die technisch werken maar niet voldoen aan de kwaliteit van de verwachtingen of zakelijke behoeften.

Waarom beide vereisten cruciaal zijn voor projectsucces

Functionele vereisten zijn de ruggengraat van succesvolle software- en systeemontwikkeling. Ze definiëren precies wat een product moet doen om aan de behoeften van de gebruiker en het bedrijfsleven te voldoen. Door het specificeren van de functies en gedragen moet een systeem vertonen, functionele eisen ervoor zorgen dat elke functie in lijn is met de verwachtingen van de gebruiker en de projectdoelstellingen.

De functionele eisen zijn echter onvoldoende. Beide soorten eisen werken samen om succesvolle systemen te creëren:

Duidelijkheid en richting bieden

Having clearly defined functional requirements reduces the risk of miscommunication between stakeholders and your development team. This w