Vad betyder tz? Så vad är en "teknisk specifikation"? Allmän information om projektet

Jag får ofta frågan: "Hur man utvecklas på rätt sätt mandat För automatiserat system?. Ämnet att utveckla tekniska specifikationer diskuteras ständigt i olika forum. Denna fråga är så bred att det är omöjligt att besvara i ett nötskal. Därför bestämde jag mig för att skriva en lång artikel om detta ämne. Under arbetet med artikeln insåg jag att det inte skulle gå att lägga allt i en artikel, eftersom... Den kommer att vara cirka 50 sidor och jag bestämde mig för att dela upp den i två delar:

I första delen" Utveckling av tekniska specifikationer. Vad är det, varför behövs det, var ska man börja och hur det ska se ut? Jag kommer att försöka besvara frågorna om ämnet i detalj, överväga strukturen och syftet med referensvillkoren och ge några rekommendationer om utformningen av krav.
Andra delen" Utveckling av tekniska specifikationer. Hur man formulerar krav? kommer helt att ägnas åt att identifiera och formulera krav på ett informationssystem.

Först måste du ta reda på vilken fråga som faktiskt intresserar dem som frågar "Hur utvecklar man en teknisk specifikation?" Faktum är att tillvägagångssättet för att utveckla de tekniska specifikationerna i hög grad kommer att bero på de syften för vilka det görs, såväl som av vem det kommer att användas. Vilka alternativ pratar jag om:

En kommersiell organisation beslutade att implementera ett automatiserat system. Den har ingen egen IT-tjänst och beslutade att göra detta: Den intresserade parten måste utveckla en teknisk specifikation och lämna in den för utveckling till en tredje part;
En kommersiell organisation beslutade att implementera ett automatiserat system. Den har en egen IT-tjänst. Vi bestämde oss för att göra detta: utveckla en teknisk specifikation, sedan komma överens om den mellan IT-tjänsten och berörda parter och implementera den på egen hand;
Myndigheten beslutade att starta ett IT-projekt. Allt här är så grumligt, många formaliteter, bakslag, nedskärningar, etc. Jag kommer inte att överväga det här alternativet i den här artikeln.
Ett IT-företag tillhandahåller tjänster för utveckling och/eller implementering av automatiserade system. Detta är det mesta svårt fall, eftersom du måste arbeta under en mängd olika förhållanden:
Kunden har sina egna specialister med sina egna åsikter och de ställer specifika krav på de Tekniska specifikationerna;
- Referensvillkoren är utvecklade för interna utvecklare (kunden bryr sig inte);
- Referensvillkoren är utvecklade för överföring till entreprenören (dvs. en grupp programmerare i företagets personal eller en enskild specialist);
- Ett missförstånd uppstår mellan företaget och kunden angående det erhållna resultatet, och företaget ställer gång på gång frågan: "Hur ska de tekniska specifikationerna utvecklas?" Kanske, sista fallet Det verkar som en paradox, men det är sant.
- Andra, mindre vanliga alternativ är också möjliga;

Jag tycker att läsaren nu borde ha frågor:

Varför kan de tekniska specifikationerna inte alltid utvecklas på samma sätt?;
Finns det några standarder, metoder, rekommendationer? Var kan jag få tag i dem?
Vem ska utveckla villkoren? Ska denna person ha någon speciell kunskap?
Hur förstår man om villkoren är välskrivna eller inte?
På vems bekostnad ska det utvecklas, och är det ens nödvändigt?

Den här listan kan vara oändlig. Jag säger detta med tillförsikt eftersom jag har arbetat med professionell mjukvaruutveckling i 15 år, och frågan om tekniska specifikationer kommer upp i alla utvecklingsteam som jag arbetar med. Orsakerna till detta är olika. När jag tar upp ämnet för att utveckla villkoren är jag väl medveten om att jag inte kommer att kunna presentera det till 100 % för alla som är intresserade av ämnet. Men jag ska försöka, som de säger, "att reda ut allting." De som redan är bekanta med mina artiklar vet att jag inte använder "copy-paste" av andras arbete, inte trycker om andras böcker, citerar inte flersidiga standarder och andra dokument som du själv kan hitta på Internet, framställer dem som dina egna geniala tankar. Skriv bara in en sökmotor "Hur man utvecklar en teknisk specifikation" så kan du läsa mycket intressant, men tyvärr upprepande saker. Som regel har de som gillar att vara smarta på forum (bara försök att söka!) aldrig gjort en ordentlig teknisk specifikation själva, och citerar ständigt GOST-rekommendationer i denna fråga. Och de som är riktigt seriösa i frågan har oftast inte tid att sitta på forumen. Förresten kommer vi också att prata om GOST-standarder. Under åren av mitt arbete har jag sett många alternativ teknisk dokumentation, sammanställd av både enskilda specialister och välrenommerade team och konsultföretag. Ibland ägnar jag mig också åt sådana aktiviteter: jag avsätter tid åt mig själv och söker information om ett ämne av intresse från ovanliga källor (som lite intelligens). Som ett resultat var jag tvungen att se dokumentation om sådana monster som GazProm, Russian Railways och många andra intressanta företag. Naturligtvis följer jag sekretesspolicyn, trots att dessa dokument kommer till mig från allmänt tillgängliga källor eller konsulters ansvarslöshet (spridning av information på Internet). Så jag säger direkt: konfidentiell information, som tillhör andra företag delar jag inte, oavsett ursprungskällor (yrkesetik).

Vad är en teknisk specifikation?

Det första vi ska göra nu är att ta reda på vilken sorts best denna "tekniska specifikation" är.

Ja, det finns verkligen GOSTs och standarder som försöker reglera denna del av verksamheten (mjukvaruutveckling). En gång i tiden var alla dessa GOST relevanta och användes aktivt. Nu finns det olika åsikter om relevansen av dessa dokument. Vissa hävdar att GOSTs utvecklades av mycket framsynta människor och fortfarande är relevanta. Andra säger att de är hopplöst föråldrade. Kanske trodde någon nu att sanningen låg någonstans i mitten. Jag skulle svara med Goethes ord: ”De säger att mellan två motsatta åsikter ligger sanningen. Inget sätt! Det finns ett problem mellan dem." Så det finns ingen sanning mellan dessa åsikter. Eftersom GOST inte avslöjar de praktiska problemen med modern utveckling, och de som kritiserar dem erbjuder inte alternativ (specifika och systemiska).

Observera att GOST uppenbarligen inte ens ger en definition, det står bara: "TK för ett kärnkraftverk är huvuddokumentet som definierar kraven och förfarandet för att skapa (utveckling eller modernisering - sedan skapande) av ett automatiserat system, i enlighet med vilken utvecklingen av ett kärnkraftverk genomförs och dess acceptans vid idrifttagandet till handling."

Om någon är intresserad av vilka GOSTs jag pratar om, här är de:

GOST 2,114-95 Enat system designdokumentation. Tekniska specifikationer;
GOST 19.201-78 Unified system för programdokumentation. Tekniska specifikationer. Krav på innehåll och design;
GOST 34.602-89 Informationsteknik. En uppsättning standarder för automatiserade system. Referensvillkor för skapandet av ett automatiserat system.

En mycket bättre definition presenteras på Wikipedia (dock om tekniska specifikationer i allmänhet, och inte bara för programvara): " Mandat- Det här originaldokument för design teknisk objekt. Mandat fastställer huvudsyftet med objektet som utvecklas, dess tekniska och taktiska tekniska specifikationer, kvalitetsindikatorer och tekniska och ekonomiska krav, instruktioner för att utföra de nödvändiga stegen för att skapa dokumentation (design, teknologi, mjukvara, etc.) och dess sammansättning, såväl som speciella krav. En uppgift som ett initialt dokument för att skapa något nytt finns inom alla verksamhetsområden, skiljer sig åt i namn, innehåll, utförandeordning etc. (exempelvis en designuppgift inom byggnation, en stridsuppgift, läxor, ett kontrakt för ett litterärt verk etc.).

Och så, som följer av definitionen, är huvudsyftet med den tekniska specifikationen att formulera kraven för objektet som utvecklas, i vårt fall, för ett automatiserat system.

Det är huvudsaken, men den enda. Det är dags att komma ner till det viktigaste: att lägga allt "på hyllorna", som utlovat.

