De meest complete gids voor vereistenbeheer en traceerbaarheid

Hoe u systeemvereisten (SRS) -documenten schrijft

Een Software Requirement Specification Document (SRS) is een essentieel document voor softwareontwikkeling dat een gedetailleerde beschrijving geeft van de behoeften en vereisten van een bepaald project. Het schetst de doelstellingen, reikwijdte, achtergrondinformatie, ontwerpdetails, implementatieplan en andere gerelateerde activiteiten. Het SRS-document dient als een contract tussen de klant en de ontwikkelaar om ervoor te zorgen dat beide partijen de specificaties en verwachtingen begrijpen van het product dat wordt ontwikkeld. Bovendien helpt het om risico's te verminderen door ervoor te zorgen dat alle belanghebbenden volledig begrijpen wat er van hen wordt verwacht tijdens elke fase van het project.

Een goed opgesteld SRS-document moet volledig, duidelijk en beknopt zijn, zodat het gemakkelijk kan worden begrepen door zowel ontwikkelaars als klanten. Bovendien zorgt het hebben van een SRS ervoor dat eventuele wijzigingen of updates van het product tijdens de ontwikkeling eenvoudig kunnen worden gedocumenteerd en gevolgd. Dit helpt verwarring te minimaliseren en zorgt ervoor dat het eindproduct voldoet aan alle vereisten die in het document worden gespecificeerd. Over het algemeen is een SRS een cruciaal hulpmiddel voor succesvolle softwareontwikkelingsprojecten, omdat het een duidelijk raamwerk voor succes biedt. Bij correct gebruik kan het teams helpen om met minimale inspanning kwaliteitsresultaten te behalen.

Specificatie van softwarevereisten versus specificatie van zakelijke vereisten

Mensen mixen soms de concepten van software en specificaties van zakelijke vereisten. Eigenlijk zijn ze allebei heel anders.

Het belangrijkste verschil tussen specificatie van softwarevereisten en specificatie van bedrijfsvereisten is dat de eerste alle informatie met betrekking tot de software vastlegt, terwijl de laatste alle informatie met betrekking tot het bedrijf vastlegt.

S. Nee.	Specificatie softwarevereisten (SRS)	Specificatie bedrijfsvereisten (BRS)
1.	Het specificeert de functionele en niet-functionele vereisten die aanwezig zijn in de software.	Het is een formeel document dat de verschillende eisen beschrijft die door de klant/belanghebbenden worden gesteld.
2.	Het is afgeleid van de Business Requirements Specificatie (BRS).	Het is afgeleid van de eisen en interacties van de klant.
3.	Het is gemaakt door een systeemanalist of een systeemarchitect of een bedrijfsanalist.	Het is gemaakt door een bedrijfsanalist.
4.	Het beschrijft zowel de technische als functionele specificaties van de software ook op hoog niveau.	Het beschrijft de functionele specificaties van de software op een zeer hoog niveau.
5.	Het gaat over de middelen die het bedrijf ter beschikking stelt.	Het gaat over zakelijke vereisten.
6.	Het beschrijft hoe het bedrijf functioneert bij het gebruik van de software of applicatie.	Het definieert de behoeften van de klant. Het document wordt gebruikt van het begin tot het einde van het project.
7.	Tabellen en use cases zijn inbegrepen.	Tabellen en use cases zijn niet inbegrepen.

Essentiële onderdelen van een SRS

De belangrijkste secties van een specificatie van softwarevereisten zijn:

