Сценарийге Багытталган Спецификация (Scenario-Oriented Specification, SOS), колдонуучу тажрыйбасынын сценарийлериндеги аракет, максат жана контекст тууралуу маалыматты көзөмөлдөнүүчү аралык көрсөтмөлөр аркылуу функционалдык талаптарга, системанын компоненттерине жана өлчөнө турган инженердик спецификацияларга айландыруу үчүн иштелип чыккан көрсөтмөлүү дизайн ыкмасы. Изилдөө колдонуучу тажрыйбасын изилдөөнүн контексттик жана баяндоочу натыйжалары менен инженериядагы өлчөнүүчү жана текшерилүүчү техникалык көрсөтмөлөрдүн ортосундагы үзүлүүнү experience–specification gap, башкача айтканда тажрыйба–спецификация ажырымы катары концептуалдаштырат. SOS бул ажырымды сценарийден акыркы техникалык мааниге түз секирүү менен эмес, бири-бирине туруктуу идентификаторлор аркылуу байланыштырылган аралык көрсөтмөлөрдү түзүү аркылуу чечет.

SOSтун баштапкы өзөгү беш кадамдан турат: сценарий элементтерин аныктоо, өз ара аракеттенүү ырааттуулуктарын түзүү, функционалдык талаптарды чыгаруу, компоненттерди тандоо жана инженердик спецификацияларды аныктоо. Ыкма үч дизайн принцибине таянат: аракетке негизделген көзөмөлдөнүүчүлүк, контекстти алдыга алып өтүү жана синхрондоштурулган көп-көрүнүштүү көрсөтмөлөр. Бул принциптер башында беш мета-талапты канааттандыруу үчүн иштелип чыккан: эки багыттуу көзөмөлдөнүүчүлүк, контексттик тактык, инженердик иш агымы менен шайкештик, кайталануучу которуу жана жалпы көрсөтмө мейкиндиги.

Ыкма Түштүк Кореяда 2021–2025-жылдары жүргүзүлгөн жана улгайган адамдардын күнүмдүк, коопсуздук жана социалдык өз ара аракеттенүү муктаждыктарына багытталган Lemmy аттуу companion-care роботун иштеп чыгуу долбоорунда табигый өндүрүштүк шарттарда бааланган. Сценарий иштеп чыгуу процесси алгач 18 изилдөө сценарийин жараткан, дизайн семинарларында бул сан 25 талапкер сценарийге көбөйтүлгөн жана 12 улгайган адамдын үйлөрүнө талаа сапарлары, пенопласт макеттер жана жогорку тактыктагы прототиптер менен роль ойноо иштеринен кийин 15 текшерилген сценарийге кыскартылган.

SOS колдонулганда бул 15 сценарийден жалпы 244 коддолгон сценарий элементи алынган. Алардын ичинен 138 — өз ара аракеттенүү элементи: 59 колдонуучу аракети жана 79 продукт аракети. Калган 106 элемент колдонуучу, максат, чөйрө, курал жана окуя сыяктуу контексттик элементтер. Бул маалыматтар 104 өз ара аракеттенүү ырааттуулугуна айландырылган; алардан 144 функционалдык талап түзүлгөн; талаптар 100 компонентке дал келтирилген жана болжол менен 312 инженердик спецификация чыгарылган.

144 функционалдык талап гармонизация учурунда 69 кайталануучу же негизги талапка жана 75 сценарийге мүнөздүү талапка бөлүнгөн. Алгачкы компонент тандоолорунда 72 сценарийден келип чыккан компонент пайда болгон, дисциплиналар аралык ишке ашыруу мүмкүнчүлүгү жана интеграция текшерүүлөрүнүн соңунда алар 65 компонент болуп консолидацияланган. Сценарийлерде түз көрүнбөгөн, бирок системанын бүтүндүгү үчүн керектүү электроника, монтаж жана ушуга окшогон инфраструктураны билдирген 35 инженериядан келип чыккан компонент кошулуп, жалпы компонент саны 100 компонентке жеткен.

Өндүрүштүк колдонуу SOSтун алгачкы беш кадамы бардык сценарийлерде аткарылышы мүмкүн экенин, бирок физикалык робот сыяктуу embodied продуктта семантикалык спецификация өзү гана жетиштүү эмес экенин да көрсөткөн. Компоненттер продукттун корпусуна чындап батабы, сенсорлор туура камтууну камсыз кылабы, монтаждык боштуктар жана коопсуздук–стиль карама-каршылыктары сыяктуу маселелерден улам мейкиндиктик интеграция (spatial integration) деп аталган алтынчы кадам колдонуу учурунда пайда болгон. Бул алтынчы кадам башында аныкталган SOS өзөгүнүн бөлүгү эмес, иш жүзүндөгү учурдан чыккан методикалык кеңейтүү.

Изилдөөнүн натыйжалары SOS бир гана учурда колдонууга жарактуу жана структуралык жактан ырааттуу экенин колдойт; бирок ыкма атаандаш дизайн ыкмалары менен көзөмөлдөнгөн түрдө салыштырылган эмес. Ошондуктан булак SOS QFD, use-case ыкмаларынан же башка талаптар инженериясынын ыкмаларынан артык экенин далилдебейт. Ошондой эле SOS инженердик максаттуу маанилерди автоматтык түрдө эсептебейт: өлчөнүүчү параметрлердин чыныгы максаттары үчүн benchmark маалыматтары, өндүрүүчү/жеткирүүчү маалыматтары, референстик спецификациялар, физикалык сыноолор жана инженердик баам керек.

Изилдөөнүн эң маанилүү чектөөсү — текшерүүнүн бир гана узак мөөнөттүү embodied-robotics долбооруна негизделиши. Биринчи автордун participant-observer катары ыкманы колдонууга катышуусу да чечмелөөдө бир жактуулук коркунучун жаратат; изилдөөчүлөр муну долбоор документтери, маектер, кошо авторлордун кароосу жана ар түрдүү маалымат булактарын триангуляциялоо аркылуу азайтууга аракет кылышкан. Ошондуктан жыйынтыктарды ар башка продукт класстарына, катуу жөнгө салынган инженердик тармактарга же жалаң санариптик кызмат долбоорлоруна түз жалпылоо туура эмес.

Сценарийге Багытталган Спецификация (SOS) деген эмне жана кайсы маселени чечет?

Сценарийге Багытталган Спецификация — колдонуучу сценарийлериндеги тажрыйбалык жана контексттик маалыматты жоготпостон, аны этап-этабы менен функционалдык талаптарга, техникалык компоненттерге жана өлчөнүүчү инженердик спецификацияларга айландырган көзөмөлдөнүүчү дизайн ыкмасы; негизги маселе сценарийдин “колдонуучу кайсы кырдаалда эмнени башынан өткөрөт жана продукт кандай аракет кылышы керек?” деген тилинен инженериянын “кайсы компонент кайсы өлчөнүүчү максатты камсыз кылышы керек?” деген тилине өткөндө контекст менен негиздеменин жоголушу.

UX сценарийи менен инженердик спецификация эмне үчүн бир эле көрсөтмө эмес?

Колдонуучу тажрыйбасынын сценарийлери убакыт ичинде жүргөн өз ара аракеттенүүлөрдү, колдонуучунун максатын, абалын, айлана-чөйрө шарттарын, өзгөчө окуяларды жана продукттун жүрүм-турумун баяндоочу түрдө бирге камтыйт. Инженердик спецификациялар болсо системаны бөлүп кароого, компоненттерге бекитүүгө, өлчөөгө жана текшерүүгө боло турган техникалык милдеттенмелерге айландырууну талап кылат. Мисалы, “улгайган колдонуучу түнкүсүн дааратканага бара жатканда робот кулап калууну өткөрүп жибербеши керек” деген контексттик күтүм инженердик жактан сенсор камтуусу, аз жарыктагы иштөө, жайгаштыруу, аныктоо логикасы жана текшерүү шарттары сыяктуу өзүнчө техникалык маселелерге айланышы мүмкүн.

