Techninė specifikacija IT projektui: šablonas, pavyzdys ir dažniausios klaidos

DESAmedia · 2026-10-07

Trumpas atsakymas

Techninė specifikacija yra dokumentas, kuriame užsakovas aprašo, ką sistema turi daryti, kas ja naudosis, su kuo ji turi keistis duomenimis ir kaip bus patikrinta, kad darbas atliktas. Gera specifikacija aprašo poreikį ir rezultatą, o ne konkrečią technologiją. Ją sudaro tikslai, vartotojų rolės, procesai, funkciniai ir nefunkciniai reikalavimai, integracijos, duomenų perkėlimas, priėmimo kriterijai ir priežiūros sąlygos. Viešuosiuose pirkimuose papildomai taikomas Viešųjų pirkimų įstatymo 37 straipsnis: specifikacija turi užtikrinti konkurenciją, o konkretūs prekių ženklai ar modeliai leidžiami tik išimties tvarka, su žodžiais „arba lygiavertis“. Žemiau rasite šabloną, kurį galite nusikopijuoti, ir trumpą (išgalvotą) techninės specifikacijos pavyzdį.

Kam reikalinga techninė specifikacija

Programinės įrangos kūrimo projektas be specifikacijos dažniausiai prasideda nuo frazės „mums reikia sistemos užsakymams“. Kiekvienas tiekėjas šį sakinį supras savaip, todėl gausite tris pasiūlymus, kurių negalima palyginti: vienas įvertins paprastą formą su lentele, kitas sistemą su apskaitos integracija ir klientų savitarna, trečias pasiūlys gatavą produktą. Pasiūlymų kainos skirsis kelis kartus, bet ne dėl įkainių, o dėl to, kad kiekvienas įvertino skirtingą darbą. Plačiau apie tai, kas lemia kainą, rašėme straipsnyje Kiek kainuoja individualios sistemos kūrimas.

Specifikacija išsprendžia tris problemas:

• Palyginami pasiūlymai. Visi tiekėjai vertina tą patį darbų sąrašą, todėl skiriasi tik kaina, terminai ir požiūris.
• Aiški apimtis. Sutartyje galima remtis dokumentu, o ne pokalbių prisiminimais. Kai atsiranda naujas pageidavimas, aišku, ar tai pakeitimas, ar jau sutartas darbas.
• Priėmimo pagrindas. Kai darbas baigtas, jį tikrinate pagal iš anksto sutartus kriterijus, o ne pagal įspūdį.

Naudos turi ir pats užsakovas. Rašant specifikaciją dažnai paaiškėja, kad skirtingi skyriai tą patį procesą supranta skirtingai, arba kad dalį problemos galima išspręsti be naujos sistemos. Jei dar svarstote, ar sistema apskritai reikalinga, padės straipsnis Excel ar individuali sistema? 7 požymiai.

Ką turi apimti techninė specifikacija

Žemiau aprašytos devynios dalys, kurios tinka daugumai verslo sistemų: CRM, užsakymų valdymo, B2B portalui, vidinei administravimo sistemai. Mažesniam projektui kai kurios dalys bus vos kelių sakinių.

1. Tikslai ir sėkmės matai

Pradėkite nuo to, kodėl sistema reikalinga ir kaip suprasite, kad ji pasiteisino. „Automatizuoti užsakymų priėmimą“ yra kryptis, o ne tikslas. Tikslas būtų toks: „užsakymas iš klientų portalo patenka į apskaitą be rankinio perrašymo, o vadybininkas mato jo būseną vienoje vietoje“. Jei turite skaičių, kiek laiko dabar užtrunka procesas ar kiek klaidų pasitaiko, įrašykite juos. Tai bus atskaitos taškas po paleidimo.

Čia pat aprašykite, kas į projektą neįeina. Sąrašas „ne šio etapo darbai“ apsaugo nuo nesusipratimų labiau nei bet koks kitas skyrius.

2. Vartotojai ir rolės

Išvardykite, kas naudosis sistema: vadybininkai, sandėlio darbuotojai, buhalterija, vadovai, klientai, partneriai. Prie kiekvienos rolės nurodykite, ką ji daro sistemoje, ką mato ir ko negali matyti, bei apytikslį naudotojų skaičių. Teisių lentelė (rolė ir veiksmas) vėliau taps vienu svarbiausių testavimo įrankių.

