Oppretting av tekniske spesifikasjoner for utvikling av et informasjonssystem. Referansevilkår for design av informasjonssystem

Nylig henvendte de seg til meg for å gi meg råd om standarder for å skrive tekniske spesifikasjoner (TOR) for utvikling av automatiserte systemer (AS) og programvare(AV). Jeg tenker, nå skal jeg gå til Yandex, finne en passende artikkel og sende den. Men det var ikke der! Én artikkel viser standarder for tekniske spesifikasjoner, inkludert maler og eksempler ferdige dokumenter, Jeg fant ikke. Du må lage denne artikkelen selv...

Og så, de viktigste standardene, metodene og kunnskapene som nevner TK eller SRS (programvare (eller system) kravspesifikasjon):

GOST 34
GOST 19
IEEE STD 830-1998
ISO/IEC/IEEE 29148-2011
RUP
SWEBOK, BABOK, etc.

GOST 34

GOST 34.602-89 Referansevilkårene for å lage et automatisert system regulerer strukturen til de tekniske spesifikasjonene for å lage et SYSTEM, som inkluderer programvare, Maskinvare, folk som jobber med programvare og automatiserte prosesser.

I følge GOST 34 teknisk oppgave bør inkludere følgende seksjoner:

1. Generell informasjon
2. Formål og mål for etablering (utvikling) av systemet
3. Kjennetegn på automasjonsobjekter
4. Systemkrav
5. Sammensetning og innhold i arbeidet med å lage systemet
6. Prosedyre for kontroll og aksept av systemet
7. Krav til sammensetning og innhold av arbeid for å klargjøre automasjonsobjektet for igangkjøring av systemet
8. Dokumentasjonskrav
9. Utviklingskilder

Ved utvikling av tekniske spesifikasjoner for offentlige prosjekter, krever kunder som regel overholdelse av denne spesielle standarden.

GOST 19

«GOST 19.xxx ett system programdokumentasjon(ESPD)» er et sett med statlige standarder som etablerer sammenkoblede regler for utvikling, design og sirkulasjon av programmer (eller programvare) og programdokumentasjon. De. Denne standarden gjelder spesielt for programvareutvikling.
I henhold til GOST 19.201-78 tekniske spesifikasjoner, krav til innhold og design, må de tekniske spesifikasjonene inneholde følgende seksjoner:

1. Introduksjon;
2. Årsaker til utvikling;
3. Formål med utvikling;
4. Krav til programmet eller programvareproduktet;
5. Krav til programdokumentasjon;
6. Tekniske og økonomiske indikatorer;
7. Stadier og stadier av utvikling;
8. Prosedyre for kontroll og aksept;
9. Søknader.

Naturligvis er GOST 34 (og 19) allerede utdatert, og jeg liker ikke å bruke dem, men med riktig tolkning av standardene kan du få gode tekniske spesifikasjoner, se konklusjon.

IEEE STD 830-1998

Nok god definisjon standard 830-1998 - IEEE anbefalt praksis for spesifikasjoner for programvarekrav er gitt i selve beskrivelsen:

Beskriver innholdet og kvalitetsegenskaper en korrekt skrevet programvarekravspesifikasjon (SRS) og gir flere SRS-maler. Denne anbefalte praksisen er ment å etablere krav til programvare under utvikling, men kan også brukes til å hjelpe til med valg av proprietære og kommersielle programvareprodukter.

I henhold til standarden skal referansevilkårene inneholde følgende seksjoner:

1. Introduksjon

1. Formål
2. Omfang
3. Definisjoner, akronymer og forkortelser
4. Lenker
5. Kort oversikt

2. Generell beskrivelse

1. Produktinteraksjoner (med andre produkter og komponenter)
2. Produktfunksjoner (kort beskrivelse)
3. Brukeregenskaper
4. Begrensninger
5. Forutsetninger og avhengigheter

3. Detaljerte krav (kan organiseres på forskjellige måter, f.eks. slik)

1. Krav til eksterne grensesnitt
- 1. Brukergrensesnitt
- 2. Maskinvaregrensesnitt
- 3. Programvaregrensesnitt
- 4. Grensesnitt
2. Funksjonskrav
3. Ytelseskrav
4. Designbegrensninger (og referanser til standarder)
5. Ikke-funksjonelle krav (pålitelighet, tilgjengelighet, sikkerhet osv.)
6. Andre krav

4. Søknader
5. Alfabetisk indeks

Faktisk er det ganske vanskelig for en nybegynner å forstå hva som skal inneholde i disse seksjonene i henhold til strukturen ovenfor (som i tilfellet med GOST), så du må lese selve standarden, som. imidlertid på engelsk. Språk.

Vel, for de som leser til slutten, det er en bonus: et eksempel på tekniske spesifikasjoner som jeg skrev for mange år siden (nå har jeg ikke jobbet som analytiker på lenge, og andre mer vellykkede eksempler er forbudt å være åpnet for offentlig visning av NDA).

Presentasjon av Yuri Buluy Klassifisering av programvarekrav og dens representasjon i standarder og metoder.
Analyse av krav til automatiserte informasjonssystemer. Forelesning 11: Dokumentasjonskrav.
(les sammen med kommentarer)
Eksempler på tekniske spesifikasjoner og annen dokumentasjon for utvikling av AS for Utviklingsdepartementet
GOST ledelsesstil. Artikkel av Gaperton riktig drift fra tekniske spesifikasjoner i henhold til GOST
Business Analyst Dokumentmaler fra

GOST 34.602-89 Informasjonsteknologi. Et sett med standarder for automatiserte systemer Tekniske spesifikasjoner for opprettelsen automatisert system(I stedet for GOST 24.201-85)

Dato for introduksjon fra 01.01.1990

Denne standarden gjelder for automatiserte systemer (AS) for automatisering av ulike typer aktiviteter (ledelse, design, forskning, etc.), inkludert kombinasjoner, og fastsetter sammensetning, innhold, regler for utarbeidelse av dokumentet "Tekniske spesifikasjoner for opprettelsen ( utvikling eller modernisering) systemer" (heretter kalt TK for AS).

1. GENERELLE BESTEMMELSER

1.1. Den tekniske spesifikasjonen for et kjernekraftverk er hoveddokumentet som definerer kravene og prosedyren for å lage (utvikling eller modernisering - deretter opprettelse) av et automatisert system, i samsvar med hvilken utviklingen av kjernekraftverket utføres og dets aksept ved igangkjøring.

1.2. Spesifikasjoner for NPP er utviklet for systemet som helhet, ment å operere uavhengig eller som en del av et annet system.

I tillegg kan tekniske spesifikasjoner for deler av NPP utvikles:

for AS-delsystemer, AS-oppgavekomplekser osv. i samsvar med kravene i denne standarden;
for komponenter teknisk støtte og programvare- og maskinvaresystemer i samsvar med ESKD- og SRPP-standarder;
for programvare i samsvar med ESPD-standarder;
for informasjonsprodukter i henhold til GOST 19.201 og NTD gyldig i avdelingen til kunden til AS.

Merk. De tekniske spesifikasjonene for et automatisert kontrollsystem for en gruppe av sammenkoblede objekter bør kun omfatte krav som er felles for objektgruppen. Spesifikke krav av et separat kontrollobjekt bør gjenspeiles i de tekniske spesifikasjonene for det automatiserte kontrollsystemet til dette objektet.

1.3. Krav til høyttalere i den utstrekning denne standarden fastsetter kan inngå i prosjekteringsoppdraget igjen opprettet objekt automasjon. I dette tilfellet er det ikke utviklet tekniske spesifikasjoner for atomkraftverket.

1.4. Kravene som er inkludert i de tekniske spesifikasjonene for kjernekraftverk må samsvare med dagens utviklingsnivå for vitenskap og teknologi og ikke være dårligere enn tilsvarende krav som stilles til de beste moderne innenlandske og utenlandske analoger. Kravene spesifisert i de tekniske spesifikasjonene for NPP bør ikke begrense systemutvikleren i søk og implementering av de mest effektive tekniske, tekniske, økonomiske og andre løsningene.

1.5. Tekniske spesifikasjoner for kjernekraftverk er utviklet på grunnlag av innledende data, inkludert de som finnes i den endelige dokumentasjonen av stadiet "Forskning og begrunnelse for opprettelse av kjernekraftverk", etablert av GOST 24.601.

1.6. De tekniske spesifikasjonene for AS inkluderer bare de kravene som utfyller kravene til systemer av denne typen (ACS, CAD, ASNI, etc.) i gjeldende normative og tekniske dokumentasjon, og bestemmes av spesifikasjonene til det spesifikke objektet som systemet blir opprettet.