Тажрыйбалык маалыматты эмне үчүн түз эле параметрлер таблицасына айландырууга болбойт?

Анткени сценарийдеги колдонуучу муктаждыгы көбүнчө бир туруктуу касиет эмес. Бир эле продукт жүрүм-туруму колдонуучунун жашына, физикалык мүмкүнчүлүгүнө, чөйрөдөгү ызы-чууга, күндүн убактысына, бар болгон куралдарга, өзгөчө кырдаалдарга жана мурунку өз ара аракеттенүүлөргө жараша болушу мүмкүн. Бул маалыматтарды түз эле бир “талаптар тизмесине” кыскартуу техникалык маанинин эмне үчүн керектүү экенин көрүнбөй калышы мүмкүн.

Тажрыйба–Спецификация Ажырымы деген эмне?

Тажрыйба–спецификация ажырымы — колдонуучу тажрыйбасынын сценарийлериндеги контексттик өз ара аракеттенүү логикасы менен инженерияда колдонулган формалдуу жана өлчөнүүчү техникалык көрсөтмөлөрдүн ортосундагы көрсөтмөлүк үзүлүү; изилдөө бул маселени жөн гана дисциплиналар аралык байланыштын жетишсиздиги катары эмес, ар башка билим формалары ар башка аналитикалык бирдиктерди жана ой жүгүртүү ыкмаларын колдонгонунан пайда болгон көрсөтмөлүк маселе катары карайт.

“Representational non-isomorphism” эмнени билдирет?

Изилдөөнүн теориялык салымдарынын бири — сценарий менен инженердик спецификацияны бир эле маалыматтын жөн гана ар башка жазылыштары катары көрбөгөнү. Сценарийлер колдонуучу тажрыйбасын убакыт, контекст жана өз ара аракеттенүү траекториясы ичинде уюштурат; спецификациялар болсо техникалык милдеттенмелерди компонент, параметр, максаттуу маани жана текшерүү логикасынын айланасында уюштурат. Ошондуктан эки көрсөтмөнүн ортосунда бирден-бир жана жоготуусуз түз шайкештештирүүнү божомолдоо ишенимдүү эмес. SOSтун аралык көрсөтмөлөрү дал ушундан улам керек.

QFD жана use case ыкмаларынан кайсы жагынан айырмаланат?

Булак Quality Function Deployment кардардын муктаждыктарын инженердик мүнөздөмөлөргө шайкеш келтирүүдө күчтүү экенин, бирок муктаждыктарды көбүнчө туруктуураак касиеттер катары караарын; контекстке көз каранды жана убакытка жайылган өз ара аракеттенүүлөр матрицалык көрсөтмөлөргө дайыма эле жакшы батпай турганын белгилейт. Use case ыкмалары актор–максат–система жүрүм-турумун калыптандырат, бирок контексттик квалификаторлор өлчөнүүчү инженердик спецификацияларга кандай алып өтүлөрү дайыма ачык эмес. Бул теориялык салыштыруу SOS бул ыкмалардан эксперименттик жактан артык экенинин далили эмес.

SOSтун беш баштапкы мета-талабы

SOSтун үч дизайн принциби

UA жана PA деген эмне?

UA (User Action), колдонуучу аткарган аракет. PA (Product Action), продукттун бул колдонуучу аракетине жооп катары аткарган же аткарышы күтүлгөн аракет. SOS чоң жана абстракттуу сценарий сүйлөмдөрүнүн ордуна ушул UA–PA жуптарын негизги которуу бирдиги катары колдонот.

Контексттик элементтер кайсылар?

Булак тажрыйбага багытталган сценарийдин алты жалпы элементин Actions, User(s), Goals, Settings, Tools жана Events деп карайт. SOSтун Step 1 коддоосунда Actions кошумча түрдө колдонуучу аракеттери (UA) жана продукт аракеттери (PA) болуп бөлүнгөндүктөн, практикалык иш таблицасында UA, PA, User, Goal, Setting, Tool жана Event болуп жети код түрү көрүнүшү мүмкүн.

Туруктуу идентификатор эмне үчүн маанилүү?

Ар бир маанилүү элементке UA1, PA1, U1, G1 же SET1 сыяктуу туруктуу идентификаторлорду берүү техникалык чечимдер өзгөрсө да маалымат чынжыры үзүлбөшүн көздөйт. Ошентип, мисалы, сенсор алмаштырылса “кайсы функционалдык талап үчүн тандалган эле, ал талап кайсы продукт аракетинен, ал продукт аракети кайсы колдонуучу сценарийинен келген?” деген суроолорду артка карай көзөмөлдөөгө болот.

SOS колдонуучу сценарийин инженердик спецификацияга кантип айлантат?

SOS которууну беш негизги кадам менен аткарат: сценарийдеги структураланган элементтер чыгарылат, UA–PA жуптарынан ырааттуу өз ара аракеттенүү тизмектери түзүлөт, продукт аракеттери контекстти сактаган чечимден көз каранды эмес функционалдык талаптарга которулат, бул талаптар ишке ашырыла турган компоненттерге бекитилет жана акырында ар бир компонент үчүн өлчөнүүчү параметрлер менен максаттар аныкталат; embodied продукт учурунда бул чынжырга физикалык ишке ашырылууну текшерген алтынчы мейкиндиктик интеграция кадамы кошулган.

Кадам 1: Сценарий элементтерин аныктоо

Катышуучулар адегенде сценарийди толугу менен окуп, баяндоо агымы жана өз ара аракеттенүү контексти боюнча жалпы түшүнүк түзүшөт. Андан кийин колдонуучу аракеттери, продукт аракеттери, колдонуучунун өзгөчөлүктөрү, максаттар, чөйрө/setting маалыматтары, куралдар жана окуялар өзүнчө элементтер катары чыгарылат.

Булак үч коддоо эрежесин аныктайт. Separation, бир эле сүйлөмдө колдонуучунун ниети жана продукттун жообу болсо, аларды өзүнчө UA жана PA катары бөлөт. Granularity, элементти өз алдынча жүрүм-турум маанисин жоготпогон эң кичине ылайыктуу деңгээлде коддойт. Identifier assignment болсо ар бир элементке UA1, PA1 же SET1 сыяктуу туруктуу идентификатор берет.

Бул кадамдын натыйжасы Scenario Element Table. Эгер сценарий бул структуралык маалыматтарды жетиштүү камтыбаса, булак сценарийди өз ара аракеттенүү ырааттуулуктарына бөлүүдөн мурда өнүктүрүү талап кылынышы мүмкүн экенин белгилейт.

Кадам 2: Өз ара аракеттенүү ырааттуулуктарын түзүү

Чыгарылган UA жана PAлар жупташтырылып, убакыт тартибине коюлат. Колдонуучу өзгөчөлүктөрү, максаттар, setting, tools жана events бул ырааттуулуктан чыгарылбайт; кийинки техникалык чечимдерге таасир этүүчү структураланган квалификаторлор болуп калат.

Мисалы, колдонуучунун “саат 19.00 чейин тез тамак даярдагысы келиши” жөн гана “тамак сунушта” функциясына кыскартылбайт. Убакыт басымы продукттун жүрүм-турумун өзгөртүп, даярдоо мөөнөтү кыскараак варианттарды артык көрүү сыяктуу техникалык/функционалдык натыйжаларды жаратышы мүмкүн.

