قالب رکورد تصمیم از arc42

https://arc42.org/overview

1. مقدمه و اهداف

توصیف کوتاه نیازمندی‌ها، نیروهای محرک، و عصارهٔ (یا چکیدهٔ) نیازمندی‌ها. سه (حداکثر پنج) هدف کیفی برتر برای معماری که بالاترین اولویت را برای ذی‌نفعان اصلی دارند. جدولی از ذی‌نفعان مهم با انتظارات آن‌ها از معماری.

1.1 مرور نیازمندی‌ها

محتوا

توصیف کوتاه نیازمندی‌های کارکردی، نیروهای محرک، عصاره (یا چکیدهٔ) نیازمندی‌ها. پیوند به اسناد نیازمندی‌ها (که امیدواریم وجود داشته باشند)، همراه با اطلاعاتی دربارهٔ محل یافتن آن‌ها.

انگیزه

از دیدگاه کاربران نهایی، یک سیستم برای بهبود پشتیبانی از یک فعالیت کسب‌وکاری و/یا بهبود کیفیت ایجاد یا تغییر داده می‌شود.

شکل

توصیف متنی کوتاه، احتمالاً به قالب جدولی مورد استفاده. اگر اسناد نیازمندی‌ها وجود دارند، این مرور باید به آن اسناد ارجاع دهد.

این گزیده‌ها را تا حد امکان کوتاه نگه دارید. میان خوانایی این سند و افزونگی احتمالی نسبت به اسناد نیازمندی‌ها تعادل برقرار کنید.

1.2 اهداف کیفی

محتوا

سه (حداکثر پنج) هدف کیفی برتر برای معماری که تحقق آن‌ها برای ذی‌نفعان اصلی از بالاترین اهمیت برخوردار است. منظور ما واقعاً اهداف کیفی برای معماری است. آن‌ها را با اهداف پروژه اشتباه نگیرید. لزوماً یکسان نیستند. استاندارد ISO 25010 مرور خوبی از موضوعات بالقوهٔ مورد توجه ارائه می‌دهد.

انگیزه

باید اهداف کیفی مهم‌ترین ذی‌نفعان خود را بدانید، زیرا آن‌ها بر تصمیم‌های بنیادین معماری تأثیر می‌گذارند. دربارهٔ این کیفیت‌ها بسیار مشخص باشید و از واژه‌های پرزرق‌وبرق بپرهیزید. اگر شما به‌عنوان معمار ندانید که کیفیت کارتان چگونه سنجیده خواهد شد …

شکل

جدولی با مهم‌ترین اهداف کیفی و سناریوهای مشخص، مرتب‌شده بر اساس اولویت.

1.3 ذی‌نفعان

محتوا

مرور صریح ذی‌نفعان سیستم، یعنی همهٔ افراد، نقش‌ها یا سازمان‌هایی که

• باید معماری را بشناسند

• باید قانع شوند که معماری درست است

• باید با معماری یا کد کار کنند

• برای کار خود به مستندات معماری نیاز دارند

• باید دربارهٔ سیستم یا توسعهٔ آن تصمیم بگیرند

انگیزه

باید همهٔ طرف‌های درگیر در توسعهٔ سیستم یا متأثر از سیستم را بشناسید. در غیر این صورت، ممکن است بعداً در فرایند توسعه با غافلگیری‌های ناخوشایند روبه‌رو شوید. این ذی‌نفعان دامنه و سطح جزئیات کار و نتایج آن را تعیین می‌کنند.

شکل

جدولی با نام نقش‌ها، نام افراد، و انتظارات آن‌ها نسبت به معماری و مستندات آن.

2. محدودیت‌ها

هر چیزی که تیم‌ها را در تصمیم‌های طراحی و پیاده‌سازی یا تصمیم‌های مربوط به فرایندهای وابسته محدود می‌کند. گاهی می‌تواند فراتر از سیستم‌های منفرد برود و برای کل سازمان‌ها و شرکت‌ها معتبر باشد.

محتوا