Zakelijke stuurprogramma's – De redenen waarom de klant een systeem wil bouwen, worden in deze sectie beschreven. In deze paragraaf wordt verder ingegaan op de problemen die de klant ondervindt met het huidige systeem en de kansen die het nieuwe systeem biedt.
Bedrijfsmodel – Het businessmodel dat het systeem moet ondersteunen, wordt in deze paragraaf besproken. Het bevat verder verschillende andere details, zoals de organisatorische en zakelijke context, de belangrijkste zakelijke functies en processtroomdiagrammen van het systeem.
Functionele en systeemvereisten – In deze sectie worden doorgaans vereisten beschreven die in een hiërarchische structuur zijn georganiseerd. De functionele vereisten bevinden zich op het hoogste niveau en de gedetailleerde systeemvereisten worden vermeld als subitems.
Systeemgebruiksscenario's – Deze sectie bestaat uit een Unified Modeling Language (UML) use case-diagram waarin alle belangrijke externe entiteiten worden uitgelegd die met het systeem zullen communiceren en de verschillende use-cases die ze moeten uitvoeren.
Technische vereisten – In deze sectie worden alle niet-functionele vereisten besproken die deel uitmaken van de technische omgeving en de technische beperkingen waarin de software zal werken.
Systeemkwaliteiten – In deze paragraaf worden de talrijke kwaliteiten van het systeem gedefinieerd, zoals betrouwbaarheid, bruikbaarheid, veiligheid, schaalbaarheid, beschikbaarheid en onderhoudbaarheid.
Beperkingen en veronderstellingen – Alle beperkingen die vanuit het oogpunt van de klant aan het systeemontwerp worden opgelegd, worden in deze sectie beschreven. Ook de verschillende aannames van het engineeringteam over wat te verwachten tijdens de ontwikkeling worden hier besproken.
Acceptatiecriteria – Details over alle voorwaarden waaraan moet worden voldaan voordat het systeem aan de eindklanten wordt overgedragen, worden in deze sectie besproken.

Structuur van een SRS

1. Inleiding -

De inleiding geeft uitleg over de betekenis van SRS in het algemeen, de reikwijdte voor uw team en de structuur ervan.

1.1. Doel

Leg hier het doel en de structuur van de SRS-softwaredocumentatie uit: de soorten vereisten die zullen worden aangepakt, evenals het personeel dat het zal gebruiken.

Houd dit gedeelte kort: 1-2 alinea's zijn voldoende.

1.2. Beoogde doelgroep

Je kunt de diepte in gaan en uitleggen hoe belanghebbenden en teams met SRS zullen werken, en ook deelnemen aan de ontwikkeling ervan. Dit zijn doorgaans producteigenaren, investeerders, bedrijfsanalisten, ontwikkelaars, soms testers en operationeel personeel. De hele structuur wordt bepaald door uw softwareontwikkelingsaanpak en de organisatiestructuur van het team.

1.3. Beoogd gebruik

Beschrijf in welke situaties uw team de SRS zal gebruiken. Meestal wordt het gebruikt in de volgende gevallen:

nieuwe functies ontwerpen en brainstormen
projectduur plannen, sprints, kosten inschatten
risico's evalueren
het succes van het team volgen en meten
conflicterende situaties wanneer betrokken partijen verschillende visies hebben op een goed uitgevoerd product.

1.4. strekking

Dit deel behandelt de reikwijdte van het product, dus u moet een snel overzicht geven van het systeem - het primaire doel, de functie en de positie ervan. Het is vergelijkbaar met hoe je een product zou uitleggen op een stakeholderbijeenkomst, behalve dat het is toegestaan om dieper in te gaan op technische details.

Dit gedeelte moet beschrijven:

Van alle soorten gebruikers wordt verwacht dat ze zich met het systeem bezighouden
Alle essentiële onderdelen van de architectuur

1.5 Definities en acroniemen

In uw document gebruikt het team regelmatig bepaalde woorden. Het elimineren van mogelijke misverstanden, het toestaan van nieuwe ontwikkelaars aan boord en het oplossen van conflicterende situaties zal allemaal gemakkelijker zijn als je de betekenis van deze woorden opheldert.

Bovenstaande onderdelen vormen een definitie. Definities bieden informatie over de functie, onderliggende technologieën, doelpersona's, zakelijke entiteiten (gebruikers, klanten, tussenpersonen) en belanghebbenden. U kunt een acroniem gebruiken om uw SRS sneller te schrijven als u daarvoor kiest. Het document is leesbaar zolang de tabel met definities het bevat.

2. Algemene beschrijving:

In het tweede deel beschrijf je de belangrijkste functies van het product, de beoogde gebruikers en de systeemomvang aan de lezers. Deze beschrijving concentreert zich alleen op de belangrijkste functies en software-architectuur zonder in te gaan op details over add-ons en verbindingen.

2.1 Gebruikersbehoeften

