#etiketten
En software kravspecifikation (SRS-dokument) beskriver, hvordan et software-system, der skal udvikles. Kort sagt, en SRS giver alle involverede en køreplan for dette projekt.
Det tilbyder high-grade definitioner for de funktionelle og ikke-funktionelle specifikationer for softwaren, og kan også omfatte use cases, der illustrerer, hvordan en bruger vil interagere med systemet ved afslutningen.,bemærk: lad os hjælpe dig med at skrive en soft .are krav specifikation. Anmod om et opkald med vores CTO ved at udfylde denne formular.
Indholdsfortegnelse
Hvorfor er et SRS-dokument vigtigt?
Antag, at du vil oprette en chat-app med et specifikt udseende og funktionalitet og gerne vil have, at den er specifikt rettet mod virksomheder. Du føler, at du kan skære de ekstra funktioner, som kommercielle chat-apps bruger til at appellere til offentligheden og fokusere på funktioner, som virksomheder har brug for. Men du er ikke en udvikler.,
så du skal outsource udviklingen af appen. Men du skal også sørge for, at den, du ansætter for at gøre din ide til virkelighed, ved præcis, hvad du forsøger at opnå. Uden alle detaljer for at afslutte appen kan tid og omkostninger hurtigt komme ud af hånden. Udviklere kan tage en forkert drejning og skal refactor koden, hvis det færdige produkt ikke passer til det billede, du havde i dit hoved.
et SRS-dokument tvinger dig til at lægge ideen ned på papir for at dække alle disse detaljer. Du skal oversætte denne ide til et sprog, som udviklere forstår., Et SRS-dokument beskriver, hvad en klient ønsker, og hvad udviklere vil give. Det er den skriftlige aftale om alle detaljer i appen.
at have et klart sæt krav sikrer, at et udviklingsteam opretter soft .are, der imødekommer kundernes behov. En SRS vil hjælpe med at estimere omkostningerne ved arbejde og dække projektomfanget. Det giver også kodere en idé om tech stack, som de får brug for, og hjælper dem med at planlægge deres arbejde, men det er ikke alt:
- Designere få projektet indsigt gennem SRS-dokumenter, så de kan matche design til den use case.,
- testere får retningslinjerne for oprettelse af testcases, der matcher virksomhedens behov.
- slutbrugere bruger SRS til at forstå soft .aren.
- det giver investorer et overblik over systemets funktioner, så de kan træffe investeringsbeslutninger.
En SRS er vigtigt, fordi det er en enkelt kilde til oplysninger og forventninger, som forhindrer misforståelser mellem projektledere, udviklere, designere og testere.
hvad inkluderer en SRS?,
en SRS skal have tilstrækkelig information til udviklere til at fuldføre den beskrevne soft .are. Det beskriver ikke kun beskrivelsen af den Soft .are, der er under udvikling, men også det formål, den vil tjene: hvad soft .aren skal gøre, og hvordan den skal udføre.,af den software, eller hvad det er meningen at gøre
Forskellen Mellem Funktionelle og Ikke-funktionelle Krav
Funktionelle krav er de mål, der med det nye system, du designer., De beskriver systemet, og hvordan det vil fungere til at hjælpe med en brugers opgaver. De definerer, hvordan systemet vil reagere på brugerinput og har detaljer om beregninger, datainput og forretningsprocesser. Du kan overveje funktionelle krav en detaljeret beskrivelse af programmets funktioner og brugerens behov. Uden at opfylde de funktionelle krav fungerer systemet ikke.
mens funktionelle krav angiver, hvad et system gør, beskriver ikke-funktionelle krav, hvordan systemet vil gøre det. Ikke-funktionelle krav påvirker ikke programmets funktionalitet., Selv uden at opfylde ikke-funktionelle krav, vil systemet udføre de ønskede opgaver.ikke-funktionelle krav er også vigtige, fordi de definerer de generelle egenskaber, der påvirker brugeroplevelsen. I stedet for at fokusere på brugernes behov, fokuserer de på brugernes forventninger og dækker emner som ydeevne, sikkerhed, pålidelighed, tilgængelighed og brugervenlighed.,
Hvordan til at Skrive en Software kravspecifikation Dokument
Det er bedst at organisere den proces, du bruger til at skrive et SRS-dokument ved at starte med et skelet og generelle oplysninger om den software, du er ved at udvikle, og efterbehandling ved at tilføje detaljer til at konkretisere dine forslag. Her er seks trin involveret i at oprette et SRS-dokument:
få Soft .arekrav Specification Document
Vi hjalp 200+ virksomheder med at opbygge deres soft .areprodukter. Ansæt vores forretningsanalytiker med 6 års ekspertise til at skrive en SRS til dig.,
Anmod om SRS
Opret en oversigt
det første trin i processen er at oprette en oversigt over dine SRS. Du kan selv oprette dette eller bruge en eksisterende SRS-skabelon som udgangspunkt. Her er en grundlæggende eksempel på en SRS disposition:
Hent e-bog
- Indledning
- Formål
- Tiltænkte Målgruppe
- Påtænkte Anvendelse
- Omfanget
- Definitioner
- Samlet Beskrivelse
- Brugernes Behov
- Forudsætninger og Afhængigheder
- Systemets Funktioner og Krav,
- Funktionelle Krav
- Eksterne Grænseflade Krav
- System Funktioner
- Ikke-funktionelle Krav
Definer Formålet
Når du har en skitse, du skal kødet ud af det., Start med at definere formålet med produktet i introduktionen af dine SRS. Her vil du beskrive det tilsigtede publikum og hvordan de vil bruge produktet. Her er hvordan du skal strukturere formål:
- Angiv produktets anvendelsesområde
- Beskrive den værdi, det vil levere
- Vis som vil bruge den software
- Detaljer, hvordan vil det hjælpe med den tiltænkte brugere’ job
Give et Overblik
Efter at definere produktets formål, opsummere, hvordan det vil virke., Her vil du give en generel beskrivelse af Soft .arens funktioner, og hvordan de passer til brugerens behov.
du vil også beskrive de antagelser, du laver om produktets funktionalitet og alt, hvad det afhænger af i det nuværende tech-økosystem.
beskriv funktionelle og ikke-funktionelle krav
nu hvor du har skrevet de generelle oplysninger, er det tid til at blive mere specifik. Når du udfylder dit overblik, inden du arbejder med funktionelle og ikke-funktionelle krav, får du en reference, der sikrer, at du opfylder brugerens grundlæggende behov, mens du udfylder detaljerne.,
denne detaljerede beskrivelse af systemets krav er den vigtigste komponent i et SRS-dokument. Beskriv de funktionelle krav I nok detaljer, så udviklere kan komme på arbejde og de ikke-funktionelle krav som Sikkerhedsspecifikationer og ydeevne.
Her tilføjer du brugssager til levende at beskrive, hvordan en bruger vil interagere med dit system. Det er her projektets mål er detaljerede og vil måle, hvordan projektet skrider frem under udviklingen.,
Tilføj supplerende detaljer
det sidste trin i oprettelsen af udkastet til dit SRS-dokument er at tilføje alle detaljer, der kan hjælpe udviklere med at afslutte jobbet i form af bilag, ordlister over udtryk og referencer.
få godkendelse
Når du har tilføjet nok detaljer til SRS for at beskrive, hvad systemet skal gøre, er det tid til at få interessenterne til at godkende dokumentet.
du bliver sandsynligvis nødt til at lave en præsentation til de mennesker, der er involveret i udviklingsprocessen., De kan bede om ændringer, og du bliver nødt til at opdatere SRS-dokumentet baseret på feedback fra interessenter inden endelig godkendelse.
Dette er et godt tegn. Det betyder, at både udviklere og interessenter gør dokumentet mere præcist, så projektet er mindre som at gå af sporet.
Sådan skriver du Soft .arebrugssager i en SRS
en brugssag beskriver, hvordan en bruger vil interagere med systemet. Det vil beskrive produktet fra slutbrugerens synspunkt i et simpelt historieformat. Skrivning use cases tvinger dig til at tænke igennem, hvad brugerne vil gøre med soft .aren, og hvordan det vil reagere., Det er den virkelige visualisering af de funktionelle krav.
Her er trin, du kan følge for at skrive en brugssag:
- beskriv dit produkts slutbrugere.
- fokus på en af disse brugere.
- Bryd denne brugers interaktioner ned i brugssager. Hver interaktion er en brugssag.
- beskriv rækkefølgen af begivenheder for hver brugssag.
- Skriv en detaljeret beskrivelse af brugerens handlinger, og hvordan systemet skal reagere.
- Udvid hver brugssag med alternative brugerhandlinger og systemresponser.
- gentag 1-6 for hver type slutbruger.,
Hvad kendetegner en god SRS?
Der er specifikke egenskaber, som hver SRS skal have. Ved at gennemgå denne liste og sammenligne den med dine SRS, kan du sikre dig, at den vil være et nyttigt dokument for alle interessenter.
eksplicit
et SRS-dokument skal være let at forstå. Intet skal være vagt, så der er ingen misforståelser mellem interessenter.,
målbar
kravene i dit SRS-dokument skal være målbare, så det færdige produkt kan valideres og verificeres i forhold til specifikationerne.
komplet
et SRS-dokument skal have tilstrækkelig information til, at dit udviklingshold kan afslutte produktet, og for testere til at validere, at produktet opfylder brugerens behov uden fejl.
levedygtig
kravene skal passe til virkeligheden i det nuværende miljø, herunder budget, tidslinje og teknologi. De bør ikke afhænge af kommende teknologiske gennembrud.,
fleksibel
da tingene kan ændre sig i arbejdsmiljøet, skal dit SRS-dokument være fleksibelt nok til at give mulighed for opdateringer. Tilføj ikke overflødige oplysninger til flere sektioner, der skal opdateres med hver ændring.
verificerbar
alle på udviklingsholdet skal have adgang til dokumentet, så de kan referere det så ofte som nødvendigt. Kravene skal være præcise, så teammedlemmer ikke behøver at bede om flere detaljer. De skal alle være tilgængelige i SRS-dokumentet.,
konsekvent
kravene skal passe hinanden. Et afsnit af dit kravdokument bør ikke være i konflikt med et andet. Dokumentet skal formateres konsekvent og bruges den samme terminologi hele vejen igennem.
ingen Implementeringsbegrænsninger
et SRS-dokument skal være detaljeret nok til at afslutte jobbet, men bør ikke være for specifikt, fordi det kan begrænse udviklingen. Meget udvikling afhænger af tredjeparts tjenester, som udviklere ikke har kontrol over.,
nøjagtige
mål i et kravdokument skal være præcise for at undgå forvirring. Undgå følgende:
- smuthuller: “applikationen skal indlæses om 3 sekunder, hvis det kan gøres.”
- tvetydighed: “MVP-produktet skal frigives så hurtigt som muligt .”
- subjektivitet: “brugergrænsefladen skal være brugervenlig.”
- superlativer: “dette skal være den bedste applikation i sin klasse.”
- sammenlignende: “denne ansøgning skal være bedre end Slack.,”
En Software Requirement Specification (SRS) Eksempel
Her er en trimmet ned eksempel på et SRS-dokument for en virksomhed chat app kaldet eChat:
Indledning
Dette dokument indeholder projektplan for udvikling af “eChat.”
det er beregnet til udviklere, designere og testere, der arbejder på “eChat” såvel som projektinvestorer., Denne plan vil indeholde en oversigt over:
- hvordan systemet vil fungere
- omfanget af projektet fra udvikling synspunkt
- den teknologi, der bruges til at udvikle projektet, og
- de data, der benyttes til at bestemme projektets fremskridt
- Samlet Beskrivelse
Virksomheder, der har brug for ekstern kommunikation værktøjer, især nu, hvor flere mennesker er at arbejde fra hjemmet. Problemet er, at de fleste virksomheder ender med at bruge flere applikationer til at opnå dette: en til tekstchat, en til videochat og en til konferencer og møder., “eChat” løser dette problem ved at kombinere disse funktioner i en applikation.
Download whitepaper
Kunder
De kunder, der vil være til virksomheder. Det vil ikke være rettet mod offentligheden.
funktionalitet
- brugere skal være i stand til at tilmelde sig Enterprise LDAP-konti.,
- brugere bør være i stand til at oprette ad hoc chat grupper bestående sæt af brugere og sende private beskeder til de enkelte brugere.
- brugere skal kunne have tekstchats, som de kan bryde ind i tråde.
- programmet skal kunne håndtere gruppevideochat på op til 100 brugere ad gangen.
Platform
applikationen vil blive udviklet i React Native for at muliggøre oprettelse af en .ebbaseret applikation, en iOS-mobilapp og en Android-mobilapp.
disse programmer vil oprette forbindelse til en REST API bygget med .,NET Core til at gemme og hente data fra en Mys .l-database.
godkendelse sker gennem eksisterende LDAP-installationer.
udviklingsansvar
udviklerne på “eChat” – teamet er ansvarlige for at skrive al koden til applikationen, udvikle databasen og styre udgivelser.,
Bruger Klasse og Egenskaber
Der vil være en klasse af brugere, der hedder admin, der vil have tilladelser til at få adgang til alle funktionerne i app ‘ en, herunder:
- Oprettelse af kanaler, hvor flere brugere kan interagere
- At disse kanaler forbudt at hele virksomheden eller privat for en gruppe af mennesker
- Slette disse kanaler
- Arkivering disse kanaler
Standard vil brugerne få adgang til alle funktionerne i appen, bortset fra dem, der er nævnt ovenfor.,
System Funktioner
Funktionelle Krav
- Brugere bør være i stand til at oprette ad hoc-chat-grupper bestående af grupper af brugere, og sende private beskeder til andre brugere.
- brugere skal kunne have tekstchats, som de kan bryde ind i tråde.
- Chats skal kunne arkiveres på ubestemt tid, så brugere kan henvise til tidligere chats.
- brugere skal kunne uploade filer til chats som reference.
- Eksterne Grænseflade Krav
Bruger-Grænseflader
- Front-end software: Reagerer Native
- Back-end software: .,s-styresystemer via deres standard-web-browser
- iPhone
- Android
- Ikke-Funktionelle Krav
Ydeevne
- ansøgningen skal indlæses og bruges inden for 3 sekunder
- ansøgningen skal opdatere den grænseflade interaktion inden for 2 sekunder
- Databasen bør være normaliseret til at undgå overflødige data og forbedre ydeevnen
- databasen skal fordeles for at forhindre driftsstop
Sikkerhedskrav
- Databaser skal bruge sharding at være overflødige for at forhindre tab af data.,
- sikkerhedskopier af databaserne skal udføres hver time og opbevares i en uge.
sikkerhedskrav
- alle nøgler, der anvendes til REST API ‘ en, skal opbevares sikkert.
- kun REST-API ‘ en skal kunne oprette forbindelse til databaserne.
- databaser skal være bag en fire .all.
Soft .arekvalitetsattributter
- tilgængelighed: da denne applikation er kritisk for forretningskommunikation, har vi et mål om fire niere(99.99%) tilgængelighed.,
- korrekthed: programmet bør aldrig tillade nogen at læse meddelelser eller diskussioner, der ikke er beregnet til den pågældende person.
- vedligeholdelse: programmet skal bruge kontinuerlig integration, så funktioner og fejlrettelser kan implementeres hurtigt uden nedetid.brugervenlighed: grænsefladen skal være let at lære uden en tutorial og give brugerne mulighed for at nå deres mål uden fejl.
resum.
et SRS-dokument er en nødvendig del af færdiggørelsen af et Soft .areudviklingsprojekt., Det er køreplanen, der giver retning til alle involverede i projektet, så det endelige produkt opfylder brugerens behov.
uden et komplet SRS-dokument på plads, før du starter et projekt, vil det være svært at se, hvornår et projekt er færdigt og kan sidespore udvikling til at skabe utilsigtede funktioner. Et SRS-dokument giver dig mulighed for at estimere et projekt nøjagtigt og tildele opgaver effektivt.
oprettelse af et SRS-dokument kan være en tidskrævende, omhyggelig proces., Heldigvis har teamet hos Relevant hjulpet over 200 virksomheder med at oprette SRS-dokumenter og lancere nye produkter. Vi er klar til at hjælpe med din næste soft .are-projekt, bare drop os en linje.