هر نیازمندی‌ای که آزادی معماران نرم‌افزار را در تصمیم‌های طراحی و پیاده‌سازی یا تصمیم دربارهٔ فرایند توسعه محدود می‌کند. این محدودیت‌ها گاهی فراتر از سیستم‌های منفرد می‌روند و برای کل سازمان‌ها و شرکت‌ها معتبرند.

انگیزه

معماران باید دقیقاً بدانند کجا در تصمیم‌های طراحی خود آزادند و کجا باید به محدودیت‌ها پایبند باشند. با محدودیت‌ها همیشه باید کنار آمد؛ هرچند ممکن است قابل مذاکره باشند.

شکل

جدول‌های ساده از محدودیت‌ها به همراه توضیحات. در صورت نیاز می‌توانید آن‌ها را به محدودیت‌های فنی، محدودیت‌های سازمانی و سیاسی، و قراردادها (مثلاً رهنمودهای برنامه‌نویسی یا نسخه‌گذاری، قراردادهای مستندسازی یا نامگذاری) تقسیم کنید

3. زمینه و دامنه

سیستم شما را از شرکای ارتباطی (بیرونی) آن (سیستم‌های همسایه و کاربران) مرزبندی می‌کند. رابط‌های بیرونی را مشخص می‌کند. از منظر کسب‌وکار/دامنه (همیشه) یا منظر فنی (اختیاری) نمایش داده می‌شود

محتوا

دامنه و زمینهٔ سیستم — همان‌طور که از نامش پیداست — سیستم شما (یعنی دامنهٔ شما) را از همهٔ شرکای ارتباطی آن (سیستم‌های همسایه و کاربران، یعنی زمینهٔ سیستم شما) مرزبندی می‌کند. بدین ترتیب رابط‌های بیرونی را مشخص می‌کند.

در صورت لزوم، زمینهٔ کسب‌وکار (ورودی‌ها و خروجی‌های مختص دامنه) را از زمینهٔ فنی (کانال‌ها، پروتکل‌ها، سخت‌افزار) متمایز کنید.

انگیزه

رابط‌های دامنه و رابط‌های فنی با شرکای ارتباطی از حیاتی‌ترین جنبه‌های سیستم شما هستند. مطمئن شوید که آن‌ها را به‌طور کامل درک می‌کنید.

شکل

• نمودارهای زمینهٔ گوناگون

• فهرست شرکای ارتباطی و رابط‌های آن‌ها.

3.1 زمینهٔ کسب‌وکار

محتوا

مشخصات همهٔ شرکای ارتباطی (کاربران، سیستم‌های فناوری اطلاعات، …) همراه با توضیح ورودی‌ها و خروجی‌ها یا رابط‌های مختص دامنه. به‌صورت اختیاری می‌توانید قالب‌ها یا پروتکل‌های ارتباطی مختص دامنه را اضافه کنید.

انگیزه

همهٔ ذی‌نفعان باید بفهمند چه داده‌ای با محیط سیستم مبادله می‌شود.

شکل

انواع نمودارهایی که سیستم را به‌صورت جعبهٔ سیاه نشان می‌دهند و رابط‌های دامنه را با شرکای ارتباطی مشخص می‌کنند.

به‌طور جایگزین (یا علاوه بر آن) می‌توانید از یک جدول استفاده کنید. عنوان جدول نام سیستم شماست، سه ستون شامل نام شریک ارتباطی، ورودی‌ها و خروجی‌ها هستند.

3.2 زمینهٔ فنی

محتوا

رابط‌های فنی (کانال‌ها و رسانه‌های انتقال) که سیستم شما را به محیطش متصل می‌کنند. به‌علاوهٔ نگاشت ورودی/خروجی مختص دامنه به کانال‌ها، یعنی توضیح اینکه کدام I/O از کدام کانال استفاده می‌کند.

انگیزه

بسیاری از ذی‌نفعان تصمیم‌های معماری را بر پایهٔ رابط‌های فنی میان سیستم و زمینهٔ آن می‌گیرند. به‌ویژه طراحان زیرساخت یا سخت‌افزار این رابط‌های فنی را تعیین می‌کنند.

شکل