Колдонууда пайда болгон “inferred action” деген эмне?

Inferred action, сценарийде ачык жазылбаса да, кийинки продукт жүрүм-туруму техникалык жактан ишке ашышы үчүн ортодо болушу керек болгон системалык операцияны көрүнүктүү кылуу. Мисалы, сценарийде “робот балдарга үн билдирүү жөнөтөт” гана айтылса, окуяны аныктоо, чечмелөө жана билдирүүнү түзүү сыяктуу зарыл аралык процесстер ачык жазылбашы мүмкүн. Команда бул операцияларды кошкон, бирок ар бир кошумчаны келип чыккан сценарий элементине байлап, көзөмөлдөнүүчүлүктү сактаган.

“Void action” деген эмне?

Void action, колдонуучунун көз карашынан каалаган, бирок долбоордун учурдагы технология, нарк же ишке ашыруу мүмкүнчүлүгүнүн чегинде аткарылбаган продукт жүрүм-туруму. SOS муну сценарийден өчүрбөйт; “азыр колдоого алынбайт” деген статус менен сактайт. Ошентип техникалык жактан ишке ашпаган жүрүм-турумдун артындагы колдонуучу ниети келечекте кайра бааланышы мүмкүн.

Өз ара аракеттенүү формасы эмне үчүн өзүнчө такталган?

Сценарийлердеги “колдонуучу роботтон сурайт” сыяктуу сөздөр үн, мобилдик колдонмо же физикалык интерфейстин кайсынысы колдонуларын түшүндүрбөшү мүмкүн. Колдонуу учурунда команда далил болсо өз ара аракеттенүү модалдуулугун тактаган; белгисиздик улана берсе бир нече мүмкүн болгон модалдуулукту жазып алган. Бул кийинки сенсор, интерфейс жана компонент тандоолорунун ойдон чыгарылган божомолго таянуусун азайткан.

Кадам 3: Функционалдык талаптарды чыгаруу

Ар бир UA–PA жуп кеминде бир функционалдык талап жаратышы күтүлөт. Функционалдык талап конкреттүү технологияны дароо тандоонун ордуна продукт аткарышы керек болгон жөндөмдү сүрөттөйт.

SOSтун чектелген FR сүйлөм логикасы: Продукт белгилүү бир продукт аракетин мүмкүн кылуу үчүн зарыл функцияны колдонуучунун өзгөчөлүктөрү, максаттар, чөйрө, куралдар же окуялар сыяктуу тиешелүү контексттик шарттарда же аларга негизденип аткарышы керек.

Бул түзүлүш математикалык формула эмес. Булактын стандартташтырылган талап жазуу грамматикасы. Максат “продукт үндү таанышы керек” сыяктуу контекстсиз талаптын ордуна, мисалы, ызы-чуулуу ашкана чөйрөсүндө тамак сунуштай алуу үчүн колдонуучунун үн буйругун ишенимдүү таануу сыяктуу себеп–функция байланышын сактоо.

Эгер бир PA бир нече жоопкерчиликти же текшерүү шартын камтыса, FRлер бөлүнүшү мүмкүн. Бирдей жүрүм-турумду билдирген FRлер болсо баштапкы из байланыштары сакталып бириктирилиши мүмкүн. Бир нече сценарийде кайталанган талаптар гармонизация аркылуу basic FR, белгилүү сценарийдин өзгөчө жүрүм-турумун гана сактагандар specific FR болуп бөлүнөт.

Кадам 4: Компоненттерди тандоо

Функционалдык талаптар аппараттык, программалык же интерфейс компоненттерине дал келтирилет. Тандоо функциянын аталышына гана жараша жүргүзүлбөйт; технологиянын жетилгендиги, иштөө чектери, нарк жана өндүрүлүү мүмкүнчүлүгү сыяктуу ишке ашыруу критерийлери да эске алынат.

Эгер бир FR бир нече компонентти талап кылса, критикалык которууну аткарган компонентке негизги ээлик берилиши жана башка көз карандылыктар катталышы мүмкүн. Бул байланыштар Function–Component Matrix ичинде сакталат.

Алгачкы семинарларда 72 сценарийден келип чыккан компонент аныкталган. Кийинки ишке ашыруу мүмкүнчүлүгү жана интеграция баалоолору менен айрым компоненттер кийинкиге жылдырылган, өзгөртүлгөн, жөнөкөйлөштүрүлгөн же бириктирилген жана саны 65 компонентке азайган. Мындан тышкары сценарийлерде түз көрүнбөгөн, бирок продукт иштеши үчүн керектүү ички электроника, конструкциялык монтаждар жана ушуга окшогон 35 инженериядан келип чыккан компонент кошулуп, жалпы 100 компонентке жеткен.

Кадам 5: Инженердик спецификацияларды аныктоо

Ар бир тандалган компонент үчүн параметрдин аталышы, бирдик, максаттуу маани жана өлчөө/текшерүү божомолу аныкталат. Булак ар бир компонент кеминде бир өлчөнүүчү параметрге ээ болушун көздөйт. Контексттик чектөө сандык түргө келтирилсе, ачык чектик мааниге айландырылат; ишенимдүү сандык маани азырынча жок болсо, текшерүү божомолу же кийин аныктала турган элемент катары катталат.

TBD эмнени билдирет?

TBD (To Be Determined), маанинин булагы али жетиштүү болбогондо кокустук максаттуу сан ойлоп табуунун ордуна “кийин аныкталсын” деп белгилөө. Булакта бул ыкма кемчиликти жашыруу эмес, белгисиздикти ачык башкаруу каражаты катары колдонулат.

SOS автоматтык талап же инженердик максаттуу маани түзүүчү системабы?

Жок; SOS сценарийден спецификацияга которуунун маалымат түзүлүшүн жана көзөмөлдөнүүчүлүгүн уюштурат, бирок микрофондун сезгичтиги, кечигүү, кубат керектөө же геометриялык чектер сыяктуу чыныгы техникалык максаттуу маанилерди өзү эсептебейт; булакта бул маанилер инженердик баалоо, benchmark, маалымат баракчалары, жеткирүүчү маалыматтары, референстик системалар жана кийинки PoC сыноолору менен аныкталышы керектиги ачык айтылат.

Бул айырма ыкманы туура түшүнүү үчүн өтө маанилүү. SOS “колдонуучу мындай муктаждыкты айтты, демек микрофондун сезгичтиги сөзсүз −35 dB болушу керек” деген автоматтык физикалык эсеп жүргүзбөйт. 8-сүрөттөгү спецификация мисалдары ыкманын иштөө логикасын көрсөтүү үчүн берилген; булак аларды бардык продукттарга колдонулуучу универсалдуу максаттар катары сунуштабайт.

Чечимден көз каранды эместик эмне үчүн маанилүү?

Функционалдык талап техникалык чечимден мурда аныкталганда бир эле колдонуучу максаты ар башка технологиялар менен ишке ашырылышы мүмкүн. Булактагы мисалдардын бири жогорку чечилишке ээ экранды нарк жана энергия себептеринен улам жөнөкөй LED матрицага алмаштырууга болору, ошол эле учурда “системанын абалын колдонуучуга билдирүү” функционалдык максаты сактала аларын көрсөтөт.

Бирок булак чечимден көз каранды эместик ыкманын ички эрежеси гана эмес экенин да баса белгилейт. Катуу убакыт графиги же эрте нарк басымы бар уюмдарда командалар бар болгон технологияга өтө эрте байланып калышы мүмкүн. Мындай эрте жакындашуу SOS көздөгөн “адегенде функционалдык ниет, андан кийин техникалык чечим” ажырымын алсыратышы мүмкүн.

