Ssenariyoyönümlü Spesifikasiya (Scenario-Oriented Specification, SOS), istifadəçi təcrübəsi ssenarilərindəki fəaliyyət, məqsəd və kontekst məlumatını izlənə bilən ara təsvirlər vasitəsilə funksional tələblərə, sistem komponentlərinə və ölçülə bilən mühəndislik spesifikasiyalarına çevirmək üçün hazırlanmış preskriptiv dizayn metodudur. Tədqiqat istifadəçi təcrübəsi araşdırmasının kontekstual və narrativ nəticələri ilə mühəndisliyin ölçülə bilən və yoxlanıla bilən texniki təsvirləri arasındakı qopmanı experience–specification gap, yəni təcrübə–spesifikasiya boşluğu kimi konseptuallaşdırır. SOS bu boşluğu ssenaridən birbaşa yekun texniki dəyərə sıçramaqla deyil, bir-birinə daimi identifikatorlarla bağlanan ara təsvirlər yaratmaqla aradan qaldırmağa çalışır.

SOS-un ilkin nüvəsi beş addımdan ibarətdir: ssenari elementlərinin müəyyənləşdirilməsi, qarşılıqlı təsir ardıcıllıqlarının qurulması, funksional tələblərin törədilməsi, komponentlərin seçilməsi və mühəndislik spesifikasiyalarının müəyyənləşdirilməsi. Metod üç dizayn prinsipinə əsaslanır: fəaliyyətəsaslı izlənəbilənlik, kontekstin irəli daşınması və sinxron çoxgörünüşlü təsvirlər. Bu prinsiplər ilkin olaraq beş meta-tələbi qarşılamaq üçün hazırlanmışdır: ikitərəfli izlənəbilənlik, kontekstual sədaqət, mühəndislik iş axını ilə uyğunluq, təkrarlana bilən çevrilmə və ortaq təsvir məkanı.

Metod Cənubi Koreyada 2021–2025-ci illər arasında həyata keçirilən və yaşlı yetkinlərin gündəlik, təhlükəsizlik və sosial qarşılıqlı təsir ehtiyaclarına yönəlmiş Lemmy adlı companion-care robotunun hazırlanması layihəsində təbii sənaye şəraitində qiymətləndirilmişdir. Ssenari hazırlama prosesi əvvəlcə 18 kəşfiyyat ssenarisi yaratmış, dizayn seminarlarında bu rəqəm 25 namizəd ssenariyə yüksəldilmiş və 12 yaşlı yetkinin evlərinə sahə səfərləri, köpük maketlər və yüksək dəqiqlikli prototiplərlə rol oynama işlərindən sonra 15 təsdiqlənmiş ssenariyə endirilmişdir.

SOS tətbiqində bu 15 ssenaridən ümumilikdə 244 kodlaşdırılmış ssenari elementi çıxarılmışdır. Bunların 138-i qarşılıqlı təsir elementidir: 59 istifadəçi fəaliyyəti və 79 məhsul fəaliyyəti. Qalan 106 element istifadəçi, məqsəd, mühit, alət və hadisə kimi kontekstual elementlərdir. Bu məlumatlar 104 qarşılıqlı təsir ardıcıllığına çevrilmiş; bunlardan 144 funksional tələb yaradılmış; tələblər 100 komponentə uyğunlaşdırılmış və təxminən 312 mühəndislik spesifikasiyası hazırlanmışdır.

144 funksional tələb harmonizasiya zamanı 69 təkrarlanan və ya əsas tələbə və 75 ssenariyə xas tələbə ayrılmışdır. İlkin komponent seçimlərində 72 ssenari-mənşəli komponent yaranmış, fənlərarası mümkünlük və inteqrasiya baxışlarından sonra bunlar 65-ə konsolidasiya edilmişdir. Ssenarilərdə birbaşa görünməyən, lakin sistem bütövlüyü üçün zəruri elektronika, montaj və oxşar infrastrukturu təmsil edən 35 mühəndislik-mənşəli komponentin əlavə edilməsi ilə ümumi komponent sayı 100-ə çatmışdır.

Sənaye tətbiqi SOS-un ilk beş addımının bütün ssenarilərdə tətbiq edilə bildiyini, lakin fiziki robot kimi embodied məhsulda semantik spesifikasiyanın təkbaşına kifayət etmədiyini də göstərmişdir. Komponentlərin məhsul gövdəsinə həqiqətən yerləşib-yerləşməməsi, sensorların düzgün əhatə təmin edib-etməməsi, montaj boşluqları və təhlükəsizlik–üslub ziddiyyətləri kimi problemlərə görə məkan inteqrasiyası (spatial integration) adlı altıncı addım tətbiq zamanı meydana çıxmışdır. Bu altıncı addım əvvəlcədən müəyyənləşdirilmiş SOS nüvəsinin hissəsi deyil, hal araşdırması zamanı yaranmış metodoloji genişlənmədir.

Tədqiqatın nəticələri SOS-un tək halda tətbiq edilə bildiyini və struktur baxımından ardıcıl olduğunu dəstəkləyir; lakin metod rəqib dizayn metodları ilə nəzarətli şəkildə müqayisə edilməmişdir. Buna görə mənbə SOS-un QFD, use-case metodları və ya başqa tələblər mühəndisliyi metodlarından üstün olduğunu sübut etmir. Eyni şəkildə SOS mühəndislik hədəf dəyərlərini avtomatik hesablamır: ölçülə bilən parametrlərin real hədəfləri üçün benchmark məlumatları, istehsalçı/təchizatçı məlumatları, istinad spesifikasiyaları, fiziki sınaqlar və mühəndislik mühakiməsi tələb olunur.

Tədqiqatın ən mühüm məhdudiyyəti doğrulamanın tək bir uzunmüddətli embodied-robotics layihəsinə əsaslanmasıdır. Birinci müəllifin participant-observer kimi metodun tətbiqində iştirak etməsi də şərh qərəzi potensialı yaradır; tədqiqatçılar bunu layihə sənədləri, müsahibələr, həmmüəllif baxışı və müxtəlif məlumat mənbələrinin triangulyasiyası ilə azaltmağa çalışmışlar. Buna görə nəticələri müxtəlif məhsul siniflərinə, yüksək dərəcədə tənzimlənən mühəndislik sahələrinə və ya yalnız rəqəmsal xidmət layihələrinə birbaşa ümumiləşdirmək uyğun deyil.

Senariyoyönümlü Spesifikasiya (SOS) nədir və hansı problemi həll edir?

Senariyoyönümlü Spesifikasiya istifadəçi ssenarilərindəki təcrübəvi və kontekstual məlumatı itirmədən onu mərhələli şəkildə funksional tələblərə, texniki komponentlərə və ölçülə bilən mühəndislik spesifikasiyalarına çevirən izlənə bilən dizayn metodudur; əsas problem ssenarinin “istifadəçi hansı vəziyyətdə nə yaşayır və məhsul necə davranmalıdır?” dilindən mühəndisliyin “hansı komponent hansı ölçülə bilən hədəfi təmin etməlidir?” dilinə keçərkən kontekst və əsaslandırmanın itirilməsidir.

UX ssenarisi ilə mühəndislik spesifikasiyası niyə eyni təsvir deyil?

İstifadəçi təcrübəsi ssenariləri zaman ərzində baş verən qarşılıqlı təsirləri, istifadəçinin məqsədini, vəziyyətini, ətraf mühit şərtlərini, istisna hadisələri və məhsul davranışını narrativ formada birlikdə daşıyır. Mühəndislik spesifikasiyaları isə sistemin ayrışdırıla bilən, komponentlərə təyin oluna bilən, ölçülə bilən və yoxlanıla bilən texniki öhdəliklərə çevrilməsini tələb edir. Məsələn, “yaşlı istifadəçi gecə vanna otağına gedərkən robot yıxılmanı gözdən qaçırmamalıdır” kimi kontekstual gözlənti mühəndislik baxımından sensor əhatəsi, zəif işıq performansı, yerləşdirmə, aşkarlama məntiqi və doğrulama şərtləri kimi ayrı texniki problemlərə çevrilə bilər.

