Business analyseBusinessanalist

Wat is de rol van een businessanalist bij het werken met niet-functionele vereisten, hoe deze te identificeren en te documenteren?

Slaag voor sollicitatiegesprekken met de Hintsage AI-assistent

Antwoord.

De businessanalist is verantwoordelijk voor het volledige verzamelen, overeenstemmen en documenteren van zowel functionele als niet-functionele vereisten: systeemsnelheid, beveiliging, schaalbaarheid, beschikbaarheid, gebruiksvriendelijkheid. Hiervoor werkt hij nauw samen met stakeholders (vooral met het bedrijfsleven en IT), gebruikt scenario's en analyseert normen. Hij moet niet alleen expliciete verwachtingen verzamelen, maar ook verborgen vereisten identificeren (bijvoorbeeld regelgeving inzake gegevensbescherming). Uiteindelijk formaliseert de analist niet-functionele vereisten in documentatie, stemt ze af met het projectteam en het technische team, en controleert hij de naleving van deze vereisten gedurende het hele project.

Belangrijke kenmerken:

  • Identificatie van verborgen en specifieke vereisten via interviews en standaardanalyse
  • Zorg voor documentatie en overeenstemming van niet-functionele vereisten
  • Toezicht op de overeenkomstigheid van de implementatie met de afgesproken niet-functionele criteria

Vragen met een addertje onder het gras.

Is het voldoende om niet-functionele vereisten in tekstvorm te beschrijven zonder meetwaarden en specificiteit?

Nee, abstracte formuleringen ("snel", "veilig") zijn niet bruikbaar voor validatie. Duidelijke parameters zijn vereist: bijvoorbeeld, een responsetijd van niet meer dan 2 seconden.

Zijn niet-functionele vereisten uitsluitend de zorg van technische specialisten?

Nee, de analist moet dergelijke vereisten identificeren en formaliseren samen met het bedrijfsleven, want het niet naleven ervan zal leiden tot ontevredenheid bij de belangrijke belangen van het bedrijf.

Is het mogelijk om te wachten met het werken aan niet-functionele vereisten tot de laatste fases van het project?

Nee, dergelijke vereisten zijn vaak cruciaal voor de architectuur van de oplossing. Het identificeren van deze vereisten in latere fasen leidt tot herwerkingen en hoge kosten.

Typische fouten en anti-patronen

  • Impliciete, formele of te algemene beschrijving van niet-functionele kenmerken
  • Negeren van veiligheidsnormen, SLA, juridische vereisten
  • Late identificatie van niet-functionele vereisten met het risico op aanzienlijke herwerkingen

Voorbeeld uit het leven

Negatieve casus: Verwacht "gebruiksgemak" en "snelheid" beschreven in de specificatie, zonder specifieke meetwaarden vast te leggen. Voordelen: Minder kosten op het moment van document schrijven. Nadelen: Geen klachten kunnen indienen bij het team toen het resultaat de klant niet tevredenstelde.

Positieve casus: Overeenstemming bereikt: "Paginalaad snelheid - tot 2 seconden bij een belasting tot 1000 gebruikers, SLA-niveau - 99,95%". Vereisten voor gegevensbescherming zijn geformaliseerd. Voordelen: Duidelijke controle van het resultaat, vermindering van herwerkrisico's, transparantie voor alle deelnemers. Nadelen: Vroeg tijd en afstemming met IT en juristen nodig.