De productie van de vereistenfase van het softwareontwikkelingsproces is Specificaties softwarevereisten (SRS) (ook wel A genoemd eisendocument ). Dit rapport legt een basis voor software-engineeringactiviteiten en komt tot stand wanneer alle vereisten zijn geïdentificeerd en geanalyseerd. SRS is een formeel rapport, dat fungeert als een representatie van software waarmee klanten kunnen beoordelen of het (SRS) aan hun eisen voldoet. Het omvat ook gebruikersvereisten voor een systeem en gedetailleerde specificaties van de systeemvereisten.

De SRS is een specificatie voor een specifiek softwareproduct, programma of reeks applicaties die bepaalde functies uitvoeren in een specifieke omgeving. Het dient verschillende doelen, afhankelijk van wie het schrijft. Ten eerste zou de SRS door de client van een systeem kunnen worden geschreven. Ten tweede zou de SRS geschreven kunnen worden door een ontwikkelaar van het systeem. De twee methoden creëren totaal verschillende situaties en stellen totaal verschillende doeleinden voor het document vast. Het eerste geval, SRS, wordt gebruikt om de behoeften en verwachtingen van de gebruikers te definiëren. De tweede case, SRS, is voor verschillende doeleinden geschreven en dient als contractdocument tussen klant en ontwikkelaar.

Kenmerken van goede SRS

Hieronder volgen de kenmerken van een goed SRS-document:

1. Correctheid: Er wordt gebruik gemaakt van gebruikersbeoordelingen om de juistheid van de vereisten vermeld in de SRS te garanderen. Er wordt gezegd dat SRS perfect is als het alle behoeften dekt die werkelijk van het systeem worden verwacht.

2. Volledigheid: Het SRS is compleet als en alleen als het de volgende elementen bevat:

(1). Alle essentiële vereisten, of het nu gaat om functionaliteit, prestaties, ontwerp, beperkingen, attributen of externe interfaces.

soorten binaire bomen

(2). Definitie van hun reacties van de software op alle realiseerbare klassen van invoergegevens in alle beschikbare categorieën van situaties.

Opmerking: Het is essentieel om de antwoorden op zowel geldige als ongeldige waarden op te geven.

(3). Volledige labels en verwijzingen naar alle figuren, tabellen en diagrammen in de SRS en definities van alle termen en maateenheden.

3. Consistentie: De SRS is consistent als en alleen als er geen subset van individuele vereisten wordt beschreven in het conflict. Er zijn drie soorten mogelijke conflicten in de SRS:

(1). De gespecificeerde kenmerken van objecten uit de echte wereld kunnen conflicten veroorzaken. Bijvoorbeeld,

(a) Het formaat van een outputrapport kan in één vereiste als tabelvormig worden beschreven, maar in een ander als tekstueel.

(b) Eén voorwaarde kan stellen dat alle lichten groen moeten zijn, terwijl een andere voorwaarde stelt dat alle lichten blauw moeten zijn.

(2). Er kan een redelijk of tijdelijk conflict bestaan ​​tussen de twee gespecificeerde acties. Bijvoorbeeld,

(a) Eén vereiste kan bepalen dat het programma twee inputs zal toevoegen, en een andere kan bepalen dat het programma deze zal vermenigvuldigen.

(b) Eén voorwaarde kan stellen dat 'A' altijd op 'B' moet volgen, terwijl andere vereist dat 'A en B' gelijktijdig voorkomen.

(3). Twee of meer vereisten kunnen hetzelfde object uit de echte wereld definiëren, maar voor dat object verschillende termen gebruiken. Het verzoek van een programma om gebruikersinvoer kan bijvoorbeeld in de ene eis een 'prompt' worden genoemd en in de andere een 'cue'. Het gebruik van standaardterminologie en -beschrijvingen bevordert de consistentie.

4. Ondubbelzinnigheid: SRS is ondubbelzinnig als elke vaste eis slechts één interpretatie kent. Dit suggereert dat elk element op een unieke manier wordt geïnterpreteerd. Als er een methode wordt gebruikt met meerdere definities, moet het vereistenrapport de implicaties in de SRS bepalen, zodat deze duidelijk en eenvoudig te begrijpen is.

5. Ranglijst voor belang en stabiliteit: De SRS wordt gerangschikt op belangrijkheid en stabiliteit als elke vereiste een identificatie heeft die de betekenis of stabiliteit van die specifieke vereiste aangeeft.

Normaal gesproken zijn niet alle vereisten even belangrijk. Sommige vereisten kunnen essentieel zijn, vooral voor levenskritische toepassingen, terwijl andere wenselijk kunnen zijn. Elk element moet worden geïdentificeerd om deze verschillen duidelijk en expliciet te maken. Een andere manier om vereisten te rangschikken is door klassen van items te onderscheiden als essentieel, voorwaardelijk en optioneel.