1.7. Endringer i de tekniske spesifikasjonene for NPP er formalisert ved et tillegg eller en protokoll signert av kunde og utvikler. Tillegget eller den spesifiserte protokollen er en integrert del av de tekniske spesifikasjonene for NPP. På tittelsiden til den tekniske spesifikasjonen for høyttaleren skal det være oppføringen "Gyldig fra...".

2. SAMMENSETNING OG INNHOLD

2.1. Den tekniske spesifikasjonen for NPP inneholder følgende seksjoner, som kan deles inn i underseksjoner:

1) generell informasjon;
2) formålet og målene for etableringen (utviklingen) av systemet;
3) egenskaper ved automatiseringsobjekter;
4) systemkrav;
5) sammensetning og innhold av arbeidet for å lage systemet;
6) prosedyren for kontroll og aksept av systemet;
7) krav til sammensetning og innhold av arbeid for å forberede automatiseringsobjektet for å sette systemet i drift;
8) dokumentasjonskrav;
9) kilder til utvikling.

Applikasjoner kan inkluderes i de tekniske spesifikasjonene for høyttalerne.

2.2. Avhengig av typen, formålet, spesifikke funksjoner til automatiseringsobjektet og driftsforholdene til systemet, er det mulig å utarbeide deler av de tekniske spesifikasjonene i form av applikasjoner, introdusere flere, ekskludere eller kombinere underseksjoner av de tekniske spesifikasjonene .

De tekniske spesifikasjonene for deler av systemet inkluderer ikke avsnitt som dupliserer innholdet i de tekniske spesifikasjonsdelene for systemet som helhet.

2.3. I delen "Generell informasjon" angir:

1) fullt navn på systemet og dets symbol;
2) emnekode eller kode (nummer) for kontrakten;
3) navnet på foretakene (foreningene) til utvikleren og kunden (brukeren) av systemet og deres detaljer;
4) en liste over dokumenter som systemet er opprettet på grunnlag av, av hvem og når disse dokumentene ble godkjent;
5) planlagte datoer for start og slutt på arbeidet med å lage systemet;
6) informasjon om kilder og prosedyre for finansiering av arbeidet;
7) prosedyren for registrering og presentasjon for kunden av resultatene av arbeidet med å lage systemet (dets deler), på produksjon og justering av individuelle midler (maskinvare, programvare, informasjon) og programvare og maskinvare (programvare og metodologiske) komplekser av systemet.

2.4. Avsnittet "Formål og mål for etablering (utvikling) av systemet" består av underavsnitt:

1) formålet med systemet;
2) målene for å lage systemet.

2.4.1. I underavsnittet "Formål med systemet" angir de typen aktivitet som automatiseres (administrasjon, design, etc.) og listen over automasjonsobjekter (anlegg) som den skal brukes på.

For automatiserte kontrollsystemer er det i tillegg angitt en liste over automatiserte kontrollorganer (punkter) og kontrollerte objekter.

2.4.2. I underavsnittet "Mål for å lage et system", er navnene og nødvendige verdier for tekniske, teknologiske, produksjonsmessige, økonomiske eller andre indikatorer for automatiseringsobjektet som må oppnås som et resultat av å lage et automatisert system gitt, og indikerer kriteriene for å vurdere oppnåelse av målene for å lage systemet.

2.5. I avsnittet "Kenskaper til automatiseringsobjektet" er følgende gitt:

1) kort informasjon om automatiseringsobjektet eller lenker til dokumenter som inneholder slik informasjon;
2) informasjon om driftsforholdene til automatiseringsobjektet og egenskapene til miljøet.

Merk: For CAD gir seksjonen i tillegg hovedparametrene og egenskapene til designobjekter.

2.6. "Systemkrav"-delen består av følgende underseksjoner:

1) krav til systemet som helhet;
2) krav til funksjoner (oppgaver) utført av systemet;
3) krav til typer sikkerhet.

Sammensetningen av kravene til systemet inkludert i denne delen av de tekniske spesifikasjonene for NPP er fastsatt avhengig av typen, formålet, spesifikke funksjoner og driftsforholdene til et bestemt system. Hvert underavsnitt gir lenker til gjeldende normativ og teknisk dokumentasjon som definerer kravene til systemer av tilsvarende type.

2.6.1. I underavsnittet "Krav til systemet som helhet" angir:

krav til systemets struktur og funksjon;
krav til antall og kvalifikasjoner til systempersonell og deres virkemåte;
destinasjonsindikatorer;
krav til pålitelighet;
sikkerhetskrav;
krav til ergonomi og teknisk estetikk;
transportabilitetskrav for mobile høyttalere;
driftskrav, vedlikehold, reparasjon og lagring av systemkomponenter;
krav for å beskytte informasjon mot uautorisert tilgang;
krav til informasjonssikkerhet i tilfelle ulykker;
krav til beskyttelse mot ytre påvirkninger;
krav til patentrenhet;
krav til standardisering og forening;
Tilleggskrav.

2.6.1.1. Kravene til strukturen og driften av systemet inkluderer:

1) en liste over delsystemer, deres formål og hovedegenskaper, krav til antall hierarkinivåer og graden av sentralisering av systemet;
2) krav til metoder og kommunikasjonsmidler for informasjonsutveksling mellom systemkomponenter;
3) krav til egenskaper ved relasjoner opprettet system med relaterte systemer, krav til kompatibilitet, inkludert instruksjoner om metoder for informasjonsutveksling (automatisk, ved å sende dokumenter, via telefon, etc.);
4) krav til systemdriftsmoduser;
5) krav til diagnostisering av systemet;
6) utsikter for utvikling og modernisering av systemet.

2.6.1.2. Kravene til antall og kvalifikasjoner til personell ved kjernekraftverk inkluderer:

krav til antall personell (brukere) av NPP;
krav til personellkvalifikasjoner, prosedyren for opplæring og kontroll av kunnskap og ferdigheter;
nødvendig driftsmodus for anleggspersonell.

2.6.1.3. I kravene til indikatorer for formålet med AS er verdiene til parametere som karakteriserer graden av samsvar med systemet med dets formål gitt.

For ACS angi:

graden av tilpasningsevne til systemet til endringer i prosesser og kontrollmetoder, til avvik i parametrene til kontrollobjektet;
akseptable grenser for modernisering og utvikling av systemet;
sannsynlighets-tidskarakteristikker under hvilke Spesielt formål systemer.

2.6.1.4. Pålitelighetskrav inkluderer:

1) sammensetning og kvantitative verdier av pålitelighetsindikatorer for systemet som helhet eller dets undersystemer;
2) liste nødsituasjoner, i henhold til hvilke pålitelighetskrav og verdiene til de tilsvarende indikatorene bør reguleres;
3) krav til pålitelighet tekniske midler og programvare;
4) krav til metoder for å vurdere og overvåke pålitelighetsindikatorer på ulike stadier lage et system i samsvar med gjeldende forskrifts- og tekniske dokumenter.

2.6.1.5. Sikkerhetskravene inkluderer krav for å ivareta sikkerhet under installasjon, igangkjøring, drift, vedlikehold og reparasjon av teknisk utstyr av systemet (beskyttelse mot påvirkninger elektrisk strøm, elektromagnetiske felt, akustisk støy, etc.), i henhold til tillatte nivåer av belysning, vibrasjon og støybelastning.

2.6.1.6. Kravene til ergonomi og teknisk estetikk inkluderer høyttalerindikatorer som spesifiserer nødvendig kvalitet menneske-maskin interaksjon og komfortable arbeidsforhold for personell.

2.6.1.7. For mobile høyttalere omfatter kravene til transportabilitet designkrav som sikrer transportabiliteten til de tekniske midlene i systemet, samt krav til kjøretøy.

2.6.1.8. Krav til drift, vedlikehold, reparasjon og lagring inkluderer:

1) betingelser og forskrifter (modus) for drift, som må sikre bruk av tekniske midler (TS) av systemet med spesifiserte tekniske indikatorer, inkludert typer og hyppighet av vedlikehold av TS av systemet eller tillatelighet av drift uten vedlikehold ;
2) foreløpige krav til de tillatte områdene for å imøtekomme personell og kjøretøysystemer, for parametere for strømforsyningsnettverk, etc.;
3) krav til antall, kvalifikasjoner til servicepersonell og deres driftsmoduser;
4) krav til sammensetning, plassering og lagringsforhold for et sett med reserveprodukter og instrumenter;
5) krav til vedlikeholdsforskrifter.

2.6.1.9. Kravene for å beskytte informasjon mot uautorisert tilgang inkluderer kravene fastsatt i den vitenskapelige og tekniske dokumentasjonen som gjelder i kundens bransje (avdeling).

2.6.1.10. Kravene til informasjonssikkerhet gir en liste over hendelser: ulykker, feil på teknisk utstyr (inkludert tap av strøm) etc., der informasjonssikkerheten i systemet skal ivaretas.

2.6.1.11. Kravene til midler for beskyttelse mot ytre påvirkning inkluderer:

1) krav til radioelektronisk beskyttelse av kjernekraftverk;
2) krav til holdbarhet, stabilitet og styrke til ytre påvirkninger(applikasjonsmiljø).

2.6.1.12. Kravene til patentrenhet angir en liste over land for hvilke patentrenheten til systemet og dets deler må sikres.

2.6.1.13. Kravene til standardisering og forening inkluderer: indikatorer som fastslår nødvendig grad av bruk av standard, enhetlige metoder for å implementere funksjonene (oppgavene) til det leverte systemet programvare, typisk matematiske metoder og modeller, standard designløsninger, enhetlige former for styringsdokumenter etablert av GOST 6.10.1, all-Union klassifikatorer av teknisk og økonomisk informasjon og klassifiserere av andre kategorier i samsvar med deres bruksområde, krav til bruk av standard automatiserte arbeidsstasjoner, komponenter og komplekser.

2.6.1.14. Ytterligere krav inkluderer:

1) krav for å utstyre systemet med enheter for opplæring av personell (simulatorer, andre enheter for lignende formål) og dokumentasjon for dem;
2) krav til serviceutstyr, står for testing av systemelementer;
3) systemkrav knyttet til spesielle driftsforhold;
4) spesielle krav etter systemutviklerens eller kundens skjønn.

2.6.2. I underavsnittet "Krav til funksjoner (oppgaver)" som utføres av systemet, er følgende gitt:

1) for hvert delsystem, en liste over funksjoner, oppgaver eller deres komplekser (inkludert de som sikrer samspillet mellom deler av systemet) underlagt automatisering;

når du oppretter et system i to eller flere køer - en liste over funksjonelle undersystemer, individuelle funksjoner eller oppgaver satt i drift i den første og påfølgende køene;

2) tidsbestemmelser for gjennomføring av hver funksjon, oppgave (eller sett med oppgaver);

3) krav til kvaliteten på implementeringen av hver funksjon (oppgave eller sett med oppgaver), for form for presentasjon av utdatainformasjon, kjennetegn ved nødvendig nøyaktighet og utførelsestid, krav til samtidig ytelse av en gruppe funksjoner, påliteligheten av resultatene;

4) liste og feilkriterier for hver funksjon som det er spesifisert pålitelighetskrav for.

2.6.3. I underavsnittet «Krav til typer støtte», avhengig av type system, er det gitt krav til matematisk, informasjon, språklig, programvare, teknisk, metrologisk, organisatorisk, metodisk og andre typer støtte for systemet.

2.6.3.1. For den matematiske støtten av systemet er det gitt krav til sammensetning, anvendelsesområde (begrensninger) og metoder for bruk av matematiske metoder og modeller i systemet, standardalgoritmer og algoritmer som skal utvikles.

2.6.3.2. Kravene til informasjonsstøtte for systemet er:

1) til sammensetningen, strukturen og metodene for å organisere data i systemet;
2) til informasjonsutveksling mellom systemkomponenter;
3) til informasjonskompatibilitet med relaterte systemer;
4) om bruk av alle-unions- og registrerte republikanske, industriklassifiserere, enhetlige dokumenter og klassifikatorer som opererer ved et gitt foretak;
5) om bruk av databasestyringssystemer;
6) til strukturen i prosessen med å samle inn, behandle, overføre data i systemet og presentere data;
7) for å beskytte data mot ødeleggelse under ulykker og strømbrudd i systemet;
8) å kontrollere, lagre, oppdatere og gjenopprette data;
9) til prosedyren for å gi rettskraft dokumenter produsert med tekniske midler fra NPP (i samsvar med GOST 6.10.4).

2.6.3.3. For språklig støtte av systemet er det gitt krav til bruk av programmeringsspråk i systemet. høy level, brukerinteraksjonsspråk og systemmaskinvare, samt krav til datakoding og -dekoding, datainndata-/utdataspråk, datamanipulasjonsspråk, beskrivelsesverktøy fagområde(automatiseringsobjekt), til måter å organisere dialog på.

2.6.3.4. For systemprogramvare er det gitt en liste over kjøpt programvare, samt krav:

1) til programvarens uavhengighet fra den brukte SVT-en og driftsmiljøet;
2) til kvaliteten på programvaren, så vel som metodene for levering og kontroll av den;
3) om nødvendig koordinere nyutviklet programvare med fondet av algoritmer og programmer.

2.6.3.5. For teknisk støtte av systemet er følgende krav gitt:

1) til typene tekniske midler, inkludert typene komplekser av tekniske midler, programvare- og maskinvarekomplekser og andre komponenter som er tillatt for bruk i systemet;
2) til funksjonelle, konstruktive og operasjonelle egenskaper hjelp av teknisk støtte til systemet.

2.6.3.6. Kravene til metrologisk støtte inkluderer:

1) foreløpig liste over målekanaler;
2) krav til nøyaktigheten av målinger av parametere og (eller) metrologiske egenskaper målekanaler;
3) krav til metrologisk kompatibilitet av tekniske midler i systemet;
4) en liste over kontroll- og datakanaler for systemet som det er nødvendig å evaluere nøyaktighetsegenskapene for;
5) krav til metrologisk støtte av maskinvare og programvare inkludert i systemets målekanaler, innebygde kontrollverktøy, metrologisk egnethet til målekanaler og måleinstrumenter brukt under idriftsettelse og testing av systemet;
6) type metrologisk sertifisering (statlig eller avdeling) som indikerer prosedyren for implementeringen og organisasjonene som utfører sertifisering.

2.6.3.7. For organisasjonsstøtte er følgende krav gitt:

1) til strukturen og funksjonene til enhetene som er involvert i driften av systemet eller sikre driften;

2) til organisering av funksjonen til systemet og prosedyren for samhandling mellom anleggspersonell og personell på automasjonsanlegg;

3) for å beskytte mot feilaktige handlinger fra systempersonell.

2.6.3.8. For metodisk støtte gir CAD krav til sammensetning av normative og teknisk dokumentasjon system (liste over standarder, forskrifter, metoder osv. som brukes i driften).

2.7. Avsnittet "Sammensetning og innhold av arbeidet med opprettelsen (utviklingen) av systemet" bør inneholde en liste over stadier og faser av arbeidet med opprettelsen av systemet i samsvar med GOST 24.601, tidspunktet for implementeringen, en liste over organisasjoner utføre arbeidet, lenker til dokumenter som bekrefter samtykket fra disse organisasjonene til å delta i opprettelsen av et system, eller en registrering som identifiserer personen som er ansvarlig (kunde eller utvikler) for å utføre dette arbeidet.

I denne seksjonen siter også:

1) en liste over dokumenter, i samsvar med GOST 34.201-89, presentert på slutten av de relevante stadiene og faser av arbeidet;
2) type og prosedyre for å gjennomføre undersøkelsen av teknisk dokumentasjon (stadium, stadium, volum av dokumentasjon som kontrolleres, ekspertorganisasjon);
3) et arbeidsprogram som tar sikte på å sikre det nødvendige nivået av pålitelighet til systemet som utvikles (om nødvendig);
4) en liste over arbeider med metrologisk støtte i alle stadier av opprettelsen av systemet, med angivelse av tidsfrister og utførende organisasjoner (om nødvendig).

2.8. I avsnittet "Prosedyre for kontroll og aksept av systemet" angir:

1) typer, sammensetning, volum og testmetoder for systemet og dets komponenter(typer av tester i samsvar med gjeldende standarder som gjelder for systemet som utvikles);
2) Generelle Krav for aksept av arbeid etter stadier (liste over deltakende bedrifter og organisasjoner, sted og tidspunkt), prosedyre for koordinering og godkjenning av akseptdokumentasjon;
H) status for akseptkomiteen (statlig, interdepartemental, institutt).

2.9. I avsnittet "Krav til sammensetning og innhold av arbeid for å forberede automatiseringsobjektet for igangkjøring av systemet," er det nødvendig å gi en liste over hovedaktivitetene og deres utøvere som bør utføres når du klargjør automatiseringsobjektet for å sette anlegget i drift.

Listen over hovedaktiviteter inkluderer:

1) bringe informasjonen inn i systemet (i samsvar med kravene til informasjon og språklig støtte) til et skjema som er egnet for behandling ved hjelp av en datamaskin;
2) endringer som må gjøres i automatiseringsobjektet;
3) opprettelse av betingelser for funksjonen til automatiseringsobjektet, der samsvaret til det opprettede systemet med kravene i de tekniske spesifikasjonene er garantert;
4) opprettelse av enheter og tjenester som er nødvendige for at systemet skal fungere;
5) timing og prosedyre for bemanning og opplæring.

For automatiske kontrollsystemer gir de for eksempel:

endringer i anvendte styringsmetoder;
skape forhold for drift av automatiserte kontrollsystemkomponenter, der systemets samsvar med kravene i de tekniske spesifikasjonene er garantert.

2.10. I delen "Dokumentasjonskrav" er følgende gitt:

1) en liste over sett og typer dokumenter som skal utvikles, avtalt av utvikleren og kunden av systemet, som oppfyller kravene i GOST 34.201-89 og NTD for kundens industri;
liste over dokumenter utstedt på datamedier;
krav til dokumentasjon på mikrofilm;
2) krav til dokumentering av komponentelementer for bruk på tvers av bransje i samsvar med kravene i ESKD og ESPD;
3) i fravær av statlige standarder som definerer kravene for å dokumentere systemelementer, inkluderer i tillegg krav til sammensetningen og innholdet av slike dokumenter.

2.11. Avsnittet "Kilder til utvikling" bør liste dokumenter og informasjonsmateriell (mulighetsstudier, rapporter om utført forskningsarbeid, informasjonsmateriell om innenlandske og utenlandske analoge systemer osv.), som de tekniske spesifikasjonene ble utviklet på grunnlag av og som bør bygges ut. brukes til å lage systemet.

2.12. I nærvær av godkjente metoder inkluderer de tekniske spesifikasjonene for kjernekraftverk vedlegg som inneholder:

1) beregning av forventet effektivitet av systemet;
2) vurdering av systemets vitenskapelige og tekniske nivå.

Søknader inngår i de tekniske spesifikasjonene for NPP som avtalt mellom utbygger og kunden av systemet.

3. REGISTRERINGSREGLER

3.1. Seksjoner og underseksjoner av de tekniske spesifikasjonene for NPP skal plasseres i den rekkefølgen som er fastsatt i pkt. 2 av denne standarden.

3.2. Tekniske spesifikasjoner for AS er utarbeidet i samsvar med kravene i GOST 2.105.95 på A4-ark i samsvar med GOST 2.301 uten ramme, hovedinnskrift og tilleggssøyler til den.

Ark (side) nummer plasseres, med start fra det første arket etter tittelsiden, øverst på arket (over teksten, i midten) etter angivelse av TK-koden på AC.

3.3. Verdiene til indikatorer, normer og krav er som regel angitt med maksimale avvik eller maksimum og minimumsverdier. Hvis disse indikatorene, normene og kravene er klart regulert av den vitenskapelige og tekniske dokumentasjonen, bør de tekniske spesifikasjonene for anlegget inneholde en lenke til disse dokumentene eller deres seksjoner, samt tilleggskrav som tar hensyn til funksjonene til systemet. opprettet. Hvis spesifikke verdier av indikatorer, normer og krav ikke kan fastsettes under utviklingen av tekniske spesifikasjoner for NPP, bør den registrere prosedyren for å etablere og bli enige om disse indikatorene, normene og kravene:

"Det endelige kravet (verdien) avklares i prosessen ... og avtales i protokollen med ... på stadiet ..."

Samtidig gjøres det ingen endringer i teksten til de tekniske spesifikasjonene for NPP.

3.4. Signaturene til kunden, utvikleren og godkjennende organisasjoner er plassert på tittelsiden, som forsegler offisielt segl. Ved behov er tittelbladet trukket opp på flere sider. Signaturene til utviklerne av de tekniske spesifikasjonene for kjernekraftverket og tjenestemennene som er involvert i godkjenningen og behandlingen av utkastet til tekniske spesifikasjoner for kjernekraftverket er plassert på det siste arket.

Formen på tittelsiden til mandatet for AS er gitt i vedlegg 2. Skjema siste ark De tekniske spesifikasjonene for NPP er gitt i vedlegg 3.

3.5. Om nødvendig er det tillatt å plassere koder etablert i bransjen på tittelsiden til de tekniske spesifikasjonene for høyttalerne, for eksempel: sikkerhetsklassifisering, arbeidskode, registreringsnummer TK osv.

3.6. Tittelsiden til tillegget til de tekniske spesifikasjonene for AS er utformet på samme måte tittelside tekniske spesifikasjoner. I stedet for navnet "Tekniske spesifikasjoner" skriver de "Tillegg nr. ... til de tekniske spesifikasjonene for AC...".

3.7. På etterfølgende ark av tillegget til de tekniske spesifikasjonene for AS, er grunnlaget for endringen, innholdet i endringen og lenker til dokumentene som disse endringene er gjort i henhold til.

3.8. Når du presenterer teksten til tillegget til de tekniske spesifikasjonene, bør du angi numrene til de tilsvarende avsnittene, underavsnittene, tabellene over de viktigste tekniske spesifikasjonene på AS, etc. og bruke ordene: "erstatt", "supplement", " ekskludere", "oppgi i en ny utgave".

PROSEDYRE FOR UTVIKLING, GODKJENNING OG GODKJENNING AV TOR FOR NPP

1. Utkastet til tekniske spesifikasjoner for NPP er utviklet av systemutviklerorganisasjonen med deltakelse av kunden på grunnlag tekniske krav(applikasjoner, taktiske og tekniske spesifikasjoner osv.).

Under den konkurransedyktige organiseringen av arbeidet vurderes alternativer for NPP-designspesifikasjonene av kunden, som enten velger det foretrukne alternativet, eller, basert på en sammenlignende analyse, forbereder det med deltakelse av den fremtidige NPP-utvikleren siste versjon TK på AC.

2. Behovet for å koordinere utkast til tekniske spesifikasjoner for NPP med myndighetene statlig tilsyn og andre interesserte organisasjoner bestemmes i fellesskap av kunden av systemet og utvikleren av utkastet til tekniske spesifikasjoner for NPP,

Arbeidet med å koordinere utkastet til tekniske spesifikasjoner for AC utføres i fellesskap av utvikleren av de tekniske spesifikasjonene for AC og kunden av systemet, hver i organisasjonene til sitt departement (avdeling).

3. Perioden for godkjenning av utkastet til tekniske spesifikasjoner for NPP i hver organisasjon bør ikke overstige 15 dager fra datoen for mottak. Det anbefales å sende kopier av utkast til tekniske spesifikasjoner for AS (kopier) samtidig til alle organisasjoner (avdelinger) for godkjenning.

4. Merknader til utkast til tekniske spesifikasjoner for NPP skal gis med en teknisk begrunnelse. Vedtak om merknader skal fattes av tiltakshaver av utkast til teknisk spesifikasjon for kjernekraftverket og kunde av systemet før godkjenning av tekniske spesifikasjoner for kjernekraftverket.

5. Hvis det ved enighet om utkast til tekniske spesifikasjoner for et kjernekraftverk oppstår uenigheter mellom utbygger og kunden (eller andre interesserte organisasjoner), så utarbeides det en uenighetsprotokoll (skjemaet er vilkårlig) og spesifikk løsning akseptert etter hvert.

6. Godkjenning av utkast til tekniske spesifikasjoner for NPP tillates et eget dokument(via brev). I dette tilfellet, under overskriften "Avtalt" er en lenke til dette dokumentet.

7. Godkjenningen av tekniske spesifikasjoner for NPP utføres av lederne for bedrifter (organisasjoner) til utvikleren og kunden av systemet.

8. Før den sendes inn for godkjenning, må den tekniske spesifikasjonen for NPP (tillegg til den tekniske spesifikasjonen) kontrolleres av forskriftskontrolltjenesten til organisasjonen som har utviklet den tekniske spesifikasjonen og, om nødvendig, underkastes metrologisk undersøkelse.

9. Kopi av godkjente tekniske spesifikasjoner for anlegget sendes av utvikler av tekniske spesifikasjoner for anlegget til deltakerne i systemopprettingen innen 10 dager etter godkjenning.

10. Samordning og godkjenning av tillegg til de tekniske spesifikasjonene for kjernekraftverket utføres på den måte som er fastsatt for de tekniske spesifikasjonene for kjernekraftverket.

11. Endringer i tekniske spesifikasjoner for NPP tillates ikke godkjent etter at systemet eller dets tur er sendt inn for akseptansetesting.

12. Registrering, regnskap og lagring av tekniske spesifikasjoner på NPP og tillegg til det utføres i samsvar med kravene i GOST 2.501.

FORM FOR TITTELSIDEN TIL TK PÅ AC

________________________________________________________

Navn
organisasjon - utvikler av tekniske spesifikasjoner for NPP

JEG GODKJENT

Veileder
(stilling, navn på bedriften - kunde av AS)

Personlig signatur
Fullt navn

Tetning

Dato

JEG GODKJENT

Veileder
(stilling, navn på bedrift - "AS-utvikler")

Personlig signatur
Fullt navn

Tetning

Dato

________________________________________________________

navnet på typen høyttaler

________________________________________________________

Objektnavn
automasjon

________________________________________________________

forkortet
navnet på taleren

TEKNISK OPPGAVE