Мейкиндиктик интеграция эмне үчүн пайда болду?

Алгачкы беш кадам системанын жүрүм-турумун жана өлчөнүүчү техникалык максаттарды семантикалык жактан байланыштырганы менен, робот сыяктуу физикалык продуктта компонент корпусуна чындап батабы, кабель жана монтаждык боштуктар жетиштүүбү, сенсор колдонуучунун кыймыл жолун көрөбү же коопсуздук элементи жаңылыш иштетилип кетеби — муну таблица аркылуу гана аныктоо мүмкүн болгон эмес.

Мейкиндиктик интеграция эмне үчүн алтынчы SOS кадамы катары пайда болду?

Мейкиндиктик интеграция — алгачкы беш SOS кадамы логикалык жана семантикалык көзөмөлдөнүүчүлүктү камсыз кылганына карабастан, физикалык роботто компоненттердин жайгашуусу, монтаждык боштук, сенсор камтуусу, өз ара аракеттенүүнүн жеткиликтүүлүгү жана стиль–коопсуздук–инженерия карама-каршылыктары өзүнчө текшерилиши керек болгондуктан колдонуу учурунда пайда болгон embodied-feasibility кеңейтүүсү; булак муну бардык продукттарга милдеттүү универсалдуу алтынчы кадам катары эмес, учурдагы embodied-product ишинде пайда болгон зарыл методикалык кеңейтүү катары чечмелейт.

Семинарларда командалар компоненттерди жалпы продукт концепциясынын үстүндө бирге жайгаштырышкан. Ошентип, сенсордун тосулушу, корпустун көлөмүнүн жетишсиздиги, микрофон–динамик акустикалык өз ара аракеттенүүсү жана монтажга жетүү сыяктуу мурунку аналитикалык көрсөтмөлөрдө көрүнбөгөн карама-каршылыктар табылган.

Мисалы, механикалык авариялык токтотуу баскычы система катасында оңой жеткиликтүү болушу керек эле, ошол эле учурда роботту сылоо, тийүү жана үн жөндөө сыяктуу жакын колдонуучу аракеттеринде кокус басылып кетпеши да керек болчу. Дисциплиналар аралык баалоонун натыйжасында баскычты арткы-төмөнкү аймакка жайгаштыруу сунушталган. Бул мисал универсалдуу emergency-stop жайгаштыруу эрежеси эмес, сценарий контексти менен коопсуздук/инженердик чектөөлөрдү бирге баалоого байланышкан учурдун жыйынтыгы.

Ыкманын өндүрүштүк текшерүү чөйрөсү

Изилдөө Түштүк Кореядагы Lemmy companion-care робот долбоорунун активдүү иштеп чыгуу процессине киргизилген узак мөөнөттүү табигый учур дизайнын колдонгон. Долбоор 2021–2025-жылдары дизайн фирмасын, өндүрүш өнөктөшүн жана мамлекеттик изилдөө мекемесин камтыган көп өнөктөштүү өнүктүрүү демилгеси болгон.

Сценарийлер кантип түзүлүп, текшерилди?

2021-жылы 12 дизайнер жана UX изилдөөчүсү терең маектерди, контексттик изилдөөлөрдү, фокус-топторду, адабияттарды кароону жана benchmarking колдонуп, алты айлык иш жүргүзгөн. Алгач 18 изилдөө сценарийи, андан кийин дизайн семинарлары аркылуу 25 талапкер сценарий түзүлгөн.

Сценарийлер 12 улгайган адамдын үйлөрүнө талаа сапарларында, пенопласт макеттер жана жогорку тактыктагы прототиптер менен роль ойноо аркылуу бааланган. Катышуучулардын пикирлери жана ички дизайн кароолору менен дал келген баяндоолор бириктирилип, кайталоолор алынып салынган жана карама-каршы божомолдор чечилип, 15 текшерилген сценарий алынган.

Бул сценарийлер үч persona айланасында уюштурулган. SOS колдонулганга чейин баяндоолор колдонуучу аракети, продукт аракети, колдонуучу профили, максат, контексттик квалификаторлор, куралдар жана окуялар ачык көрүнгөн ырааттуу түзүлүшкө келтирилген. Изилдөөчүлөр муну сценарийдин баштапкы ниетин өзгөртпөстөн жасалганын белгилешет.

Пилот жана толук колдонуу

Адегенде бир өкүл сценарий башынан аягына чейин пилот катары колдонулган; терминология, иш келишимдери, ажыратуу деңгээли жана шаблондор туруктуу болгондон кийин ыкма калган сценарийлерге колдонулган. Иш физикалык ак тактадан реалдуу убакыттагы биргелешкен түзөтүүнү жана туруктуу документтештирүүнү колдогон Miro иш мейкиндигине өткөн.

Негизги колдонуу командасы адам факторлору, өндүрүштүк инженерия, өнөр жай дизайны, механика инженериясы, UX дизайны жана бизнес тажрыйбасы бар алты изилдөөчүдөн турган. Команданы дизайн методологиясы жана продукт өнүктүрүүдө 25 жылдык тажрыйбасы бар улук продукт дизайнер көзөмөлдөгөн.

Команда ошондой эле электр, механика жана программалык инженерлерди, ошондой эле бизнес адистерин камтыган 12 тармак адиси менен иштеген. Бул адамдар ишке ашыруу мүмкүнчүлүгүн баалоодо, техникалык компонент тандоодо жана спецификация иштеп чыгууда салым кошкон.

Эмпирикалык текшерүүнүн төрт өлчөмү

Структуралык текшерүү эмнени баалады?

Эмпирикалык текшерүү “ыкманы колдонууда эмне болду?” деген суроого көңүл бурса, структуралык текшерүү үч дизайн принциби көздөлгөн мета-талаптарды чындап операциялаштырдыбы, ошону изилдеген. MR1–MR5 үчүн байкоого боло турган көрсөткүчтөр аныкталып, чыныгы долбоор артефакттарындагы жүрүм-турум каралган.

Маалымат булактары

Негизги эмпирикалык материал — SOS учурунда түзүлгөн Scenario Element Table, Interaction Sequence Map, FR тизмелери, Function–Component Matrix жана Specification Sheet сыяктуу долбоор документтери. Бул документтер из жолдору, которуу чечимдери жана параметр негиздемелери үчүн түз далил берген.

Экинчи булак participant observation. Биринчи автор SOS колдонууга participant-observer катары катышкан; ыкмадан четтөөлөрдү, түшүндүрмө талап кылган пункттарды, итерацияларды жана катышуучулардын сүйлөшүүлөрүн талаа жазуулары жана жыйын протоколдору менен документтештирген. Бул жазуулар бир изилдөөчүнүн бир жактуулугун азайтуу үчүн кошо авторлор менен каралган.

Үчүнчү булак — катышуучулардын рефлексиялары жана жарым түзүмдөлгөн маектер. SOS колдонууга катышкан 12 адис менен колдонуу учурунда жана андан кийин маектер жүргүзүлүп, колдонууга жарактуулук, кездешкен кыйынчылыктар жана спецификация чечимдеринин негиздемелери изилденген.

Framework-Guided Content Structuring (FGCS) кантип иштеди?

FGCS, SOS колдонууда маалымат кадамдардын арасында кантип алып өтүлгөнүн кайра түзүү үчүн колдонулган жана framework analysis менен сапаттык мазмун анализин бириктирген аналитикалык ыкма. SOS процедурасы аналитикалык каркас катары колдонулган.

