SOFTWARE REQUIREMENT SPECIFICATION (SRS) FORMAT - TECHCODEVIEW.COM

For at danne en god SRS, vil du her se nogle punkter, som kan bruges og bør overvejes til at danne en struktur af god Software Requirements Specification (SRS). Disse er nævnt nedenfor i indholdsfortegnelsen og er godt forklaret nedenfor.

Software Requirement Specification (SRS) Format som navnet antyder, er en komplet specifikation og beskrivelse af krav til softwaren, der skal opfyldes for en vellykket udvikling af softwaresystemet. Disse krav kan være funktionelle såvel som ikke-funktionelle afhængigt af typen af krav. Samspillet mellem forskellige kunder og entreprenører sker, fordi det er nødvendigt at forstå kundernes behov fuldt ud. Softwarekravspecifikationsformat Afhængigt af information indsamlet efter interaktion, er SRS udviklet, som beskriver krav til software, der kan omfatte ændringer og modifikationer, der er nødvendige for at øge kvaliteten af produktet og for at tilfredsstille kundens efterspørgsel.

Introduktion

Formålet med dette dokument - Først forklares og beskrives hovedformålet med, hvorfor dette dokument er nødvendigt, og hvad formålet med dokumentet er.
Omfanget af dette dokument – I dette beskrives og forklares det overordnede arbejds- og hovedformål med dokumentet og hvilken værdi det vil give kunden. Den indeholder også en beskrivelse af udviklingsomkostninger og krævet tid.
Overblik – Heri forklares produktbeskrivelsen. Det er simpelthen en opsummering eller overordnet anmeldelse af produktet.

Generel beskrivelse

I dette, generelle funktioner af produktet, som inkluderer formålet med brugeren, en brugeregenskab, funktioner, fordele, om hvorfor dets betydning er nævnt. Den beskriver også funktioner i brugerfællesskabet.

pointer i c

Funktionelle krav

I dette er det mulige resultat af softwaresystem, som inkluderer effekter på grund af programmets drift, fuldt ud forklaret. Alle funktionskrav, som kan omfatte beregninger, databehandling osv., er placeret i en rækkefølge. Funktionelle krav specificerer den forventede opførsel af systemet - hvilke output der skal produceres fra de givne input. De beskriver forholdet mellem input og output af systemet. For hvert funktionskrav skal der angives en detaljeret beskrivelse af alle datainput og deres kilde, måleenhederne og rækken af gyldige input.

Grænsefladekrav

I denne er softwaregrænseflader, som betyder, hvordan softwareprogrammer kommunikerer med hinanden eller brugere, enten i form af et hvilket som helst sprog, kode eller besked, fuldstændigt beskrevet og forklaret. Eksempler kan være delt hukommelse, datastrømme osv.

Ydelseskrav

Heri forklares, hvordan et softwaresystem udfører ønskede funktioner under specifikke forhold. Den forklarer også påkrævet tid, påkrævet hukommelse, maksimal fejlrate osv. Ydelseskrav-delen af en SRS specificerer ydeevnebegrænsningerne på softwaresystemet. Alle krav vedrørende systemets ydeevne skal være klart specificeret. Der er to typer præstationskrav: statisk og dynamisk. Statiske krav er dem, der ikke lægger begrænsninger på systemets eksekveringsegenskaber. Dynamiske krav specificerer begrænsninger for systemets eksekveringsadfærd.

Design begrænsninger

I dette er begrænsninger, som blot betyder begrænsning eller begrænsning, specificeret og forklaret for designteamet. Eksempler kan omfatte brug af en bestemt algoritme, hardware- og softwarebegrænsninger osv. Der er en række faktorer i klientens miljø, der kan begrænse en designers valg, hvilket fører til designbegrænsninger. Sådanne faktorer omfatter standarder, der skal overholdes ressourcegrænser, drift miljø, pålidelighed og sikkerhedskrav og politikker, der kan have indflydelse på systemets design. En SRS bør identificere og specificere alle sådanne begrænsninger.

Ikke-funktionelle attributter

I denne forklares ikke-funktionelle attributter, der kræves af softwaresystemet for bedre ydeevne. Et eksempel kan omfatte sikkerhed, bærbarhed, pålidelighed, genanvendelighed, applikationskompatibilitet, dataintegritet, skalerbarhedskapacitet osv.

søgealgoritmer

Foreløbig tidsplan og budget

I denne forklares den oprindelige version og budget for projektplanen, som inkluderer den samlede krævede varighed og de samlede omkostninger, der kræves til udvikling af projektet.

Bilag

Heri gives og forklares yderligere information som referencer, hvorfra information er indsamlet, definitioner af nogle specifikke termer, akronymer, forkortelser osv.

Brug af SRS-dokument

Udviklingsteam kræver det for at udvikle produkt efter behov.
Testplaner genereres af testgruppe baseret på beskriv ekstern adfærd.
Vedligeholdelses- og supportpersonale har brug for det for at forstå, hvad softwareproduktet skal gøre.
Projektleder baserer deres planer og skøn over tidsplan, indsats og ressourcer på det.
kunder stole på det for at kende det produkt, de kan forvente.
Som en kontrakt mellem udvikler og kunde.
i dokumentationsformål.

Ofte stillede spørgsmål om SRS-format

1. Hvorfor er det vigtigt at definere omfanget af et SRS-dokument?

At definere omfanget i et SRS-dokument hjælper kunden med at forstå softwarens mål og værdi. Den har også detaljer om, hvor meget det vil koste at skabe, og hvor lang tid det vil tage, så projektets grænser er klare.
gb vs mb

2. Hvad er funktionelle krav i et SRS-dokument, og hvorfor er de vigtige?

Funktionelle krav beskriver, hvordan softwaresystemet skal fungere, herunder hvordan det skal reagere på input og lave output. De hjælper dig med at finde ud af, hvad softwaren skal gøre, og giver dig et sted, hvor du kan begynde at bygge og teste den.

Konklusion

Softwareudvikling kræver en velstruktureret Software Requirement Specification (SRS). Det hjælper interessenter med at kommunikere, giver en køreplan for udviklingsteams, guider testere i at skabe effektive testplaner, guider vedligeholdelses- og supportmedarbejdere, informerer projektledelsesbeslutninger og sætter kundernes forventninger. SRS-dokumentet er med til at sikre, at softwaren opfylder funktionelle og ikke-funktionelle krav, hvilket resulterer i et kvalitetsprodukt til tiden og inden for budgettet.