Dit onderdeel is een kwestie van keuze, dus sommige organisaties kiezen ervoor om het niet op te nemen in hun SRS-technische documentatie. Wij zijn van mening dat het beter is om de problemen die u met uw functionaliteit wilt oplossen nu op te sommen. Het zal later van pas komen tijdens brainstorm- en monitoringfuncties. U kunt op elk moment tijdens het productontwikkelingsproces teruggaan naar dit gedeelte en zien of het gebruikerservaringsteam niet is afgedwaald van het beoogde pad.

Behoeften verwijzen naar problemen die gebruikers met het systeem kunnen oplossen. Je kunt deze behoeften onderverdelen in subcategorieën als je te maken hebt met een sterk gesegmenteerd publiek. Probeer niet in details te treden over de behoeften van elke gebruiker. Je moet wat ruimte laten voor interpretatie, voor het geval een probleem belangrijker blijkt te zijn dan je aanvankelijk dacht.

2.2 Aannames en afhankelijkheden

Aannames zijn de aannames van het team over het product en zijn mogelijkheden die in 99% van de situaties correct zullen zijn. Het is bijvoorbeeld logisch om aan te nemen dat een platform dat bestuurders helpt bij nachtelijke navigatie, voornamelijk in de nachtmodus wordt gebruikt.

Wat is de betekenis van aannames? Hiermee kunt u zich eerst concentreren op de belangrijkste functies van de app. Deze veronderstelling helpt om te begrijpen dat ontwerpers een interface moeten ontwikkelen die geschikt is voor zicht in het donker voor een nachtrijassistent. Sommige gebruikers zullen de applicatie zeker overdag openen, maar het is een lange kans, dus u hoeft niet meteen gerelateerde elementen in het prototype op te nemen.

3. Systeemkenmerken en -vereisten

Dit deel behandelt de productkenmerken en uitvoeringscriteria in detail. Omdat de vorige twee secties het product als geheel behandelen, vindt u hier een uitgebreidere beschrijving.

3.1 Functionele vereisten

worden vermeld in een lijst met functies die in een systeem zullen worden uitgevoerd. Deze criteria hebben betrekking op "wat wordt er gecreëerd?" in plaats van 'hoe' en 'wanneer'.

Functionele vereisten beginnen met het beschrijven van de vereiste functionaliteit op basis van hoe essentieel deze is voor de toepassing. Als je er eerst aan wilt werken, kun je beginnen met ontwerpen, maar dan moet je gaan ontwikkelen. Functionele vereisten gaan niet in detail over technologie-stacks, omdat ze kunnen veranderen naarmate het project vordert. In plaats van zich te concentreren op interne logica, richten functionele vereisten zich op eindgebruikersfunctionaliteit.

3.2 Externe interface-eisen

Functionele vereisten vormen een belangrijk onderdeel van een specificatie van systeemvereisten. Om alle noodzakelijke functies van het systeem te behandelen, hebt u 4-5 pagina's met informatie nodig. Sommige teams splitsen ze op per thema om het document leesbaarder te maken.

Doorgaans wordt naar SRS-ontwerpcomponenten verwezen als los van de backend en bedrijfslogica. Dit is logisch omdat ontwerpers in plaats van ontwikkelaars het grootste deel van dit gebied afhandelen, maar ook omdat hier het productontwikkelingsproces zal beginnen.

Afhankelijk van het project kunnen externe interface-eisen uit vier typen bestaan:

Gebruikersinterface
Software-interface
Hardware interface
Communicatie-interface

Externe interfacevereisten beschrijven de pagina-elementen die zichtbaar zijn voor de eindklant. Ze kunnen de lijst met pagina's, ontwerpelementen, belangrijke stilistische thema's, zelfs artistieke elementen en meer bevatten als ze essentieel zijn voor het product.

3.3 Systeemvereisten

In de systeemeisen van het product staat onder welke omstandigheden het mag worden gebruikt. Ze hebben meestal betrekking op hardwarespecificaties en -functies. SRS-hardwarevereisten worden vaak bepaald door minimale en maximale bereiken, evenals een optimale drempel voor productprestaties.

Het opstellen van systeemvereisten voordat u begint met het maken van een product lijkt misschien moeilijk, maar het is essentieel. Ontwikkelaars moeten zich houden aan de hardwarevereisten, zodat ze het project later niet opnieuw hoeven te starten. Vooral mobiele apps (met veel variabelen waarmee rekening moet worden gehouden) en applicaties die een hoge reactiviteit vereisen (games, elk product met VR/AR of IoT) zijn kwetsbaar.