3. Procesai

Aprašykite, kaip darbas vyksta dabar ir kaip turėtų vykti su nauja sistema. Užtenka paprasto žingsnių sąrašo: kas inicijuoja veiksmą, kokie duomenys perduodami, kas tvirtina, kas nutinka, kai kažkas nepavyksta. Jei turite pavyzdinių dokumentų, ataskaitų ar skaičiuoklių, pridėkite juos kaip priedus. Programuotojui pavyzdinis užsakymo PDF ar realus Excel failas pasako daugiau nei puslapis teksto.

4. Funkciniai reikalavimai

Funkciniai reikalavimai aprašo, ką sistema daro: kokius veiksmus atlieka vartotojas ir kaip sistema reaguoja. Kiekvienam reikalavimui suteikite numerį (pavyzdžiui, FR-01), kad vėliau į jį būtų galima remtis sutartyje, sąmatoje ir priėmimo teste. Rašykite iš vartotojo pozicijos: „Vadybininkas gali pakeisti užsakymo būseną, o klientas apie pakeitimą gauna el. laišką.“

5. Nefunkciniai reikalavimai

Nefunkciniai reikalavimai aprašo, kaip gerai sistema turi veikti. Juos dažniausiai pamirštama įrašyti, o vėliau jie lemia didžiausius ginčus. Kaip kontrolinį sąrašą galima naudoti tarptautinio standarto ISO/IEC 25010:2023 kokybės modelį. Jame išskiriamos devynios programinės įrangos kokybės savybės: funkcinis tinkamumas, našumas, suderinamumas, sąveikos galimybės (anksčiau vadintos tinkamumu naudoti), patikimumas, saugumas, prižiūrimumas, lankstumas ir sauga.

Dėl asmens duomenų verta prisiminti BDAR 25 straipsnį: duomenų apsauga turi būti numatyta jau projektuojant sistemą, o ne pridėta po paleidimo. 32 straipsnis reikalauja tinkamų techninių ir organizacinių saugumo priemonių. Abu dalykus lengviausia įgyvendinti, kai jie įrašyti specifikacijoje.

Prieinamumas privalomas ne visoms sistemoms. Viešojo sektoriaus svetainėms ir programėlėms bei vartotojams skirtoms paslaugoms, pavyzdžiui, el. prekybai, taikomi teisės aktų reikalavimai. Kam jie taikomi ir ką WCAG 2.1 AA reiškia praktiškai, aprašėme straipsnyje WCAG ir EU Accessibility Act. Net kai reikalavimas neprivalomas, prieinamumą verta įrašyti klientų ir partnerių sąsajoms: pataisyti jį vėliau kainuoja daugiau.

6. Integracijos

Kiekvienai išorinei sistemai nurodykite, kokie duomenys keliauja, kuria kryptimi, kaip dažnai ir kuri sistema yra „tiesos šaltinis“. Pavyzdžiui: prekės ir likučiai ateina iš apskaitos kas 15 minučių, užsakymai į apskaitą siunčiami iškart patvirtinus, o klientų kontaktai pildomi tik naujoje sistemoje. Būtinai nurodykite naudojamos programos versiją (pavyzdžiui, Rivilė GAMA ar Rivilė ERP), nes nuo to priklauso, kokia jungtis įmanoma. Kokias jungtis realiai galima padaryti su populiariausiomis Lietuvos apskaitos programomis, aprašėme straipsnyje Sistemų integracija su Rivile, Directo ir Agnum.

Nepamirškite klaidų atvejo: kas turi nutikti, jei apskaita nepasiekiama, ir kas apie tai sužino.

7. Duomenys ir jų perkėlimas

Jei sistema pakeičia skaičiuokles ar seną programą, aprašykite, kokius duomenis reikia perkelti, kiek jų yra, kokios kokybės jie yra ir kas atsakingas už jų sutvarkymą. Duomenų perkėlimas dažnai užtrunka ilgiau, nei tikimasi, nes senuose duomenyse randama dublikatų, tuščių laukų ir skirtingų formatų. Nurodykite, ar reikia perkelti visą istoriją, ar tik aktyvius įrašus, ir kada vyks galutinis perkėlimas prieš paleidimą.

8. Priėmimo kriterijai