På ____ ark

Gyldig
Med

AVTALT

Veileder
(stilling, navn på den godkjennende organisasjonen)

Personlig signatur
Fullt navn

Tetning

Dato

FORM FOR SISTE ARK AV TOREN PÅ AC

(TK-kode)

UTFULLT SOM AVTALT

VEDLEGG 4
Informasjon

BESTEMMELSER FOR OPPRETTELSE AV ET ENHETSSETT MED AUTOMATISKE SYSTEMSTANDARDER

1. Innledende forutsetninger for å skape komplekset

1.1. Opprettelsen og implementeringen av automatiserte systemer av ulike klasser og formål utføres i mange bransjer i henhold til regulatorisk og teknisk dokumentasjon som etablerer ulike organisatoriske, metodiske og tekniske standarder, regler og forskrifter som kompliserer integrasjonen av systemer og deres effektive felles funksjon.

1.2. I perioden da USSR State Standard tok en beslutning om å forbedre standardkomplekser mellom industrien, var følgende komplekser og standardsystemer i kraft, og etablerte krav til forskjellige typer AC:

1) et enhetlig system av standarder for automatiserte kontrollsystemer (24. system), som dekker automatiserte kontrollsystemer, automatiserte kontrollsystemer, prosesskontrollsystemer og andre organisatoriske og økonomiske systemer;
2) et sett med standarder (system 23501); utvide til datastøttede designsystemer;
3) den fjerde gruppen av det 14. standardsystemet, som dekker automatiserte systemer for teknologisk forberedelse av produksjon.

1.3. Praksisen med å anvende standarder for automatiserte kontrollsystemer, CAD, automatiserte prosesskontrollsystemer, automatiserte prosesskontrollsystemer har vist at de bruker det samme konseptuelle apparatet, det er mange vanlige objekter for standardisering, men kravene til standardene er ikke i samsvar med hver annet er det forskjeller i verkets sammensetning og innhold, forskjeller i betegnelse, sammensetning, innhold og utførelse av dokumenter mv.

1.4. På bakgrunn av fraværet av en enhetlig teknisk politikk i feltet for å skape AS, sikret ikke variasjonen av standarder bred kompatibilitet av AS under deres samhandling, tillot ikke systemer å bli replikert, og hindret utviklingen av lovende områder for bruk av datateknologi.

1.5. For tiden pågår en overgang til å lage komplekse automatiserte systemer (i utlandet, CAD - CAM-systemer), som inkluderer automatiserte kontrollsystemer teknologiske prosesser og produksjon, CAD - designer, CAD - teknolog, ASNI og andre systemer. Bruken av motstridende regler når man oppretter slike systemer fører til en reduksjon i kvalitet, en økning i kostnadene for arbeid og en forsinkelse i idriftsettelse av kjernekraftverk.

1.6. Et enkelt sett med standarder og veiledningsdokumenter bør gjelde for automatiserte systemer til ulike formål: ASNI, CAD, OASU, ASUP, ASUTP, ASUGPS, ASK, ASTPP, inkludert deres integrering.

1.7. Når du utvikler interindustrielle dokumenter, bør følgende funksjoner ved AS som standardiseringsobjekt tas i betraktning:

1) den tekniske spesifikasjonen er hoveddokumentet som opprettelsen av AS utføres i henhold til og aksept av kunden;
2) NPP er som regel skapt ved design, komplett med serie- og enkeltproduksjonsprodukter og utfører konstruksjon, installasjon, igangkjøring og igangkjøringsarbeid som er nødvendig for å sette NPP i drift;
3) i det generelle tilfellet består AS (AS-delsystemet) av programvare og maskinvare (PTK), programvare og metodiske komplekser (PMK) og komponenter av teknisk, programvare og informasjonsstøtte.
Komponentene til disse støttetypene, samt PMC og PTK, skal produseres og leveres som produkter til industrielle og tekniske formål.
Komponenter kan inkluderes i AS som uavhengige deler eller kan kombineres til komplekser;
4) opprettelsen av AS i organisasjoner (bedrifter) krever spesiell opplæring for brukere og systemvedlikeholdspersonell;
5) funksjonen til AS og komplekser er sikret av et sett med organisatoriske og metodiske dokumenter, vurdert under opprettelsesprosessen som komponenter av juridisk, metodisk, språklig, matematisk, organisatorisk og andre typer støtte. Individuelle løsninger oppnådd i prosessen med å utvikle denne programvaren kan implementeres i form av komponenter av maskinvare, programvare eller informasjonsstøtte;
6) felles funksjon og samhandling ulike systemer og komplekser utføres på grunnlag lokale nettverk DATAMASKIN.

Spesifikasjoner og avtaler vedtatt for lokale datanettverk er obligatoriske for å sikre kompatibilitet av systemer, komplekser og komponenter.

2. Sammenheng mellom CEN AS og andre systemer og standardsett

2.1. Standardisering innen høyttalere er integrert del jobber med det generaliserte problemet "Informasjonsteknologi".

2.2. Et enhetlig sett med standarder for styrende dokumenter for automatiserte systemer, sammen med andre systemer og sett med standarder, bør utgjøre en komplett regulatorisk og teknisk støtte for prosessene for opprettelse og drift av automatiserte systemer.

2.3. CEN AU bør dekke standardiseringsområder som er spesifikke for automatiserte systemer og utvide tradisjonelle standardiseringsområder til programvare og maskinvare, programvare og metodiske komplekser og automatiserte systemer generelt.

2.4. Retningene og oppgavene for standardisering i regulatorisk og teknisk støtte til prosessene for opprettelse og drift av kjernekraftverk er gruppert som følger:

1) etablering av tekniske krav til produkter;
2) regulering av testmetoder og regler for sertifisering og sertifisering av produkter;
3) regulering av regler og prosedyre for utvikling;
4) etablere dokumentasjonsregler;
5) sikre kompatibilitet;
6) regulering av organisatoriske og metodiske spørsmål om systemer som fungerer.

Retningslinjer 1-4 er tradisjonelle i utvikling, produksjon og levering av produkter. Retningene 5, 6 er spesifikke og kommer fra egenskapene som er iboende i AS.

2.5. Leveringen av kjernekraftverk som helhet og deres komponenter med regulatorisk og teknisk dokumentasjon innenfor rammen av aksepterte retningslinjer og standardiseringsoppgaver er annerledes.

Komponenter av maskinvare, programvare og informasjonsstøtte, som produkter for industrielle og tekniske formål, regnes som henholdsvis design, programvare og informasjonsprodukter. Disse produktene er underlagt gjeldende sett med standarder ESKD, SRPP, ESPD, SGIP, USD, klassifiserere og kodifikatorer av teknisk og økonomisk informasjon, sett med standarder som "OTT", "Test Methods", "TU", samt kundens OTT.

2.5.1. Alle Livssyklus designprodukter er fullt utstyrt med forskriftsmessig og teknisk dokumentasjon som er gyldig innen maskinteknikk og instrumentproduksjon.

2.5.2. Programvareprodukter leveres med vitenskapelig og teknisk dokumentasjon inkludert i ESPD og OTT til kunden. Omfanget av denne tekniske dokumentasjonen bør imidlertid utvides til å gjenspeile problemstillinger knyttet til utvikling, opprettelse, distribusjon og drift av programvareprodukter.

2.5.3. Informasjonsprodukter er foreløpig ikke utstyrt med vitenskapelig og teknisk dokumentasjon, selv om visse problemstillinger har blitt utarbeidet innenfor rammen av USD, klassifiserere og kodifikatorer av teknisk og økonomisk informasjon.

2.6. Programvare-maskinvare og programvare-metodologiske komplekser betraktes som komplekse produkter som ikke har noen analoger innen maskinteknikk. Tatt i betraktning statusen til PTC og PMK som produkter for industrielle og tekniske formål, bør reglene og prosedyren for deres utvikling være lik kravene fastsatt av standardene til systemet for utvikling og produksjon av produkter (SRPP).

Det unike med IP som et produkt for industrielle og tekniske formål, uttrykt i kompleksiteten, i fravær av standarder for de fleste typer prosedyrer og arbeid, gjør prosessen med planlegging og design svært kompleks og vanskelig. Når en bedrift samhandler med en IS-utvikler for et hvilket som helst formål, kreves to hoveddokumenter for å begynne arbeidet: en avtale og en teknisk spesifikasjon (TOR). Å utarbeide tekniske spesifikasjoner er en egen oppgave. Den tekniske spesifikasjonen i seg selv er faktisk et dokument som gjenspeiler alle kundens ønsker; det bør utarbeides så detaljert som mulig, og angi alle detaljer og visjon om resultatet. Kun på grunnlag av det vil det bli bestemt hva utviklerne er pålagt å gjøre, så mandatet bør utarbeides så detaljert som mulig.

