Antwoord.

SRS is een gestructureerd document dat alle vereisten voor het te ontwikkelen systeem beschrijft. De taak is om de bedrijfsverwachtingen zo eenduidig en volledig mogelijk naar de taal van het projectteam "te vertalen". Hoofdsecties:

1. Inleiding (doelen, toepassingsgebied, terminologie)
2. Productbeschrijving en zakelijke context
3. Beschrijving van gebruikers en hun rollen
4. Functionele vereisten (use cases, user stories)
5. Niet-functionele vereisten (beveiliging, prestaties, bruikbaarheid)
6. Beperkingen
7. Interfaces
8. Externe afhankelijkheden
9. Acceptatiecriteria voor vereisten
10. Woordenlijst

Belangrijke kenmerken:

SRS bevat zowel functionele als niet-functionele vereisten.
Vereisten worden eenduidig geformuleerd, met minimale dubbelzinnigheid.
In SRS worden gebruiksscenario's, beperkingen en criteria voor succesvol resultaat verplicht weergegeven.

Voor controle van volledigheid en kwaliteit maakt de analist gebruik van validatielijsten, sjablonen, IEEE 830-normen en regelmatige afstemming met belangrijke belanghebbenden.

Misleidende vragen.

Is het voldoende om alleen user stories te beschrijven voor een volledige SRS?

Nee. User stories tonen de functionele kant, maar dekken geen niet-functionele vereisten, beperkingen, interfaces, uitzonderingsscenario's en acceptatiecriteria.

Mag je verschillende termen gebruiken voor dezelfde entiteit in het document?

Nee. Het is noodzakelijk om consistentie in terminologie te handhaven: hiervoor wordt een woordenlijst gemaakt en vindt er kruisreview van het document plaats.

Moet SRS vereisten voor beveiliging en prestaties bevatten?

Ja. Niet-functionele vereisten zijn van cruciaal belang: het ontbreken ervan leidt tot technische schuld of onmogelijkheid van systeemgebruik.

Typische fouten en anti-patronen

Onvoldoende detail in vereisten, gebrek aan voorbeelden en acceptatiecriteria.
Gebruik van dubbelzinnige formuleringen: "snel", "gemakkelijk", "betrouwbaar" zonder numerieke specificaties.
Negeren van niet-functionele vereisten.

Voorbeeld uit het leven

Negatieve case

SRS is alleen gebaseerd op user stories, eisen voor prestaties en beveiliging zijn vergeten.

Voordelen:

Snelle totstandkoming van documentatie.

Nadelen:

Project heeft de beveiligingsaudit niet doorstaan, voldoet niet aan het vereiste aantal gelijktijdige gebruikers.

Positieve case

SRS omvat de volledige lijst van noodzakelijke attributen - functionaliteit, niet-functionele vereisten, acceptatiecriteria, woordenlijst.