Təcrübəvi məlumat niyə birbaşa parametr cədvəlinə çevrilə bilməz?

Çünki ssenari daxilində istifadəçi ehtiyacı çox vaxt tək sabit xüsusiyyət deyil. Eyni məhsul davranışı istifadəçinin yaşı, fiziki imkanları, mühit səs-küyü, günün vaxtı, mövcud alətlər, fövqəladə hallar və əvvəlki qarşılıqlı təsirlər kimi kontekstdən asılı ola bilər. Bu məlumatları birbaşa tək “tələb siyahısı”na endirmək texniki dəyərin niyə lazım olduğunu görünməz edə bilər.

Təcrübə–Spesifikasiya Boşluğu nədir?

Təcrübə–spesifikasiya boşluğu istifadəçi təcrübəsi ssenarilərindəki kontekstual qarşılıqlı təsir məntiqi ilə mühəndislikdə istifadə olunan formal və ölçülə bilən texniki təsvirlər arasında yaranan təmsil fasiləsizliyinin pozulmasıdır; tədqiqat bu problemi yalnız fənlərarası kommunikasiya çatışmazlığı kimi deyil, fərqli məlumat formalarının fərqli analitik vahidlər və mühakimə üsullarından istifadə etməsindən doğan təmsil problemi kimi nəzərdən keçirir.

“Representational non-isomorphism” nə deməkdir?

Tədqiqatın nəzəri töhfələrindən biri ssenari ilə mühəndislik spesifikasiyasını eyni məlumatın yalnız fərqli yazılışları kimi görməməsidir. Ssenarilər istifadəçi təcrübəsini zaman, kontekst və qarşılıqlı təsir trayektoriyası daxilində təşkil edir; spesifikasiyalar isə texniki öhdəlikləri komponent, parametr, hədəf dəyər və doğrulama məntiqi ətrafında təşkil edir. Buna görə iki təsvir arasında bir-bir və itkisiz birbaşa uyğunlaşdırma fərz etmək etibarlı deyil. SOS-un ara təsvirləri məhz buna görə zəruridir.

QFD və use case yanaşmalarından hansı baxımdan fərqlənir?

Mənbə Quality Function Deployment-ın müştəri ehtiyaclarını mühəndislik xüsusiyyətlərinə uyğunlaşdırmaqda güclü olduğunu, lakin ehtiyacları çox vaxt daha statik xüsusiyyətlər kimi nəzərdən keçirdiyini; kontekstdən asılı və zamana yayılan qarşılıqlı təsirlərin matris təsvirlərinə həmişə yaxşı uyğun gəlmədiyini bildirir. Use case yanaşmaları aktor–məqsəd–sistem davranışını formalaşdırır, lakin kontekstual niteleyicilərin ölçülə bilən mühəndislik spesifikasiyalarına necə daşınacağı həmişə aydın deyil. Bu nəzəri müqayisə SOS-un həmin metodlardan eksperimental olaraq üstün olduğunun sübutu deyil.

SOS-un beş ilkin meta-tələbi

SOS-un üç dizayn prinsipi

UA və PA nədir?

UA (User Action), istifadəçinin yerinə yetirdiyi fəaliyyətdir. PA (Product Action), məhsulun bu istifadəçi fəaliyyətinə cavab olaraq yerinə yetirdiyi və ya yerinə yetirməsi gözlənilən fəaliyyətdir. SOS böyük və abstrakt ssenari cümlələri əvəzinə bu UA–PA cütlərini əsas çevrilmə vahidi kimi istifadə edir.

Kontekstual elementlər hansılardır?

Mənbə təcrübə-mərkəzli ssenarinin altı ümumi elementini Actions, User(s), Goals, Settings, Tools və Events kimi nəzərdən keçirir. SOS-un Step 1 kodlaşdırmasında Actions əlavə olaraq istifadəçi fəaliyyətləri (UA) və məhsul fəaliyyətləri (PA) kimi ayrıldığı üçün praktiki iş cədvəlində UA, PA, User, Goal, Setting, Tool və Event olmaqla yeddi kod növü görünə bilər.

Daimi identifikator niyə vacibdir?

Hər mühüm elementə UA1, PA1, U1, G1 və ya SET1 kimi daimi kimliklərin verilməsi texniki qərarlar dəyişsə belə məlumat zəncirinin qırılmamasını hədəfləyir. Beləliklə, məsələn, sensor dəyişdirildikdə “hansı funksional tələb üçün seçilmişdi, həmin tələb hansı məhsul fəaliyyətindən, həmin məhsul fəaliyyəti hansı istifadəçi ssenarisindən gəlmişdi?” sualları geriyə doğru izlənə bilər.

SOS istifadəçi ssenarisini mühəndislik spesifikasiyasına necə çevirir?

SOS çevrilməni beş əsas addımla həyata keçirir: ssenaridəki strukturlaşdırılmış elementlər çıxarılır, UA–PA cütlərindən ardıcıl qarşılıqlı təsir zəncirləri yaradılır, məhsul fəaliyyətləri konteksti qoruyan həll-dən müstəqil funksional tələblərə çevrilir, bu tələblər tətbiq edilə bilən komponentlərə təyin olunur və sonda hər komponent üçün ölçülə bilən parametrlər və hədəflər müəyyənləşdirilir; embodied məhsul halında bu zəncirə fiziki mümkünlüyü yoxlayan altıncı məkan inteqrasiyası addımı əlavə edilmişdir.

Addım 1: Ssenari elementlərini müəyyənləşdirmə

İştirakçılar əvvəlcə ssenarini bütöv oxuyaraq narrativ axın və qarşılıqlı təsir konteksti barədə ortaq anlayış yaradırlar. Daha sonra istifadəçi fəaliyyətləri, məhsul fəaliyyətləri, istifadəçi xüsusiyyətləri, məqsədlər, mühit/setting məlumatları, alətlər və hadisələr ayrı elementlər şəklində çıxarılır.

Mənbə üç kodlaşdırma qaydası müəyyən edir. Separation, eyni cümlədə istifadəçi niyyəti və məhsul cavabı varsa onları ayrı UA və PA kimi ayırır. Granularity, elementi müstəqil davranış mənasını itirməyəcək ən kiçik uyğun səviyyədə kodlaşdırır. Identifier assignment isə hər elementə UA1, PA1 və ya SET1 kimi daimi kimlik verir.

Bu addımın nəticəsi Scenario Element Table-dır. Ssenari bu struktur məlumatları kifayət qədər ehtiva etmirsə, mənbə ssenarinin qarşılıqlı təsir ardıcıllıqlarına ayrılmadan əvvəl inkişaf etdirilməsinin lazım ola biləcəyini bildirir.

Addım 2: Qarşılıqlı təsir ardıcıllıqlarını yaratma

Çıxarılan UA və PA-lar uyğunlaşdırılır və zaman sırasına qoyulur. İstifadəçi xüsusiyyətləri, məqsədlər, setting, tools və events bu ardıcıllıqdan çıxarılmır; sonrakı texniki qərarlara təsir edən strukturlaşdırılmış niteleyicilər kimi qalır.

Məsələn, istifadəçinin “axşam 19.00-a qədər tez yemək hazırlamaq istəməsi” yalnız “yemək təklif et” funksiyasına endirilmir. Zaman təzyiqi məhsul davranışını dəyişir və daha qısa hazırlanma müddəti olan seçimlərin prioritetləşdirilməsi kimi texniki/funksional nəticələr yarada bilər.

Tətbiq zamanı ortaya çıxan “inferred action” nədir?

