Een document met softwarevereisten schrijven (met sjabloon)

Herinner je je nog dat je op school 19e-eeuwse romans las en dacht: "Is dit wel dezelfde taal?" Waarschijnlijk heb je die gedachte ook op kantoor gehad bij het samenwerken met technisch ingestelde AI-ontwikkelaars of web-savvy SEO-analisten. Waren er maar CliffsNotes voor collega's.

Soms is het essentieel dat afdelingen aan weerszijden van een organisatie samenwerken, zelfs als ze verschillende technische talen spreken. Als je ooit in een cross-functional team hebt gewerkt, weet je hoe uitdagend het kan zijn om iedereen op één lijn te houden. 

Softwarevereistespecificatie-documenten kunnen projectmanagers, productmanagers en bedrijfsanalisten helpen om concepten op hoog niveau op te splitsen in actiepunten die elk teamlid tijdens het ontwikkelingsproces kan volgen. 

Wat is een software requirement specification document (SRS)?

Een software requirement specifications (SRS)-document bevat de vereisten, verwachtingen, het ontwerp en de normen voor een toekomstig project. Deze omvatten de bedrijfsvereisten op hoog niveau die het doel van het project bepalen, de vereisten en behoeften van de eindgebruiker en de functionaliteit van het product in technische termen. Eenvoudig gezegd, een SRS geeft een gedetailleerde beschrijving van hoe een softwareproduct zou moeten werken en hoe je ontwikkelingsteam het zou moeten laten werken.

Stel je voor dat je een geweldig idee hebt voor een App. Je hebt een visie van wat je wilt dat het doet en hoe je wilt dat het eruit ziet, maar je weet dat je niet zomaar een mondelinge beschrijving aan een ontwikkelaar kunt geven en verwachten dat deze aan je verwachtingen voldoet. Dit is waar een SRS van pas komt.

Waarom een SRS gebruiken?

Als ontwikkelaars geen duidelijke aanwijzingen hebben bij het maken van een nieuw product, kun je uiteindelijk meer tijd en geld besteden dan verwacht om de software te laten overeenkomen met wat je in gedachten had. 

Het opstellen van een SRS-document helpt je om je idee op papier te zetten en een duidelijke lijst met vereisten op te stellen. Dit document wordt de enige bron van waarheid van je product, zodat al je teams - van marketing tot onderhoud - op dezelfde lijn zitten. 

Omdat software-vereistespecificaties levende documenten zijn, dienen ze ook als een communicatiepunt tussen alle belanghebbenden die betrokken zijn bij het productontwikkelingsproces. Productiteraties zijn onvermijdelijk in elk softwareontwikkelingsproject. Door wijzigingen in de SRS vast te leggen, kunnen alle partijen deze binnen het document verifiëren om verwarring over productvereisten te voorkomen.

Als je team nog steeds de bredere bedrijfscontext achter je software definieert, koppel je je SRS aan een sjabloon voor bedrijfsvereistendocumenten om doelen, bereik en successtatistieken te definiëren voordat je de technische details documenteert.

Wat op te nemen in een SRS-document

Een basis SRS-documentoverzicht heeft vier delen: een inleiding, systeem- en functionele vereisten, externe interfacevereisten en niet-functionele vereisten.

1. Inleiding

Een SRS-introductie is precies wat je verwacht - het is een overzicht van het totale project. Beschrijf bij het schrijven van je introductie het doel van het product, de beoogde doelgroep en hoe de doelgroep het zal gebruiken. Zorg ervoor dat je in je inleiding het volgende opneemt:

• Productbereik: het bereik moet betrekking hebben op de algemene bedrijfsdoelen van het product, wat vooral belangrijk is als meerdere teams of aannemers toegang hebben tot het document. Maak een lijst van de voordelen, doelstellingen en doelen die voor het product zijn bedoeld. 

• Productwaarde: waarom is je product belangrijk? Hoe zal het je beoogde publiek helpen? Welke functie zal het vervullen, of welk probleem zal het oplossen? Vraag jezelf af hoe je publiek waarde in het product zal vinden. 

• Beoogd publiek: Beschrijf je ideale publiek. Zij zullen de look en feel van je product dicteren en hoe je het op de markt brengt. 

• Beoogd gebruik: stel je voor hoe je publiek je product zal gebruiken. Maak een lijst van de functies die je biedt en alle mogelijke manieren waarop je publiek je product kan gebruiken, afhankelijk van hun rol. Het is ook een goede praktijk om use-cases op te nemen om je visie te illustreren.