3.4 Niet-functionele vereisten

Voor veel organisaties is dit deel van een SRS het moeilijkst. Als functionele eisen betrekking hebben op de vraag wat te creëren, definiëren niet-functionele standaarden hoe. Ze stellen de criteria vast op basis van hoe effectief het systeem moet werken. Drempels voor prestaties, beveiliging en bruikbaarheid zijn allemaal opgenomen in dit gebied.

De echte waarde is wat het moeilijk maakt om niet-functionele vereisten te definiëren. Het definiëren van dergelijke uitdrukkingen als "gelijktijdigheid" of "draagbaarheid" is moeilijk omdat ze voor alle betrokken partijen verschillende interpretaties kunnen hebben. Daarom pleiten wij ervoor om elke niet-functionele eis een score te geven. U kunt uw projectvereisten op elk moment opnieuw bekijken om te zien of het huidige systeem voldoet aan de aanvankelijke verwachtingen.

Welke fouten moeten worden vermeden bij het opstellen van een specificatie van systeemvereisten?

Naarmate uw vaardigheden op het gebied van SRS-ontwikkeling toenemen, wordt het proces versneld. Desalniettemin, als je net begint, is het verstandig om een lijst met typische blunders bij de hand te hebben ter referentie. Denk daarom eens na over deze:

Verwaarlozing om een uitgebreide woordenlijst op te nemen: Bevat uw SRS jargon dat alleen bekend is bij mensen binnen de branche? Als dat het geval is, maak dan een eenvoudig te begrijpen woordenboekgedeelte en voeg definities toe van woorden of uitdrukkingen die niet algemeen bekend zijn. Dit zorgt ervoor dat alle gebruikers zowel het doel als de terminologie van het document kunnen begrijpen.
Waanzin creëren door ideeën te combineren: Structureer uw document op een ordelijke manier en zorg ervoor dat de informatie in een logische volgorde aan de lezers wordt verstrekt. Om misverstanden of verwarring te voorkomen, verwar concepten niet door de hele tekst heen.
Onwetendheid over de behoeften en wensen van de doelgroep: Om de verwachte output van software te begrijpen, is het belangrijk om te onderscheiden wie het gaat gebruiken en welke resultaten worden verwacht. Stel dat er bijvoorbeeld een app is gemaakt voor het maken van rapporten. Sommige van de vereisten moeten inhouden hoe gebruikers op bepaalde knoppen kunnen drukken om verschillende documenten te verkrijgen. Om echt te begrijpen wat er van dit rapportageprogramma wordt verlangd en ook te herkennen wie het gaat gebruiken, moet u inzicht hebben in zowel de gebruiker als zijn verwachtingen met betrekking tot functionaliteit.
Dubbelzinnig zijn: Zorg ervoor dat uw behoeften ondubbelzinnig zijn. Een SRS is opgesteld om misverstanden te voorkomen en daarom is het essentieel om ervoor te zorgen dat het document geen verwarring veroorzaakt. Zorg ervoor dat u voor elke kenmerk- of voorwaardebeschrijving geen functies opneemt die nog niet zijn gespecificeerd.

Best practices voor het schrijven van SRS-documenten

Het schrijven van een System Requirement Specification (SRS)-document is een cruciaal aspect van softwareontwikkeling, en het naleven van best practices kan de kwaliteit en effectiviteit van het document aanzienlijk verbeteren. Hier volgen enkele best practices voor het schrijven van SRS-documenten:

