Senaryo Odaklı Spesifikasyon (Scenario-Oriented Specification, SOS), kullanıcı deneyimi senaryolarındaki eylem, hedef ve bağlam bilgisini izlenebilir ara temsiller üzerinden fonksiyonel gereksinimlere, sistem bileşenlerine ve ölçülebilir mühendislik spesifikasyonlarına dönüştürmek için geliştirilmiş reçeteli bir tasarım yöntemidir. Çalışma, kullanıcı deneyimi araştırmasının bağlamsal ve anlatısal çıktılarıyla mühendisliğin ölçülebilir ve doğrulanabilir teknik temsilleri arasındaki kopukluğu experience–specification gap yani deneyim–spesifikasyon boşluğu olarak kavramsallaştırmaktadır. SOS bu boşluğu doğrudan senaryodan nihai teknik değere sıçrayarak değil, birbirine kalıcı tanımlayıcılarla bağlanan ara temsiller oluşturarak ele almaktadır.

SOS'un başlangıçtaki çekirdeği beş adımdır: senaryo öğelerinin belirlenmesi, etkileşim dizilerinin kurulması, fonksiyonel gereksinimlerin türetilmesi, bileşenlerin seçilmesi ve mühendislik spesifikasyonlarının belirlenmesi. Yöntem üç tasarım ilkesine dayanır: eylem-temelli izlenebilirlik, bağlamın ileri taşınması ve eşzamanlı çoklu-görünüm temsilleri. Bu ilkeler başlangıçta beş meta-gereksinimi karşılamak üzere tasarlanmıştır: çift yönlü izlenebilirlik, bağlamsal sadakat, mühendislik iş akışıyla uyumluluk, tekrarlanabilir dönüşüm ve ortak temsil alanı.

Yöntem, Güney Kore'de 2021–2025 arasında yürütülen ve yaşlı yetişkinlerin gündelik, güvenlik ve sosyal etkileşim ihtiyaçlarına yönelik Lemmy adlı companion-care robot geliştirme projesinde doğal endüstriyel koşullar altında değerlendirilmiştir. Senaryo geliştirme süreci ilk olarak 18 keşif senaryosu üretmiş, tasarım çalıştaylarında bu sayı 25 aday senaryoya çıkarılmış ve 12 yaşlı yetişkinin evlerine yapılan saha ziyaretleri, köpük maketler ve yüksek doğruluklu prototiplerle rol yapma çalışmaları sonrasında 15 doğrulanmış senaryoya indirgenmiştir.

SOS uygulamasında bu 15 senaryodan toplam 244 kodlanmış senaryo öğesi çıkarılmıştır. Bunların 138'i etkileşim öğesidir: 59 kullanıcı eylemi ve 79 ürün eylemi. Kalan 106 öğe kullanıcı, hedef, ortam, araç ve olay gibi bağlamsal öğelerdir. Bu bilgiler 104 etkileşim dizisine dönüştürülmüş; bunlardan 144 fonksiyonel gereksinim oluşturulmuş; gereksinimler 100 bileşene eşlenmiş ve yaklaşık 312 mühendislik spesifikasyonu üretilmiştir.

144 fonksiyonel gereksinim harmonizasyon sırasında 69 tekrarlanan veya temel gereksinim ile 75 senaryoya özgü gereksinime ayrılmıştır. İlk bileşen seçimlerinde 72 senaryo-kökenli bileşen oluşmuş, disiplinlerarası fizibilite ve entegrasyon incelemeleri sonunda bunlar 65'e konsolide edilmiştir. Senaryolarda doğrudan görünmeyen fakat sistem bütünlüğü için gerekli elektronik, montaj ve benzeri altyapıları temsil eden 35 mühendislik-kökenli bileşenin eklenmesiyle toplam bileşen sayısı 100'e ulaşmıştır.

Endüstriyel uygulama, SOS'un ilk beş adımının bütün senaryolarda uygulanabildiğini ancak fiziksel bir robot gibi embodied bir üründe semantik spesifikasyonun tek başına yeterli olmadığını da göstermiştir. Bileşenlerin ürün gövdesine gerçekten sığıp sığmadığı, sensörlerin doğru kapsama sağlayıp sağlamadığı, montaj açıklıkları ve güvenlik–stil çatışmaları gibi sorunlar nedeniyle mekânsal entegrasyon (spatial integration) adlı altıncı adım uygulama sırasında ortaya çıkmıştır. Bu altıncı adım başlangıçta tanımlanmış SOS çekirdeğinin parçası değil, vaka sırasında ortaya çıkan yöntemsel bir uzantıdır.

Çalışmanın sonuçları SOS'un tek vakada uygulanabilir ve yapısal olarak tutarlı olduğunu desteklemektedir; ancak yöntem rakip tasarım yöntemleriyle kontrollü biçimde karşılaştırılmamıştır. Bu nedenle kaynak SOS'un QFD, use-case yöntemleri veya başka gereksinim mühendisliği yöntemlerinden üstün olduğunu kanıtlamaz. Aynı şekilde SOS, mühendislik hedef değerlerini otomatik olarak hesaplamaz: ölçülebilir parametrelerin gerçek hedefleri için benchmark verileri, üretici/tedarikçi bilgileri, referans spesifikasyonlar, fiziksel testler ve mühendislik yargısı gerekmektedir.

Çalışmanın en önemli sınırlılığı, doğrulamanın tek bir uzunlamasına embodied-robotics projesine dayanmasıdır. Birinci yazarın participant-observer olarak yöntemin uygulanmasına katılması da yorum yanlılığı potansiyeli yaratmaktadır; araştırmacılar bunu proje dokümanları, görüşmeler, ortak-yazar incelemesi ve farklı veri kaynaklarını üçgenleyerek azaltmaya çalışmıştır. Dolayısıyla bulguların farklı ürün sınıflarına, yüksek derecede düzenlenmiş mühendislik alanlarına veya yalnızca dijital hizmet projelerine doğrudan genellenmesi uygun değildir.

Senaryo Odaklı Spesifikasyon (SOS) Nedir ve Hangi Problemi Çözer?

Senaryo Odaklı Spesifikasyon, kullanıcı senaryolarındaki deneyimsel ve bağlamsal bilgiyi kaybetmeden bu bilgiyi aşamalı olarak fonksiyonel gereksinimlere, teknik bileşenlere ve ölçülebilir mühendislik spesifikasyonlarına dönüştüren izlenebilir bir tasarım yöntemidir; temel problem, senaryonun “kullanıcı hangi durumda ne yaşıyor ve ürün nasıl davranmalı?” dilinden mühendisliğin “hangi bileşen hangi ölçülebilir hedefi sağlamalı?” diline geçerken bağlam ve gerekçenin kaybolmasıdır.

UX senaryosu ile mühendislik spesifikasyonu neden aynı temsil değildir?