• Definities en acroniemen: elke branche of elk bedrijf heeft zijn eigen unieke acroniemen of jargon. Leg de definities vast van de termen die je in je SRS gebruikt om ervoor te zorgen dat alle partijen begrijpen wat je probeert te zeggen.

• Inhoudsopgave: een grondig SRS-document zal waarschijnlijk erg lang zijn. Voeg een inhoudsopgave toe om alle deelnemers te helpen precies te vinden wat ze zoeken. 

Zorg ervoor dat je introductie duidelijk en beknopt is. Vergeet niet dat je inleiding je gids zal zijn voor de rest van de SRS-schets, en je wilt dat deze door iedereen die het document gebruikt op dezelfde manier wordt geïnterpreteerd.

2. Systeemvereisten en functionele vereisten

Zodra je je introductie hebt, is het tijd om specifieker te worden. Functionele vereisten splitsen systeemfuncties en functies op die ervoor zorgen dat je systeem presteert zoals bedoeld. 

Gebruik je overzicht als referentie om te controleren of je vereisten voldoen aan de basisbehoeften van de gebruiker terwijl je de details invult. Er zijn duizenden functionele vereisten die je kunt opnemen, afhankelijk van je product. Enkele van de meest voorkomende zijn:

• Als/dan-gedrag

• Logica voor gegevensverwerking

• Systeemworkflows

• transactieverwerking

• Administratieve functies

• Regelgevings- en nalevingsbehoeften

• Prestatievereisten

• Details van de uitgevoerde bewerkingen voor elk scherm

Als dit overweldigend aanvoelt, probeer het dan één vereiste per keer aan te pakken. Hoe meer details je in je SRS-document kunt opnemen, hoe minder problemen je later hoeft op te lossen. 

Naarmate je in gedetailleerde vereisten komt, is het net zo belangrijk om je ondersteunende materialen consistent en gemakkelijk te volgen te houden. Een sjabloon voor technische documentatie kan tijd besparen, fouten verminderen en ervoor zorgen dat iedereen - van ontwikkelaars tot eindgebruikers - duidelijke, actuele instructies heeft.

3. Externe interfacevereisten

Externe interface-vereisten zijn soorten functionele vereisten die ervoor zorgen dat het systeem goed communiceert met externe componenten, zoals:

• Gebruikersinterfaces: de sleutel tot de bruikbaarheid van de applicatie, waaronder de presentatie van inhoud, navigatie door de applicatie en gebruikersondersteuning.

• Hardware-interfaces: de kenmerken van elke interface tussen de software- en hardwarecomponenten van het systeem, zoals ondersteunde apparaattypen en communicatieprotocollen.  

• Software-interfaces: de verbindingen tussen je product en andere softwarecomponenten, waaronder databases, bibliotheken en besturingssystemen. 

• Communicatie-interfaces: de vereisten voor de communicatiefuncties die je product zal gebruiken, zoals e-mails of ingebouwde formulieren. 

Ingebouwde systemen zijn afhankelijk van externe interfacevereisten. Je moet dingen opnemen zoals schermindelingen, knopfuncties en een beschrijving van hoe je product afhankelijk is van andere systemen. 

