Eenduidige vereisten helpen ontwikkelteams bij het maken van het juiste product. En met een specificatie van software-eisen (SRS) legt u de basis voor productontwikkeling.
Wij leggen uit wat dit is, wanneer u er een kunt gebruiken en in vijf stappen een SRS-document kunt schrijven.
In vogelvlucht ziet u hoe u een document met vereisten schrijft:
- Bepaal het doel van uw product.
- Beschrijf wat u gaat bouwen.
- Detailleer de vereisten.
- Krijg het goedgekeurd.
Wat is een Software Requirements Specification (SRS) document?
Een software requirements specification (SRS) is een document waarin wordt beschreven wat de software gaat doen en hoe deze geacht wordt te presteren. Het beschrijft ook de functionaliteit die het product nodig heeft om aan de behoeften van alle belanghebbenden (bedrijven, gebruikers) te voldoen.
Een typische SRS bevat:
- Een doel
- Een algemene beschrijving
- Specifieke vereisten
De beste SRS-documenten definiëren hoe de software zal reageren wanneer deze in hardware wordt ingebed – of wanneer deze met andere software wordt verbonden. Goede SRS-documenten houden ook rekening met gebruikers uit de praktijk.
Waarom een SRS-document gebruiken?
Een software-eisen specificatie is de basis voor uw hele project. Het legt het raamwerk vast dat elk bij de ontwikkeling betrokken team zal volgen.
Het wordt gebruikt om kritische informatie te verstrekken aan meerdere teams – ontwikkeling, kwaliteitsborging, operations, en onderhoud. Zo blijft iedereen op de hoogte.
Het gebruik van het SRS helpt ervoor te zorgen dat aan de eisen wordt voldaan. En het kan u ook helpen beslissingen te nemen over de levenscyclus van uw product – bijvoorbeeld wanneer u een functie buiten gebruik stelt.
Het schrijven van een SRS kan ook de totale ontwikkelingstijd en -kosten minimaliseren. Vooral embedded ontwikkelteams hebben baat bij het gebruik van een SRS.
Software Requirements Specification vs. System Requirements Specification
Een software requirements specification (SRS) bevat een diepgaande beschrijving van de software die zal worden ontwikkeld.
Een systeemvereisten specificatie (SyRS) verzamelt informatie over de vereisten voor een systeem.
“Software” en “systeem” worden soms door elkaar gebruikt als SRS. Maar een specificatie van software-eisen is gedetailleerder dan een specificatie van systeemeisen.
>> Wilt u compliance bewijzen? Zo maakt u een traceerbaarheidsmatrix >>
Hoe een SRS-document te schrijven
Het schrijven van een SRS-document is belangrijk. Maar het is niet altijd gemakkelijk.
Hier volgen vijf stappen die u kunt volgen om een effectief SRS-document te schrijven.
Maak een schets (of gebruik een SRS-sjabloon)
Uw eerste stap is het maken van een schets voor uw software-eisen-specificatie. Dit kan iets zijn dat u zelf maakt. Of u gebruikt een bestaand SRS-sjabloon.
Als u dit zelf doet, ziet uw schets er als volgt uit:
1. Inleiding
1.1 Doel
1.2 Beoogd publiek
1.3 Beoogd gebruik
1.4 Reikwijdte
1.5 Definities en acroniemen
2. Algemene beschrijving
2.1 Behoeften van de gebruiker
2.2 Veronderstellingen en afhankelijkheden
3. Systeemeigenschappen en -eisen
3.1 Functionele Eisen
3.2 Externe Interface Eisen
3.3 Systeemeigenschappen
3.4 Niet-functionele Eisen
Als u eenmaal uw basis schets heeft, bent u klaar om te beginnen met het invullen ervan.
Download een whitepaper over best practices voor het schrijven van requirements >>
Start met een doel
De inleiding van uw SRS is erg belangrijk. Het stelt de verwachting voor het product dat u bouwt.
Dus begin met het definiëren van het doel van uw product.
Intended Audience and Intended Use
Definieer wie in uw organisatie toegang zal hebben tot het SRS – en hoe ze het moeten gebruiken. Dit kunnen ontwikkelaars, testers en projectmanagers zijn. Het kunnen ook belanghebbenden in andere afdelingen zijn, zoals leiderschapsteams, verkoop en marketing.
Product Scope
Beschrijf de software die wordt gespecificeerd. En vermeld voordelen, doelstellingen en objectieven. Dit moet verband houden met de algemene bedrijfsdoelen, vooral als teams buiten de ontwikkeling toegang krijgen tot het SRS.
Definities en acroniemen
Het is slim om een risicodefinitie op te nemen. Het vermijden van risico’s is voor veel ontwikkelaars van het grootste belang – vooral voor degenen die in veiligheidskritische ontwikkelteams werken.
Hier volgt een voorbeeld. Als je een medisch apparaat maakt, kan het risico zijn dat het apparaat faalt en een dodelijke afloop heeft.
Door dat risico van tevoren te definiëren, is het eenvoudiger om de specifieke vereisten te bepalen die nodig zijn om het risico te beperken.
>> Moet u een PRD maken? Hier is een how-to met voorbeelden >>
Geef een overzicht van wat u gaat bouwen
Uw volgende stap is een beschrijving geven van wat u gaat bouwen. Is het een update van een bestaand product? Is het een nieuw product? Is het een uitbreiding op een product dat u al hebt gemaakt?
Dit is belangrijk om van tevoren te beschrijven, zodat iedereen weet wat u gaat bouwen.
U moet ook beschrijven waarom u het gaat bouwen en voor wie het is.
Gebruikersbehoeften
Gebruikersbehoeften – of gebruikersklassen en -kenmerken – zijn van cruciaal belang. U moet bepalen wie het product gaat gebruiken en hoe.
U hebt primaire en secundaire gebruikers die het product op regelmatige basis zullen gebruiken. Misschien moet u ook de behoeften van een afzonderlijke koper van het product definiëren (die misschien geen primaire of secundaire gebruiker is). En als je bijvoorbeeld een medisch apparaat bouwt, moet je de behoeften van de patiënt beschrijven.
Aannames en afhankelijkheden
Er kunnen factoren zijn die van invloed zijn op uw vermogen om te voldoen aan de eisen die in uw SRS worden geschetst. Wat zijn die factoren?
Zijn er aannames die u doet met het SRS die onjuist zouden kunnen blijken te zijn? Ook die moet u hier vermelden.
Ten slotte moet u vermelden of uw project afhankelijk is van externe factoren. Denk bijvoorbeeld aan softwarecomponenten die u uit een ander project hergebruikt.
Detail uw specifieke eisen
Het volgende deel is belangrijk voor uw ontwikkelteam. Dit is waar u de specifieke eisen voor het bouwen van uw product beschrijft.
Functionele eisen
De functionele eisen zijn essentieel voor het bouwen van uw product.
Als u een medisch apparaat ontwikkelt, kan het onder meer gaan om een infuus en een batterij. En binnen deze functionele eisen, kunt u een subset van risico’s en eisen hebben.
Externe interface-eisen
Externe interface-eisen zijn soorten functionele eisen. Ze zijn belangrijk voor embedded systemen. En ze geven aan hoe uw product zal interfacen met andere componenten.
Er zijn verschillende soorten interfaces waarvoor u eisen kunt hebben, waaronder:
- Gebruiker
- Hardware
- Software
- Communicatie
Systeemeigenschappen
Systeemeigenschappen zijn soorten functionele eisen. Dit zijn eigenschappen die nodig zijn om een systeem te laten functioneren.
Andere niet-functionele vereisten
Niet-functionele vereisten kunnen net zo belangrijk zijn als functionele.
Deze omvatten:
- Prestaties
- Veiligheid
- Kwaliteit
Het belang van dit soort eisen kan variëren, afhankelijk van uw bedrijfstak. Veiligheidseisen, bijvoorbeeld, zullen van cruciaal belang zijn in de medische hulpmiddelen industrie.
IEEE biedt ook richtlijnen voor het schrijven van software-eisen specificaties, als u lid bent.
Geef goedkeuring voor de SRS
Als u de SRS eenmaal hebt voltooid, moet u deze laten goedkeuren door de belangrijkste belanghebbenden. En iedereen moet de laatste versie van het document kunnen inzien.
Het schrijven van een SRS in Microsoft Word vs. Requirement Software
U kunt uw software requirement specificatie in Microsoft Word schrijven. Een slimme manier om dit te doen is door een SRS template te maken die u kunt gebruiken als uitgangspunt voor elk project.
Hoewel, zelfs met een template, kan het schrijven van een SRS op deze manier een moeizaam proces zijn. En als een requirement verandert, kan je SRS snel achterhaald zijn. Bovendien kunnen er versieproblemen ontstaan met requirements-documenten in Word.
U kunt tijd besparen – en de nauwkeurigheid waarborgen – door in plaats daarvan een SRS in Helix ALM op te stellen.
Waarom Helix ALM beter is…
Helix ALM (dat wordt geleverd met een speciaal requirements management tool) voegt efficiency toe aan uw gehele requirements management proces.
Door een SRS aan te maken in Helix ALM, bent u verzekerd van een single source of truth op uw SRS. Het wordt eenvoudiger om requirements reviews van uw SRS uit te voeren. En dat helpt u om sneller goedkeuring te krijgen – zodat uw ontwikkelaars aan de slag kunnen.
Als u eenmaal requirements in een SRS heeft staan, kunt u deze eenvoudig gedurende uw hele ontwikkelproces beheren.
Als u ook een PRD schrijft, kunt u deze feature requirements koppelen aan de high-level requirement in de SRS. Dit creëert traceerbaarheid in uw requirements proces.
U kunt de vereisten in uw SRS ook koppelen aan tests. Dit helpt u ervoor te zorgen dat het product dat u levert voldoet aan het doel en de eisen van uw SRS.
Zie zelf hoe eenvoudig het kan zijn om een SRS te schrijven. Probeer Helix ALM gratis uit – en zie hoe een effectief SRS uw ontwikkelproces zal verbeteren. U kunt ook onze demo bekijken om meer functionaliteit te zien.
bespaar tijd bij het schrijven van een SRS in Helix ALM ▶️ bekijk eerst de demo