Kullanıcı deneyimi senaryoları zaman içinde gerçekleşen etkileşimleri, kullanıcının amacını, durumunu, çevresel koşulları, istisnai olayları ve ürün davranışını anlatısal biçimde birlikte taşır. Mühendislik spesifikasyonları ise sistemin ayrıştırılabilir, bileşenlere atanabilir, ölçülebilir ve doğrulanabilir teknik taahhütlere dönüştürülmesini gerektirir. Örneğin “yaşlı kullanıcı gece banyoya giderken robot düşmeyi kaçırmamalıdır” biçimindeki bağlamsal beklenti, mühendislik açısından sensör kapsaması, düşük ışık performansı, konumlandırma, algılama mantığı ve doğrulama koşulları gibi ayrı teknik problemlere dönüşebilir.

Deneyimsel bilgi neden doğrudan bir parametre tablosuna çevrilemez?

Çünkü senaryo içindeki bir kullanıcı ihtiyacı çoğu zaman tek bir sabit özellik değildir. Aynı ürün davranışı kullanıcının yaşı, fiziksel kapasitesi, ortam gürültüsü, günün saati, mevcut araçlar, acil durumlar ve önceki etkileşimler gibi bağlama bağlı olabilir. Bu bilgileri doğrudan tek bir “gereksinim listesine” indirgemek, teknik değerin neden gerekli olduğunu görünmez hale getirebilir.

Deneyim–Spesifikasyon Boşluğu Nedir?

Deneyim–spesifikasyon boşluğu, kullanıcı deneyimi senaryolarındaki bağlamsal etkileşim mantığı ile mühendislikte kullanılan formel ve ölçülebilir teknik temsiller arasında oluşan temsil süreksizliğidir; çalışma bu sorunu yalnız disiplinler arası iletişim eksikliği olarak değil, farklı bilgi biçimlerinin farklı analitik birimler ve akıl yürütme biçimleri kullanmasından kaynaklanan bir temsil problemi olarak ele almaktadır.

“Representational non-isomorphism” ne anlama geliyor?

Çalışmanın teorik katkılarından biri, senaryo ile mühendislik spesifikasyonunu aynı bilginin yalnız farklı yazılışları olarak görmemesidir. Senaryolar kullanıcı deneyimini zaman, bağlam ve etkileşim yörüngesi içinde düzenler; spesifikasyonlar ise teknik taahhütleri bileşen, parametre, hedef değer ve doğrulama mantığı çevresinde düzenler. Bu nedenle iki temsil arasında birebir ve kayıpsız doğrudan eşleme varsaymak güvenilir değildir. SOS'un ara temsilleri bu nedenle gereklidir.

QFD ve use case yaklaşımlarından hangi açıdan ayrılıyor?

Kaynak, Quality Function Deployment'ın müşteri ihtiyaçlarını mühendislik karakteristiklerine eşlemede güçlü olduğunu ancak ihtiyaçları çoğunlukla daha durağan özellikler olarak ele aldığını; bağlama bağlı ve zamana yayılan etkileşimlerin matris temsillerine her zaman iyi oturmadığını belirtmektedir. Use case yaklaşımları aktör–hedef–sistem davranışını biçimlendirir ancak bağlamsal niteleyicilerin ölçülebilir mühendislik spesifikasyonlarına nasıl taşınacağı her zaman açık değildir. Bu teorik karşılaştırma, SOS'un bu yöntemlerden deneysel olarak üstün olduğunun kanıtı değildir.

SOS'un beş başlangıç meta-gereksinimi

SOS'un üç tasarım ilkesi

UA ve PA nedir?

UA (User Action), kullanıcının gerçekleştirdiği eylemdir. PA (Product Action), ürünün bu kullanıcı eylemine karşılık gerçekleştirdiği veya gerçekleştirmesi beklenen eylemdir. SOS, büyük ve soyut senaryo cümleleri yerine bu UA–PA çiftlerini temel dönüşüm birimi olarak kullanır.

Bağlamsal öğeler hangileridir?

Kaynak deneyim-merkezli senaryonun altı genel unsurunu Actions, User(s), Goals, Settings, Tools ve Events olarak ele alır. SOS'un Step 1 kodlamasında Actions ayrıca kullanıcı eylemleri (UA) ve ürün eylemleri (PA) olarak ayrıldığı için pratik çalışma tablosunda UA, PA, User, Goal, Setting, Tool ve Event olmak üzere yedi kod türü görülebilir.

Kalıcı tanımlayıcı neden önemlidir?

Her önemli öğeye UA1, PA1, U1, G1 veya SET1 gibi kalıcı kimlikler verilmesi, teknik kararlar değişse bile bilgi zincirinin kopmamasını amaçlar. Böylece örneğin bir sensörün değiştirilmesi durumunda “hangi fonksiyonel gereksinim için seçilmişti, o gereksinim hangi ürün eyleminden, o ürün eylemi hangi kullanıcı senaryosundan gelmişti?” soruları geriye doğru izlenebilir.

SOS Kullanıcı Senaryosunu Mühendislik Spesifikasyonuna Nasıl Dönüştürür?

SOS dönüşümü beş çekirdek adımla gerçekleştirir: senaryodaki yapılandırılmış öğeler çıkarılır, UA–PA çiftlerinden sıralı etkileşim dizileri oluşturulur, ürün eylemleri bağlamı koruyan çözümden bağımsız fonksiyonel gereksinimlere çevrilir, bu gereksinimler uygulanabilir bileşenlere atanır ve son olarak her bileşen için ölçülebilir parametreler ile hedefler tanımlanır; embodied ürün vakasında bu zincire fiziksel uygulanabilirliği sınayan altıncı mekânsal entegrasyon adımı eklenmiştir.

Adım 1: Senaryo öğelerini belirleme

Katılımcılar önce senaryonun bütününü okuyarak anlatı akışı ve etkileşim bağlamı konusunda ortak anlayış oluşturur. Daha sonra kullanıcı eylemleri, ürün eylemleri, kullanıcı özellikleri, hedefler, ortam/setting bilgileri, araçlar ve olaylar ayrı öğeler halinde çıkarılır.

Kaynak üç kodlama kuralı tanımlar. Separation, aynı cümlede kullanıcı niyeti ve ürün cevabı bulunuyorsa bunları ayrı UA ve PA olarak böler. Granularity, öğeyi bağımsız davranış anlamını kaybetmeyecek en küçük uygun düzeyde kodlar. Identifier assignment ise her öğeye UA1, PA1 veya SET1 gibi kalıcı bir kimlik verir.

Bu adımın çıktısı Scenario Element Table'dır. Senaryo bu yapısal bilgileri yeterince içermiyorsa kaynak, senaryonun etkileşim dizilerine ayrılmadan önce geliştirilmesi gerekebileceğini belirtmektedir.

Adım 2: Etkileşim dizilerini oluşturma

Çıkarılan UA ve PA'lar eşleştirilir ve zaman sırasına konur. Kullanıcı özellikleri, hedefler, setting, tools ve events bu dizinin dışına atılmaz; sonraki teknik kararları etkileyen yapılandırılmış niteleyiciler olarak kalır.

Örneğin bir kullanıcının “akşam 19.00'a kadar hızlı yemek hazırlamak istemesi” yalnız “yemek öner” fonksiyonuna indirgenmez. Zaman baskısı ürün davranışını değiştirir ve daha kısa hazırlama süresine sahip seçeneklerin önceliklendirilmesi gibi teknik/fonksiyonel sonuçlar doğurabilir.