مثلاً نمودار استقرار UML که کانال‌ها به سیستم‌های همسایه را توصیف می‌کند، همراه با یک جدول نگاشت که روابط میان کانال‌ها و ورودی/خروجی را نشان می‌دهد.

4. راهبرد راه‌حل

خلاصهٔ تصمیم‌های بنیادین و راهبردهای راه‌حل که معماری را شکل می‌دهند. می‌تواند شامل فناوری، تجزیهٔ سطح بالا، رویکردهای دستیابی به اهداف کیفی برتر و تصمیم‌های سازمانی مرتبط باشد.

محتوا

خلاصه و توضیح کوتاه تصمیم‌های بنیادین و راهبردهای راه‌حل که معماری سیستم را شکل می‌دهند. این‌ها شامل

• تصمیم‌های فناوری

• تصمیم‌های مربوط به تجزیهٔ سطح بالای سیستم، مثلاً استفاده از یک الگوی معماری یا الگوی طراحی

• تصمیم‌ها دربارهٔ چگونگی دستیابی به اهداف کیفی کلیدی

• تصمیم‌های سازمانی مرتبط، مثلاً انتخاب یک فرایند توسعه یا واگذاری برخی وظایف به اشخاص ثالث.

انگیزه

این تصمیم‌ها سنگ‌بنای معماری شما را تشکیل می‌دهند. آن‌ها پایهٔ بسیاری از تصمیم‌های تفصیلی یا قواعد پیاده‌سازی دیگر هستند.

شکل

توضیح این تصمیم‌های کلیدی را کوتاه نگه دارید.

انگیزه بدهید که چه تصمیمی گرفته‌اید و چرا به این شکل تصمیم گرفته‌اید، بر پایهٔ بیان مسئله، اهداف کیفی و محدودیت‌های کلیدی. به جزئیات در بخش‌های بعدی ارجاع دهید (بخش 5 برای جزئیات ساختاری، بخش 8 برای مفاهیم فراگیر).

می‌توانید از فهرستی از رویکردهای راه‌حل یا یک جدول استفاده کنید.

5. نمای بلوک‌های سازنده

تجزیهٔ ایستای سیستم، انتزاع‌های کد منبع، که به‌صورت سلسله‌مراتبی از جعبه‌های سفید (حاوی جعبه‌های سیاه) تا سطح جزئیات مناسب نمایش داده می‌شود.

محتوا

نمای بلوک‌های سازنده، تجزیهٔ ایستای سیستم را به بلوک‌های سازنده (ماژول‌ها، مؤلفه‌ها، زیرسیستم‌ها، کلاس‌ها، رابط‌ها، بسته‌ها، کتابخانه‌ها، چارچوب‌ها، لایه‌ها، پارتیشن‌ها، سطوح، توابع، ماکروها، عملیات، ساختارهای داده، …) و همچنین وابستگی‌های آن‌ها (روابط، انجمن‌ها، …) نشان می‌دهد

این نما برای مستندات هر معماری اجباری است. در تشبیه با یک خانه، این نقشهٔ طبقات است.

انگیزه

با قابل‌فهم کردن ساختار کد منبع خود از طریق انتزاع، مرور کلی بر آن را حفظ کنید.

این به شما امکان می‌دهد با ذی‌نفعان خود در سطح انتزاعی بدون افشای جزئیات پیاده‌سازی ارتباط برقرار کنید.

شکل

نمای بلوک‌های سازنده مجموعه‌ای سلسله‌مراتبی از جعبه‌های سیاه و جعبه‌های سفید (شکل زیر را ببینید) و توصیفات آن‌هاست.

5.1 جعبه سفید کل سیستم

اینجا تجزیهٔ کل سیستم را با استفاده از قالب جعبه سفید زیر توصیف می‌کنید. شامل

• یک نمودار مرور کلی

• انگیزه‌ای برای تجزیه