6. Aanpasbaarheid: SRS moet zo aanpasbaar mogelijk worden gemaakt en moet in staat zijn snel tot op zekere hoogte wijzigingen in het systeem te bewerkstelligen. Wijzigingen moeten perfect worden geïndexeerd en waarnaar wordt verwezen.

7. Controleerbaarheid: SRS heeft gelijk als de gestelde eisen kunnen worden geverifieerd met een kosteneffectief systeem om te controleren of de uiteindelijke software aan die eisen voldoet. De vereisten worden geverifieerd met behulp van beoordelingen.

8. Traceerbaarheid: De SRS is traceerbaar als de oorsprong van elk van de vereisten duidelijk is en als het de verwijzing naar elke voorwaarde in toekomstige ontwikkelings- of verbeteringsdocumentatie vergemakkelijkt.

Er zijn twee soorten traceerbaarheid:

arraylengte java

1. Achterwaartse traceerbaarheid: Dit hangt ervan af of elke vereiste expliciet verwijst naar de bron in eerdere documenten.

2. Voorwaartse traceerbaarheid: Dit hangt ervan af of elk element in het SRS een unieke naam of referentienummer heeft.

jasmijn davis als kind

De voorwaartse traceerbaarheid van het SRS is vooral cruciaal wanneer het softwareproduct de exploitatie- en onderhoudsfase ingaat. Wanneer de code en het ontwerpdocument worden gewijzigd, is het noodzakelijk om de volledige reeks eisen vast te stellen waarop deze wijzigingen betrekking kunnen hebben.

9. Ontwerponafhankelijkheid: Er moet een optie zijn om te kiezen uit meerdere ontwerpalternatieven voor het uiteindelijke systeem. Meer specifiek mag de SRS geen implementatiedetails bevatten.

10. Testbaarheid: Een SRS moet zo worden geschreven dat het eenvoudig is om uit het rapport testgevallen en testplannen te genereren.

11. Begrijpelijk voor de klant: Een eindgebruiker kan een expert zijn op zijn/haar expliciete domein, maar is mogelijk niet opgeleid in computerwetenschappen. Daarom moet het doel van formele notaties en symbolen zoveel mogelijk worden vermeden. Het taalgebruik moet eenvoudig en duidelijk gehouden worden.

12. Het juiste abstractieniveau: Als de SRS is geschreven voor de fase van eisen, moeten de details expliciet worden toegelicht. Terwijl voor een haalbaarheidsstudie minder analyses nodig zijn. Het abstractieniveau verandert dus afhankelijk van de doelstelling van de SRS.

Eigenschappen van een goed SRS-document

De essentiële eigenschappen van een goed SRS-document zijn de volgende:

Beknopt: Het SRS-rapport moet beknopt en tegelijkertijd ondubbelzinnig, consistent en volledig zijn. Uitgebreide en irrelevante beschrijvingen verminderen de leesbaarheid en vergroten ook de foutmogelijkheden.

Gestructureerd: Het moet goed gestructureerd zijn. Een goed gestructureerd document is eenvoudig te begrijpen en aan te passen. In de praktijk ondergaat het SRS-document verschillende herzieningen om aan de gebruikersvereisten te voldoen. Vaak evolueren de gebruikersvereisten in de loop van de tijd. Om de wijzigingen in het SRS-document eenvoudig te maken, is het daarom van cruciaal belang dat het rapport goed gestructureerd is.

Blackbox-weergave: Het moet alleen definiëren wat het systeem moet doen en niet aangeven hoe dit moet worden gedaan. Dit betekent dat het SRS-document het externe gedrag van het systeem moet definiëren en niet de implementatiekwesties moet bespreken. Het SRS-rapport moet het te ontwikkelen systeem beschouwen als een black box en het extern zichtbare gedrag van het systeem definiëren. Om deze reden wordt het SRS-rapport ook wel de black-box-specificatie van een systeem genoemd.

Conceptuele integriteit: Het moet blijk geven van conceptuele integriteit, zodat de lezer het alleen maar kan begrijpen. Reactie op ongewenste gebeurtenissen: Het moet acceptabele reacties op ongewenste gebeurtenissen karakteriseren. Dit worden systeemreacties op uitzonderlijke omstandigheden genoemd.

Verifieerbaar: Alle vereisten van het systeem, zoals gedocumenteerd in het SRS-document, moeten correct zijn. Dit betekent dat het mogelijk moet zijn om te bepalen of bij een implementatie wel of niet aan de eisen is voldaan.