3-7-1-2- معایب فریم‌های مشکل
اول در عمل یک هدف امنیتی می‌تواند از طریق کاهش، شناسایی یا واکنش به تهدید ویژه تحقق پیدا کند اما نیازمندی‌ها برای این‌چنین تهدیداتی نمی‌توانند به آسانی به عنوان محدودیت‌ها مدل شوند. علاوه بر آن، نمایش امنیت به عنوان محدودیت می‌تواند نیازمندی‌های امنیتی را در مقابل قابلیت کاربری قرار دهد، به جای آنکه امنیت را به عنوان تقویت کننده نیازمندی‌های قابلیت کاربری در نظر بگیرد. این رویکرد امنیت را به عنوان محدود کننده‌ها در نظر می‌گیرد.
دوم، فریم‌های مشکل، محیط فیزیکی را یکتا فرض می‌کنند. مفهوم زمینه برای چشم اندازی از جهان مشکل که اخیراً مدل شده‌است معین و مشخص است.
سوم، رویکرد‌های فریم‌های مشکل منکر تکنیک‌های استفاده شده برای استخراج داده هستند. اگرچه هالی و دیگران( 2008)، استفاده از مباحث امنیتی برای اثبات فرضیات تصمیمات امنیتی را پیشنهاد می‌کند. دانش آسیب پذیری‌های زمینه‌ای ممکن است در یک دیاگرام مشکل کلی، گم شود.
در نهایت، فریم‌های مشکل در حوزه خارج از تحقیقات مهندسی نیازمندی‌ها زیاد پذیرفته نشده‌اند. یک مطالعه مقایسه‌ای استفاده ازUML و فریم‌های مشکل (وینسنت216، 2008) نتیجه می‌گیرد که حرفه‌ای‌های حوزه‌هایی غیر ازIT، فریم‌های مشکل را بسیار نامفهوم ارزیابی کرده‌اند.
علاوه بر آن، حرفه‌ای‌هایIT، در ارائه دیاگرام فریم‌های مشکل به ذینفعانی که با مسائل IT آشنایی ندارند راحت نبودند. نکته نهایی این است که اغلب رویکردهای این فریم‌ها هنوز خارج از کمیته تحقیقی استفاده نشده‌اند. فریم‌های مشکل به آنالیست‌ها امکان مدل کردن دامنه‌های پیچیده با استفاده از مدل‌های مختصر و مفید را می‌دهند. این مدل‌ها دانش دامنه‌ای زیادی را در خود تجمیع می‌کنند که
درک و کارکردن با آنها را بدون داشتن دانش در مورد رویکرد و دامنه مشکل تقریباً ناممکن می‌کند. در مقایسه، دیاگرام کلاس UML، مدلی از طبقه بندی کننده‌ها و وابستگی میان آنهاست؛ در نتیجه دیاگرام کلاس UML نیاز به آگاهی کمتری نسبت به دیاگرام فریم‌های مشکل دارد.
3-7-2- رویکرد‌های هدف محور
مهندسی نیازمندی‌های هدف محور217 به استفاده از اهداف برای استخراج نیازمندی‌ها، ارزیابی، مذاکره، پیچیدگی ساختار بندی، مستند سازی، آنالیز و تکامل تدریجی اشاره دارد. (لمسوئیرد218، 2009)
در این بخش یک نمونه را که روی کشف اهداف و نیازمندی‌ها تمرکز دارد و با چهارچوب KAOS مشخص شده‌است، بازبینی می کنیم.
2-
3-
3-7-
3-7-2-
3-7-2-1- KAOS
روش219KAOS (داردنه220 و دیگران، 1993) یک رویکرد سیستماتیک برای آنالیز، شناسایی و ساختاربندی اهداف و نیازمندی‌ها است. این رویکرد بر اساس مدل کردن اهداف به صورت بالا به پایین221 و پایین به بالا222 استوار است.
KAOS، هدف را به عنوان قصد و نیتی که سیستم باید از طریق مشارکت عواملش به آنها دست یابد تعریف می‌کند. (لمسوئیرد، 2009) این عوامل ممکن است کامپوننت‌هایی از یک سیستم بزرگ یا بشر یا ماشین باشند.
هدف می‌تواند رفتاری223یا نرم224 باشد. اهداف رفتاری، رفتارهای سیستم را تعیین می‌کنند و ممکن است اهداف دست یافتنی یا پشتیبانی باشند. اهداف دست یافتنی رفتارهایی که سیستم باید دیر یا زود به آنها دست یابد را معرفی می‌کند. در حالیکه اهداف پشتیبانی رفتارهایی از سیستم که همیشه باید وجود داشته باشد را تعیین می‌کند. اهداف نرم ترجیحات میان رفتارهای سیستم را تعیین می‌کنند و معمولاً با کلمات کلیدی مانند افزایش یا کاهش به جای دست یافتنی یا پشتیبانی معرفی می‌شوند.
یک مدل هدف KAOS یک گراف تفسیری هدف است که از طریق لینک‌های و/یا225 بهم مرتبط شده‌اند، برای مثال در مورد لینک‌های”و”، همه زیر اهداف لینک شده به هدف پدر، باید قبل از برآورده شدن هدف پدر برآورده شوند.
اهداف ممکن است به وسیله ویژگی‌های دامنه پالایش شوند. اهداف همچنین می‌توانند به وسیله عملیات سیستم که تغییرات در وضعیت سیستم ایجاد می‌کنند عملیاتی شوند. (اسپیوی226، 1992)
2-
3-
3-7-
3-7-2-
3-7-2-1-
3-7-2-1-1- معایب KAOS
KAOS منکر پروسه استخراج نیازمندی‌ها و مدل کردن زمینه‌ای است. ضعف استخراج نیازمندی‌ها در KAOS عمیق‌تر شده‌است زیرا استفاده از بحث امنیت (هالی و دیگران، 2008) و آنالیز ریسک (چمیت227، 2010) چند راه برای چک کردن سلامت داده‌ها قبل از مدل کردن را ارائه می‌دهد. اما با KAOS، ارزیابی پروسه مدل کردن اهداف هیچ پشتگرمی در مورد اعتبار اهداف نمی‌دهند.
3-7-3- رویکردهای عامل محور228
آغاز رویکردهای عامل محور به کار چانگ و دیگران229روی چهارچوب NFR230 (چانگ، 2007) باز می‌گردد. اساس چهارچوب NFR طراحی سیستم‌هایی است که با نیازمندی‌های غیر عملکردی مانند امنیت، دقت و کارائی درگیر می‌باشد.
چانگ و دیگران تقویت استخراج نیازمندی‌های عملیاتی، با فعالیت‌هایی در جهت شناسایی، تجزیه و تحلیل و عملیاتی کردن اهدافی که مشکلات غیر عملکردی را منعکس می‌کنند را پیشنهاد می‌کنند. اگرچه نیازمندی‌های غیرعملکردی اغلب کامل مشخص نیستند و ممکن است به عنوان اثرات جانبی دیگر اهداف شناسایی شوند.
3-7-3-
3-7-3-1- I*
چهارچوب I*231 یک رویکرد عامل محور در مهندسی نیازمندی‌ها است. I* برای تمرکز روی مهندسی نیازمندی‌ها در مراحل ابتدایی تبیین شده‌است. هدف از I* مدل کردن و آنالیز علاقه مندی‌های ذینفعان و چگونگی جایگزینی متغیرهای محیطی و سیستمی است. (یو232، 1997)
اگر یک بازیگر قصد رسیدن به هدف را داشته باشد، می‌تواند به وسیله انجام دادن وظیفه یا به وسیله متکی بودن به دیگر بازیگران برای رسیدن به هدف یا منابع یا وظایف لازم برای رسیدن به هدف، به هدف دست یابند. این‌ها می‌تواند با استفاده از مدل‌های استراتژیک وابستگی مدل شده باشد.
I* همچنین از مدل منطق استراتژیک، که در آن پیوند‌های داخلی معرف وابستگی‌های استراتژیک هستند، پشتیبانی می‌کند. I* اجازه مدل کردن و مطرح کردن تصمیمات طراحی سطح بالا را در مراحل ابتدایی می‌دهد. (یو، 1997)
3-7-3-2- Tropos
Tropos یک پروسه طراحی عامل محور طراحی شده برای به حداقل رساندن فاصله‌های میان مدل کردن هدف، طراحی معماری و پیاده سازی سیستم‌ها است. به حداقل رساندن این فاصله‌ها حدالامکان از طریق به کار بستن مفاهیم بازیگران، اهداف و وظایف و مفاهیم مرتبط میان همه مراحل پروسه طراحی ایجاد می‌شود. Tropos به وسیله فعالیت‌های زیر توصیف می‌شود: آنالیز نیازمندی‌های ابتدایی، آنالیز نیازمندی‌های تازه، طراحی معماری، طراحی جزئی. (برسیانی233 و دیگران، 2004)
3-7-3-2-1- بسط‌های امنیتی
اخیراً در هر دو زمینهI* و Tropos تحقیقات زیادی انجام شده‌است. الاهی و دیگران234 (الاهی، 2010) بحث می‌کنند که بازیگران، منابع و وظایف مترادف با دارایی‌ها هستند زیرا آنها ارزش را برای یک سازمان حفظ می‌کنند و می‌توانند هدف حمله کنندگان باشند.
Tropos امن (مراتیدیس235 و گیارجینی236، 2007) روش Tropos را به چندین روش توسعه می‌دهد. اول چندین مفهوم برای نشان گذاری مدل کردن اضافه شده‌است. این‌ها شامل محدودیت‌های امن که راه حل‌های ممکن را محدود می‌کنند، وابستگی‌های امنیتی برای نمایش روابط وابستگی محدودیت‌های امنیتی و اهداف امن برای دست‌یابی به محدودیت امنیتی می‌شود. علاوه بر مفاهیم جدید، تعدادی فعالیت‌های مدل کردن جدید نیز برای پشتیبانی از فازهای مختلف Tropos اضافه شده‌اند.
3-7-3-2-2- معایب
مفهوم وظایف امنیتی گسسته ممکن است دلیل دقیق نبودن این وظایف باشد و رفتارهای مرتبط امنیتی ممکن است در میان وظایف نرمال پراکنده شده باشند. از دیدگاه قابلیت استفاده، در نظر گرفتن امنیت به
عنوان یک هدف غیرعملکردی، امنیت و قابلیت کاربری را در یک سو در نظر می‌گیرد. ارزیابی اخیر از اثر بخشی تصویری I* (مودی و دیگران، 20089) گویای پیچیدگی گرافیکی آن است. گزارشات اخیر
مودی237 (نوردباتن238 و ای. کراسبی239، 1999)، بیان می‌کند که ‌این پیچیدگی ممکن است دلیل کاهش معنی دار درک دیاگرام‌های مهندسی نیازمندی‌ها به ویژه به وسیله تازه کارها باشد. ورینگلی240 (2010) علامت گذاری عناصر امنیتی را گسترش می‌دهد. مدل کردن دقیق زمینه اجتماعی با عمق مناسب برای حل مشکلات قابلیت کاربری، ممکن است با رویکردهای I* نامناسب باشد. یو (1997) بیان می‌کند که هر مدل I* چشم اندازی از دید کاربران را نمایش می‌دهد. در نتیجه، یک مدل کامل، بازیگران زیادی دارند و از هر دیدگاهی، نظر بازیگری را پوشش می‌دهند.
یو (1997) پیشنهاد می‌دهد که اگر مصاحبه‌ها انجام شده باشند. مدل‌های اینچنینی می‌توانند از چشم انداز هر بازیگر ایجاد شده باشد. اگر چه ‌اینگونه مدل‌ها منجر به مشکلات مدیریتی مدل ناشی از سایز و کیفیت مدل‌های مختلف شده و لزوم وفق دادن مدل‌های مختلف در آنها اجتناب ناپذیر است. پروسه ادغام مدل‌هایTropos و I* مختلف ممکن است منجر به دانش مفید درباره دامنه و زمینه اجتماعی استفاده شود. (استربروک و دیگران، 2005)
3-7-4- رویکردهای سناریو محور
رویکردهای سناریو محور در مهندسی نیازمندی‌ها، برای فعالیت‌هایی مانند استخراج نیازمندی‌ها، ارزیابی و حتی مستند سازی نیازمندی‌ها محبوب هستند. تقریباً اغلب رویکردهای شناخته شده موردهای کاربرد241 جکوبسن242هستند. (کراچتن243، 2003)
3-7-4-1- مورد کاربرد
موردهای کاربرد، رشته‌ای از عملیات سیستم هستند که عملیات یک بازیگر، شخص یا هر چیز خارج از سیستم که با سیستم در تعامل است را نمایش می‌دهد. (کراچتن 2003) این رشته از عملیات به عنوان تعاملی میان سیستم و بازیگر توصیف شده‌است. لزوماً، موردهای کاربرد بیشتر از سناریوها نیستند. یک قالب رسمی‌تر نیز برای تکمیل مورد کاربرد توسط ککبرن244 (2001) پیشنهاد شده که‌این قالب شامل اهداف مورد کاربرد، مراحل سناریو اصلی و نرمال، سناریو‌های ناپایداری که شاخه‌ای از سناریو اصلی هستند، استثناها، پیش شرط‌ها و پس شرط‌ها و محدودیت‌های ویژه مورد کاربرد می‌شوند.
3-7-4-2- موردهای استفاده نادرست و سوء استفاده245
مسیندر و آپدایر246 (2005) توسعه نظریه مورد کاربرد برای پشتیبانی از رفتار سیستم ناخواسته را پیشنهاد داده‌اند. این‌چنین رفتارهایی می‌تواند از طریق یک سوء استفاده نمود پیدا کند.
راحت‌ترین راه‌ایجاد مورد سوءاستفاده، آگاهی گرفتن از خبرگان امنیت با روش طوفان ذهنی و با سؤال پرسیدن درباره سیستم‌های شبیه و ضعف‌های آنها است. این فعالیت‌ها راه‌هایی که ممکن است حمله کنندگان به آن فکر کنند، منعکس می‌کنند. (هپ247 و دیگران، 2004)
روش دیگر مشابه مورد استفاده نادرست است: تعاملی میان سیستم و یک یا چند بازیگر، که نتایج تعامل برای بازیگران یا دیگر ذینفعان مضر است. (ام سی درمات وفاکس248، 1999) مورد سوء استفاده ومورد
استفاده نادرست هر دو سناریو محور هستند و می‌توانند به طور گرافیکی در دیاگرام مورد کاربرد ارائه شوند. تمایز میان مورد سوءاستفاده و استفاده نادرست خیلی لطیف است. سیندر و آپدایر ادعا می‌کنند که قالب‌های متنی استفاده شده در هر دو متفاوت است.
3-7-4-3- معایب
نگرانی بر آمده از (سیندره و اندرسن، 2005) امکان مقیاس پذیری مسائل زمانیکه با تعداد زیادی از تهدیدها در ارتباط هستند و مشکلات ناشی از آن که ممکن است نیاز به راهنمایی‌های بیشتری برای اولویت بندی نیازمندی‌ها، به جای مورد‌های سوء استفاده فی‌نفسه داشته باشد. مورد کاربرد اقدام متقابل، مورد سوء استفاده و آسیب پذیری‌های جدید را کاهش می‌دهد. ممکن است این اثر تنها به وسیله مطالعه متن موردهای کاربرد مربوطه احساس شود.
3-8- مشخصات چهارچوب

دسته بندی : No category

دیدگاهتان را بنویسید