Inferred action, ssenaridə açıq yazılmamasına baxmayaraq növbəti məhsul davranışının texniki cəhətdən baş verə bilməsi üçün arada mövcud olmalı sistem əməliyyatının görünən hala gətirilməsidir. Məsələn, ssenaridə yalnız “robot uşaqlara səsli mesaj göndərir” deyilirsə, hadisənin aşkarlanması, şərh edilməsi və mesajın yaradılması kimi zəruri ara proseslər açıq yazılmamış ola bilər. Komanda bu əməliyyatları əlavə etmiş, lakin hər əlavəni mənşə aldığı ssenari elementinə bağlayaraq izlənəbilənliyi qorumuşdur.

“Void action” nədir?

Void action, istifadəçi baxımından arzuolunan, lakin layihənin mövcud texnologiya, xərc və ya tətbiq oluna bilmə məhdudiyyətləri daxilində həyata keçirilə bilməyən məhsul davranışıdır. SOS bunu ssenaridən silmir; “hazırda dəstəklənmir” statusu ilə qoruyur. Beləliklə texniki cəhətdən həyata keçirilə bilməyən davranışın arxasındakı istifadəçi niyyəti gələcəkdə yenidən qiymətləndirilə bilər.

Qarşılıqlı təsir forması niyə ayrıca aydınlaşdırıldı?

Ssenarilərdə “istifadəçi robota soruşur” kimi ifadələr səs, mobil tətbiq və ya fiziki interfeysdən hansının istifadə olunduğunu açıqlamaya bilər. Tətbiq zamanı komanda, sübut varsa qarşılıqlı təsir modalitesini aydınlaşdırmış; qeyri-müəyyənlik davam edirsə birdən çox mümkün modaliteyi qeyd etmişdir. Bu əməliyyat sonrakı sensor, interfeys və komponent seçimlərinin uydurma fərziyyəyə söykənməsini azaltmışdır.

Addım 3: Funksional tələbləri törətmə

Hər UA–PA cütünün ən azı bir funksional tələb yaratması gözlənilir. Funksional tələb birbaşa konkret texnologiya seçmək əvəzinə məhsulun həyata keçirməli olduğu qabiliyyəti təsvir edir.

SOS-un məhdudlaşdırılmış FR cümlə məntiqi: Məhsul müəyyən bir məhsul fəaliyyətini mümkün etmək məqsədilə zəruri funksiyanı; istifadəçi xüsusiyyətləri, məqsədlər, mühit, alətlər və ya hadisələr kimi müvafiq kontekst şərtləri altında və ya onlara əsaslanaraq həyata keçirməlidir.

Bu struktur riyazi formula deyil. Mənbənin standartlaşdırılmış tələb yazma qrammatikasıdır. Məqsəd “məhsul səs tanıma etməlidir” kimi kontekstsiz tələb əvəzinə, məsələn, səs-küylü mətbəx mühitində yemək təklifi verə bilmək üçün istifadəçinin səs əmrini etibarlı şəkildə tanımaq kimi səbəb–funksiya əlaqəsini qorumaqdır.

Bir PA birdən çox məsuliyyət və ya doğrulama şərti ehtiva edirsə, FR-lər bölünə bilər. Eyni davranışı ifadə edən FR-lər isə ilkin iz bağlantıları qorunaraq birləşdirilə bilər. Birdən çox ssenaridə təkrarlanan tələblər harmonizasiya ilə basic FR, yalnız konkret ssenarinin xüsusi davranışını qoruyanlar isə specific FR kimi ayrılır.

Addım 4: Komponentləri seçmə

Funksional tələblər aparat təminatı, proqram təminatı və ya interfeys komponentlərinə uyğunlaşdırılır. Seçim yalnız funksiyanın adına görə edilmir; texnologiyanın yetkinliyi, performans məhdudiyyətləri, xərc və istehsal oluna bilmə kimi mümkünlük meyarları da nəzərə alınır.

Bir FR birdən çox komponent tələb edirsə, kritik çevrilməni həyata keçirən komponentə ilkin sahiblik verilə və digər asılılıqlar qeyd oluna bilər. Bu əlaqələr Function–Component Matrix daxilində saxlanılır.

İlkin seminarларда 72 ssenari-mənşəli komponent müəyyən edilmişdir. Sonrakı mümkünlük və inteqrasiya qiymətləndirmələri ilə bəzi komponentlər təxirə salınmış, dəyişdirilmiş, sadələşdirilmiş və ya birləşdirilmiş və say 65-ə enmişdir. Bundan əlavə, ssenarilərdə birbaşa görünməyən, lakin məhsulun işləməsi üçün zəruri daxili elektronika, struktur montajlar və oxşar 35 mühəndislik-mənşəli komponent əlavə edilmiş; ümumi say 100 komponentə çatmışdır.

Addım 5: Mühəndislik spesifikasiyalarını müəyyənləşdirmə

Hər seçilmiş komponent üçün parametr adı, vahid, hədəf dəyər və ölçmə/doğrulama fərziyyəsi müəyyən edilir. Mənbə hər komponentin ən azı bir ölçülə bilən parametr daşımasını hədəfləyir. Kontekstual məhdudiyyət kəmiyyətləşdirilə bilirsə, açıq hədd dəyərinə çevrilir; hələ etibarlı kəmiyyət dəyəri yoxdursa, doğrulama fərziyyəsi və ya sonradan müəyyən ediləcək element kimi qeyd olunur.

TBD nə deməkdir?

TBD (To Be Determined), dəyərin mənbəyi hələ kifayət etmədikdə təsadüfi hədəf rəqəmi uydurmaq əvəzinə “sonradan müəyyən edilməlidir” kimi işarələnməsidir. Mənbədə bu yanaşma çatışmazlığı gizlətmə üsulu deyil, qeyri-müəyyənliyi görünən şəkildə idarə etmə vasitəsi kimi istifadə olunur.

SOS avtomatik tələb və ya mühəndislik hədəf dəyəri yaradan sistemdirmi?

Xeyr; SOS ssenaridən spesifikasiyaya çevrilmənin məlumat strukturunu və izlənəbilənliyini təşkil edir, lakin mikrofon həssaslığı, gecikmə, enerji sərfi və ya geometrik sərhədlər kimi real texniki hədəf dəyərlərini özbaşına hesablamır; mənbə bu dəyərlərin mühəndislik təxmini, benchmark, məlumat vərəqləri, təchizatçı məlumatları, istinad sistemləri və sonrakı PoC sınaqları ilə müəyyən edilməli olduğunu açıq bildirir.

Bu fərq metodun düzgün başa düşülməsi üçün kritikdir. SOS “istifadəçi bu ehtiyacı dedi, deməli mikrofon həssaslığı mütləq −35 dB olmalıdır” formasında avtomatik fiziki hesab aparmır. Şəkil 8-də verilən spesifikasiya nümunələri metodun işləmə formasını göstərmək üçündür; mənbə onları bütün məhsullara tətbiq edilə bilən universal hədəflər kimi təqdim etmir.

Həlldən müstəqillik niyə vacibdir?

Funksional tələb texniki həlldən əvvəl müəyyən ediləndə eyni istifadəçi məqsədi fərqli texnologiyalarla həyata keçirilə bilər. Mənbədəki nümunələrdən biri yüksək ayırdetməli ekranın xərc və enerji səbəbilə daha sadə LED matrisə çevrilə bilməsi, bununla belə “sistem vəziyyətini istifadəçiyə çatdırmaq” funksional məqsədinin qoruna bilməsidir.

Lakin mənbə həlldən müstəqilliyin yalnız metodun daxili qaydası olmadığını da vurğulayır. Sıx vaxt cədvəli və ya erkən xərc təzyiqi olan təşkilatlarda komandalar mövcud texnologiyaya çox tez bağlana bilər. Belə erkən yaxınlaşma SOS-un hədəflədiyi “əvvəl funksional niyyət, sonra texniki həll” ayrımını zəiflədə bilər.

