تحلیلگران کسب و کار اغلب می پرسند که چرا به آنچه که می خواستند در پروژه خود انجام دهند دست پیدا نکرده اند یا چگونه می توانند در پروژه های آینده بهتر عمل کنند. در پاسخ به این سوال، به راحتی می توان الگوی اشتباهاتی را که به نظر می رسد بارها و بارها رخ می دهند، تشخیص داد. بیایید پنج اشتباه رایج مربوط به توسعه و مدیریت الزامات در یک طرح را با هم بررسی کنیم.
- از دست دادن دید اصلی: در حین انجام فعالیت‌های مربوط به توسعه و مدیریت الزامات یک پروژه طولانی، به راحتی ممکن است چشم‌انداز اصلی و اهداف تجاری از دست بروند. این امر ممکن است به این دلیل رخ دهد که اهداف در طول یک پروژه تغییر می کنند، توافقات و اغماض هایی در پروژه انجام می شوند و یا تغییری در حامیان پروژه ایجاد می شود. به همین دلیل ضروری است که چشم انداز پروژه و اهداف تجاری به وضوح تعریف شده و برای بررسی توسط همه ذینفعان و اعضای تیم پروژه که روی پروژه کار می کنند در دسترس باشند و در چرخه های بررسی در طول عمر پروژه ادغام گردند.
- درک نشدن فرآیند کسب و کار قبل از تعریف الزامات نرم افزاری: پروژه‌های سیستمی تنها برای تکنولوژی های جدید در نظر گرفته نشده‌اند، بلکه برای کمک به خودکارسازی فرآیندهای کسب و کار و کارآمدتر کردن فرآیند کسب و کار نیز انجام می‌شوند. قبل از شروع به تعریف الزامات نرم افزاری که فرآیند را خودکار می کند، می بایست درک کاملی از نحوه عملکرد فرآیند کسب و کار به دست آورید. این درک کامل از فرآیند کسب و کار هم برای ذینفعان و هم برای اعضای تیم پروژه مهم است. اغلب اوقات، ذینفعان فقط فرآیند فعلی را درک می کنند و فرآیند جدید را نمی توانند به خوبی درک نمایند و بنابراین به جای فرآیند پیشنهادی، نیازهای کاربر را برای فرآیند فعلی ارائه می نمایند. این امر اصطلاحا منجر به “بازسازی راه مال رو” می شود.
- ایجاد نکردن آنچه ذینفعان می خواهند: اغلب اوقات، با ذینفعان طی یک جلسه مصاحبه انجام می شود و در مورد الزامات نهایی یا تغییراتی که در طول عمر پروژه در الزامات ایجاد شده است، مطلع نمی شوند. این باور کاملا غیر واقعی است که تصور کنیم الزامات معنادار را می توان تنها با یک جلسه یک ساعته با یک ذینفع کلیدی جمع آوری کرد. استخراج الزامات یک فعالیت تکراری و افزایشی است و برگزاری تنها یک جلسه با یک ذینفع کلیدی برای به دست آوردن درکی واقعی از نیازهای کاربر واقعی کارساز نخواهد بود. به احتمال زیاد نیاز به یک سری مصاحبه با کاربران مختلف در همه سطوح خواهد بود، زیرا الزامات طی یک دوره زمانی به طور پیوسته اصلاح می شوند.
- تهیه نکردن برنامه برای مدیریت الزامات: برنامه ریزی برای مدیریت الزامات، فعالیت های کلیدی را برای توسعه و مدیریت الزامات و همچنین نقش ها و مسئولیت ها تعریف می کند. ذینفعان کلیدی، تحلیلگران الزامات، منابع توسعه و مدیریت پروژه باید در اوایل چرخه عمر پروژه در مورد فرمت سند الزامات و فعالیت ها به توافق برسند.
- برنامه مدیریت الزامات باید شامل موارد زیر باشد:
- روش‌های جمع‌آوری الزامات (مصاحبه ها، جلسات گروهی بررسی صاحبان کسب و کار ، مشاهدات و غیره)
- فرمت اسناد مورد نیاز شامل تکنیک های مختلف مورد استفاده همچون موارد استفاده، داستان های کاربری و غیره.
- انواع مختلفی از تکنیک‌های ترسیم و مصورسازی الزامات (نقشه‌های فرآیند کسب و کار، نمودارهای UML، وایرفریم، تخته وایت بردها و غیره)که مورد استفاده قرار می‌گیرند.
- نحوه ردیابی و استفاده از الزامات در فعالیت های مختلف پروژه مانند طراحی، تست سیستم و تست پذیرش کاربر.
- رویکرد کنترل تغییرات – چگونه تغییرات ایجاد شده الزامات تایید می شوند و به تیم پروژه ابلاغ می شوند.
- فرمت الزامات نیز باید توسط کارکنان فنی کلیدی مورد موافقت قرار گیرند تا اطمینان حاصل شود که هیچ مقاومتی در برابر ساختار یا محتویات بعدی در پروژه وجود ندارد.
- عدم توسعه الزامات به صورت مکرر: اکثر متدولوژی های مدرن توسعه سیستم، نوعی از توسعه تکراری را تجویز می کنند. این امر به ویژه در مورد روش های توسعه Agile مانند Scrum یا XP صادق است. انتظار برای «تمام شدن» الزامات قبل از شروع توسعه برای این متدولوژی ها کارساز نیست.
الزامات باید به طور مکرر بر اساس اولویت ها جمع آوری شده و بر اساس روش توسعه استفاده شده در اختیار تیم توسعه قرار گیرند. به عنوان مثال، اگر تیم توسعه برنامه دارد که هر سه ماه ورژن جدیدی از نرم‌افزار را ارئه دهد، الزامات می بایست برای هر یک از ورژن های سه ماهه برای تیم توسعه منتشر شوند. انتشار یک سند جامع برای همه الزامات نمی تواند برای توسعه تکراری به نحو موثری کارگر باشد. استفاده از روش‌های تکراری برای توسعه الزامات مزایای بسیاری را به همراه دارد که از جمله می‌توان به موارد زیر اشاره کرد:
- الزامات انتزاعی هستند و اغلب نیاز به یک سیستم کار واقعی است تا ذینفعان ببینند و تجربه کنند و بتوانند صحت الزامات را تأیید نمایند.
- پس از بازبینی اتفاقات گذشته، الزامات در نسخه های بعدی بسیار بهتر خواهند شد و ذینفعان درک بهتری از نحوه عملکرد سیستم و فرآیند پیدا خواهند کرد.
- توسعه دهندگان می توانند در چرخه عمر پروژه کار را زودتر شروع کنند و محصول نهایی را زودتر تحویل دهند.
- مدیریت پروژه بازخورد اولیه در مورد امکان سنجی و کیفیت الزامات را از تیم توسعه دریافت خواهد کرد.
