الزامات غیر کاربردی: مثالها ، انواع ، نحوه رویکرد
الزامات غیر کاربردی: مثالها ، انواع ، نحوه رویکرد
< /img> تصور کنید در حال خرید یک موتورسیکلت هستید. چه ویژگی هایی در ذهن دارید؟ آیا انتظار دارید با سرعت زیاد 170 مایل در ساعت حرکت کند و از هم پاشیده نشود؟ آیا می توانید با چسباندن یک تریلر ، یک صندلی جانبی به آن وصل کنید یا فضای چمدان را افزایش دهید؟ و سیستم های امنیتی را فراموش نکنیم. در حالی که این الزامات به طور مستقیم عملکرد اصلی خودرو را نشان نمی دهد - انتقال شخص از نقطه A به نقطه B - هنوز برای برآوردن نیازهای شما به عنوان راننده مهم است.
مانند موتورسیکلت ها یا هر نوع ماشین آلات ، نرم افزار الزامات غیر کاربردی خاص خود را دارد. چه یک وب سایت باشد ، چه یک تلفن همراه یا یک برنامه رومیزی ، باید مجموعه ای از ویژگی های کیفی را برای پاسخگویی به نیازهای کاربر نهایی داشته باشد.
الزامات غیر کاربردی چیست؟
به سادگی گفته شد ، یک الزام غیر کاربردی مشخصه ای است که قابلیت ها و محدودیت های عملکرد سیستم را که عملکرد آن را افزایش می دهد ، توصیف می کند. اینها ممکن است سرعت ، امنیت ، قابلیت اطمینان و غیره باشند. ما قبلاً انواع مختلفی از نیازهای نرم افزاری را پوشش داده ایم ، اما این بار روی موارد غیر کاربردی و نحوه برخورد و مستندسازی آنها تمرکز می کنیم.
اگر تا به حال با الزامات غیر کاربردی برخورد کرده اید ، ممکن است بدانید که منابع و راهنماهای مختلف از اصطلاحات مختلفی استفاده می کنند. به عنوان مثال ، چارچوب استانداردهای ISO/IEC 25000 الزامات غیر کاربردی را به عنوان کیفیت سیستم و الزامات کیفیت نرم افزار تعریف می کند. BABOK ، یکی از منابع اصلی دانش برای تحلیلگران تجاری ، واژه الزامات غیر عملکردی (NFR) را پیشنهاد می کند ، که در حال حاضر رایج ترین تعریف است. با این وجود ، این نامگذاریها نوع یکسانی از مواد را در نظر می گیرند - الزاماتی که ویژگیهای عملیاتی را توصیف می کنند تا رفتار محصول.
فهرست آنها نیز بسته به منبع متفاوت است. و صادقانه بگویم ، ممکن است برای محصولات مختلف متفاوت باشد. به عنوان مثال ، اگر قصد جمع آوری داده های کاربر را دارید و وب سایت شما در اتحادیه اروپا فعالیت می کند ، باید قوانین انطباق GDPR را رعایت کنید. در برخی موارد ، این ممکن است به شما مربوط نباشد. یا اگر پرداخت ها را پردازش می کنید ، ممکن است الزامات دیگری برای انطباق داشته باشید.
در این مقاله ، ما فقط رایج ترین انواع را که باید به چک لیست شما وارد شوند ، پوشش می دهیم. با این حال ، ممکن است صدها نفر از آنها وجود داشته باشد. معمولاً منابعی مانند BABOK الزامات غیر کاربردی را به صورت جداگانه فهرست می کنند. ما برخی از آنها را گروه بندی کردیم زیرا رویکردهای مستندسازی این الزامات با یکدیگر همپوشانی دارند و برخی دیگر بدون سایر موارد قابل تخمین نیستند:
عملکرد و مقیاس پذیری. نتایج سیستم با چه سرعتی باز می گردد؟ این عملکرد با حجم کاری بیشتر چقدر تغییر خواهد کرد؟
قابلیت حمل و سازگاری. نرم افزار روی کدام سخت افزار ، سیستم عامل ، مرورگرها و نسخه های آنها اجرا می شود؟ آیا با سایر برنامه ها و فرایندهای موجود در این محیط ها در تضاد است؟
قابلیت اطمینان ، در دسترس بودن ، قابلیت نگهداری. هر چند وقت یکبار سیستم دچار خرابی های مهم می شود؟ و چقدر زمان در اختیار کاربران در زمان خرابی است؟
امنیت. چگونه سیستم و داده های آن در برابر حملات محافظت می شوند؟
محلی سازی. آیا سیستم با مشخصات محلی مطابقت دارد؟
قابلیت استفاده. استفاده از سیستم برای مشتری چقدر آسان است؟
عملکرد و مقیاس پذیری
عملکرد نشان می دهد که چگونه یک سیستم نرم افزاری یا قطعه خاص آن تحت بار کاری خاصی به اقدامات کاربران خاص پاسخ می دهد. در بیشتر موارد ، این معیار میزان کاربر را توضیح می دهدباید منتظر بمانید تا عملیات هدف (صفحه ارائه می دهد ، تراکنش پردازش می شود و غیره) با توجه به تعداد کلی کاربران در حال حاضر. اما همیشه اینطور نیست الزامات عملکرد ممکن است فرایندهای نامرئی را برای کاربران توصیف کند ، به عنوان مثال. پشتیبان گیری. اما بیایید بر عملکرد کاربر محور تمرکز کنیم.
مقیاس پذیری بالاترین حجم کاری را که تحت آن سیستم همچنان نیازهای عملکرد را برآورده می کند ، ارزیابی می کند.
نحوه نزدیک شدن
شروع با توصیه های Google برای صفحات وب معمولی. گوگل نسبت به زمان بارگذاری دسکتاپ و موبایل بسیار حساس است. بنابراین ، اگر به دنبال راهنمای عملکرد برای صفحات وب معمولی هستید که همه کاربران به آن دسترسی دارند ، اطلاعات مربوط به سرعت صفحه Google را بررسی کنید. موتور جستجو سناریوهای متعددی از جمله نوع اتصال ، بارگذاری تلفن همراه یا دسکتاپ و نوع محتوای نمایش داده شده را در نظر می گیرد. براساس مجموع عوامل ، نمرات عملکرد متفاوتی را ارائه می دهد که می توانید برای وب سایت خود تخمین بزنید. اگر الزامات مربوط به صفحات فرود را تنظیم کنید ، این امر بسیار مهم است ، زیرا Google ممکن است صفحه شما را با توجه به سرعت آن پایین بیاورد.
Google عملکرد را بر اساس عوامل متعدد برآورد می کند توصیه های اولیه زمان پاسخ را بررسی کنید. یاکوب نیلسن در سال 1993 3 معیار اصلی برای زمان پاسخ را بیان کرد. در حالی که این طرح کلی ممکن است قدیمی به نظر برسد ، معیارها هنوز معنی دار هستند زیرا عموماً بر اساس نحوه عملکرد توجه انسان استوار هستند:
معمولاً شما نمی خواهید نمی خواهید به این آستانه 10 ثانیه برسید ، زیرا حدود 40 درصد از کاربران وب سایت را پس از 3 ثانیه ترک می کنند.
سناریوی اندازه گیری را مشخص کنید. آیا معیار شما شامل ارائه مرورگر است یا فقط زمان لازم برای تحویل داده ها به مرورگر؟ اگر انواع مختلف محتوا با سرعت متفاوت بارگیری می شوند ، ممکن است محدودیت های زمانی متفاوتی برای متن ، تصاویر و فیلم ها داشته باشید.
حجم کار فعلی را برای اندازه گیری مشخص کنید. از آنجایی که ممکن است مثلاً 5 هزار کاربر در طول روز و هزار نفر در شب داشته باشید ، سناریوهای بارگذاری را که مستند می کنید ، مشخص کنید. شاید هر دو را مستند کنید ، شاید بخواهید بالاترین آستانه را تنظیم کنید.
زمان لازم برای ارائه نتایج توسط شخص ثالث را در نظر نگیرید. اگر عملکرد شما به تماس هایی بستگی دارد که داده ها را از API شخص ثالث باز می گرداند ، تیم توسعه شما نمی تواند مسئولیت آن را بر عهده بگیرد.
محدودیت های معماری را بپذیرید. اگر توسعه دهندگان با یک راه حل سازمانی یا سیستم قدیمی سر و کار دارند ، ممکن است راههای بسیار کمی برای بهبود عملکرد بدون بازسازی کل معماری وجود داشته باشد.
مقیاس پذیری را در نظر بگیرید. ما مقیاس پذیری را نیز در این بخش قرار دادیم ، زیرا حداکثر بار را در نظر می گیرد که سیستم الزاماً در حال حاضر پردازش نمی کند ، اما ممکن است در آینده نزدیک پردازش شود. به عنوان مثال ، شما انتظار دارید که تعداد جلسات برنامه پس از یک کمپین بازاریابی دو برابر شود و شما همچنان می خواهید عملکرد موجود را حفظ کنید. اگرچه پیش بینی سخت است ، اما ارزش آن را دارد که حداقل انتظارات بار را داشته باشید.
نمونه ای از الزامات عملکرد:
صفحه فرود که از 5 هزار کاربر در ساعت پشتیبانی می کند بایدارائه 6 ثانیه یا کمتر زمان پاسخگویی در مرورگر دسکتاپ Chrome ، از جمله ارائه متن و تصاویر ، از طریق اتصال LTE.
قابلیت حمل و سازگاری
قابلیت حمل نحوه تعریف یک سیستم یا آن عنصر را می توان در یک محیط یا محیط دیگر راه اندازی کرد. معمولاً شامل سخت افزار ، نرم افزار یا سایر مشخصات پلت فرم استفاده است. به بیان ساده ، نحوه عملکرد خوب عملکردهایی که از طریق یک پلتفرم بر روی پلتفرم دیگر انجام می شود را تعیین می کند. همچنین ، نحوه دسترسی به عناصر سیستم و تعامل آنها از دو محیط متفاوت را تجویز می کند.
قابلیت حمل همچنین جنبه دیگری به نام سازگاری دارد. سازگاری تعریف می کند که چگونه یک سیستم می تواند با یک سیستم دیگر در همان محیط همزیستی داشته باشد. به عنوان مثال ، نرم افزار نصب شده بر روی یک سیستم عامل باید با دیوار آتش یا حفاظت آنتی ویروس سازگار باشد.
قابلیت حمل و سازگاری از نظر سیستم عامل ها ، دستگاه های سخت افزاری ، مرورگرها ، سیستم های نرم افزاری و نسخه های آنها ایجاد می شود. در حال حاضر ، یک راه حل چند پلتفرمی ، مرور بین صفحه ای و پاسخگو به تلفن همراه یک استاندارد رایج برای برنامه های وب است.
الزامات غیر کاربردی قابل حمل معمولاً بر اساس تحقیقات اولیه بازار ، فعالیتهای تحقیقات میدانی یا گزارشات تحلیلی در مورد انواع نرم افزارها و دستگاه هایی که مخاطبان هدف دارند. اگر در محیطی شرکتی مشغول به کار هستید و نرم افزار از طریق فهرست مستند دستگاه ها و سیستم عامل ها به آن دسترسی پیدا می کند ، تعیین سازگاری و قابلیت حمل بسیار آسان است.
نحوه برخورد
در صورت امکان الزامات قابلیت حمل را از ابزارهای تجزیه و تحلیل خود استنباط کنید. اگر از طریق Google Analytics یا سایر بسترهای تحلیلی به داده های بازدیدکنندگان دسترسی دارید ، می توانید ارزیابی کنید که کدام نوع دستگاه ها ، مرورگرها و نسخه های آنها بیشتر مورد استفاده قرار می گیرد.
کاملترین فهرست الزامات قابلیت حمل را در نظر بگیرید. این سند نه تنها راهنمایی مهندسان را ارائه می دهد ، بلکه محدوده سناریوهای آزمایش را نیز بیان می کند:
نمونه ای از قابلیت حمل و سازگاری Visual Studio IDE سازگاری با سایر برنامه ها ، از جمله شخص ثالث را تعریف کنید. اگر سیستم باید با نرم افزار شخص ثالث یا سایر برنامه های موجود در اکوسیستم نرم افزار همزیستی داشته باشد ، آنها را وارد کنید.
نمونه ای از الزامات سازگاری: برنامه iOS باید از دستگاه های iPhone در نسخه های OS پشتیبانی کند:
قابلیت اطمینان ، در دسترس بودن ، قابلیت نگهداری
در حالی که این سه نوع الزامات معمولاً به طور جداگانه مستندسازی می شوند ، ما آنها را در یک بخش تجمیع می کنیم ، زیرا آنها به یک نوع مشکل از مسائل مختلف نزدیک می شوند. زاویه. نکته دیگری که باید با این الزامات در نظر داشت این است که بیان آنها با شرایط محاسباتی بسیار سخت است. و صادقانه بگویم ، بسیاری از ارائه دهندگان سیستم آنها را به طور کامل مستند نمی کنند. بیایید ببینیم.
قابلیت اطمینان. این ویژگی کیفیت مشخص می کند که چقدر احتمال دارد سیستم یا عنصر آن بدون خرابی برای مدت زمان معینی در شرایط از پیش تعیین شده کار کند. به طور سنتی ، به عنوان درصد احتمال بیان می شود. به عنوان مثال ، اگر سیستم به مدت یک ماه 85 درصد قابلیت اطمینان داشته باشد ، این بدان معناست که در این ماه ، در شرایط عادی استفاده ، 85 درصد احتمال دارد که سیستم دچار نقص جدی نشود.
ممکن است حدس زده باشید ، تعریف شکست بحرانی ، زمان و شرایط عادی استفاده نسبتاً مشکل است. رویکرد دیگر ، تا حدی ساده تر برای این معیار ، شمارش تعداد اشکالات مهم موجود در تولید برای برخی از دوره ها استزمان یا محاسبه میانگین زمان شکست. سه روش برای اندازه گیری آن عبارتند از:
قابلیت نگهداری. قابلیت نگهداری زمان مورد نیاز برای ثابت ماندن محلول ، اجزای آن ، افزایش عملکرد یا سایر ویژگیها یا سازگار شدن با محیط در حال تغییر را تعیین می کند. مانند قابلیت اطمینان ، می توان آن را بعنوان احتمال تعمیر در مدتی بیان کرد. به عنوان مثال ، اگر 75 درصد قابلیت نگهداری را برای 24 ساعت دارید ، این بدان معناست که 75 درصد احتمال دارد که قطعه در 24 ساعت ثابت شود.
در دسترس بودن. و سرانجام ، در دسترس بودن توصیف می کند که چگونه سیستم در یک زمان معین برای کاربر در دسترس است. در حالی که می توان آن را به عنوان یک درصد احتمال بیان کرد ، شما همچنین می توانید آن را به عنوان درصدی از زمان دسترسی سیستم برای کار در طول یک دوره زمانی مشخص کنید. به عنوان مثال ، این سیستم ممکن است 98 درصد مواقع در طول یک ماه در دسترس باشد. در دسترس بودن شاید مهمترین نیاز تجاری باشد ، اما برای تعریف آن ، باید از قابلیت اطمینان و قابلیت نگهداری نیز برخوردار باشید.
همانطور که می بینید ، این سه معیار به هم نزدیک هستند. و مهمتر از همه ، اگر تصمیم دارید آنها را به عنوان الزامات غیرعملی برای سیستم خود مستند کنید ، باید با آنها برخورد کنید. آیا می توانید برنامه خود را در 5 درصد مواقع در دسترس قرار دهید؟ آیا می توانید ضررهای قابل قبول را در ارقام مالی یا برخی دیگر از KPI در سطح محصول بیان کنید؟ با در نظر داشتن هیچ برنامه کاربردی کاملاً مقاوم در برابر خرابی ، آستانه ای را که نمی توانید از آن عبور کنید ، تعیین کنید.
جزء مورد نظر خود را مشخص کنید. می توانید به کل سیستم نزدیک شوید ، اما اگر محیط های متفاوتی (گردش کار پرداخت ، صفحات فرود ، داشبورد) دارد ، هر یک از آنها ممکن است محدودیت خرابی معقول و الزامات در دسترس بودن خود را داشته باشند.
سناریوهای بارگذاری مختلف را شرح دهید. بسته به حجم کاری مختلف ، سیستم ممکن است زمان های مختلف خرابی را تجربه کند. مشابه اندازه گیری عملکرد ، شرایط مختلف را برای تعریف شرایط طبیعی و احتمالی غیرطبیعی در نظر بگیرید.
طول عمر محصول را در نظر بگیرید. در مورد ایجاد قابلیت نگهداری/قابلیت اطمینان/در دسترس بودن ، طول عمر محصول نرم افزاری را در نظر بگیرید. هرچه طول می کشد ، توسعه راه حل بسیار قابل نگهداری منطقی تر می شود. به عبارت دیگر ، اگر در حال ساختن یک MVP برای آزمایش فرضیات هستید ، نیازی به سرمایه گذاری زودهنگام بر روی کیفیت توسعه نیست.
برآورد در هنگام آزمایش و تولید. می توانید معیارهای محصولات و ویژگی های مشابه را جستجو کنید ، اما اگر این اطلاعات در مراحل برنامه ریزی محصول در دسترس نباشد ، تعیین اندازه گیری برای شما دشوار است. بنابراین ، به احتمال زیاد شما می توانید این الزامات را در حین آزمایش و تولید پیش از راه اندازی بیان کنید. با این حال ، می توانید در طول توسعه بر کیفیت کد تأکید کنید.
نمونه ای از الزامات در دسترس بودن: داشبورد وب باید 98 درصد مواقع در هر ماه در ساعات کاری EST برای کاربران ایالات متحده در دسترس باشد. بخشی در برابر حملات بدافزار یا دسترسی غیر مجاز محافظت می شود. اما یک گرفتاری وجود دارد سهم شیر از الزامات غیر کاربردی امنیتی را می توان به همتایان کاربردی خاص تبدیل کرد. اگر می خواهید پنل مدیریت را از دسترسی غیر مجاز محافظت کنید ،شما جریان ورود و نقش های مختلف کاربر را به عنوان رفتار سیستم یا اقدامات کاربر تعریف می کنید.
بنابراین ، بخش الزامات غیر کاربردی انواع خاصی از تهدیدها را ایجاد می کند که الزامات عملکردی با جزئیات بیشتری به آنها می پردازد. اما همیشه اینطور نیست اگر امنیت شما متکی به استانداردهای خاص و روشهای رمزگذاری است ، این استانداردها به طور مستقیم رفتار یک سیستم را توصیف نمی کند ، بلکه به مهندسان در راهنمای پیاده سازی کمک می کند.
نحوه برخورد
تعریف تهدیدهای خاصی که می خواهید سیستم شما در برابر آنها محافظت شود. به عنوان مثال ، چنین جزئیاتی را باید در نظر گرفت: تحت چه شرایطی دسترسی غیرمجاز صورت می گیرد ، چه مواردی برای نقض داده ها وجود دارد ، چه نوع حملات بدافزاری را می خواهید از بین ببرید.
گسترش الزامات غیر عملکردی به موارد کاربردی آنها می توانند ، مثلاً ، یک طرح مجوز و احراز هویت جامع برای هر بازیگر سیستم را شامل شوند. همچنین ، سیستم باید محدودیت هایی را در مورد افرادی که می توانند داده ها را تولید ، مشاهده ، تکرار ، ویرایش یا حذف کنند ، معرفی کند.
استانداردهایی را که بر آنها تکیه می کنید در نظر بگیرید. اگر سیستم شما باید با برخی از استانداردها یا مقررات امنیتی مطابقت داشته باشد ، بخش غیر کاربردی بهترین مکان برای آنها است.
نمونه الزامات امنیتی: درگاه پردازش پرداخت باید با PCI DSS سازگار باشد. زمینه شامل زبانها ، قوانین ، ارزها ، فرهنگها ، املا و سایر جنبه های محلی است. هرچه محصول بیشتر به آن بچسبد ، موفقیت بیشتری باید برای مخاطبان خاص داشته باشد.
مواردی که باید مورد توجه قرار گیرد
بر تحقیقات بازار تکیه کنید. برای مستندسازی این نیاز ، باید به تحقیقات اولیه بازار از یک مدیر محصول یا یک مطالعه میدانی جامع توسط یک محقق UX تکیه کنید.
از نظر جنبه های محلی سازی دقیق باشید. اگر چندین گزینه برای هر جزء در یک بازار واحد وجود دارد ، باید به همه آنها توجه شود. برای مثال ، زبان ، ارز ، و آدرس و قالب های پرداخت بسیار مهم است.
نمونه ای از الزامات محلی سازی: قالب تاریخ باید به شرح زیر باشد: month.date.year.
قابلیت استفاده
قابلیت استفاده یکی دیگر از الزامات کلاسیک غیر کاربردی است که به یک س simpleال ساده پاسخ می دهد: استفاده از محصول چقدر سخت است ؟ تعریف این الزامات آنقدرها هم که به نظر می رسد آسان نیست. انواع مختلفی از معیارهای قابلیت استفاده وجود دارد. یکی از معروف ترین آنها توسط گروه Nielsen Norman ، ارزیابی قابلیت استفاده را در پنج بعد پیشنهاد می کند:
قابلیت یادگیری. تکمیل اقدامات اصلی پس از مشاهده رابط کاربری چقدر سریع است؟
کارآیی. کاربران با چه سرعتی می توانند به اهداف خود برسند؟
قابلیت یادآوری. آیا کاربران می توانند پس از مدتی به رابط کاربری بازگردند و بلافاصله کار کارآمد را با آن شروع کنند؟
خطاها. کاربران هر چند وقت یکبار اشتباه می کنند؟
رضایت. آیا استفاده از طرح دلپذیر است؟
با در نظر گرفتن این نکته ، باید نحوه اندازه گیری این الزامات را در نظر بگیرید.
نحوه رویکرد
با قدیمی شروع کنید طرح. اگر قبلاً محصولی دارید ، اندازه گیری تعداد خطاها ، مدت زمان لازم برای یادگیری رابط و تکمیل وظایف برای تنظیم خط پایه و تعیین اهداف قابلیت استفاده را در نظر بگیرید.
بر اساس KPI های محصول خود ، آستانه ها را تعیین کنید. آیا می توانید این هزینه را بپردازید که تنها 50 درصد از کاربران می توانند آنچه را که بدنبال آن هستند پیدا کنند؟ چه عددی خواهد بودکه برنامه های استراتژیک شما را برآورده می کند؟
آزمایش قابلیت استفاده بر روی محصولات رقیب را اجرا کنید. اگر محصول فعلی ندارید ، آزمایشاتی را با رقبا انجام دهید تا زمینه های بهبود را نشان دهید. همچنین می توانید برای کسب اطلاعات بیشتر مقاله ما در زمینه مهندسی قابلیت استفاده را بررسی کنید.
قابلیت استفاده را روی نمونه های اولیه آزمایش کنید تا محصول نهایی. این یک نکته مهم نیست ، زیرا قابلیت استفاده باید قبل از شروع مهندسی شما ایجاد شود.
نمونه ای از الزامات قابلیت استفاده: میزان خطای کاربرانی که جزئیات پرداخت خود را در صفحه تسویه حساب ارسال می کنند نباید بیش از 10 درصد باشد.
توصیه های کلی برای مستندسازی الزامات غیر کاربردی
قبل از پایان کار ، بیایید در مورد کلید بحث کنیم مواردی را که هنگام تنظیم و مستندسازی الزامات کیفیت نرم افزار باید به خاطر بسپارید.
آنها را قابل اندازه گیری و آزمایش کنید. برای درک اینکه آیا سیستم شما با محدودیت های کیفی مطابقت دارد ، مطمئن شوید که الزامات خود را کمی کنید. شما باید واحدهای اندازه گیری ، روش هایی که قرار است از آنها استفاده کنید ، و همچنین سطح موفقیت و شکست را مشخص کنید.
الزامات را برای اجزای سیستم به جای کل محصولات تعیین کنید. در نظر بگیرید که کدام رابط ها و سیستم های مهم به چنین الزاماتی نیاز دارند. اگر کاربران شما هرگز با قسمتی از محصول شما (به عنوان مثال پنل مدیریت) تعامل ندارند ، محدودیت های عملکرد این اجزا ممکن است بی فایده یا مضر باشد ، زیرا تیم شما تلاش بیشتری را بدون هیچگونه بدیهی انجام می دهد.
NFR را با اهداف تجاری پیوند دهید. تفاوت چند دقیقه ای در دسترس بودن سیستم ممکن است تأثیر چشمگیری بر تعداد فروش شما نداشته باشد ، اما گاهی اوقات می تواند به معنای هفته های مهندسی اضافی باشد. سعی کنید اهداف تجاری خود را به الزامات سیستم تقسیم کنید.
محدودیت های شخص ثالث را در نظر بگیرید. اگر یک API شخص ثالث که باید از آن استفاده کنید داده ها را کندتر از آنچه می خواهید برمی گرداند ، شما یا تیم شما نمی توانید در این مورد کاری انجام دهید.
محدودیت های معماری را در نظر بگیرید. سیستم های قدیمی می توانند کیفیت را محدود کنند. در حالی که بازسازی کد قدیمی امکان پذیر است ، گاهی معماری فعلی باید به طور کامل بازسازی شود تا برخی از الزامات را برآورده کند.
به دنبال استانداردها و راهنماهای موجود باشید. به احتمال زیاد بسیاری از توصیه های کیفیت سیستم قبلاً ارائه شده است. بنابراین ، دستورالعمل های برنامه iOS یا Android را بررسی کنید تا برخی از الزامات برنامه خود را پیشنهاد دهید.
ابتدا در وبلاگ فناوری AltexSoft "الزامات غیر کاربردی: مثالها ، انواع ، نحوه برخورد" منتشر شده است