Məkan inteqrasiyası niyə ortaya çıxdı?

İlk beş addım sistem davranışını və ölçülə bilən texniki hədəfləri semantik olaraq bağlasa da, robot kimi fiziki məhsulda komponentin həqiqətən gövdəyə yerləşib-yerləşmədiyi, kabel və montaj boşluqlarının kifayət edib-etmədiyi, sensorun istifadəçinin hərəkət yolunu görüb-görmədiyi və ya təhlükəsizlik elementinin səhvən işə düşüb-düşməyəcəyi yalnız cədvəl üzərindən müəyyən edilə bilməmişdir.

Məkan inteqrasiyası niyə altıncı SOS addımı kimi ortaya çıxdı?

Məkan inteqrasiyası ilk beş SOS addımının məntiqi və semantik izlənəbilənliyi təmin etməsinə baxmayaraq fiziki robotda komponent yerləşimi, montaj boşluğu, sensor əhatəsi, qarşılıqlı təsir əlçatanlığı və üslub–təhlükəsizlik–mühəndislik ziddiyyətlərinin ayrıca yoxlanmalı olması səbəbilə tətbiq zamanı ortaya çıxan embodied-feasibility genişlənməsidir; mənbə bunu bütün məhsullar üçün məcburi universal altıncı addım kimi deyil, mövcud embodied-product halında yaranmış zəruri metodoloji genişlənmə kimi şərh edir.

Seminarlarda komandalar komponentləri ortaq məhsul konsepti üzərində birlikdə yerləşdirmişlər. Beləliklə sensorun maneələnməsi, korpus həcminin yetərsizliyi, mikrofon–dinamik akustik qarşılıqlı təsiri və montaj əlçatanlığı kimi əvvəlki analitik təsvirlərdə görünməyən ziddiyyətlər üzə çıxarılmışdır.

Məsələn, mexaniki təcili dayandırma düyməsinin sistem xətalarında asan əlçatan olması lazım idi, eyni zamanda robotun sığallanması, toxunulması və səs tənzimlənməsi kimi yaxın istifadəçi qarşılıqlı təsirlərində səhvən basılmaması da tələb olunurdu. Fənlərarası qiymətləndirmə nəticəsində düymənin arxa-alt sahədə yerləşdirilməsi təklif edilmişdir. Bu nümunə universal emergency-stop yerləşdirmə qaydası deyil, ssenari konteksti ilə təhlükəsizlik/mühəndislik məhdudiyyətlərinin birlikdə qiymətləndirilməsinə dair hal nəticəsidir.

Metodun sənaye doğrulama mühiti

Tədqiqat Cənubi Koreyadakı Lemmy companion-care robot layihəsinin aktiv inkişaf prosesinə daxil edilmiş uzunmüddətli təbii hal dizaynından istifadə etmişdir. Layihə 2021–2025-ci illərdə dizayn firması, istehsal tərəfdaşı və dövlət tədqiqat qurumunu əhatə edən çoxtərəfli inkişaf təşəbbüsüdür.

Ssenarilər necə yaradıldı və doğrulandı?

2021-ci ildə 12 dizayner və UX tədqiqatçısı dərin müsahibələr, kontekstual tədqiqatlar, fokus qrupları, ədəbiyyat icmalı və benchmarking istifadə edərək altı aylıq iş aparmışdır. Əvvəlcə 18 kəşfiyyat ssenarisi, sonra dizayn seminarları ilə 25 namizəd ssenari hazırlanmışdır.

Ssenarilər 12 yaşlı yetkinin evlərinə sahə səfərlərində, köpük maketlər və yüksək dəqiqlikli prototiplərlə rol oynama yolu ilə qiymətləndirilmişdir. İştirakçı rəyləri və daxili dizayn baxışları ilə üst-üstə düşən narrativlər birləşdirilmiş, təkrarlar çıxarılmış və ziddiyyətli fərziyyələr həll edilərək 15 təsdiqlənmiş ssenari əldə edilmişdir.

Bu ssenarilər üç persona ətrafında təşkil edilmişdir. SOS tətbiqindən əvvəl narrativlər istifadəçi fəaliyyəti, məhsul fəaliyyəti, istifadəçi profili, məqsəd, kontekstual niteleyicilər, alətlər və hadisələr aydın olacaq şəkildə ardıcıl quruluşa gətirilmişdir. Tədqiqatçılar bunun ssenarinin ilkin niyyətini dəyişdirmədən edildiyini bildirirlər.

Pilot və tam tətbiq

Əvvəlcə bir təmsilçi ssenari başdan sona pilot kimi istifadə edilmiş; terminologiya, iş razılaşmaları, ayrışdırma səviyyəsi və şablonlar sabitləşdikdən sonra metod qalan ssenarilərə tətbiq edilmişdir. İş fiziki ağ lövhədən real vaxtda birgə redaktəni və daimi sənədləşdirməni dəstəkləyən Miro iş sahəsinə keçmişdir.

Əsas tətbiq komandası insan faktorları, sənaye mühəndisliyi, sənaye dizaynı, maşın mühəndisliyi, UX dizaynı və biznes təcrübəsi olan altı tədqiqatçıdan ibarət olmuşdur. Komandaya dizayn metodologiyası və məhsul inkişafında 25 illik təcrübəsi olan baş məhsul dizayneri nəzarət etmişdir.

Komanda həmçinin elektrik, mexanika və proqram mühəndisləri ilə biznes mütəxəssislərini əhatə edən 12 sahə mütəxəssisi ilə işləmişdir. Bu şəxslər mümkünlük qiymətləndirilməsi, texniki komponent seçimi və spesifikasiya inkişafı zamanı töhfə vermişlər.

Empirik doğrulamanın dörd ölçüsü

Struktur doğrulama nəyi qiymətləndirdi?

Empirik doğrulama “metod istifadə zamanı nə baş verdi?” sualına yönəldiyi halda, struktur doğrulama üç dizayn prinsipinin hədəflənən meta-tələbləri həqiqətən əməli hala gətirib-gətirmədiyini araşdırmışdır. MR1–MR5 üçün müşahidə edilə bilən göstəricilər müəyyən edilmiş və real layihə artefaktlarındakı davranış tədqiq edilmişdir.

Məlumat mənbələri

Əsas empirik material SOS zamanı yaradılan Scenario Element Table, Interaction Sequence Map, FR siyahıları, Function–Component Matrix və Specification Sheet kimi layihə sənədləridir. Bu sənədlər iz yolları, çevrilmə qərarları və parametr əsaslandırmaları üçün birbaşa sübut təmin etmişdir.

İkinci mənbə participant observation-dır. Birinci müəllif SOS tətbiqində participant-observer kimi iştirak etmiş; metoddan yayınmaları, izah tələb edən məqamları, iterasiyaları və iştirakçıların müzakirələrini sahə qeydləri və iclas protokolları ilə sənədləşdirmişdir. Bu qeydlər tək tədqiqatçı qərəzini azaltmaq üçün həmmüəlliflərlə nəzərdən keçirilmişdir.

Üçüncü mənbə iştirakçı refleksiyaları və yarı-strukturlaşdırılmış müsahibələrdir. SOS tətbiqində iştirak edən 12 mütəxəssislə istifadə zamanı və sonrasında müsahibələr aparılmış; istifadə rahatlığı, qarşılaşılan çətinliklər və spesifikasiya qərarlarının əsaslandırmaları araşdırılmışdır.

Framework-Guided Content Structuring (FGCS) necə işlədi?

FGCS, SOS tətbiqində məlumatın addımlar arasında necə daşındığını yenidən qurmaq üçün istifadə olunan və framework analysis ilə keyfiyyət məzmun analizini birləşdirən analitik metoddur. SOS proseduru analitik skelet kimi istifadə edilmişdir.

