#produktetiketten
En programvare for krav-spesifikasjonen (SRS dokument) beskriver hvordan en programvare system bør utvikles. Enkelt sagt, en SRS gir alle som er involvert med et veikart for det prosjektet.
Det tilbyr high-grade definisjoner for de funksjonelle og ikke-funksjonelle spesifikasjoner for programvaren, og kan også omfatte tilfeller som illustrerer hvordan en bruker ville samhandle med systemet ved ferdigstillelse.,
Merk: La oss hjelpe deg å skrive en Programvare for Krav-Spesifikasjonen. Be om en samtale med vår administrerende direktør ved å fylle ut dette skjemaet.
Innholdsfortegnelse
Hvorfor er en SRS-Dokument Viktig?
Tenk deg at du ønsker å opprette en chat-appen med et bestemt utseende og funksjonalitet og ønsker at det skal være rettet spesielt til bedrifter. Du føler at du kan kutte ut den ekstra funksjoner som kommersielle chat apps bruke til å appellere til offentligheten og fokus på funksjoner som bedriftene trenger. Men at du ikke er en utvikler.,
Så du trenger å outsource utvikling av appen. Men du må også sørge for at den du ansetter for å slå din idé til virkelighet vet nøyaktig hva du prøver å oppnå. Uten alle detaljer for å fullføre app, tid og kostnader kan raskt komme ut av kontroll. Utviklere kan ta feil og har å refactor koden dersom det ferdige produkt ikke stemmer overens med det bildet du hadde i hodet.
En SRS-dokument tvinger deg til å sette ideen ned på papiret for å dekke alle disse detaljene. Du må oversette denne ideen inn i et språk som utviklere forstår., En SRS dokumentet beskriver hva klienten ønsker og hva utviklere vil gi. Det er den skriftlige avtalen på hver detalj av appen.
å Ha et klart sett av krav som sikrer at en utvikling team skaper programvare som tilfredsstiller brukernes behov. En SRS vil hjelpe til med å beregne kostnadene for arbeid og dekker omfang av prosjektet. Det gir også sikrer en idé av tech stabel de trenger og hjelper dem med å planlegge arbeidet, men det er ikke alt:
- Designere få prosjektet innsikt gjennom SRS dokumenter slik at de kan matche design for å bruke saken.,
- Testere få retningslinjer for å opprette test tilfeller som samsvarer med virksomhetens behov.
- End-brukere bruke SRS å forstå programvaren.
- Det gir investorer med en oversikt over systemets funksjoner slik at de kan ta investeringsbeslutninger.
En SRS er viktig fordi det er en enkelt kilde av informasjon og forventninger, som hindrer misforståelser mellom prosjektledere, utviklere, designere og testere.
Hva Gjør en SRS Inneholde?,
En SRS bør ha nok informasjon for utviklere å fullføre den programvaren som er beskrevet. Det er ikke bare legger ut beskrivelse av programvare under utvikling, men også for det formål det skal tjene: hva programvaren er ment å gjøre, og hvordan det skal utføre.,av programvare eller hva det er ment å gjøre
Forskjellen Mellom funksjonelle og Ikke-Funksjonelle Krav
Funksjonelle kravene er mål for det nye systemet du utformer., De beskriver systemet og hvordan det vil fungere å hjelpe deg med et brukerens oppgaver. De definerer hvordan systemet reagerer på inndata fra brukeren og ha informasjon om beregninger, inndata-og forretningsprosesser. Du kan vurdere funksjonelle krav en detaljert beskrivelse av programmets funksjoner og brukerens behov. Uten å møte de funksjonelle kravene, vil ikke systemet fungere.
Mens funksjonelle krav spesifisere hva et system gjør, ikke-funksjonelle krav beskriver hvordan systemet vil gjøre det. Ikke-funksjonelle krav ikke påvirke programmets funksjonalitet., Selv uten å møte ikke-funksjonelle krav, vil systemet utføre den ønskede oppgaver.
Ikke-funksjonelle krav er også viktig fordi de definerer den generelle kjennetegn som påvirker brukeropplevelsen. I stedet for å fokusere på brukernes behov, de fokuserer på brukernes forventninger og dekker emner som ytelse, sikkerhet, pålitelighet, tilgjengelighet og brukervennlighet.,
Hvordan å Skrive en Programvare kravspesifikasjon Dokumentet
Det er best å organisere prosessen du bruker til å skrive en SRS-dokument ved å starte med et skjelett og generell informasjon om programvaren du utvikler, og etterbehandling ved å legge informasjon til kjøttet ut utkast. Her er seks trinnene som er involvert i å skape en SRS-dokument:
Hent Programvare kravspesifikasjon Dokumentet
Vi hjalp 200+ selskapene bygge deres programvare produkter. Leie av vår virksomhet analytiker med 6 års kompetanse til å skrive en SRS for deg.,
Be om SRS
Lag en oversikt
Det første trinnet i prosessen er å lage en disposisjon for SRS. Du kan lage dette selv, eller bruke et eksisterende SRS mal som utgangspunkt. Her er et enkelt eksempel på en SRS omriss:
Laste ned ebok
– >
- Innledning
- Formål
- ønskede Målgruppen
- hadde til Hensikt å Bruke
- Omfang
- Definisjoner
- Generell Beskrivelse
- Må Brukeren
- Antagelser og Avhengigheter
- System Funksjoner og Krav
- Funksjonelle Krav
- Eksterne Grensesnitt Krav
- System
- Ikke-funksjonelle Krav
Definere Formålet
Når du har en disposisjon, må du kjøttet ut av det., Start med å definere hensikten med produktet i innføring av SRS. Her vil du beskrive den ønskede målgruppen, og hvordan de skal bruke produktet. Her er hvordan du bør strukturere formål:
- Definere produktet omfang
- Beskrive den verdi det vil levere
- Vis som vil bruke programvaren
- Detalj hvordan det vil hjelpe til med den tiltenkte brukere’ jobb
Gi en Oversikt
Når du har angitt på produktets formål, oppsummere hvordan det vil fungere., Her vil du gi en generell beskrivelse av programmets funksjoner og hvordan de passer brukerens behov.
Du vil også beskrive de forutsetninger som du gjør om produktets funksjonalitet og alt det avhenger i dagens flerkulturelle.
Beskrive funksjonelle og Ikke-Funksjonelle Krav
Nå at du har skrevet den generelle informasjonen, er det på tide å få mer spesifikke. Du er ferdig med din oversikt før du begynner å arbeide på funksjonelle og ikke-funksjonelle krav gir deg en referanse for å sikre at du oppfyller brukerens grunnleggende behov, mens du fylle ut detaljene.,
Denne detaljert beskrivelse av systemets krav er de mest essensielle komponenter av en SRS-dokument. Beskrive de funksjonelle kravene i tilstrekkelig detalj slik at utviklere kan få til å fungere og ikke-funksjonelle krav som sikkerhet spesifikasjoner og ytelse.
Her er hvor du vil legge til bruk saker til levende beskriver hvordan en bruker vil samhandle med systemet. Det er der din prosjektets mål er detaljert og vil måle hvordan prosjektet går under utvikling.,
Legg til Supplerende Opplysninger
Den siste trinn i å lage utkast til din SRS dokumentet er å legge til noen detaljer som kan hjelpe utviklere med å fullføre jobben i form av vedlegg, ordlister av begreper og referanser.
Få Godkjenning
Når du har lagt nok detaljer til å SRS å beskrive hva som systemet er ment å gjøre, er det på tide å ha interessenter for å godkjenne dokumentet.
vil Du mest sannsynlig har å gjøre en presentasjon til personer som har vært involvert i utviklingsprosessen., De kan be for endringer, og du er nødt til å oppdatere SRS-dokument basert på interessentenes tilbakemelding før endelig godkjenning.
Dette er et godt tegn. Det betyr at både utviklere og interessenter er å gjøre dokumentet mer presis, så prosjektet er mindre lyst til å gå utenfor sporet.
Hvordan å Skrive Programvare som Bruker Tilfeller i en SRS
En brukstilfellet beskriver hvordan en bruker vil samhandle med systemet. Det vil beskrive produktet fra sluttbrukerens ståsted i en enkel historie-format. Skrive ut bruke tilfeller tvinger deg til å tenke gjennom hva brukerne vil gjøre med programvaren, og hvordan det vil reagere., Det er den virkelige visualisering av funksjonelle krav.
Her er noen skritt du kan følge for å skrive en use case:
- Beskrive produktet er sluttbrukere.
- Fokusere på ett av disse brukerne.
- Bryte denne brukerens vekselsvirkningene ned i bruken tilfeller. Samhandling er et use case.
- Beskrive sekvensen av hendelser for hver use case.
- Skriv en detaljert beskrivelse av brukerens handlinger og hvordan systemet skal reagere.
- Utvid hver use case med alternative handlinger brukeren og systemet svar.
- Gjenta 1-6 for hver type av sluttbrukeren.,
Hva er kjennetegnene på en bra SRS?
Det er spesielle egenskaper som hver SRS bør ha. Ved å gjennomgå denne listen og sammenligne den med din SRS, kan du sikre at det vil være et nyttig dokument for alle interessenter.
Eksplisitt
En SRS dokumentet skal være lett å forstå. Ingenting skulle være uklart, så det er ingen misforståelser mellom interessenter.,
Målbare
kravene i SRS dokumentet må være målbare, slik at det ferdige produktet kan bli godkjent og verifisert mot spesifikasjonene.
Fullført
En SRS dokumentet bør ha nok informasjon for din utvikling team for å fullføre produktet og for testere å kontrollere at produktet er i overensstemmelse med brukerens behov uten bugs.
Levedyktig
De krav som bør passe virkeligheten av det gjeldende miljøet, inkludert de økonomiske, tidslinje og teknologi. De bør ikke stole på kommende teknologiske gjennombrudd.,
Fleksibel
Fordi ting kan endre seg i arbeidsmiljøet, din SRS dokumentet bør være fleksibel nok til å tillate for oppdateringer. Ikke legg til redundant informasjon til flere deler som må oppdateres med hver endring.
Etterprøvbare
Alle på teamet skal ha tilgang til dokumentet, slik at de kan bruke det så ofte som nødvendig. Krav må være presise slik at gruppemedlemmene ikke har til å be om mer informasjon. De skal alle være tilgjengelig i SRS dokumentet.,
Konsistent
De krav som bør passe hverandre. En del av kravene dokumentet skal ikke komme i konflikt med en annen. Dokumentet skal være formatert og konsekvent brukt den samme terminologien hele.
Nei Gjennomføring Begrensninger
En SRS dokumentet bør være detaljert nok til å fullføre jobben, men bør ikke være alt for spesifikk, fordi det kan begrense utviklingen. Mye av utviklingen avhenger av tredjeparts tjenester som utviklere har ingen kontroll over.,
Nøyaktige
Mål i et krav dokumentet skal være presis for å unngå forvirring. Unngå følgende:
- Smutthull: «programmet skal legge i 3 sekunder hvis det kan gjøres.»
- Tvetydighet: «MVP produktet skal bli løslatt så raskt som mulig.»
- Subjektivitet: «BRUKERGRENSESNITTET skal være brukervennlig.»
- Superlativer: «Dette må være det beste programmet i sin klasse.»
- Sammenlignende: «Dette programmet skal være bedre enn Slakk.,»
En Programvare kravspesifikasjon (SRS) Eksempel på
Her er en trimmet ned eksempel på en SRS-dokument for en bedrift chat-app som heter eChat:
Innledning
Dette dokumentet detaljer prosjektet plan for utvikling av «eChat.»
Det er ment for utviklere, designere og testere som arbeider på «eChat», samt prosjekt investorer., Denne planen vil inneholde en oppsummering av:
- hvordan systemet vil fungere
- omfanget av prosjektet fra utvikling synspunkt
- teknologi som brukes til å utvikle prosjektet, og
- beregninger brukt til å bestemme prosjektets fremdrift
- Generell Beskrivelse
Bedrifter trenger ekstern kommunikasjon verktøy, spesielt nå som flere arbeider fra hjemmet. Problemet er at de fleste bedrifter ender opp med å bruke flere programmer for å oppnå dette: en for tekst-chat, ett for video-chat, og en for konferanser og møter., «eChat» vil løse dette problemet ved å kombinere disse funksjonene i ett program.
Last ned produktark
Kunder
kunder vil være enterprise selskaper. Det vil ikke mål allmennheten.
Funksjonalitet
- Brukere bør være i stand til å registrere deg med enterprise-LDAP-kontoer.,
- Brukere bør være i stand til å opprette ad hoc-chat-grupper bestående av et sett av brukere og sende private meldinger til individuelle brukere.
- Brukere bør være i stand til å ha tekstmeldinger om at de kan bryte seg inn i trådene.
- søknaden skal være i stand til å håndtere gruppen video chat for opptil 100 brukere på en gang.
Plattform
programmet vil bli utviklet i Reagerer Native å muliggjøre etableringen av en web-basert applikasjon, en iOS-app og en Android-mobil-app.
Disse programmene skal koble til en REST API bygget med .,NETTO Core til å lagre og hente data fra en MySQL database.
Godkjenning vil være gjennom eksisterende LDAP-installasjoner.
Utvikling Ansvar
utviklerne på «eChat» team vil være ansvarlig for å skrive all koden for programmet, utvikle databasen, og administrere utgivelser.,
User-Klassen og Egenskaper
Det vil være en klasse av brukere som kalles admin som vil ha tillatelse til å få tilgang til all funksjonalitet i appen, inkludert:
- Opprette tv der flere brukere kan samhandle
- for å Lage disse-tv offentlige til hele bedriften eller privat for en gruppe mennesker
- Slette disse kanalene
- Arkivering av disse kanalene
Standard brukere vil ha tilgang til all funksjonalitet i appen, unntatt de som er nevnt ovenfor.,
System Funksjoner
Funksjonelle Krav
- Brukere bør være i stand til å opprette ad hoc-chat-grupper bestående av et sett av brukere og sende private meldinger til andre brukere.
- Brukere bør være i stand til å ha tekstmeldinger om at de kan bryte seg inn i trådene.
- Samtaler skal være i stand til å bli arkivert på ubestemt tid, slik at brukere kan henvise til tidligere samtaler.
- Brukere bør være i stand til å laste opp filer til samtaler for referanse.
- Eksterne Grensesnitt Krav
brukergrensesnitt
- Front-end programvare: Reagerer Native
- Back-end programvare: .,s operativsystemer gjennom sin standard nettleser
- iPhone
- Android
- Ikke-Funksjonelle Krav
Krav til Ytelse
- programmet skal laste og kunne brukes innen 3 sekunder
- programmet skal oppdatere grensesnitt på samhandling innen 2 sekunder
- Databasen skal være normalisert å hindre overflødig data og forbedre ytelsen
- databasen bør fordeles for å hindre strømbrudd
Hms Krav
- Databaser bør bruke sharding å være overflødig å hindre tap av data.,
- Sikkerhetskopier av databaser bør gjøres hver time og holdes i en uke.
Sikkerhet Krav
- Alle tastene som brukes for RESTEN API bør være lagret sikkert.
- Bare RESTEN API bør være i stand til å koble til databaser.
- Databaser bør være bak en brannmur.
Software Kvalitet Attributter
- Tilgjengelighet: Fordi dette programmet er kritiske til virksomheten kommunikasjon, vil vi ha et mål om fire niere(99.99%) tilgjengelighet.,
- Korrekt: søknaden bør aldri tillate noen å lese meldinger eller diskusjoner som ikke er beregnet for denne personen.
- Vedlikehold: programmet skal bruke kontinuerlig integrasjon, slik at funksjoner og feilrettinger som kan distribueres raskt uten nedetid.
- Brukervennlighet: grensesnittet bør være lett å lære uten en tutorial og tillate brukere å oppnå sine mål uten feil.
Oppsummering
En SRS-dokument er en nødvendig del av å fullføre et software development project., Det er veikart som gir retning for alle som er involvert i prosjektet, slik at det endelige produktet tilfredsstiller brukerens behov.
Uten en fullstendig SRS dokumentet på plass før du begynner på et prosjekt, vil det være vanskelig å si når et prosjekt er ferdig, og du kan sidesteg utviklingen til å skape utilsiktede funksjoner. En SRS dokumentet gir deg muligheten til å estimere et prosjekt nøyaktig og tilordne oppgaver effektivt.
Opprette en SRS-dokument kan være en tidkrevende, møysommelig prosess., Heldigvis, teamet på Relevant har bidratt til over 200 bedrifter skaper SRS dokumenter og lansere nye produkter. Vi er klare til å hjelpe deg med din neste programvare-prosjekt, bare send oss en linje.