1. Артефакттарды кадамдар боюнча уюштуруу: Ар бир сценарийдин натыйжалары SOS кадамдары боюнча хронологиялык топтолгон.
2. Элемент агымдарын көзөмөлдөө: Өзгөчө UA жана PAлардын өз ара аракеттенүү ырааттуулуктары, FRлер, компоненттер жана спецификациялар боюнча сакталып-сакталбаганы катталган.
3. Четтөөлөрдү жана ыңгайлашууларды белгилөө: Өткөрүп жиберилген же кайра иреттелген кадамдар, кошумча ички кадамдар жана чечмелөө өзгөрүүлөрү документтештирилген.
4. Сценарийлер аралык үлгүлөрдү синтездөө: Кайталанган колдонмолор, жалпы кыйынчылыктар жана туруктуу ыңгайлашуулар 15 сценарий боюнча салыштырылган.

Тематикалык анализ кантип жүргүзүлдү?

Катышуучулар SOSту кантип колдонгонун түшүнүү үчүн алты этаптуу тематикалык анализ колдонулуп, биринчи/экинчи цикл коддоо менен колдоого алынган. Ыкма гибрид дедуктивдүү–индуктивдүү: алдын ала аныкталган төрт текшерүү өлчөмү дедуктивдүү тема алкагын түзгөн, колдонууда күтүүсүз пайда болгон inferred action, void action жана spatial integration сыяктуу үлгүлөр индуктивдүү түрдө кошулган.

Алты этап: маалымат менен таанышуу, алгачкы коддоо, кайра коддоо, суб-темаларды издөө, темаларды кароо/аныктоо жана отчет даярдоо. FGCS “кайсы артефакт качан жана кантип өзгөрдү?” деген суроого көбүрөөк структуралык жооп берсе, тематикалык анализ “катышуучулар муну кантип жана эмне үчүн ушундай колдонушту?” деген суроону чечмелөөгө жардам берген.

Изилдөөнүн Ыкмасы жана Жыйынтыктары

Изилдөө дизайнынын техникалык кыскача баяны

15 сценарийдин сандык которуу кыскача жыйынтыгы

Практикалык аткарылуу мүмкүнчүлүгүнүн натыйжасы

Алдын ала каралган беш SOS кадамы бардык 15 сценарийде аяктаган. Ишке ашыруу мүмкүнчүлүгүн кароолор кээде мурунку кадамдарга кайтууну талап кылган, бирок туруктуу из байланыштары сакталган. Бир кадамдын натыйжасы көбүнчө кийинки кадам үчүн колдонууга жарактуу киргизме болуп, кээде гана түшүндүрүү же түзөтүү керек болгон.

Колдонуу учурунда үч маанилүү ыңгайлашуу пайда болгон: жетишпеген аралык системалык операцияларды көрүнүктүү кылган inferred actions, техникалык жактан азырынча мүмкүн эмес, бирок колдонуучунун ниетин сактаган void actions жана embodied продукттун физикалык реалдуулугун баалаган spatial integration.

Натыйжа сапатынын жыйынтыгы

Колдонуучу-борборлуулук “сценарий колдонулганы” үчүн гана эмес, техникалык спецификациялар тиешелүү колдонуучу аракетине, максатына жана чөйрөсүнө ачык из байланышын алып жүргөнү аркылуу сакталган. Мисалы, сенсор жайгашуусу абстракттуу камтуу маанилерине гана эмес, колдонуучунун түнкүсүн үй ичиндеги чыныгы кыймыл жолдору сыяктуу сценарий шарттарына жараша кайра каралган.

Чечимден көз каранды эместик продукт аткарышы керек болгон функция менен аны аткара турган техникалык компонентти ар башка этаптарда карап чыгуу аркылуу сакталууга аракет кылынган. Ошол эле учурда изилдөө чечимден көз каранды эместик уюштуруучулук убакыт/нарк басымынан таасирлениши мүмкүн экенин да көрсөткөн.

Ишке ашыруу мүмкүнчүлүгү жагынан айрым баштапкы чечимдер өзгөртүлгөн. Булак мисалдарында зымсыз кубаттоонун ордуна смартфонду кубаттоо эскертмесин баалоо жана айрым edge-computing варианттарын кубат/нарк себептеринен улам азыраак кубат талап кылган чечимдер менен алмаштыруу бар. Бул өзгөрүүлөрдө сценарийдин баштапкы функционалдык максаты из байланышы менен сакталган.

Спецификациялардын канча бөлүгү аяктады?

Спецификация иштеп чыгуунун аягында сценарийден чыккан компоненттердин болжол менен %80 бөлүгү толук параметрлештирилген. Калган бөлүгү “flagged for validation” деп белгиленип, кийинки PoC текшерүүсүн талап кылган параметрлер ачык көрүнүп турган.

Бул %80 маани “продукттун %80 бөлүгү бүттү” дегенди билдирбейт. Булак сценарийден чыккан компоненттердин инженердик спецификациялар жагынан параметрлештирүү абалын гана билдирет. Бул жөнгө салуу, өндүрүш, ишенимдүүлүк сертификациясы же продукттун рынокко даярдыгы үчүн аяктоо пайызы эмес.

Процесс сапатынын жыйынтыгы

Жалпы аралык артефакттар дисциплиналар аралык талкууларды жөн гана жеке пикир алмашуудан чыгарып, сценарий, өз ара аракеттенүү, FR жана компонент байланыштары аркылуу көбүрөөк көзөмөлдөнүүчү сүйлөшүүгө айланткан. Miro чөйрөсү сценарийлерди, ырааттуулуктарды, талаптарды жана спецификацияларды бир визуалдык мейкиндикте көзөмөлдөөнү жеңилдеткен.

Лидерлик ар бир кадамда бир эле дисциплина тарабынан жүргүзүлгөн эмес. Баштапкы сценарийди чечмелөөдө жана күнүмдүк карталоодо UX/дизайн командалары көбүрөөк роль аткарса, FR чыгаруу жалпы көпүрө функциясын аткарган; компонент жана спецификация этаптарында инженердик лидерлик күчөгөн; spatial integration этабында дизайн менен инженерия кайрадан биргелешкен лидерликке өткөн. Булак бул SOSтун милдеттүү роль бөлүштүрүүсү эмес, учурдагы иш командасында байкалган үлгү экенин өзгөчө белгилейт.

Масштабдалуу маселеси

Сценарий, FR, компонент жана параметр саны көбөйгөн сайын көптөн-көпкө байланыш тармагы тыгыздалып, кол менен из башкаруу морт болуп калган. Булак ушул жерде визуалдык ачыктыктын пайдасы тыгыз из тармагын кол менен башкаруунун когнитивдик наркынан ашып кетиши мүмкүн болгон масштаб чегин байкаган.

Файлдарды Miroдон электрондук таблицаларга, талап тизмелерине жана башка документтештирүү чөйрөлөрүнө көчүрүү байланыштын үзүлүшү жана версиялардын айырмаланышы коркунучун жараткан. Ошондуктан команда айрым артефакттарды жандуу жалпы иш мейкиндигинде, туруктуураак артефакттарды версия көзөмөлдөгөн документтерде сактаган.

Процесс натыйжалуулугунун жыйынтыгы

SOS колдонуу болжол менен 11 айлык мезгилде жүргүзүлгөн. Биринчи сценарий баштан-аяк калибрлөө иши катары колдонулуп, андан кийин калган сценарийлер үч партия менен иштетилген. Алгачкы партиялар терминология, ажыратуу деңгээли жана из башкаруу али калыптана элек болгондуктан жайыраак жүргөн; кайталанган функциялар жана компоненттер пайда болгондо кийинки сценарийлерде кайра колдонуу мүмкүн болгон.