Vad behöver du veta om kraven? Det är nödvändigt att tydligt förstå att alla krav måste delas in efter typ och egenskaper. Nu ska vi lära oss hur man gör detta. För att separera krav efter typ, hjälper GOST oss. Listan över typer av krav som presenteras där finns bra exempel vilka typer av krav som bör beaktas. Till exempel:

Funktionalitetskrav;
Krav på säkerhet och åtkomsträttigheter;
Krav på personalkvalifikationer;
…. Etc. Du kan läsa om dem i nämnda GOST (och nedan ska jag även titta på dem lite mer detaljerat).

Jag tror att det är uppenbart för dig att nyckelfaktorn för en framgångsrik teknisk specifikation är just välformulerade funktionalitetskrav. De flesta av de verk och metoder som jag talade om är ägnade åt dessa krav. Funktionalitetskraven är 90 % av komplexiteten i arbetet med att ta fram uppdragsbeskrivningen. Allt annat är ofta ett "kamouflage" som täcker dessa krav. Om kraven är dåligt formulerade, oavsett vilket vackert kamouflage du sätter på dem, kommer ett framgångsrikt projekt inte att komma ut. Ja, formellt kommer alla krav att uppfyllas (enligt GOST J), den tekniska specifikationen är utvecklad, godkänd och undertecknad och pengar har erhållits för det. Och vad? Och sedan börjar den mest intressanta delen: vad ska man göra? Om detta är ett projekt på statsordern, finns det inga problem - budgeten där är sådan att den inte passar i någons ficka, och under genomförandeprocessen (om det finns en) kommer allt att klargöras. Det är precis så majoriteten av projektbudgetarna spenderas på statliga order (de klottrade "TZ", förlorade tiotals miljoner, men gjorde inte projektet. Alla formaliteter iakttogs, det fanns inga skyldiga, en ny bil är nära huset . Skönhet!). Men vi pratar om kommersiella organisationer, där pengar räknas, och ett annat resultat behövs. Låt oss därför förstå det viktigaste, hur man utvecklas användbara och fungerande Tekniska specifikationer.

Jag sa om typerna av krav, men hur är det med fastigheter? Om typerna av krav kan vara olika (beroende på projektets mål), är allt enklare med egenskaper, det finns 3 av dem:

Kravet måste vara begriplig;
Kravet måste vara specifik;
Kravet måste vara testtagare;

Dessutom är den sista egenskapen omöjlig utan de två föregående, d.v.s. är ett slags "lackmustest". Om resultatet av ett krav inte kan prövas betyder det att det antingen är oklart eller inte specifikt. Tänk på det. Det är i behärskning av dessa tre kravegenskaper som behärskning och professionalism ligger. Det är faktiskt väldigt enkelt. När du kommer på det.

Detta avslutar historien om vad en teknisk specifikation är och går vidare till det viktigaste: hur man formulerar krav. Men det är inte så snabbt. Det finns ytterligare en extremt viktig punkt:

På vilket språk (i fråga om svårighetsförståelse) ska den tekniska specifikationen skrivas?
Ska den beskriva specifikationerna för olika funktioner, algoritmer, datatyper och andra tekniska saker?
Vad är teknisk design, som förresten också nämns i GOSTs, och hur är det relaterat till de tekniska specifikationerna?

Det finns en mycket lömsk sak gömd i svaren på dessa frågor. Det är därför det ofta uppstår tvister om tillräckligheten eller bristen på nödvändiga detaljer i kraven, om kundens och entreprenörernas förståelighet av dokumentet, om redundans, presentationsformat etc. Var går gränsen mellan villkoren och det tekniska projektet?

Mandat- detta är ett dokument baserat på krav formulerade på ett språk som är förståeligt (vanligt, bekant) för kunden. I detta fall kan och bör branschterminologi som är förståelig för kunden användas. Det bör inte finnas några kopplingar till detaljerna i den tekniska implementeringen. Dessa. på det tekniska specifikationsstadiet spelar det i princip ingen roll på vilken plattform dessa krav kommer att implementeras. Även om det finns undantag. Om vi pratar om att implementera ett system baserat på ett befintligt mjukvaruprodukt, då kan en sådan länk ske, men endast på nivå med skärmformulär, rapportformulär etc. Förtydligande och formulering av krav, samt utveckling av uppdragsbeskrivning bör genomföras affärsanalytiker. Och absolut inte en programmerare (såvida han inte kombinerar dessa roller händer detta). Dessa. denna person måste tala med kunden på språket för hans verksamhet.

Tekniskt projekt- detta är ett dokument som är avsett för den tekniska implementeringen av kraven formulerade i villkoren. Detta dokument beskriver datastrukturer, triggers och lagrade procedurer, algoritmer och andra saker som kommer att krävas tekniska specialister . Kunden behöver inte fördjupa sig i detta alls (även sådana villkor kanske inte är tydliga för honom). Det gör det tekniska projektet Systemarkitekt(att kombinera denna roll med en programmerare är ganska normalt). Eller snarare, en grupp JSC-specialister ledda av en arkitekt. Ju större projekt, desto fler arbetar med uppdragsbeskrivningen.

Vad har vi i praktiken? Det är roligt att se när regissören får en teknisk specifikation för godkännande, som är fylld av teknisk terminologi, beskrivningar av datatyper och deras värden, databasstruktur etc. Han försöker förstås förstå, eftersom han behöver godkänna , försöker hitta bekanta ord mellan raderna och inte förlora kedjans affärskrav. Är detta en bekant situation? Och hur slutar det? Som regel godkänns sådana tekniska specifikationer, implementeras sedan, och i 80% av fallen motsvarar de inte alls faktumet av det utförda arbetet, eftersom de bestämde sig för att ändra, göra om en massa saker, missförstås, trodde fel osv. etc. Och så börjar serien om att skicka in arbeten. "Men här är det inte vad vi behöver", utan "det här kommer inte att fungera för oss", "det här är för komplicerat", "det här är obekvämt" etc. Låter det bekant?!! Det är bekant för mig, jag var tvungen att träffa gupp i sinom tid.

Så vad har vi i praktiken? Men i praktiken har vi en suddig gräns mellan uppdragsbeskrivningen och det tekniska projektet. Hon svävar mellan TK och TP i en mängd olika manifestationer. Och det är dåligt. Detta sker för att utvecklingskulturen har blivit svag. Detta beror dels på specialisternas kompetens, dels på viljan att minska budgetar och deadlines (trots allt tar dokumentation mycket tid - det är ett faktum). Det finns en annan viktig faktor som påverkar användningen av den tekniska designen som ett separat dokument: den snabba utvecklingen av verktyg för snabb utveckling, såväl som utvecklingsmetoder. Men det här är en separat historia, jag ska säga några ord om det nedan.

En annan liten men viktig punkt. Ibland kallas villkoren för en liten del av krav, enkel och begriplig. Till exempel, förbättra sökningen efter ett objekt baserat på vissa villkor, lägg till en kolumn i rapporten, etc. Detta tillvägagångssätt är ganska motiverat, varför komplicera livet. Men det används inte på stora projekt, utan på mindre förbättringar. Jag skulle säga att detta är närmare underhåll av mjukvaruprodukt. I detta fall kan uppdragsbeskrivningen även beskriva en specifik teknisk lösning för att implementera kravet. Till exempel, "Gör en sådan och en sådan förändring av en sådan och en sådan algoritm", vilket indikerar en specifik procedur och en specifik förändring för programmeraren. Detta är fallet när gränsen mellan villkoren och tekniska projekt är helt utraderad, eftersom det finns ingen ekonomisk möjlighet att blåsa upp pappersarbete där det inte behövs, och användbart dokument skapas. Och det stämmer.

Är teknisk specifikation överhuvudtaget nödvändig? Hur är det med det tekniska projektet?