• توصیف جعبه سیاه بلوک‌های سازنده. برای این‌ها گزینه‌هایی به شما ارائه می‌دهیم:

  • از یک جدول برای مرور کوتاه و عملی همهٔ بلوک‌های سازندهٔ موجود و رابط‌های آن‌ها استفاده کنید

  • از فهرستی از توصیف‌های جعبه سیاه بلوک‌های سازنده بر اساس قالب جعبه سیاه (زیر را ببینید) استفاده کنید. بسته به انتخاب ابزار شما، این فهرست می‌تواند زیرفصل (در فایل‌های متنی)، زیرصفحه (در ویکی) یا عناصر تودرتو (در ابزار مدل‌سازی) باشد.

  • (اختیاری:) رابط‌های مهمی که در قالب‌های جعبه سیاه یک بلوک سازنده توضیح داده نشده‌اند، اما برای درک جعبه سفید بسیار مهم‌اند.

از آنجا که راه‌های بسیاری برای مشخص کردن رابط‌ها وجود دارد، قالب مشخصی برای آن‌ها ارائه نمی‌دهیم.

در بهترین حالت با نمونه‌ها یا امضاهای ساده کار را پیش می‌برید.

5.2 سطح 2

اینجا می‌توانید ساختار درونی (برخی از) بلوک‌های سازندهٔ سطح 1 را به‌صورت جعبه سفید مشخص کنید.

باید تصمیم بگیرید کدام بلوک‌های سازندهٔ سیستم شما به‌اندازه‌ای مهم هستند که چنین توصیف تفصیلی‌ای را توجیه کنند. لطفاً ارتباط را بر کامل بودن ترجیح دهید. بلوک‌های سازندهٔ مهم، شگفت‌انگیز، پرخطر، پیچیده یا ناپایدار را مشخص کنید. بخش‌های عادی، ساده، خسته‌کننده یا استاندارد سیستم خود را کنار بگذارید

5.2.1 جعبه سفید برای بلوک سازندهٔ 1

ساختار درونی بلوک سازندهٔ 1 را مشخص می‌کند.

از قالب جعبه سفید (بالا را ببینید) استفاده کنید.

6. نمای زمان اجرا

رفتار بلوک‌های سازنده به‌صورت سناریو، که موارد استفاده یا قابلیت‌های مهم، تعامل‌ها در رابط‌های بیرونی حیاتی، عملیات و مدیریت به‌علاوهٔ رفتار خطا و استثنا را پوشش می‌دهد.

محتوا

نمای زمان اجرا رفتار و تعامل‌های مشخص بلوک‌های سازندهٔ سیستم را به شکل سناریوهایی از حوزه‌های زیر توصیف می‌کند:

• موارد استفاده یا قابلیت‌های مهم: بلوک‌های سازنده آن‌ها را چگونه اجرا می‌کنند؟

• تعامل‌ها در رابط‌های بیرونی حیاتی: بلوک‌های سازنده چگونه با کاربران و سیستم‌های همسایه همکاری می‌کنند؟

• عملیات و مدیریت: راه‌اندازی، شروع به کار، توقف

• سناریوهای خطا و استثنا

نکته: معیار اصلی برای انتخاب سناریوهای ممکن (توالی‌ها، گردش‌کارها) ارتباط معماری آن‌هاست. توصیف تعداد زیادی سناریو مهم نیست. بهتر است گزینشی نماینده را مستند کنید.

انگیزه

باید بفهمید که (نمونه‌های) بلوک‌های سازندهٔ سیستم شما در زمان اجرا چگونه کار خود را انجام می‌دهند و ارتباط برقرار می‌کنند. شما عمدتاً سناریوها را در مستندات خود ثبت خواهید کرد تا معماری خود را به ذی‌نفعانی منتقل کنید که کمتر مایل یا قادرند مدل‌های ایستا (نمای بلوک‌های سازنده، نمای استقرار) را بخوانند و بفهمند.

شکل

نمادگذاری‌های بسیاری برای توصیف سناریوها وجود دارد، مثلاً

• فهرست شمارهٔ مراحل (به زبان طبیعی)

• نمودارهای فعالیت یا فلوچارت

• نمودارهای توالی

• BPMN یا EPC (زنجیره‌های فرایند رویداد)

• ماشین‌های حالت

• و غیره.

6.n سناریوی زمان اجرا n (1، 2، 3 و غیره)