Экинчи жана үчүнчү партия жалпы он сценарийди камтып, болжол менен төрт–беш ай ичинде аяктаган. Булак бул ылдамдануу сценарийлердин арасындагы функционалдык кайталануу аркылуу болгонун белгилейт. Окшоштугу аз долбоорлордо ушундай ылдамдануу болору көрсөтүлгөн эмес.

Сценарийден чыккан компонент спецификацияларынын болжол менен %30 бөлүгү кеминде бир жолу кайра каралган; өзгөчө наркка сезимтал же техникалык жактан оор компоненттерде өзгөрүү болгон. Бул көрсөткүч “SOS %30 ката чыгарды” дегенди билдирбейт. Ревизиялар система интеграциясынын жана ишке ашыруу мүмкүнчүлүгүн баалоонун бөлүгү.

SOS процесс натыйжалуулугун өзү гана кепилдедиби?

Жок. Булак натыйжалуулуктагы утуштар ыкмадан гана келбегенин ачык белгилейт. Көзөмөлдөнүүчүлүктүн иштеши жалпы документтештирүү тартиби, артефакттарга жалпы ээлик, үзгүлтүксүз кайчылаш-функционалдык жыйындар жана сатып алуу/өндүрүш командалары менен эрте координация сыяктуу уюштуруучулук шарттардан көз каранды.

Структуралык текшерүү эмнени көрсөттү?

MR1 жана MR4 жагынан туруктуу идентификаторлор жөн гана аудит жазуусу эмес, ишке ашыруу мүмкүнчүлүгү боюнча сүйлөшүүлөрдө, компонент өзгөрүүлөрүндө жана spatial integration учурунда активдүү ой жүгүртүү каражатына айланган.

MR2 контексттик тактык семантикалык деңгээлде камсыз болгон, бирок embodied системада контекстти текст менен гана алып өтүү жетишсиз экени көрүнгөн. Өз ара аракеттенүү модалдуулугу, колдонуучунун физикалык кыймыл жолу, сенсор жайгашуусу жана монтаж чектөөлөрү контексттик тактыктын физикалык өлчөмүн ачкан.

MR3 иш агымы менен шайкештик инженерлер SOS артефакттарын түз өндүргөнү жана спецификация таблицалары PoC пландоодо жана сатып алуу иштеринде колдонулганы менен колдоого алынган.

MR5 жалпы көрсөтмө мейкиндиги да өзгөчө spatial integration учурунда күчтүү көрүнгөн, бирок бул функция уюштуруучулук жактан шарттуу бойдон калган. Жалпы иш тартиби же идентификатор башкаруу алсыз болсо, ошол эле артефакттардын ырааттуулугу сакталбай калышы мүмкүн.

Колдонууда пайда болгон MR6 деген эмне?

Баштапкы frameworkте MR1–MR5 гана бар кезде иш учурунда MR6: Traceability scalability, башкача айтканда көзөмөлдөнүүчүлүктүн масштабдалуусу, пайда болгон структуралык талап катары аныкталган. Артефакт тыгыздыгы өскөн сайын кол менен из башкаруунун координация жүгү көбөйгөн; чоң системаларда туруктуу идентификаторлор, визуалдык байланыштар жана жалпы мейкиндиктен тышкары курал-колдоолуу trace management муктаждыгы айкын болгон.

MR6нын булакта “emergent” болушу маанилүү. SOS башында алты мета-талап менен түзүлгөн эмес; алтынчы талап колдонуудагы масштабдалуу чектеринен келип чыккан.

Изилдөө колдогон жыйынтыктар

• SOS изилденген 15 сценарийлик өндүрүштүк иште сценарий–FR–компонент–спецификация чынжырын көзөмөлдөнүүчү түрдө курууну колдогон.
• Туруктуу идентификаторлор техникалык чечимдерди баштапкы сценарий контекстине кайра байлоодо активдүү каражат катары колдонулган.
• Контекстти алдыга алып өтүү техникалык чечимдердин колдонуучунун абалы жана колдонуу чөйрөсү менен байланышын көрүнүктүү сактоого жардам берген.
• Беш негизги SOS кадамы бардык 15 сценарийде колдонулган.
• Inferred action жана void action колдонмолору жетишпеген же азыр ишке ашпай турган жүрүм-турумду көрүнүктүү башкарууга мүмкүнчүлүк берген.
• Embodied робот контекстинде spatial integration деп аталган алтынчы кадам зарыл болгон.
• 144 FRди гармонизациялоо 69 негизги жана 75 сценарийге мүнөздүү FRге бөлүүгө алып келген.
• Алгачкы 72 сценарийден чыккан компонент ишке ашыруу мүмкүнчүлүгү текшерүүлөрү менен 65 компонент болуп консолидацияланып, 35 инженериядан чыккан компонент кошулуп, жалпы 100 компонент түзүлгөн.
• Сценарийден чыккан компоненттердин болжол менен %80 бөлүгү изилдөөнүн аягында толук параметрлештирилген.
• Сценарийден чыккан компонент спецификацияларынын болжол менен %30 бөлүгү кеминде бир жолу кайра каралган.
• Артефакт тыгыздыгынын өсүшү кол менен из башкаруунун масштаб чегин көрүнүктүү кылып, emergent MR6ны жараткан.

Изилдөө колдобогон жыйынтыктар

• SOS QFD, use case же башка талап/дизайн ыкмаларынан артык экени эксперименттик түрдө көрсөтүлгөн эмес.
• SOS продукттун иштөөсүн, ишенимдүүлүгүн, наркын же рынокко чыгуу убактысын белгилүү бир пайызга жакшыртат деп көрсөтүлгөн эмес.
• Изилдөө рандомизацияланган же салыштырма ыкма эксперименти эмес.
• SOS инженердик максаттуу маанилерди автоматтык эсептеген алгоритм же жасалма интеллект системасы эмес.
• SOS начар же жетишсиз даярдалган колдонуучу сценарийлерин өзүнөн өзү оңдобойт.
• Spatial integration бардык продукт түрлөрүндө милдеттүү алтынчы кадам экени көрсөтүлгөн эмес.
• Бир робот ишиндеги лидерлик бөлүштүрүү SOSтун милдеттүү уюштуруучулук түзүлүшү эмес.
• Болжол менен %80 параметрлештирүү мааниси продукттун %80 бүтүшүн же продукттун даярдык деңгээлин билдирбейт.
• Болжол менен %30 ревизия деңгээли ката деңгээли эмес.
• Экинчи жана үчүнчү партияда байкалган ылдамдануу бардык долбоорлордо ошол эле убакыт же деңгээлде процесс утушу болорун далилдебейт.
• SOS жөнгө салуучу шайкештикти, өндүрүш сертификациясын, ишенимдүүлүк текшерүүсүн же физикалык PoC сыноолорун алмаштырбайт.

Изилдөөнүн негизги күчтүү жактары

Биринчи күчтүү жак — ыкма концептуалдык түрдө гана сунушталбастан, активдүү өндүрүштүк долбоордо 15 ар башка сценарий боюнча узак мөөнөт колдонулган. Ошентип ыкманын теориялык кадамдары менен катар колдонууда чыккан бузулуулар, артка кайтуулар жана күтүүсүз ыңгайлашуулар да байкалган.

Экинчи күчтүү жак — эмпирикалык текшерүү менен структуралык текшерүүнүн бирге колдонулушу. Изилдөө “катышуучулар ыкманы жактырдыбы?” деген суроого гана эмес, дизайн принциптери башында аныкталган мета-талаптарды чындап кандай аткарганына да караган.