Uygulamada ortaya çıkan “inferred action” nedir?

Inferred action, senaryoda açıkça yazılmamasına rağmen bir sonraki ürün davranışının teknik olarak gerçekleşebilmesi için arada bulunması gereken sistem işleminin görünür hale getirilmesidir. Örneğin senaryoda yalnız “robot çocuklara sesli mesaj yollar” deniyorsa olayın algılanması, yorumlanması ve mesajın oluşturulması gibi gerekli ara süreçler açıkça yazılmamış olabilir. Ekip bu işlemleri eklemiş ancak her eklemeyi köken aldığı senaryo öğesine bağlayarak izlenebilirliği korumuştur.

“Void action” nedir?

Void action, kullanıcı açısından arzu edilen fakat projenin mevcut teknoloji, maliyet veya uygulanabilirlik sınırları içinde gerçekleştirilemeyen ürün davranışıdır. SOS bunu senaryodan silmez; “şu anda desteklenmiyor” statüsüyle korur. Böylece teknik olarak uygulanamayan bir davranışın arkasındaki kullanıcı niyeti gelecekte yeniden değerlendirilebilir.

Etkileşim biçimi neden ayrıca açıklığa kavuşturuldu?

Senaryolarda “kullanıcı robota sorar” gibi ifadeler ses, mobil uygulama veya fiziksel arayüzden hangisinin kullanıldığını açıklamayabilir. Uygulama sırasında ekip, kanıt varsa etkileşim modalitesini açıklaştırmış; belirsizlik devam ediyorsa birden fazla olası modaliteyi kaydetmiştir. Bu işlem sonraki sensör, arayüz ve bileşen seçimlerinin hayalî bir varsayıma dayanmasını azaltmıştır.

Adım 3: Fonksiyonel gereksinimleri türetme

Her UA–PA çiftinin en az bir fonksiyonel gereksinim üretmesi beklenir. Fonksiyonel gereksinim doğrudan belirli bir teknolojiyi seçmek yerine, ürünün gerçekleştirmesi gereken yeteneği tanımlar.

SOS'un kısıtlı FR cümle mantığı: Ürün, belirli bir ürün eylemini mümkün kılmak amacıyla gerekli işlevi; kullanıcı özellikleri, hedefler, ortam, araçlar veya olaylar gibi ilgili bağlam koşulları altında ya da bunlara dayanarak gerçekleştirmelidir.

Bu yapı bir matematiksel formül değildir. Kaynağın standartlaştırılmış gereksinim yazma grameridir. Amaç, “ürün ses tanıma yapmalı” gibi bağlamsız bir gereksinim yerine örneğin gürültülü mutfak ortamında yemek önerisi sunabilmek için kullanıcı ses komutunu güvenilir biçimde tanıma gibi neden–işlev ilişkisini korumaktır.

Bir PA birden fazla sorumluluk veya doğrulama koşulu içeriyorsa FR'ler bölünebilir. Aynı davranışı ifade eden FR'ler ise özgün iz bağlantıları korunarak birleştirilebilir. Birden fazla senaryoda tekrar eden gereksinimler harmonizasyonla basic FR, yalnız belirli senaryonun özel davranışını koruyanlar specific FR olarak ayrılır.

Adım 4: Bileşenleri seçme

Fonksiyonel gereksinimler donanım, yazılım veya arayüz bileşenlerine eşlenir. Seçim yalnız fonksiyon adına göre yapılmaz; teknoloji olgunluğu, performans sınırları, maliyet ve üretilebilirlik gibi fizibilite ölçütleri de dikkate alınır.

Bir FR birden fazla bileşen gerektiriyorsa kritik dönüşümü gerçekleştiren bileşene birincil sahiplik verilebilir ve diğer bağımlılıklar kaydedilir. Bu ilişkiler Function–Component Matrix içinde tutulur.

İlk çalıştaylarda 72 senaryo-kökenli bileşen belirlenmiştir. Sonraki fizibilite ve entegrasyon değerlendirmeleriyle bazı bileşenler ertelenmiş, değiştirilmiş, sadeleştirilmiş veya birleştirilmiş ve sayı 65'e düşmüştür. Buna ek olarak senaryolarda doğrudan görünmeyen fakat ürünün çalışması için gerekli iç elektronik, yapısal montajlar ve benzeri 35 mühendislik-kökenli bileşen eklenmiş; toplam 100 bileşene ulaşılmıştır.

Adım 5: Mühendislik spesifikasyonlarını belirleme

Her seçilmiş bileşen için parametre adı, birim, hedef değer ve ölçüm/doğrulama varsayımı tanımlanır. Kaynak, her bileşenin en az bir ölçülebilir parametre taşımasını hedefler. Bağlamsal kısıt nicelleştirilebiliyorsa açık eşik değerine dönüştürülür; henüz güvenilir nicel değer yoksa doğrulama varsayımı veya daha sonra belirlenecek bir öğe olarak kaydedilir.

TBD ne demektir?

TBD (To Be Determined), değerin kaynağı henüz yeterli olmadığında rastgele hedef sayı uydurmak yerine “daha sonra belirlenmeli” olarak işaretlenmesidir. Kaynakta bu yaklaşım bir eksiklik gizleme yöntemi değil, belirsizliği görünür biçimde yönetme aracı olarak kullanılmaktadır.

SOS Otomatik Gereksinim veya Mühendislik Hedef Değeri Üreten Bir Sistem midir?

Hayır; SOS senaryodan spesifikasyona dönüşümün bilgi yapısını ve izlenebilirliğini düzenler, ancak mikrofon hassasiyeti, gecikme, güç tüketimi veya geometrik sınırlar gibi gerçek teknik hedef değerleri kendi başına hesaplamaz; kaynakta bu değerlerin mühendislik tahmini, benchmark, veri sayfaları, tedarikçi bilgileri, referans sistemler ve sonraki PoC testleriyle belirlenmesi gerektiği açıkça belirtilmektedir.

Bu ayrım yöntemin doğru anlaşılması için kritiktir. SOS “kullanıcı şu ihtiyacı söyledi, o halde mikrofon hassasiyeti kesin −35 dB olmalıdır” biçiminde otomatik bir fiziksel hesap yapmaz. Şekil 8'de verilen spesifikasyon örnekleri yöntemin çalışma biçimini göstermek içindir; kaynak bunları bütün ürünlere uygulanabilir evrensel hedefler olarak sunmaz.

Çözüm bağımsızlığı neden önemli?

Fonksiyonel gereksinim teknik çözümden önce tanımlandığında aynı kullanıcı amacı farklı teknolojilerle gerçekleştirilebilir. Kaynaktaki örneklerden biri, yüksek çözünürlüklü ekranın maliyet ve enerji gerekçesiyle daha basit LED matrise dönüştürülebilmesi; buna rağmen “sistem durumunu kullanıcıya iletme” işlevsel amacının korunabilmesidir.

Ancak kaynak çözüm bağımsızlığının yalnız yöntemin iç kuralı olmadığını da vurgular. Sıkı zaman takvimi veya erken maliyet baskısı olan organizasyonlarda ekipler mevcut teknolojiye çok erken bağlanabilir. Böyle bir erken yakınsama SOS'un hedeflediği “önce işlevsel niyet, sonra teknik çözüm” ayrımını zayıflatabilir.