نمودار زمان اجرا یا توصیف متنی سناریو را درج کنید.

توصیف جنبه‌های قابل‌توجه تعامل‌ها میان نمونه‌های بلوک سازندهٔ نشان‌داده‌شده در این نمودار را درج کنید.

7. نمای استقرار

زیرساخت فنی با محیط‌ها، رایانه‌ها، پردازنده‌ها، توپولوژی‌ها. نگاشت بلوک‌های سازندهٔ (نرم‌افزاری) به عناصر زیرساخت.

محتوا

نمای استقرار توصیف می‌کند:

• زیرساخت فنی مورد استفاده برای اجرای سیستم شما، با عناصر زیرساختی مانند مکان‌های جغرافیایی، محیط‌ها، رایانه‌ها، پردازنده‌ها، کانال‌ها و توپولوژی‌های شبکه و همچنین سایر عناصر زیرساخت، و

• نگاشت بلوک‌های سازندهٔ (نرم‌افزاری) به آن عناصر زیرساخت.

اغلب سیستم‌ها در محیط‌های مختلفی اجرا می‌شوند، مثلاً محیط توسعه، محیط آزمون، محیط تولید. در چنین مواردی باید همهٔ محیط‌های مرتبط را مستند کنید.

به‌ویژه وقتی نرم‌افزار شما به‌صورت سیستم توزیع‌شده با بیش از یک رایانه، پردازنده، سرور یا کانتینر اجرا می‌شود یا وقتی پردازنده‌ها و تراشه‌های سخت‌افزاری خود را طراحی و می‌سازید، نمای استقرار را مستند کنید.

از دیدگاه نرم‌افزار، ثبت آن عناصر زیرساختی که برای نشان دادن استقرار بلوک‌های سازندهٔ شما لازم‌اند کافی است. معماران سخت‌افزار می‌توانند فراتر بروند و زیرساخت را تا هر سطح از جزئیاتی که برای ثبت لازم دارند توصیف کنند.

انگیزه

نرم‌افزار بدون سخت‌افزار اجرا نمی‌شود. این زیرساخت زیربنایی می‌تواند و خواهد توانست بر سیستم شما و/یا برخی مفاهیم فراگیر تأثیر بگذارد. بنابراین باید زیرساخت را بشناسید.

شکل

شاید نمودار استقرار سطح بالاترین پیش‌تر در بخش 3.2 به‌عنوان زمینهٔ فنی با زیرساخت خود شما به‌صورت یک (ONE) جعبه سیاه گنجانده شده باشد. در این بخش با نمودارهای استقرار اضافی روی این جعبه سیاه بزرگ‌نمایی می‌کنید.

• UML برای بیان آن نما نمودارهای استقرار ارائه می‌دهد. وقتی زیرساخت شما پیچیده‌تر است از آن، احتمالاً با نمودارهای تودرتو، استفاده کنید.

• وقتی ذی‌نفعان (سخت‌افزاری) شما انواع دیگر نمودار را به نمودار استقرار UML ترجیح می‌دهند، بگذارید هر نوعی را که می‌تواند گره‌ها و کانال‌های زیرساخت را نشان دهد به کار ببرند.

7.1 زیرساخت سطح 1

توصیف کنید (معمولاً با ترکیبی از نمودارها، جدول‌ها و متن):

• توزیع سیستم شما در چند مکان، محیط، رایانه، پردازنده، .. و همچنین اتصالات فیزیکی میان آن‌ها

• توجیه یا انگیزهٔ مهم برای این ساختار استقرار

• ویژگی‌های کیفیت و/یا کارایی زیرساخت

• نگاشت مصنوعات نرم‌افزاری (بلوک‌های سازنده) به عناصر زیرساخت

برای محیط‌های متعدد یا استقرارهای جایگزین، لطفاً آن بخش از arc42 را برای همهٔ محیط‌های مرتبط کپی کنید. **

7.2 زیرساخت سطح 2

اینجا می‌توانید ساختار درونی (برخی از) عناصر زیرساخت سطح 1 زیرساخت را بگنجانید.