Үчүнчү күчтүү жак — акыркы спецификация таблицалары гана эмес; сценарий элемент таблицалары, interaction sequence mapтери, FR тизмелери, component matrixтери, specification sheetтери, байкоо жазуулары жана эксперттик маектер чогуу бааланган.

Төртүнчү күчтүү жак — ыкманын ийгилигин кемчиликсиз колдонуу менен гана баалабастан, inferred actions, void actions, spatial integration жана MR6 сыяктуу башында болбогон, бирок чыныгы колдонууда зарыл болуп калган ыңгайлашууларды ачык билдирген.

Негизги чектөөлөр

Бир гана иш: Изилдөө бир гана узак мөөнөттүү embodied-robotics долбооруна негизделет. Чыныгы өндүрүштүк процесстин көрүнүшү күчтүү болсо да, ар башка продукттарга жана уюмдарга жалпылоо чектелген.

Participant-observer коркунучу: Биринчи автор ыкманы колдонууда participant-observer болуп, сапаттык анализдин негизги жоопкерчилигин алган. Бул чечмелөө бир жактуулугунун потенциалын жаратат. Артефакт триангуляциясы, кошо авторлордун кароосу жана системалуу чечим жазуулары бул коркунучту азайтуу үчүн колдонулган, бирок толугу менен жок кылбайт.

Кирүүчү сценарийдин сапатына көз карандылык: SOS сценарий иштеп чыгуу ыкмасы эмес. Колдонуучу аракети, продукт жообу жана контексттик маалымат алсыз болсо, кийинки техникалык талаптар да жалпы жана жетишсиз болуп калышы мүмкүн.

Техникалык параметр чыгарбайт: Benchmark, маалымат баракчасы, жеткирүүчү текшерүүсү же инженердик сыноо болбосо, максаттуу маанилер TBD бойдон калышы мүмкүн.

Кол менен масштабдалуу: Из тармагы чоңойгон сайын Miro жана кол менен идентификатор башкаруу жетишсиз болуп калышы мүмкүн. Чоң долбоорлор атайын traceability жана version-control куралдарына муктаж болушу мүмкүн.

Уюштуруучулук көз карандылык: Ыкманын кызматташтык таасири жалпы артефакт мейкиндиги, туруктуу кайчылаш-функционалдык иш жана катышуучулардын итерацияга ачыктыгы сыяктуу уюштуруучулук шарттардан көз каранды.

Формалдуу trade-off эрежеси жок: SOS колдонуучу тажрыйбасы, нарк, коопсуздук, жөнгө салуу жана техникалык ишке ашыруу мүмкүнчүлүгүнүн ортосунда кайсы вариант “утушу керектигин” математикалык же формалдуу чечим эрежеси менен аныктабайт. Учурдагы иште бул карама-каршылыктар дисциплиналар аралык сүйлөшүү аркылуу чечилген.

Келечектеги изилдөө темалары

Булак келечектеги иштин беш негизги багытын аныктайт. Биринчиден, чоң артефакт тармактары үчүн dedicated digital environments, version control, визуалдык trace management жана адам көзөмөлүн сактаган AI-assisted же жарым автоматтык trace consistency механизмдери изилдениши керек.

Экинчиден, учурдагы TBD жана “flagged for validation” ыкмасына Low–Medium–High сыяктуу жеңил specification-confidence көрсөткүчтөрүн кошуу сунушталат. Бул көрсөткүчтөр маанинин канчалык бекем далилге негизделгенин жана кайсы параметр биринчи физикалык текшерүүдөн өтүшү керектигин көрүнүктүү кыла алат.

Үчүнчүдөн, SOS сапаттуу кирүүчү сценарийге көз каранды болгондуктан, сценарий жазуу синтаксисин жана инженердик колдонууга даяр сценарий стандартын иштеп чыгуу сунушталат. Өзгөчө өз ара аракеттенүү модалдуулуктары, колдонуучу каталары жана failure conditions сыяктуу өзгөчө учурларды сценарийлерде ачыгыраак көрсөтүү изилдениши керек.

Төртүнчүдөн, Steps 3 жана 4 кадамдарында коопсуздук, жөнгө салуу, нарк жана колдонуучу тажрыйбасы сыяктуу карама-каршы максаттарды чечүү үчүн структураланган decision heuristics жана rationale-capture механизмдерин иштеп чыгуу сунушталат.

Бешинчиден, SOS ар башка продукт түрлөрүндө, секторлордо, уюштуруучулук түзүлүштөрдө жана долбоор масштабдарында кайра колдонулушу керек. Өзгөчө жеңилирээк SOS колдонмосу качан жетиштүү жана толук алты кадамдуу түзүлүш качан керек экени али аныкталган эмес.

Verianla Live жагынан ылайыктуулук

SOS Verianla Live үчүн өзгөчө ыкма агымы жана көзөмөлдөнүүчү маалымат чынжыры жагынан ылайыктуу. 15 сценарий → 244 элемент → 104 өз ара аракеттенүү → 144 FR → 100 компонент → болжол менен 312 спецификация чынжыры source-faithful Live Process/Live Flow катары көрсөтүлүшү мүмкүн. Бирок булакта ар бир сценарий үчүн убакыт катарындагы сандык өлчөө жок болгондуктан, жасалма анимация убакыттары же аралык маалымат чекиттери чыгарылбашы керек.

Булак жана Ыкма Жөнүндө Эскертүү

Түпнуска аталышы: Scenario-Oriented Specification (SOS): a design method for translating user scenarios into engineering specifications.

Авторлор: Ulugbek Vahobjon Ugli Ismatullaev; KwanMyung Kim.

Авторлордун ирети: Ulugbek Vahobjon Ugli Ismatullaev биринчи автор, KwanMyung Kim экинчи автор.

Тең салым: Булакта тең салым/тең биринчи автор тууралуу билдирүү жок.

Жооптуу автор: KwanMyung Kim.

Мекеме: Department of Design, Ulsan National Institute of Science and Technology (UNIST), Ulsan, South Korea.

Журнал: Research in Engineering Design.

Басма: Springer Nature.

Булак түрү: Research Article; инженердик дизайн ыкмасын иштеп чыгуу жана өндүрүштүк ишти текшерүү изилдөөсү.

Том: 37.

Макала номери: 36.

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

Received: 25 Март 2026.

Revised: 20 Июнь 2026.

Accepted: 16 Июль 2026.

Published / Version of Record: 31 Август 2026.

Рецензия абалы: Research in Engineering Design журналында жарыяланган рецензияланган Research Article.

Preprint абалы: Берилген булак жарыяланган Version of Record PDF; булакта бул изилдөө үчүн өзүнчө preprint идентификатору көрсөтүлгөн эмес.

Лицензия: Creative Commons Attribution 4.0 International (CC BY 4.0).

Расмий жарыя шилтемеси: DOI 10.1007/s00163-026-00498-w аркылуу Springer Nature расмий макала жазуусу.

Негизги изилдөө суроосу: Колдонуучу сценарийлери контексттик маани жана көзөмөлдөнүүчүлүк сакталып, инженердик иш агымдары менен шайкеш кала тургандай дисциплиналар аралык командалар тарабынан кайталануучу түрдө инженердик спецификацияларга кантип системалуу которулат?

SOS негизги түзүлүшү: Беш баштапкы кадам: сценарий элементтерин аныктоо; interaction sequence түзүү; функционалдык талаптарды чыгаруу; компоненттерди тандоо; инженердик спецификацияларды аныктоо.

Колдонууда пайда болгон кеңейтүү: Step 6 — Spatial integration.