1. Artefaktları addımlara görə təşkil etmə: Hər ssenarinin nəticələri SOS addımlarına görə xronoloji şəkildə qruplaşdırılmışdır.
2. Element axınlarını izləmə: Xüsusilə UA və PA-ların qarşılıqlı təsir ardıcıllıqları, FR-lər, komponentlər və spesifikasiyalar boyunca qorunub-qorunmadığı qeyd edilmişdir.
3. Yayınma və uyğunlaşmaları işarələmə: Buraxılan və ya yenidən sıralanan addımlar, əlavə alt addımlar və şərh dəyişiklikləri sənədləşdirilmişdir.
4. Ssenarilərarası nümunələri sintez etmə: Təkrarlanan tətbiqlər, ortaq çətinliklər və sabit uyğunlaşmalar 15 ssenari arasında müqayisə edilmişdir.

Tematik analiz necə aparıldı?

İştirakçıların SOS-u necə tətbiq etdiyini anlamaq üçün altı mərhələli tematik analiz istifadə edilmiş və birinci/ikinci dövr kodlaşdırma ilə dəstəklənmişdir. Yanaşma hibrid deduktiv–induktivdir: əvvəlcədən müəyyən edilmiş dörd doğrulama ölçüsü deduktiv tema çərçivəsini təmin etmiş, tətbiqdə gözlənilmədən ortaya çıxan inferred action, void action və spatial integration kimi nümunələr induktiv şəkildə əlavə edilmişdir.

Altı mərhələ; məlumatla tanışlıq qazanma, ilkin kodlaşdırma, yenidən kodlaşdırma, alt-temaları axtarma, temaların nəzərdən keçirilməsi/müəyyənləşdirilməsi və hesabatın hazırlanmasıdır. FGCS “hansı artefakt nə vaxt və necə çevrildi?” sualına daha struktur cavab verdiyi halda tematik analiz “iştirakçılar bunu necə və niyə bu şəkildə tətbiq etdilər?” sualını şərh etməyə kömək etmişdir.

Tədqiqatın Metodu və Nəticələri

Tədqiqat dizaynının texniki xülasəsi

15 ssenarinin kəmiyyət çevrilmə xülasəsi

Praktik tətbiq oluna bilmə nəticəsi

Nəzərdə tutulan beş SOS addımının hamısı 15 ssenarinin hamısında tamamlanmışdır. Mümkünlük baxışları bəzən əvvəlki addımlara qayıtmağı tələb etmiş, lakin daimi iz bağlantıları qorunmuşdur. Bir addımın nəticəsi ümumilikdə növbəti addım üçün istifadə edilə bilən giriş olmuş və yalnız bəzən izah və ya düzəliş tələb olunmuşdur.

Tətbiq zamanı üç mühüm uyğunlaşma ortaya çıxmışdır: çatışmayan ara sistem əməliyyatlarını görünən edən inferred actions, texniki baxımdan hazırda mümkün olmayan, lakin istifadəçi niyyətini qoruyan void actions və embodied məhsulun fiziki reallığını qiymətləndirən spatial integration.

Nəticə keyfiyyəti nəticəsi

İstifadəçi-mərkəzlilik yalnız “ssenari istifadə olunduğu” üçün deyil, texniki spesifikasiyaların müvafiq istifadəçi fəaliyyəti, məqsədi və mühitinə açıq iz bağlantıları daşıması ilə qorunmuşdur. Məsələn, sensor yerləşimləri yalnız abstrakt əhatə dəyərlərinə görə deyil, istifadəçinin gecə ev daxilindəki real hərəkət yolları kimi ssenari şərtlərinə görə yenidən nəzərdən keçirilmişdir.

Həlldən müstəqillik məhsulun yerinə yetirməli olduğu funksiya ilə onu həyata keçirəcək texniki komponenti müxtəlif mərhələlərdə nəzərdən keçirməklə qorunmağa çalışılmışdır. Bununla belə, tədqiqat həlldən müstəqilliyin təşkilati vaxt/xərc təzyiqindən təsirlənə biləcəyini də göstərmişdir.

Mümkünlük baxımından bəzi ilkin həllər dəyişdirilmişdir. Mənbə nümunələrində simsiz şarj əvəzinə smartfon şarj xatırladıcısının qiymətləndirilməsi və müəyyən edge-computing seçimlərinin enerji/xərc səbəbilə daha aşağı güclü həllərlə əvəz edilməsi yer alır. Bu dəyişikliklərdə ssenarinin ilkin funksional məqsədi iz bağlantısı ilə qorunmuşdur.

Spesifikasiyaların nə qədəri tamamlandı?

Spesifikasiya inkişafının sonunda ssenari-mənşəli komponentlərin təxminən %80-i tam parametrləşdirilmişdir. Qalan hissə “flagged for validation” kimi işarələnmiş və sonrakı PoC doğrulaması tələb edən parametrlər açıq şəkildə görünən saxlanmışdır.

Bu %80 dəyəri “məhsulun %80-i tamamlandı” demək deyil. Mənbə yalnız ssenari-mənşəli komponentlərin mühəndislik spesifikasiyaları baxımından parametrləşdirilmə vəziyyətini ifadə edir. Bu, tənzimləmə, istehsal, etibarlılıq sertifikasiyası və ya məhsulun bazara hazır olması üçün tamamlanma faizi deyil.

Proses keyfiyyəti nəticəsi

Paylaşılan ara artefaktlar fənlərarası müzakirələri yalnız şəxsi fikir mübadiləsindən çıxarıb ssenari, qarşılıqlı təsir, FR və komponent bağlantıları üzərindən daha izlənə bilən müzakirəyə çevirmişdir. Miro mühiti ssenarilərin, ardıcıllıqların, tələblərin və spesifikasiyaların eyni vizual mühitdə izlənməsini asanlaşdırmışdır.

Liderlik hər addımda eyni fənn tərəfindən həyata keçirilməmişdir. Erkən ssenari şərhi və rutin xəritələmədə UX/dizayn komandaları daha nəzərəçarpan rol oynayarkən, FR törətməsi ortaq körpü funksiyası görmüş; komponent və spesifikasiya mərhələlərində mühəndislik liderliyi artmış; spatial integration mərhələsində dizayn və mühəndislik yenidən ortaq liderliyə dönmüşdür. Mənbə bunun SOS-un məcburi rol bölgüsü olmadığını, mövcud hal komandasındakı müşahidə olunan nümunə olduğunu xüsusi qeyd edir.

Ölçəklənəbilənlik problemi

Ssenari, FR, komponent və parametr sayı artdıqca çoxdan-çoxa bağlantı şəbəkəsi sıxlaşmış və əl ilə iz idarəetməsi kövrək hala gəlmişdir. Mənbə bu nöqtədə vizual şəffaflığın faydasının sıx iz şəbəkəsini əl ilə idarə etməyin idrak xərci tərəfindən üstələnə biləcəyi miqyas həddi müşahidə etmişdir.

Faylların Miro-dan elektron cədvəllərə, tələb siyahılarına və digər sənədləşdirmə mühitlərinə daşınması əlavə olaraq bağlantıların qırılması və versiyaların ayrışması riski yaratmışdır. Buna görə komanda bəzi artefaktları canlı ortaq iş sahəsində, daha sabit artefaktları isə versiya-nəzarətli sənədləşdirmədə saxlamışdır.

Proses səmərəliliyi nəticəsi

SOS tətbiqi təxminən 11 aylıq müddətdə həyata keçirilmişdir. İlk ssenari başdan sona kalibrləmə halı kimi istifadə edilmiş və sonra qalan ssenarilər üç partiya halında işlənmişdir. İlkin partiyalar terminologiya, ayrışdırma səviyyəsi və iz idarəetməsi hələ sabitləşmədiyi üçün daha yavaş irəliləmiş; təkrarlanan funksiyalar və komponentlər yarandıqdan sonra sonrakı ssenarilərdə yenidən istifadə mümkün olmuşdur.