Mekânsal entegrasyon neden ortaya çıktı?

İlk beş adım sistem davranışını ve ölçülebilir teknik hedefleri semantik olarak bağlasa da robot gibi fiziksel bir üründe bileşenin gerçekten gövdeye sığıp sığmadığı, kablo ve montaj açıklıklarının yeterli olup olmadığı, sensörün kullanıcının hareket yolunu görüp görmediği veya güvenlik elemanının yanlışlıkla etkinleşip etkinleşmeyeceği yalnız tablo üzerinden belirlenememiştir.

Mekânsal Entegrasyon Neden Altıncı SOS Adımı Olarak Ortaya Çıktı?

Mekânsal entegrasyon, ilk beş SOS adımının mantıksal ve semantik izlenebilirliği sağlamasına rağmen fiziksel robotta bileşen yerleşimi, montaj açıklığı, sensör kapsaması, etkileşim erişilebilirliği ve stil–güvenlik–mühendislik çatışmalarının ayrıca kontrol edilmesi gerektiği için uygulama sırasında ortaya çıkan embodied-feasibility uzantısıdır; kaynak bunu bütün ürünlere zorunlu evrensel altıncı adım olarak değil, mevcut embodied-product vakasında ortaya çıkan gerekli bir yöntemsel genişleme olarak yorumlamaktadır.

Çalıştaylarda ekipler bileşenleri ortak ürün konsepti üzerinde birlikte konumlandırmıştır. Böylece sensör engellenmesi, muhafaza hacminin yetersizliği, mikrofon–hoparlör akustik etkileşimi ve montaj erişimi gibi daha önceki analitik temsillerde görünmeyen çatışmalar ortaya çıkarılmıştır.

Örneğin mekanik acil durdurma düğmesinin sistem hatalarında kolay erişilebilir olması gerekirken, robotun sevilmesi, dokunulması ve ses ayarı gibi yakın kullanıcı etkileşimlerinde yanlışlıkla basılmaması da gerekiyordu. Disiplinlerarası değerlendirme sonucunda düğmenin arka-alt bölgede konumlandırılması önerilmiştir. Bu örnek bir evrensel acil-stop konumlandırma kuralı değil, senaryo bağlamı ile güvenlik/mühendislik kısıtlarının birlikte değerlendirilmesine ilişkin vaka bulgusudur.

Yöntemin endüstriyel doğrulama ortamı

Çalışma, Güney Kore'deki Lemmy companion-care robot projesinin aktif geliştirme sürecine gömülü uzunlamasına doğal vaka tasarımı kullanmıştır. Proje 2021–2025 arasında bir tasarım firması, üretim ortağı ve kamu araştırma kurumunu içeren çok ortaklı bir geliştirme girişimidir.

Senaryolar nasıl oluşturuldu ve doğrulandı?

2021 yılında 12 tasarımcı ve UX araştırmacısı derinlemesine görüşmeler, bağlamsal araştırmalar, odak grupları, literatür incelemesi ve benchmarking kullanarak altı aylık çalışma yürütmüştür. İlk olarak 18 keşif senaryosu, ardından tasarım çalıştaylarıyla 25 aday senaryo oluşturulmuştur.

Senaryolar 12 yaşlı yetişkinin evlerine yapılan saha ziyaretlerinde, köpük maketler ve yüksek doğruluklu prototiplerle rol yapma yoluyla değerlendirilmiştir. Katılımcı geri bildirimleri ve iç tasarım incelemeleriyle örtüşen anlatılar birleştirilmiş, tekrarlar çıkarılmış ve çelişkili varsayımlar çözülerek 15 doğrulanmış senaryo elde edilmiştir.

Bu senaryolar üç persona çevresinde düzenlenmiştir. SOS uygulamasından önce anlatılar; kullanıcı eylemi, ürün eylemi, kullanıcı profili, hedef, bağlamsal niteleyiciler, araçlar ve olaylar açık olacak şekilde tutarlı bir yapıya getirilmiştir. Araştırmacılar bunun senaryonun özgün niyetini değiştirmeden yapıldığını belirtmektedir.

Pilot ve tam uygulama

Önce tek bir temsilî senaryo uçtan uca pilot olarak kullanılmış; terminoloji, çalışma sözleşmeleri, ayrıştırma düzeyi ve şablonlar kararlı hale getirildikten sonra yöntem kalan senaryolara uygulanmıştır. Çalışma fiziksel beyaz tahtadan gerçek zamanlı ortak düzenlemeyi ve kalıcı dokümantasyonu destekleyen Miro çalışma alanına geçmiştir.

Çekirdek uygulama ekibi insan faktörleri, endüstri mühendisliği, endüstriyel tasarım, makine mühendisliği, UX tasarımı ve işletme geçmişine sahip altı araştırmacıdan oluşmuştur. Ekibi tasarım metodolojisi ve ürün geliştirmede 25 yıllık deneyimi olan kıdemli ürün tasarımcısı denetlemiştir.

Ekip ayrıca elektrik, mekanik ve yazılım mühendisleri ile iş uzmanlarını içeren 12 alan uzmanıyla çalışmıştır. Bu kişiler fizibilite değerlendirmesi, teknik bileşen seçimi ve spesifikasyon geliştirme sırasında katkı vermiştir.

Empirik doğrulamanın dört boyutu

Yapısal doğrulama neyi değerlendirdi?

Empirik doğrulama “yöntem kullanım sırasında ne oldu?” sorusuna odaklanırken yapısal doğrulama, üç tasarım ilkesinin hedeflenen meta-gereksinimleri gerçekten operasyonelleştirip operasyonelleştirmediğini incelemiştir. MR1–MR5 için gözlenebilir göstergeler tanımlanmış ve gerçek proje artefaktları üzerindeki davranış incelenmiştir.

Veri kaynakları

Birincil empirik materyal SOS sırasında üretilen Scenario Element Table, Interaction Sequence Map, FR listeleri, Function–Component Matrix ve Specification Sheet gibi proje dokümanlarıdır. Bu belgeler iz yolları, dönüşüm kararları ve parametre gerekçeleri için doğrudan kanıt sağlamıştır.

İkinci kaynak participant observation'dır. Birinci yazar SOS uygulamasına participant-observer olarak katılmış; yöntemden sapmaları, açıklama gerektiren noktaları, iterasyonları ve katılımcıların müzakerelerini saha notları ve toplantı kayıtlarıyla belgelemiştir. Bu notlar tek araştırmacı yanlılığını azaltmak amacıyla ortak yazarlarla gözden geçirilmiştir.

Üçüncü kaynak katılımcı yansımaları ve yarı yapılandırılmış görüşmelerdir. SOS uygulamasına katılan 12 uzmanla kullanım sırasında ve sonrasında görüşmeler yapılmış; kullanılabilirlik, karşılaşılan zorluklar ve spesifikasyon kararlarının gerekçeleri incelenmiştir.

Framework-Guided Content Structuring (FGCS) nasıl çalıştı?