Överhettas jag? Är detta möjligt utan någon Tekniska specifikationer? Föreställ dig att det är möjligt (eller snarare, det är möjligt), och detta tillvägagångssätt har många anhängare, och deras antal växer. Som regel efter att unga specialister har läst böcker om Scrum, Agile och andra snabba utvecklingsteknologier. Faktum är att det här är underbara tekniker, och de fungerar, men de säger inte bokstavligen "du behöver inte göra tekniska uppgifter." De säger "ett minimum av pappersarbete", särskilt onödiga sådana, närmare kunden, mer specifika och snabbare resultat. Men ingen avbröt kravregistreringen och det står tydligt där. Det är där som kraven är fixerade utifrån de tre anmärkningsvärda egenskaperna som jag nämnde ovan. Det är bara det att vissa människors sinnen är strukturerade på ett sådant sätt att om något kan förenklas, låt oss förenkla det till en punkt av fullständig frånvaro. Som Einstein sa " Gör det så enkelt som möjligt, men inte enklare än så." . Det är gyllene ord som hör till allt. Så Mandat nödvändigt, annars kommer du inte att se ett framgångsrikt projekt. En annan fråga är hur man komponerar den och vad som ska ingå där. I ljuset av snabba utvecklingsmetoder behöver du bara fokusera på kraven, och allt "kamouflage" kan kasseras. I princip håller jag med om detta.

Hur är det med det tekniska projektet? Detta dokument är mycket användbart och har inte förlorat sin relevans. Dessutom kan du ofta helt enkelt inte klara dig utan den. Särskilt när det gäller att lägga ut utvecklingsarbete på entreprenad, d.v.s. på principen om outsourcing. Om du inte gör detta riskerar du att lära dig mycket om hur systemet du tänkt dig ska se ut. Ska Kunden bekanta sig med det? Om han vill, varför inte, men det finns ingen anledning att insistera och godkänna detta dokument, det kommer bara att hålla tillbaka och störa arbetet. Det är nästan omöjligt att designa ett system in i minsta detalj. I det här fallet måste du kontinuerligt göra ändringar i den tekniska designen, vilket tar mycket tid. Och om organisationen är kraftigt byråkratisk, kommer du att lämna alla dina nerver där. Att minska denna typ av design är precis vad moderna snabbutvecklingsmetoder som jag nämnde ovan handlar om. Förresten är de alla baserade på den klassiska XP (extrem programmering) – ett tillvägagångssätt som redan är cirka 20 år gammalt. Så gör en högkvalitativ teknisk specifikation som är förståelig för kunden, och använd den tekniska designen som internt dokument, för förhållandet mellan systemarkitekten och programmerare.

Intressant detalj om teknisk design: vissa utvecklingsverktyg utformade enligt den ämnesorienterade principen (som 1C och liknande) antar att design (vilket betyder dokumentationsprocessen) endast krävs i verkligt komplexa områden där interaktion mellan hela delsystem krävs. I det enklaste fallet, till exempel att skapa en katalog eller ett dokument, räcker det med endast korrekt formulerade affärskrav. Detta bevisas också av affärsstrategin för denna plattform när det gäller utbildning av specialister. Om man tittar på tentamen specialist (det är vad han kallas, inte en "programmerare"), då kommer du att se att det bara finns affärskrav, och hur man implementerar dem på ett programspråk är specialistens uppgift. Dessa. den del av problemet som det tekniska projektet är avsett att lösa måste specialisten lösa "i huvudet" (vi pratar om uppgifter av medelhög komplexitet), här och nu, efter vissa utvecklings- och designstandarder, som återigen bildas av 1C-företaget för sin plattform. Av två specialister vars arbetsresultat ser identiska ut kan alltså den ena klara provet, men den andra kan inte, eftersom uppenbart brutit mot utvecklingsstandarder. Det vill säga att det självklart förutsätts att specialister ska ha sådana kvalifikationer att de kan utforma typiska uppgifter självständigt, utan inblandning av systemarkitekter. Och detta tillvägagångssätt fungerar.

Låt oss fortsätta att studera frågan: "Vilka krav bör inkluderas i referensvillkoren?"

Formulering av krav på informationssystemet. Uppförandevillkorens struktur

Låt oss vara tydliga direkt: vi kommer att prata specifikt om att formulera krav på ett informationssystem, dvs. förutsatt att arbetet med att utveckla affärskrav, formalisering av affärsprocesser och allt tidigare konsultarbete redan är avslutat. Visst kan vissa förtydliganden göras i detta skede, men bara förtydliganden. Automationsprojektet i sig löser inte affärsproblem – kom ihåg detta. Detta är ett axiom. Av någon anledning försöker vissa chefer motbevisa det och tror att om de köper programmet kommer ordning att komma till en kaotisk verksamhet. Men ett axiom är ett axiom eftersom det inte kräver bevis.

Liksom alla aktiviteter kan (och bör) formulera krav delas in i steg. Allt har sin tid. Detta är hårt intellektuellt arbete. Och om du behandlar det med otillräcklig uppmärksamhet, kommer resultatet att vara lämpligt. Av expertbedömningar, kostnaden för att utveckla villkoren kan vara 30-50%. Jag är av samma åsikt. Fast 50 är kanske för mycket. Den tekniska specifikationen är trots allt inte det sista dokumentet som måste utvecklas. Det måste ju också finnas teknisk design. Denna variation beror på olika automationsplattformar, tillvägagångssätt och tekniker som används av projektteam under utveckling. Till exempel, om vi pratar om utveckling i ett klassiskt språk som C++, då är detaljerad teknisk design oumbärlig. Om vi pratar om att implementera ett system på 1C-plattformen, är situationen med design något annorlunda, som vi såg ovan (även om, när man utvecklar ett system från grunden, är det designat enligt det klassiska schemat).

Även om kravförklaringen är huvuddelen Tekniska specifikationer, och i vissa fall blir det den enda delen av de tekniska specifikationerna, bör du vara uppmärksam på att detta är ett viktigt dokument, och det bör upprättas i enlighet med detta. Var ska man börja? Först och främst måste du börja med innehållet. Skriv innehållet och börja sedan utöka det. Personligen gör jag så här: först skissar jag på innehållet, beskriver målen, all inledande information och kommer sedan ner till huvuddelen – formuleringen av kraven. Varför inte tvärtom? Jag vet inte, det är bekvämare för mig. För det första är detta en mycket mindre del av tiden (jämfört med kraven), och för det andra, medan du beskriver all inledande information, stämmer du in på huvudsaken. Tja, den som gillar det. Med tiden kommer du att utveckla din egen tekniska specifikationsmall. Till att börja med rekommenderar jag att ta som innehåll exakt det som beskrivs i GOST. Det är perfekt för innehåll! Sedan tar vi och börjar beskriva varje avsnitt, inte att glömma rekommendationerna för följande tre egenskaper: förståelighet, specificitet och testbarhet. Varför insisterar jag på detta så mycket? Mer om detta i nästa avsnitt. Och nu föreslår jag att gå igenom punkterna i de tekniska specifikationerna som rekommenderas i GOST.

allmän information;
syfte och mål för skapandet (utveckling) av systemet;
egenskaper hos automationsobjekt;
systemkrav;
sammansättning och innehåll i arbetet för att skapa systemet;
förfarande för kontroll och godkännande av systemet;
krav på sammansättning och innehåll av arbetet för att förbereda automationsobjektet för att sätta systemet i drift;
dokumentationskrav;
utvecklingskällor.

Totalt 9 sektioner som var och en också är indelad i underavdelningar. Låt oss titta på dem i ordning. För enkelhetens skull kommer jag att presentera allt i form av en tabell för varje objekt.

Avsnitt 1. allmän information.

Rekommendationer enligt GOST
fullständigt namn på systemet och dess symbol;	Allt är klart här: vi skriver vad systemet kommer att heta, dess korta namn
ämneskod eller kod (nummer) för kontraktet;	Detta är inte relevant, men du kan specificera det vid behov
namnet på företagen (föreningarna) för utvecklaren och kunden (användaren) av systemet och deras uppgifter;	ange vilka (vilka organisationer) som ska arbeta med projektet. Du kan också ange deras roller. Du kan till och med ta bort det här avsnittet (ganska formellt).
en lista över dokument på grundval av vilka systemet skapas, av vem och när dessa dokument godkändes;	Användbar information. Här bör du ange den regulatoriska och referensdokumentation som du fått för att bekanta dig med en viss del av kraven
planerade start- och slutdatum för arbetet med att skapa systemet;	Begäran om timing. Ibland skriver de om detta i de tekniska specifikationerna, men oftare beskrivs sådant i arbetskontrakt
information om källorna och förfarandet för finansiering av arbetet;	Samma som i föregående stycke om deadlines. Mer relevant för statliga order (för statligt anställda)
förfarandet för registrering och presentation för kunden av resultaten av arbetet med att skapa systemet (dess delar), om produktion och justering av individuella medel (hårdvara, programvara, information) och mjukvara och hårdvara (mjukvara och metodiska) komplex av system.	Jag ser inte behovet av denna punkt, eftersom... dokumentationskrav utfärdas separat, och dessutom finns en helhet separat sektion"Procedur för kontroll och acceptans" av systemet.

