features functional requirements
In deze zelfstudie worden de typen, kenmerken, vergelijking van functionele versus niet-functionele vereisten en zakelijke versus functionele vereisten uitgelegd met voorbeelden:
Functionele vereisten bepalen wat een softwaresysteem moet doen. Het definieert een functie van een softwaresysteem of zijn module. Functionaliteit wordt gemeten als een set van inputs naar het te testen systeem naar de output van het systeem.
De implementatie van functionele vereisten in een systeem wordt gepland in de systeemontwerpfase, terwijl het in het geval van niet-functionele vereisten wordt gepland in het systeemarchitectuurdocument. De functionele eis ondersteunt het genereren van de niet-functionele eisen.
Wat je leert:
- Functionele vereisten en niet-functionele vereisten
- Functionele versus niet-functionele vereisten
- Gevolgtrekking
Functionele vereisten en niet-functionele vereisten
Functionele vereisten
Laten we aan de hand van voorbeelden begrijpen wat functionele vereisten zijn:
Voorbeeld: In een Automotive ADAS-project zou een functionele eis van een surround-view-systeem kunnen zijn: 'Achteruitrijcamera moet een bedreiging of object detecteren'. Niet-functionele vereisten kunnen hier zijn 'hoe snel de waarschuwing voor een gebruiker moet worden weergegeven wanneer een bedreiging wordt gedetecteerd door camerasensoren'.
Neem een andere voorbeeld van het project Infotainmentsystemen. De gebruiker schakelt hier Bluetooth in vanaf HMI en controleert of Bluetooth is ingeschakeld of niet. Notitie , worden andere Bluetooth-services ingeschakeld (van grijs naar vet) wanneer de gebruiker Bluetooth inschakelt.
wat is de netwerksleutel op de router
Functionele vereisten spreken dus over een bepaald systeemresultaat wanneer een taak erop wordt uitgevoerd door de gebruiker. Aan de andere kant geeft de niet-functionele eis het algehele gedrag van het systeem of zijn component aan en niet de functie.
Soorten functionele vereisten
Functionele vereisten kunnen de volgende componenten omvatten die kunnen worden gemeten als onderdeel van functionele testen:
# 1) Interoperabiliteit: Vereiste beschrijft of een softwaresysteem interoperabel is tussen verschillende systemen.
Voorbeeld: Voor functionele Bluetooth-vereisten in het auto-infotainmentsysteem: wanneer de gebruiker een op Android gebaseerde Bluetooth-smartphone koppelt aan een op QNX gebaseerd infotainmentsysteem, zouden we in staat moeten zijn om het telefoonboek over te zetten naar het infotainmentsysteem of muziek te streamen van onze telefoon naar het infotainmentsysteem.
Interoperabiliteit controleert dus of communicatie tussen de twee verschillende apparaten mogelijk is of niet.
Een ander voorbeeld is van de e-mailservicesystemen zoals Gmail. Met Gmail kunt u e-mails importeren van een andere e-mailuitwisselingsserver zoals Yahoo.com of Rediffmail.com. Dit is mogelijk vanwege de interoperabiliteit tussen e-mailservers.
# 2) Beveiliging: Het functionele vereiste beschrijft het beveiligingsaspect van softwarevereisten.
Voorbeeld: Cyber Security-gebaseerde services in het ADAS surround-view camera-gebaseerde systeem dat gebruikmaakt van Controller Area Network (CAN) dat het systeem beschermt tegen de veiligheidsdreiging.
Een ander voorbeeld is van de sociale netwerksite Facebook De gegevens van een gebruiker moeten veilig zijn en mogen niet worden gelekt naar een buitenstaander. We hopen dat dit voorbeeld van Facebook lezers een bredere kijk op beveiliging biedt vanwege de recente incidenten met datalekken op Facebook en de gevolgen waarmee Facebook te maken heeft.
# 3) Nauwkeurigheid: Nauwkeurigheid bepaalt dat gegevens die in het systeem zijn ingevoerd, correct worden berekend en gebruikt door het systeem en dat de uitvoer correct is.
Voorbeeld: Wanneer in het Controller Area Network een CAN-signaalwaarde via een CAN-bus wordt verzonden door een ECU (d.w.z. ABS-eenheid, HVAC-eenheid, instrumentenpaneeleenheid, enz.), Kan een andere ECU vaststellen of de verzonden gegevens correct zijn of niet via CRC-check.
Een ander voorbeeld kan afkomstig zijn van een oplossing voor online bankieren. Wanneer de gebruiker een fonds ontvangt, moet het ontvangen bedrag exact op de rekening worden bijgeschreven en wordt er geen variatie in de nauwkeurigheid geaccepteerd.
# 4) Naleving: Functionele nalevingsvereisten bevestigen dat het ontwikkelde systeem voldoet aan industriële normen.
Voorbeeld: Of Bluetooth-profielfunctionaliteiten (nl. Audiostreaming via A2DP, telefoongesprek via HFP) voldoen aan Bluetooth SIG-releaseprofielversies.
Een ander voorbeeld kan dat zijn van Apple Car Play in Car-infotainmentsysteem. De App in het infotainment krijgt een certificaat van appel als aan alle voorwaarden die op de Apple-website worden vermeld, is voldaan door Car Play-apparaten van derden (in dit geval infotainment).
Een ander voorbeeld kan afkomstig zijn van een webgebaseerde toepassing voor het spoorwegkaartverkoopsysteem. De website moet de cybersecurity-richtlijnen volgen en wat betreft toegankelijkheid voldoen aan het World Wide Web.
Voorbeeld van een vereistenformulier:
Met enkele voorbeelden hebben we al gezien wat functionele eis is. Laten we nu eens kijken hoe een functionele vereiste eruit zou zien wanneer deze wordt geïntegreerd in tools voor vereistenbeheer, zoals IBM DOORS. Er zijn meerdere attributen waarmee rekening moet worden gehouden bij het documenteren van een functionele vereiste in de tool voor vereistenbeheer.
Hieronder staan enkele kenmerken waarmee u rekening moet houden:
- Object type: Dit attribuut legt uit welke sectie van het behoeftedocument deel uitmaakt van dit attribuut. Dit kunnen kop, uitleg, vereiste, enz. Zijn. Meestal wordt het gedeelte 'Vereiste' beschouwd voor de implementatie en testen, terwijl hoofdstukken met koppen en uitleg worden gebruikt als ondersteunende beschrijvingen voor vereisten voor een beter begrip.
- Verantwoordelijk persoon: Een auteur die de vereiste heeft gedocumenteerd in de tool voor vereistenbeheer.
- Project- / systeemnaam: Het project waarop de eis van toepassing is, bijvoorbeeld, 'Infotainmentsystemen voor XYZ OEM (Original Equipment Manufacturer) een autobedrijf of webapplicatie voor ABC Banking Limited Company'.
- Vereiste versienummer: Dit veld / kenmerk vermeldt het versienummer van de vereiste als de vereiste meerdere wijzigingen heeft ondergaan vanwege updates van de klant of wijzigingen in het systeemontwerp.
- Vereiste ID: Dit kenmerk vermeldt de unieke vereiste-ID. Requirement Id wordt gebruikt om de vereisten in de database eenvoudig te volgen en ook om de vereisten in code efficiënt in kaart te brengen. Het kan ook worden gebruikt om te verwijzen naar vereisten tijdens het loggen van defecten in bug-trackingtools.
- Vereiste beschrijving: Dit kenmerk is een van de belangrijkste kenmerken die de vereiste uitleggen. Door dit attribuut te lezen, zou een ingenieur de vereiste kunnen begrijpen.
- Vereiste status: Eisstatusattribuut zegt over de status van een vereiste in de tool voor behoeftebeheer, d.w.z. of het project is geaccepteerd, in de wacht, afgewezen of verwijderd.
- Opmerkingen: Dit attribuut biedt de verantwoordelijke persoon of vereistenbeheerder de mogelijkheid om eventuele opmerkingen over de vereiste te documenteren. Voorbeeld: een mogelijke opmerking voor een functionele vereiste zou kunnen zijn 'afhankelijkheid van een softwarepakket van een derde partij om de vereiste te implementeren'.
Een momentopname van DOORS
Functionele vereisten afleiden uit bedrijfsvereisten
Dit wordt al behandeld als onderdeel van de sectie ' Functionele vereisten afleiden uit zakelijke vereisten ' onder de Vereiste analyse artikel.
Zakelijke vereisten versus functionele vereisten
Dit verschil wordt losjes gedekt in de Vereiste analyse artikel. We zullen het echter proberen markeer hier nog een paar punten in de onderstaande tabel:
Sl. Nee. | Zakelijke vereisten | Functionele vereisten |
---|---|---|
7 | Bijvoorbeeld, in het online banksysteem zou een zakelijke vereiste kunnen zijn 'Als gebruiker zou ik een contant transactieoverzicht moeten kunnen krijgen'. | Functionele vereiste in dit systeem voor online bankieren zou kunnen zijn: 'Wanneer de gebruiker het datumbereik opgeeft in de transactieopvraag, wordt deze invoer gebruikt door de server en wordt de webpagina voorzien van de benodigde contante transactiegegevens'. |
1 | Zakelijke vereisten zeggen 'wat' -aspect van de klantvereiste. Voorbeeld, Wat moet zichtbaar zijn voor de gebruiker nadat de gebruiker zich heeft aangemeld. | Functionele vereisten zeggen 'hoe' aspect van zakelijke vereisten. Voorbeeld, Hoe de webpagina de aanmeldingspagina van de gebruiker moet weergeven wanneer de gebruiker zich verifieert. |
twee | Bedrijfsvereisten worden geïdentificeerd door bedrijfsanalisten. | Functionele vereisten worden gemaakt / afgeleid door ontwikkelaars / softwarearchitect |
3 | Ze benadrukken het voordeel voor de organisatie en zijn gerelateerd aan zakelijke doelstellingen. | Hun doel is de vervulling van de klantvereisten. |
4 | Zakelijke vereisten zijn van de klant. | Functionele vereisten zijn afgeleid van softwarevereisten, die op hun beurt zijn afgeleid van zakelijke vereisten. |
5 | Zakelijke vereisten worden niet rechtstreeks door Software Test Engineers getest. Ze worden meestal door de klant getest. | Functionele vereisten worden getest door Software Test-engineers en in het algemeen niet getest door klanten. |
6 | De zakelijke eis is een vereist document op hoog niveau. | Een functionele vereiste is een gedetailleerd technisch vereiste document. |
Niet-functionele vereiste
De niet-functionele eis zegt over “wat een systeem zou moeten zijn” in plaats van “wat een systeem zou moeten doen” (functionele eis). Ze zijn veelal afgeleid van functionele eisen op basis van input van de klant en andere stakeholders. Details van de implementatie van niet-functionele vereisten worden gedocumenteerd in het document Systeemarchitectuur.
Niet-functionele eisen verklaren de kwaliteitsaspecten van het te bouwen systeem, namelijk. prestatie, draagbaarheid, bruikbaarheid, enz. Niet-functionele vereisten, in tegenstelling tot functionele vereisten, worden stapsgewijs in elk systeem geïmplementeerd.
URPS (Bruikbaarheid, betrouwbaarheid, prestaties en ondersteuning) van FURPS (Functionaliteit, bruikbaarheid, betrouwbaarheid, prestaties en ondersteunbaarheid) kwaliteitsattributen die veel worden gebruikt in de IT-industrie om de kwaliteit van een softwareontwikkelaar te meten, vallen allemaal onder niet-functionele vereisten. Daarnaast zijn er ook andere kwaliteitsattributen (details in de volgende sectie).
Wikipedia noemt de niet-functionele vereiste soms ‘‘ ‘’, vanwege de aanwezigheid van verschillende kwaliteitsattributen zoals draagbaarheid en stabiliteit.
Soorten niet-functionele vereisten
Niet-functionele vereisten bestaan uit onderstaande subtypen (niet-uitputtend):
# 1) Prestaties:
Een prestatiekenmerktype van niet-functionele vereiste meet de systeemprestaties. Voorbeeld: In het ADAS surround view-systeem moet 'achteruitrijcamera-weergave worden weergegeven binnen 2 seconden na het starten van de auto-ontsteking'.
Een ander voorbeeld van de prestaties kan afkomstig zijn van een infotainmentsysteem Navigatiesysteem. 'Wanneer een gebruiker naar het navigatiescherm gaat en de bestemming invoert, moet de route binnen' X 'seconden worden berekend'. Nog een voorbeeld vanaf de aanmeldingspagina van de webtoepassing. 'Tijd die nodig is om de gebruikersprofielpagina te laden na inloggen.'
Houd er rekening mee dat het meten van de systeemprestaties anders is dan het meten van de belasting. Tijdens loadtests laden we de systeem-CPU en RAM en controleren we de systeemdoorvoer. In het geval van prestaties testen we de systeemdoorvoer onder normale belasting / stressomstandigheden.
# 2) Bruikbaarheid
Bruikbaarheid meet de bruikbaarheid van het te ontwikkelen softwaresysteem.
Bijvoorbeeld , is er een mobiele webapplicatie ontwikkeld die u informatie geeft over de beschikbaarheid van loodgieters en elektriciens in uw regio.
De invoer voor deze app is postcode en straal (in kilometers) vanaf uw huidige locatie. Maar om deze gegevens in te voeren, als de gebruiker door meerdere schermen moet bladeren en de optie voor gegevensinvoer wordt weergegeven in kleine tekstvakken die niet direct zichtbaar zijn voor een gebruiker, dan is deze app niet gebruiksvriendelijk en daarom zal de bruikbaarheid van de app zijn heel laag.
# 3) Onderhoudbaarheid
Onderhoudbaarheid van een softwaresysteem is het gemak waarmee het systeem kan worden onderhouden. Als de Mean Time Between Failures (MTBF) laag is of de Mean Time To Repair (MTTR) hoog is voor het systeem dat wordt ontwikkeld, wordt de onderhoudbaarheid van het systeem als laag beschouwd.
Onderhoudbaarheid wordt vaak gemeten op codeniveau met behulp van cyclomatische complexiteit. Cyclomatische complexiteit zegt dat hoe minder complex de code is, hoe gemakkelijker het is om de software te onderhouden.
unix shell scripting interviewvragen en antwoorden voor ervaren
Voorbeeld: Er wordt een softwaresysteem ontwikkeld met een hoog aantal dode codes (codes die niet worden gebruikt door andere functies of modules), zeer complex door overmatig gebruik van de if / else-voorwaarde, geneste lussen, enz. Of als het systeem enorm is met actieve codes in vele miljoenen regels codes en zonder de juiste commentaren. Een dergelijk systeem is laag in onderhoud.
Een ander voorbeeld kan een webpagina voor online winkelen zijn. Als er veel externe links op de website staan zodat de gebruiker een overzicht van het product heeft (dit om geheugen te besparen), dan is de onderhoudbaarheid van deze website laag. Dit komt omdat, als de externe webpagina-link verandert, deze ook te vaak moet worden bijgewerkt op de online winkelwebsite.
# 4) Betrouwbaarheid
Betrouwbaarheid is een ander aspect van beschikbaarheid. Dit kwaliteitskenmerk benadrukt de beschikbaarheid van een systeem onder bepaalde voorwaarden. Het wordt gemeten als MTBF, net als onderhoudbaarheid.
Voorbeeld: Wederzijds exclusieve functies zoals achteruitkijkcamera en Trailer in ADAS surround-view camerasysteem zouden betrouwbaar in het systeem moeten werken zonder enige interferentie met elkaar. Wanneer een gebruiker de Trailer-functie oproept, mag de achteruitkijkspiegel niet interfereren en vice versa, aangezien beide functies toegang hebben tot de achteruitrijcamera van de auto.
Een ander voorbeeld van het online verzekeringsclaimsysteem. Wanneer een gebruiker een claimrapportage start en vervolgens relevante onkostenrekeningen uploadt, moet het systeem voldoende tijd geven om het uploaden te voltooien en mag het uploadproces niet snel worden afgebroken.
# 5) Draagbaarheid:
Draagbaarheid betekent het vermogen van een softwaresysteem om in een andere omgeving te werken als het onderliggende afhankelijke raamwerk hetzelfde blijft.
Voorbeeld: Softwaresysteem / component in een infotainmentsysteem dat is ontwikkeld (nl. Bluetooth-service of multimediaservice) voor een autofabrikant moet het mogelijk maken om te worden gebruikt in een ander infotainmentsysteem met weinig of geen wijziging in code, hoewel de twee infotainmentsystemen totaal verschillend zijn .
Laten we er nog een nemen voorbeeld van WhatsApp. Het is mogelijk om de berichtenservice te installeren en te gebruiken op IOS, Android, Windows, Tablet, Laptop en Telefoon.
# 6) Ondersteunbaarheid:
Onderhoudsgemak van een softwaresysteem is het vermogen van een service- / technisch expert om het softwaresysteem in een realtime omgeving te installeren, het systeem te bewaken terwijl het draait, eventuele technische problemen in het systeem te identificeren en een oplossing te bieden om het probleem op te lossen.
Onderhoudsgemak is mogelijk als het systeem is ontwikkeld om onderhoudsgemak te vergemakkelijken.
Voorbeeld: Periodieke herinneringspop-up aan de gebruiker voor een software-update, logging / trace-mechanisme om problemen op te lossen, automatisch herstel na een fout via een terugdraaimechanisme (het softwaresysteem terugdraaien naar de vorige werkende staat).
Een ander voorbeeld van Rediffmail. Toen er een update was in de versie van de webgebaseerde mailingservice, stond het systeem de gebruiker toe om over te schakelen naar een nieuwere versie van het mailsysteem, waardoor de oudere enkele maanden intact bleef. Dit verbetert ook de gebruikerservaring.
# 7) Aanpassingsvermogen:
Het aanpassingsvermogen van een systeem wordt gedefinieerd als het vermogen van een softwaresysteem om zich aan te passen aan veranderingen in een omgeving zonder enige verandering in zijn gedrag.
Voorbeeld: Het antiblokkeerremsysteem in de auto moet in alle weersomstandigheden (warm of koud) volgens de norm werken. Een ander voorbeeld zou dat van een Android-besturingssysteem kunnen zijn. Het wordt gebruikt in verschillende soorten apparaten, namelijk. Smartphones, tabletcomputers en infotainmentsystemen en zijn zeer flexibel.
Naast de 7 hierboven genoemde niet-functionele vereisten, hebben we nog vele andere, zoals:
Toegankelijkheid, Back-up, Capaciteit, Compliance, Gegevensintegriteit, Gegevensbehoud, Afhankelijkheid, Implementatie, Documentatie, Duurzaamheid, Efficiëntie, Exploitatie, Uitbreidbaarheid, Storingsbeheer, Fouttolerantie, Interoperabiliteit, Aanpasbaarheid, Bediening, Privacy, Leesbaarheid, Rapportage, Veerkracht, Herbruikbaarheid, Robuustheid, schaalbaarheid, stabiliteit, testbaarheid, doorvoer, transparantie, integriteit.
Het dekken van al deze niet-functionele vereisten valt buiten het bestek van dit artikel. U kunt echter meer lezen over deze niet-functionele vereiste typen in Wikipedia.
Niet-functionele vereisten afleiden uit functionele vereisten
Niet-functionele vereisten kunnen op veel manieren worden afgeleid, maar de beste en meest beproefde manier in de industrie is van functionele vereisten.
Laten we het voorbeeld nemen van onze infotainmentsystemen die we al op een paar plaatsen in dit artikel hebben genomen. De gebruiker kan veel acties uitvoeren op het Infotainmentsysteem, namelijk. het nummer wijzigen, de nummerbron wijzigen van USB naar FM of Bluetooth-audio, de navigatiebestemming instellen, infotainmentsoftware bijwerken via een software-update, enz.
# 1) Verzameling van niet-functionele vereisten:
We vermelden de taken die door een gebruiker worden uitgevoerd, wat een onderdeel is van functionele vereisten. Zodra de gebruikersacties zijn genoteerd in het UML-use case-diagram (elk ovaal), beginnen we relevante vragen (elke rechthoek) over de acties van elke gebruiker. Antwoorden op deze vragen geven onze niet-functionele vereisten.
# 2) Categorisering van niet-functionele vereisten:
De volgende stap is het categoriseren van niet-functionele eisen die we via vragen hebben geïdentificeerd. In dit stadium kunnen we het mogelijke antwoord controleren en de antwoorden categoriseren op mogelijke niet-functionele categorieën of verschillende kwaliteiten.
In de onderstaande afbeelding kunt u de mogelijke kwaliteitsattributen zien die uit de antwoorden worden geïdentificeerd.
Functionele versus niet-functionele vereisten
We hebben al gezien wat functionele en niet-functionele eisen zijn en hoe ze worden afgeleid. Laten we eens kijken naar de belangrijkste verschillen tussen functionele en niet-functionele eisen.
Sl. Nee | Functionele vereisten (FR) | Niet-functionele eisen (NFR) |
---|---|---|
7 | Functionele vereisten vormen het skelet van de implementatie van softwaresystemen | Niet-functionele vereisten completeren het SW-systeem door de functionele vereisten bij elkaar te houden, als een spier. |
1 | Ze zeggen wat een systeem zou moeten doen. | Ze zeggen wat een systeem zou moeten zijn. |
twee | Ze worden gedetailleerd beschreven in het systeemontwerpdocument. | Ze worden gedetailleerd beschreven in het document Systeemarchitectuur. |
3 | Ze praten over het gedrag van een functie of kenmerk. | Ze praten over het werkgedrag van een heel systeem of een onderdeel van het systeem en niet over een bepaalde functie. |
4 | De gebruiker geeft de invoer door en controleert of de uitvoer correct wordt weergegeven. | Wanneer de gebruiker een invoer doorgeeft, kunnen de volgende vragen door NFR's worden beantwoord: i) Hoeveel tijd kost het om de output weer te geven? ii) Is de output consistent met de tijd? iii) Zijn er andere manieren om de invoerparameter door te geven? iv) Hoe gemakkelijk is het om de invoerparameter door te geven? |
5 | In een webapplicatie moet de gebruiker kunnen inloggen via authenticatie is FR | In een webapplicatie, hoeveel tijd kost het om in te loggen op de website, look en feel van de inlogpagina, gebruiksgemak van een webpagina, etc. zijn onderdeel van NFR |
6 | Functionele vereisten worden allereerst afgeleid uit softwarevereisten. | Niet-functionele eisen zijn afgeleid van functionele eisen. |
8 | Functionele eisen kunnen bestaan zonder een niet-functionele eis. | Niet-functionele eisen kunnen niet bestaan zonder functionele eisen. |
9 | Een functionele eis geeft concrete informatie over een kenmerk, Voorbeeld , Profielfoto op Facebook moet zichtbaar zijn bij inloggen. | Een functionele eis kan veel niet-functionele eisenattributen hebben. Voorbeeld, tijd om in te loggen (prestatie), look en feel van de profielpagina (bruikbaarheid), aantal gebruikers dat tegelijkertijd kan inloggen (capaciteit, prestatie) |
10 | Het afleiden van functionele vereisten uit SW-vereisten is mogelijk voor bijna alle zakelijke vereisten | NFR's worden vaak over het hoofd gezien om te worden gedocumenteerd, aangezien relevante vragen niet worden gesteld over FR's. |
elf | Het implementeren van een functionele vereiste gebeurt normaal gesproken in één softwarebouw. | NFR's worden gedurende de levenscyclus van het project geïmplementeerd totdat het gewenste gedrag is bereikt. |
12 | Deze zijn meestal zichtbaar voor de klant. | Deze zijn meestal niet zichtbaar voor de klant maar kunnen op lange termijn worden ervaren. Voorbeeld, Bruikbaarheid, prestaties, enz. Kunnen alleen op de lange termijn worden ervaren, maar kunnen helemaal niet zichtbaar zijn. |
Gevolgtrekking
Vereisten vormen de basisbouwsteen om elk softwaresysteem te ontwikkelen. Het is mogelijk om een systeem te bouwen met functionele eisen, maar de mogelijkheden ervan kunnen niet worden bepaald of gemeten. Dat gezegd hebbende, is het erg belangrijk om functionele vereisten van goede kwaliteit te hebben die zijn afgeleid van een zakelijke vereiste om een werkend softwaresysteem van hoge kwaliteit te hebben.
Functionele vereisten geven dus de richting aan van de implementatie van een softwaresysteem, maar niet-functionele vereisten bepalen de kwaliteit van de implementatie die eindgebruikers zullen ervaren.
Aanbevolen literatuur
- Hoe de specificatie van softwarevereisten (SRS) testen?
- Functioneel testen versus niet-functioneel testen
- Hoe een applicatie testen zonder vereisten?
- Wat is behoefteanalyse en -verzameling in SDLC?
- 5 dodelijke fouten in het beheer van vereisten en hoe deze te verhelpen
- Kenmerken van functionele vereisten en niet-functionele vereisten
- Vereisten-traceerbaarheidsmatrix (RTM) maken: voorbeeld en voorbeeldsjabloon
- Top 20+ Best Requirements Management Tools (de volledige lijst)