كشف نيازمندي‌هاي نرم‌افزار در اولين مراحل توسعه همواره از مهمترين مسائل شناخت بوده است و همانطور كه مطلب «پيچيدگي نيازمندي‌هاي نرم‌افزار» و «مدلسازي نيازمندي‌هاي كيفي» بيان شد، استفاده از برخي نكات يا دسته‌بندي ارائه‌شده توسط استانداردها مي‌تواند به شناخت و مدلسازي نيازمندي‌هاي نرم‌افزار كمك كند. در واقع، با مطالعه كتاب‌هاي مختلف (كتاب‌هايي كه من تاكنون مطالعه نمودم) نكاتي در مورد انواع طبقه‌بندي  نيازمندي‌ها، روش گام به گام شناسايي و مدلسازي نيازمندي‌ها، قالب نوشتن نيازمندي‌ها و همچنين چگونگي ارزيابي اوليه نيازمندي‌ها به‌دست مي‌آوريد. اما وقتي اندازه نرم‌افزار متوسط يا بزرگ باشد يا نياز به شناخت سريع براي نوشتن پروپوزال داريد، روش‌هاي متداول توسعه نيازمندي‌ها اغلب نمي‌توانند مورد استفاده قرار گيرند چرا كه اغلب موارد، اين روش‌ها نيازمند زمان، همراهي كارفرما و يا تيم باتجربه مي‌باشند. شايد يكي از بهترين كتاب‌هايي كه در حوزه نيازمندي‌ها نوشته شده باشد، كتاب «نيازمندي‌هاي نرم‌افزار» آقاي 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 را مطالعه نماييد. اگر نيازمند يك مثال عملي در اين زمينه هستيد، مي‌توانيد با اينجانب تماس بگيرد.