Avsnitt 2. syfte och mål för skapandet (utveckling) av systemet.

Rekommendationer enligt GOST	Vad ska man göra åt det i praktiken
Syftet med systemet	Å ena sidan är syftet enkelt. Men det är lämpligt att formulera det specifikt. Om du skriver något i stil med "högkvalitativ automatisering av lagerbokföring i företag X", så kan du diskutera resultatet länge efter det att det är klart, även oavsett hur bra kraven är formulerade. Därför att Kunden kan alltid säga att han med kvalitet menade något annat. I allmänhet kan man förstöra varandras nerver mycket, men varför? Det är bättre att omedelbart skriva något så här: "Systemet är utformat för att underhålla lagerbokföring i företag X i enlighet med de krav som anges i denna uppdragsbeskrivning.”
Mål för att skapa systemet	Mål är definitivt en viktig del. Om vi ska ha med det så måste vi kunna formulera dessa mål. Om du har svårt att formulera mål är det bättre att helt utesluta detta avsnitt. Ett exempel på ett misslyckat mål: ”Se till snabb bearbetning handlingar av chefen." Vad är snabbt? Detta kan sedan bevisas i oändlighet. Om detta är viktigt är det bättre att omformulera detta mål så här: "Säljchefen ska kunna upprätta ett dokument "Varuförsäljning" på 100 rader på 10 minuter." Ett sånt här mål kan komma upp om till exempel en chef för närvarande lägger ungefär en timme på detta, vilket är för mycket för det företaget och det är viktigt för dem. I denna formulering korsar målet redan kraven, vilket är ganska naturligt, eftersom när vi utökar målträdet (dvs. delar upp dem i mindre relaterade mål), kommer vi redan närmare kraven. Därför ska du inte ryckas med.

Generellt sett är förmågan att identifiera mål, formulera dem och bygga ett träd av mål ett helt separat ämne. Kom ihåg det viktigaste: om du vet hur, skriv, om du inte är säker, skriv inte alls. Vad händer om du inte formulerar mål? Du kommer att arbeta efter kraven, detta tränas ofta.

Avsnitt 3. Egenskaper för automationsobjekt.

Avsnitt 4. Systemkrav

GOST dechiffrerar listan över sådana krav:

krav på systemets struktur och funktion;
krav på antal och kvalifikationer för systempersonal och deras funktionssätt;
destinationsindikatorer;
krav på tillförlitlighet;
säkerhetskrav;
krav på ergonomi och teknisk estetik;
transporterbarhetskrav för mobila högtalare;
krav på drift, underhåll, reparation och lagring av systemkomponenter;
krav för att skydda information från obehörig åtkomst;
krav på informationssäkerhet vid olyckor;
krav på skydd mot yttre påverkan;
krav på patenterad renhet;
krav på standardisering och enande;

Trots det faktum att den huvudsakliga säkert kommer att vara avsnittet med specifika krav (funktionellt), kan detta avsnitt också vara av stor betydelse (och i de flesta fall är det). Vad kan vara viktigt och användbart:

Kvalifikationskrav. Det är möjligt att systemet som utvecklas kommer att kräva omskolning av specialister. Det kan vara både användare av det framtida systemet och IT-specialister som kommer att behövas för att stödja det. Otillräcklig uppmärksamhet på denna fråga utvecklas ofta till problem. Om kvalifikationerna för den befintliga personalen är uppenbart otillräckliga, är det bättre att specificera krav på organisation av utbildning, utbildningsprogram, timing etc.
Krav för att skydda information från obehörig åtkomst. Inga kommentarer här. Det är just dessa krav för att avgränsa tillgången till data. Om sådana krav är planerade måste de skrivas separat, så detaljerat som möjligt, enligt samma regler som funktionskrav (förståelighet, specificitet, testbarhet). Därför kan dessa krav ingå i avsnittet med funktionskrav
Krav på standardisering. Om det finns några konstruktionsstandarder som är tillämpliga på projektet kan de ingå i kraven. Sådana krav initieras i regel av Kundens IT-tjänst. Till exempel har 1C-företaget designkrav programkod, gränssnittsdesign, etc.;
Krav på systemets struktur och funktion. Här kan kraven på att integrera system med varandra beskrivas och en beskrivning av den allmänna arkitekturen presenteras. Oftare är integrationskrav i allmänhet uppdelade i ett separat avsnitt eller till och med en separat teknisk specifikation, eftersom dessa krav kan vara ganska komplexa.

Alla andra krav är mindre viktiga och behöver inte beskrivas. Enligt mig gör de bara dokumentationen tyngre, och praktisk nytta bära lite. Och det är mycket svårt att beskriva ergonomiska krav i form av allmänna krav, det är bättre att överföra dem till funktionella. Exempelvis kan kravet ”Få information om priset på en produkt genom att bara trycka på en knapp” formuleras. Enligt min åsikt är detta fortfarande närmare specifika funktionskrav, även om det gäller ergonomi. Krav på funktioner (uppgifter) som utförs av systemet. Detta är huvud- och nyckelpunkten som kommer att avgöra framgång. Även om allt annat är gjort perfekt, och det här avsnittet är "3", kommer resultatet av projektet att bli bästa fallet vid "3", eller till och med projektet kommer att misslyckas helt. Det är dessa som vi kommer att behandla mer i detalj i den andra artikeln, som kommer att ingå i det 5:e numret av nyhetsbrevet. Det är till denna punkt som "regeln om tre egenskaper för krav" som jag talade om gäller krav på typer av säkerheter

GOST identifierar följande typer:

Matematisk
Informationsinformation
Språklig
Programvara
Teknisk
Metrologiska
Organisatorisk
Metodisk
med flera...

Vid första anblicken kan dessa krav verka oviktiga. I de flesta projekt är detta sant. Men inte alltid. När ska dessa krav beskrivas:

Inga beslut har fattats om vilken språk- (eller plattforms)utveckling som ska genomföras;
Systemet kräver ett flerspråkigt gränssnitt (till exempel ryska/engelska)
För att systemet ska fungera måste en separat enhet skapas eller nya medarbetare anställas;
För att systemet ska fungera måste Kunden genomgå förändringar i arbetssätt och dessa förändringar måste specificeras och planeras;
Integration med all utrustning förväntas och krav ställs på den (till exempel certifiering, kompatibilitet etc.)
Andra situationer är möjliga, allt beror på projektets specifika mål.

Avsnitt 5. Sammansättning och innehåll i arbetet för att skapa systemet

Avsnitt 6. Förfarande för kontroll och acceptans av systemet

Allmänna krav för godkännande av arbete efter stadier (lista över deltagande företag och organisationer, plats och tidpunkt), procedur för samordning och godkännande av godkännandedokumentation Jag rekommenderar starkt att du tar ansvar för proceduren för inlämning av arbete och kontroll av systemet. Det är just därför som det behövs testbara krav. Men även förekomsten av testbara krav kanske inte räcker när systemet levereras om förfarandet för godkännande och överföring av arbete inte är tydligt. Till exempel en vanlig fälla: systemet är byggt och är fullt fungerande, men kunden är av någon anledning inte redo att arbeta i det. Dessa skäl kan vara vilka som helst: ingen tid, målen har ändrats, någon slutar, etc. Och han säger: "Eftersom vi ännu inte arbetar i det nya systemet betyder det att vi inte kan vara säkra på att det fungerar." Så lär dig att korrekt identifiera stadier av arbetet och sätt att kontrollera resultaten av dessa stadier. Dessutom måste sådana metoder vara tydliga för kunden från första början. Om de är fasta på nivån för de tekniska specifikationerna kan du alltid vända dig till dem vid behov och slutföra arbetet med överföringen.

7 § Krav på sammansättning och innehåll av arbete för att förbereda automationsobjektet för driftsättning av systemet

Det kan finnas andra regler för inmatning av information som antagits av företaget (eller planerat). Till exempel skrevs information om ett kontrakt tidigare in som en textsträng i valfri form, men nu krävs ett separat nummer, ett separat datum etc. Det kan finnas många sådana förhållanden. Vissa av dem kan uppfattas med motstånd från personalen, så det är bättre att registrera alla sådana fall på nivån av krav på ordningsföljd för datainmatning. Ändringar som måste göras i automatiseringsobjektet

