Antwoord.

Geschiedenis van de vraag:

Oorspronkelijk waren systeemanalisten op IT-projecten voornamelijk gefocust op zakelijke vereisten, terwijl technische beperkingen vaak werden doorgegeven of genegeerd, wat leidde tot niet-functionerende of te dure oplossingen.

Probleem:

Technische beperkingen worden niet altijd gedeclareerd – de klant is zich er misschien niet van bewust, de ontwikkeling houdt er misschien geen rekening mee, en het resultaat kan in tegenspraak zijn met de mogelijkheden van de infrastructuur of integratiesystemen.

Oplossing:

De systeemanalist interviewt actief architecten, DevOps, QA, integratoren:

• Bepaalt technologische stacks, zakelijke en infrastructuurafhankelijkheden.
• Stem benodigde eisen af met architecturale principes: SLA, fouttolerantie, schaalbaarheid, licentie- of beveiligingsbeperkingen.
• Documenteert en valideert compromissen tussen mogelijkheden en wensen van de business.
• Past benaderingen zoals "Scenario-based analysis" en "Non-functional requirements" toe.

Belangrijke kenmerken:

• Vroegtijdige vastlegging van beperkingen en afhankelijkheden met alle betrokkenen.
• Documentatie van compromissen en impliciete beperkingen.
• Voortdurende afstemming van projectoplossingen met de architectuur van het bedrijf.

Vragen met een valstrik.

Kan men impliciete technische beperkingen negeren als ze niet direct zijn genoemd?

Juist: Nee. Impliciete technische beperkingen (bijvoorbeeld integratie time-outs, berichtgrootte limieten) vereisen altijd aandacht en vastlegging, zelfs als ze niet expliciet zijn genoemd.

Moet een analist deelnemen aan architectonische calls/workshops?

Juist: Ja, de systeemanalist is de schakel tussen de business en de architecten, en vertaalt de eisen naar beide partijen en documenteert de oplossingen.

Is het voldoende om alleen zakelijke vereisten te verzamelen en niet naar geërfde beperkingen te kijken?

Juist: Nee, dat is niet voldoende. Geërfde code, licenties, integraties (legacy) kunnen soms meer beperkingen dictëren dan de expliciet gedefinieerde vereisten.

Typische fouten en anti-patronen

• Het onderschatten van verborgen beperkingen en afhankelijkheden van oude systemen.
• Het negeren van "niet-handgeschreven" architectureregels.
• Alleen de zakelijke kant vastleggen zonder rekening te houden met technische uitvoerbaarheid.

Voorbeeld uit het leven

Negatieve case: De analist documenteerde de integratie volgens het bedrijfsproces, maar vroeg niet naar beperkingen in de snelheid van gegevensoverdracht in de interface.

Voordelen: Snelle implementatie van de specificatie. Nadelen: Het systeem kon de belasting niet aan, de business verloor geld en tijd.

Positieve case: De analist nam deel aan architecturale sessies, ontdekte beperkingen (maximaal aantal stroom = 100, integratie 1 keer in de 10 seconden), stemde de snijdende limieten af met de business.

Voordelen: Oplossing is werkend, duurzame integratie. Nadelen: Het was nodig om de functionaliteit compromisgewijs te verminderen en dit aan de klant te verantwoorden.