Gebruik duidelijke en beknopte taal:
- Vermijd technisch jargon en acroniemen die mogelijk niet door iedereen worden begrepen. Gebruik taal die duidelijk en duidelijk is, zodat alle belanghebbenden de inhoud gemakkelijk kunnen begrijpen.
Voeg visuele hulpmiddelen toe:
- Verbeter het begrip door diagrammen, stroomdiagrammen en mock-ups op te nemen naast tekstuele beschrijvingen van vereisten. Visuele hulpmiddelen kunnen een meer intuïtieve weergave bieden van complexe concepten en systeemgedrag.
Prioriteer vereisten:
- Definieer duidelijk de prioriteit van elke vereiste. Gebruik labels als ‘must-have’, ‘should-have’ en ‘nice-to-have’ om het relatieve belang van verschillende kenmerken aan te geven. Prioritering helpt het ontwikkelteam zich eerst te concentreren op kritieke functionaliteit.
Houd het bijgewerkt:
- Versiebeheer voor het SRS-document onderhouden. Werk het document regelmatig bij om eventuele wijzigingen in de projectvereisten, de reikwijdte of de feedback van belanghebbenden weer te geven. Houd een duidelijk wijzigingslogboek bij om wijzigingen in de loop van de tijd bij te houden.
Betrek belanghebbenden:
- Werk nauw samen met alle relevante belanghebbenden tijdens het SRS-ontwikkelingsproces. Neem deel aan discussies, verzamel feedback en zorg ervoor dat hun behoeften en verwachtingen nauwkeurig in het document worden vastgelegd. Deze betrokkenheid bevordert een gedeeld begrip van de projectdoelen.
Wees alomvattend:
- Laat geen ruimte voor interpretatie of veronderstelling. Geef gedetailleerde en uitgebreide beschrijvingen van elke vereiste, inclusief functionele en niet-functionele aspecten. Onduidelijkheid in eisen kan leiden tot misverstanden en projectvertragingen.
Gebruik een gestructureerd formaat:
- Organiseer het SRS-document in goed gedefinieerde secties, zoals Inleiding, Vereisten van belanghebbenden, Systeemarchitectuur, Functionele vereisten, Niet-functionele vereisten, Beperkingen, Aannames, Afhankelijkheden en een traceerbaarheidsmatrix. Een gestructureerd formaat maakt het voor lezers gemakkelijker om specifieke informatie te vinden.
Zorg voor testbaarheid:
- Schrijf vereisten op een manier die testen en validatie vergemakkelijkt. Elke eis moet verifieerbaar zijn, zodat testers testgevallen kunnen creëren die valideren of het systeem aan de gespecificeerde criteria voldoet. Duidelijke acceptatiecriteria per eis zijn essentieel.
Vermijd dubbelzinnigheid:
- Wees waakzaam over het elimineren van dubbelzinnigheid in de vereisten. Gebruik nauwkeurig taalgebruik, vermijd vage termen en zorg ervoor dat er geen ruimte is voor meerdere interpretaties van een vereiste. Onduidelijkheden kunnen leiden tot misverstanden en herbewerking van projecten.
Overweeg toekomstige schaalbaarheid:
- Denk na over de schaalbaarheid van het softwaresysteem op de lange termijn. Anticipeer op potentiële toekomstige behoeften en zorg ervoor dat het SRS-document hieraan tegemoet komt. Deze proactieve aanpak kan in de toekomst tijd en middelen besparen.
Beoordelen en valideren:
- Voer grondige beoordelingen van het SRS-document uit met belanghebbenden, waaronder de klant, het ontwikkelingsteam en deskundigen op het gebied van het onderwerp. Pak eventuele discrepanties, inconsistenties of dubbelzinnigheden aan die zich tijdens het beoordelingsproces voordoen. Validatie zorgt ervoor dat het document de doelstellingen van het project nauwkeurig weergeeft.
Formele goedkeuring verkrijgen:
- Nadat u het SRS-document hebt afgerond, verkrijgt u formele goedkeuring en ondertekening van de klant of projectsponsor. Dit formaliseert de overeenstemming over de reikwijdte en vereisten van het project en biedt een duidelijke basis voor ontwikkeling.

Het opnemen van deze best practices in het proces van het schrijven van SRS-documenten kan bijdragen aan het succes van softwareontwikkelingsprojecten. Een goed opgesteld SRS-document dient als een betrouwbare gids voor zowel het ontwikkelteam als de belanghebbenden, en helpt ervoor te zorgen dat het uiteindelijke softwaresysteem aansluit bij de verwachtingen en vereisten.

Conclusie

Het schrijven van een effectief System Requirement Specification (SRS)-document is een cruciale stap in het softwareontwikkelingsproces. Het dient als basis voor succesvolle projectplanning, ontwikkeling, testen en validatie. Door de stappen in dit artikel te volgen en u aan de best practices te houden, kunt u SRS-documenten maken die dienen als een betrouwbare gids voor het bouwen van softwaresystemen die voldoen aan de behoeften en verwachtingen van belanghebbenden.

Vergeet dit bericht niet te delen!