Requirements

Functional Requirements

Een functionele eis beschrijft een handeling die het product moet uitvoeren om nuttig te zijn voor de gebruiker — deze eisen komen voort uit het werk dat je stakeholders moeten doen.

• Dingen die het product moet doen
• Specificeert wat het systeem moet doen
• Handelingen die het product moet uitvoeren
• Afgeleid van het hoofddoel van het product
• Geen kwaliteitseigenschap
• Wordt gekenmerkt door werkwoorden

Voorbeelden

• Het systeem moet gebruikers laten inloggen met e‑mail en wachtwoord.
• Het systeem moet een bevestigingsmail sturen na elke bestelling.
• De gebruiker moet producten kunnen zoeken op naam en categorie.
• Het systeem moet maandelijkse rapportages genereren in PDF‑formaat.
• De applicatie moet betalingen kunnen verwerken via Uni5Pay+ en creditcard.
• De student moet zijn cijfers online kunnen raadplegen.

Non-functional Requirements

Niet-functionele eisen zijn eigenschappen of kwaliteiten die het product moet hebben om acceptabel te zijn voor de eigenaar en gebruiker.

• In sommige gevallen zijn niet-functionele eisen — zoals performance, look-and-feel, usability, security en juridische eigenschappen — cruciaal voor het succes van het product.
• Soms zijn het eisen omdat ze het product verbeteren of aantrekkelijker maken.
• Soms zorgen ze ervoor dat het product bruikbaar is.
• Eigenschappen of kwaliteiten die het systeem moet hebben.
• Worden gekenmerkt door bijvoeglijke naamwoorden.
• Checklist:
  • Look-and-feel
  • usability
  • performance
  • onderhoudbaarheid
  • portabiliteit

Voorbeelden

• De website moet binnen 2 seconden laden bij normaal gebruik. (performance)
• Het systeem moet 24/7 beschikbaar zijn met een uptime van minimaal 99,5%. (betrouwbaarheid)
• De gebruikersinterface moet intuïtief en eenvoudig te gebruiken zijn zonder training. (usability)
• Gevoelige gegevens moeten versleuteld worden opgeslagen volgens de ISO richtlijnen. (security, juridisch)
• De applicatie moet onderhoudbaar zijn zodat een ontwikkelaar in < 1 dag een eenvoudige wijziging kan doorvoeren. (onderhoudbaarheid)
• De oplossing moet op zowel mobiele apparaten als desktop goed werken. (portabiliteit / compatibiliteit)

Scoping the Business Problem

Afbakening van het businessprobleem. Een afbakening van het bedrijfsgebied dat moet worden gewijzigd, zodat het projectteam een duidelijke visie heeft op wat het project moet bereiken.

• De scope is de omvang van het bedrijfsgebied dat door het product wordt beïnvloed.
• Omdat het een deel van een echte organisatie afbakent, wijst de scope naar de stakeholders — de mensen die belang hebben bij, of invloed hebben op, het succes van het werk.
• De stakeholders bepalen op hun beurt de doelen: de verbeteringen die het bedrijf wil bereiken wanneer het product wordt geïmplementeerd.
• Scheid de activiteiten waarin je geïnteresseerd bent — de activiteiten binnen jouw werk — van andere activiteiten die voor jou niet relevant zijn. Die laatstgenoemde activiteiten vallen buiten de scope van je werk.
• De werkcontext laat zien waar de verantwoordelijkheden van het werk beginnen en eindigen, en waar die van aangrenzende systemen starten.

---

• Fundamenteel uitgangspunt:
  • Als er software wordt gebouwd, moet deze optimaal waardevol zijn voor de eigenaar.
• Wat doet de eigenaar
  • Wat is de scope
• Met of voor wie doet de eigenaar dit
  • Wie zijn de stakeholders
• Waarom wil de eigenaar dit doen
  • Wat zijn de doelen

Goals

Doelen: Wat wil je bereiken?

• Het projectdoel is de hoogste vorm van requirement.

Doelstelling

• De doelstelling van het project is niet alleen het oplossen van het probleem, maar ook het creëren van een bedrijfsvoordeel voor de eigenaar van het product.
• Als er een voordeel is, moet het meetbaar zijn.

Constraints

Constraints zijn globale beperkingen die de requirements vormgeven.

• Het kunnen beperkingen zijn op het project zelf of restricties op het uiteindelijke ontwerp van het product.
• Constraints zijn globale eisen. Ze kunnen zowel projectbeperkingen zijn als beperkingen op het ontwerp van het product.

Een speciaal type requirement dat aanwijzingen geeft over waar je je inspanningen voor het verzamelen van requirements op moet richten.

---

• Wat ze ook beperken, constraints kunnen worden gezien als een ander type requirement.
• Het zijn globale factoren die de requirements beïnvloeden.
• Ze verwijzen naar elke beperking in de manier waarop het product wordt ontwikkeld.
• Bijvoorbeeld: verplichte ontwerpoplossingen, beperkte tijd of budget.

Globale requirements

• Beperkingen helpen bepalen welke subset van requirements kan worden opgenomen in het uiteindelijke product.
• Constraints beïnvloeden beslissingen over de scope van het product door de hoeveelheid tijd of geld die aan het project besteed mag worden te beperken.
• Soms is de constraint een vooraf bepaalde ontwerpbeslissing die de manier waarop het probleem wordt opgelost beperkt.
• Deze beperkingen worden opgeschreven alsof het reguliere requirements zijn.

Solution Constraints

• Verplichte ontwerpen of oplossingen
• Wanneer er slechts één acceptabele ontwerp-oplossing bestaat
  • Om een doorslaggevende reden: marketing, cultuur, management, politiek, klantverwachtingen of financieel
• Partner- of samenwerkingsapplicaties: interfaces met andere systemen
  • Bestaande databases, rapportagesystemen of webgebaseerde systemen

Project Constraints

• Beschrijven de tijd- en financiële budgetten voor het project

To Go or Not to Go

• Is het productdoel duidelijk en eenduidig, of bevat het vage termen?
• Is het doel meetbaar? Met andere woorden, geeft het een duidelijke indicatie wanneer het project succesvol is afgerond?
• Geeft het doel een daadwerkelijk voordeel voor de eigenaar?
• Is het haalbaar? Kunnen de doelstellingen van het project worden bereikt binnen de beschikbare tijd en het budget?
• Is er overeenstemming bereikt over de scope van het werk?
• Zijn er risico’s met een hoge kans om problemen te veroorzaken?
• Is de impact van deze risico’s zodanig dat het project onhaalbaar wordt?
• Is de kosten-batenanalyse van onderzoek redelijk gezien het voordeel van het product?
• Zijn de stakeholders bereid om betrokken te zijn?
• Heb je voldoende redenen om in het project te investeren?
• Zijn er genoeg redenen om niet in het project te investeren?
• Moet er nog aanvullend onderzoek worden gedaan voordat het requirements-project wordt gestart?