Menu

Hoe de specificatie van softwarevereisten (SRS) testen?

how test software requirements specification

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Weet u dat 'Meeste van de Bugs in software zijn te wijten aan onvolledige of onnauwkeurige functionele vereisten? ' Hoe goed het ook is geschreven, de softwarecode doet er niet toe en er kan niets worden gedaan als er onduidelijkheden zijn in de vereisten.

Dit artikel over Software Requirements Specification (SRS) stelt dat Requirements duidelijk, specifiek, meetbaar en compleet moeten zijn zonder tegenstrijdigheden.

Het is beter om de onduidelijkheden in de vereisten op te vangen en ze op te lossen in de vroege ontwikkelingscyclus zelf.

Specificatie van softwarevereisten (SRS) testen _

De kosten voor het oplossen van de bug na voltooiing van de ontwikkeling of productrelease zijn te hoog. Het is dus belangrijk om een ​​behoefteanalyse te hebben en deze onjuiste vereisten op te sporen voordat ontwerpspecificaties en projectimplementatiefasen van SDLC worden uitgevoerd.

Wat je leert:

Hoe functionele SRS-documenten te meten?

Welnu, we moeten een aantal standaardtests definiëren om de vereisten te meten. Nadat elke vereiste door deze tests is gehaald, kunt u de functionele vereisten evalueren en bevriezen.

Laten we een voorbeeld, je werkt aan een webgebaseerde applicatie. De vereiste is als volgt: 'Webapplicatie moet in staat zijn om de gebruikersvragen zo vroeg mogelijk te beantwoorden'

c / c ++ interviewvragen

Hoe gaat u in dit geval de vereiste bevriezen?

Wat worden uw criterium voor het voldoen aan de vereisten? Om het antwoord te krijgen, stelt u deze vraag aan de belanghebbenden: hoeveel reactietijd is oké voor u? Als ze zeggen, zullen we het antwoord accepteren als het binnen 2 seconden is, dan is dit uw vereiste maatregel. Zet deze vereiste stil en voer dezelfde procedure ook uit voor de volgende vereiste.

We hebben net geleerd hoe we de vereisten kunnen meten en die in de ontwerp-, implementatie- en testfasen kunnen bevriezen.

Laten we nu nog een voorbeeld nemen: Ik werkte aan een webproject. Opdrachtgever (stakeholders) heeft in de beginfase van de projectontwikkeling de projecteisen gespecificeerd. Mijn manager heeft alle vereisten in het team ter beoordeling verspreid. Toen we de discussie over deze vereisten begonnen, waren we gewoon geschokt!

Iedereen had zijn of haar eigen opvatting over de vereisten. We hebben veel onduidelijkheden gevonden in de ‘termen’ gespecificeerd in de vereiste documenten, die later naar de klant werden gestuurd voor beoordeling / verduidelijking.

De klant gebruikte veel dubbelzinnige termen, die veel verschillende betekenissen hadden, waardoor het moeilijk voor ons was om de exacte betekenis te analyseren. De volgende versie van het vereiste document van de klant was duidelijk genoeg om te bevriezen voor de ontwerpfase.

Uit dit voorbeeld hebben we geleerd dat 'Vereisten duidelijk en consistent moeten zijn'

Het volgende criterium voor het testen van de specificatie van vereisten is 'Ontbrekende vereisten ontdekken', laten we er eens naar kijken.

gratis registry cleaner download voor windows 10

Ontdek ontbrekende vereisten

Vaak hebben de projectontwerpers geen duidelijk idee over elke specifieke module en gaan ze gewoon uit van enkele vereisten in de ontwerpfase. Elke vereiste mag niet op aannames zijn gebaseerd. De vereisten moeten volledig zijn en elk aspect van het systeem in ontwikkeling dekken.

Specificaties moeten beide typen vereisten vermelden, d.w.z. welk systeem moet doen en wat niet.

Over het algemeen gebruik ik mijn eigen methode om de niet-gespecificeerde vereisten te achterhalen. Toen ik het Softwarevereisten Specificatie document (SRS) , Noteer ik mijn eigen begrip van de vereisten die worden gespecificeerd, plus andere vereisten die het SRS-document zou moeten dekken.

Dit helpt me om de vragen over de niet-gespecificeerde vereisten te stellen, waardoor het duidelijker wordt.

Om de volledigheid van de vereisten te controleren, verdeelt u de vereisten in drie secties: ‘Moet’ vereisten, vereisten die niet zijn gespecificeerd maar worden ‘aangenomen’ en het derde type is ‘verbeelding’ vereisten. Controleer of aan alle soorten vereisten is voldaan voordat de software-ontwerpfase begint.

Controleer of de vereisten verband houden met het projectdoel

Soms hebben stakeholders hun eigen expertise, waarvan ze verwachten dat deze in het systeem in ontwikkeling komt. Ze denken niet eens na of die vereiste relevant zou zijn voor het lopende project. Zorg ervoor dat u dergelijke vereisten identificeert. Probeer alle irrelevante vereisten tijdens de eerste fase van de projectontwikkelingscyclus te vermijden.

Indien niet mogelijk, stel dan de vragen aan belanghebbenden, zoals waarom wilt u deze specifieke vereiste implementeren? Dit zal de specifieke vereiste in detail beschrijven, waardoor het gemakkelijker wordt om het systeem te ontwerpen met het oog op de toekomstige reikwijdte.

Maar hoe te beslissen of de vereisten relevant zijn of niet?

Eenvoudig antwoord: stel het projectdoel vast en stel deze vraag: als het niet implementeren van deze vereiste problemen oplevert om ons gespecificeerde doel te bereiken? Zo niet, dan is dit een irrelevante vereiste. Vraag de belanghebbenden of ze dit soort eisen echt willen implementeren.

Kortom, het Requirements Specification (SRS) -document zou het volgende moeten behandelen:

  • Projectfunctionaliteit (wat moet er wel en niet worden gedaan).
  • Software, hardware-interfaces en de gebruikersinterface.
  • Systeemcorrectheid, beveiliging en prestatiecriteria.
  • Eventuele implementatieproblemen (risico's).

Gevolgtrekking

Ik heb bijna alle aspecten van het meten van eisen behandeld. Om specifiek te zijn over vereisten, zal ik het testen van vereisten in één zin samenvatten:

'Vereisten moeten duidelijk en specifiek zijn zonder onzekerheid, vereisten moeten meetbaar zijn in termen van specifieke waarden, vereisten moeten testbaar zijn met een aantal evaluatiecriteria voor elke vereiste, en vereisten moeten volledig zijn, zonder enige tegenstrijdigheid'

Het testen moet beginnen in de vereistenfase om verdere vereiste-gerelateerde bugs te voorkomen. Communiceren steeds meer met uw belanghebbenden om alle vereisten te verduidelijken voordat u begint met het ontwerp en de uitvoering van het project.

Heb je ervaring met het testen van softwarevereisten?

Deel ze gerust in de reacties hieronder.

Aanbevolen literatuur

^