FGCS, SOS uygulamasında bilginin adımlar arasında nasıl taşındığını yeniden kurmak için kullanılan ve framework analysis ile nitel içerik analizini birleştiren analitik yöntemdir. SOS prosedürü analitik iskelet olarak kullanılmıştır.

1. Artefaktları adımlara göre düzenleme: Her senaryonun çıktıları SOS adımlarına göre kronolojik olarak gruplanmıştır.
2. Öğe akışlarını izleme: Özellikle UA ve PA'ların etkileşim dizileri, FR'ler, bileşenler ve spesifikasyonlar boyunca korunup korunmadığı kaydedilmiştir.
3. Sapma ve uyarlamaları işaretleme: Atlanan veya yeniden sıralanan adımlar, ek alt adımlar ve yorum değişiklikleri belgelenmiştir.
4. Senaryolar arası örüntüleri sentezleme: Tekrarlanan uygulamalar, ortak zorluklar ve kararlı uyarlamalar 15 senaryo arasında karşılaştırılmıştır.

Tematik analiz nasıl yapıldı?

Katılımcıların SOS'u nasıl uyguladığını anlamak için altı aşamalı tematik analiz kullanılmış ve birinci/ikinci çevrim kodlamayla desteklenmiştir. Yaklaşım hibrit tümdengelimsel–tümevarımsaldır: önceden tanımlanmış dört doğrulama boyutu tümdengelimsel tema çerçevesini sağlamış, uygulamada beklenmedik biçimde ortaya çıkan inferred action, void action ve spatial integration gibi örüntüler tümevarımsal olarak eklenmiştir.

Altı aşama; veriye aşinalık kazanma, ilk kodlama, yeniden kodlama, alt-temaları arama, tema gözden geçirme/tanımlama ve rapor üretimidir. FGCS “hangi artefakt ne zaman ve nasıl dönüştü?” sorusuna daha yapısal yanıt verirken tematik analiz “katılımcılar bunu nasıl ve neden bu şekilde uyguladı?” sorusunu yorumlamaya yardımcı olmuştur.

Çalışmanın Yöntemi ve Bulguları

Araştırma tasarımının teknik özeti

15 senaryonun nicel dönüşüm özeti

Pratik uygulanabilirlik sonucu

Beş öngörülen SOS adımı bütün 15 senaryoda tamamlanmıştır. Fizibilite incelemeleri zaman zaman önceki adımlara geri dönülmesini gerektirmiş, ancak kalıcı iz bağlantıları korunmuştur. Bir adımın çıktısı genel olarak sonraki adım için kullanılabilir girdi olmuş ve yalnız zaman zaman açıklama veya düzeltme gerekmiştir.

Uygulama sırasında üç önemli uyarlama ortaya çıkmıştır: eksik ara sistem işlemlerini görünür hale getiren inferred actions, teknik olarak şimdilik mümkün olmayan fakat kullanıcı niyetini koruyan void actions ve embodied ürünün fiziksel gerçekliğini değerlendiren spatial integration.

Çıktı kalitesi sonucu

Kullanıcı-merkezlilik yalnız “senaryo kullanıldığı” için değil, teknik spesifikasyonların ilgili kullanıcı eylemi, hedefi ve ortamına açık iz bağlantıları taşımasıyla korunmuştur. Örneğin sensör yerleşimleri yalnız soyut kapsama değerlerine değil, kullanıcının gece ev içindeki gerçek hareket yolları gibi senaryo koşullarına göre yeniden gözden geçirilmiştir.

Çözüm bağımsızlığı, ürünün gerçekleştirmesi gereken işlev ile bunu gerçekleştirecek teknik bileşeni farklı aşamalarda ele alarak korunmaya çalışılmıştır. Bununla birlikte çalışma, çözüm bağımsızlığının organizasyonel zaman/maliyet baskısından etkilenebileceğini de göstermiştir.

Fizibilite açısından bazı başlangıç çözümleri değiştirilmiştir. Kaynak örneklerinde kablosuz şarj yerine akıllı telefon şarj hatırlatıcısının değerlendirilmesi ve belirli edge-computing seçeneklerinin güç/maliyet nedeniyle daha düşük güçlü çözümlerle değiştirilmesi yer almaktadır. Bu değişikliklerde senaryonun özgün fonksiyonel amacı iz bağlantısıyla korunmuştur.

Spesifikasyonların ne kadarı tamamlandı?

Spesifikasyon geliştirme sonunda senaryo-kökenli bileşenlerin yaklaşık %80'i tamamen parametreleştirilmiştir. Kalan bölüm “flagged for validation” olarak işaretlenmiş ve sonraki PoC doğrulaması gerektiren parametreler açıkça görünür bırakılmıştır.

Bu %80 değeri “ürünün %80'i tamamlandı” anlamına gelmez. Kaynak yalnız senaryo-kökenli bileşenlerin mühendislik spesifikasyonları açısından parametreleştirilme durumunu ifade etmektedir. Regülasyon, üretim, güvenilirlik sertifikasyonu veya ürünün pazara hazır olması için bir tamamlanma yüzdesi değildir.

Süreç kalitesi sonucu

Paylaşımlı ara artefaktlar disiplinlerarası tartışmaları yalnız kişisel görüş alışverişinden çıkarıp senaryo, etkileşim, FR ve bileşen bağlantıları üzerinden daha izlenebilir müzakereye dönüştürmüştür. Miro ortamı senaryolar, diziler, gereksinimler ve spesifikasyonların aynı görsel ortamda izlenmesini kolaylaştırmıştır.

Liderlik her adımda aynı disiplin tarafından yürütülmemiştir. Erken senaryo yorumlama ve rutin haritalamada UX/tasarım ekipleri daha belirgin rol oynarken, FR türetme ortak bir köprü işlevi görmüş; bileşen ve spesifikasyon aşamalarında mühendislik liderliği artmış; spatial integration aşamasında tasarım ve mühendislik yeniden ortak liderliğe dönmüştür. Kaynak bunun SOS'un zorunlu rol dağılımı olmadığını, mevcut vaka ekibinde gözlenen örüntü olduğunu özellikle belirtmektedir.

Ölçeklenebilirlik sorunu

Senaryo, FR, bileşen ve parametre sayısı arttıkça çoktan-çoğa bağlantı ağı yoğunlaşmış ve manuel iz yönetimi kırılgan hale gelmiştir. Kaynak bu noktada görsel şeffaflığın yararının, yoğun iz ağını elle yönetmenin bilişsel maliyeti tarafından aşılabileceği bir ölçek eşiği gözlemlemiştir.

Dosyaların Miro'dan elektronik tablolar, gereksinim listeleri ve başka dokümantasyon ortamlarına taşınması ayrıca bağlantı kırılması ve sürüm ayrışması riski doğurmuştur. Ekip bu nedenle bazı artefaktları canlı ortak çalışma alanında, daha kararlı artefaktları ise sürüm kontrollü dokümantasyonda tutmuştur.

Süreç verimliliği sonucu

SOS uygulaması yaklaşık 11 aylık dönemde yürütülmüştür. İlk senaryo uçtan uca kalibrasyon vakası olarak kullanılmış ve sonrasında kalan senaryolar üç parti halinde işlenmiştir. İlk partiler terminoloji, ayrıştırma düzeyi ve iz yönetimi henüz oturmadığı için daha yavaş ilerlemiş; tekrar eden fonksiyonlar ve bileşenler oluşunca sonraki senaryolarda yeniden kullanım mümkün olmuştur.