Priėmimo kriterijai atsako į klausimą, kada darbas laikomas atliktu. Juos patogiausia rašyti kaip patikrinamus scenarijus: „Kai klientas pateikia užsakymą portale, per 5 minutes jis atsiranda apskaitoje su tais pačiais kiekiais ir kainomis.“ Taip pat susitarkite, kiek laiko turėsite patikrai, kas laikoma kritine klaida ir kas nutinka, jei ji randama. Klausimai, kuriuos verta aptarti su tiekėju dar prieš sutartį, surinkti straipsnyje Kaip išsirinkti programavimo partnerį.

9. Priežiūra, garantija ir SLA

Sistema po paleidimo gyvena metų metus, todėl specifikacijoje aprašykite garantinį laikotarpį, reakcijos laiką pagal klaidos svarbą, atnaujinimų ir saugumo pataisų tvarką, atsarginių kopijų reikalavimus ir tai, ką gausite nutraukus bendradarbiavimą: kodą, dokumentaciją, prieigas. Jei turtinės teisės į kodą turi būti perduotos jums, įrašykite tai aiškiai. Viešųjų pirkimų įstatymo 37 straipsnis tiesiogiai numato, kad techninėje specifikacijoje gali būti nurodyta, ar reikalaujama perduoti intelektinės nuosavybės teises.

Kaip parašyti gerą reikalavimą

Reikalavimų inžinerijos standartas ISO/IEC/IEEE 29148:2018 nurodo savybes, kurias turėtų turėti kiekvienas reikalavimas. Praktikoje svarbiausios keturios: reikalavimas turi būti vienareikšmis (suprantamas tik vienaip), patikrinamas (galima įrodyti, kad įvykdytas), vienas (viename sakinyje vienas reikalavimas) ir reikalingas (be jo sistemos tikslas nepasiekiamas).

Dar vienas naudingas įprotis: venkite žodžių „ir t. t.“, „pagal poreikį“, „jei reikės“. Kiekvienas jų yra vieta, kurioje vėliau atsiras ginčas dėl kainos.

Kiek detali turi būti specifikacija

Specifikacija turi aprašyti, ką sistema daro ir kokių rezultatų tikitės, bet ne kaip ją programuoti. Užsakovas geriausiai žino procesą, o kūrėjas technologijas. Jei specifikacijoje nurodysite duomenų bazių lenteles ar programavimo kalbą be rimtos priežasties, apribosite tiekėjų pasirinkimą ir prisiimsite atsakomybę už techninius sprendimus.

Geras orientyras: specifikacija pakankamai detali, kai du skirtingi tiekėjai, ją perskaitę, įvertintų panašų darbų kiekį. Ekranų dizainas, mygtukų spalvos ar tikslus laukų išdėstymas dažniausiai nereikalingi. Pakanka nurodyti, kokius duomenis ekranas rodo ir kokius veiksmus leidžia atlikti.

Reikalavimams verta suteikti prioritetus. Vienas paplitusių būdų yra MoSCoW metodas: Must have (be to sistema neturi prasmės), Should have (svarbu, bet galima laikinai apeiti), Could have (pageidautina) ir Won't have this time (sąmoningai atidedama). Prioritetai leidžia susitarti dėl pirmosios versijos ir išlaikyti biudžetą, kai paaiškėja, kad viskas į jį netelpa.

Techninė specifikacija viešiesiems pirkimams ir privačiam projektui

Turinys abiem atvejais panašus, bet viešajame sektoriuje specifikacija tampa pirkimo dokumentu, kuriam taikomos įstatymo taisyklės.

Svarbiausios Viešųjų pirkimų įstatymo nuostatos, į kurias reikia atsižvelgti:

• Konkurencija. Techninė specifikacija turi užtikrinti konkurenciją ir nediskriminuoti tiekėjų (37 straipsnio 3 dalis).
• Funkciniai reikalavimai. Pirkimo objektą galima apibūdinti norimu rezultatu ar funkciniais reikalavimais, kurie turi būti tikslūs, kad tiekėjai galėtų parengti tinkamus pasiūlymus (37 straipsnio 4 dalis). IT sistemai tai dažniausiai tinkamiausias būdas.
• „Arba lygiavertis“. Konkretus modelis, prekės ženklas ar tiekimo šaltinis leidžiamas tik tada, kai objekto neįmanoma apibūdinti kitaip, ir tik su žodžiais „arba lygiavertis“ (37 straipsnio 5 dalis). Viešųjų pirkimų tarnyba yra išaiškinusi, kad šiuos žodžius reikia įrašyti prie kiekvieno tokio reikalavimo: bendra nuostata pirkimo dokumentuose jų nepakeičia.
• Prieinamumas. Fiziniams asmenims skirtų pirkimų specifikacijose, išskyrus pagrįstus atvejus, turėtų būti atsižvelgta į neįgaliųjų poreikius ir tinkamumą visiems naudotojams, o privalomi reikalavimai turi būti taikomi (37 straipsnio 2 dalis).
• Sutarties keitimas. Pirkimo sutartį be naujos procedūros galima keisti tik 89 straipsnyje nustatytais atvejais. Vienas jų yra pakeitimai ar pasirinkimo galimybės, kurie iš anksto aiškiai, tiksliai ir nedviprasmiškai aprašyti pirkimo dokumentuose. Jei sistemą planuojate kurti etapais, galimą plėtrą (pavyzdžiui, papildomus modulius ar integracijas) verta numatyti jau pirkimo dokumentuose.
• Rinkos konsultacijos. Prieš pirkimą perkančioji organizacija gali konsultuotis su rinkos dalyviais, o kvietimas skelbiamas CVP IS (27 straipsnis). Tam tikrais atvejais, pavyzdžiui, kai per paskutinius 12 mėnesių panašiame skelbiamame pirkime negauta nė vieno arba gautas tik vienas tinkamas pasiūlymas, konsultacijos yra privalomos. Jei specifikaciją padėjo rengti tiekėjas, perkančioji organizacija turi imtis priemonių, kad nebūtų iškreipta konkurencija, pavyzdžiui, pateikti tą pačią informaciją kitiems dalyviams ir nustatyti pakankamą pasiūlymų terminą.

Valstybės, registrų ir vidaus administravimo informacinėms sistemoms galioja ir atskira tvarka. Pagal Informacinių sistemų steigimo, kūrimo, atnaujinimo, pertvarkymo ir likvidavimo tvarkos aprašą (patvirtintas Vyriausybės 2024 m. gegužės 15 d. nutarimu Nr. 349) iki kūrimo darbų pradžios rengiamas informacinės sistemos techninis aprašymas (specifikacija), kuris derinamas su įgaliota institucija. Tokiu atveju pirkimo specifikacija turi būti suderinta su šiuo dokumentu.

Daugiau apie mūsų darbą su viešuoju sektoriumi rasite puslapyje Viešajam sektoriui.

Analizės etapas: kai specifikaciją rengiate kartu su kūrėju

Ne kiekviena organizacija turi žmogų, galintį parašyti specifikaciją. Tokiu atveju yra du keliai.

Pirmas kelias: mokamas analizės etapas. Pasirenkate tiekėją tik analizei: jis kalbasi su vartotojais, peržiūri esamus failus ir programas, aprašo procesus ir parengia specifikaciją su sąmata. Rezultatas yra dokumentas, kuris priklauso jums ir kurį galite naudoti rinkdamiesi kūrėją, net jei vėliau pasirinksite kitą tiekėją. Privačiame projekte tai dažniausiai greičiausias kelias iki tikslios kainos.

Antras kelias: specifikacija ir pirkimas atskirai. Viešajame sektoriuje analizę galima nupirkti kaip atskirą paslaugą, o kūrimą pirkti vėliau pagal parengtą specifikaciją. Čia svarbu prisiminti aukščiau minėtą 27 straipsnio taisyklę: jei specifikaciją rengęs tiekėjas dalyvaus kūrimo pirkime, perkančioji organizacija turi užtikrinti, kad jo turima informacija nesuteiktų pranašumo, o tiekėjo gali būti paprašyta raštu pagrįsti, kad jo konsultacija nepažeidė konkurencijos.

Abiem atvejais verta, kad specifikacijos rengime dalyvautų žmonės, kurie sistema naudosis kasdien. Vadovybės vizija ir realus darbo procesas dažnai skiriasi.

Dažniausios klaidos

