تحلیل کسب و کار: الزامات خوب برنامه ریزی شده

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

  • یک سند الزامات خوب می‌تواند بخشی از یک گروه با نیازهای سطح بالا باشد که به زیر الزامات تقسیم شده باشد.
  • آن‌ها همچنین ممکن است شامل مشخصاتی باشند که شامل مجموعه‌ای از الزامات کارکردی است که رفتار یا اجزای محصول نهایی را توصیف می‌کنند.
  • الزامات خوب باید مختصر و خاص باشند و باید به این سوال پاسخ دهند، ” ما چه نیاز داریم؟ به جای این سوال که، ” ما چگونه به یک نیاز عمل می‌کنیم؟ “
  • الزامات خوب تضمین می‌کنند که همه سهامداران بخشی از برنامه خود را درک کنند؛ اگر بخش‌ها نامشخص باشند یا بد تعبیر شوند، محصول نهایی می‌تواند معیوب و یا شکست بخورد.

تحلیل و جمع آوری الزامات

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

الزامات باید:

  • مستندسازی
  • قابل‌اجرا
  • قابل‌اندازه‌گیری
  • قابل آزمون
  • قابل ردیابی

الزامات باید به نیازها یا فرصت‌های کسب‌وکار شناسایی‌شده مرتبط باشند و برای سطحی از جزییات کافی برای طراحی سیستم تعریف شوند.

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

رویکرد استخراجی

برای استخراج اهداف، از متخصص کسب‌وکار، مدیر توسعه، و اسپانسر پروژه سوالات زیر  را بپرسید:

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

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

انواع مختلف الزامات

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

الزامات کسب‌وکار کار

الزامات کسب‌وکار فعالیت‌های حیاتی یک شرکت هستند که باید برای برآورده کردن اهداف سازمانی در عین حال مستقل بودن راه‌حل انجام شود. یک سند الزامات کسب‌وکار ( BRD ) جزئیات کسب‌وکار یک پروژه از جمله مستندسازی نیازها و انتظارات مشتری را توضیح می‌دهد.

نیازمندی‌های کاربر

الزامات کاربر باید الزامات ویژه‌ای که کاربر انتظار دارد / از نرم‌افزاری که از پروژه نرم‌افزاری ساخته شده‌باشد را مشخص کند. نیاز کاربر باید قابل تایید، روشن و مختصر، کامل، یکدست، پایدار، قابل دوام باشد.

سند الزامات کاربر ( urd ) یا مشخصات نیازمندی‌های کاربر یک سند است که معمولا در مهندسی نرم‌افزار به کار می‌رود که آنچه را که کاربر انتظار دارد نرم‌افزار قادر به انجام آن باشد مشخص می‌کند.

الزامات سیستم

الزامات سیستم با تعریف الزامات منابع نرم‌افزاری و پیش‌نیازهای لازم برای نصب بر روی یک کامپیوتر برای ارایه عملکرد بهینه یک برنامه سروکار دارند.

الزامات کارکردی

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

الزامات غیر کارکردی

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

الزامات غیر کارکردی در مورد نحوه ظاهر سیستم صحبت می‌کنند و یا می توان آن را ” سیستم باید باشد ” ذکر کرد. الزامات غیر کاربردی به عنوان ویژگی‌های سیستم نامیده می‌شوند

الزامات انتقال

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

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

قابلیت پی‌گیری و مدیریت تغییر

قابلیت پی‌گیری نیازمندی‌ها راهی برای سازماندهی، سند و پی‌گیری تمام نیازمندی‌های شما از طریق ایجاد ایده اولیه از طریق مرحله آزمایش است .

ماتریس قابلیت ردیابی الزامات ( RTM) روشی را برای ردیابی نیازمندی‌های کاربردی و اجرای آن‌ها از طریق فرآیند توسعه ارائه می‌دهد. هر الزام در ماتریس همراه با شماره بخش مربوطه آن گنجانده شده‌است.

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

شامل ستون‌هایی برای هر یک از موارد زیر باشد:

  • شرح نیازمندی‌های
  • ارجاع ضروری در سند الزامات کارکردی
  • روش تائیدیه
  • نیاز به ارجاع در برنامه آزمایش

مثال: اتصال نقاط برای شناسایی روابط بین آیتم‌های درون پروژه تان. این یک اتصال‌دهنده از جریان عادی رو به پایین است.

ایده طراحی الزامات آزمایش اهداف کسب و کار

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

با ردیابی الزامات، شما قادر به تشخیص تغییرات اثر ریپل ( موج‌دار ) هستید، ببینید که آیا یک الزام تکمیل شده‌است و اینکه آیا این نیاز به درستی آزمایش شده‌است یا نه . قابلیت پی‌گیری و مدیریت تغییر به مدیران آرامش ذهن و قابلیت دید مورد نیاز برای پیش‌بینی مسائل و تضمین کیفیت پیوسته را می‌دهد .

تضمین کیفیت

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

به طور مختصر، نیازمندی‌های خاص می‌تواند به شما کمک کند تا مشکلات را زودتر تشخیص دهید و مشکلات را زودتر حل کنید تا زمانی که تعمیر آن گران‌تر است. علاوه بر این ، آن می‌تواند ۱۰۰ برابر بیشتر برای اصلاح یک نقص بعد از کد گذاری بعد از کدگذاری شده باشد، تا زمانی که یک الزام درست باشد.

با ادغام مدیریت الزامات در فرآیند تضمین کیفیت تان، می‌توانید به تیم خود کمک کنید تا کارایی را افزایش داده و دوباره‌کاری را حذف کند. علاوه بر این دوباره‌کاری است که بیشتر مسایل هزینه روی می‌دهد.

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

به طور خلاصه، مدیریت الزامات می‌تواند مانند یک رشته پیچیده به نظر برسد، اما وقتی آن را به یک مفهوم ساده متصل نمایید – آن در مورد کمک به تیم‌ها برای پاسخ به این سوال است، ” آیا همه می‌دانند که ما چه چیزی می‌سازیم و چرا؟ ” از تحلیلگران کسب‌وکار، مدیران محصول و مدیران پروژه تا توسعه دهندگان، مدیران تضمین کیفیت و آزمایش کنندگان، همراه با سهامداران و مشتریان دخیل، بنابراین اغلب علت اصلی شکست پروژه یک سو تفاهم در حوزه پروژه است.

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

نکته، تحقیقات نشان داده‌اند که تیم‌های پروژه می‌توانند ۵۰ تا ۸۰ درصد خطاهای پروژه را با مدیریت موثر الزامات حذف کنند. طبق گفته موسسه مهندسی نرم‌افزار کارنگی ملون، ” ۶۰ – ۸۰ درصد از هزینه توسعه نرم‌افزار در حال دوباره‌کاری است .”

به دست آوردن الزامات پایان جا زده

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

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

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

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *