«سریع» یک الزام نیست. «پاسخگو» هم نیست. «قابل توسعه» نیز همینطور. بدترین دلیل برای این موضوع این است که هیچ راه عینی برای تشخیص تحقق آنها وجود ندارد. اما با این حال، کاربران آنها را میخواهند. نقش معمار تا حد زیادی کمک به سیستم برای دستیابی به این ویژگیها و متعادلسازی تضادها و ناسازگاریهای اجتنابناپذیر بین آنهاست. بدون معیارهای عینی، معماران در برابر کاربران دمدمیمزاج («نه، قبول نمیکنم، هنوز بهاندازه کافی سریع نیست») و برنامهنویسان وسواسی («نه، منتشر نمیکنم، هنوز بهاندازه کافی سریع نیست») بیدفاع میمانند.
مانند همه الزامات، ما تلاش میکنیم این خواستهها را مکتوب کنیم. اما اغلب صفتهای مبهمی مانند «انعطافپذیر»، «قابل نگهداری» و موارد مشابه ظاهر میشوند. اما مشخص شده است که در هر مورد (بله، حتی «قابل استفاده» با تلاش کافی)، این ویژگیها قابل اندازهگیری هستند و میتوان برای آنها حد آستانه تعیین کرد. در غیر این صورت، هیچ مبنایی برای پذیرش سیستم توسط کاربران وجود ندارد، راهنمای ارزشمندی از دست سازندگانش گرفته میشود و چشمانداز معماران آن نیز مبهم میشود.
سوالات سادهای که باید پرسید: چند تا؟ در چه بازهای؟ هر چند وقت یکبار؟ چقدر زود؟ رو به افزایش یا کاهش؟ با چه نرخی؟ اگر نتوان به این سوالات پاسخ داد، یعنی نیاز بهدرستی درک نشده است. پاسخها باید در طرح تجاری سیستم مشخص شوند و اگر اینطور نیست، باید بهدقت بررسی شوند. اگر شما بهعنوان یک معمار کار میکنید و کسبوکار این اعداد را به شما نداده (یا نمیخواهد بدهد)، از خود بپرسید چرا؟ سپس بروید و آنها را به دست آورید. دفعه بعد که کسی به شما گفت یک سیستم باید «مقیاسپذیر» باشد، از او بپرسید که کاربران جدید از کجا خواهند آمد و چرا؟ تعدادشان چقدر خواهد بود و تا چه زمانی؟ پاسخهایی مانند «خیلی» و «بهزودی» را رد کنید.
معیارهای کمی نامشخص باید بهصورت یک بازه ارائه شوند: حداقل، مقدار اسمی، و حداکثر. اگر این بازه مشخص نشود، یعنی رفتار موردنیاز درک نشده است. همانطور که معماری سیستم شکل میگیرد، میتوان آن را با این معیارها بررسی کرد تا اطمینان حاصل شود که همچنان در محدوده موردنظر قرار دارد. عملکرد سیستم در برابر برخی معیارها در طول زمان تغییر میکند و بازخورد ارزشمندی به دست میآید. یافتن این بازهها و بررسی آنها فرآیندی زمانبر و پرهزینه است. اگر کسی بهاندازه کافی به «عملکرد» سیستم (که نه یک الزام است و نه حتی یک واژه مناسب) اهمیت نمیدهد تا برای آزمایشهای عملکردی هزینه کند، پس احتمالاً عملکرد مهم نیست. در این صورت، شما آزادید که تلاشهای معماری خود را بر روی جنبههایی از سیستم متمرکز کنید که ارزش سرمایهگذاری دارند.
«باید در کمتر از ۱۵۰۰ میلیثانیه به ورودی کاربر پاسخ دهد. تحت بار عادی (که بهطور مشخص تعریف شده است…) میانگین زمان پاسخ باید بین ۷۵۰ تا ۱۲۵۰ میلیثانیه باشد. زمانهای پاسخ کمتر از ۵۰۰ میلیثانیه توسط کاربر قابل تشخیص نیستند، بنابراین برای کاهش بیشتر هزینه نخواهیم کرد.» این یک الزام واقعی است.
نویسنده :Keith Braithwaite