• Sprendimas vietoj problemos. „Reikia mobiliosios programėlės“ vietoj „vairuotojai turi užfiksuoti pristatymą be popierinio važtaraščio“. Pirmasis variantas iš karto atmeta galbūt pigesnius sprendimus.
• Nėra „neįeina“ sąrašo. Neaprašyta riba reiškia, kad kiekviena šalis ją įsivaizduoja savaip.
• Nefunkciniai reikalavimai pamiršti. Našumas, prieinamumas, atsarginės kopijos ir teisės paaiškėja tik testuojant, kai jų pridėti brangiausia.
• Integracijos aprašytos vienu žodžiu. „Integracija su apskaita“ gali reikšti ir kasdienį failo importą, ir realaus laiko dvikryptę jungtį. Kaina skiriasi kelis kartus.
• Duomenų perkėlimas paliktas pabaigai. Senų duomenų tvarkymui reikia ir užsakovo darbuotojų laiko, kurio niekas nesuplanavo.
• Nukopijuota sena sistema. Specifikacija, kuri aprašo esamą programą su visais jos apėjimais, perkelia senus įpročius į naują sistemą.
• Viešajame pirkime nurodytas konkretus produktas be „arba lygiavertis“ ar reikalavimai, kuriuos atitinka tik vienas tiekėjas. Tai rizika pirkimo ginčams.
• Nėra priėmimo kriterijų. Be jų sunku pagrįstai reikalauti ištaisyti trūkumus.

Techninės specifikacijos šablonas

Šį šabloną galite nusikopijuoti ir pildyti. Mažam projektui kai kurios dalys bus vos kelių eilučių, didelėje sistemoje kiekviena gali tapti atskiru priedu.