Баштапкы мета-талаптар: MR1 Bidirectional traceability; MR2 Contextual fidelity; MR3 Workflow compatibility; MR4 Repeatable translation; MR5 Shared representational space.

Колдонууда пайда болгон мета-талап: MR6 Traceability scalability.

Дизайн принциптери: DP1 Action-based traceability; DP2 Context propagation; DP3 Synchronized multi-view representations.

Негизги сценарий түзүлүштөрү: Actions, User(s), Goals, Settings, Tools жана Events; SOS коддоосунда Actions, UA жана PA болуп бөлүнөт.

Негизги из идентификаторлору: UA, PA, U, G, SET, T/E жана компонент коддору сыяктуу persistent identifiers.

Иш долбоору: Lemmy companion-care robot.

Долбоор мезгили: 2021–2025.

География: Түштүк Корея.

Баштапкы изилдөө сценарийи: 18.

Талапкер сценарий: 25.

Текшерилген сценарий: 15.

Persona: 3.

Талаа текшерүүсүнүн катышуучусу: 12 улгайган адам.

Сценарий иштеп чыгуу командасы: 12 дизайнер жана UX изилдөөчүсү.

Негизги SOS колдонуу командасы: 6 изилдөөчү.

Тармак адиси: 12 электр, механика, программалык камсыздоо жана бизнес адиси.

Негизги сценарий текшерүү куралдары: Терең маектер, contextual inquiry, focus groups, адабияттарды кароо, benchmarking, талаа сапары, foam mock-up жана high-fidelity prototype role-playing.

Колдонуу убактысы: Сценарий иштеп чыгуу аяктагандан кийин жана proof-of-concept прототиптөөдөн мурда.

Иш чөйрөсү: Башында физикалык whiteboard, андан кийин жалпы Miro workspace.

Эмпирикалык текшерүү өлчөмдөрү: Practical enactability, output quality, process quality, process efficiency.

Structural validation: MR1–MR5 менен DP1–DP3 ортосундагы байланыштардын реалдуу колдонуудагы ырааттуулугун изилдөө.

Негизги эмпирикалык материал: Scenario element tables, interaction sequence maps, functional requirement lists, function–component matrices жана specification tables.

Башка маалымат булактары: Participant observation, annotated artifacts, written notes, meeting minutes, participant reflections жана 12 адис менен semi-structured interviews.

FGCS: Framework-Guided Content Structuring; framework analysis менен сапаттык мазмун анализин SOS процедурасынын айланасында бириктирген төрт этаптуу структуралык анализ.

FGCS этаптары: Артефакттарды SOS кадамдары боюнча уюштуруу; элемент агымдарын көзөмөлдөө; четтөөлөрдү жана ыңгайлашууларды коддоо; сценарийлер аралык үлгүлөрдү синтездөө.

Тематикалык анализ: Алты этаптуу Braun–Clarke ыкмасы, first- жана second-cycle coding менен колдоого алынган гибрид deductive–inductive стратегия.

Тематикалык анализ этаптары: Familiarization; initial coding; re-coding; searching for sub-themes; reviewing and defining themes; producing the report.

Негизги колдонуу көлөмү: 244 коддолгон элемент; 59 UA; 79 PA; 106 контексттик элемент; 104 interaction; 144 FR; 100 component; болжол менен 312 engineering specification.

FR гармонизациясы: 69 recurring/basic FR + 75 scenario-specific FR.

Компонент өнүгүүсү: Адегенде 72 scenario-driven component; консолидациядан кийин 65; кошумча 35 engineering-driven component; жалпы 100.

Параметрлештирүү натыйжасы: Scenario-driven componentтардын болжол менен %80 бөлүгү изилдөөнүн аягында толук parameterized; калгандары “flagged for validation”.

Ревизия натыйжасы: Scenario-driven component specificationsтын болжол менен %30 бөлүгү кеминде бир жолу ревизияланган.

Колдонуу мөөнөтү: Болжол менен 11 ай.

Кийинки партиялардын ылдамдыгы: Экинчи жана үчүнчү партиядагы жалпы он сценарий болжол менен төрт–беш айда иштетилген; булак бул ылдамдануу кайталанган функциялар жана кайра колдонуу аркылуу болгонун, башка долбоорлордо ушундай ылдамдык кепилденбей турганын белгилейт.

Математикалык формула абалы: Булакта изилдөө натыйжасын чыгарган борбордук математикалык теңдеме жок. SOSтун FR чыгарууда колдонгон түзүлүшү математикалык формула эмес, чектелген табигый тил грамматикасы.

Статистикалык тыянак: Изилдөө ыкмалар аралык рандомизацияланган же көзөмөлдөнгөн сандык иштөө эксперименти эмес; негизги баалоо сапаттык учур анализи, артефакт көзөмөлдөө, descriptive counts, FGCS жана thematic analysis аркылуу жүргүзүлгөн.

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

Макулдук: Минималдуу тобокелдиктен улам жазуу жүзүндөгү informed consent документтештирүүсүнөн баш тартууга уруксат берилген. Маалыматтар de-identified түрдө анализденип, отчет берилген.

Маалымат жеткиликтүүлүгү: Маалымат топтомдору өндүрүштүк кызматташтыкка тиешелүү идентификациядан ажыратылган, бирок потенциалдуу сезимтал долбоор материалдарын жана адам катышуучуларды камтыган сапаттык маалымат болгондуктан коомчулукка ачык эмес. Алты SOS кадамы үчүн кеңири колдонуу көрсөтмөлөрүн жана шаблондорду камтыган practitioner manual жооптуу автордон суроо боюнча алынышы мүмкүн.

Автордук салымдар — Ulugbek Vahobjon Ugli Ismatullaev: Conceptualization; Methodology; Investigation; Data curation; Formal analysis; Validation; Visualization; Writing – original draft; Writing – review & editing.

Автордук салымдар — KwanMyung Kim: Conceptualization; Methodology; Validation; Supervision; Project administration; Funding acquisition; Writing – review & editing.

Каржылоо: Open Access funding UNIST тарабынан камсыздалып, уюштурулган. Изилдөө Republic of Korea Ministry of Trade, Industry and Energy (MOTIE) каржылаган Technology Innovation Program алкагындагы 20015056 жана RS-2025-04752997 номерлүү долбоорлор менен колдоого алынган.

Кызыкчылыктардын кагылышы: Авторлор competing interests жок экенин билдиришкен.

Негизги методикалык чек: Бир узак мөөнөттүү embodied-robotics иши transfer/жалпылоо дооматын чектейт.

Чечмелөө бир жактуулугунун чеги: Биринчи автор participant-observer ролунда болуп, сапаттык анализдин негизги жоопкерчилигин алган; тобокелдик артефакт triangulation, co-author review жана системалуу документтештирүү менен азайтылган.

Автоматташтыруу чеги: SOS техникалык максаттуу маанилерди өз алдынча чыгарбайт жана инженердик баамдын ордун баспайт.

Артыкчылык чеги: Изилдөө SOS альтернативдүү ыкмалардан артык экенин же downstream продукт иштөөсүн жакшыртарын көрсөтүүнү максат кылган эмес жана мындай салыштыруу жүргүзгөн эмес.

Колдонуу чеги: Ыкма системаны эрте аныктоо этабындагы өз ара аракеттенүүсү көп, контексти бай продукттар үчүн өзгөчө ылайыктуу көрүнөт. Өтө formal systems engineering, оор regulatory compliance же жалаң санариптик service logic менен башкарылган тармактарда башка же ылайыкташтырылган көрсөтмө түзүлүштөр керек болушу мүмкүн.