İkinci ve üçüncü parti toplam on senaryoyu kapsamış ve yaklaşık dört ila beş ay içinde tamamlanmıştır. Kaynak bu hızlanmanın senaryolar arasındaki işlevsel tekrar sayesinde ortaya çıktığını belirtmektedir. Az ortaklık içeren projelerde aynı hızlanmanın gerçekleşeceği gösterilmemiştir.

Senaryo-kökenli bileşen spesifikasyonlarının yaklaşık %30'u en az bir kez revize edilmiştir; özellikle maliyet-duyarlı veya teknik olarak zor bileşenlerde değişiklik görülmüştür. Bu oran “SOS %30 hata üretti” anlamına gelmez. Revizyonlar sistem entegrasyonu ve fizibilite değerlendirmesinin parçasıdır.

SOS süreç verimliliğini tek başına garanti etti mi?

Hayır. Kaynak, verimlilik kazanımlarının yalnız yöntemden kaynaklanmadığını açıkça vurgulamaktadır. İzlenebilirliğin işe yaraması ortak dokümantasyon disiplini, artefaktların ortak sahipliği, düzenli çapraz-fonksiyonel toplantılar ve satın alma/üretim ekipleriyle erken koordinasyon gibi organizasyonel koşullara bağlıdır.

Yapısal doğrulama ne gösterdi?

MR1 ve MR4 açısından kalıcı tanımlayıcıların yalnız denetim kaydı olmadığı, fizibilite görüşmelerinde, bileşen değişimlerinde ve spatial integration sırasında aktif akıl yürütme aracı haline geldiği gözlenmiştir.

MR2 bağlamsal sadakat semantik düzeyde sağlanmış, ancak embodied sistemde bağlamın yalnız metinle taşınmasının yetmediği görülmüştür. Etkileşim modalitesi, kullanıcının fiziksel hareket yolu, sensör yerleşimi ve montaj sınırlamaları bağlamsal sadakatin fiziksel boyutunu ortaya çıkarmıştır.

MR3 iş akışı uyumluluğu, mühendislerin SOS artefaktlarını doğrudan üretmesi ve spesifikasyon tablolarının PoC planlama ile satın alma çalışmalarında kullanılabilmesiyle desteklenmiştir.

MR5 ortak temsil alanı da özellikle spatial integration sırasında güçlü görünmüş, fakat bu işlev organizasyonel olarak koşullu kalmıştır. Ortak çalışma disiplini veya tanımlayıcı yönetişimi zayıfsa aynı artefaktların tutarlılığı korunamayabilir.

Uygulamada ortaya çıkan MR6 nedir?

Başlangıç framework'ünde yalnız MR1–MR5 bulunurken vaka sırasında MR6: Traceability scalability, yani izlenebilirliğin ölçeklenebilirliği, ortaya çıkan yapısal gereksinim olarak tanımlanmıştır. Artefakt yoğunluğu arttıkça manuel iz yönetiminin koordinasyon yükü yükselmiş; daha büyük sistemlerde kalıcı kimlikler, görsel bağlantılar ve ortak alanın ötesinde araç-destekli trace management ihtiyacı belirginleşmiştir.

MR6'nın kaynakta “emergent” olması önemlidir. SOS başlangıçta altı meta-gereksinimle tasarlanmamıştır; altıncı gereksinim uygulamanın ölçeklenebilirlik sınırlarından türetilmiştir.

Çalışmanın desteklediği sonuçlar

• SOS, incelenen 15 senaryoluk endüstriyel vaka içinde senaryo–FR–bileşen–spesifikasyon zincirinin izlenebilir biçimde kurulmasını desteklemiştir.
• Kalıcı tanımlayıcılar teknik kararları özgün senaryo bağlamına geri bağlamada aktif araç olarak kullanılmıştır.
• Bağlamın ileri taşınması teknik kararların kullanıcı durumu ve kullanım ortamıyla ilişkisinin görünür kalmasına yardımcı olmuştur.
• Beş çekirdek SOS adımı bütün 15 senaryoda uygulanmıştır.
• Inferred action ve void action uygulamaları eksik veya şu an uygulanamaz davranışların görünür biçimde yönetilmesini sağlamıştır.
• Embodied robot bağlamında spatial integration adlı altıncı bir adım gerekli hale gelmiştir.
• 144 FR'nin harmonizasyonu 69 temel ve 75 senaryoya özgü FR ayrımına yol açmıştır.
• 72 başlangıç senaryo-kökenli bileşen fizibilite incelemeleriyle 65'e konsolide edilmiş ve 35 mühendislik-kökenli bileşenin eklenmesiyle toplam 100 bileşen oluşturulmuştur.
• Senaryo-kökenli bileşenlerin yaklaşık %80'i çalışma sonunda tamamen parametreleştirilmiştir.
• Senaryo-kökenli bileşen spesifikasyonlarının yaklaşık %30'u en az bir kez revize edilmiştir.
• Artan artefakt yoğunluğu manuel iz yönetiminin ölçek sınırını görünür hale getirmiş ve emergent MR6'yı doğurmuştur.

Çalışmanın desteklemediği sonuçlar

• SOS'un QFD, use case veya başka gereksinim/tasarım yöntemlerinden üstün olduğu deneysel olarak gösterilmemiştir.
• SOS'un ürün performansını, güvenilirliğini, maliyetini veya pazara çıkış süresini belirli bir yüzdeyle iyileştirdiği gösterilmemiştir.
• Çalışma randomize veya karşılaştırmalı yöntem deneyi değildir.
• SOS mühendislik hedef değerlerini otomatik hesaplayan bir algoritma veya yapay zekâ sistemi değildir.
• SOS, kötü veya yetersiz hazırlanmış kullanıcı senaryolarını kendiliğinden düzeltmez.
• Spatial integration'ın bütün ürün tiplerinde zorunlu altıncı adım olduğu gösterilmemiştir.
• Tek robot vakasındaki liderlik dağılımı SOS'un zorunlu organizasyon yapısı değildir.
• Yaklaşık %80 parametreleme değeri ürünün %80 tamamlanması veya ürün hazır olma seviyesi anlamına gelmez.
• Yaklaşık %30 revizyon oranı hata oranı değildir.
• İkinci ve üçüncü partide gözlenen hızlanma, bütün projelerde aynı sürede veya oranda süreç kazancı oluşacağını kanıtlamaz.
• SOS düzenleyici uygunluk, üretim sertifikasyonu, güvenilirlik doğrulaması veya fiziksel PoC testlerinin yerini almaz.

Çalışmanın temel güçlü yönleri

Birinci güçlü yön, yöntemin yalnız kavramsal olarak sunulmaması ve aktif bir endüstriyel projede 15 farklı senaryo üzerinden uzunlamasına uygulanmasıdır. Böylece yöntemin teorik adımları kadar uygulama sırasında oluşan bozulmalar, geri dönüşler ve beklenmedik uyarlamalar da gözlenebilmiştir.