1. Bendra informacija: projekto pavadinimas, užsakovas, atsakingi asmenys, dokumento versija ir data.
2. Esama situacija ir problema: kaip darbas vyksta dabar, kas neveikia, kiek tai kainuoja (jei žinoma).
3. Tikslai ir sėkmės matai: ko siekiama ir kaip tai bus matuojama po paleidimo.
4. Apimtis: kas įeina į projektą ir kas sąmoningai neįeina.
5. Vartotojai ir rolės: rolių sąrašas, apytikslis naudotojų skaičius, teisių lentelė.
6. Procesai: svarbiausių procesų aprašymai „dabar“ ir „turėtų būti“, pavyzdiniai dokumentai prieduose.
7. Funkciniai reikalavimai: sunumeruoti (FR-01, FR-02...), su prioritetu (Must, Should, Could, Won't).
8. Nefunkciniai reikalavimai: saugumas, asmens duomenys, prieinamumas, našumas, patikimumas, suderinamumas, prižiūrimumas.
9. Integracijos: kiekvienai sistemai duomenys, kryptis, dažnumas, tiesos šaltinis, klaidų valdymas, turimos sąsajos.
10. Duomenys ir jų perkėlimas: šaltiniai, apimtys, kokybė, atsakomybė, perkėlimo laikas.
11. Priėmimo kriterijai: priėmimo scenarijai, testavimo trukmė, klaidų klasifikacija.
12. Diegimas ir apmokymai: aplinkos (testinė, gamybinė), naudotojų apmokymas, dokumentacija.
13. Priežiūra, garantija ir SLA: garantinis laikotarpis, reakcijos laikas, atnaujinimai, kopijos, išėjimo sąlygos.
14. Teisės ir nuosavybė: turtinės teisės į kodą, licencijos, duomenų tvarkymo sutartis.
15. Apribojimai ir prielaidos: biudžeto rėžis, terminai, privalomos technologijos ar infrastruktūra (jei yra pagrįsta priežastis).
16. Priedai: pavyzdiniai dokumentai, ataskaitos, esamų sistemų aprašai, sąsajų dokumentacija.

Techninės specifikacijos pavyzdys: užsakymų valdymo sistema

Žemiau pateikiama sutrumpinta specifikacijos ištrauka. Įmonė ir visi skaičiai išgalvoti: pavyzdys parodo formuluočių lygį, o ne realaus projekto apimtį.

Esama situacija. UAB „Pavyzdys“ yra statybinių medžiagų didmenininkas, aptarnaujantis apie 300 verslo klientų. Užsakymai gaunami el. paštu ir telefonu, vadybininkai juos perrašo į Rivilę GAMA. Klientai skambina teirautis užsakymo būsenos, o perrašant pasitaiko kiekių ir kainų klaidų.

Tikslai.

• Klientai užsakymus pateikia patys, matydami savo kainas ir likučius.
• Užsakymai patenka į apskaitą be rankinio perrašymo.
• Klientas pats mato užsakymo būseną ir sąskaitas.

Neįeina: sandėlio valdymas, mokėjimai kortele, mobilioji programėlė.

Rolės: klientas (apie 300 įmonių, iki 3 naudotojų kiekvienoje), vadybininkas (6), buhalterija (2), administratorius (1).

Funkciniai reikalavimai (ištrauka).

Nefunkciniai reikalavimai (ištrauka).

• NFR-01: klientų portalas atitinka WCAG 2.1 AA ir veikia mobiliajame telefone.
• NFR-02: visi užsakymo pakeitimai įrašomi į veiksmų žurnalą, kurį mato administratorius.
• NFR-03: duomenų bazės kopija daroma kasdien ir saugoma 30 dienų; atkūrimas išbandomas prieš paleidimą.

Integracija su Rivile GAMA.

• Prekės, kainos ir likučiai: iš Rivilės į portalą kas 15 minučių. Tiesos šaltinis yra Rivilė.
• Patvirtinti užsakymai: iš portalo į Rivilę per 5 minutes, kaip pardavimo užsakymo dokumentas.
• Jei Rivilė nepasiekiama, užsakymai kaupiami eilėje, o administratorius gauna pranešimą.

Duomenų perkėlimas. Perkeliami aktyvūs klientai ir jų kontaktai iš Rivilės. Užsakymų istorija neperkeliama.

Priėmimo kriterijus (pavyzdys). Kai klientas pateikia užsakymą su 10 prekių eilučių, per 5 minutes Rivilėje atsiranda pardavimo užsakymas su tais pačiais kiekiais ir kliento kainomis, o portale užsakymo būsena tampa „Priimtas“.

Toks dokumentas gali būti 10-20 puslapių. Jo užtenka, kad keli tiekėjai pateiktų palyginamus pasiūlymus, o jūs žinotumėte, ką tikrinsite priimdami darbą.

Ką daryti toliau

Pradėkite nuo trijų dalykų: užrašykite tikslus ir „neįeina“ sąrašą, išvardykite roles ir surinkite pavyzdinius dokumentus bei skaičiuokles. Jau su tuo galima kalbėtis su tiekėjais. Jei norite, kad specifikaciją parengtume kartu su jūsų komanda, tam skirta paslauga IT konsultacijos ir sistemų projektavimas: procesų analizė, reikalavimai, integracijų žemėlapis ir sąmata, kurią galėsite naudoti su bet kuriuo kūrėju. Klausimus galite užduoti per kontaktų puslapį.

Šaltiniai

• Lietuvos Respublikos viešųjų pirkimų įstatymas, 37 straipsnis. Techninė specifikacija (temidy.lt, aktuali redakcija)
• Lietuvos Respublikos viešųjų pirkimų įstatymas, 27 straipsnis. Pasirengimas pirkimui (temidy.lt)
• Lietuvos Respublikos viešųjų pirkimų įstatymas, 89 straipsnis. Pirkimo sutarties keitimas (temidy.lt)
• Viešųjų pirkimų tarnyba. Dėl formuluotės „arba lygiavertis“ nurodymo techninėse specifikacijose
• Viešųjų pirkimų tarnyba. Rinkos konsultacijos: iššūkiai ir galimybės (gairės)
• Lietuvos Respublikos Vyriausybės 2024 m. gegužės 15 d. nutarimas Nr. 349 „Dėl Lietuvos Respublikos valstybės informacinių išteklių valdymo įstatymo įgyvendinimo“ (e-tar.lt, suvestinė redakcija)
• ISO/IEC 25010:2023. Product quality model
• ISO/IEC/IEEE 29148:2018. Requirements engineering
• Agile Business Consortium. What is MoSCoW Prioritization?
• BDAR 25 straipsnis. Pritaikytoji ir standartizuotoji duomenų apsauga (gdpr-info.eu)
• BDAR 32 straipsnis. Tvarkymo saugumas (gdpr-info.eu)
• W3C. Web Content Accessibility Guidelines (WCAG) 2.2