Ved utforming av informasjonssystemer kreves de Detaljert beskrivelse. For disse formålene kan du bruke ulike måter og metoder, men de fleste effektiv løsning er utvikling av tekniske spesifikasjoner (TOR), som beskriver mål, målsettinger, grensesnitt og andre krav til objektet som utvikles.

En teknisk spesifikasjon er et dokument som definerer mål, krav og grunnleggende inputdata som er nødvendige for utviklingen av en IS. Den tekniske spesifikasjonen for en IP er hoveddokumentet som definerer kravene og prosedyren for opprettelse, utvikling eller modernisering av en IP, i samsvar med hvilken utvikling, idriftsettelse og aksept utføres.

Suksess med å implementere IP ligger i riktigheten av oppgaven satt av kunden. Jeg faller nødvendige forholdå skrive en god teknisk spesifikasjon er fullført, så vil resultatet bli fra forventet til gjennomførbart.

av kunden selv;

av entreprenøren, men i dette tilfellet vil hans ansvar omfatte design og testing;

konkurrerende utøvere hvis oppgaver bare inkluderer å skrive tekniske spesifikasjoner;

av tredjeparts entreprenører.

For de tekniske spesifikasjonene som er skrevet av entreprenøren, finnes det en rekke forskriftsmessig dokumentasjon:

GOST 21.408-93 "Regler for implementering av arbeidsdokumentasjon for automatisering av teknologiske prosesser";

GOST 34.201-89 "Typer, fullstendighet og betegnelse av dokumenter når du oppretter automatiserte systemer";

GOST 24.703-85 "Standard designløsninger i automatiserte kontrollsystemer. Grunnleggende bestemmelser";

GOST 34.003-90 "Automatiske systemer. Begreper og definisjoner";

GOST 34.601-90 "Automatiske systemer. Skapelsesstadier";

GOST 34.602-90 "Tekniske spesifikasjoner for å lage et automatisert system";

GOST 19.201-78 enhetlig system for programdokumentasjon;

GOST 2.114-95 enhetlig system for designdokumentasjon.

Teknisk spesifikasjon for en IS er en liste over grunnleggende operasjonelle, teknologiske, tekniske, organisatoriske, programvare-, informasjonslogiske og språklige, økonomiske og andre krav som IS må tilfredsstille på alle stadier av sin eksistens.

TK er tekstdokument, kompilert i hvilken som helst form. Det anbefales å sende inn nødvendige tegninger, diagrammer og store tabeller i form av vedlegg. Avhengig av typen, formålet og de spesifikke egenskapene til automatiseringsobjektet og driftsbetingelsene til systemet, er det mulig å utarbeide seksjoner av den tekniske spesifikasjonen i form av applikasjoner, introdusere ytterligere, ekskludere eller kombinere dens underseksjoner.

Det er ingen konkrete anbefalinger om hva den tekniske spesifikasjonen skal inneholde, noe som betyr at seksjoner og underseksjoner må utvikles og plasseres i den rekkefølge som er fastsatt av entreprenøren. Det er bare Generelle egenskaper seksjoner og underseksjoner. Utvikleren kan uavhengig endre, legge til og redigere navn og mengde.

Ark (side) nummer plasseres, med start fra det første arket etter tittelsiden, øverst på arket (over teksten, i midten) etter angivelse av TK-koden på IP.

Signaturene til kunden, utvikleren og godkjennende selskaper plasseres på tittelsiden og forsegles. Ved behov er tittelbladet trukket opp på flere sider. Signaturene til utviklerne av de tekniske spesifikasjonene og tjenestemenn som er involvert i godkjenningen og behandlingen av utkastet til tekniske spesifikasjoner for IP er plassert på det siste arket.

Tittelsiden til tillegget til de tekniske spesifikasjonene er utformet på samme måte som tittelsiden til de tekniske spesifikasjonene. I stedet for navnet "Tekniske spesifikasjoner" skriver de "Tillegg nr... til de tekniske spesifikasjonene for AC..."

På etterfølgende ark med tillegget til de tekniske spesifikasjonene, er grunnlaget for endringen, innholdet i endringen og lenker til dokumentene som disse endringene er gjort i henhold til.

Når du presenterer teksten til et tillegg til de tekniske spesifikasjonene, bør du angi numrene til de tilsvarende avsnittene, underavsnittene, tabellene over de viktigste tekniske spesifikasjonene osv. og bruke ordene: "erstatt", "suppler", "ekskluder", "stat i en ny utgave".

På det første stadiet utvikling av tekniske spesifikasjoner lager utøveren en grov innholdsplan.

Generell informasjon;

Hensikt og mål med å lage systemet;

Egenskaper til automatiseringsobjektet;

Systemkrav;

Vilkår for bruk;

Krav til programdokumentasjon;

Tekniske og økonomiske indikatorer;

Stadier og stadier av utvikling;

Kontroll og akseptprosedyre.

Disse seksjonene kan deles inn i underseksjoner. De tekniske spesifikasjonene kan også omfatte applikasjoner som er beskrevet i henhold til etablerte standarder. Entreprenøren kan legge til eller slette etter behov nødvendige seksjoner, må alle disse faktorene diskuteres med kunden. Ved å følge den fastsatte planen kan entreprenøren utvikle tekniske spesifikasjoner effektivt og på kort tid.

Om nødvendig lager utøveren en liste aksepterte forkortelser og ordliste.

Referansevilkår for IP-utvikling medisinsk institusjon lagt ut i vedlegg B.

Nylig henvendte de seg til meg for å gi meg råd om standarder for å skrive tekniske spesifikasjoner (TOR) for utvikling av automatiserte systemer (AS) og programvare (SW). Jeg tenker, nå skal jeg gå til Yandex, finne en passende artikkel og sende den. Men det var ikke der! Jeg fant ikke én artikkel som viser standarder for tekniske spesifikasjoner, inkludert maler og eksempler på ferdige dokumenter. Du må lage denne artikkelen selv...

Og så, de viktigste standardene, metodene og kunnskapene som nevner TK eller SRS (programvare (eller system) kravspesifikasjon):

GOST 34
GOST 19
IEEE STD 830-1998
ISO/IEC/IEEE 29148-2011
RUP
SWEBOK, BABOK, etc.

GOST 34

GOST 34.602-89 Referansevilkårene for opprettelse av et automatisert system regulerer strukturen til de tekniske spesifikasjonene for opprettelsen av SYSTEMET, som inkluderer programvare, maskinvare, personer som jobber med programvaren og automatiserte prosesser.

I følge GOST 34 må den tekniske spesifikasjonen inneholde følgende seksjoner:

Ved utvikling av tekniske spesifikasjoner for offentlige prosjekter, krever kunder som regel overholdelse av denne spesielle standarden.

GOST 19

"GOST 19.xxx Unified System of Program Documentation (USPD)" er et sett med statlige standarder som etablerer sammenkoblede regler for utvikling, design og sirkulasjon av programmer (eller programvare) og programdokumentasjon. De. Denne standarden gjelder spesielt for programvareutvikling.
I henhold til GOST 19.201-78 tekniske spesifikasjoner, krav til innhold og design, må de tekniske spesifikasjonene inneholde følgende seksjoner:

Naturligvis er GOST 34 (og 19) allerede utdatert, og jeg liker ikke å bruke dem, men med riktig tolkning av standardene kan du få gode tekniske spesifikasjoner, se konklusjon.

IEEE STD 830-1998

En ganske god definisjon av standard 830-1998 - IEEE Recommended Practice for Software Requirements Specifications er gitt i selve beskrivelsen:

Beskriver innholdet og kvalitetsegenskapene til en velskrevet programvarekravspesifikasjon (SRS) og gir flere SRS-maler. Denne anbefalte praksisen er ment å etablere krav til programvare under utvikling, men kan også brukes til å hjelpe til med valg av proprietære og kommersielle programvareprodukter.

I henhold til standarden skal referansevilkårene inneholde følgende seksjoner:

1. Introduksjon

1. Formål
2. Omfang
3. Definisjoner, akronymer og forkortelser
4. Lenker
5. Kort oversikt

2. Generell beskrivelse

1. Produktinteraksjoner (med andre produkter og komponenter)
2. Produktfunksjoner (kort beskrivelse)
3. Brukeregenskaper
4. Begrensninger
5. Forutsetninger og avhengigheter

3. Detaljerte krav (kan organiseres på forskjellige måter, f.eks. slik)

1. Krav til eksterne grensesnitt
- 1. Brukergrensesnitt
- 2. Maskinvaregrensesnitt
- 3. Programvaregrensesnitt
- 4. Grensesnitt
2. Funksjonskrav
3. Ytelseskrav
4. Designbegrensninger (og referanser til standarder)
5. Ikke-funksjonelle krav (pålitelighet, tilgjengelighet, sikkerhet osv.)
6. Andre krav

