کشف نیازمندی‌های نرم‌افزار در اولین مراحل توسعه همواره از مهمترین مسائل شناخت بوده است و همانطور که مطلب «پیچیدگی نیازمندی‌های نرم‌افزار» و «مدلسازی نیازمندی‌های کیفی» بیان شد، استفاده از برخی نکات یا دسته‌بندی ارائه‌شده توسط استانداردها می‌تواند به شناخت و مدلسازی نیازمندی‌های نرم‌افزار کمک کند. در واقع، با مطالعه کتاب‌های مختلف (کتاب‌هایی که من تاکنون مطالعه نمودم) نکاتی در مورد انواع طبقه‌بندی  نیازمندی‌ها، روش گام به گام شناسایی و مدلسازی نیازمندی‌ها، قالب نوشتن نیازمندی‌ها و همچنین چگونگی ارزیابی اولیه نیازمندی‌ها به‌دست می‌آورید. اما وقتی اندازه نرم‌افزار متوسط یا بزرگ باشد یا نیاز به شناخت سریع برای نوشتن پروپوزال دارید، روش‌های متداول توسعه نیازمندی‌ها اغلب نمی‌توانند مورد استفاده قرار گیرند چرا که اغلب موارد، این روش‌ها نیازمند زمان، همراهی کارفرما و یا تیم باتجربه می‌باشند. شاید یکی از بهترین کتاب‌هایی که در حوزه نیازمندی‌ها نوشته شده باشد، کتاب «نیازمندی‌های نرم‌افزار» آقای Karl Wiegers و Joy Beatty می‌باشد که با جزئیات مناسبی توسعه نیازمندی‌ها را پوشش داده است.

در توسعه نرم‌افزارها، اغلب کشف نیازها (Needs)، نیازمندی‌های ذی‌نفعان (Stakeholder Requirements) و نیازمندی‌های سیستمی (System Requirements) همواره چالشی را در ابتدای پروژه توسعه نرم‌افزار ایجاد می‌کند. علاوه بر این دسته‌بندی نیازمندی‌های کارکردی و کیفی هم بر این چالش اضافه می‌نماید، خصوصاً وقتی اندازه نرم‌افزار از حدی فراتر رود و تعداد افراد درگیر (ذی‌نفعان) افزایش یابد. یادمان باشد که به این دو موضوع باید سطح‌بندی نیازمندی‌های (Granularity) را نیز اضافه کنیم، چرا که برخی از نیازمندی‌ها بسیار جزئی و برخی بسیار درشت هستند. مطالعه کتاب‌های مختلف تقریباً سودی ندارد! و شاید هم ضرر داشته باشد! راه‌حل چیست؟

برگرفته از www.meetsky.me

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

ConcernsCategoriesبرگرفته از کتاب (Software Systems Architecture)

به‌صورت عملی شما نیاز دارید تا برای نرم‌افزار دغدغه‌ها در حوزه‌های ذیل را کشف کنید. این حوزه‌ها، «تصمیمات کلیدی معماری» (Architecturally Significant Decisions) را تشکیل می‌دهند و پاسخ به این حوزه‌ها در مراحل اولیه شناخت کافیست و نیازی به سایر دسته‌بندی‌های نیازمندی‌ها برای شناخت نخواهید داشت! این تصمیمات می‌توانند از ذی‌نفعان استخراج شده، از استانداردها اخذ شده یا با استفاده از تجربه تعیین شوند. بسته به نوع نرم‌افزار می‌توان برخی از این تصمیمات را نادیده گرفت و یا برخی را با جزئیات بیشتری دقیق نمود.

  • تخصیص وظایف: وظایف کلیدی سیستم را تعیین کنید. از نظر من، وظایف کلیدی سیستم نباید بیش از 5 مورد باشند.
  • مدل هماهنگی: مکانیزم‌ها و روش‌های هماهنگی (پروتکل‌های ارتباطی) بین عناصر نرم‌افزار و یا برای ارتباط با عناصر خارج از نرم‌افزار را تعیین کنید.
  • مدل داده: خصوصیات و ویژگی‌های مربوط به نحوه ذخیره داده‌ها و پایگاه داده‌ها را تعیین کنید.
  • مدیریت منابع: نحوه مدیریت منابع توسط نرم‌افزار را تعیین کنید.
  • انتخاب فناوری: زیرساخت‌های فنی برای اجرای نرم‌افزار و بسترهای مورد نیاز برای توسعه را تعیین کنید.
  • تصمیمات زمان تقید: بسته به نوع فناوری، ممکن است نیاز باشد تصمیماتی در مورد تقید و زمان تقید بگیرید.
  • نگاشت بین عناصر: نگاشت بین ماژول‌های طراحی و عناصر زمان اجرا را تعیین کنید.

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

برای مطالعه دقیق‌تر در این زمینه می‌توانید فصل هشتم از کتاب Software Systems Architecture و بخش 4.6 و بخش‌های سوم از فصل‌های پنجم تا یازدهم  از کتاب Software Architecture in Practice را مطالعه نمایید. اگر نیازمند یک مثال عملی در این زمینه هستید، می‌توانید با اینجانب تماس بگیرد.