مختصری دربارهٔ نوشتن نیازمندی‌های محصول

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

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

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

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

اصل اساسی نیازمندی‌های نرم افزار

بیاید با یک اصل بنیادی برای پروژه‌های نرم افزاری پیچیده شروع کنیم که اغلب قدرش دانسته نمیشه:

نیازمندی‌ها کم کم آشکار می‌شوند.

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

البته بهتر است همه چیز را با جزئیات طراحی کنید و سپس بسادگی از روی برنامه اجرا کنید که همان رویکرد Waterfall «آبشاری» است. رویکرد آبشاری برای پروژه‌هایی که پیش‌بینی پذیر هستند یا از یک فرمول تکرارپذیر پیروی می کنند خوب کار می‌کند مثلا طراحی یک فروشگاه معمولی یا سایت معرفی خدمات یک شرکت اما برای پروژه هایی که نتیجه نهایی نامشخص است این رویکرد مناسب نیست.

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

هنگامی که جزئیات را به نیازمندی‌های اضافه می کنیم نیازداریم تا آن ها را قالب‌های مختلف ثبت کنیم:

• داستان‌های کلی (high level stories - epics) برای ثبت مفهوم و ارزش کسب و کار.
• داستان های جزیی (low level stories - backlogs) برای ثبت ویژگی‌های منحصر بفرد و تقسیم نشدنی.
• نمودارها برای ترسیم جریان کار و منطق کسب و کار.
• وایرفریم و طرح های تصویری برای رابط کاربری، نگاه و احساس.
• اکسل و فرمول‌ها که ورودی های احتمالی و خروجی های مورد انتظار را تعریف می کنند.
• پروتوتایپ با جزئیات کم (low-fidelity prototypes) برای بازخورد گرفتن و ایجاد تنظیمات.

مختصری درباره داستان های کاربر

داستان های کاربر (User Stories) چهارچوب مناسبی را برای بازتعریف نیازها از مفهومی سطح بالا و کلی به ریز جزئیات فراهم می‌کند. داستان‌های کاربر نقطه شروع دیگر قالب‌ها هستند و برای بیان ارزش پیشنهادی کسب‌وکار، برنامه‌ریزی و تخمین دقیق مفید هستند.

رایج ترین الگو نوشتن داستان کاربر، الگویی است که مک کوهن آن را باب کرد:

من به عنوان < نوع کاربر >، می‌خواهم < هدف > تا < دلیل >.

به بیان دیگر، ما با جمله بالا به این سوالات پاسخ می دهیم:

چه کسی (who): ما برای چه کسی این کار را می کنیم.

چه چیزی (what): چیکار داریم می‌کنیم؟

چرا (why): چرا داریم این کار را می‌کنیم؟

این الگو ساده و قابل فهم است و ارزش کسب و کار را نشان میدهد و به معنی راه حل یا پیاده سازی خاصی نیست. این مهم است به این دلیل که نیازهای سطح بالا باید مسئله را تعریف کند و نه راه حل را. داستان های کاربر برنامه ریزی و درک پروژه را در گفتگو با اعضای - فنی و غیرفنی - تیم را تسهیل می کند.

مفید است که به داستانهای کاربر در دو سطح فکر کنیم. اپیک ها و بک لاگ ها، که رابطه پدر و فرزندی با یکدیگر دارند. می توانیم چند مرحله برای ترسیم داستان ها در نظر بگیریم.

مرحله اول این است که نیازمندی‌ها را بازگو کنیم. برای مثال، تعریف اپیک ها محدوده کلی شرایط اپلیکیشن را مشخص می‌کند. این مقدار از جزئیات برای برنامه ریزی انتشار و برآورد میزان تلاش کافی است.
مرحله دوم تعریف بک لاگ هاو (sub-stories) است که هر اپیک از آن‌ها تشکیل شده است. این زیرداستان‌ها هر کدام یک ویژگی (feature) یا جز (component) از برنامه هستند و ذیل یک اپیک قرار می‌گیرند. بخش «why» در این زیرداستان‌ها ضروری نیست اما مشخص کردن «what» و «how» مهم است. این سطح از جزئیات برای برنامه ریزی‌ دقیق‌تر و تخمین زدن مقدار منابع و تعیین زمان تقریبی (در حد روز و هفته) کافی است. مراحل بعدی برای اضافه کردن جزئیات بیشتر به زیرداستان‌هاست. جزئیاتی مثل شرایط رضایت(Conditions of Satisfaction)، وایرفریم‌ها، جدول‌های تست و موارد دیگر. این سطح از جزئیات تخمین ها را در چند ساعت امکان پذیر می کند.

مختصری درباره نوع کاربر (user type)

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

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

- کاربر جدید
- کاربر ثبت نام شده
- کاربر VIP
- کاربر غیرفعال شده
- کاربر مجدد
- مدیر
- کاربر با یک حساب کاربری واحد
- کاربر با چندین حساب
- و...

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

در بخش بعدی با مثالی عملی دیگر بخش های یک نیازمندی را بررسی می کنیم.