لطفاً ساختار سطح 1 را برای هر عنصر انتخاب‌شده کپی کنید.

8. مفاهیم فراگیر

به‌طور کلی، مقررات اصلی و رویکردهای راه‌حل مرتبط در چندین بخش (← فراگیر) سیستم. مفاهیم اغلب به چندین بلوک سازنده مربوط می‌شوند. موضوعات مختلفی مانند مدل‌های دامنه، الگوها و سبک‌های معماری، قواعد استفاده از فناوری مشخص و قواعد پیاده‌سازی را شامل شوید.

محتوا

این بخش مفاهیم فراگیر (شیوه‌ها، الگوها، مقررات یا ایده‌های راه‌حل) را توصیف می‌کند. چنین مفاهیمی اغلب به چندین بلوک سازنده مربوط می‌شوند. ممکن است موضوعات بسیار متنوعی را شامل شوند.

انگیزه

مفاهیم پایهٔ یکپارچگی مفهومی (سازگاری، همگنی) معماری را تشکیل می‌دهند. بنابراین، سهم مهمی در دستیابی به کیفیت‌های درونی سیستم شما دارند.

این جایی در قالب است که ما برای مشخصات منسجم چنین مفاهیمی در نظر گرفته‌ایم.

بسیاری از این مفاهیم به چندین بلوک سازندهٔ شما مربوط‌اند یا بر آن‌ها تأثیر می‌گذارند.

شکل

شکل می‌تواند متنوع باشد:

• مقالات مفهومی با هر نوع ساختار

• پیاده‌سازی‌های نمونه، به‌ویژه برای مفاهیم فنی

• گزیده‌های مدل فراگیر یا سناریوها با استفاده از نمادگذاری‌های نماهای معماری

ساختار این بخش

فقط موضوعات مورد نیاز بیشتر را برای سیستم خود برگزینید و به هر کدام در این بخش یک عنوان سطح 2 بدهید (مثلاً 8.1، 8.2 و غیره).

• تلاش نکنید همهٔ موضوعات نمودار فوق را پوشش دهید.

پس‌زمینه

برخی موضوعات در سیستم‌ها اغلب به چندین بلوک سازنده، عنصر سخت‌افزاری یا فرایند توسعه مربوط می‌شوند. ممکن است ارتباط یا مستندسازی چنین موضوعات فراگیری در یک مکان مرکزی، به‌جای تکرار آن‌ها در توصیف بلوک‌های سازنده، عناصر سخت‌افزاری یا فرایندهای توسعهٔ ذی‌ربط، آسان‌تر باشد.

برخی مفاهیم ممکن است همهٔ عناصر یک سیستم را در بر بگیرند و برخی دیگر فقط برای چند مورد مرتبط باشند.

9. تصمیمات معماری

تصمیم‌های معماری مهم، پرهزینه، حیاتی، بزرگ‌مقیاس یا پرخطر همراه با دلایل.

محتوا

تصمیم‌های معماری مهم، پرهزینه، بزرگ‌مقیاس یا پرخطر همراه با دلایل. منظور ما از «تصمیم‌ها» انتخاب یک جایگزین بر پایهٔ معیارهای داده‌شده است.

لطفاً با قضاوت خود تصمیم بگیرید که آیا یک تصمیم معماری باید در این بخش مرکزی مستند شود یا بهتر است آن را به‌صورت محلی (مثلاً در قالب جعبه سفید یکی از بلوک‌های سازنده) مستند کنید. از متن‌های تکراری پرهیز کنید. به بخش 4 ارجاع دهید که در آن مهم‌ترین تصمیم‌های معماری خود را پیش‌تر ثبت کرده‌اید.

انگیزه

ذی‌نفعان سیستم شما باید بتوانند تصمیم‌های شما را درک و ردیابی کنند.

شکل

• ADR (رکورد تصمیم معماری) برای هر تصمیم مهم

• فهرست یا جدول، مرتب‌شده بر اساس اهمیت و پیامدها، یا

• تفصیلی‌تر به‌صورت بخش‌های جداگانه برای هر تصمیم

پس‌زمینه (دربارهٔ ADRها)