İkinci güçlü yön, empirik doğrulama ile yapısal doğrulamanın birlikte kullanılmasıdır. Çalışma yalnız “katılımcılar yöntemi beğendi mi?” sorusuna değil, tasarım ilkelerinin başlangıçta tanımlanan meta-gereksinimleri gerçekten nasıl gerçekleştirdiğine de bakmıştır.

Üçüncü güçlü yön, yalnız nihai spesifikasyon tablolarının değil; senaryo element tabloları, interaction sequence map'leri, FR listeleri, component matrix'leri, specification sheet'leri, gözlem notları ve uzman görüşmelerinin birlikte değerlendirilmesidir.

Dördüncü güçlü yön, yöntem başarısını yalnız kusursuz uygulamayla değerlendirmemesi; inferred actions, void actions, spatial integration ve MR6 gibi başlangıçta bulunmayan fakat gerçek uygulamada gerekli hale gelen uyarlamaları açıkça raporlamasıdır.

Temel sınırlılıklar

Tek vaka: Çalışma yalnız bir uzunlamasına embodied-robotics projesine dayanır. Gerçek endüstriyel süreç görünürlüğü güçlü olsa da farklı ürün ve organizasyonlara genelleme sınırlıdır.

Participant-observer riski: Birinci yazar yöntemin uygulanmasında participant-observer olarak yer almış ve nitel analizin ana sorumluluğunu taşımıştır. Bu durum yorum yanlılığı potansiyeli yaratır. Artefakt üçgenlemesi, ortak-yazar incelemesi ve sistematik karar kayıtları bu riski azaltmak için kullanılmıştır ancak tamamen ortadan kaldırmaz.

Girdi senaryosunun kalitesine bağımlılık: SOS senaryo geliştirme yöntemi değildir. Kullanıcı eylemi, ürün cevabı ve bağlamsal bilgi zayıfsa sonraki teknik gereksinimler de genel ve yetersiz kalabilir.

Teknik parametre üretmez: Benchmark, veri sayfası, tedarikçi doğrulaması veya mühendislik testi olmadığında hedef değerler TBD kalabilir.

Manuel ölçeklenebilirlik: İz ağı büyüdükçe Miro ve manuel kimlik yönetimi yetersiz hale gelebilir. Daha büyük projeler özel traceability ve version-control araçlarına ihtiyaç duyabilir.

Organizasyonel bağımlılık: Yöntemin iş birliği etkisi ortak artefakt alanı, düzenli çapraz-fonksiyonel çalışma ve katılımcıların iterasyona açık olması gibi organizasyonel koşullara bağlıdır.

Formal trade-off kuralı yok: SOS kullanıcı deneyimi, maliyet, güvenlik, regülasyon ve teknik fizibilite arasında hangi seçeneğin “kazanması gerektiğini” matematiksel veya formal karar kuralıyla belirlemez. Mevcut vakada bu çatışmalar disiplinlerarası müzakereyle çözülmüştür.

Gelecek araştırma başlıkları

Kaynak beş ana gelecek çalışma alanı tanımlamaktadır. İlk olarak, büyük artefakt ağları için dedicated digital environments, version control, görsel trace management ve insan gözetimini koruyan AI-assisted veya yarı otomatik trace consistency mekanizmaları araştırılmalıdır.

İkinci olarak, mevcut TBD ve “flagged for validation” yaklaşımının yanına Low–Medium–High gibi hafif specification-confidence göstergelerinin eklenmesi önerilmektedir. Bu göstergeler bir değerin ne kadar sağlam kanıta dayandığını ve hangi parametrenin önce fiziksel olarak doğrulanması gerektiğini görünür hale getirebilir.

Üçüncü olarak, SOS'un kaliteli girdi senaryosuna bağımlılığı nedeniyle senaryo yazım söz dizimi ve mühendislik kullanımına hazır senaryo standardı geliştirilmesi önerilmektedir. Özellikle etkileşim modaliteleri, kullanıcı hataları ve failure conditions gibi istisnai durumların senaryolarda daha açık belirtilmesi araştırılmalıdır.

Dördüncü olarak, Steps 3 ve 4'te güvenlik, regülasyon, maliyet ve kullanıcı deneyimi gibi çatışan hedeflerin çözümü için yapılandırılmış decision heuristics ve rationale-capture mekanizmaları geliştirilmesi önerilmektedir.

Beşinci olarak, SOS'un farklı ürün türleri, sektörler, organizasyon yapıları ve proje ölçeklerinde yeniden uygulanması gerekmektedir. Özellikle daha hafif bir SOS uygulamasının ne zaman yeterli, tam altı-adımlı yapının ne zaman gerekli olduğu henüz belirlenmemiştir.

Verianla Live açısından uygunluk

SOS, Verianla Live için özellikle yöntem akışı ve izlenebilir veri zinciri bakımından uygundur. 15 senaryo → 244 öğe → 104 etkileşim → 144 FR → 100 bileşen → yaklaşık 312 spesifikasyon zinciri source-faithful Live Process/Live Flow olarak gösterilebilir. Ancak kaynakta senaryoların her biri için zaman serisi biçiminde nicel ölçüm bulunmadığından sahte animasyon zamanları veya ara veri noktaları üretilmemelidir.

Kaynak ve Yöntem Notu

Özgün başlık: Scenario-Oriented Specification (SOS): a design method for translating user scenarios into engineering specifications.

Yazarlar: Ulugbek Vahobjon Ugli Ismatullaev; KwanMyung Kim.

Yazar sırası: Ulugbek Vahobjon Ugli Ismatullaev birinci yazar, KwanMyung Kim ikinci yazardır.

Eş katkı: Kaynakta eşit katkı/eş birinci yazar bildirimi bulunmamaktadır.

Sorumlu yazar: KwanMyung Kim.

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

Dergi: Research in Engineering Design.

Yayınevi: Springer Nature.

Kaynak türü: Research Article; mühendislik tasarımı yöntemi geliştirme ve endüstriyel vaka doğrulama çalışması.

Cilt: 37.

Makale numarası: 36.

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

Received: 25 Mart 2026.

Revised: 20 Haziran 2026.

Accepted: 16 Temmuz 2026.

Published / Version of Record: 31 Ağustos 2026.

Hakemlik durumu: Research in Engineering Design dergisinde yayımlanmış hakemli Research Article.

Preprint durumu: Sağlanan kaynak yayımlanmış Version of Record PDF'sidir; kaynakta bu çalışma için ayrı bir preprint kimliği bildirilmemektedir.

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

Resmî yayın bağlantısı: DOI 10.1007/s00163-026-00498-w üzerinden Springer Nature'ın resmî makale kaydı.

Ana araştırma sorusu: Kullanıcı senaryoları, bağlamsal anlam ve izlenebilirlik korunurken ve mühendislik iş akışlarıyla uyumlu kalırken disiplinlerarası ekipler tarafından tekrarlanabilir biçimde mühendislik spesifikasyonlarına nasıl sistematik olarak dönüştürülebilir?

SOS çekirdek yapısı: Beş başlangıç adımı: senaryo öğelerini belirleme; interaction sequence oluşturma; fonksiyonel gereksinimleri türetme; bileşenleri seçme; mühendislik spesifikasyonlarını belirleme.