İkinci və üçüncü partiya ümumilikdə on ssenarini əhatə etmiş və təxminən dörd-beş ayda tamamlanmışdır. Mənbə bu sürətlənmənin ssenarilər arasındakı funksional təkrar sayəsində yarandığını bildirir. Ortaqlığı az olan layihələrdə eyni sürətlənmənin baş verəcəyi göstərilməmişdir.

Ssenari-mənşəli komponent spesifikasiyalarının təxminən %30-u ən azı bir dəfə yenidən nəzərdən keçirilmişdir; xüsusilə xərcə həssas və ya texniki baxımdan çətin komponentlərdə dəyişikliklər müşahidə edilmişdir. Bu nisbət “SOS %30 xəta yaratdı” demək deyil. Reviziyalar sistem inteqrasiyası və mümkünlük qiymətləndirilməsinin hissəsidir.

SOS proses səmərəliliyini təkbaşına təmin etdimi?

Xeyr. Mənbə səmərəlilik qazanclarının yalnız metoddan qaynaqlanmadığını açıq vurğulayır. İzlənəbilənliyin işləməsi ortaq sənədləşdirmə intizamı, artefaktların ortaq sahibliyi, müntəzəm çarpaz-funksional görüşlər və satınalma/istehsal komandaları ilə erkən koordinasiya kimi təşkilati şərtlərdən asılıdır.

Struktur doğrulama nə göstərdi?

MR1 və MR4 baxımından daimi identifikatorların yalnız audit qeydi olmadığı, mümkünlük müzakirələrində, komponent dəyişikliklərində və spatial integration zamanı aktiv mühakimə alətinə çevrildiyi müşahidə edilmişdir.

MR2 kontekstual sədaqət semantik səviyyədə təmin edilmiş, lakin embodied sistemdə kontekstin yalnız mətnlə daşınmasının kifayət etmədiyi görülmüşdür. Qarşılıqlı təsir modalitesi, istifadəçinin fiziki hərəkət yolu, sensor yerləşimi və montaj məhdudiyyətləri kontekstual sədaqətin fiziki ölçüsünü ortaya çıxarmışdır.

MR3 iş axını uyğunluğu mühəndislərin SOS artefaktlarını birbaşa hazırlaması və spesifikasiya cədvəllərinin PoC planlaşdırma və satınalma işlərində istifadə edilə bilməsi ilə dəstəklənmişdir.

MR5 ortaq təsvir məkanı da xüsusilə spatial integration zamanı güclü görünmüş, lakin bu funksiya təşkilati baxımdan şərti qalmışdır. Ortaq iş intizamı və ya identifikator idarəçiliyi zəifdirsə eyni artefaktların ardıcıllığı qorunmaya bilər.

Tətbiq zamanı ortaya çıxan MR6 nədir?

İlkin framework-də yalnız MR1–MR5 olduğu halda, hal araşdırması zamanı MR6: Traceability scalability, yəni izlənəbilənliyin ölçəklənə bilməsi, ortaya çıxan struktur tələb kimi müəyyən edilmişdir. Artefakt sıxlığı artdıqca əl ilə iz idarəetməsinin koordinasiya yükü yüksəlmiş; daha böyük sistemlərdə daimi kimliklər, vizual bağlantılar və ortaq məkanın fövqündə alət-dəstəkli trace management ehtiyacı aydınlaşmışdır.

MR6-nın mənbədə “emergent” olması vacibdir. SOS ilkin olaraq altı meta-tələblə hazırlanmayıb; altıncı tələb tətbiqin ölçəklənə bilmə sərhədlərindən törəmişdir.

Tədqiqatın dəstəklədiyi nəticələr

• SOS araşdırılan 15 ssenarilik sənaye halında ssenari–FR–komponent–spesifikasiya zəncirinin izlənə bilən şəkildə qurulmasını dəstəkləmişdir.
• Daimi identifikatorlar texniki qərarları ilkin ssenari kontekstinə geri bağlamaqda aktiv alət kimi istifadə edilmişdir.
• Kontekstin irəli daşınması texniki qərarların istifadəçi vəziyyəti və istifadə mühiti ilə əlaqəsinin görünən qalmasına kömək etmişdir.
• Beş əsas SOS addımı bütün 15 ssenaridə tətbiq edilmişdir.
• Inferred action və void action tətbiqləri çatışmayan və ya hazırda həyata keçirilə bilməyən davranışların görünən şəkildə idarə olunmasını təmin etmişdir.
• Embodied robot kontekstində spatial integration adlı altıncı addım zəruri olmuşdur.
• 144 FR-in harmonizasiyası 69 əsas və 75 ssenariyə xas FR ayrımına gətirib çıxarmışdır.
• 72 ilkin ssenari-mənşəli komponent mümkünlük baxışları ilə 65-ə konsolidasiya edilmiş və 35 mühəndislik-mənşəli komponentin əlavə olunması ilə ümumilikdə 100 komponent yaradılmışdır.
• Ssenari-mənşəli komponentlərin təxminən %80-i tədqiqatın sonunda tam parametrləşdirilmişdir.
• Ssenari-mənşəli komponent spesifikasiyalarının təxminən %30-u ən azı bir dəfə yenidən nəzərdən keçirilmişdir.
• Artan artefakt sıxlığı əl ilə iz idarəetməsinin miqyas sərhədini görünən etmiş və emergent MR6-nı doğurmuşdur.

Tədqiqatın dəstəkləmədiyi nəticələr

• SOS-un QFD, use case və ya başqa tələb/dizayn metodlarından üstün olduğu eksperimental olaraq göstərilməmişdir.
• SOS-un məhsul performansını, etibarlılığını, xərcini və ya bazara çıxış müddətini müəyyən faizlə yaxşılaşdırdığı göstərilməmişdir.
• Tədqiqat randomizə edilmiş və ya müqayisəli metod eksperimenti deyil.
• SOS mühəndislik hədəf dəyərlərini avtomatik hesablayan alqoritm və ya süni intellekt sistemi deyil.
• SOS pis və ya yetərsiz hazırlanmış istifadəçi ssenarilərini öz-özünə düzəltmir.
• Spatial integration-ın bütün məhsul növlərində məcburi altıncı addım olduğu göstərilməmişdir.
• Tək robot halındakı liderlik bölgüsü SOS-un məcburi təşkilati quruluşu deyil.
• Təxminən %80 parametrləşdirmə dəyəri məhsulun %80 tamamlanması və ya məhsul hazırlıq səviyyəsi demək deyil.
• Təxminən %30 reviziya nisbəti xəta nisbəti deyil.
• İkinci və üçüncü partiyada müşahidə olunan sürətlənmə bütün layihələrdə eyni müddətdə və ya nisbətdə proses qazancı yaranacağını sübut etmir.
• SOS tənzimləyici uyğunluq, istehsal sertifikasiyası, etibarlılıq doğrulaması və ya fiziki PoC sınaqlarını əvəz etmir.

Tədqiqatın əsas güclü tərəfləri

Birinci güclü tərəf metodun yalnız konseptual təqdim edilməməsi və aktiv sənaye layihəsində 15 fərqli ssenari üzrə uzunmüddətli tətbiq edilməsidir. Beləliklə metodun nəzəri addımları ilə yanaşı tətbiq zamanı yaranan pozulmalar, geri dönüşlər və gözlənilməz uyğunlaşmalar da müşahidə edilə bilmişdir.

İkinci güclü tərəf empirik doğrulama ilə struktur doğrulamanın birlikdə istifadə edilməsidir. Tədqiqat yalnız “iştirakçılar metodu bəyəndimi?” sualına deyil, dizayn prinsiplərinin əvvəlcədən müəyyən edilmiş meta-tələbləri həqiqətən necə həyata keçirdiyinə də baxmışdır.