تکه‌های کوچک‌تر مستندات خواندن، ایجاد و نگهداری آسان‌تری دارند. وقتی صحبت از تصمیم‌های معماری است، تیم‌های توسعه اغلب:

• از تصمیم خبر دارند، زیرا مثلاً در کد منبع دیده می‌شود، اما

• انگیزهٔ پشت آن تصمیم را از دست می‌دهند (Nygard 2011 را ببینید)

بنابراین باید چند تصمیم مهم را همراه با انگیزه و استدلال آن‌ها مستند کنید

پیشنهاد ما دربارهٔ تصمیم‌ها

مجموعه‌ای از تصمیم‌های مهم از نظر معماری را نگه دارید، یعنی تصمیم‌هایی که بر ساختار، ویژگی‌های کیفی، وابستگی‌ها و رابط‌های مهم (به‌ویژه بیرونی) یا تکنیک‌های ساخت تأثیر می‌گذارند (با تشکر از Michael Nygard برای این پیشنهاد).

10. نیازمندی‌های کیفیت

نیازمندی‌های کیفیت به‌صورت سناریو، همراه با درخت کیفیت برای ارائهٔ مرور سطح بالا. مهم‌ترین اهداف کیفی باید در بخش 1.2 (اهداف کیفی) توصیف شده باشند.

محتوا

این بخش شامل همهٔ نیازمندی‌های کیفیت مرتبط است.

مهم‌ترین این نیازمندی‌ها پیش‌تر در بخش 1.2 (اهداف کیفی) توصیف شده‌اند، بنابراین اینجا فقط باید به آن‌ها ارجاع شود. در این بخش 10 باید نیازمندی‌های کیفیت با اهمیت کمتر را نیز ثبت کنید، که در صورت تحقق کامل نیافتن ریسک‌های بزرگ ایجاد نمی‌کنند (اما ممکن است داشتنشان خوب باشد).

انگیزه

از آنجا که نیازمندی‌های کیفیت تأثیر زیادی بر تصمیم‌های معماری خواهند داشت، باید بدانید کدام کیفیت‌ها برای ذی‌نفعان شما واقعاً مهم‌اند، به‌صورتی مشخص و قابل اندازه‌گیری.

اطلاعات بیشتر

مدل جامع کیفیت Q42 را در https://quality.arc42.org ببینید.

10.1 مرور نیازمندی‌های کیفیت

محتوا

مرور یا خلاصه‌ای از نیازمندی‌های کیفیت.

انگیزه

