Een softwarevereistendocument schrijven (met sjabloon)

Herinner je je dat je op school 19e-eeuwse romans las en dacht: "Is dit wel dezelfde taal?" Nou, het is waarschijnlijk dat je precies die gedachte op kantoor hebt gehad bij het samenwerken met tech-minded AI-ontwikkelaars of web-savvy SEO-analisten. Waren er maar CliffsNotes voor collega's.

Soms is het essentieel dat afdelingen aan de andere kant 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. 

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

Wat is een softwarevereistenspecificatiedocument (SRS)?

Een software requirement specifications (SRS)-document somt de vereisten, verwachtingen, ontwerp en normen voor een toekomstig project op. Deze omvatten de algemene bedrijfsvereisten 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 biedt een gedetailleerde beschrijving van hoe een softwareproduct moet werken en hoe je ontwikkelingsteam het moet 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 eruitziet, maar je weet dat je niet zomaar een mondelinge beschrijving aan een ontwikkelaar kunt geven en kunt 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 samenstellen 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 softwarevereistenspecificaties levende documenten zijn, kunnen ze ook fungeren als een communicatiepunt tussen elke belanghebbende die betrokken is bij het productontwikkelingsproces. Productiteraties zullen onvermijdelijk plaatsvinden tijdens elk softwareontwikkelingsproject - door wijzigingen in de SRS op te merken, kunnen alle partijen ze in het document valideren. Dit zal eventuele verwarring over productvereisten verminderen. 

Wat moet je opnemen in een SRS-document?

Een basis SRS-document bestaat uit 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 inleiding 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:

• Projectbereik: 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 zal vinden in het product. 

• Beoogd publiek: beschrijf je ideale publiek. Zij bepalen de look en feel van je product 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 beste praktijk om use cases op te nemen om je visie te illustreren.

• Definities en acroniemen: elke branche of bedrijf heeft zijn eigen unieke acroniemen of jargon. Leg de definities uit 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 dat 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 breken systeemfuncties en functies af waarmee je systeem kan presteren 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 om op te nemen, 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 bewerkingen die voor elk scherm worden uitgevoerd

Als dit overweldigend aanvoelt, probeer het dan één vereiste per keer aan te pakken. Hoe meer detail je in je SRS-document kunt opnemen, hoe minder problemen je later zult moeten oplossen. 

Naarmate je gedetailleerde vereisten krijgt, 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, up-to-date instructies heeft.

3. Externe interfacevereisten

Externe interfacevereisten zijn soorten functionele vereisten die ervoor zorgen dat het systeem correct communiceert met externe componenten, zoals:

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

• 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 ingesloten formulieren. 

Ingebedde systemen vertrouwen op 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 (NRF'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 je systeem bijvoorbeeld 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, loop je het risico de verwachtingen van gebruikers of belanghebbenden niet te vervullen. 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. Het zijn:

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

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

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

• Betrouwbaarheid en beschikbaarheid: hoe vaak je verwacht 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 makkelijk 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? Onze SRS-sjabloon schetst alle vier de belangrijkste onderdelen 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 voor ogen 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 die je moet volgen om ervoor te zorgen dat je SRS zijn doel dient.

Verrijk je SRS met visuals

Het opnemen van afbeeldingen 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 de werking 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 getekend. 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 ze 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. Neem zoveel mogelijk details op bij het beschrijven van je softwarevereisten en vermijd:

• Het gebruik van vage woorden zoals over het algemeen of ongeveer

• terminaal combineren met een "/", wat kan worden geïnterpreteerd als "en" of "of"

• Gecompliceerde grenswaarden te gebruiken

• Dubbele en driedubbele negatieven te gebruiken

Een formele peer review is een goede manier om onduidelijkheden in je SRS-document te identificeren. 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 begrip te krijgen van 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 zich kan voordoen 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. 

Neem een marge voor flexibiliteit op

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

Gebruik softwarevereistendocumenten om je visie te verduidelijken

Een SRS schrijven is niet eenvoudig, maar eindeloos problemen oplossen of discussies tussen je teamleden navigeren ook niet. Het werk dat je in een uitgebreid softwarevereistendocument steekt, zal zijn vruchten afwerpen met een prachtig product waar jij en je belanghebbenden trots op kunnen zijn.