Üçüncü güclü tərəf yalnız yekun spesifikasiya cədvəllərinin deyil; ssenari element cədvəlləri, interaction sequence map-ləri, FR siyahıları, component matrix-ləri, specification sheet-ləri, müşahidə qeydləri və ekspert müsahibələrinin birlikdə qiymətləndirilməsidir.

Dördüncü güclü tərəf metod uğurunu yalnız qüsursuz tətbiqlə qiymətləndirməməsi; inferred actions, void actions, spatial integration və MR6 kimi əvvəlcədən mövcud olmayan, lakin real tətbiqdə zəruri hala gələn uyğunlaşmaları açıq şəkildə hesabatlandırmasıdır.

Əsas məhdudiyyətlər

Tək hal: Tədqiqat yalnız bir uzunmüddətli embodied-robotics layihəsinə əsaslanır. Real sənaye prosesinin görünməsi güclü olsa da, müxtəlif məhsul və təşkilatlara ümumiləşdirmə məhduddur.

Participant-observer riski: Birinci müəllif metodun tətbiqində participant-observer kimi iştirak etmiş və keyfiyyət analizinin əsas məsuliyyətini daşımışdır. Bu vəziyyət şərh qərəzi potensialı yaradır. Artefakt triangulyasiyası, həmmüəllif baxışı və sistemli qərar qeydləri bu riski azaltmaq üçün istifadə edilmişdir, lakin onu tamamilə aradan qaldırmır.

Giriş ssenarisinin keyfiyyətindən asılılıq: SOS ssenari inkişaf etdirmə metodu deyil. İstifadəçi fəaliyyəti, məhsul cavabı və kontekstual məlumat zəifdirsə, sonrakı texniki tələblər də ümumi və yetərsiz qala bilər.

Texniki parametr yaratmır: Benchmark, məlumat vərəqi, təchizatçı doğrulaması və ya mühəndislik sınağı olmadıqda hədəf dəyərlər TBD qala bilər.

Əl ilə ölçəklənə bilmə: İz şəbəkəsi böyüdükcə Miro və əl ilə kimlik idarəetməsi yetərsiz qala bilər. Daha böyük layihələr xüsusi traceability və version-control alətlərinə ehtiyac duya bilər.

Təşkilati asılılıq: Metodun əməkdaşlıq təsiri ortaq artefakt məkanı, müntəzəm çarpaz-funksional iş və iştirakçıların iterasiyaya açıq olması kimi təşkilati şərtlərdən asılıdır.

Formal trade-off qaydası yoxdur: SOS istifadəçi təcrübəsi, xərc, təhlükəsizlik, tənzimləmə və texniki mümkünlük arasında hansı seçimin “qalib gəlməli olduğunu” riyazi və ya formal qərar qaydası ilə müəyyən etmir. Mövcud halda bu ziddiyyətlər fənlərarası müzakirə ilə həll edilmişdir.

Gələcək tədqiqat mövzuları

Mənbə gələcək iş üçün beş əsas sahə müəyyən edir. Birincisi, böyük artefakt şəbəkələri üçün dedicated digital environments, version control, vizual trace management və insan nəzarətini qoruyan AI-assisted və ya yarı-avtomatik trace consistency mexanizmləri araşdırılmalıdır.

İkincisi, mövcud TBD və “flagged for validation” yanaşmasının yanına Low–Medium–High kimi yüngül specification-confidence göstəricilərinin əlavə edilməsi təklif olunur. Bu göstəricilər dəyərin nə dərəcədə möhkəm sübuta əsaslandığını və hansı parametrin əvvəlcə fiziki olaraq doğrulanmalı olduğunu görünən edə bilər.

Üçüncüsü, SOS-un keyfiyyətli giriş ssenarisindən asılılığına görə ssenari yazma sintaksisinin və mühəndislik istifadəsinə hazır ssenari standartının hazırlanması təklif olunur. Xüsusilə qarşılıqlı təsir modaliteləri, istifadəçi xətaları və failure conditions kimi istisna halların ssenarilərdə daha açıq göstərilməsi araşdırılmalıdır.

Dördüncüsü, Steps 3 və 4-də təhlükəsizlik, tənzimləmə, xərc və istifadəçi təcrübəsi kimi ziddiyyətli hədəflərin həlli üçün strukturlaşdırılmış decision heuristics və rationale-capture mexanizmlərinin hazırlanması təklif olunur.

Beşincisi, SOS-un müxtəlif məhsul növləri, sektorlar, təşkilati strukturlar və layihə miqyaslarında yenidən tətbiq edilməsi lazımdır. Xüsusilə daha yüngül SOS tətbiqinin nə zaman kifayət etdiyi və tam altı-addımlı quruluşun nə zaman zəruri olduğu hələ müəyyən edilməmişdir.

Verianla Live baxımından uyğunluq

SOS Verianla Live üçün xüsusilə metod axını və izlənə bilən məlumat zənciri baxımından uyğundur. 15 ssenari → 244 element → 104 qarşılıqlı təsir → 144 FR → 100 komponent → təxminən 312 spesifikasiya zənciri source-faithful Live Process/Live Flow kimi göstərilə bilər. Lakin mənbədə hər ssenari üçün zaman sırası formasında kəmiyyət ölçməsi olmadığından saxta animasiya vaxtları və ya ara məlumat nöqtələri yaradılmamalıdır.

Mənbə və Metod Qeydi

Orijinal başlıq: Scenario-Oriented Specification (SOS): a design method for translating user scenarios into engineering specifications.

Müəlliflər: Ulugbek Vahobjon Ugli Ismatullaev; KwanMyung Kim.

Müəllif sırası: Ulugbek Vahobjon Ugli Ismatullaev birinci müəllif, KwanMyung Kim ikinci müəllifdir.

Bərabər töhfə: Mənbədə bərabər töhfə/bərabər birinci müəllif barədə bildiriş yoxdur.

Məsul müəllif: KwanMyung Kim.

Qurum: Department of Design, Ulsan National Institute of Science and Technology (UNIST), Ulsan, South Korea.

Jurnal: Research in Engineering Design.

Nəşriyyat: Springer Nature.

Mənbə növü: Research Article; mühəndislik dizaynı metodu inkişafı və sənaye halının doğrulanması tədqiqatı.

Cild: 37.

Məqalə nömrəsi: 36.

DOI: 10.1007/s00163-026-00498-w.

Received: 25 Mart 2026.

Revised: 20 İyun 2026.

Accepted: 16 İyul 2026.

Published / Version of Record: 31 Avqust 2026.

Rəyçi qiymətləndirməsi statusu: Research in Engineering Design jurnalında dərc olunmuş rəyçi qiymətləndirməsindən keçmiş Research Article.

Preprint statusu: Təqdim olunan mənbə dərc edilmiş Version of Record PDF-dir; mənbədə bu tədqiqat üçün ayrıca preprint identifikatoru göstərilmir.

Lisenziya: Creative Commons Attribution 4.0 International (CC BY 4.0).

Rəsmi nəşr bağlantısı: DOI 10.1007/s00163-026-00498-w vasitəsilə Springer Nature-ın rəsmi məqalə qeydi.

Əsas tədqiqat sualı: İstifadəçi ssenariləri kontekstual məna və izlənəbilənlik qorunaraq və mühəndislik iş axınları ilə uyğun qalaraq fənlərarası komandalar tərəfindən təkrarlana bilən şəkildə mühəndislik spesifikasiyalarına necə sistemli çevrilə bilər?

SOS əsas strukturu: Beş ilkin addım: ssenari elementlərini müəyyənləşdirmə; interaction sequence yaratma; funksional tələbləri törətmə; komponentləri seçmə; mühəndislik spesifikasiyalarını müəyyənləşdirmə.

Tətbiq zamanı ortaya çıxan genişlənmə: Step 6 — Spatial integration.