Skapande av villkor för automatiseringsobjektets funktion, under vilka det skapade systemets överensstämmelse med kraven i de tekniska specifikationerna garanteras Eventuella ändringar som kan krävas. Till exempel har företaget inte lokalt nätverk, en föråldrad datorpark där systemet inte fungerar.

Kanske bearbetades en del nödvändig information på papper, och nu måste den läggas in i systemet. Om du inte gör detta så fungerar inte någon modul osv.

Kanske har något förenklats, men nu måste man ta hänsyn till det mer i detalj, så någon måste samla in information enligt vissa regler.

Denna lista kan vara lång, titta på det specifika fallet med ditt projekt. Skapande av avdelningar och tjänster som är nödvändiga för att systemet ska fungera.

Tidpunkt och tillvägagångssätt för bemanning och utbildning Vi har redan pratat om detta tidigare. Kanske utvecklas systemet för en ny struktur eller typ av verksamhet som inte fanns tidigare. Om det inte finns någon lämplig personal, och till och med utbildad, kommer systemet inte att fungera, oavsett hur kompetent det är byggt.

Avsnitt 8. Dokumentationskrav

Fundera över hur användarmanualer kommer att presenteras.

Kanske har kunden accepterat företagsstandarder, vilket innebär att vi måste hänvisa till dem.

Att ignorera dokumentationskraven leder mycket ofta till de mest oväntade konsekvenserna för projekt. Allt är till exempel gjort och allt fungerar. Användarna vet också hur man arbetar. Det fanns ingen överenskommelse eller samtal om dokumentation överhuvudtaget. Och plötsligt, vid överlämnandet av arbetet, frågar en av kundens högsta chefer, som inte ens deltog i projektet, men som är involverad i att acceptera arbetet, dig: "Var är användarmanualerna?" Och det börjar övertyga dig om att det inte fanns något behov av att komma överens om tillgängligheten av användarmanualer, detta antyds "naturligtvis". Och det är det, han vill inte ta ditt jobb. På vems bekostnad kommer du att utveckla riktlinjerna? Många lag har redan fallit för denna krok.

Avsnitt 9. Utvecklingskällor

Rekommendationer enligt GOST	Vad ska man göra åt det i praktiken
Dokument ska listas och informationsmaterial(förstudie, rapporter om genomfört forskningsarbete, informationsmaterial om inhemska och utländska analoga system etc.), utifrån vilka de tekniska specifikationerna har tagits fram och som bör användas vid skapandet av systemet.	För att vara ärlig så ligger det här närmare texten. Speciellt när de pratar om den ekonomiska effekten och annat som är nästan omöjligt att objektivt beräkna. Dessa. Naturligtvis blir det mer troligt på pappret, rent teoretiskt.

Därför är det bättre att helt enkelt hänvisa till undersökningsrapporten och nyckelpersoners krav.

Så vi har övervägt alla avsnitt som kan inkluderas i villkoren. "Kan" och inte "Måste" just för att vilket dokument som helst måste utvecklas för att uppnå ett resultat. Därför, om det är uppenbart för dig att ett visst avsnitt inte kommer att föra dig närmare resultatet, behöver du det inte och du behöver inte slösa tid på det.

Men ingen kompetent teknisk specifikation klarar sig utan det viktigaste: funktionskrav. Jag skulle vilja notera att i praktiken förekommer sådana tekniska specifikationer, och hur! Det finns figurer som kommer att kunna separera vattnet i alla avsnitt, beskriv allmänna krav i allmänna ordalag, och dokumentet visar sig vara ganska tungt, och det finns många smarta ord i det, och till och med kunden kan gilla det (det vill säga, han kommer att godkänna det). Men det kanske inte fungerar enligt det, d.v.s. Den har liten praktisk användning. I de flesta fall föds sådana dokument när du behöver få mycket pengar specifikt för villkoren, men det måste göras snabbt och utan att dyka ner i detaljer. Och speciellt om man vet att saken inte kommer att gå vidare, eller helt andra människor kommer att göra det. I allmänhet bara för att hantera budgeten, särskilt statsbudgeten.

I den andra artikeln kommer vi bara att prata om avsnitt 4 "Systemkrav", och specifikt kommer vi att formulera krav av tydlighetsskäl, specificitet och testbarhet.

Varför krav måste vara tydliga, specifika och testbara.

Eftersom praktiken visar: till en början visar sig de flesta tekniska krav som utvecklas av specialister antingen inte vara efterfrågade (stämmer inte överens med verkligheten) eller blir ett problem för dem som måste implementera dem, eftersom Kunden börjar manipulera vaga villkor och krav. Jag kommer att ge några exempel på vilka fraser man stötte på, vad detta ledde till, och sedan ska jag försöka ge rekommendationer om hur man undviker sådana problem.

Typ av krav

Felaktig formulering

De tekniska specifikationerna är källmaterialet för att skapa informationssystem eller annan produkt. Därför måste den tekniska specifikationen (förkortad som TK) först och främst innehålla huvudet tekniska krav till produkten och svara på frågan vad detta system bör göra, hur man arbetar och under vilka förhållanden.

I regel föregås stadiet med att upprätta tekniska specifikationer av en undersökning av ämnesområdet, som slutar med skapandet analytisk rapport. Det är den analytiska rapporten (eller den analytiska noteringen) som ligger till grund för referensdokumentet.

Om rapporten kan ange kundens krav i allmän syn och illustrerad med UML-diagram bör de tekniska specifikationerna i detalj beskriva alla funktions- och användarkrav för systemet. Ju mer detaljerade de tekniska specifikationerna är, desto mindre kontroversiella situationer kommer att uppstå mellan kunden och utvecklaren vid acceptanstestning.

Den tekniska specifikationen är alltså ett dokument som gör det möjligt för både utvecklaren och kunden att presentera slutprodukten och därefter kontrollera efterlevnaden av kraven.

De vägledande standarderna för att skriva tekniska specifikationer är GOST 34.602.89 "Tekniska specifikationer för att skapa ett automatiserat system" och GOST 19.201-78 "Tekniska specifikationer. Krav på innehåll och design." Den första standarden är avsedd för utvecklare av automatiserade system, den andra för programvara (vi diskuterade skillnaden mellan dessa serier i artikeln "Vad är GOST").

Så nedan presenterar vi en lista och beskrivning av avsnitten som de tekniska specifikationerna ska innehålla i enlighet med GOST.

GOST 19.201-78 Tekniska specifikationer. Krav på innehåll och design	GOST 34.602.89 Tekniska specifikationer för att skapa ett automatiserat system
1. Introduktion	1. Allmän information
2. Skäl till utveckling	1. Allmän information
3. Syfte med utveckling	2. Syfte och mål med att skapa systemet
	3. Egenskaper för automationsobjektet
4. Krav för programmet eller mjukvaruprodukten	4. Systemkrav
4.1. Funktionskrav	4.2. Krav på funktioner (uppgifter) som utförs av systemet
	4.1. Krav på systemet som helhet
	4.1.1. Krav på systemets struktur och funktion
	4.1.3. Destinationsindikatorer
4.2. Krav på tillförlitlighet	4.1.4. Krav på tillförlitlighet
	4. 1.5. Säkerhetskrav
	4. 1.6. Krav på ergonomi och teknisk estetik
4.3. Användarvillkor	4.1.2. Krav på antal och kvalifikationer för systempersonal och deras funktionssätt
	4. 1.9. Krav för att skydda information från obehörig åtkomst
	4. 1.10. Krav på informationssäkerhet vid olyckor
	4. 1.11. Krav på skydd mot yttre påverkan
	4. 1.12. Krav på patentrenhet
	4. 1.13. Krav på standardisering och enande
4.4. Krav på sammansättning och parametrar tekniska medel	4. 1.8. Krav på drift, underhåll, reparation och lagring av systemkomponenter
4.5. Krav på information och programvarukompatibilitet
4.6. Krav på märkning och förpackning
4.7. Krav på transport och lagring	4. 1.7. Transportabilitetskrav för mobila system
4.8. Särskilda krav	4. 1.14. Ytterligare krav
	4.3. Krav på typer av säkerheter
