اولین قدم در تعریف یک محصول، خدمت، فرآیند یا سیستم جدید، تعریف الزامات است، یعنی الزامات عملکردی یا غیرعملکردی خاص.
- الزامات عملکردیتوضیح می‌دهد که چگونه محصول یا خدمت نیازهای مشتری را برآورده می‌کند. این شامل ویژگی‌ها و عملکردها در موارد استفاده است که نحوه تعامل کاربران با محصول یا خدمت را مستند می‌کند.
- الزامات غیرعملکردیویژگی‌های عملیاتی و محصول هستند که گاهی برای کاربر واضح نیستند، از جمله عملکرد، قابلیت استفاده، دوام، امنیت و مالی (قیمت و هزینه).
این تصویر را ویرایش کنید – الزامات عملکردی در مقابل الزامات غیرعملکردی
الزامات عملکردی را می‌توان به عنوان آنچه که محصول باید برای مشتری انجام دهد در نظر گرفت، در حالی که الزامات غیرعملکردی را می‌توان به عنوان محدودیت‌هایی در نظر گرفت که محصول یا خدمت باید برای برآورده کردن آن طراحی شود.
الزامات عملکردی رفتار مورد نظر سیستم را ضبط می‌کنند. این رفتار ممکن است به عنوان خدمات، وظایف یا عملکردهایی که سیستم باید انجام دهد بیان شود. در صنعت توسعه نرم‌افزار، رویکرد مورد استفاده به سرعت به یک عمل رایج برای ضبط الزامات عملکردی تبدیل شده است. این موضوع به ویژه در جامعه شیءگرا و UML که در آنجا به وجود آمده‌اند، صادق است، اما قابلیت کاربرد آنها محدود به سیستم‌های شیءگرا نیست.
چه تکنیک‌هایی برای ضبط الزامات عملکردی وجود دارد؟
الزامات عملکردی معمولاً به صورت موارد استفاده یا سناریوهای کاربر ضبط می‌شوند. این اصطلاحات گاهی به صورت متناوب استفاده می‌شوند، اما در واقع به معنای کمی متفاوت هستند.
- موارد استفاده بیشتر بر روی سیستم و آنچه که باید انجام دهد تا نیازهای کاربران را برآورده کند، تمرکز دارند.
- داستان‌های کاربراز طرف دیگر، عملکرد محصول را از دیدگاه کاربر نشان می‌دهند و نقش‌های کاربر و اهداف خاصی که می‌خواهند به آن برسند را مشخص می‌کنند.
ضبط الزامات عملکردی با استفاده از داستان‌های کاربر
داستان‌های کاربر یک روش سبک برای ضبط سریع «چه کسی»، «چه چیزی» و «چرا» الزامات یک محصول هستند. به سادگی، داستان‌های کاربر ایده‌هایی هستند که نیازهایی را که کاربران می‌خواهند بیان می‌کنند. داستان‌های کاربر کوتاه هستند و هر عنصر معمولاً کمتر از 10 یا 15 کلمه دارد. داستان‌های کاربر لیست‌های «باید انجام شود» هستند که به شما کمک می‌کنند مراحل را در مسیر پروژه شناسایی کنید. آنها کمک می‌کنند تا اطمینان حاصل شود که فرآیند شما و محصول حاصل، الزامات شما را برآورده می‌کند.
الگوی داستان کاربر
داستان‌های کاربر فقط عناصر اساسی یک الزام را ضبط می‌کنند:
- این برای چه کسی است؟
- چه انتظاری از سیستم دارد؟
- چرا این مهم است (اختیاری؟)
در اینجا یک فرمت ساده از داستان کاربر است که توسط 70٪ از متخصصان استفاده می‌شود:
نقش – کاربر باید یک انسان واقعی باشد که با سیستم تعامل دارد.
- تا حد ممکن خاص باشید
- تیم توسعه کاربر نیست
عمل – رفتار سیستم باید به عنوان یک عمل نوشته شود.
- معمولاً برای هر داستان کاربر منحصر به فرد است
- «سیستم» ضمنی است و در داستان نوشته نمی‌شود
- صدای فعال، نه صدای منفعل («می‌توانم مطلع شوم»)
مزایا – مزیت باید یک نتیجه واقعی باشد که غیرعملکردی یا خارجی به سیستم است.
- بسیاری از داستان‌ها ممکن است بیانیه مزیت یکسانی داشته باشند.
- مزیت ممکن است برای سایر کاربران یا مشتریان باشد، نه فقط برای کاربر در داستان.
چگونه الزامات عملکردی را با استفاده از مورد استفاده شناسایی کنیم؟
برای درک کامل الزامات عملکردی سیستم، باید بدانید که سیستم برای چه کسی است، یعنی چه کسی از سیستم استفاده خواهد کرد؟
پاسخ به این سوال این است: بازیگر در تحلیل مورد استفاده
موارد استفادهیا داستان‌های کاربر الزامات عملکردی را ضبط می‌کنند که رفتار ممکن است به عنوان خدمات، وظایف یا عملکردهایی که سیستم باید انجام دهد بیان شود. موارد استفاده تعامل بین کاربر و خدمات سیستم را تعریف می‌کنند که می‌تواند به تعریف الزامات عملکردی سیستم در حال توسعه کمک کند. یا به عبارت دیگر، آنچه که محصول یا خدمت باید انجام دهد تا نیازها و خواسته‌های مشتری را برآورده کند.
یک مورد استفاده با یک «بازیگر» یا «چه کسی» شروع می‌شود، یک کاربر خاص از محصول یا خدمت.
یک بازیگرشخص یا یک سیستم خارجی است که نقشی در تعامل با سیستم ایفا می‌کند. نمونه‌های بازیگران می‌توانند افراد یا سیستم‌های خارجی باشند؛ با این حال، هر بازیگر یک دیدگاه منحصر به فرد و مهم از سیستم ارائه می‌دهد، دیدگاهی که برای هر نمونه (شخص واقعی / کاربر) از بازیگر مشترک است.
کاربر واقعی در مقابل بازیگر مورد استفاده
برای درک کامل هدف سیستم، باید بدانید که سیستم برای چه کسی است، یعنی چه کسی از آن استفاده خواهد کرد. انواع مختلف کاربران به عنوان بازیگر (نقش‌ها) نمایندگی می‌شوند.
تفاوت بین یک نقش و یک کاربر فردی این است که یک نقش نماینده یک کلاس خاص از کاربران است، نه یک کاربر واقعی. کاربران مختلف می‌توانند همان نقش را ایفا کنند، در این صورت هر کاربر یک نمونه از یک بازیگر را تشکیل می‌دهد.
این تمایز بین بازیگران و نمونه‌های بازیگران در موارد زیر نشان داده شده است:
شکل زیر موردی را نشان می‌دهد که ماری و جان مشتریان یک دستگاه فروش خودکار هستند. وقتی آنها از دستگاه فروش خودکار استفاده می‌کنند، هر یک به عنوان یک نمونه از یک بازیگر به نام مشتری نمایندگی می‌شود که انتظار دارد به برخی از عملکردهای سیستم (در این مورد چاپ خرید غذا) دسترسی داشته باشد.
این تصویر دستگاه فروش خودکار را ویرایش کنید
برعکس، یک کاربر می‌تواند چندین نقش را ایفا کند (یعنی یک شخص می‌تواند نقش‌های مختلفی را ایفا کند).
به عنوان مثال، دکتر گیتس که عضو کمیته جامعه کامپیوتر است. او مسئول مدیریت سیستم مدیریت عضویت، مانند افزودن و حذف حساب‌های کاربری است. وقتی او این کار را انجام می‌دهد، نقش مدیر (بازیگر) را ایفا می‌کند. با این حال، همان دکتر گیتس ممکن است همچنین عضو جامعه کامپیوتر باشد. در این صورت، او همچنین نقش «عضو» (بازیگر) را ایفا می‌کند.
چگونه الزامات عملکردی را با شناسایی موارد استفاده سیستم به دست آوریم
یک مورد استفاده می‌تواند با پرسیدن انواع سوالات زیر از ذینفعان شناسایی شود (که آنها باید از دیدگاه بازیگران به آن پاسخ دهند):
- کاربران در این نقش چه چیزی را سعی دارند به دست آورند؟
- برای انجام این نقش، کاربران به چه چیزهایی نیاز دارند که بتوانند انجام دهند؟
- وظایف اصلی کاربران در این نقش چیست؟
- کاربران در این نقش به چه اطلاعاتی نیاز دارند که بررسی، ایجاد یا تغییر دهند؟
- کاربران در این نقش به چه اطلاعاتی باید از سیستم مطلع شوند؟
- کاربران در این نقش باید به سیستم چه اطلاعاتی را اطلاع دهند؟
توجه داشته باشید که:
موارد استفاده اغلب به عنوان وسیله‌ای برای کشف و نمایندگی الزامات عملکردی و سیستم استفاده می‌شوند، زیرا یک مورد استفاده تعاملات و وظایف لازم برای اجرای یک هدف تجاری خاص را تعریف می‌کند. با این حال، آنها معمولاً راه خوبی برای تعریف الزامات غیرعملکردی، مانند عملکرد و کیفیت سیستم نیستند.
منابع
- داستان کاربر در مقابل مورد استفاده برای توسعه نرم‌افزار چابک
- داستان کاربر چیست؟
- نقشه‌برداری داستان کاربر چیست؟
- شناسایی الزامات کاربر با نمودارهای مورد استفاده
- چگونه از وایرفریم‌ها با داستان‌های کاربر استفاده کنیم؟
- رویکرد مبتنی بر مورد استفاده برای توسعه چابک
- مشخصات مورد استفاده چیست؟
This post is also available in Deutsch, English, Español, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文.