فرایند مدیریت الزامات

فرایند مدیریت الزامات و مهندسی سیستم ها

فرایند مدیریت الزامات و مهندسی سیستم ها

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

فرایند مدیریت الزامات و تشریح گام های فرایند

گام اول: شناسایی ذینفعان

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

گام دوم: درک نیازهای مشتری

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

گام سوم: تدوین الزامات

مهندس سیستم ها برای شناخت کامل نیازها باید مشتری و سایر ذینفعان اصلی سیستم را در فرآیند تعریف، شفاف سازی و اولویت بندی الزامات دخیل کند. الزامات بصورت آماده در اختیار مهندسین سیستم قرار نمی گیرند بلکه باید آنها را از بطن نیازهای ذینفعان استخراج کرد. تعریف کارکردهایی که هر یک از اجزاء و زیرسیستم ها باید برای تحقق مأموریت اصلی سیستم انجام دهد می تواند به شناخت بهتر الزامات کمک کند. البته فرآیند تخصیص الزامات به کارکردها فرآیند پیچیده ای است که مستلزم انجام بازنگری های مکرر و متعددی جهت تطبیق کارکردها با الزامات تعریف شده است. بنابراین، در اینجا هدف از شناسایی کارکردها صرفاً شناخت بهتر الزامات رفتاری سیستم است. با استخراج هر الزام جدید، باید ضرورت و منطق وجودی آن مورد بررسی قرار گیرد تا پس از شناسایی کامل الزامات بتوان الزامات غیرضروری یا سخت گیرانه را در تعامل با مشتری حذف یا تعدیل و نسبت به اولویت بندی مابقی آنها اقدام کرد.

فرایند مدیریت الزامات و مهندسی سیستم ها

گام چهارم: شفاف سازی الزامات

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

گام پنجم: شکست الزامات

شکست الزامات به معنای تجزیه یک الزام به دو یا چند الزام دیگر است. در این فرآیند، مجموع محتوای الزامات جدید برابر با محتوای الزام اولیه است با این تفاوت که آنها از شفافیت و جزئیات بیشتری نسبت به الزام اولیه برخوردارند. عمل شکست الزامات عمدتاً در مورد الزامات مبهم و مرکب صورت می گیرد تا با انجام تجزیه بتوان الزامات اولیه را حذف و الزامات جدید را جایگزین آنها کرد. برای درک بهتر موضوع شرایطی که باید یک الزام محقق نماید تا به عنوان یک الزام خوب تلقی شود؛ عبارتند از:
۱- غیر مبهم : الزام باید تنها یک تفسیر، مفهوم و معنی داشته باشد و نتوان از آن بیش از یک مفهوم برداشت کرد (به عنوان یک نکته در این قسمت، نباید از کلمات مختصر در الزام استفاده کرد).
۲- قابل تست : الزام باید به گونه ای باشد تا بتوان از طریق تصدیق و صحه گذاری به تحقق درستی آنها پی برد. بنابراین با توجه به اینکه نتیجه هر تست باید یا قبول یا رد باشد لذا الزام باید واضح، صریح و غیر مبهم باشد.
۳- واضح و روشن (کوتاه، مختصر، ساده، دقیق و صریح): الزام نمی بایست حاوی اطلاعات اضافی و غیر لازم باشد و نمی بایست مطالب غیر مفید در الزام آورده شود.
۴- صحیح و درست : اگر الزام دارای موارد واقعی و حقیقی است این موارد باید درست، واقعی و صحیح باشد؛
۵- قابل فهم : الزام باید از نظر دستور زمانی صحیح باشد و در یک سبک مناسب ادبی نگارش شود. به عبارت دیگر ادبیات نگارش رعایت شده و جمله بندی الزامات درست باشد.
۶- امکانپذیر (واقعی و ممکن) یا قابل دستیابی : الزام باید با توجه به محدودیت های موجود مانند فناوری های در دسترس، زمان، مالی و منابع در دسترس، قابل اجرا و شدنی باشد.
۷- غیر وابسته و مستقل : الزام باید به گونه ای باشد که برای درک آن نیازی به دانستن سایر الزامات نباشد.
۸- تجزیه ناپذیر : الزام باید شامل یک جزء قابل ردیابی تکی باشد
۹- لازم و ضروری : یک الزام در صورتی غیر ضروری است که یکی از ویژگی های ذیل را داشته باشد:
– هیچ ذی نفعی آن را نیاز نداشته باشد؛
– حذف الزام بر روی سیستم تاثیر نداشته باشد؛
۱۰- مستقل از نحوه اجرا باشد : الزامات نباید حاوی اطلاعات طراحی و پیاده سازی غیر ضروری باشد و در آنها نباید چگونگی تحقق الزامات بیان شود.
علاوه بر معیارهای فوق که مربوط به الزامات منفرد بودند، سه معیار نیز برای مجموعه الزامات وجود دارد که عبارتند از:
۱۱- سازگار : نباید بین الزامات تضاد وجود داشته باشد. این تضادها می توانند مستقیم یا غیرمستقیم باشند. تضادهای مستقیم در مواقعی اتفاق می افتند که در یک شرایط یکسان، رفتارهای متضادی مورد انتظار باشد.
در چنین مواردی باید شرایط الزامات را تغییر داد و در غیر اینصورت یکی از الزامات را باید تغییر و یا حذف کرد. به عنوان نمونه برای مثال ذکر شده می توان شرایط را تغییر داد و الزام را این چنین بیان کرد که اگر استفاده کننده آمریکایی باشد، الزام ۱ اجرا شود و در صورتی که استفاده کننده فرانسوی باشد، الزام ۲ محقق شود.
تضادهای غیر مستقیم در مواقعی رخ می دهند که الزامات یک کارکرد یکسان را بیان نمی کنند ولی ممکن نیست هر دو در یک زمان محقق شوند.
در چنین مدت زمان محدودی قابلیت طراحی و پیاده سازی چنین سیستمی وجود ندارد.
۱۲- غیر اضافی : هر الزام باید فقط یک بار بیان شود و نباید با سایر الزامات همپوشانی داشته باشد.
۱۳- کامل : یک الزام باید برای کلیه شرایطی که می تواند رخ دهد بیان شود. کلیه الزامات کاربردی باید مشخص شوند. این معیار دشوارترین شرایطی است که باید بررسی شود چرا که در واقع هیچ راهی وجود ندارد تا مطمئن شد که کلیه الزامات در نظر گرفته شده اند و الزامی جا نمانده است.
۱۴- الزام باید در قالب یک نیاز بیان شود و در آن راه حل و روش تحقق الزام وجود نداشته باشد. به عبارت دیگر، در الزام باید چرایی و مقدار بیان شود نه چگونگی تحقق آن.
۱۵- الزام باید با سطح ساختار سلسله مراتبی محصول (درخت محصول) سازگار باشد. به عنوان مثال الزامات دقیق و جزئی که در سطح مجموعه ها و زیرمجموعه ها استفاده می شود نباید برای سطح سیستم نیز بکار برده شود تا باعث ایجاد محدودیت بر روی راه حل های ممکن شود.

گام ششم: تخصیص الزامات

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

گام هفتم: استخراج الزامات تلویحی

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

گام هشتم: اولویت بندی الزامات

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

گام نهم: تصدیق و صحه گذاری الزامات

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

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

مطالب مرتبط

نظر بدهید

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