5. Krav på programdokumentation	8. Dokumentationskrav
6. Tekniska och ekonomiska indikatorer
7. Stadier och utvecklingsstadier	5. Sammansättning och innehåll i arbetet för att skapa systemet
8. Procedur för kontroll och acceptans	6. Procedur för kontroll och acceptans av systemet
	7. Krav på sammansättning och innehåll av arbete för att förbereda automationsobjektet för driftsättning av systemet
	9. Utvecklingskällor

Så dokumentet med tekniska specifikationer bör i själva verket återspegla alla krav för den designade produkten, identifierade vid analysstadiet av automationsobjektet.

Baserat på tabellen ovan kan vi lyfta fram huvuddelarna av de tekniska specifikationerna:

Allmän information om systemet (program);
Syfte, mål och mål för systemet (programmet);
Systemkrav (funktionskrav, användarkrav, krav på systemet som helhet, etc.);
Krav på typer av säkerhet;
Dokumentationskrav;
Stadier och utvecklingsstadier;
Proceduren för kontroll och godkännande av systemet (programmet).

Allmän information
Denna del av dokumentet med tekniska specifikationer måste innehålla systemets fullständiga namn och alla förkortningar som kommer att användas vid utvecklingen av dokumentationen.

Exempel:

"I detta dokument Informationssystemet som skapas kallas "Single window of access to educational resources", förkortat SW.
Systemet med det enda fönstret för tillgång till utbildningsresurser kan vidare hänvisas till som det enda fönstret eller systemet i detta dokument."

Även här bör du inkludera underavsnitt som ger information om de organisationer som är involverade i utvecklingen (kund och entreprenör).

Underavsnittet "Grundlag för utveckling" i dokumentet med tekniska specifikationer listar de viktigaste dokumenten på grundval av vilka detta arbete utförs. Till exempel för ett system beställt av regeringen i ett eller annat land Statligt organ, lagar, förordningar och myndighetsföreskrifter ska anges.

En integrerad del av dokumentet med tekniska specifikationer bör också vara en lista med termer och förkortningar. Det är bättre att presentera termer och förkortningar i form av en tabell med två kolumner "Term" och "Full Form".

Termer och förkortningar är ordnade i alfabetisk ordning. Först och främst är det vanligt att dechiffrera ryskspråkiga termer och förkortningar, sedan engelskspråkiga.

Syfte och mål med att skapa systemet

Detta avsnitt av den tekniska specifikationen måste innehålla syftet och målen med att skapa systemet.

Exempel:

"Informationssystemet "Single Window of Access to Educational Resources" är utformat för att ge användare fullständig, snabb och bekväm information om Ryska federationens utbildningssystem och organisationer som utför utbildningsinstitutioner.

Huvudmålet med systemet är att skapa en enhetlig informationsmiljö och automatisera affärsprocesser för utbildningsinstitutioner ryska federationen.

Skapandet av informationssystemet Single Window bör säkerställa:

tillhandahålla användare med ett brett utbud av informationsresurser;
nivå upp informationssäkerhet;
öka effektiviteten hos utbildningsinstitutioner och avdelningar genom att optimera ett antal affärsprocesser;
öka effektiviteten i interaktionsprocessen mellan informationssystem och tjänster inom avdelningen.

Skapandet av systemet kommer att minska driftskostnaderna som ett resultat av att avdelningens effektivitet ökar."

Systemkrav

Detta avsnitt av tekniska specifikationer är avsett att beskriva de grundläggande funktionskraven för systemet. Detta är den viktigaste delen av den tekniska specifikationen, eftersom det kommer att vara ditt huvudargument i tvister med kunden under processen att sätta systemet i drift. Därför är det nödvändigt att närma sig skrivandet mycket noggrant.

Referensdokumentet måste innehålla alla krav som identifierats vid analysstadiet av automationsobjektet. Det är bäst att lyfta fram de huvudsakliga affärsprocesserna, som bör avslöjas genom en beskrivning av funktionskrav.

Exempel:

"4.1 Affärsprocess "Att tillhandahålla information om utbildningsinstitutioner i Ryska federationen

Följande deltagare identifieras i denna affärsprocess:

Moderator – en anställd på avdelningen, en del av systemets underhållspersonal, ansvarig för att de uppgifter som tillhandahålls är korrekta

Användaren är en medborgare som behöver få information om arbetet i utbildningsinstitutioner i Ryska federationen.

4.1.1 Registrering läroanstalt i systemet

Registrering av en utbildningsinstitution i Ryska federationen utförs av den ansvariga anställde vid institutionen ("Regeringsdekret ...").

Processen för att registrera en utbildningsinstitution inkluderar följande steg:

Författaren skapar ett register om organisationen;
Författaren anger organisationens data;
Systemet söker efter en licens för en given organisation

Om licensen finns i databasen skickar systemet ett meddelande till författaren om framgångsrik registrering;
Om licensen inte hittas i databasen skickar systemet ett meddelande till författaren om att det inte finns någon licens för denna organisation."

Om tiden tillåter, bör informationen i detta avsnitt lämnas mer fullständigt i bilagan till referensdokumentet. I bilagan till de tekniska specifikationerna kan du tillhandahålla ett skärmformulär och nedan beskriva alla händelser som finns på det (skapa, visa, redigera, ta bort, etc.).

Kraven på systemet som helhet inkluderar en beskrivning av dess arkitektur med en beskrivning av alla delsystem. Denna del av villkoren bör beskriva kraven för att integrera systemet med andra produkter (om några). Vidare bör mandatet innehålla:

krav på systemdriftlägen
destinationsindikatorer
krav på tillförlitlighet
säkerhetskrav
krav på personalens antal och kvalifikationer och deras arbetsschema
krav på informationsskydd
krav på informationssäkerhet vid olyckor
patentkrav
krav på standardisering och enande
etc.

Krav på typer av säkerheter

Detta avsnitt av tekniska specifikationer bör innehålla krav på matematisk, information, språklig, mjukvara, teknisk och andra typer av support (om någon).

Dokumentationskrav

Avsnittet "Dokumentationskrav" i den tekniska specifikationen innehåller en lista över design- och driftsdokument som måste tillhandahållas kunden.

Denna del av den tekniska specifikationen är lika viktig som beskrivningen av funktionskraven, så du bör inte begränsa dig till frasen "Kunden måste förses med all dokumentation i enlighet med GOST 34." Detta innebär att du måste tillhandahålla hela paketet med dokument inklusive "formulär", "pass" etc. De flesta av dokumenten från listan som anges i GOST 34.201-89 behövs inte av varken dig eller kunden, så det är bättre att omedelbart komma överens om listan vid utvecklingsstadiet för tekniska specifikationer.

Minimipaketet med dokument inkluderar vanligtvis:

Tekniska specifikationer;
Redogörelse för preliminär (teknisk) design;
Förklarande anmärkning till det tekniska projektet;
Beskrivning av organisationen av informationsbasen;
Användarhandbok;
Administratörsguide;
Testprogram och metodik;
Acceptanstestrapport;
Intyg om utfört arbete

Det är bättre att presentera listan över dokument i de tekniska specifikationerna i form av en tabell, som anger namnet på dokumentet och standarden på grundval av vilken det ska utvecklas.

Stadier och utvecklingsstadier

Detta avsnitt av referensdokumentet bör ge information om alla stadier av arbetet som måste utföras.

Beskrivningen av scenen bör innehålla namn, tidpunkt, beskrivning av arbetet och slutresultatet.

Procedur för kontroll och acceptans av systemet

I det här avsnittet av dokumentet med tekniska specifikationer är det nödvändigt att ange det dokument på grundval av vilket acceptanstest ska utföras.

Vid behov kan den tekniska specifikationen kompletteras med andra avsnitt, eller minskas genom att olämpliga föremål tas bort.

Vid ändring av strukturen för de tekniska specifikationerna, för att undvika konfliktsituationer, måste det överenskommas med kunden innan dokumentet utvecklas.

Denna text skapades enbart för att det finns en permanent länk, som författaren själv, och alla ni, säkert kunde skicka till era framtida kunder, kollegor, släktingar och bekanta i form av ett standardiserat svar på frågan: "Behöver jag dina tekniska specifikationer och vad i allmänhet?"

Som de säger - "istället för tusen ord", eftersom varje gång att evangelisera i 4-5 timmar på Skype om detta ämne redan börjar bli tröttsamt, och den globala tendensen att glida in rent nonsens i definitionen av "tekniska specifikationer" bara intensifieras genom åren.

Problem

Faktum är att när det finns ett specifikt format, såväl som en tydlig och begriplig definition av en term, så ser alla manipulationer och ersättningar av den med dina egna trosor, prototyper, frågeformulär uppfunna i farten, beskrivningar och helt enkelt inkommande applikationer åtminstone oprofessionellt. Därför börjar vi med den vetenskapliga definitionen av vårt koncept:

Referensvillkor - det ursprungliga designdokumentet tekniskt objekt(produkter). Den tekniska specifikationen fastställer huvudsyftet med objektet som utvecklas, dess tekniska egenskaper, kvalitetsindikatorer och tekniska och ekonomiska krav, instruktioner för att slutföra de nödvändiga stegen för att skapa dokumentation (design, teknologi, programvara, etc.) och dess sammansättning, samt som särskilda krav. Uppdraget är juridisk handling- hur ansökan ingår i kontraktet mellan beställaren och entreprenören för att utföra designarbete och är dess grund: bestämmer ordningen och villkoren för arbetet, inklusive mål, mål, principer, förväntade resultat och deadlines. Det vill säga att det måste finnas objektiva kriterier genom vilka man kan avgöra om ett visst arbete har slutförts eller inte. Alla ändringar, tillägg och förtydliganden av de tekniska specifikationernas ordalydelse måste avtalas med kunden och godkännas av denne. Detta är också nödvändigt eftersom om felaktigheter eller fel i de initiala uppgifterna upptäcks i processen för att lösa ett designproblem, blir det nödvändigt att fastställa graden av skuld hos var och en av de parter som är involverade i utvecklingen och fördelningen av förluster i samband med med detta. Teknisk specifikation som term inom området informationsteknik– detta är ett juridiskt betydelsefullt dokument som innehåller omfattande information som är nödvändig för att tilldela utförare uppgifter för utveckling, implementering eller integration av en mjukvaruprodukt, informationssystem, webbplats, portal eller annan IT-tjänst.

Översättning till ett begripligt språk

1) Tekniskt uppdrag - det sätter uppgiften. Detta betyder att det bör komma före prototypen, skiss, test, designprojekt, eftersom alla mindmap, dataflödesdiagram, arkitektur redan är slutförandet av en viss uppgift, detta är svaret på frågan. Och innan själva frågan ännu inte har ställts, formulerats och undertecknats av alla parter, så blir väl något svar a priori felaktigt? Så, början på allt arbete med något projekt är formuleringen av ett problem, och inte ett frenetiskt sökande efter skisser av ett dussin alternativ för att lösa det.

2) Egentligen följer en ny logiskt av den första punkten - själva texten i TK måste börja med kapitlet "Mål och mål", som tydligt formulerar vilka affärsmål som eftersträvas av detta senaste försök att öka entropin i världen . En planlös uppgift som inte löser några problem, inte uppnår någonting och görs "av tristess" anses inte officiellt vara en teknisk uppgift, och är från och med nu i statusen "ett vanligt papper".

3) Hur förstår du om det föreslagna designkonceptet eller en interaktiv prototyp, eller till och med en färdig att använda webbplats, löser ovanstående affärsproblem? Det finns inget att göra, vi måste gå tillbaka till definitionen igen: "bestämmer ... förväntade resultat och deadlines. Det vill säga att det måste finnas objektiva kriterier genom vilka man kan avgöra om det ena eller det andra arbetet har slutförts eller inte.” Det vill säga att tekniska specifikationer inte kan existera utan tydliga mätbara indikatorer i rubel, sekunder, tonkilometer eller grader Celsius. Kanske en brief, eller en prototyp, eller något annat absurt papper, men inte det tekniska uppdraget.

Härifrån drar vi slutsatsen att det i denna TOR måste finnas ett kapitel "Acceptans- och utvärderingsförfarande", när samma indikatorer tas, mäts och parterna antingen skakar hand eller skickar projektet för omarbetning.

4) Det tekniska uppdraget måste nödvändigtvis överensstämma med kundens övergripande affärsplan, dess affärsutvecklingsstrategi och marknadssegmentsanalys. Allt detta gör att du kan sätta rätt mål, härleda korrekta mätvärden, som sedan kommer att användas för att på ett adekvat sätt acceptera den färdiga informationsprodukten. Frånvaron av en affärsplan från kunden garanterar automatiskt oprofessionellt genomförande av de tekniska specifikationerna.

Känner en utlagd studio till verksamhetens mål och mätbara indikatorer bättre än dess ägare? Uppenbarligen nej, vilket innebär att de korrekta tekniska specifikationerna ska skrivas av representanter för Kunden och inte av inhyrda anställda hos Entreprenören. Det är absurt när en artist sätter en uppgift för sig själv, sedan kommer på sätt att utvärdera den och i slutändan ger sig själv ett slutbetyg för det utförda arbetet. Helst borde sådan "amatöraktivitet" inte existera, även om det i praktiken är exakt vad som händer överallt, vilket gör att det tekniska uppdraget inte har någon inverkan den hjälp du behöver projekt, alltför ofta är i huvudsak ett fiktivt dokument. Gör inte det.

5) Varje ändring av den färdiga tekniska specifikationen måste kosta pengar. Du kan inte fritt och oändligt redigera "Constitution of your project" bara för att en av parterna ändrade sig, inte fick tillräckligt med sömn, plötsligt bestämde sig för att spara pengar, etc. Priset för varje ändring av de tekniska specifikationerna bör också tydligt anges i förväg i respektive kapitel.

Förresten, i teorin, på samma sätt, bör varje designredigering eller ändring av listan över sidor eller funktioner ha ett tydligt pris, som betalas i förskott, innan du gör denna ändring. Personligen föreslår jag att eventuell redigering av den godkända tekniska specifikationen ska uppskattas till 30 % av hela projektbudgeten, men du kan göra annat.

Är det värt att nämna att mandatet helt enkelt behöver ange i förväg tidpunkten och den totala budgeten för utveckling, samt en lista över alla befintliga resurser och restriktioner? – Nej, det blir för uppenbart.

Så: Vad gör vi? För vad? Hur ska vi förstå vad vi har gjort? Hur mycket kostar varje pivot? - Svaren på alla dessa frågor skrivna på ett papper är "silverkulan" som kan dra ut även det mest misslyckade projektet.

Säkerhetsfrågor

Och här kommer jag att lista svaren på de vanligaste frågorna från kunder:

1) Så, det kanske också finns en officiell GOST för att skriva tekniska specifikationer? – Ja, till och med flera.

2) Vad, den tekniska specifikationen innehåller ingen beskrivning nödvändiga sidor, antal knappar, använda bibliotek, riktlinjer etc.? - Inte i själva TOR, men i Bilagorna kan du lägga allt detta, naturligtvis, justera allt detta med ovan beskrivna mål, begränsningar och metoder för att ytterligare bedöma det uppnådda resultatet. Lägg upp åtminstone allt framtida innehåll, även en beskrivning av typiska karaktärer - men inte istället för ett tydligt uttalande av uppgiften, utan efter den.

3) Så jag kanske inte behöver det så? – Kanske görs i dag tusentals sajter utan tekniska specifikationer alls, precis som tusentals människor i världen lever bra och är blinda från födseln. Men om du vill se vart du är på väg, medvetet fatta beslut och självständigt utvärdera de erhållna resultaten, då kan du inte klara dig utan tekniska specifikationer.

4) Så du och Wikipedia skriver att den tekniska specifikationen är skapad av kunden. Men jag vet inte hur/jag har inte tid/jag vill bara inte göra det själv. Hur kan detta vara? - Outsourca utvecklingen av tekniska specifikationer till en tredje part som är helt insatt i din verksamhet, dess uppgifter, målgrupp och behov, och samtidigt grundligt kunnig om webbutvecklingens alla stadier. Denna tredje part kommer att bli en sorts "webnotarie", det vill säga en garant för att entreprenören inte kommer att underskatta de indikatorer du behöver eller inte kommer att försena tidsfristerna, och att kunden kommer att ställa in möjliga mätvärden och vid det slutliga godkännandet inte kommer att utvärdera den skapade produkten subjektivt och ändra de tidigare inspelade kraven i farten.

5) Och vad händer om den tekniska specifikationen är ett juridiskt dokument, då kan jag stämma utkontraktören, inte betala honom, tvinga honom att göra om allt för tionde gången? - Om dokumentet är korrekt utarbetat anges målen och metoderna för att bedöma hur de uppnåtts; om handlingen är undertecknad av parterna och nämns i Avtalet (Referensvillkoren i sig är inte ett avtal) - så kan du givetvis. Men med den vanliga briefen, prototyper, konstkreativ layout, säker affär på FL - inte längre.

6) De berättar för mig att arbetet kommer att utföras med någon form av Scrum eller Agile; vilket innebär att jag inte längre behöver den arkaiska tekniska specifikationen. Är det så? - Döm själv: de kallar dig ett obegripligt ord som tydligt döljer något, och nu, på grundval av en obekant term, erbjuder de att överge ett juridiskt kompetent dokument fyllt med mål och mått. Agile själv kan inte sätta några mål som "att uppnå minst 10 000 besök i slutet av året", eller "att uppnå fler än 25 beställningar från webbplatsen på en månad", det är bara ett sätt att hålla möten och ny organisation slarviga anställda. Tänk flera gånger: "kastar de inte damm i dina ögon?" Faktum är att professionella tekniska specifikationer inte kan skada något nymodigt Scrum, men det kommer säkert att hjälpa.

När man utvecklar något projekt. Hur förbereds detta dokument? Detta kommer att diskuteras i artikeln.

Teknisk specifikation - vad är det?

Innan man börjar utveckla ett projekt måste man först göra upp en plan. Byggande, företagande, bostadsarbete – absolut vad som helst arbetssfären kräver utveckling av en lämplig plan. I det här fallet spelar det ingen roll hur komplext eller allvarligt det eller det arbetet är. Utvecklingen av tekniska specifikationer, och faktiskt en vanlig handlingsplan, är ett nyckelskede här.

Mandatet behövs av båda sidor i arbetsprocessen: entreprenören och kunden. Ofta uppstår gräl, konflikter och missförstånd mellan dessa två individer. En väl utarbetad handlingsplan kommer att hjälpa till att strikt reglera alla skyldigheter för varje part.

Varför behöver kunden tekniska specifikationer?

Som redan nämnts är utvecklingen av tekniska specifikationer en nödvändig process som är användbar för båda parter anställningsavtal. Men nu är det värt att prata om varför det presenterade dokumentet behövs av den direkta kunden.

Det viktigaste att notera är att de tekniska specifikationerna endast utvecklas av kunden. Det här är en sorts handlingsplan, ett avtal om tillhandahållande av tjänster. Med hjälp av detta dokument kan artister tydligt definiera sina arbetsfunktioner, liksom vad som exakt krävs av dem. Dokumentet i fråga ska alltid utvecklas med högsta kvalitet och omsorg. Således måste kunden ta hänsyn till alla huvudteser och punkter, och även undvika motstridiga frågor. Om handlingen är korrekt upprättad kommer kunden alltid att kunna hänvisa den missnöjda entreprenören till en viss klausul i kontraktet.

Varför behöver entreprenören tekniska specifikationer?

Entreprenören får prover på tekniska specifikationer innan något arbete påbörjas. Arbetaren måste läsa alla punkter i dokumentet mycket noggrant. Detta steg kommer att hjälpa till att undvika manipulation av kunden. Därmed kan många chefer kräva något av anställda som inte diskuterades i de tekniska specifikationerna.

Entreprenören måste klargöra alla nödvändiga punkter och betalningsbeloppet. Så det bör du se till kontanta betalningar avser endast de punkter som anges i dokumentet. Annars kan ouppmärksamma artister arbeta gratis.

Entreprenören bör därför uppmärksamma prover av tekniska specifikationer så ofta som möjligt. Detta kommer att hjälpa honom att undvika onödiga problem och missförstånd.

Börjar kompilera ett dokument

Var ska jag börja fylla i dokumentet? Uppdraget för arbetet bör alltid inledas med allmänna bestämmelser och mål. Vad ingår allmänna bestämmelser? Först en liten ordlista. Det är det naturligtvis inte nödvändig förutsättning. Men om dokumentet är snävt fokuserat och därför fyllt med specifik terminologi, är det fortfarande värt att bifoga en liten ordbok. Detta blir i alla fall ytterligare ett steg mot ömsesidig förståelse mellan beställaren och entreprenören. För det andra ska de allmänna bestämmelserna innehålla information om avtalsparterna.

Vilka är syftena med uppdragsbeskrivningen? Det är nog inte svårt att gissa. Så det är nödvändigt att kortfattat beskriva vilken typ av projekt som utvecklas, varför det behövs och hur det slutliga resultatet kan uppnås. Alla uppgifter och mål ska beskrivas så detaljerat och tydligt som möjligt. Detta tillvägagångssätt kommer att bidra till att skapa ömsesidig förståelse mellan avtalsparterna.

Krav och deadlines

I obligatorisk varje teknisk specifikation för utförandet av arbetet måste innehålla vissa krav, såväl som tydligt fastställda tidsfrister. Allt är relativt klart med timingen. Även om det är värt att notera att det är bättre att ta tid med lite reserv. Dessutom bör hastigheten på orderutförande inte påverka kvaliteten. Om entreprenören bryter mot fastställda tidsfrister ska kontraktet innehålla vissa sanktioner för detta fall.

Vad kan du berätta om kraven? Kunden måste komma ihåg att alla krav är uppdelade i två huvudtyper: speciella och funktionella. Funktionskraven är till viss del visuella och figurativa. Det är vissa bilder, element, skisser av vad kunden skulle vilja se. Särskilda krav är strikt reglerade, vilket indikerar specifika uppgifter och metoder för utförande. Särskilda bör naturligtvis dominera betydligt. I annat artisten kanske helt enkelt inte förstår exakt vad de vill ha av honom.

Ansvar och rapportering

Det är värt att prata om ytterligare två viktiga element som absolut alla tekniska provspecifikationer bör innehålla lite mer detaljerat. Vi talar om parternas ansvar och om ansvarighet. Vad representerar vart och ett av dessa element?

Det är tillrådligt att generera rapportering i etapper, särskilt om uppdraget är stort. När ett visst skede av arbetet har avslutats kan rapportering lämnas in (obligatoriskt). Dessutom låter ett sådant system dig hålla artisten i god form. Annars kan han göra allt i sista stund, och därför av extremt dålig kvalitet.

Vad kan sägas om parternas ansvar? Det är omedelbart värt att notera att en sådan klausul inte är obligatorisk. Många kunder finner det dock fortfarande nödvändigt att reglera huvudtyperna av böter, straff och sanktioner för olika överträdelser. Det är tillrådligt att ange huvuddelarna av ansvar i dokument som tekniska specifikationer för upphandling, transport etc.

Upprättande av tekniska specifikationer

Varje tekniskt uppdrag (för leverans, konstruktion, transport etc.) måste utformas mycket kompetent och effektivt. Detta är nödvändigt för det första så att det i framtiden inte kommer att finnas några rättsliga förfaranden, tvister och konflikter på grund av missförstånd mellan parterna. Och för det andra, för enkel bekvämlighet. Inte alla kunder kan på ett kompetent sätt upprätta tekniska specifikationer. Ofta anlitas advokater för att hantera detta ärende, även om det inte är någon mening med det.

Du måste bara komma ihåg några enkla regler:

kontraktet måste vara detaljerat och detaljerat (det finns dock ingen anledning att överdriva; det är osannolikt att minst en entreprenör kommer att vilja läsa kommentarer i flera volymer om kraven);
avtalet måste vara tydligt, utan förvirring och onödig information.
uppgiften ska inte vara någon form av dogm; det är värt att komma ihåg att detta bara är en indikation, om än en strikt reglerad sådan - vare sig det är en teknisk specifikation för underhåll eller plantera träd.

Alla råd som gavs ovan är bara en liten del av vad man kunde prata om. Du kan dock fortfarande ge kunderna ett par riktlinjer. Därmed kan mandatet (för underhåll eller konstruktion) byggas efter en mall. Det är inte nödvändigt att ta denna mall från någonstans; Så om att skriva ett kontrakt för tillhandahållande av tjänster är en ganska vanlig uppgift, kommer det inte att vara så svårt att skapa ett par klichéer för dig själv.

Det är värt att komma ihåg hur viktigt det är att kontrollera standarderna: vare sig det är GOST, regulatorisk eller rättshandlingar, lokala handlingar etc.