Specificatie van softwarevereisten schrijven (SRS document)

Wat is een SRS document?

SRS staat voor Software Requirements Specification, wat vrij vertaald specificaties van softwarevereisten betekend. In eenvoudige bewoordingen beschrijft de SRS aan welke eisen een softwaretoepassing moet voldoen.

Dit artikel is bedoeld om te demonstreren hoe je een SRS document schrijft.

Het document beschrijft het doel van de toepassing en de kenmerken die deze moeten bevatten. De applicatie doet precies wat de projecteigenaar wil door aan alle eisen te voldoen. Niet meer niet minder.

Succes hangt af van het hebben van een complete set van duidelijke, ondubbelzinnige, coherente en correcte vereisten. Het proces van het schijven van een specificatie van softwarevereisten zal ervoor zorgen dat aan deze succescriteria wordt voldaan.

Specificaties van softwarevereisten kunnen worden afgekort als SRS, maar deze kunnen worden verward met specificaties van systeemvereisten (system requirements specifications). Dit laatste definieert de vereisten voor een volledig systeem waarvan software een onderdeel kan zijn.

In dit artikel gebruiken we SRS uitsluitend om te verwijzen naar softwarevereisten.

Wie gebruikt een SRS document?

De specificaties van softwarevereisten legt de basis voor het softwareontwikkelingsproject dat de instructies bevat voor alle teams die bij het project betrokken zijn. Dit bevat:

1. Ontwikkelaars zullen het SRS documentgebruiken om software te ontwerpen en te implementeren die aan de vereisten voldoet.
2. Testers zullen de vereisten gebruiken om de tests te definiëren die nodig zijn om te controleren of de softwarevereisten zijn geïmplementeerd en om te valideren dat aan de vereisten van de klant is voldaan.
3. Operations kan het document gebruiken om bedrijfsprocessen en procedures vast te stellen voor in-service-implementatie van de software.
4. Beheerders kunnen het document gebruiken om onderhoudsprocessen en -procedures vast te stellen na de in-service-implementatie van de software.
5. Quality Assurance kan het gebruiken om te valideren dat aan de kwaliteitseisen is voldaan.
6. Projectmanagement kan het aantal eisen gebruiken om de benodigde resources en tijdschema's voor ontwikkeling in te schatten en de gegevens van geïmplementeerde eisen gebruiken om de voortgang te bewaken ten opzichte van plannen en klantrapportage.
7. Sales en Marketing kunnen het overzicht gebruiken om publiciteitsmateriaal te creëren en marktkansen te identificeren.
8. Het senior management kan het document gebruiken om extra investeringen aan te trekken.

Het document met de specificatie van de softwarevereisten beschrijft deze criteria voor alle teams en zorgt voor een consistentie en gemeenschappelijke einddoelen, die essentieel zijn voor het succes van projecten.

Dit kan een uitdaging zijn wanneer ontwikkelaars termen gebruiken die klanten, gebruikers of zelfs hun eigen managers niet kunnen begrijpen.

Een document hebben dat alle stakeholders kunnen begrijpen en precies hetzelfde beeld van de vereisten hebben, is het uiteindelijke doel van de SRS.

Wat moet een SRS document bevatten?

De inhoud van de SRS moet de volgende zeven essentiële elementen bevatten:

1. Een duidelijke definitie van het doel van de software, waarin wordt vastgelegd waarvoor de software bedoeld is:

• Wat probeert de software te bereiken?
• Wie zal de software gebruiken, als in demografie en capaciteiten?
• Hoe past de software in een breder landschap?
• Wat is de waardepropositie?
• Wat zijn de succescriteria?

2. Ondubbelzinnige definities van alle productterminologie opgenomen in productbeschrijvingen en vereisten.

Deze definities moeten alle kernbegrippen duidelijk en ondubbelzinnig omschrijven. Er moet een gemeenschappelijk begrip zijn tussen de diverse projectteams van de formulering van de softwarevereisten.

3. Een productbeschrijving die bepaalt welke functionaliteiten vereist zijn voor elk van de geïnteresseerde partijen die interactie met de softwaretoepassing zullen hebben.

Deze partijen omvatten doorgaans:

• Gebruikers
• Beheerders
• Onderhouders
• Externe dienstverleners

4. Een volledige lijst van alle toepasselijke aannames, variabelen en vereisten die tijdens het ontdekkingsproces zijn geïdentificeerd en die het ontwikkelingsproces zullen beperken of beïnvloeden.

5. De eisen, de kern van het specificatiedocument voor softwarevereisten, onderverdeeld in:

• Functionele eisen, het vaststellen van het gewenste gedrag van de software.
• Niet-functionele vereisten, het definiëren van technologieën, infrastructuur, prestaties, schaalbaarheid, kwaliteitskenmerken en andere niet-gedragsvereisten.
• Gebruikersvereisten, use cases die bepalen hoe gebruikers zullen omgaan met de software en de beoogde gebruikersinterface-ervaring.
• Interfacevereisten, waarin wordt beschreven hoe de software zal werken met hardware, firmware of softwarefuncties van derden, inclusief tijdelijke beperkingen.

