Udarbejdelse af tekniske specifikationer til udvikling af et informationssystem. Kommissorium for design af informationssystem

For nylig henvendte de sig til mig for at rådgive mig om standarder for at skrive tekniske specifikationer (TOR) til udvikling af automatiserede systemer (AS) og software(VED). Så jeg tror, nu vil jeg gå til Yandex, finde en passende artikel og sende den. Men det var der ikke! En artikel med standarder for tekniske specifikationer, inklusive skabeloner og eksempler færdige dokumenter, jeg fandt ikke. Du skal selv lave denne artikel...

Og så de vigtigste standarder, metoder og viden, der nævner TK eller SRS (Software (eller System) Requirements Specification):

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

GOST 34

GOST 34.602-89 Referencevilkårene for oprettelse af et automatiseret system regulerer strukturen af de tekniske specifikationer for oprettelse af et SYSTEM, som inkluderer software, Hardware, folk der arbejder med software og automatiserede processer.

Ifølge GOST 34 teknisk opgave skal indeholde følgende afsnit:

1. Generel information
2. Formål og mål for oprettelse (udvikling) af systemet
3. Karakteristika for automatiseringsobjekter
4. Systemkrav
5. Sammensætning og indhold af arbejdet med at skabe systemet
6. Procedure for kontrol og accept af systemet
7. Krav til sammensætning og indhold af arbejdet med at klargøre automatiseringsobjektet til idriftsættelse af systemet
8. Dokumentationskrav
9. Udviklingskilder

Ved udvikling af tekniske specifikationer for offentlige projekter kræver kunder som regel overholdelse af denne særlige standard.

GOST 19

"GOST 19.xxx ét system program dokumentation(ESPD)" er et sæt statsstandarder, der etablerer indbyrdes forbundne regler for udvikling, design og cirkulation af programmer (eller software) og programdokumentation. De der. Denne standard gælder specifikt for softwareudvikling.
I henhold til GOST 19.201-78 Tekniske specifikationer, krav til indhold og design skal de tekniske specifikationer omfatte følgende sektioner:

1. Introduktion;
2. Årsager til udvikling;
3. Formål med udvikling;
4. Krav til programmet eller softwareproduktet;
5. Krav til programdokumentation;
6. Tekniske og økonomiske indikatorer;
7. Stadier og stadier af udvikling;
8. Procedure for kontrol og accept;
9. Ansøgninger.

Naturligvis er GOST 34 (og 19) allerede forældede, og jeg kan ikke lide at bruge dem, men med den korrekte fortolkning af standarderne kan du få gode tekniske specifikationer, se konklusion.

IEEE STD 830-1998

Nok god definition standard 830-1998 - IEEE anbefalet praksis for softwarekravspecifikationer er givet i selve beskrivelsen:

Beskriver indholdet og kvalitetsegenskaber en korrekt skrevet softwarekravspecifikation (SRS) og indeholder flere SRS-skabeloner. Denne anbefalede praksis har til formål at fastlægge krav til software under udvikling, men kan også bruges til at hjælpe med udvælgelsen af proprietære og kommercielle softwareprodukter.

I henhold til standarden skal kommissoriet indeholde følgende afsnit:

1. Introduktion

1. Formål
2. Omfang
3. Definitioner, akronymer og forkortelser
4. Links
5. Kort oversigt

2. Generel beskrivelse

1. Produktinteraktioner (med andre produkter og komponenter)
2. Produktegenskaber (kort beskrivelse)
3. Brugeregenskaber
4. Begrænsninger
5. Antagelser og afhængigheder

3. Detaljerede krav (kan organiseres på forskellige måder, f.eks. på denne måde)

1. Krav til eksterne grænseflader
- 1. Brugergrænseflader
- 2. Hardware-grænseflader
- 3. Softwaregrænseflader
- 4. Grænseflader
2. Funktionelle krav
3. Ydelseskrav
4. Designbegrænsninger (og referencer til standarder)
5. Ikke-funktionelle krav (pålidelighed, tilgængelighed, sikkerhed osv.)
6. Andre krav

4. Ansøgninger
5. Alfabetisk indeks

Faktisk er det ret svært for en nybegynder at forstå, hvad der skal være indeholdt i disse sektioner i henhold til ovenstående struktur (som i tilfældet med GOST), så du skal læse selve standarden, som. dog på engelsk. Sprog.

Nå, for dem, der læser til slutningen, er der en bonus: et eksempel på tekniske specifikationer, som jeg skrev for mange år siden (nu har jeg ikke arbejdet som analytiker i lang tid, og andre mere vellykkede eksempler er forbudt at være åbnet for offentlig visning af NDA).

Præsentation af Yuri Buluy Klassificering af softwarekrav og dets repræsentation i standarder og metoder.
Analyse af krav til automatiserede informationssystemer. Foredrag 11: Dokumentationskrav.
(læs sammen med kommentarer)
Eksempler på tekniske specifikationer og anden dokumentation til udvikling af AS for Ministeriet for Økonomisk Udvikling
GOST ledelsesstil. Artikel af Gaperton korrekt drift fra tekniske specifikationer i henhold til GOST
Business Analyst Dokument skabeloner fra

GOST 34.602-89 Informationsteknologi. Et sæt standarder for automatiserede systemer Tekniske specifikationer for oprettelsen automatiseret system(I stedet for GOST 24.201-85)

Dato for introduktion fra 01/01/1990

Denne standard gælder for automatiserede systemer (AS) til automatisering af forskellige typer aktiviteter (ledelse, design, forskning osv.), herunder deres kombinationer, og fastlægger sammensætning, indhold, regler for udarbejdelse af dokumentet "Tekniske specifikationer for oprettelsen ( udvikling eller modernisering) systemer" (i det følgende benævnt TK for AS).

1. ALMINDELIGE BESTEMMELSER

1.1. Den tekniske specifikation for et atomkraftværk er hoveddokumentet, der definerer kravene og proceduren for oprettelse (udvikling eller modernisering - derefter oprettelse) af et automatiseret system, i overensstemmelse med hvilket udviklingen af atomkraftværket udføres og dets accept ved idriftsættelse.

1.2. Specifikationer for NPP er udviklet til systemet som helhed, beregnet til at fungere uafhængigt eller som en del af et andet system.

Derudover kan tekniske specifikationer for dele af kernekraftværket udvikles:

for AS-undersystemer, AS-opgavekomplekser osv. i overensstemmelse med kravene i denne standard;
for komponenter teknisk support og software- og hardwaresystemer i overensstemmelse med ESKD- og SRPP-standarder;
til software i overensstemmelse med ESPD-standarder;
for informationsprodukter i overensstemmelse med GOST 19.201 og NTD, der er gyldige i AS-kundens afdeling.

Bemærk. De tekniske specifikationer for et automatiseret kontrolsystem for en gruppe af indbyrdes forbundne objekter bør kun omfatte krav, der er fælles for gruppen af objekter. Specifikke krav af et separat kontrolobjekt bør afspejles i de tekniske specifikationer for dette objekts automatiserede kontrolsystem.

1.3. Krav til højttalere i det omfang, der er fastlagt af denne standard, kan indgå i designopgaven igen oprettet objekt automatisering. I dette tilfælde er tekniske specifikationer for atomkraftværket ikke udviklet.

1.4. Kravene, der er inkluderet i de tekniske specifikationer for atomkraftværker, skal svare til det nuværende udviklingsniveau for videnskab og teknologi og ikke være ringere end tilsvarende krav, der stilles til de bedste moderne indenlandske og udenlandske analoger. Kravene specificeret i de tekniske specifikationer for NPP bør ikke begrænse systemudvikleren i søgningen og implementeringen af de mest effektive tekniske, tekniske, økonomiske og andre løsninger.

1.5. Tekniske specifikationer for atomkraftværker er udviklet på grundlag af indledende data, herunder dem, der er indeholdt i den endelige dokumentation af stadiet "Forskning og begrundelse for oprettelse af atomkraftværker", etableret af GOST 24.601.

1.6. De tekniske specifikationer for AS'en omfatter kun de krav, der supplerer kravene til systemer af denne type (ACS, CAD, ASNI osv.), som er indeholdt i den aktuelle normative og tekniske dokumentation, og er bestemt af specifikationerne for det specifikke objekt, for hvilket systemet er ved at blive oprettet.

1.7. Ændringer af de tekniske specifikationer for NPP er formaliseret ved en tilføjelse eller en protokol underskrevet af kunden og udvikleren. Tilføjelsen eller den specificerede protokol er en integreret del af de tekniske specifikationer for NPP. På forsiden af den tekniske specifikation for højttaleren skal der være posten "Gyldig fra...".

2. SAMMENSÆTNING OG INDHOLD

2.1. Den tekniske specifikation for kernekraftværket indeholder følgende sektioner, som kan opdeles i underafsnit:

1) generel information;
2) formålet med og målene for oprettelsen (udviklingen) af systemet;
3) egenskaber ved automatiseringsobjekter;
4) systemkrav;
5) sammensætning og indhold af arbejdet for at skabe systemet;
6) proceduren for kontrol og accept af systemet;
7) krav til sammensætning og indhold af arbejdet for at forberede automatiseringsobjektet til at sætte systemet i drift;
8) dokumentationskrav;
9) kilder til udvikling.

Ansøgninger kan være inkluderet i de tekniske specifikationer for højttalerne.

2.2. Afhængigt af automatiseringsobjektets type, formål, specifikke egenskaber og systemets driftsbetingelser er det muligt at udarbejde sektioner af de tekniske specifikationer i form af applikationer, indføre yderligere, udelukke eller kombinere underafsnit af de tekniske specifikationer .

De tekniske specifikationer for dele af systemet omfatter ikke afsnit, der kopierer indholdet af de tekniske specifikationer for systemet som helhed.

2.3. I afsnittet "Generelle oplysninger" angives:

1) systemets fulde navn og dets symbol;
2) emnekode eller kode (nummer) for kontrakten;
3) navnet på virksomhederne (foreningerne) af udvikleren og kunden (brugeren) af systemet og deres detaljer;
4) en liste over dokumenter, på grundlag af hvilke systemet er oprettet, af hvem og hvornår disse dokumenter blev godkendt;
5) planlagte datoer for start og afslutning af arbejdet med at oprette systemet;
6) oplysninger om kilder og procedure for finansiering af arbejdet;
7) proceduren for registrering og præsentation for kunden af resultaterne af arbejdet med at skabe systemet (dets dele), om produktion og justering af individuelle midler (hardware, software, information) og software og hardware (software og metodiske) komplekser af systemet.

2.4. Afsnittet "Formål og mål med oprettelse (udvikling) af systemet" består af underafsnit:

1) formålet med systemet;
2) målene med at skabe systemet.

2.4.1. I underafsnittet "Formål med systemet" angiver de typen af aktivitet, der automatiseres (styring, design osv.) og listen over automatiseringsobjekter (faciliteter), som det er meningen, det skal bruges på.

For automatiserede styresystemer er der desuden angivet en liste over automatiserede kontrolorganer (punkter) og kontrollerede objekter.

2.4.2. I underafsnittet "Mål for oprettelse af et system" angives navnene og krævede værdier af tekniske, teknologiske, produktionsmæssige, økonomiske eller andre indikatorer for automatiseringsobjektet, der skal opnås som et resultat af oprettelse af et automatiseret system, og angiver kriterierne for vurdering af opnåelsen af målene for oprettelse af systemet.

2.5. I afsnittet "Karakteristika for automatiseringsobjektet" er følgende angivet:

1) kort information om automatiseringsobjektet eller links til dokumenter, der indeholder sådanne oplysninger;
2) information om automatiseringsobjektets driftsbetingelser og miljøets karakteristika.

Bemærk: For CAD giver afsnittet desuden de vigtigste parametre og karakteristika for designobjekter.

2.6. Afsnittet "Systemkrav" består af følgende underafsnit:

1) krav til systemet som helhed;
2) krav til funktioner (opgaver) udført af systemet;
3) krav til sikkerhedstyper.

Sammensætningen af kravene til systemet, der er inkluderet i dette afsnit af de tekniske specifikationer for NPP, fastlægges afhængigt af typen, formålet, specifikke funktioner og driftsbetingelser for et bestemt system. Hvert underafsnit indeholder links til den aktuelle normative og tekniske dokumentation, der definerer kravene til systemer af den tilsvarende type.

2.6.1. I underafsnittet "Krav til systemet som helhed" angives:

krav til systemets struktur og funktion;
krav til systempersonalets antal og kvalifikationer og deres funktionsmåde;
destinationsindikatorer;
krav til pålidelighed;
sikkerhedskrav;
krav til ergonomi og teknisk æstetik;
transportabilitetskrav til mobile højttalere;
driftskrav, vedligeholdelse, reparation og opbevaring af systemkomponenter;
krav til beskyttelse af information mod uautoriseret adgang;
krav til informationssikkerhed i tilfælde af ulykker;
krav til beskyttelse mod ydre påvirkninger;
krav til patentrenhed;
krav til standardisering og ensretning;
Yderligere krav.

2.6.1.1. Kravene til systemets struktur og drift omfatter:

1) en liste over delsystemer, deres formål og hovedkarakteristika, krav til antallet af hierarkiniveauer og graden af centralisering af systemet;
2) krav til metoder og kommunikationsmidler til informationsudveksling mellem systemkomponenter;
3) krav til relationers karakteristika oprettet system med relaterede systemer, krav til dets kompatibilitet, herunder instruktioner om metoder til informationsudveksling (automatisk, ved at sende dokumenter, via telefon osv.);
4) krav til systemdriftstilstande;
5) krav til diagnosticering af systemet;
6) udsigter til udvikling og modernisering af systemet.

2.6.1.2. Kravene til antallet og kvalifikationerne for personale på atomkraftværker omfatter:

krav til antallet af personale (brugere) af kernekraftværket;
krav til personalekvalifikationer, proceduren for deres uddannelse og kontrol med viden og færdigheder;
påkrævet driftstilstand for anlæggets personale.

2.6.1.3. I kravene til indikatorer for formålet med AS er værdierne af parametre, der karakteriserer graden af systemets overensstemmelse med dets formål, angivet.

For ACS angiv:

graden af tilpasningsevne af systemet til ændringer i processer og kontrolmetoder, til afvigelser i parametrene for kontrolobjektet;
acceptable grænser for modernisering og udvikling af systemet;
sandsynligheds-tidskarakteristika, hvorunder særligt formål systemer.

2.6.1.4. Kravene til pålidelighed omfatter:

1) sammensætning og kvantitative værdier af pålidelighedsindikatorer for systemet som helhed eller dets undersystemer;
2) liste nødsituationer, ifølge hvilke pålidelighedskrav og værdierne af de tilsvarende indikatorer skal reguleres;
3) krav til pålidelighed tekniske midler og software;
4) krav til metoder til vurdering og overvågning af pålidelighedsindikatorer på forskellige stadier oprettelse af et system i overensstemmelse med gældende lovgivningsmæssige og tekniske dokumenter.

2.6.1.5. Sikkerhedskravene omfatter krav til sikring af sikkerhed under installation, idriftsættelse, drift, vedligeholdelse og reparation af systemets teknisk udstyr (beskyttelse mod påvirkninger elektrisk strøm, elektromagnetiske felter, akustisk støj osv.), i henhold til tilladte niveauer af belysning, vibrationer og støjbelastninger.

2.6.1.6. Kravene til ergonomi og teknisk æstetik omfatter højttalerindikatorer, der specificerer påkrævet kvalitet menneske-maskine interaktion og behagelige arbejdsforhold for personalet.

2.6.1.7. For mobile højttalere omfatter kravene til transportabilitet designkrav, der sikrer transportabiliteten af systemets tekniske midler, samt krav til køretøjer.

2.6.1.8. Krav til drift, vedligeholdelse, reparation og opbevaring omfatter:

1) betingelser og regler (driftsmåde), som skal sikre brugen af systemets tekniske midler (TS) med specificerede tekniske indikatorer, herunder typen og hyppigheden af vedligeholdelse af systemets TS eller tilladeligheden af drift uden vedligeholdelse ;
2) foreløbige krav til de tilladte områder til at rumme personale og køretøjssystemer, til parametrene for strømforsyningsnetværk osv.;
3) krav til antal, kvalifikationer for servicepersonale og deres driftsformer;
4) krav til sammensætning, placering og opbevaringsbetingelser for et sæt reserveprodukter og -anordninger;
5) krav til vedligeholdelsesforskrifter.

2.6.1.9. Kravene til beskyttelse af information mod uautoriseret adgang omfatter de krav, der er fastsat i den videnskabelige og tekniske dokumentation, der gælder i kundens branche (afdeling).

2.6.1.10. Kravene til informationssikkerhed giver en liste over hændelser: ulykker, svigt af teknisk udstyr (herunder strømsvigt) mv., hvor informationssikkerheden i systemet skal sikres.

2.6.1.11. Kravene til midler til beskyttelse mod ydre påvirkninger omfatter:

1) krav til radioelektronisk beskyttelse af atomkraftværker;
2) krav til holdbarhed, stabilitet og styrke til ydre påvirkninger(anvendelsesmiljø).

2.6.1.12. Kravene til patentrenhed angiver en liste over lande, for hvilke patentrenheden af systemet og dets dele skal sikres.

2.6.1.13. Kravene til standardisering og ensretning omfatter: indikatorer, der fastlægger den nødvendige grad af brug af standard, ensartede metoder til implementering af funktionerne (opgaverne) i det leverede system software, typisk matematiske metoder og modeller, standarddesignløsninger, ensartede former for styringsdokumenter etableret af GOST 6.10.1, klassifikatorer i hele EU af teknisk og økonomisk information og klassifikatorer af andre kategorier i overensstemmelse med deres anvendelsesområde, krav til brug af standard automatiserede arbejdsstationer, komponenter og komplekser.

2.6.1.14. Yderligere krav omfatter:

1) krav til at udstyre systemet med udstyr til personaletræning (simulatorer, andre enheder til lignende formål) og dokumentation for dem;
2) krav til serviceudstyr, står for test af systemelementer;
3) systemkrav relateret til særlige driftsforhold;
4) særlige krav efter systemudviklerens eller kundens skøn.

2.6.2. I underafsnittet "Krav til funktioner (opgaver)" udført af systemet er følgende angivet:

1) for hvert delsystem en liste over funktioner, opgaver eller deres komplekser (inklusive dem, der sikrer samspillet mellem dele af systemet) underlagt automatisering;

ved oprettelse af et system i to eller flere køer - en liste over funktionelle undersystemer, individuelle funktioner eller opgaver sat i drift i den 1. og efterfølgende køer;

2) tidsregler for gennemførelsen af hver funktion, opgave (eller sæt af opgaver);

3) krav til kvaliteten af implementeringen af hver funktion (opgave eller sæt af opgaver), til form for præsentation af outputinformation, karakteristika for den nødvendige nøjagtighed og udførelsestid, krav til samtidig udførelse af en gruppe af funktioner, pålideligheden af resultaterne;

4) liste og fejlkriterier for hver funktion, for hvilke der er specificeret pålidelighedskrav.

2.6.3. I underafsnittet "Krav til typer af støtte" er der afhængig af systemtype angivet krav til matematisk, informationsmæssig, sproglig, software, teknisk, metrologisk, organisatorisk, metodisk og andre former for støtte til systemet.

2.6.3.1. Til den matematiske understøttelse af systemet stilles krav til sammensætning, anvendelsesområde (begrænsninger) og metoder til at anvende matematiske metoder og modeller i systemet, standardalgoritmer og algoritmer, der skal udvikles.

2.6.3.2. Kravene til informationsunderstøttelse af systemet er:

1) til sammensætning, struktur og metoder til organisering af data i systemet;
2) til informationsudveksling mellem systemkomponenter;
3) til informationskompatibilitet med relaterede systemer;
4) om brugen af alle-unions- og registrerede republikanske, industriklassifikatorer, forenede dokumenter og klassifikatorer, der opererer på en given virksomhed;
5) om brugen af databasestyringssystemer;
6) til strukturen af processen med at indsamle, behandle, overføre data i systemet og præsentere data;
7) at beskytte data mod ødelæggelse under ulykker og systemstrømsvigt;
8) at kontrollere, gemme, opdatere og gendanne data;
9) til proceduren for at give retskraft dokumenter produceret ved hjælp af tekniske midler fra NPP (i overensstemmelse med GOST 6.10.4).

2.6.3.3. Til sproglig understøttelse af systemet oplyses krav til brug af programmeringssprog i systemet. højt niveau, brugerinteraktionssprog og systemhardware, samt krav til datakodning og -afkodning, datainput/outputsprog, datamanipulationssprog, beskrivelsesværktøjer emneområde(automatiseringsobjekt), til måder at organisere dialog på.

2.6.3.4. For systemsoftware leveres en liste over købt software samt krav:

1) til softwarens uafhængighed fra det brugte SVT og driftsmiljø;
2) til kvaliteten af software, såvel som til metoderne til dets levering og kontrol;
3) om nødvendigt koordinere nyudviklet software med fonden af algoritmer og programmer.

2.6.3.5. Til teknisk support af systemet stilles følgende krav:

1) til typerne af tekniske midler, herunder typer af komplekser af tekniske midler, software- og hardwarekomplekser og andre komponenter, der er tilladt til brug i systemet;
2) til funktionelle, konstruktive og operationelle egenskaber midler til teknisk support af systemet.

2.6.3.6. Kravene til metrologisk støtte omfatter:

1) foreløbig liste over målekanaler;
2) krav til nøjagtigheden af målinger af parametre og (eller) metrologiske egenskaber målekanaler;
3) krav til metrologisk kompatibilitet af systemets tekniske midler;
4) en liste over kontrol- og beregningskanaler i systemet, for hvilke det er nødvendigt at evaluere nøjagtighedsegenskaberne;
5) krav til metrologisk understøttelse af hardware og software, der indgår i systemets målekanaler, indbyggede styringsværktøjer, metrologisk egnethed af målekanaler og måleinstrumenter anvendt under idriftsættelse og test af systemet;
6) type metrologisk certificering (stat eller departement), der angiver proceduren for dens gennemførelse og de organisationer, der udfører certificering.

2.6.3.7. Til organisatorisk støtte stilles følgende krav:

1) til strukturen og funktionerne af de enheder, der er involveret i driften af systemet eller sikringen af driften;

2) til tilrettelæggelsen af systemets funktion og proceduren for interaktion mellem anlægspersonale og automationsanlægspersonale;

3) for at beskytte mod fejlagtige handlinger fra systempersonalet.

2.6.3.8. Til metodisk støtte stiller CAD krav til sammensætning af normative og teknisk dokumentation system (liste over standarder, forskrifter, metoder osv. anvendt i dets drift).

2.7. Afsnittet "Sammensætning og indhold af arbejdet med oprettelse (udvikling) af systemet" bør indeholde en liste over stadier og faser af arbejdet med oprettelse af systemet i overensstemmelse med GOST 24.601, tidspunktet for deres implementering, en liste over organisationer udfører arbejdet, links til dokumenter, der bekræfter disse organisationers samtykke til at deltage i oprettelsen af et system, eller en registrering, der identificerer den person, der er ansvarlig (kunde eller udvikler) for at udføre dette arbejde.

I dette afsnit citerer også:

1) en liste over dokumenter, i overensstemmelse med GOST 34.201-89, præsenteret i slutningen af de relevante stadier og faser af arbejdet;
2) type og procedure for udførelse af undersøgelse af teknisk dokumentation (stadie, fase, mængden af dokumentation, der kontrolleres, ekspertorganisation);
3) et arbejdsprogram, der tager sigte på at sikre det krævede niveau af pålidelighed af det system, der udvikles (hvis nødvendigt);
4) en liste over arbejder med metrologisk støtte på alle stadier af oprettelsen af systemet, med angivelse af deres deadlines og udførende organisationer (hvis nødvendigt).

2.8. I afsnittet "Procedure for kontrol og accept af systemet" angives:

1) typer, sammensætning, volumen og testmetoder for systemet og dets komponenter(typer af test i overensstemmelse med gældende standarder, der gælder for det system, der udvikles);
2) Generelle krav for accept af arbejde efter etaper (liste over deltagende virksomheder og organisationer, sted og tidspunkt), procedure for koordinering og godkendelse af acceptdokumentation;
H) status for overtagelsesudvalget (statslig, tværministeriel, afdelingsmæssig).

2.9. I afsnittet "Krav til sammensætning og indhold af arbejdet med at forberede automatiseringsobjektet til idriftsættelse af systemet" er det nødvendigt at give en liste over de vigtigste aktiviteter og deres udførende, der skal udføres, når automatiseringsobjektet klargøres til at sætte anlæg i drift.

Listen over hovedaktiviteter omfatter:

1) at bringe oplysningerne ind i systemet (i overensstemmelse med kravene til information og sproglig støtte) til en form, der er egnet til behandling ved hjælp af en computer;
2) ændringer, der skal foretages i automatiseringsobjektet;
3) skabelse af betingelser for funktion af automatiseringsobjektet, hvorunder det oprettede systems overensstemmelse med kravene i de tekniske specifikationer er garanteret;
4) oprettelse af enheder og tjenester, der er nødvendige for systemets funktion;
5) timing og procedure for bemanding og uddannelse.

For automatiske kontrolsystemer giver de for eksempel:

ændringer i anvendte ledelsesmetoder;
skabe betingelser for driften af automatiserede styresystemkomponenter, hvorunder systemets overensstemmelse med kravene i de tekniske specifikationer er garanteret.

2.10. I afsnittet "Dokumentationskrav" er følgende angivet:

1) en liste over sæt og typer af dokumenter, der skal udvikles, aftalt af udvikleren og kunden af systemet, der opfylder kravene i GOST 34.201-89 og NTD for kundens industri;
liste over dokumenter udstedt på computermedier;
krav til dokumentation for mikrofilm;
2) krav til dokumentation af komponentelementer til brug på tværs af industrien i overensstemmelse med kravene i ESKD og ESPD;
3) i mangel af statslige standarder, der definerer kravene til dokumentation af systemelementer, omfatter desuden krav til sammensætningen og indholdet af sådanne dokumenter.

2.11. Afsnittet "Udviklingskilder" bør angive dokumenter og informationsmateriale (feasibility-undersøgelser, rapporter om afsluttet forskningsarbejde, informationsmateriale om indenlandske og udenlandske analoge systemer osv.), på grundlag af hvilke de tekniske specifikationer er udviklet, og som bør bruges til at skabe systemet.

2.12. Ved tilstedeværelse af godkendte metoder omfatter de tekniske specifikationer for atomkraftværker bilag, der indeholder:

1) beregning af systemets forventede effektivitet;
2) vurdering af systemets videnskabelige og tekniske niveau.

Applikationer er inkluderet i de tekniske specifikationer for kernekraftværket som aftalt mellem bygherren og kunden af systemet.

3. REGISTRERINGSREGLER

3.1. Afsnit og underafsnit af de tekniske specifikationer for kernekraftværket skal placeres i den rækkefølge, der er fastsat i afsnit. 2 i denne standard.

3.2. Tekniske specifikationer for AS er udarbejdet i overensstemmelse med kravene i GOST 2.105.95 på A4-ark i overensstemmelse med GOST 2.301 uden en ramme, hovedinskription og yderligere kolonner til den.

Ark (side) numre placeres, startende fra det første ark efter titelbladet, øverst på arket (over teksten i midten) efter angivelse af TK-koden på AC.

3.3. Værdierne af indikatorer, normer og krav er som regel angivet med maksimale afvigelser eller maksimum og minimumsværdier. Hvis disse indikatorer, normer og krav er klart reguleret af den videnskabelige og tekniske dokumentation, bør de tekniske specifikationer for anlægget indeholde et link til disse dokumenter eller deres sektioner, samt yderligere krav, der tager højde for systemets egenskaber. oprettet. Hvis specifikke værdier af indikatorer, normer og krav ikke kan fastlægges under udviklingen af tekniske specifikationer for kernekraftværket, bør den lave en registrering af proceduren for etablering og enighed om disse indikatorer, normer og krav:

"Det endelige krav (værdi) afklares i processen... og aftales af protokollen med... på stadiet..."

Samtidig er der ingen ændringer i teksten til de tekniske specifikationer for kernekraftværket.

3.4. Underskrifterne fra kunden, udvikleren og godkendende organisationer er placeret på titelbladet, som forsegler officielt segl. Om nødvendigt tegnes titelbladet på flere sider. Underskrifterne fra udviklerne af de tekniske specifikationer for atomkraftværket og de embedsmænd, der er involveret i godkendelsen og behandlingen af udkastet til tekniske specifikationer for atomkraftværket, er placeret på det sidste ark.

Formen for titelbladet til kommissoriet for AS er angivet i bilag 2. Form sidste ark De tekniske specifikationer for kernekraftværket er angivet i bilag 3.

3.5. Om nødvendigt er det tilladt at placere koder etableret i branchen på forsiden af de tekniske specifikationer for højttalerne, for eksempel: sikkerhedsklassificering, arbejdskode, registreringsnummer TK osv.

3.6. Titelsiden på tillægget til de tekniske specifikationer for AS'en er udformet på samme måde titel side tekniske specifikationer. I stedet for navnet "Tekniske specifikationer" skriver de "Tilføjelse nr. ... til de tekniske specifikationer for AC...".

3.7. På efterfølgende ark af tillægget til de tekniske specifikationer for AS'et er grundlaget for ændringen, indholdet af ændringen og links til de dokumenter, som disse ændringer er foretaget i henhold til.

3.8. Når du præsenterer teksten til en tilføjelse til de tekniske specifikationer, skal du angive numrene på de tilsvarende afsnit, underafsnit, tabeller over de vigtigste tekniske specifikationer på AS'et osv. og bruge ordene: "erstat", "suppler", " udelukke", "angiv i en ny udgave".

PROCEDURE FOR UDVIKLING, GODKENDELSE OG GODKENDELSE AF TOR TIL NPP

1. Udkastet til tekniske specifikationer for NPP er udviklet af systemudviklerorganisationen med deltagelse af kunden på basis af tekniske krav(applikationer, taktiske og tekniske specifikationer osv.).

Under den konkurrenceprægede tilrettelæggelse af arbejdet overvejes mulighederne for NPP-designspecifikationerne af kunden, som enten vælger den foretrukne mulighed eller, baseret på en sammenlignende analyse, forbereder den med deltagelse af den fremtidige NPP-udvikler sidste version TK på AC.

2. Behovet for at koordinere udkastet til tekniske specifikationer for kernekraftværket med myndighederne statstilsyn og andre interesserede organisationer bestemmes i fællesskab af kunden af systemet og udvikleren af udkastet til tekniske specifikationer for NPP,

Arbejdet med at koordinere udkastet til tekniske specifikationer for AC udføres i fællesskab af udvikleren af de tekniske specifikationer for AC og systemets kunde, hver i organisationerne i sit ministerium (departement).

3. Perioden for godkendelse af udkastet til tekniske specifikationer for kernekraftværket i hver organisation bør ikke overstige 15 dage fra datoen for dets modtagelse. Det anbefales at sende kopier af udkastet til tekniske specifikationer for AS (kopier) samtidigt til alle organisationer (afdelinger) til godkendelse.

4. Bemærkninger til udkastet til tekniske specifikationer for kernekraftværket skal indsendes med en teknisk begrundelse. Beslutning om bemærkninger skal træffes af bygherren af udkastet til tekniske specifikationer for atomkraftværket og kunden af systemet inden godkendelse af de tekniske specifikationer for atomkraftværket.

5. Hvis der ved enighed om udkastet til tekniske specifikationer for et atomkraftværk opstår uoverensstemmelser mellem bygherren og kunden (eller andre interesserede organisationer), så udarbejdes en protokol over uenigheder (formen er vilkårlig) og specifik løsning accepteret til sin tid.

6. Godkendelse af udkastet til tekniske specifikationer for kernekraftværket er tilladt et særskilt dokument(ved brev). I dette tilfælde er der under overskriften "Aftalt" et link til dette dokument.

7. Godkendelsen af tekniske specifikationer for NPP udføres af lederne af virksomheder (organisationer) af udvikleren og kunden af systemet.

8. Inden den indsendes til godkendelse, skal den tekniske specifikation for NPP (tillæg til den tekniske specifikation) kontrolleres af myndighedskontroltjenesten i den organisation, der har udviklet den tekniske specifikation, og om nødvendigt underkastes metrologisk undersøgelse.

9. Kopi af de godkendte tekniske specifikationer for anlægget fremsendes af bygherren af de tekniske specifikationer for anlægget til deltagerne i systemoprettelsen inden 10 dage efter godkendelse.

10. Koordinering og godkendelse af tilføjelser til de tekniske specifikationer for atomkraftværket udføres på den måde, der er fastsat for de tekniske specifikationer for atomkraftværket.

11. Ændringer af de tekniske specifikationer for kernekraftværket må ikke godkendes, efter at systemet eller dets tur er indgivet til accepttest.

12. Registrering, regnskab og opbevaring af tekniske specifikationer på NPP og tilføjelser til det udføres i overensstemmelse med kravene i GOST 2.501.

FORM FOR TITELSIDEN AF TK PÅ AC

________________________________________________________

Navn
organisation - udvikler af tekniske specifikationer for kernekraftværket

JEG GODKENDT

Tilsynsførende
(stilling, navn på virksomheden - kunde i AS)

Personlig signatur
Fulde navn

Forsegle

dato

JEG GODKENDT

Tilsynsførende
(stilling, firmanavn - "AS-udvikler")

Personlig signatur
Fulde navn

Forsegle

dato

________________________________________________________

navnet på typen af højttaler

________________________________________________________

Objektnavn
automatisering

________________________________________________________

forkortet
talerens navn

TEKNISK OPGAVE

På ____ ark

Gyldig
Med

AFTALT

Tilsynsførende
(stilling, navn på den godkendende organisation)

Personlig signatur
Fulde navn

Forsegle

dato

FORM AF DET SIDSTE ARK AF TOREN PÅ AC

(TK-kode)

UDFØRT SOM AFTALT

BILAG 4
Information

BESTEMMELSER FOR OPRETTELSE AF ET ENLIGT SÆT AF AUTOMATISKE SYSTEMSTANDARDER

1. Indledende forudsætninger for at skabe komplekset

1.1. Oprettelse og implementering af automatiserede systemer af forskellige klasser og formål udføres i mange industrier i henhold til regulatorisk og teknisk dokumentation, der etablerer forskellige organisatoriske, metodiske og tekniske standarder, regler og forskrifter, der komplicerer integrationen af systemer og deres effektive fælles funktion.

1.2. I den periode, hvor USSR State Standard traf en beslutning om at forbedre inter-industrielle komplekser af standarder, var følgende komplekser og standardsystemer i kraft, der fastlagde krav til forskellige typer AC:

1) et samlet system af standarder for automatiserede kontrolsystemer (24. system), der dækker automatiserede kontrolsystemer, automatiserede kontrolsystemer, proceskontrolsystemer og andre organisatoriske og økonomiske systemer;
2) et sæt standarder (system 23501); udvidelse til computerstøttede designsystemer;
3) den fjerde gruppe af det 14. standardsystem, der dækker automatiserede systemer til teknologisk forberedelse af produktionen.

1.3. Praksisen med at anvende standarder for automatiserede kontrolsystemer, CAD, automatiserede proceskontrolsystemer, automatiserede proceskontrolsystemer har vist, at de bruger det samme konceptuelle apparat, der er mange fælles formål med standardisering, men kravene i standarderne er ikke i overensstemmelse med hver andet er der forskelle i værkets sammensætning og indhold, forskelle i betegnelse, sammensætning, indhold og udførelse af dokumenter mv.

1.4. På baggrund af fraværet af en samlet teknisk politik inden for oprettelse af AS, sikrede de mange forskellige standarder ikke bred kompatibilitet af AS under deres interaktion, tillod ikke systemer at blive replikeret og hæmmede udviklingen af lovende områder for brug af computerteknologi.

1.5. I øjeblikket foretages en overgang til oprettelse af komplekse automatiserede systemer (i udlandet, CAD - CAM-systemer), som omfatter automatiserede kontrolsystemer teknologiske processer og produktion, CAD - designer, CAD - teknolog, ASNI og andre systemer. Brugen af modstridende regler ved oprettelse af sådanne systemer fører til et fald i kvaliteten, en stigning i arbejdsomkostningerne og en forsinkelse i idriftsættelsen af atomkraftværker.

1.6. Et enkelt sæt standarder og vejledningsdokumenter bør gælde for automatiserede systemer til forskellige formål: ASNI, CAD, OASU, ASUP, ASUTP, ASUGPS, ASK, ASTPP, inklusive deres integration.

1.7. Ved udvikling af interindustrielle dokumenter bør følgende funktioner i AS som standardiseringsobjekter tages i betragtning:

1) den tekniske specifikation er hoveddokumentet, i overensstemmelse med hvilket oprettelsen af AS'et udføres og dets accept af kunden;
2) NPP'er er som regel skabt ved design, komplet med serie- og enkeltproduktionsprodukter og udfører konstruktions-, installations-, idriftsættelses- og idriftsættelsesarbejde, der er nødvendigt for at sætte kernekraftværket i drift;
3) i det generelle tilfælde består AS (AS-delsystemet) af software og hardware (PTK), software og metodiske komplekser (PMK) og komponenter af teknisk, software og informationssupport.
Komponenterne i disse understøtningstyper samt PMC og PTK skal fremstilles og leveres som produkter til industrielle og tekniske formål.
Komponenter kan indgå i AS'et som selvstændige dele eller kan kombineres til komplekser;
4) oprettelsen af AS i organisationer (virksomheder) kræver særlig uddannelse af brugere og systemvedligeholdelsespersonale;
5) funktionen af AS og komplekser er sikret af et sæt af organisatoriske og metodiske dokumenter, der under oprettelsesprocessen betragtes som komponenter af juridisk, metodisk, sproglig, matematisk, organisatorisk og andre former for støtte. Individuelle løsninger opnået i processen med at udvikle denne software kan implementeres i form af komponenter af hardware, software eller informationsstøtte;
6) fælles funktion og interaktion forskellige systemer og komplekser udføres på basis lokale netværk COMPUTER.

Specifikationer og aftaler vedtaget for lokale computernetværk er obligatoriske for at sikre kompatibilitet af systemer, komplekser og komponenter.

2. Indbyrdes sammenhæng mellem CEN AS og andre systemer og sæt standarder

2.1. Standardisering inden for højttalere er integreret del arbejder med det generaliserede problem "Informationsteknologi".

2.2. Et samlet sæt standarder for styrende dokumenter for automatiserede systemer bør sammen med andre systemer og sæt standarder udgøre en komplet regulatorisk og teknisk støtte til processerne for oprettelse og drift af automatiserede systemer.

2.3. CEN AU bør dække standardiseringsområder, der er specifikke for automatiserede systemer og udvide traditionelle standardiseringsområder til software og hardware, software og metodologiske komplekser og automatiserede systemer generelt.

2.4. Retningslinjerne og opgaverne med standardisering i den regulatoriske og tekniske støtte til processerne for oprettelse og drift af atomkraftværker er grupperet som følger:

1) etablering af tekniske krav til produkter;
2) regulering af testmetoder og regler for certificering og certificering af produkter;
3) regulering af regler og procedurer for udvikling;
4) etablering af dokumentationsregler;
5) sikring af kompatibilitet;
6) regulering af organisatoriske og metodiske spørgsmål om systemernes funktion.

Retninger 1-4 er traditionelle i udvikling, fremstilling og levering af produkter. Retningslinjerne 5, 6 er specifikke og stammer fra de egenskaber, der er iboende i AS.

2.5. Forsyningen af atomkraftværker som helhed og deres komponenter med regulatorisk og teknisk dokumentation inden for rammerne af accepterede retningslinjer og standardiseringsopgaver er anderledes.

Komponenter af hardware, software og informationssupport, som produkter til industrielle og tekniske formål, betragtes som henholdsvis design-, software- og informationsprodukter. Disse produkter er underlagt de nuværende sæt standarder ESKD, SRPP, ESPD, SGIP, USD, klassifikatorer og kodifikatorer af teknisk og økonomisk information, sæt standarder som "OTT", "Test Methods", "TU", samt kundens OTT.

2.5.1. Alle livscyklus designprodukter er fuldt forsynet med regulatorisk og teknisk dokumentation, der er gyldig inden for mekanik og instrumentfremstilling.

2.5.2. Softwareprodukter leveres med videnskabelig og teknisk dokumentation inkluderet i kundens ESPD og OTT. Omfanget af denne tekniske dokumentation bør dog udvides til at afspejle spørgsmål relateret til udvikling, oprettelse, distribution og drift af softwareprodukter.

2.5.3. Informationsprodukter er i øjeblikket ikke forsynet med videnskabelig og teknisk dokumentation, selv om visse spørgsmål er blevet udarbejdet inden for rammerne af USD, klassifikatorer og kodifikatorer af teknisk og økonomisk information.

2.6. Software-hardware og software-metodologiske komplekser betragtes som komplekse produkter, der ikke har nogen analoger inden for maskinteknik. I betragtning af PTC's og PMK's status som produkter til industrielle og tekniske formål, bør reglerne og proceduren for deres udvikling svare til kravene fastsat af standarderne for systemet til udvikling og produktion af produkter (SRPP).

Det unikke ved IP som et produkt til industrielle og tekniske formål, udtrykt i dets kompleksitet, i mangel af standarder for de fleste typer procedurer og arbejde, gør processen med deres planlægning og design meget kompleks og vanskelig. Når en virksomhed interagerer med en IS-udvikler til ethvert formål, kræves der to hoveddokumenter for at begynde arbejdet: en aftale og en teknisk specifikation (TOR). Udarbejdelse af tekniske specifikationer er en særskilt opgave. Den tekniske specifikation i sig selv er i virkeligheden et dokument, der afspejler alle kundens ønsker; det skal udarbejdes så detaljeret som muligt og angive alle detaljer og vision for resultatet. Kun på grundlag heraf vil det blive fastlagt, hvad udviklerne skal gøre, så kommissoriet bør udarbejdes så detaljeret som muligt.

Ved design af informationssystemer er de påkrævet Detaljeret beskrivelse. Til disse formål kan du bruge forskellige måder og metoder, men de fleste effektiv løsning er udvikling af tekniske specifikationer (TOR), som beskriver mål, målsætninger, grænseflade og andre krav til det objekt, der udvikles.

En teknisk specifikation er et dokument, der definerer de mål, krav og grundlæggende inputdata, der er nødvendige for udviklingen af en IS. Den tekniske specifikation for en IP er hoveddokumentet, der definerer kravene og proceduren for oprettelse, udvikling eller modernisering af en IP, i overensstemmelse med hvilken dens udvikling, idriftsættelse og accept udføres.

Succes med at implementere IP ligger i rigtigheden af den opgave, som kunden har sat. Jeg falder de nødvendige betingelser at skrive en god teknisk specifikation er afsluttet, så bliver resultatet fra forventet til gennemførligt.

af kunden selv;

af entreprenøren, men i dette tilfælde vil hans ansvar omfatte design og afprøvning;

konkurrerende kunstnere, hvis opgaver kun omfatter at skrive tekniske specifikationer;

af tredjeparts entreprenører.

For de tekniske specifikationer, der er skrevet af entreprenøren, er der en række lovgivningsmæssig dokumentation:

GOST 21.408-93 "Regler for implementering af arbejdsdokumentation til automatisering af teknologiske processer";

GOST 34.201-89 "Typer, fuldstændighed og betegnelse af dokumenter ved oprettelse af automatiserede systemer";

GOST 24.703-85 "Standard designløsninger i automatiserede kontrolsystemer. Grundlæggende bestemmelser";

GOST 34.003-90 "Automatiske systemer. Vilkår og definitioner";

GOST 34.601-90 "Automatiske systemer. Stadier af skabelse";

GOST 34.602-90 "Tekniske specifikationer til oprettelse af et automatiseret system";

GOST 19.201-78 Unified system of program documentation;

GOST 2.114-95 Unified system for designdokumentation.

Teknisk specifikation for en IS er en liste over grundlæggende operationelle, teknologiske, tekniske, organisatoriske, software-, informationslogiske og sproglige, økonomiske og andre krav, som IS skal opfylde på alle stadier af sin eksistens.

TK er tekstdokument, kompileret i enhver form. Det anbefales at indsende de nødvendige tegninger, diagrammer og store tabeller i form af bilag. Afhængigt af automatiseringsobjektets type, formål og specifikke egenskaber og systemets driftsbetingelser er det muligt at udarbejde sektioner af den tekniske specifikation i form af applikationer, indføre yderligere, udelukke eller kombinere dets underafsnit.

Der er ingen konkrete anbefalinger til, hvad den tekniske specifikation skal indeholde, hvilket betyder, at afsnit og underafsnit skal udvikles og placeres i den rækkefølge, entreprenøren har fastsat. Der er kun Generelle egenskaber afsnit og underafsnit. Udvikleren kan selvstændigt ændre, tilføje og redigere deres navn og antal.

Ark (side) numre placeres, startende fra det første ark efter titelbladet, øverst på arket (over teksten, i midten) efter angivelse af TK-koden på IP.

Kundens, udvikleren og godkendende virksomheders underskrifter placeres på titelbladet og forsegles. Om nødvendigt tegnes titelbladet på flere sider. Underskrifterne fra udviklerne af de tekniske specifikationer og embedsmænd, der er involveret i godkendelsen og behandlingen af udkastet til tekniske specifikationer for IP, er placeret på det sidste ark.

Titelsiden for tilføjelsen til de tekniske specifikationer er udformet på samme måde som titelsiden til de tekniske specifikationer. I stedet for navnet "Tekniske specifikationer" skriver de "Tilføjelse nr... til de tekniske specifikationer for AC..."

På efterfølgende ark med tilføjelsen til de tekniske specifikationer er grundlaget for ændringen, indholdet af ændringen og links til de dokumenter, som disse ændringer er foretaget i henhold til.

Når du præsenterer teksten til en tilføjelse til de tekniske specifikationer, bør du angive numrene på de tilsvarende afsnit, underafsnit, tabeller over de vigtigste tekniske specifikationer osv. og bruge ordene: "erstat", "suppler", "ekskluder", "stat i en ny udgave".

På indledende fase udvikling af tekniske specifikationer, laver udføreren en grov indholdsplan.

Generel information;

Formål og mål med at skabe systemet;

Karakteristika for automatiseringsobjektet;

Systemkrav;

Vilkår for brug;

Krav til programdokumentation;

Tekniske og økonomiske indikatorer;

Stadier og udviklingsstadier;

Kontrol- og acceptprocedure.

Disse afsnit kan opdeles i underafsnit. De tekniske specifikationer kan også omfatte applikationer, der er beskrevet i henhold til etablerede standarder. Entreprenøren kan tilføje eller slette efter behov nødvendige afsnit, skal alle disse faktorer diskuteres med kunden. Ved at overholde den fastlagte plan kan entreprenøren udvikle tekniske specifikationer effektivt og på kort tid.

Om nødvendigt opretter kunstneren en liste accepterede forkortelser og ordliste.

Kommissorium for IP-udvikling medicinsk institution opslået i bilag B.

For nylig henvendte de sig til mig for at rådgive mig om standarder for skrivning af tekniske specifikationer (TOR) til udvikling af automatiserede systemer (AS) og software (SW). Så jeg tror, nu vil jeg gå til Yandex, finde en passende artikel og sende den. Men det var der ikke! Jeg fandt ikke én artikel, der oplister standarder for tekniske specifikationer, herunder skabeloner og eksempler på færdige dokumenter. Du skal selv lave denne artikel...

Og så de vigtigste standarder, metoder og viden, der nævner TK eller SRS (Software (eller System) Requirements Specification):

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

GOST 34

GOST 34.602-89 Referencevilkårene for oprettelse af et automatiseret system regulerer strukturen af de tekniske specifikationer for oprettelse af SYSTEMET, som omfatter software, hardware, folk, der arbejder med softwaren, og automatiserede processer.

Ifølge GOST 34 skal den tekniske specifikation omfatte følgende sektioner:

Ved udvikling af tekniske specifikationer for offentlige projekter kræver kunder som regel overholdelse af denne særlige standard.

GOST 19

"GOST 19.xxx Unified System of Program Documentation (USPD)" er et sæt statsstandarder, der etablerer indbyrdes forbundne regler for udvikling, design og cirkulation af programmer (eller software) og programdokumentation. De der. Denne standard gælder specifikt for softwareudvikling.
I henhold til GOST 19.201-78 Tekniske specifikationer, krav til indhold og design skal de tekniske specifikationer omfatte følgende sektioner:

Naturligvis er GOST 34 (og 19) allerede forældede, og jeg kan ikke lide at bruge dem, men med den korrekte fortolkning af standarderne kan du få gode tekniske specifikationer, se konklusion.

IEEE STD 830-1998

En ret god definition af standard 830-1998 - IEEE Recommended Practice for Software Requirements Specifications er givet i selve beskrivelsen:

Beskriver indholdet og kvalitetsegenskaberne for en velskrevet softwarekravspecifikation (SRS) og giver flere SRS-skabeloner. Denne anbefalede praksis har til formål at fastlægge krav til software under udvikling, men kan også bruges til at hjælpe med udvælgelsen af proprietære og kommercielle softwareprodukter.

I henhold til standarden skal kommissoriet indeholde følgende afsnit:

1. Introduktion

1. Formål
2. Omfang
3. Definitioner, akronymer og forkortelser
4. Links
5. Kort oversigt

2. Generel beskrivelse

1. Produktinteraktioner (med andre produkter og komponenter)
2. Produktegenskaber (kort beskrivelse)
3. Brugeregenskaber
4. Begrænsninger
5. Antagelser og afhængigheder

3. Detaljerede krav (kan organiseres på forskellige måder, f.eks. på denne måde)

1. Krav til eksterne grænseflader
- 1. Brugergrænseflader
- 2. Hardware-grænseflader
- 3. Softwaregrænseflader
- 4. Grænseflader
2. Funktionelle krav
3. Ydelseskrav
4. Designbegrænsninger (og referencer til standarder)
5. Ikke-funktionelle krav (pålidelighed, tilgængelighed, sikkerhed osv.)
6. Andre krav

4. Ansøgninger
5. Alfabetisk indeks

Præsentation af Yuri Buluy Klassificering af softwarekrav og dets repræsentation i standarder og metoder.
Analyse af krav til automatiserede informationssystemer. Foredrag 11: Dokumentationskrav.
Regler for udarbejdelse af softwarekravspecifikation (læs sammen med kommentarer)
Eksempler på tekniske specifikationer og anden dokumentation til udvikling af AS for Ministeriet for Økonomisk Udvikling
GOST ledelsesstil. Gaperton artikel om korrekt arbejde med tekniske specifikationer i henhold til GOST
Business Analyst Dokument skabeloner fra

TEKNISK OPGAVE

til udvikling af et informationssystem

1. Generel information

4. Systemkrav

6. Procedure for kontrol og accept af systemet

1. Generel information

I overensstemmelse med aftale nr. MP23 mellem TechnoPlus LLC (herefter benævnt udvikleren) og OptoTorgovlya LLC (herefter benævnt kunden), designer Udvikleren databasen, udvikler og sætter "Regnskabs" informationssystemet i drift handelsaktiviteter»

Startdatoen for design af BDB anses for at være dagen efter underskrivelsen af denne tekniske specifikation

Hvis Kunden under udviklingsprocessen ændrer kravene beskrevet i dette dokument, udformes de i et særskilt dokument og medfører en ændring eller tilføjelse til Aftalen mellem Kunden og DB-udvikleren om fristen for gennemførelse og betaling af aftalen.

Kunden betaler for Databaseudviklerens arbejde i henhold til Aftale nr. XXX

2. Formål og mål for oprettelse (udvikling) af systemet

IS "Regnskab for Handelsoperationer" er designet til lagring, behandling og analyse af information relateret til Kundens hovedaktiviteter.

Formålet med at oprette IS "Regnskab for handelsoperationer" er:

Lagring af information om afsluttede handelsoperationer;

Refleksion af handelstransaktioner i regnskaber;

Analyse af økonomiske resultater af handelsoperationer;

Analyse af handelsaktiviteter fordelt på produktsortiment og modparter.

3. Karakteristika for automatiseringsobjekter

3.1. Kundens hovedaktivitet er handel med møbler og relaterede produkter ved bankoverførsel.

3.2. Kunden er ikke momspligtig

3.3. I løbet af dagen foretager Kunden ikke mere end 100 handelstransaktioner ved køb og salg af varer.

3.4. Produktsortimentets samlede volumen overstiger ikke 3000 enheder

3.5. Det samlede antal modparter - leverandører er ikke mere end 100 enheder.

3.6. Antallet af modparter – købere – er ikke begrænset. På tidspunktet for underskrivelsen af kontrakten var N XXX 300 enheder.

3.7. Kunden afskriver varer fra lageret efter metoden med vægtet gennemsnitlig kostpris.

3.9. Kun klasse 9 konti anvendes som udgiftskonti.

3.10. De økonomiske resultater af virksomhedens handelsaktivitet (driftens rentabilitet og rentabilitet) beregnes på grundlag af forskellen mellem sektor 702 og 902.

3.11. Handelstransaktioner registreres i de primære dokumenter Kvitteringsfaktura, Udgiftsfaktura, Kontoudtog.

Pributkovs faktura (PN) angiver det faktum, at varerne er ankommet til virksomhedens lager og inkluderer følgende oplysninger:

- nummer;

- dato;

– Navn på modparten (virksomhed - postejer);

– navnet på produktet;

- styrke;

– enhedspris på produktet;

- sumu.

Vidatkovs faktura (VN) repræsenterer det faktum, at varerne er blevet promoveret fra købers lager og indeholder oplysninger svarende til oplysningerne i PN (i stedet for leveringsfirmaet angives det indkøbende firma).

Bankudskriftsrække bekræfter kendsgerningen om modtagelse/vibration af midler fra rozrakhunku (r/r)-virksomheden og indeholder følgende oplysninger:

- dato;

– tegn på ankomst/betaling af midler;

– Navn på modparten (som blev fundet / hvem var overforsikret).

3.12. Hud primært dokument Det er en platform til at foretage regelmæssige transaktioner, der resulterer i ændringer i eksisterende regnskaber. Handelstransaktioner kræver følgende transaktioner (tabel 3.1)

Tabel 3.1 – Bogføringer anvendt i regnskabet hos Kundens virksomhed

Operation	Dokument	Konto debitering	Kontokredit	Overførselsbeløb
Udstationering	Købsfaktura			dokumentbeløb
Forsendelse af varer	Salgsfaktura			dokumentbeløb
				omkostninger for afsendte varer
Modtagelse af penge til foliokonto	Kontoudtog (kvittering)			dokumentbeløb
Overførsel af penge fra en foliokonto	Kontoudtog (udgifter)			dokumentbeløb
Fastlæggelse af økonomiske resultater				for beløbet for afslutning af 902 konti
				for beløbet for lukning af 702 konti

de 281 – varer på lager;

311 – rozrakhunkovy rakhunok i den onde valuta;

361 – detailforretninger med kurvekøb;

631 – rozrakhunki med postarbejdere;

702 – indtægter fra salg af varer;

902 – forenelighed af solgte varer (tilbagetrækninger).

3.13. Balancen for den syntetiske form ser ud som i tabel 3.2.

Tabel 3.2 – Omsætningsbalance for syntetiske produkter

Varenummer	Kolbe balance	Vend om	Kintseve balance







Sammen

4. Systemkrav

IS "Regnskab for handelsoperationer" skal opfylde følgende krav:

4.1. Databasen for IS'en "Accounting for Trade Operations" skal give lagring, visning og redigering af reference- og driftsoplysninger.

Referenceoplysninger:

o beskrivelse af varer:

Nomenklatur (produkt) nummer;

Produktnavn;

Beskrivelse;

o modparter – leverandører;

Modpartsnummer;

Entreprenørens navn;

Modpartsadresse;

Kontakter;

o modparter – købere;

Modpartsnummer;

Entreprenørens navn;

Modpartsadresse;

Kontakter;

o kontoplan, hvorpå der udføres regnskab for at registrere handelsoperationer og analysere økonomiske resultater;

o en liste over grundlæggende transaktioner til visning af handelstransaktioner i regnskabet forårsaget af primære dokumenter, som ser sådan ud som i tabel 3.1;

Operativ information:

o Primære dokumenter: Kvitteringsfaktura, udgiftsfaktura, kontoudtog (beskrivelse af dokumenter er givet i 3.11)

o Regnskabsposteringer forårsaget af primære dokumenter (typen af posteringer er vist i tabel 3.2)

o Oplysninger om varer på lager:

Varenummer;

Antal;

Sum;

Gennemsnitspris.

4.2. "Trade Operations Accounting" IS bør give dig mulighed for at automatisere følgende handlinger:

4.2.1 Afspejle fakta om modtagelse (modtagelse) og forsendelse af varer på lageret, nemlig genberegn mængden af varer på lageret og dets gennemsnitlige omkostninger.

4.2.2 Generer regnskabsposteringer automatisk baseret på primære dokumenter.

4.2.3 Søg efter følgende oplysninger:

Primære dokumenter af den angivne type for en vis periode;

Posteringer for en specificeret bilagstype for en bestemt dato;

Oplysninger om modparten

Produkt information

4.2.4 Udfør en analyse af handelsaktivitet for den angivne periode i følgende afsnit:

Økonomiske resultater af handelsaktiviteter;

Resultater af afviklinger for hver modpart;

Resterende varer på lageret for hver vare;

Omkostningerne ved transaktioner for hver modpart;

Omkostninger og antal salg for hver type produkt

4.2.5 Generer rapporter for den angivne periode:

Udstyret, som IC'en er installeret på, skal være udstyret med en uafbrydelig strømforsyning. I tilfælde af strømafbrydelse bør IS automatisk lukke ned uden tab af data.

IS skal have backup-mekanismer, og IS skal være udstyret med passende hardware og software:

Kvantitative værdier af pålidelighedsindikatorer:

- tid automatisk afslutning arbejde bør ikke tage mere end 1 minut;

- restitutionstid efter en fejl bør ikke være mere end 30 minutter;

- indeks fejltolerance IP'en skal være 11/7, dvs. uafbrudt drift ER 11 timer om dagen, 7 dage om ugen.

Vedligeholdelse af IS skal udføres uden at afbryde dens drift.

4.5 Krav til metoder til vurdering og overvågning af pålidelighedsindikatorer på prøvedriftsstadiet

For at overvåge pålidelighedsindikatorer på stadierne af prøvedrift af IS'en skal vedligeholdelsespersonalet føre en fejllog, som skal indeholde følgende informationstegn:

Datoen fejlen opstod;

Den samlede driftstid for objektet fra begyndelsen af dets drift, indtil fejlen blev opdaget;

Eksterne tegn og fejlens art;

Den type arbejde, hvor fejlen blev opdaget.

4.6 IC-ydelseskrav

Systemet skal understøtte muligheden for at behandle op til 1000 dokumenter pr

Systemet skal have følgende ydeevne:

80 % af operationerne skal have en responstid (operationsudførelsestid) på mindre end 1 sekund;

15 % af operationerne – fra 5 sekunder. op til 10 sek;

5 % af operationerne - mere end 10 sekunder, men ikke mere end 30 minutter.

4.7 Krav til volumener (skalerbarhed)

Systemet skal understøtte adgang til data i 10 år.

Den anslåede stigning i databasevolumen pr. dag i drift er 20 MB.

4.8 Krav til IS-personalets antal, funktioner og kvalifikationer og deres virkemåde

Arbejdet med IS vil blive udført af følgende kundepersonale:

Administrator:

Antal: 1;

Kvalifikation: netværksadministrator, database Administrator ;

Funktioner: systemsikkerhedsstyring, backup data ved begyndelsen af hver arbejdsdag, dataarkivering én gang om året;

Arbejdstid: 1 time om dagen, 5 dage om ugen

Operatøren (brugeren), der registrerer en handelsoperation og analyserer resultaterne af handelsaktiviteter:

Antal: 2;

Kvalifikation: revisor, pc-bruger;

Funktioner: input af primære dokumenter, vedligeholdelse nuværende tilstand lagerinformation, generering af regnskabsposteringer, analyse af handelsresultater, sikkerhedskopiering af data ved begyndelsen af arbejdsdagen, der falder på lørdag og søndag.

Arbejdstid: på skift for at sikre systemdrift 11 timer om dagen, 7 dage om ugen;

Adgang til arbejde: 8-timers træningskursus;

Før IS tages i drift, skal personalet gennemføre et 8-timers træningskursus for at få tilladelse til at arbejde. Efter endt kursus udføres test, hvorunder opløsningens rigtighed og hastighed vurderes praktiske problemer, samt kendskab til job og tekniske instruktioner.

Systemet bør kun give adgang til dets funktioner til registrerede IS-brugere ved at angive en adgangskode.

4.10 Krav til software og sammensætning, struktur og metoder til organisering af IS-databasen

Data i systemet skal gemmes i relationel DBMS FRK SQL Server 2000.

- T-SQL (SQL sprog dialekt);

MED #.

Softwaren består af generel systemsoftware købt for Kundens regning (købt software), og speciel software udviklet som led i arbejdet med at oprette IP'en.

Følgende software skal bruges som systemdækkende software:

Operativ system;

Databasestyringssystem MS SQL Server 2000;

Backup software;

4.11 Hardwarekrav

Databaseserver, 2 arbejdsstationer.

Netværksgennemstrømningen er 100 Mbit per sekund.

4.12 Krav til udviklingsmuligheder og IS-modernisering

Det skal være muligt at modernisere og udvikle IS uden at involvere udvikleren af IS-administratoren på niveau med:

- tilføjelser, ændringer, sletninger referenceoplysninger IP;

- tilslutning/fjernelse af nye IS-brugere;

- ændringer af adgangskode;

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

Det bør være muligt at modernisere og udvikle IS med begrænset deltagelse af udvikleren (telefonkonsultationer) på niveau med modernisering af gamle rapporter og oprettelse af nye rapporter. Muligheden og betingelserne for telefonrådgivning fra udvikleren om IS-modernisering forhandles separat ved underskrivelse af en ny aftale.

5. Sammensætning og indhold af arbejdet med at skabe systemet

Arbejdet med udformningen af IS "Regnskab for handelsoperationer" udføres i tre faser.

Den første fase omfatter:

Kontrol af muligheden for at indhente alle de oplysninger, kunden anmoder om baseret på de oprindelige data;

IS database design;

Udfyldning af den udviklede database test sæt data;

Udvikling af brugergrænsefladedesign;

Udvikling af en lav-niveau teknisk specifikation for udviklingen af IS "Regnskab for handelsoperationer"

Slutningen af den første fase bekræftes af underskrivelsen af det interne certifikat for afsluttet arbejde og godkendelsen af den tekniske specifikation på lavt niveau for udviklingen af IP.

Anden fase er udviklingen af en testversion af IS "Accounting for Trade Operations". Slutning denne fase er at sætte testversionen i prøvedrift.

Tredje trin er prøvedriften af IS "Regnskab for handelsoperationer", som omfatter eliminering af identificerede fejl, mangler og uoverensstemmelser med denne tekniske specifikation. Slutningen af anden fase er indførelsen af IS i kommerciel drift.

Gennemførelsen af hver anden og tredje fase bekræftes af aftaleparterne ved at underskrive overførsels- og acceptcertifikatet.

Varigheden af den første fase er 10 dage. Begyndelsen af den første fase anses for at være dagen efter den dag, hvor kunden og DB-udvikleren underskrev denne tekniske specifikation.

Varigheden af anden fase er 20 dage. Begyndelsen af anden fase anses for at være dagen efter dagen for godkendelsen af den lave tekniske specifikation for udvikling af IP.

Varigheden af den tredje fase er 20 dage. Begyndelsen af tredje fase anses for at være dagen efter den dag, hvor kunden og DB-udvikleren underskrev acceptcertifikatet for testversionen af IS til prøvedrift.

Datasættet til test af IS leveres af kunden.

Ved afslutningen af anden fase af arbejdet installerer DB-udvikleren en test-IS på kundens testserver og giver kunden en foreløbig brugermanual, der indeholder en beskrivelse af de procedurer, der er nødvendige for at arbejde med "Trade Accounting"-IS. Beskrivelser findes i i elektronisk format.

Ved afslutningen af tredje fase af arbejdet giver DB-udvikleren kunden et program til installation af databasen på serveren, samt bruger- og programmørinstruktioner og instruktioner til installation af IS med beskrivelser af de procedurer, der er nødvendige for at arbejde med ER "Regnskab for handelsoperationer".

6. Procedure for kontrol og accept af systemet

Ved afslutningen af den første fase underskrives et internt certifikat for udført arbejde, og arbejdet på lavt niveau godkendes datablad til IP-udvikling.

Ved afslutningen af andet og tredje designtrin installerer udvikleren IS hos kunden, demonstrerer driften af IS i overensstemmelse med kravene i denne tekniske specifikation og underskriver overførsels- og acceptcertifikatet.

7. Krav til sammensætning og indhold af arbejdet med at klargøre automatiseringsobjektet til idriftsættelse af systemet

På dagen for prøvedriftens start er Kunden forpligtet til at give Udvikleren den nødvendige adgang til den server, hvorpå testversionen af "Trade Operations Accounting" IS vil blive implementeret.

Manglen på en server til installation af IS "Accounting for Trade Operations"-databasen kan ikke være grundlag for at nægte at underskrive acceptbeviset for IS "Accounting for Trade Operations" til prøvedrift eller kommerciel drift.

I slutningen af anden fase af udviklingen af IS "Regnskab for handelsoperationer" gennemfører udvikleren et 8-timers træningskursus med kundens personale om IS-vedligeholdelse. Ved afslutningen dette kursus Kundens personale testes.

8. Dokumentationskrav

I slutningen af den tredje fase overfører udvikleren af IS'en "Accounting for Trade Operations" følgende dokumentation til kunden:

1. Programmeringsinstruktioner.

Programmørens instruktioner beskriver de procedurer, der er nødvendige for at arbejde med "Trade Operations Accounting" IS. Beskrivelse af procedurer omfatter:

Navn på proceduren;

Beskrivelse af de handlinger, der udføres af proceduren;

Beskrivelse input parametre, der angiver typen af parameter, dets optagelsesformat og standardværdien, hvis der er defineret en for parameteren;

Beskrivelse af outputparametre og (eller) retursæt af poster, med angivelse af deres typer og formater

Et eksempel på et procedurekald og de værdier, det returnerer. Hvis en procedure kan have flere kaldemuligheder, så eksempler for hver mulighed.

2. Instruktioner til installation af IS'en "Regnskab for handelsoperationer".

3. Instruktioner til brugeren af IS "Regnskab for handelsoperationer".

Ingen anden dokumentation leveres til kunden. Instruktioner leveres i både trykt og elektronisk format. Trykte instruktioner leveres i ét eksemplar.