Uygulamada ortaya çıkan uzantı: Step 6 — Spatial integration.

Başlangıç meta-gereksinimleri: MR1 Bidirectional traceability; MR2 Contextual fidelity; MR3 Workflow compatibility; MR4 Repeatable translation; MR5 Shared representational space.

Uygulamada ortaya çıkan meta-gereksinim: MR6 Traceability scalability.

Tasarım ilkeleri: DP1 Action-based traceability; DP2 Context propagation; DP3 Synchronized multi-view representations.

Ana senaryo yapıları: Actions, User(s), Goals, Settings, Tools ve Events; SOS kodlamasında Actions, UA ve PA olarak ayrıştırılır.

Temel iz tanımlayıcıları: UA, PA, U, G, SET, T/E ve bileşen kodları gibi persistent identifiers.

Vaka projesi: Lemmy companion-care robot.

Proje dönemi: 2021–2025.

Coğrafya: Güney Kore.

Başlangıç keşif senaryosu: 18.

Aday senaryo: 25.

Doğrulanmış senaryo: 15.

Persona: 3.

Saha doğrulama katılımcısı: 12 yaşlı yetişkin.

Senaryo geliştirme ekibi: 12 tasarımcı ve UX araştırmacısı.

Çekirdek SOS uygulama ekibi: 6 araştırmacı.

Alan uzmanı: 12 elektrik, mekanik, yazılım ve iş uzmanı.

Ana senaryo doğrulama araçları: Derinlemesine görüşmeler, contextual inquiry, focus groups, literatür incelemesi, benchmarking, saha ziyareti, foam mock-up ve high-fidelity prototype role-playing.

Uygulama zamanlaması: Senaryo geliştirme tamamlandıktan sonra ve proof-of-concept prototiplemeden önce.

Çalışma ortamı: Başlangıçta fiziksel whiteboard, ardından ortak Miro workspace.

Empirik doğrulama boyutları: Practical enactability, output quality, process quality, process efficiency.

Structural validation: MR1–MR5 ile DP1–DP3 arasındaki ilişkilerin gerçek uygulamada tutarlılığının incelenmesi.

Birincil empirik materyal: Scenario element tables, interaction sequence maps, functional requirement lists, function–component matrices ve specification tables.

Diğer veri kaynakları: Participant observation, annotated artifacts, written notes, meeting minutes, participant reflections ve 12 uzmanla semi-structured interviews.

FGCS: Framework-Guided Content Structuring; framework analysis ile nitel içerik analizini SOS prosedürü etrafında birleştiren dört aşamalı yapısal analiz.

FGCS aşamaları: Artefaktları SOS adımlarına göre düzenleme; öğe akışlarını izleme; sapma ve uyarlamaları kodlama; senaryolar arası örüntüleri sentezleme.

Tematik analiz: Altı aşamalı Braun–Clarke yaklaşımı, first- ve second-cycle coding ile desteklenmiş hibrit deductive–inductive strateji.

Tematik analiz aşamaları: Familiarization; initial coding; re-coding; searching for sub-themes; reviewing and defining themes; producing the report.

Ana uygulama hacmi: 244 kodlanmış öğe; 59 UA; 79 PA; 106 bağlamsal öğe; 104 interaction; 144 FR; 100 component; yaklaşık 312 engineering specification.

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

Bileşen gelişimi: İlk olarak 72 scenario-driven component; konsolidasyon sonrası 65; ayrıca 35 engineering-driven component; toplam 100.

Parametreleme sonucu: Scenario-driven component'ların yaklaşık %80'i çalışma sonunda tamamen parameterized; kalanlar “flagged for validation”.

Revizyon sonucu: Scenario-driven component specifications'ın yaklaşık %30'u en az bir kez revize edilmiştir.

Uygulama süresi: Yaklaşık 11 ay.

Sonraki parti hızı: İkinci ve üçüncü partideki toplam on senaryo yaklaşık dört–beş ayda işlenmiştir; kaynak bunun tekrar eden işlevler ve yeniden kullanım sayesinde oluştuğunu, başka projelerde aynı hızın garanti olmadığını belirtmektedir.

Matematiksel formül durumu: Kaynakta araştırma sonucu üreten merkezi matematiksel denklem bulunmamaktadır. SOS'un FR üretiminde kullandığı yapı, matematiksel formül değil kısıtlı doğal dil grameridir.

İstatistiksel çıkarım: Çalışma yöntemler-arası randomize veya kontrollü nicel performans deneyi değildir; ana değerlendirme nitel vaka analizi, artefakt izleme, descriptive counts, FGCS ve thematic analysis üzerinden yapılmıştır.

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

Onam: Minimal risk nedeniyle yazılı informed consent dokümantasyonundan feragat verilmiştir. Veriler de-identified biçimde analiz ve rapor edilmiştir.

Veri erişilebilirliği: Veri setleri, endüstriyel iş birliğine ait kimliksizleştirilmiş fakat potansiyel olarak hassas proje materyalleri ve insan katılımcıları içeren nitel veriler nedeniyle kamuya açık değildir. Altı SOS adımı için ayrıntılı uygulama talimatları ve şablonlar içeren practitioner manual, sorumlu yazardan talep üzerine sağlanabilir.

Yazar katkıları — Ulugbek Vahobjon Ugli Ismatullaev: Conceptualization; Methodology; Investigation; Data curation; Formal analysis; Validation; Visualization; Writing – original draft; Writing – review & editing.

Yazar katkıları — KwanMyung Kim: Conceptualization; Methodology; Validation; Supervision; Project administration; Funding acquisition; Writing – review & editing.

Finansman: Open Access funding UNIST tarafından sağlanmış ve düzenlenmiştir. Çalışma Republic of Korea Ministry of Trade, Industry and Energy (MOTIE) tarafından finanse edilen Technology Innovation Program kapsamında 20015056 ve RS-2025-04752997 numaralı projelerle desteklenmiştir.

Çıkar çatışması: Yazarlar competing interests bulunmadığını bildirmiştir.

Ana yöntemsel sınır: Tek uzunlamasına embodied-robotics vakası transfer/genellenebilirlik iddiasını sınırlar.

Yorum yanlılığı sınırı: Birinci yazar participant-observer rolündedir ve nitel analizin ana sorumluluğunu taşımıştır; artefakt triangulation, co-author review ve sistematik dokümantasyonla risk azaltılmıştır.

Otomasyon sınırı: SOS teknik hedef değerleri bağımsız üretmez ve mühendislik yargısının yerini almaz.

Üstünlük sınırı: Çalışma SOS'un alternatif yöntemlerden üstün olduğunu veya downstream ürün performansını artırdığını göstermeyi amaçlamamış ve böyle bir karşılaştırma yapmamıştır.

Uygulanabilirlik sınırı: Yöntem erken sistem tanımlama aşamasındaki etkileşim yoğun, bağlam açısından zengin ürünlerde özellikle uygun görünmektedir. Çok formal systems engineering, ağır regulatory compliance veya yalnız dijital service logic ile yönetilen alanlarda farklı ya da uyarlanmış temsil yapıları gerekebilir.