حالت نقشه‌ی فنی فعال است — تصمیم‌های طراحی این سایت را ببینید

ماتریس ردیابی نیازمندی: از نیاز تا آزمون، بدون جا افتادن

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

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

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

ماتریس ردیابی چیست

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

شناسهنیازمنبعطراحیپیاده‌سازیآزمونوضعیت
N-12کاربر بتواند سفارش را لغو کندجلسه‌ی دومصفحه‌ی سفارش‌هاماژول سفارشT-31تأییدشده
N-13مدیر گزارش لغوها را ببیندسند مناقصهداشبوردماژول گزارشT-32در حال ساخت

با یک نگاه معلوم می‌شود هر نیاز کجاست و کدام خانه خالی مانده است.

ردیابی دوطرفه

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

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

رو به عقب: از کد به نیاز. آیا هر چیزی که ساخته شده، به نیازی برمی‌گردد؟ قابلیتی که به هیچ نیازی وصل نیست، یا اضافه‌کاری است یا نیازی که هیچ‌وقت ثبت نشده.

جهت دوم کمتر دیده می‌شود ولی جلوی بزرگ شدن بی‌دلیل پروژه را می‌گیرد.

چه زمانی لازم است

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

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

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

چطور بسازیم

۱. به هر نیاز شناسه بدهید

شناسه‌ی یکتا و ثابت. بدون آن، ردیابی ممکن نیست. شناسه هرگز دوباره استفاده نمی‌شود، حتی اگر نیاز حذف شود.

۲. نیاز را آزمودنی بنویسید

«سامانه باید سریع باشد» ردیابی نمی‌شود. «فهرست سفارش‌ها در کمتر از دو ثانیه نمایش داده شود» می‌شود. نیازی که نشود برایش آزمون نوشت، هنوز نیاز نیست؛ یک آرزوست.

۳. منبع را ثبت کنید

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

۴. در طول پروژه پر کنید، نه در پایان

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

۵. تغییر را ثبت کنید

وقتی نیازی عوض یا حذف می‌شود، ردیفش پاک نمی‌شود؛ وضعیتش عوض می‌شود و دلیلش نوشته می‌شود.

تحلیل اثر تغییر

یکی از مفیدترین کاربردهای ماتریس وقتی است که کارفرما می‌گوید «این را عوض کنیم». با ماتریس می‌شود در چند دقیقه گفت این تغییر به کدام طراحی، کدام بخش کد و کدام آزمون‌ها اثر می‌گذارد. تخمین دقیق‌تر می‌شود و چیزی فراموش نمی‌شود.

ارتباط با دروازه‌های تأیید

ماتریس ردیابی و دروازه‌های تأیید مکمل هم‌اند. در هر دروازه، ماتریس پاسخ یک پرسش مشخص را می‌دهد:

  • پایان تعریف: آیا همه‌ی نیازها شناسه و منبع دارند؟
  • پایان طراحی: آیا هر نیاز در طراحی دیده شده است؟
  • پایان ساخت: آیا هر نیاز پیاده شده است؟
  • پایان اعتبارسنجی: آیا هر نیاز آزمونی دارد که پاس شده است؟

در گام آخر، ماتریس پرشده همان مدرک تحویل است.

اشتباه‌های رایج

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

جمع‌بندی

ماتریس ردیابی ابزار پرزرق‌وبرقی نیست، ولی به یک پرسش مهم پاسخ قطعی می‌دهد: «آیا آنچه خواسته شد، ساخته و آزموده شده است؟» در پروژه‌های بزرگ، همین پاسخ تفاوت تحویل مطمئن با تحویل پرتنش است.

برای پروژه‌ی در جریانی که به نظم نیاز دارد، هدایت پروژه و کیفیت را ببینید.

نویسنده

محمد علی اسلامی‌پور

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