4. Niet-functionele vereisten (NFR's)

De laatste sectie van je SRS beschrijft niet-functionele vereisten. Terwijl functionele vereisten een systeem vertellen wat het moet doen, bepalen niet-functionele vereisten (NFR's) hoe je systeem deze functies zal implementeren. Een functionele vereiste kan bijvoorbeeld je systeem vertellen om een pakbon af te drukken wanneer een klant je product bestelt. Een NFR zorgt ervoor dat de pakbon wordt afgedrukt op wit papier van 4"x6", de standaardgrootte voor pakbonnen. 

Hoewel een systeem nog steeds kan werken als je niet aan NFR's voldoet, breng je mogelijk de verwachtingen van gebruikers of belanghebbenden in gevaar. Deze vereisten houden functionele vereisten in toom, dus het bevat nog steeds kenmerken zoals betaalbaarheid van het product en gebruiksgemak. 

De meest voorkomende soorten NFR's worden de 'Itys' genoemd. Dit zijn:

• Beveiliging: wat nodig is om ervoor te zorgen dat alle gevoelige informatie die je software van gebruikers verzamelt, wordt beschermd. 

• Capaciteit: De huidige en toekomstige opslagbehoeften van je product, inclusief een plan voor hoe je systeem zal opschalen voor toenemende volumebehoeften.

• Compatibiliteit: de minimale hardwarevereisten voor je software, zoals ondersteuning voor besturingssystemen en hun versies. 

• Betrouwbaarheid en beschikbaarheid: hoe vaak verwacht je dat gebruikers je software gebruiken en wat de kritieke uitvaltijd is bij normaal gebruik. 

• Schaalbaarheid: de hoogste werkbelastingen waaronder je systeem nog steeds zal presteren zoals verwacht. 

• Onderhoudbaarheid: hoe je applicatie continue integratie moet gebruiken, zodat je snel functies en bugfixes kunt implementeren. 

• Bruikbaarheid: hoe gemakkelijk het is om het product te gebruiken. 

Andere veel voorkomende soorten niet-functionele vereisten zijn prestatie-, regelgevings- en milieuvereisten. 

Sjabloon voor softwarevereistendocument

Klaar om je eigen softwareontwikkelingsonderneming te starten? Ons SRS-sjabloon schetst alle vier de belangrijkste componenten van een geweldig SRS-document, waardoor jij en je team waardevolle inzichten krijgen in het product dat je gaat ontwikkelen. Vergeet niet om je vereisten gedetailleerd, duidelijk en beknopt te houden, zodat alle partijen dezelfde visie in gedachten hebben.

Beste praktijken voor het schrijven van een SRS-document

Het doel van een SRS is om elk team in elke afdeling te laten werken aan een duidelijk doel. Dat gezegd hebbende, zijn er een paar beste praktijken om te volgen om ervoor te zorgen dat je SRS zijn doel dient.

Verrijk je SRS met visuals

Het opnemen van visuals zoals diagrammen, schema's en modellen zal teamleden helpen het proces beter te begrijpen. Deze zijn vooral handig bij het illustreren van de belangrijkste functies en bedienbaarheid van je software. 

Een techniek om te proberen tijdens het brainstormen over je project is mind mapping, waarbij ideeën, functies en scenario's worden georganiseerd en de verbanden tussen hen worden getrokken. Maak een mindmap om willekeurige gedachten te structureren terwijl je je ideeën begint samen te stellen. Deze visual hoeft niet super gedetailleerd te zijn - daar is je SRS voor. Concentreer je in plaats daarvan op de belangrijkste functies van je software en hoe deze zich tot elkaar verhouden.

Houd het duidelijk en beknopt

Het laatste wat je wilt is dat je ontwikkelaars aan zichzelf twijfelen bij het bouwen van je product. Probeer geen ruimte te laten voor teamleden om creatief te worden en de lege plekken in te vullen. Geef zoveel mogelijk detail bij het beschrijven van je softwarevereisten en vermijd:

• Het gebruik van vage woorden zoals algemeen of ongeveer

• Termen te combineren met een '/', wat kan worden geïnterpreteerd als 'en' of 'of'

• Het gebruik van ingewikkelde grenswaarden

• Dubbele en drievoudige negatieven te gebruiken

Een formele peer review is een goede manier om onduidelijkheden in je SRS-document aan te wijzen. Plan om het met elke deelnemer door te nemen om zijn of haar begrip van de vereisten te vergelijken en de nodige wijzigingen aan te brengen. 

Ken je eindgebruiker

Voeg je veldonderzoek en gebruikersinterviews toe aan de SRS om een duidelijk inzicht te krijgen in de vereisten, verwachtingen en behoeften van je eindgebruikers. Dit zou je moeten helpen de bewerkingen te visualiseren die je eindgebruiker met de software zal uitvoeren. Houd rekening met elk mogelijk scenario en elke nuance die kan gebeuren en neem deze op in je SRS. Vergeet niet dat je ontwikkelaars precies zullen implementeren wat je in het document opneemt - niet meer, niet minder. 

Voeg een marge voor flexibiliteit toe

Je SRS is een levend document, wat betekent dat je bij elke iteratie nieuwe functies en wijzigingen toevoegt. Houd daar rekening mee door de vereisten flexibel te houden voor het geval de uitkomst niet aan je verwachtingen voldoet. Het is ook een goede praktijk om de wijzigingen in het document bij te houden om misverstanden te voorkomen. Deelnemers moeten elke vereiste kunnen terugleiden naar het origineel en zien wie de wijziging aanbrengt, wanneer en waarom. 

Gebruik software-vereistendocumenten om je visie te verduidelijken

Het schrijven van een SRS is niet eenvoudig, maar dat geldt ook voor het eindeloos oplossen van problemen of het navigeren door argumenten tussen je teamleden. Het werk dat je in een uitgebreid document met softwarevereisten steekt, zal zijn vruchten afwerpen met een prachtig product waar jij en je belanghebbenden trots op kunnen zijn.