تحقیق درمورد نیازمندی‌ها، نرم افزار، طراحی کاربر محور

دیگر، کوپر در (کوپر، 1999) معتقد است که مهندسی نیازمندی‌های ضعیف به عنوان قسمتی از طراحی قابلیت کاربری و پاسخ به درخواست برنامه نویسان برای ویژگی‌های نیاز‌های کاری ممکن است به همان اندازه مقصر دانسته شود.
در نتیجه به همان اندازه که ممکن است (کوپر، 1999) تأیید شود، به همان اندازه نیز ممکن است رد شود، یک تعصب ضد تکنولوژیست مشابه نیز در تیمبلبی (2007) مشاهده می‌شود که ادعا می‌کندحرفه‌ای‌های قابلیت کاربری متعصبانه معتقدند که تکنولوژیست‌ها منشأ مشکلات قابلیت کاربری هستند و این مشکلات می‌تواند از طریق کاربر محور بودن و رفتار کردن به عنوان نمایندگان کاربر حل شود.
سوم: رویکردهای کاربر محور ممکن است در برخی موارد از نظر شناختی ضعیف باشند. چاپمن و میلهام191 (2006) بحث‌های مقدماتی کمی از تکنیک Persona را گزارش می‌دهد. بنابراین ممکن است تأیید دقت آنها ممکن نباشد. علاوه بر این، از آنجاییکه Persona‌ها نمایش‌های افسانه‌ای هستند و راه ساده‌ای برای تحریف آنها وجود دارد، بنابراین، اگر یک Persona با استفاده از روش‌های سؤال برانگیز یا داده‌های با دقت پایین برنامه نویسی شده باشد، تکذیب کردن اعتبار Persona سخت است. در (چاپمن و میلهام، 2006) نویسنده بیشتر در مورد معایب و مزایای Persona‌ها صحبت کرده است.
چهارم: تمرکز مقدماتی برای رسیدن به اهداف و وظایفی که کاربر نیاز به دسترسی به آنها دارد، ممکن است باعث نتیجه گیری جامع در مورد کیفیت طراحی تعاملی شود. نورمن (2005) ادعا می‌کند که مثال‌های زیادی از تکنولوژی فعالیت‌هایی که با موفقیت طراحی شده، به نسبت کاربرانی که به تنهایی فعالیت‌ها را انجام می‌دادند وجود دارد. این بدین معنی است که نیاز به وفق دادن تکنولوژی به نسبت راه‌های دیگر اطرافمان داریم. نورمن بحث می‌کند که رویکرد‌های کاربر محور ممکن است مضر باشد زیرا تمرکز کاربران را بر اهمیت فعالیت‌هاشان می‌کاهد. علاوه بر این، تن دادن به نیاز‌های کاربر ممکن است منجر به طراحی‌هایی با پیچیدگی بالاشود.
کاربری که به طور بالقوه طراح را در مورد زمینه اجتماعی کار خود آگاه نمی‌کند، خطر بزرگی را متوجه طراحی می‌کند. (لیام جی. بنن، 1991) بنن نزدیک به دو دهه پیش به ‌این نکته توجه می‌کند که تحقیقات HCI به تمرکز روی نیازهای کاربران فردی گرایش دارند و اهمیت هماهنگی میان پروسه‌ها نادیده گرفته شده‌است. از آن زمان به بعد جامعه 192CSCW، به‌این نکته توجه کردند که تکنولوژی فعالیت‌های اجتماعی نیاز به پشتیبانی از جهات گوناگون دارد. علاوه بر این شناخت به وجود آمده از
سیستم‌های فرض شده، به وسیله طراحان نگهداری نشده‌است. مخصوصاً زمانیکه کاربران به دلیل اهداف پنهان در برابر بیان کردن آن مقاومت کنند. (مارک اس. آکرمن، 2000) تلاش‌هایی برای ایجاد تکنیک‌های طراحی استخراج این‌چنینی انجام شده که از این دسته، (بیر وهلتزبلت، 1998) را می‌توان نام برد. ملند193 و دیگران ادعا می‌کند که تنش، زمانی به وجود می‌آید که امکان وفق دادن وجود داشته باشد. زیرا مهندسین در مورد ترکیب تکنیک‌ها نگران هستند نه تجزیه و تحلیل. (رندال و دیگران، 1979) کارهای اخیر برای وفق دادن خروجی‌های طراحی کاربر محور در زمینه فعالیت‌های مشارکتی مانند (ملند و دیگران، 2008) آغاز شد. اما تأثیر مقیاس پذیری خروجی‌های طراحی فرد گرا در پشتیبانی از فعالیت‌های مشارکتی ناشناخته باقی مانده است.
نکته نهایی که توسط تیمبلبی (2007) بیان شده، این است که شناخت در مورد مشکلات قابلیت کاربری از تمایل داشتن برای حل و توانایی حل آنها متفاوت است. دانستن اینکه مشکلات قابلیت کاربری وجود دارد اگرچه مهم است، اما به خودی خود کافی نیست. این بدین دلیل است که به نظر می‌رسد تکنیک‌های طراحی کاربر محور تنها در دنیای خارج و روی رابط کاربری، بدون در نظر گرفتن میزان مفید بودن ویژگی‌های رسمی، برای مدل کردن پیچیدگی و ابهام تمرکز دارند. به همین دلیل، طرفداران HCI ویژگی‌های مهندسی نرم افزار را با HCI می‌آمیزند.
3-6-5- مهندسی نرم افزار بشر محور
نیاز به اصول مهندسی برنامه نویسی در کنار فاکتورهای بشری دو دهه پیش توسط دوول و لانگ194 (1989) پیشنهاد داده شد. دوول و لانگ بحث می‌کنند که از آنجاییکه طراحی قابلیت کاربری به صورت ضعیفی در پروسه‌های مهندسی نرم افزار یکپارچه شده‌اند، برنامه نویسان تصمیماتی را اتخاذ می‌کنند که بدون در نظر گرفتن ویژگی‌های قابلیت کاربری بر روی قابلیت کاربری سیستم اثر می‌گذارد. وظایف، ابزارهایی هستند که سیستم کاری به واسطه آنها، دامنه برنامه را تغییر می‌دهد و سیستم به اهداف و حالت‌های آینده که باید به آن نائل شود، می‌رسد. ایجاد تمایز میان اهداف کاربر و اهداف سیستم شبیه کشیدن خط میان HCI و مهندسی نرم افزار است.
کارهای انجام شده در جهت اشتراک این دیسیپلین‌ها، قوت‌ها و ضعف‌های هر کدام را بیان می‌کنند. همین‌طور یک رویکرد یکپارچه، برای یکسان کردن طراحی، پیاده سازی و ارزیابی اصول هر دو دیسیپلین، ممکن است منجر به استفاده مؤثر از فعالیت‌های طراحی قابلیت کاربری در مهندسی نرم افزار شود. (سفاه و متزکر ، 2004)
یک راه حل مشکل یکپارچه سازی HCI و مهندسی نرم افزار، پذیرفتن نشان گذاری و تکنیک‌های معمول است. برای مثال طراحی کاربر محور (کنستانتین، 2006) تعامل نقش‌های کاربر و سیستم را با سناریو‌های ساختار یافته که «مورد‌های کاربری حیاتی» نامیده می‌شوند مدل می‌کند. طراحی کاربر محور، همچنین چندین نماد سازی برای مدل کردن با UML مانند (اریکسون195 و پنکر196، 2000) را با
هم یکی می‌کند. گولیکسن ودیگران 197 (2005) معتقدند که پذیرفتن رویکرد تولید مدل این‌چنینی،
ممکن است به کاربر حق انتساب از نقش همکار طراح به آگاهی دهنده را دهد. به طور مشابه تیمبلبی روی تفاوت میان مهارت‌های حرفه‌ای مرتبط با طراحی کاربر محور و دیگر رویکردهای مهندسی تأکید می‌کند و تحقیقات انجام شده و ریسک‌های دوگانه صنعتی طراحان تعاملی و مهندسی را از روش‌هایی مانند بحث کوپر در مورد Persona، جدا می‌کند. (تیمبلی، 2007)
از چشم انداز امنیت، هر دوی زمینه و ذینفعان ممکن است منابع مهمی از داده‌ها درباره حملات و آسیب پذیری‌های عمده و همچنین قابلیت کاربری و عملکردی باشند. بنابراین نمادسازی سناریوها و مدل کردن به تنهایی ممکن است برای ترکیب قابلیت کاربری و امنیت در جهت طراحی مناسب کافی نباشد.
ساتکلیفه198 (2005) سنت‌های موجود در HCI و مهندسی نرم افزار را با مسائل طراحی تئوری مقایسه می‌کند. ساتکلیفه نتیجه گیری می‌کند که سناریوها مرز میان این دیسیپلین‌ها هستند اما در هر زمینه تحقیقاتی وجود دارد که یکی را بر دیگری برتر می‌داند. این موضوع ممکن است رقابت به نظر برسد اما ممکن است به عنوان همگرایی میان دیسیپلین‌ها نیز در نظر گرفته شود. هر دوی دیسیپلین‌ها زمانی که با مشکلات تعامل سرو کار دارند همگرا می‌شوند اگرچه نقطه نظرات هر دیسیپلین از دیگری متفاوت است. ساتکلیفه بحث می‌کند که اگر به جای تمرکز روی روش‌های سنگین، طیف رویکردهای تکمیلی پذیرفته شود، امکان ترکیب کردن دیسیپلین‌ها وجود دارد. ساتکلیفه سناریوهایی را نیز به عنوان تکنیک‌های یکپارچگی معرفی می‌کند.
3-7- تبیین امنیت
زیو199مهندسی نیازمندی‌ها را به عنوان شاخه‌ای از مهندسی نرم افزار در ارتباط با اهداف جهان واقعی و انجام عملیات و اعمال محدودیت این گونه سیستم‌های نرم افزاری (زیو، 1997) تعریف می‌کند. این اهداف، متوجه‌این است که چرا سیستم نیاز به‌ایجاد شدن دارد، سیستم باید چگونه باشد (نوسیبه200 واستربروک201، 2000) و…
نیازمندی‌ها عموماً به صورت عملیاتی202وغیر عملیاتی طبقه بندی می‌شوند. هیچ تعریف پذیرفته شده‌ای برای هر یک از این طبقه بندی‌ها وجود ندارد، اگرچه به طور کلی پذیرفته شده که نیازمندی‌های عملیاتی به عنوان جنبه‌ها و شرایطی که باید احراز شود تعریف می‌شود. همینطور نیازمندی‌های غیر عملیاتی اغلب به عنوان نیازمندی‌های کیفی در نظر گرفته می‌شوند.
(یان سامرویل203 و پیتر ساویر204، 1999) و(یان و پیتر، 1999) بهترین نمونه‌های مهندسی نیازمندی را بیان می‌کنند. به ویژه قالب205 ویژگی نیازمندی‌ هایوالره206 (2009) که در صنعت و پروژه‌های مهندسی نیازمندی‌ها پذیرفته شده و در دانشگاه نیز تدریس می‌شوند وجود دارد.
علاقه‌مندی صنعت به مهندسی نیازمندی‌ها و دانش در حال رشد، مستلزم مورد توجه قراردادن مشکلات
غیر عملیاتی در مراحل ابتدایی طراحی دارد. مهندسی امنیت اغلب به عنوان نیازمندی‌های غیر عملیاتی
در نظر گرفته می‌شود. اگرچه در مورد اینکه ‌آیا این انتساب مناسب است یا نه، تردید وجود دارد. فلچز و دیگران (2009) معتقدند که در نظر گرفتن امنیت به عنوان یک نیازمندی غیر عملیاتی، ممکن است طراحان را به عقب انداختن مهندسی و طراحی نیازمندی‌های امنیتی ترغیب کند.
ککتن معتقد بر اولویت قابلیت کاربری، بر دیگر نیازمندی‌ها، می‌باشد. متأسفانه، تعریف نیازمندی از چشم انداز امنیت نامشخص است. حذف در نظر گرفتن نیازمندی‌های امنیتی گسترده است که از دلایل آن می‌توان به کمبود آموزش (هاکلید207، 2008) مطابقت با نیازهای بیرونی و نیازمندی‌های حکومتی (هلوکوناس208 و کوسیستو209، 2003) و نبود کارکنانی که اعتقاد به اهمیت امنیت سازمانشان داشته باشند اشاره کرد. (رابرتسن210، 2009) برآورد رویکرد‌های مهندسی نیازمندی‌های امنیتی توسط تاندل و دیگران211 نتیجه می‌گیرد که رویکردهای نیازمندی‌های امنیتی استخراج شده، چشم انداز کافی و مناسب قابل استفاده بودن برای برنامه نویس‌ها را ندارند.
نتایج برآورد با مشاهدات قبلی فایراسمیت212 ( فایراسمیت و دیگران، 2006) و‌هالی و دیگران213 (2008)
که مهندسان، نیازمندی‌های امنیتی گیج کننده را با خروجی‌های پیاده سازی دیگر اشتباه می‌گیرند مطابقت دارد. همچنین معتقد است که تعریف روشنی برای خروجی‌های مهندسی امنیت به دلیل عدم وجود اندازه‌گیری امنیتی سازگار با خروجی‌ها، وجود ندارد. آنچه که واضح است این است که مهندسی نیازمندی‌ها به عنوان یک دیسیپلین ظاهر می‌شود تا یک سلسله مراتب تحقیقاتی میان HCI و امنیت اطلاعات. علاوه بر آن، همان‌طور که ساتکلیفه (2005) نیز اظهار می‌کند، نیازمندی‌ها محدودیت میان HCI و تحقیقات مهندسی نرم افزار هستند.
در بخش زیر 3 رویکرد مهندسی نرم افزار ویژه را بازبینی می‌کنیم.
3-7-1- فریم‌های مشکل214
فریم‌های مشکل ابزارهایی برای طبقه بندی، آنالیز و ساختار بندی مشکلات پیاده سازی نرم افزار هستند. دیاگرام‌های این فریم‌ها، وظایفی که نیاز به انجام شدن به وسیله یک ماشین جهان واقعی دارند را مدل می‌کند.
این دیاگرام‌ها پدیده‌ها را مدل می‌کنند. موجودیت‌های قابل مشاهده، مانند رویدادها، اشیا و مقادیر می‌توانند در محدوده‌هایی که جعبه215 نامیده می‌شوند گروه بندی شوند. جعبه‌ها، محدودیت‌های مختلفی را نشان می‌دهند. اما هیچ اطلاعات تکمیلی درباره محدودیت‌ها ارائه نمی‌کنند.
2-
3-
3-7-
3-7-1-
3-7-1-1- بسط فریم‌های مشکل امنیت
هالی و دیگران (2008) یک رویکرد مهندسی نیازمندی امنیت بر اساس فریم‌های مشکل را پیشنهاد می‌دهد. این رویکرد با مدل کردن زمینه سیستم با استفاده از دیاگرام مشکل، استخراج نیازمندی‌های عملیاتی سیستم، استخراج اهداف امنیتی و تهدیداتی که مانع رسیدن به اهداف می‌شوند و شناسایی نیازمندی‌های امنیتی درگیر است. این نیازمندی‌ها به صورت محدودیت‌هایی روی نیازمندی‌های عملیاتی مدل شده‌اند. توزیع اصلی چهارچوب ‌هالی و دیگران شناخت طبیعت سمبلیک نیازمندی‌های امنیتی با خروجی‌های اصلی طراحی دیگر مانند مدل‌ها و دیگر نیازمندی‌ها است.