Raadpleeg voor meer gedetailleerde informatie over typen vereisten onze blog over functionele vereisten vs niet-functionele vereisten.

6. Voorwaarden voor acceptatie van software, die bepalen hoe de ontwikkelde software moet worden gevalideerd tegen zijn vereisten, bewust van de doelen van de projecteigenaar.

Voor meer gedetailleerde informatie verwijzen we naar onze blog over acceptatiecriteria.

7. De traceability van alle softwarevereiste tot de bronvereiste van de klant toont aan dat alle zakelijke vereisten van de klant worden vertegenwoordigd door een of meer softwarevereisten.

Dit vergemakkelijkt ook een efficiënt en effectief wijzigingsbeheer en regressietest analyses als de klant wijzigingen in zijn vereisten aanbrengt.

Traceability geeft aan welke softwarefuncties worden beïnvloed, vereenvoudigt het wijzigingsproces en schat de benodigde inspanning nauwkeurig in.

Een uitstekend SRS document schrijven

Het resultaat van de ontdekkingsfase is een reeks belangrijke resultaten die de ontwikkelingsfasen ondersteunen.

Een complete en uitgebreide reeks van deliverables van de ontdekkingsfase van het project, maakt de ontwikkeling sneller en eenvoudiger, waardoor het risico op problemen en functionele hiaten wordt verkleind.

1. De SRS moet de klant de zekerheid bieden dat zijn zakelijke behoeften correct zijn begrepen. Deze behoeften zijn in het geheel zijn opgenomen in de softwarevereisten, en deze behoeften zullen worden aangepakt.
2. De SRS moet begrijpelijk zijn, waardoor het gebruik van simpele taal nodig is in plaats van wiskundige notaties. De SRS moet echter nauwkeurig en ondubbelzinnig zijn, wat het taalgebruik beperkt. De balans tussen begrijpelijkheid en eenduidigheid is een uitdaging.
3. De SRS moet complexe problemen opsplitsen in gecompartimenteerde oplossingen die kunnen worden geprioriteerd en beheerd met behulp van agile ontwikkelingstechnieken.
4. De SRS moet een solide basis bieden voor de ontwikkelingslevenscyclus en de ontwerp-, test- en assurance-processen ondersteunen.

De belangrijkste kenmerken die een uitstekende SRS maken, zijn:

1. Volledigheid, alle vereisten zijn geïdentificeerd en gedocumenteerd, waarbij elke klantbehoefte wordt vertegenwoordigd door een of meer softwarevereisten. Alle aannames zijn gedefinieerd en gevalideerd, alle afhankelijkheden en voorwaarden zijn geïdentificeerd en voldaan.
2. Correctheid, alle eisen zijn correct en voldoen aan de algemene eisen van de klant.
3. Samenhang, alle vereisten vullen elkaar aan, zonder conflicten door tegenstrijdigheden tussen individuele vereisten.
4. Ondubbelzinnig, alle eisen zijn duidelijk gedefinieerd met behulp van overeengekomen terminologie zonder ruimte voor verkeerde interpretatie.
5. Implementatie-agnostisch, de specificatie van vereisten mag geen architecturale of technologische oplossingen opleggen of een ontwerpmethodologie, ontwikkelingsproces of codeertaal specificeren.
6. Onderhoudbaarheid, wijzigingen in de eisen van de klant tijdens het ontwikkelingsproces kunnen zodanig worden beheerd dat verstoringen tot een minimum worden beperkt en een efficiënte switch van ontwikkelingsactiviteiten mogelijk wordt gemaakt.
7. Verantwoording, change management wordt bijgehouden om te controleren waarom wijzigingen worden aangebracht en wie de wijzigingen heeft geautoriseerd, waardoor terugdraaien mogelijk is in het geval van onbedoelde ontwikkelingen of alternatieve oplossingen.
8. Traceability, een duidelijke relatie van klantvereisten tot softwarevereisten zal validatieprocessen vergemakkelijken, volledigheid aantonen en veranderingsbeheerprocessen en regressietesten ondersteunen na wijzigingen in klantvereisten.

Het schrijven van effectieve vereisten

Alle vereisten moeten gemakkelijk te lezen en te begrijpen zijn om effectief te zijn. Ze moeten een onderwerp definiëren en een eigenschap bevatten: een voorwaarde, actie of resultaat. Bijvoorbeeld: "De software moet de lokale tijd weergeven aan de gebruiker". Hier is de eigenschap de tijdweergave. De eigenschap moet voldaan aan de volgende kenmerken:

• Uitvoerbaar
• Noodzakelijk
• Ondubbelzinnig
• Testbaar

De gebruikte tekst moet ook de aard van de eigenschap definiëren, bijvoorbeeld:

• Zullen en zal moeten zijn verplichte vereisten
• Kunnen en zou moeten zijn optionele vereisten 

Hieronder volgen voorbeelden van goed geschreven vereisten:

"De software moet de gebruiker toegang geven tot zijn ongelezen berichten in minder dan drie seconden."

"De software moet de gebruiker een indicatie geven dat de transactie succesvol is voltooid."

• De software is het onderwerp
• De toegang tot ongelezen berichten en een indicatie van succesvolle transacties zijn de eigenschappen
• Over het algemeen zijn beide vereisten testbaar

Daarentegen zijn de volgende voorbeelden slecht geschreven varianten van deze vereisten:

"De gebruiker zou snel toegang moeten hebben tot zijn ongelezen berichten met behulp van een smartphone."

"De gebruiker zou een vriendelijke e-mail of een ander type bericht moeten ontvangen die de transactie bevestigen."

• De gebruiker is het onderwerp, maar eisen kunnen niet aan de gebruiker worden gesteld, alleen de software
• Snel en gebruiksvriendelijk zijn subjectieve termen die niet te testen zijn
• De verwijzingen naar smartphones en e-mails zijn vooraf gedefinieerde oplossingen
• De formulering "of een ander type bericht" is dubbelzinnig en niet-testbaar
• Het gebruik van "zou moeten" impliceert dat de vereisten niet verplicht zijn

Andere veelvoorkomende problemen zijn onder meer meerdere voorwaarden in één zin wanneer een goede vereiste een enkele eigenschap zou moeten bevatten.

Het volgende voorbeeld omvat een groot aantal vereisten die elk te algemeen van aard zijn omdat ze niet precies specificeren wat de zakelijke behoefte is of wat de gebruikersvereisten zijn:

"Met de software kan de gebruiker contact opnemen met een helpdesk via livechat en contactformulieren, met functies voor het tracken van problemen en casebeheer."

Elke vereiste moet een indicatie bevatten van de prioriteit ervan om ontwikkeling te bevorderen.

Het moet ook een unieke identificatiecode hebben om traceability te ondersteunen, zowel richting de eisen van de klant om volledigheid aan te tonen, als het documenten beschrijven en testen ter ondersteuning van kwaliteitscontrole en de processen rondom change management.

Goedkeuringsprocedure

Een volledig SRS document zal het ontwikkelingsproces, de verificatie- en validatieactiviteiten aansturen.

Elke fout in de SRS wordt doorgevoerd in het ontwikkelingsproces en in de geïmplementeerde software. Bovendien zullen testactiviteiten die zijn gedefinieerd met behulp van de SRS en die worden uitgevoerd om de software te verifiëren, dergelijke fouten niet identificeren.

Eventuele fouten worden alleen vastgesteld wanneer de geïmplementeerde software niet voldoet aan de oorspronkelijke eisen van de klant bij de definitieve acceptatietests van het product.

Het ontdekken van fundamentele fouten in de validatiefase is kostbaar en moeilijk op te lossen, waardoor in feite volledige onderdelen van het ontwikkelingsproces moeten worden herhaald.

Daarom moeten alle belanghebbenden de SRS grondig herzien als een formeel acceptatieproces voordat het ontwikkelingswerk begint.

Waar het op neerkomt

De SRS is een essentieel document voor het softwareontwikkelingsproces.

Het ondersteunt de ontwikkeling en biedt een eensgezind beeld en routekaart voor alle stakeholders.

Het geeft precies aan wat de software moet doen en bepaalt het ontwikkelpunt wanneer dit is bereikt.

De eisen moeten volledig, duidelijk, ondubbelzinnig, coherent en correct zijn. De SRS zal het bereiken van deze doelen vergemakkelijken door:

• Providing the development team with a clear understanding of what exactly the customer wants
• Providing the customer with the assurance that the software will do what they want it to do
• Communicating all necessary information relating to the software to all interested stakeholders in terms they understand
• Characterizing users and defining user stories as implementable requirements
• Characterizing the required software behavior under all conditions and environments
• Providing the foundation for software testing activities
• Developing the outputs of the discovery phase and further scrutinizing possible risks
• Het ontwikkelteam een duidelijk beeld geven van wat de klant precies wil
• De klant de zekerheid bieden dat de software zal doen wat hij wil dat het doet
• Communiceren van alle noodzakelijke informatie met betrekking tot de software aan alle stakeholders, in termen die zij begrijpen
• Gebruikers karakteriseren en user stories definiëren als implementeerbare vereisten
• Karakteriseren van het gewenste gedrag van de software onder alle omstandigheden
• De basis leggen voor het testen van de software
• De output samenstellen van de ontdekkingsfase en het onderzoeken van mogelijke risico's

We hopen dat je nu weet hoe je een specificatie voor softwarevereisten moet schrijven en dat je begrijpt hoe de geleverde inspanning zal worden beloond met de efficiëntie van het ontwikkelingsproces, verminderde ontwikkelingsrisico's en verhoogde succespercentages.