Requirements Framing Affects Design Creativity
نویسنده: راهول موهانی، بوراک تورهان و پل رالف
ترجمه: حلما بهبود، پژوهشگر حوزه دیزاین
قاببندی الزامات ونیازمندیها (چگونه) بر خلاقیت طراحی تأثیر میگذارد؟
یافتهها
پس از تعیین دو فیلتر در زمینه خلاقیت یعنی : اصالت و کارکرد. نیازها، خواستهها، ترجیحات و حدسهای ذینفعان پروژه را میتوان به روشهای مختلفی در قالب نیازها، داستانهای کاربر، سناریوها، الگوهای استفاده یا صرفاً ایدهها در نظر گرفت. تحقیقات نشان میدهند که قاببندی وظایف ساختاریافتهتر و بدون ابهام منجر به طرحهایی میشود که کمتر اصیل اما بیشتر کاربردی هستند با این حال، هیچ مطالعه قبلی ثابت نکرده است که آیا این پدیده در مهندسی نرم افزار کاربرد دارد یا خیر؟
بنابراین، هدف بررسی این امر بود که آیا یک تغییر کوچک در نحوه قالب بندی نیازمندی و خواستهها میتواند تفاوت قابل توجهی در نتایج (خلاقه) طراحی ایجاد کند یا خیر. نتایج آزمایشات بر روی این موضوع حاکی از این است که ارائه مجموعهای از خواستهها و نیازمندیها، تأثیر عمیقی بر عملکرد طراحی دارد و منجر به شکل گیری طرحهایی میشود که بیشتر کاربردی و کمتر اصیل هستند. بنابراین هنگامی که یک پروژه به نوآوری نیاز دارد – بایستی از رویکردها و الزامات قبلی فاصله بگیرد و برعکس، هنگامی که یک پروژه به راه حلهای سادهتر و کهن الگویی نیاز دارد، ارائه خواستهها و نیازمندیها بایستی بیش از پیش مورد بررسی قرار بگیرند. یافتههای درگیر در این مطالعات بایستی به صورت تصادفیسازیشده و کنترلشده، بررسی شوند ونیازمندیها و الزامات به خوبی لحاظ شوند.
بسیاری از این نتایج برای مهندسی نیازمندیها RE قابل پذیرش نیست، چرا که ارائه وضوح، دقت و ساختار بیشتر را برای موفقیت بسیار حیاتی میدانند. برخی از کارشناسان RE نمیتوانند قبول کنند که گاهی ابهام بیشتر میتواند نتیجه بهتری داشته باشد. احتمالا ریشه این موضوع در چشم انداز متفاوت تحلیلگران نیازمندی است. چرا که در ادبیات دانشگاهی مهندسی نیازمندی و طراحی این چشم انداز متفاوت شکل گیری و تقویت میشود. در RE، الزام و نیاز امری است که مورد درخواست است و موفقیت بر تحویل هر چیزی است که پیش تر در قالب الزامات و نیازمندی بر آن توافق شده است.
میتوان بین الزامات اجباری و اختیاری تمایزی ایجاد کرد تا هم برای کاربران و هم برای کسب و کار طرح رضایت بخش باشد. علاوه بر این، بررسی اثرات روانشناختی تقسیم بندی الزامات با برچسبگذاری نادرست نشان میدهد که استفاده از هر برچسب اضافی احتمالاً سردرگمی را افزایش میدهد و خلاقیت را محدود میکند. در RE، اغلب فرض بر این است که کاربران نیازمندیهایی دارند با این وجود تحقیقات تجربی تمرکز ساختار یافته بر این دیدگاه را تایید نمیکند. مردم معمولاً با ترجیحات پایدار و مرتبط از یک فهرست به سؤالات پاسخ نمیدهند. در طول مصاحبه، تحلیلگر و کاربر هستند که ترجیحاتی ناپایدار را با حضور یکدیگر شکل میدهند. اگرچه بسیاری از محققان RE پیشنهاد کردهاند که الزامات از مجموعهای از نظرات، باورها، خواستهها یا ترجیحات متناقض هستند، بسیاری از تحقیقات RE همچنان بر این فرض ادامه میدهند که الزامات استخراج شده و برچسب زدن به یک اولویت زودگذر به عنوان یک نیاز، هم اهمیت تخمینی آن و هم اعتماد ما به آن برآورد را افزایش میدهد.
با این وجود چنین الزاماتی برای یک طراح، تصویری نادرست از زمینه پروژه ترسیم میکنند. یک رابطه عکس قوی بین ساختار مسئله و اصالت طراحی وجود دارد. سوال واضحی که پیش میآید این است که چرا این اتفاق می افتد؟ چرا مفاهیم طراحی تولید شده در پاسخ به قاب بندیهای صلب و رسمی کمتر اصیل هستند. تحقیقات قبلی در مورد تثبیت طراحی نشان میدهند که ارائه نمونههای واضح به طراحان خلاقیت آنها را کاهش میدهد. قاب بندی خواستهها به عنوان الزامات به طور مشابه اصالت را کاهش میدهد، وضعیتی شکل میگیرد که مشابه تثبیت طراحان استفاده از تواناییهای خود را به دلیل سوگیری ناشی از موقعیت محدود میکنند.
با این وجود، برخی از طراحان نسبت به اصالت تعصب دارند و طراحان خبره تمایل دارند بدون توجه به قاب بندی، با خواستهها و محدودیتها با تردید بیشتری برخورد کنند. به عبارت دیگر، اهمیت و اطمینان بالا که در اصطلاح الزام نامیده میشود، همراه با یک ترتیب از پیش تعیینشده (یعنی اولویتبندی)، با ترویج این دیدگاه که مشکل از قبل به خوبی درک شده و تا حد زیادی حل شده است، پتانسیل خلاق شرکتکنندگان را از بین میبرد. قاب بندی و چارچوببندی نیازمندیها، شرکتکنندگان را وادار میکند تا به جای کاوش در فضای راهحل، روی خواستههای اعلامشده تمرکز کنند.
این امر ما را به این نظریه سوق داد که متخصصان نرمافزار مستعد تثبیت الزامات هستند و تمایل زیادی برای تکیه بر خواستههایی که صریحاً به عنوان الزامات در نظر گرفته شدهاند دارند.
برخی از علائم تثبیت نیازها و الزامات عبارتند از:
- عدم پرسش از خواستههای مشکوک، مبهم یا متضاد.
- ادراک خواستهها به عنوان دارای اهمیت یکسان (وبالا).
- درک خواستهها با اعتبار یکسان.
- عدم در نظر گرفتن تفاوت بین اهداف پروژه و خواستهها.
- عدم در نظر گرفتن خواستههای ضمنی یا غیرعملکردی.
اطلاعات برآمده از تحقیقات در این رابطه حاکی از تثبیت واسط بین قاب بندی و عملی بودن و کارکردی بودن طرح هستند، نه اصالت طرح.
در حالی که تحقیقات RE به طور سنتی بیشتر بر روی کیفیت مشخصات نیازمندیها متمرکز هستند، ارائه اطلاعات به عنوان عامل تاثیرگذار نیز اهمیت دارد. ارائه نه تنها شامل تکنیکهای مدلسازی (مانند موارد استفاده، سناریوها، مدلهای هدف، مدلهای عامل، بیانیههای IEEE- شامل جملاتی نظیر «سیستم باید…») میشود، بلکه زبان مورد استفاده برای انتقال اطلاعات هم محسوب میشود.
تحقیقات RE به طور سنتی بر اولویتبندی خواستهها و تمایز خواستههای اجباری (یعنی نیازها) از خواستههای اختیاری (یعنی خواستهها) متمرکز است. تکنیکها یا ابزارهایی ارائه، تحلیل و رسیدگی به وظایف طراحی نامناسب هستند. توصیه میشود خواستههای کمتر قطعی و کماهمیت را به گونهای ارائه شوند که شکگرایی را ترویج کند و متناسب با زمینه باشد. سؤالات متعددی را برای تحقیقات آینده وجود دارد، از جمله اینکه چگونه اطمینان و اهمیت ابرداده بر خلاقیت و کارکردی بودن تأثیر میگذارد.
خواستهها باید کمتر به شکل رسمی قاب شوند. شاید حتی برای القای شک و تردید. با این حال، مدلسازی خواستهها به طور رسمیتر ممکن است منجر به راهحلهایی شود که کارکردی هستند. متخصصان بایستی تشویق شوند که ارائه مناسبی را برای ارائه استفاده کنند (داستانهای کاربر، شخصیتها، سناریوها، و غیره). هدف این مطالعه نادیده گرفتن نیازهای واقعی توسط طراحان نیست، بلکه تشویق آنها به ارزیابی انتقادی و تشخیص نیازهای واقعی از موارد مشکوک برای تولید راهحلهای خلاقانهتر است. متخصصان میتوانند دو ویژگی را به همین منظور در نظر بگیرند: اهمیت و اطمینان.
اهمیت به این موضوع اشاره دارد که موفقیت در زمینه مطرح شده، تا چه اندازه حیاتی است و اطمینان به ارتباط قطعی خواستهها با مسئله اشاره دارد. برچسب زدن به خواستههای کم اهمیت و با اطمینان کم به عنوان الزامات مشکلسازتر از برچسب زدن به خواستههای کم اهمیت و با اطمینان بالا خواهد بود. برای ارتقای خلاقیت و نوآوری، باید برای مواردی که دارای اهمیت بالا و شواهد پشتیبان کافی هستند، در نظر گرفته شوند. این تصور که تحلیلگران نیازمندیها را استخراج میکنند و طراحان آن نیازها را به طراحی سیستم تبدیل میکنند، به سادگی گمراه کننده است.
آموزش SE باید درک زیربنای روانشناختی و تحلیل نیازمندیها را تشویق کند، طوریکه، تحلیلگر الزامات را به عنوان همراهی با ذینفعان لحاظ کند، و نه کشف یا استخراج یک واقعیت عینی. زبان RE اختلافات و ابهامات موجود در پروژههای نرمافزاری را پنهان میکند و منجر به درک نادرست خواستهها میشود. چندین پیشنهاد برای پیشرفت آموزش SE پیشنهاد عبارتند از: 1) آموزش بیشتر در تکنیکها و رویکردهای خلاقیت محور 2) پیشبرد پروژههای مبهمتر و مشکلات بد ساختار با مشخصات رسمی کمتر 3) قرار گرفتن بیشتر در معرض نظریهها و تکنیکهای مناسب برای زمینههای مبهم با سهامداران متضاد، مانند نظریه عامل- شبکه و روششناسی سیستمهای نرم و منعطف.
نتیجهگیری
هدف از این تحقیق بررسی این سوال بود که آیا قاببندی الزامات و خواستهها بر خلاقیت طراحی دارند؟ که در نهایت مشخص شد که قاب بندی خواستهها بهعنوان الزامات یا الزامات اولویتبندی شده به طور قابلتوجهی بر خلاقیت طراحی تأثیر میگذارد. که در دو گزاره کلی قابل جمع بندی است:
1- الزامات منجر به خروجیهایی میشود که کمتر اصیل اما کاربردیتر هستند.
2-طراحان به شدت مستعد تغییرات جزئی در ارائه و زبان، برای برقراری ارتباط بهتر با خواستهها هستند.
در تحقیقات قبلی در مورد تثبیت، تمایل به تکیه شدید بر خواستههایی که به عنوان الزامات قاب بندی شدهاند، مشخص شده بود. طراحان دچار تثبیت بر ویژگیهای نمونههای داده شده میشوند و روی خواستههای داده شده تمرکز میکنند.
تغییرات جزئی در زبان مورد استفاده برای برقراری ارتباط با خواستههای مورد نظر میتواند عملکرد شناختی طراحان را تغییر دهد و به نتایج بسیار متفاوتی منجر شود. علاوه بر این، طراحان به عدم اتکا به الزامات و ارزیابی انتقادی خواستههای ارائه شده به عنوان الزامات برای تولید راهحلهای خلاقانهتر تأکید دارند و تثبیت نیازها ممکن است با ارائه خواستهها به صورت مبهم، غیررسمی و نامطمئن کاهش یابد.
منابع:
Mohanani, R., Turhan, B., & Ralph, P. (2019). Requirements framing affects design creativity. IEEE Transactions on Software Engineering, 47(5), 936-947.
Mohanani, R., Ralph, P., Turhan, B., & Mandić, V. (2021). How templated requirements specifications inhibit creativity in software engineering. IEEE Transactions on Software Engineering, 48(10), 4074-4086.