4. Søknader
5. Alfabetisk indeks

Presentasjon av Yuri Buluy Klassifisering av programvarekrav og dens representasjon i standarder og metoder.
Analyse av krav til automatiserte informasjonssystemer. Forelesning 11: Dokumentasjonskrav.
Regler for utarbeidelse av programvarekravspesifikasjon (les sammen med kommentarer)
Eksempler på tekniske spesifikasjoner og annen dokumentasjon for utvikling av AS for Utviklingsdepartementet
GOST ledelsesstil. Gaperton-artikkel om riktig arbeid med tekniske spesifikasjoner i henhold til GOST
Business Analyst Dokumentmaler fra

TEKNISK OPPGAVE

for utvikling av et informasjonssystem

1. Generell informasjon

4. Systemkrav

6. Prosedyre for kontroll og aksept av systemet

1. Generell informasjon

I samsvar med avtale nr. MP23 mellom TechnoPlus LLC (heretter referert til som utvikleren) og OptoTorgovlya LLC (heretter kalt kunden), designer utvikleren databasen, utvikler og setter i drift informasjonssystemet "Regnskap" handelsoperasjoner»

Startdatoen for utformingen av BDB anses å være dagen etter signering av denne tekniske spesifikasjonen

Dersom Kunden under utviklingsprosessen endrer kravene beskrevet i dette dokumentet, så er de utarbeidet i et eget dokument og innebærer en endring eller tillegg til Avtalen mellom Kunden og DB-Utvikler om frist for gjennomføring og betaling av avtalen.

Kunden betaler for arbeidet til Databaseutvikleren i henhold til Avtale nr. XXX

2. Formål og mål for etablering (utvikling) av systemet

IS "Regnskap for handelsoperasjoner" er designet for å lagre, behandle og analysere informasjon knyttet til kundens hovedaktiviteter.

Formålet med å opprette IS "Regnskap for handelsoperasjoner" er:

Lagre informasjon om fullførte handelsoperasjoner;

Refleksjon av handelstransaksjoner i regnskap;

Analyse av økonomiske resultater av handelsoperasjoner;

Analyse av handelsaktiviteter etter produktspekter og motparter.

3. Kjennetegn på automasjonsobjekter

3.1. Kundens hovedaktivitet er handel med møbler og tilhørende produkter ved bankoverføring.

3.2. Kunden er ikke momsbetaler

3.3. I løpet av dagen foretar Kunden ikke mer enn 100 handelstransaksjoner for kjøp og salg av varer.

3.4. Det totale volumet av produktutvalget overstiger ikke 3000 enheter

3.5. Det totale antallet motparter - leverandører er ikke mer enn 100 enheter.

3.6. Antall motparter – kjøpere – er ikke begrenset. På tidspunktet for signering av kontrakten var N XXX 300 enheter.

3.7. Kunden skriver av varer fra lageret etter metoden for vektet gjennomsnittlig kostnad.

3.9. Kun klasse 9-kontoer brukes som utgiftskontoer.

3.10. De økonomiske resultatene av foretakets handelsaktivitet (lønnsomhet og lønnsomhet av driften) beregnes på grunnlag av forskjellen mellom sektorene 702 og 902.

3.11. Handelstransaksjoner registreres i primærdokumentene Kvitteringsfaktura, Utgiftsfaktura, Kontoutskrift.

Pributkovs faktura (PN) vil indikere det faktum at varene har ankommet bedriftslageret og inkluderer følgende informasjon:

- Antall;

- Dato;

– Navn på motparten (selskap - posteier);

– navnet på produktet;

- styrke;

– enhetsprisen på produktet;

- sumu.

Vidatkovs faktura (VN) representerer det faktum at varene har blitt markedsført fra lageret til kjøperen og inneholder informasjon som ligner på informasjonen i PN (i stedet for leveringsselskapet er det innkjøpsselskapet angitt).

Bankutskriftsrad bekrefter faktum om mottak / vibrasjon av midler fra rozrakhunku (r/r)-bedriften og inneholder følgende informasjon:

- Dato;

– tegn på ankomst/betaling av midler;

– Navn på motparten (som ble funnet / som var overforsikret).

3.12. Hud primærdokument Det er en plattform for å gjøre regelmessige transaksjoner som resulterer i endringer i eksisterende regnskapsposter. Handelstransaksjoner krever følgende transaksjoner (tabell 3.1)

Tabell 3.1 – Konteringer brukt i regnskapet hos Kundens virksomhet

Operasjon	Dokument	Kontodebet	Kontokreditt	Transaksjons beløp
Innlegg	Kjøpsfaktura			dokumentbeløp
Forsendelse av varer	Salgsfaktura			dokumentbeløp
				kostnad for sendt varer
Mottak av penger til brukskonto	Kontoutskrift (kvittering)			dokumentbeløp
Overføring av penger fra en brukskonto	Kontoutskrift (utgifter)			dokumentbeløp
Fastsettelse av økonomiske resultater				for beløpet for avsluttende 902 kontoer
				for beløpet for å avslutte 702 kontoer

de 281 – varer på lager;

311 - rozrakhunkovy rakhunok i den onde valutaen;

361 – utsalgssteder med kurvkjøp;

631 - rozrakhunki med postarbeidere;

702 – inntekt fra salg av varer;

902 – kompatibilitet av solgte varer (uttak).

3.13. Balansen til den syntetiske formen ser ut som i tabell 3.2.

Tabell 3.2 – Omsetningsbalanse for syntetiske produkter

Artikkelnummer	Kolbebalanse	Snu seg	Kintseve balanse







Sammen

4. Systemkrav

IS «Regnskap for handelsoperasjoner» må oppfylle følgende krav:

4.1. Databasen for IS «Regnskap for handelsoperasjoner» skal gi lagring, visning og redigering av referanse- og driftsinformasjon.

Referanse informasjon:

o beskrivelse av varer:

Nomenklatur (produkt) nummer;

Produktnavn;

Beskrivelse;

o motparter – leverandører;

Motpartsnummer;

Entreprenørens navn;

Motpartsadresse;

Kontakter;

o motparter – kjøpere;

Motpartsnummer;

Entreprenørens navn;

Motpartsadresse;

Kontakter;

o kontoplan som regnskapsføres på for å registrere handelsoperasjoner og analysere økonomiske resultater;

o en liste over grunnleggende transaksjoner for å vise handelstransaksjoner i regnskap forårsaket av primærdokumenter, som ser slik ut, som i tabell 3.1;

Operativ informasjon:

o Primære dokumenter: Kvitteringsfaktura, utgiftsfaktura, kontoutskrift (beskrivelse av dokumenter er gitt i 3.11)

o Regnskapsposter forårsaket av primærdokumenter (type posteringer er vist i tabell 3.2)

o Informasjon om varer på lager:

Artikkelnummer;

Mengde;

Sum;

Gjennomsnittspris.

4.2. "Trade Operations Accounting" IS bør tillate deg å automatisere følgende handlinger:

4.2.1 Gjenspeil fakta om mottak (mottak) og forsendelse av varer på lageret, nemlig omberegn varemengden på lageret og dens gjennomsnittlige kostnad.

4.2.2 Generer regnskapsposter automatisk basert på primærdokumenter.

4.2.3 Søk etter følgende informasjon:

Primære dokumenter av den angitte typen for en viss periode;

Posteringer for en spesifisert dokumenttype for en bestemt dato;

Informasjon om motparten

Produktinformasjon

4.2.4 Gjennomfør en analyse av handelsaktivitet for den angitte perioden i følgende avsnitt:

Økonomiske resultater av handelsaktiviteter;

Resultater av oppgjør for hver motpart;

Resterende varer på lageret for hver vare;

Transaksjonskostnadene for hver motpart;

Kostnad og antall salg for hver type produkt

4.2.5 Generer rapporter for den angitte perioden:

Utstyret som IC er installert på må være utstyrt med en avbruddsfri strømforsyning. Ved strømbrudd skal IS automatisk slå seg av uten å miste data.

IS må ha backup-mekanismer, og IS må være utstyrt med passende maskinvare og programvare:

Kvantitative verdier av pålitelighetsindikatorer:

- tid automatisk fullføring arbeidet bør ikke ta mer enn 1 minutt;

- gjenopprettingstiden etter en feil bør ikke være mer enn 30 minutter;

- indeks feiltoleranse IP-en skal være 11/7, dvs. uavbrutt drift IS 11 timer i døgnet, 7 dager i uken.

Vedlikehold av IS må utføres uten å avbryte driften.

4.5 Krav til metoder for å vurdere og overvåke pålitelighetsindikatorer på prøvedriftsstadiet

For å overvåke pålitelighetsindikatorer på stadier av prøvedrift av IS, må vedlikeholdspersonell opprettholde en feillogg, som må inneholde følgende informasjonsskilt:

Datoen feilen oppsto;

Den totale driftstiden for objektet fra begynnelsen av driften til feilen ble oppdaget;

Ytre tegn og arten av feilen;

Type arbeid der feilen ble oppdaget.

4.6 IC ytelseskrav

Systemet skal støtte muligheten til å behandle opptil 1000 dokumenter per dag

Systemet må ha følgende ytelse:

80 % av operasjonene må ha en responstid (operasjonsgjennomføringstid) på mindre enn 1 sekund;

15 % av operasjonene – fra 5 sekunder. opptil 10 sek;

5 % av operasjonene - mer enn 10 sekunder, men ikke mer enn 30 minutter.

4.7 Krav til volumer (skalerbarhet)

Systemet skal støtte tilgang til data i 10 år.

Den estimerte økningen i databasevolum per dag i drift er 20 MB.

4.8 Krav til antall, funksjoner og kvalifikasjoner til IS-personell og deres virkemåte

Arbeidet med IS vil bli utført av følgende kundepersonell:

Administrator:

Antall: 1;

Kvalifikasjon: nettverksadministrator, databaseadministrator ;

Funksjoner: systemsikkerhetsadministrasjon, backup data ved begynnelsen av hver arbeidsdag, dataarkivering en gang i året;

Arbeidstid: 1 time daglig, 5 dager i uken

Operatøren (brukeren) som registrerer fakta om en handelsoperasjon og analyserer resultatene av handelsaktiviteter:

Antall: 2;

Kvalifikasjoner: regnskapsfører, PC-bruker;

Funksjoner: inntasting av primærdokumenter, vedlikehold nåværende situasjon lagerinformasjon, generere regnskapsposter, analysere handelsresultater, sikkerhetskopiere data ved begynnelsen av arbeidsdagen som faller på lørdag og søndag.

Arbeidstid: i skift for å sikre systemdrift 11 timer i døgnet, 7 dager i uken;

Tilgang til arbeid: 8-timers opplæringskurs;

Før IS settes i drift, for å få tillatelse til å arbeide, må personellet gjennomføre et 8-timers opplæringskurs. Etter å ha fullført kurset utføres testing, hvor riktigheten og hastigheten til løsningen vurderes praktiske problemer, samt kunnskap om jobb og tekniske instruksjoner.

Systemet skal kun gi tilgang til sine funksjoner til registrerte IS-brukere ved å spesifisere et passord.

4.10 Krav til programvare og sammensetning, struktur og metoder for organisering av IS-databasen

Data i systemet må lagres i relasjonell DBMS MS SQL Server 2000.

- T-SQL (SQL-språkdialekt);

MED # .

Programvaren består av generell systemprogramvare kjøpt på bekostning av Kunden (kjøpt programvare), og spesiell programvare utviklet som ledd i arbeidet med å lage IP-en.

Følgende programvare bør brukes som programvare for hele systemet:

Operativsystem;

Databasestyringssystem MS SQL Server 2000;

Programvare for sikkerhetskopiering;

4.11 Krav til maskinvare

Databaseserver, 2 arbeidsstasjoner.

Nettverksgjennomstrømningen er 100 Mbit per sekund.

4.12 Krav til utviklingsutsikter og IS-modernisering

Det må være mulig å modernisere og utvikle IS uten å involvere Utvikleren av IS-administratoren på nivå med:

- tillegg, endringer, slettinger referanse informasjon IP;

- koble til/fjerne nye IS-brukere;

- passordendringer;

- importere/eksportere data fra/til eksterne kilder data.

Det bør være mulig å modernisere og utvikle IS med begrenset deltakelse fra Utvikler (telefonkonsultasjoner) på nivå med modernisering av gamle rapporter og opprettelse av nye rapporter. Muligheten og betingelsene for telefonkonsultasjon fra utvikleren om IS-modernisering forhandles separat ved å signere en ny avtale.

5. Sammensetning og innhold i arbeidet med å lage systemet

Arbeidet med utformingen av IS «Regnskap for handelsoperasjoner» utføres i tre trinn.

Den første fasen inkluderer:

Sjekke muligheten for å få all informasjon som kunden ber om basert på de første dataene;

IS database design;

Fyller den utviklede databasen testsett data;

Utvikling av brukergrensesnittdesign;

Utvikling av en teknisk spesifikasjon på lavt nivå for utvikling av IS "Regnskap for handelsoperasjoner"

Slutten av den første fasen bekreftes ved signering av det interne sertifikatet for fullført arbeid og godkjenning av den tekniske spesifikasjonen på lavt nivå for utviklingen av IP.

Den andre fasen er utviklingen av en testversjon av IS "Accounting for Trade Operations". Slutt dette stadiet er å sette testversjonen i prøvedrift.

Det tredje trinnet er prøvedriften av IS "Regnskap for handelsoperasjoner", som inkluderer eliminering av identifiserte feil, mangler og inkonsistens med denne tekniske spesifikasjonen. Slutten på den andre fasen er introduksjonen av IS i kommersiell drift.

Gjennomføringen av hvert andre og tredje trinn bekreftes av avtalepartene ved å signere overførings- og akseptsertifikatet.

Varigheten av den første fasen er 10 dager. Begynnelsen av det første trinnet anses å være dagen etter den dagen kunden og DB-utvikleren signerte denne tekniske spesifikasjonen.

Varigheten av den andre fasen er 20 dager. Begynnelsen av den andre fasen anses å være dagen etter dagen for godkjenning av lavnivåteknisk spesifikasjon for utvikling av IP.

Varigheten av den tredje fasen er 20 dager. Begynnelsen av det tredje trinnet anses å være dagen etter den dagen Kunden og DB-utvikleren signerte akseptsertifikatet for testversjonen av IS for prøvedrift.

Datasettet for testing av IS leveres av kunden.

På slutten av den andre fasen av arbeidet, installerer DB-utvikleren en test-IS på kundens testserver og gir kunden en foreløpig brukermanual som inneholder en beskrivelse av prosedyrene som er nødvendige for å arbeide med "Trade Accounting"-IS. Beskrivelser er gitt i i elektronisk format.

På slutten av den tredje arbeidsfasen gir DB-utvikleren kunden et program for å installere databasen på serveren, samt bruker- og programmererinstruksjoner og instruksjoner for installasjon av IS med beskrivelser av prosedyrene som er nødvendige for å arbeide med IS "Regnskap for handelsoperasjoner".

6. Prosedyre for kontroll og aksept av systemet

På slutten av den første fasen signeres et internt sertifikat for fullført arbeid og lavnivåarbeidet godkjennes datablad for IP-utvikling.

På slutten av andre og tredje designstadium, installerer utvikleren IS hos kunden, demonstrerer driften av IS i samsvar med kravene angitt i denne tekniske spesifikasjonen, og signerer overførings- og akseptsertifikatet.

7. Krav til sammensetning og innhold av arbeid for å klargjøre automasjonsobjektet for igangkjøring av systemet

På dagen for starten av prøvedriften er Kunden forpliktet til å gi Utvikleren nødvendig tilgang til serveren som testversjonen av "Trade Operations Accounting" IS vil bli distribuert på.

Mangelen på en server for installering av IS «Accounting for Trade Operations»-databasen kan ikke være grunnlag for å nekte å signere akseptsertifikatet for IS «Accounting for Trade Operations» for prøvedrift eller kommersiell drift.

På slutten av den andre fasen av utviklingen av IS "Regnskap for handelsoperasjoner" gjennomfører utvikleren et 8-timers opplæringskurs med kundens personell om IS-vedlikehold. Ved ferdigstillelse dette kurset Kundens personell testes.

8. Dokumentasjonskrav

På slutten av det tredje trinnet overfører utvikleren av IS "Regnskap for handelsoperasjoner" følgende dokumentasjon til kunden:

1. Programmeringsinstruksjoner.

Programmererens instruksjoner beskriver prosedyrene som er nødvendige for å arbeide med "Trade Operations Accounting" IS. Beskrivelse av prosedyrer inkluderer:

Navn på prosedyren;

Beskrivelse av handlingene utført av prosedyren;

Beskrivelse inndataparametere, som indikerer typen parameter, opptaksformatet og standardverdien, hvis en er definert for parameteren;

Beskrivelse av utdataparametere og (eller) retursett med poster, som indikerer deres typer og formater

Et eksempel på et prosedyrekall og verdiene det returnerer. Hvis en prosedyre kan ha flere anropsalternativer, så eksempler for hvert alternativ.

2. Instruksjoner for installasjon av IS "Regnskap for handelsoperasjoner".

3. Instruksjoner for brukeren av IS "Regnskap for handelsoperasjoner".

Ingen annen dokumentasjon leveres til kunden. Instruksjoner leveres i både trykt og elektronisk format. Trykte instruksjoner leveres i ett eksemplar.