İlkin meta-tələblər: MR1 Bidirectional traceability; MR2 Contextual fidelity; MR3 Workflow compatibility; MR4 Repeatable translation; MR5 Shared representational space.

Tətbiq zamanı ortaya çıxan meta-tələb: MR6 Traceability scalability.

Dizayn prinsipləri: DP1 Action-based traceability; DP2 Context propagation; DP3 Synchronized multi-view representations.

Əsas ssenari strukturları: Actions, User(s), Goals, Settings, Tools və Events; SOS kodlaşdırmasında Actions, UA və PA kimi ayrılır.

Əsas iz identifikatorları: UA, PA, U, G, SET, T/E və komponent kodları kimi persistent identifiers.

Hal layihəsi: Lemmy companion-care robot.

Layihə dövrü: 2021–2025.

Coğrafiya: Cənubi Koreya.

İlkin kəşfiyyat ssenarisi: 18.

Namizəd ssenari: 25.

Təsdiqlənmiş ssenari: 15.

Persona: 3.

Sahə doğrulama iştirakçısı: 12 yaşlı yetkin.

Ssenari inkişaf komandası: 12 dizayner və UX tədqiqatçısı.

Əsas SOS tətbiq komandası: 6 tədqiqatçı.

Sahə mütəxəssisi: 12 elektrik, mexanika, proqram təminatı və biznes mütəxəssisi.

Əsas ssenari doğrulama alətləri: Dərin müsahibələr, contextual inquiry, focus groups, ədəbiyyat icmalı, benchmarking, sahə səfəri, foam mock-up və high-fidelity prototype role-playing.

Tətbiq vaxtlandırması: Ssenari inkişafı tamamlandıqdan sonra və proof-of-concept prototipləmədən əvvəl.

İş mühiti: Başlanğıcda fiziki whiteboard, sonra ortaq Miro workspace.

Empirik doğrulama ölçüləri: Practical enactability, output quality, process quality, process efficiency.

Structural validation: MR1–MR5 ilə DP1–DP3 arasındakı əlaqələrin real tətbiqdə ardıcıllığının araşdırılması.

Əsas empirik material: Scenario element tables, interaction sequence maps, functional requirement lists, function–component matrices və specification tables.

Digər məlumat mənbələri: Participant observation, annotated artifacts, written notes, meeting minutes, participant reflections və 12 mütəxəssislə semi-structured interviews.

FGCS: Framework-Guided Content Structuring; framework analysis ilə keyfiyyət məzmun analizini SOS proseduru ətrafında birləşdirən dörd mərhələli struktur analiz.

FGCS mərhələləri: Artefaktları SOS addımlarına görə təşkil etmə; element axınlarını izləmə; yayınma və uyğunlaşmaları kodlaşdırma; ssenarilərarası nümunələri sintez etmə.

Tematik analiz: Altı mərhələli Braun–Clarke yanaşması, first- və second-cycle coding ilə dəstəklənən hibrid deductive–inductive strategiya.

Tematik analiz mərhələləri: Familiarization; initial coding; re-coding; searching for sub-themes; reviewing and defining themes; producing the report.

Əsas tətbiq həcmi: 244 kodlaşdırılmış element; 59 UA; 79 PA; 106 kontekstual element; 104 interaction; 144 FR; 100 component; təxminən 312 engineering specification.

FR harmonizasiyası: 69 recurring/basic FR + 75 scenario-specific FR.

Komponent inkişafı: Əvvəlcə 72 scenario-driven component; konsolidasiyadan sonra 65; əlavə olaraq 35 engineering-driven component; cəmi 100.

Parametrləşdirmə nəticəsi: Scenario-driven component-lərin təxminən %80-i tədqiqatın sonunda tam parameterized; qalanları “flagged for validation”.

Reviziya nəticəsi: Scenario-driven component specifications-ın təxminən %30-u ən azı bir dəfə reviziya edilmişdir.

Tətbiq müddəti: Təxminən 11 ay.

Sonrakı partiya sürəti: İkinci və üçüncü partiyadakı ümumilikdə on ssenari təxminən dörd–beş ayda işlənmişdir; mənbə bunun təkrarlanan funksiyalar və yenidən istifadə sayəsində baş verdiyini, başqa layihələrdə eyni sürətin zəmanətli olmadığını bildirir.

Riyazi formula vəziyyəti: Mənbədə tədqiqat nəticəsi yaradan mərkəzi riyazi tənlik yoxdur. SOS-un FR yaratmaqda istifadə etdiyi struktur riyazi formula deyil, məhdudlaşdırılmış təbii dil qrammatikasıdır.

Statistik nəticəçıxarma: Tədqiqat metodlararası randomizə edilmiş və ya nəzarətli kəmiyyət performans eksperimenti deyil; əsas qiymətləndirmə keyfiyyət hal analizi, artefakt izləmə, descriptive counts, FGCS və thematic analysis üzərindən aparılmışdır.

IRB: UNIST Institutional Review Board; review exemption, IRB Exemption No. UNISTIRB-26-005-C.

Razılıq: Minimal risk səbəbilə yazılı informed consent sənədləşməsindən imtina verilmişdir. Məlumatlar de-identified şəkildə analiz və hesabatlandırılmışdır.

Məlumat əlçatanlığı: Məlumat dəstləri sənaye əməkdaşlığına aid kimliksizləşdirilmiş, lakin potensial həssas layihə materialları və insan iştirakçılarını əhatə edən keyfiyyət məlumatları səbəbilə ictimaiyyətə açıq deyil. Altı SOS addımı üçün ətraflı tətbiq təlimatları və şablonlar ehtiva edən practitioner manual məsul müəllifdən sorğu əsasında əldə edilə bilər.

Müəllif töhfələri — Ulugbek Vahobjon Ugli Ismatullaev: Conceptualization; Methodology; Investigation; Data curation; Formal analysis; Validation; Visualization; Writing – original draft; Writing – review & editing.

Müəllif töhfələri — KwanMyung Kim: Conceptualization; Methodology; Validation; Supervision; Project administration; Funding acquisition; Writing – review & editing.

Maliyyələşdirmə: Open Access funding UNIST tərəfindən təmin edilmiş və təşkil olunmuşdur. Tədqiqat Republic of Korea Ministry of Trade, Industry and Energy (MOTIE) tərəfindən maliyyələşdirilən Technology Innovation Program çərçivəsində 20015056 və RS-2025-04752997 nömrəli layihələrlə dəstəklənmişdir.

Maraqlar toqquşması: Müəlliflər competing interests olmadığını bildirmişlər.

Əsas metodoloji sərhəd: Tək uzunmüddətli embodied-robotics halı transfer/ümumiləşdirilə bilmə iddiasını məhdudlaşdırır.

Şərh qərəzi sərhədi: Birinci müəllif participant-observer rolundadır və keyfiyyət analizinin əsas məsuliyyətini daşıyır; risk artefakt triangulation, co-author review və sistemli sənədləşdirmə ilə azaldılmışdır.

Avtomatlaşdırma sərhədi: SOS texniki hədəf dəyərlərini müstəqil yaratmır və mühəndislik mühakiməsini əvəz etmir.

Üstünlük sərhədi: Tədqiqat SOS-un alternativ metodlardan üstün olduğunu və ya downstream məhsul performansını artırdığını göstərməyi məqsəd qoymayıb və belə müqayisə aparmayıb.

Tətbiq oluna bilmə sərhədi: Metod erkən sistem müəyyənləşdirmə mərhələsində qarşılıqlı təsir baxımından intensiv və kontekst baxımından zəngin məhsullarda xüsusilə uyğun görünür. Çox formal systems engineering, ağır regulatory compliance və ya yalnız rəqəmsal service logic ilə idarə olunan sahələrdə fərqli və ya uyğunlaşdırılmış təsvir strukturları lazım ola bilər.