اغلب با ده‌ها (یا حتی صدها) نیازمندی کیفیت تفصیلی روبه‌رو می‌شویم. در این بخش مرور باید سعی کنید خلاصه‌سازی کنید، مثلاً با توصیف دسته‌ها یا موضوعات (آنچه ISO 25010:2023 یا Q42 پیشنهاد می‌کنند

اگر این توصیف‌های خلاصه از پیش دقیق، به‌اندازهٔ کافی مشخص و قابل اندازه‌گیری باشند، می‌توانید بخش 10.2 را رد کنید.

شکل

از یک جدول ساده استفاده کنید که هر سطر آن شامل یک دسته یا موضوع و توصیف کوتاه نیازمندی کیفیت باشد. به‌طور جایگزین، می‌توانید از نقشهٔ ذهنی برای ساختار دادن به این نیازمندی‌های کیفیت استفاده کنید.

در متون، ایدهٔ درخت ویژگی کیفی نیز توصیف شده است، که واژهٔ کلی «کیفیت» را ریشه قرار می‌دهد و از پالایش درخت‌مانند واژهٔ «کیفیت» استفاده می‌کند. [Bass+21] اصطلاح «Quality Attribute Utility Tree» را برای این منظور معرفی کرد.

10.2 سناریوهای کیفیت

محتوا

سناریوهای کیفیت نیازمندی‌های کیفیت را مشخص می‌کنند و امکان تصمیم‌گیری دربارهٔ اینکه آیا برآورده شده‌اند (به معنای معیارهای پذیرش) را فراهم می‌کنند. مطمئن شوید که سناریوهای شما مشخص و قابل اندازه‌گیری‌اند.

دو نوع سناریو به‌ویژه مفیدند:

• سناریوهای استفاده (که سناریوهای کاربرد یا سناریوهای مورد استفاده نیز نامیده می‌شوند) واکنش زمان اجرای سیستم به یک محرک مشخص را توصیف می‌کنند. این شامل سناریوهایی نیز می‌شود که کارایی یا عملکرد سیستم را توصیف می‌کنند. نمونه: سیستم ظرف یک ثانیه به درخواست کاربر واکنش نشان می‌دهد.

• سناریوهای تغییر اثر مطلوب یک اصلاح یا گسترش سیستم یا محیط بلافصل آن را توصیف می‌کنند. نمونه: قابلیت اضافی پیاده‌سازی می‌شود یا نیازمندی‌های یک ویژگی کیفی تغییر می‌کند، و تلاش یا مدت تغییر اندازه‌گیری می‌شود.

شکل

اطلاعات معمول برای سناریوهای تفصیلی شامل موارد زیر است:

در شکل کوتاه (مورد پسند مدل Q42):

• زمینه/پس‌زمینه: چه نوع سیستم یا مؤلفه‌ای، محیط یا وضعیت چیست؟

• منبع/محرک: چه کسی یا چه چیزی رفتار، واکنش یا اقدامی را آغاز یا راه‌اندازی می‌کند.

• سنجه/معیار پذیرش: یک پاسخ شامل یک اندازه یا سنجه

شکل بلند سناریوها (مورد پسند SEI و [Bass+21]) تفصیلی‌تر است و شامل اطلاعات زیر است:

• شناسهٔ سناریو: شناسهٔ یکتا برای سناریو.

• نام سناریو: نام کوتاه و توصیفی برای سناریو.

• منبع: موجودیتی (کاربر، سیستم یا رویداد) که سناریو را آغاز می‌کند.

• محرک: رویداد یا شرط محرکی که سیستم باید به آن بپردازد.

• محیط: زمینه یا شرط عملیاتی که سیستم در آن محرک را تجربه می‌کند.

• مصنوع: بلوک‌های سازنده یا سایر عناصر سیستم که از محرک تأثیر می‌پذیرند.

• پاسخ: نتیجه یا رفتاری که سیستم در واکنش به محرک نشان می‌دهد.

• سنجهٔ پاسخ: معیار یا سنجه‌ای که با آن پاسخ سیستم ارزیابی می‌شود.

همچنین ببینید

از ژانویهٔ 2023، arc42 یک مدل کیفیت عملگرا ارائه می‌دهد که پیشنهاد می‌کند نیازمندی‌های کیفیت با هشتگ یا برچسب‌هایی مانند #flexible، #efficient، #usable، #operable، #testable، #secure، #safe، #reliable برچسب‌گذاری شوند.

11. ریسک‌ها و بدهی فنی

ریسک‌ها یا بدهی فنی شناخته‌شده. چه مشکلات بالقوه‌ای در درون یا پیرامون سیستم وجود دارد؟ تیم توسعه از چه چیزی احساس ناراحتی می‌کند؟

محتوا

فهرستی از ریسک‌ها یا بدهی‌های فنی شناسایی‌شده، مرتب‌شده بر اساس اولویت

انگیزه

«مدیریت ریسک، مدیریت پروژه برای بزرگسالان است» (Tim Lister، Atlantic Systems Guild.)

این باید شعار شما برای شناسایی و ارزیابی نظام‌مند ریسک‌ها و بدهی‌های فنی در معماری باشد، که ذی‌نفعان مدیریتی (مثلاً مدیران پروژه، مالکان محصول) به‌عنوان بخشی از تحلیل ریسک کلی و برنامه‌ریزی اندازه‌گیری به آن نیاز خواهند داشت.

شکل

فهرست ریسک‌ها و/یا بدهی‌های فنی، احتمالاً شامل اقدامات پیشنهادی برای به حداقل رساندن، کاهش یا اجتناب از ریسک‌ها یا کاهش بدهی‌های فنی.