1. Reaalajasüsteemid on tegelikkuse osa, kui arvutimudeli realiseerimisüsteemid vaid katsuvad tegelikkuse tööd modelleerida. Sellest tulenevalt, on neile küllaltki erinevad nõudmised ja ka erinev metoodika. Näiteks reaalajasüsteemide puhul on tihti olulised kõiksugu ohutus- ja turvakaalutlused (et miski õhku ei lendaks), kui modelleerimisüsteemidel oleks selline nõudmine koguni absurdne. Reaalajasüsteemi puhul aga ei saa eksperimentaalselt vähimagi kindlusega selgitada süsteemi korrektset tööd, mis modelleerimissüsteemi puhul on aga peaaegu et ainuke viis verifitseerimiseks. 2. 1) Rakendusinsenerid loovad katsetuste käigus uue arvutisüsteemi, mis täiustab mingit protsessi. Kuna tegemist pole otseselt tark- ja riistvaratootjatega, koosneb see süsteem esialgu küllalt käepärastest osadest ning ei pruugi kommertsiaalselt üldse rakendatav olla. 2) Peale esialgse lisatakse arvutisüsteemile uut funktsionaalsust, mis täiustab või koguni lisab uut väärtust. Et aga süsteem on "põlve otsas tehtud" ei suuda ta keerulisemaks kasvades enam vajalikku töökindlust tagada. Tehnilised ideed on olemas, aga realisatsioon on ebatäiuslik. 3) Professionaalsed riistvara- ja tarkvaratehnikud disainivad seade uuesti, võttes prototüübi funktsionaalsuse eeskujuks. Sealjuures saavutatakse rakendusinseneride tehnilise geeniuse ja tarkvaratehnikute professionaalse oskuse vahel mingi küllalt optimaalne ja hea lahendus. 4) Seadme juures järgitakse standardeid (kus vaja) ja lisatakse interfeisid mis suudavad suhelda suurema süsteemi teiste komponentidega, või koguni teiste sarnaste seadeteka. Siinkohal on valmis kommertisaalselt kasutuskõlblik seade. 3. Funktsionaalsed on nõuded tarkvaras väljakutsutavate funktsioonide olemasolule. See on siis, et antud tarkvara oleks võimeline kontrollima börsiinfot või et tarkvara suudaks üle võrgu teiste omalaadsetega suhelda. Mittefunktsionaalsed nõudmised on nõudmised sellele, mil moel funktsionaalseid nõudmisi täidetakse. Näiteks võib esitada nõudmisi töökindlusele, ohutusele, turvalisusele, valmidusele, hallatavusele või siis panna paika ajakitsendusi (kui nüüd lausa loetleda). Töökindlus tähendab siis, et kas tarkvara tõesti iga kord, kui vaja, suudab kontrollida börisinfot, või mõningates ekstreemsetes olukordades jääb hätta. Nõuded turvalisusele täpsustavad, mil moel peab tarkvara olema kaitstud süsteemiväliste mõjutuste vastu, kasvõi terrorismirünnaku vastu. Hallatavuse all mõistetakse seda, kui kerge vaevaga saab süsteemi sisse viia parandusi või uut funktsionaalsust - tarkvara tasemel tähendab siis kui põhjalik on dokumentatsioon ja spetsifikatsioon, kuidas on kood organiseeritud, ons süsteem modulaarne ja kindlasti ka muid kriteeriume. 4. Kehtivusintervall määratakse vastavalt muutuja kasutuskohale. Kui ta võib kiiresti muutuda, kehtib ta vähem aega, kui ta on väga stabiilne siis kehtib ta kauem. Samuti on kehtivusintervall seotud protsessi ohtlikkusega ja võib olla seotud ka süsteemi üldise olekuga. Näiteks pole vaja mõõta mingi paagi keemilist koostist kord kümnendiksekundis, kui see paak üldsegi tühi on (aga aegajalt võiks siiski mõõta, sest kuskil võib olla rike ja sinna paaki võib hakata siiski vedelikku valguma). Muutujal võib olla nii palju kehtivusintervalle kui palju tal on kasutuskohtasid. Iga arvutus võib põhimõtteliselt esitada muutujale omad ajakitsendused. 5. Alarmiseire kutsub välja eriolukorra töötluse alamsüsteemi, kui ta peab seda vajalikuks (ehk siis, alarmid viitavad, et on tegemist eriolukorraga). 6. Enamik mõõteriistasid annab oma väljundiks mingisuguse pinge, mis vastab otsesemalt või kaudsemalt suurusele, mida me mõõta soovime. See suhe võib olla lineaarne, aga ei pruugi. Seega, kõige esimene eeltöötlus võiks olla selle pinge muundamine (ausaltöeldes, teistsuguseks pingeks) mingiks otseselt kasutuskõlblikumaks suuruseks. Seejärel, meie mõõdetav suurus tõenäoliselt püsib kuskil vahemikus. See vahemik võib olla sobiv arvutisse sisse laskmiseks, aga ei pruugi. Seega tuleks see suurus seada täpselt nii, et ta alam- ja ülempiir ühtiks sisendi omadega - seda nii läbipõlemiskaitseks kui ka suurima võimaliku täpsuse saavutamiseks. Tõenäoliselt oleks vaja see analoogpinge ka digitaliseerida. Enamikel juhtudel oleks vaja ta ka varustada ajalipikuga, mille järgi siis erinevad komponendid saaks vaadata, kas antud mõõtesuurus sobib kasutamiseks või pole enam piisavalt aktuaalne. Tundub, et need võiksid olla ühed olulisemad eeltöötluse sammud. 7. Enamikes traditsioonilistes inimliidetes on loogika säärane: Kasutaja valib mingi funktsiooni, liides käivitab funktsiooni, kuvab tulemused ja ootab uut funktsiooni valikut. Reaalajatarkvaratehnikas pole kasutajaliides niimoodi realiseeritav, kuna suur hulk protsesse käib pidevalt ning nad võivad igal hetkel anda väljundit, millele kasutaja koheselt reageerima peab. Seega peab kasutajaliides olema täielikult interaktiivne. Teisalt jällegi on vaja arvestada mõningate teguritega, mis traditsiooniliselt on olnud vähemtähtsad või koguni tähtsusetud. Kohe tuleb meelde näide loengust, et tihtulugu tekivad rikete korral massiivsed häiretelaviinid ja neid ei tohi kõiki korraga kohe ekraanile lasta, vaid on vaja leida algpõhjuseid ja valida tähtsamaid häireid, vastasel juhul läheb kasutaja lihtsalt paanikasse ning lisaks ei ole ta suuteline nii massiivsest infotulvast vajalikku infot eristama. 8. Kuna reaalajasüsteemides töötavad korraga mitmed erinevad protsessid ja tarkvaratükid, mis vajavad informatsiooni ning juhatust päriselt eksisteeriva ajaga kooskõlastatult töötamiseks teatud kindlatel hetkedel. See on siis erinevalt äriinfosüsteemidest, kus (peaaegu) ainuke tegelik ajakitsendus on mitte kasutaja meelt väga mustaks ajada, kui ta liialt ootama peab. Näiteks, mingi aktiivsema protsessi juhtimisel on ülioluline piisava sagedusega läbi viia arvutusi tema stabiilsuse kohta, seega peab neid arvutusi saama teha mingi väga lühikese aja jooksul - isegi kui me mõõdame süsteemi parameetreid igal sajandiksekundil pole sellest mingit kasu, kui neist aru saamisele kulub näiteks neli sekundit - piisavalt aega et reaktor totaalselt õhku lasta. See on siis kitsendus mingite komponentide töö kiirusele (nende jõudlusele). Kitsendusi võib olla ka kõiksugu infovahetuse sünkroonsuse juures, erinevate toimingute järjekorra koha pealt, andmetel võib olla (ja üldiselt ongi) mitmeid kehtivusaegu.. Võib olla ka spetsifitseeritud, kui täpselt neid kitsendusi vaja jälgida on. Kõik sõltub tegelikult konreetsest rakendusest. 9. Minumeelest on töökindlus ja hooldatavus vägagi erinevad omadused ning neile on tunduvalt raskem leida sarnaseid, kui erinevaid külgi. Peamine sarnasus on neil, et mõlema jaoks on kasulik selgus ning piiritletus - töökindluse mõttes on hägusemates olukordades kergem eksida ja valesid eeldusi teha, hooldatavuse mõttes on selgemini spetsifitseeritud koodist lihtsam aru saada ja ka siis muudatusi, parandusi ning täiendusi teha. Muus mõttes on nad ikkagi kaks täiesti erinevat asja (kui mitte arvestada juhuslikku seaduspärasust, et ebatöökindlusele tihti järgneb hooldamine). 10. Sertifitseerimisel kontrollitakse korrektsust ja töökindlust. Mõlema kontrollimiseks on mitmeid viise (korrektsuse all pean silmas, et tarkvara teeb, mida tellijad talt nõudsid ning töökindluse all, et ta teeb seda ilma tõrkumata (täpsemas terminoloogias käiks siis mu "töökindlusele" alla ka ohutus ja turvalisus)). Korrektsuse tagamiseks võib kasutada formaalset verifitseerimist (kriitilisemate komponentide juures), mis on küllalt keerukas ja tihtilugu võimatu või reverse engineeringut, mille käigus tuletatakse tarkvara koodist tema spetsifikatsioon (põhimõtteliselt see on siis analüüs, vaadatakse mida ja kuidas kood teeb ning püütakse selgeks saada, miks) ning võrreldakse seda tarkvara originaalspetsifikatsiooniga - kui nad kattuvad on kood korrektne. Töökindluse kontrolliks nõutakse juba eelnevalt sertifitseeritud komponentide ja tööriistade kasutamist tarkvaraloomes ning luuakse ja analüüsitakse süsteemi töökindluse mudelit.