استفاده مجدد از نیازمندی‌ها (Requirements Reuse)

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

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

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

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

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

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