بخش اول این متن را ابتدا بخوانید:
مختصری درباره نوشتن نیازمندی‌های محصول
بیاید بقیه بحث را با یک مثال جلو می بریم. فرض کنید می‌خواهیم سیستمی برای یک شرکت خدماتی ایجاد کنیم که کاربران بتوانند صورت حساب‌هایشان را بطور آنلاین ببینند. کار را با این یوزر استوری شروع می کنیم:
به عنوان یک مشتری، میتوانم وارد سیستم شوم و صورت حسابم را مشاهده کنم و بنابراین مجبور نیستم منتظر ایمیل صورت حساب بمانم.
یکسری سوال وجود دارد که باید به آن‌ها پاسخ بدهیم:
داستان‌های فرعی را تکرار می‌کنیم. صورت حساب به‌تنهایی می‌تواند چند بخش شود:
برای بخش ورود ممکن است این‌ها را داشته باشیم:
در این قسمت شاید بهتر باشید یک دیاگرام بکشیم تا بتوانیم دقیق‌تر درباره جزئیات ورود فکر کنیم. این کار برای ما مشخص می‌کند که «ورود» چندان هم ساده نیست و مراحل گوناگوی دارد که هر کدام خودشان یک داستان هستند.
داستان‌های دیگر کم کم آشکار می‌شوند. نام کاربری و رمزعبور فراموش شده، لینک اعتبارسنجی، شماره موبایل، پیامک و... . کشیدن صفحه‌ها و طراحی نمونه اولیه می تواند به ما در این مرحله کمک کند تا داستان‌های بیشتری کشف کنیم.
حالا بیایید جزئیات را به داستان هایمان اضافه کنیم: شرایط رضایت (Conditions of Satisfaction).
شرایط رضایت ملاک هایی هستند باید برای پذیرفتن داستان. شرایط رضایت (COS) داستان را «آزمایش پذیر» می‌کند. این کار باعث می‌شود ابهامات ما کمتر شود.
نوشتن داستان کاربر ممکن است آسان باشد، اما ثبت و ضبط کردن همه شرایط رضایتمندی کار زیادی می طلبد. خب بیایید ببینیم برخی از شرایط رضایت احتمالی داستان زیر چیست؟
به عنوان کاربر جدید با وارد کردن نام کاربری، رمزعبور و ایمیلم میتوانم حساب کاربری برای خود ایجاد کنم.
برخی از شرایط رضایت:
نام کاربری وارد شده باید بین ۴ تا ۲۰ نویسه باشد:
رمز عبور وارد شده باید بین ۴ تا ۲۰ نویسه باشد:
یک ایمیل باید ارائه شود:
و...
مثالهای بیشتری هم میتوانم در این قالب‌ها نوشت:
نوشتن تمام COS ها کار سخت و وقت‌گیری است اما به ما اطمینان می‌دهد آن چیزی که قرار است ساخته شود همان چیزی است که فکر می کردیم.
شرایط رضایت به ما کمک می‌کنند تا منطق و قوانین کسب و کارمان را در پشت داستان‌ها حفظ کنیم اما کلمات که نمی‌توانند UI را توصیف کنند. درباره داستانی که در حال بررسی آن بودیم، از وایرفریم‌ها استفاده می‌کنیم تا:
شاید نیاز باشد برای داستان وایرفریم داشته باشیم.
با تعریف داستان‌های کاربر و COS معمولا نیازمندی‌های غیرعملیاتی فراموش می‌شوند و می‌توانند بعدا آسیب‌زا باشند پس باید مراقب این نوع از نیازمندی‌ها باشیم و آن‌ها را تعریف کنیم.
الزامات غیر عملکردی به الزامات مبتنی بر کیفیت و عملکرد گفته می‌شود. به عنوان مثال ، اگر سیستم نیاز به پشتیبانی از 10،000 کاربر همزمان را داشته باشد ، این نیازی غیر عملیاتی است. مثالهای دیگر:
و...
نیازمندی‌های غیرعملیاتی ممکن است در داستان های خاص اعمال شود یا خود یک داستان باشد.
"نمونه اولیه با جزئیات کم" کلمه کلیدی است که می‌توان به چیز‌هایی نسبت داد که به تجسم یا شبیه سازی عملکرد کمک می کند. می‌تواند یک وایرفریم قابل کلیک باشد که با ابزار نمونه سازی اولیه، اکسل با ماکرو یا حتی یک انیمیشن تعاملی ساخته شده است. فراتر رفتن از کلمات و تصاویر ثابت می تواند در رسیدن به نیازها بسیار مفید باشد.
سطح نهایی جزئیات نیازمندی‌ها نوشتن جدول های تست و اسکریپت‌های تست است. به عبارت دیگر سطح نهایی جزئیات تعریف آزمایشی است که می تواند برای تأیید تأمین شرایط رضایت استفاده شود.
تعریف تست باید بعنوان بخشی از نیازمندی‌ها در نظر گرفته شود، تعیین تست‌ها در هنگام نوشتن نیازمندی‌ها یکی از کارآمدترین روشهای اطمینان از کیفیت مصحول است. این کار بسیار مطمئن تر از این است که کسی پس از توسعه محصول آن را تست و بررسی کند (که احتمالاً خیلی چیزها را از دست خواهد داد) و از همه مهمتر ، کل تیم را درگیر تلاش برای افزایش کیفیت و کاهش خطاها می کند.
این رویکرد گاهی اوقات به عنوان TDD یا توسعه مبتنی بر تست شناخته می شود و شاما best practices های زیادی، از جمله روش های خودکار کردن بسیاری از تست‌ها با استفاده از تست های واحد و یکپارچه سازی مداوم و... است.
در اینجا به چگونگی تعریف تست ها می پردازیم. برای تست‌های ساده ، به یک ساختار جدول از ورودی های احتمالی و خروجی های مورد انتظار فکر می کنیم. بیایید یک جدول تست برای COS زیر ایجاد کنیم:
نام کاربری باید بین ۴ تا ۲۰ نویسه باشد.
برای تست، به یک اسکریپت تست نیاز داریم که یک سری اقدامات با نتایج مورد انتظار است. این به وضوح سناریوهایی را مشخص می کند که باید به توسعه دهندگان ارائه شود:
۱- ثبت نام حساب جدید
۲- با نام کاربری و رمزعبور ایجاد شده با حساب جدید وارد شوید
۳- تأیید کنید که صفحه خوش آمدید در ورود اولیه نشان داده شده است
۴- از سیستم خارج شوید و دوباره وارد شوید
۵- تأیید کنید که صفحه خوش آمدید در ورود به سیستم بعدی نشان داده نمی شود
نوشتن جداول و اسکریپت های تست برای حالت های مختلف از آنچه ممکن است اتفاق بیفتد، مسلماً کار بسی دشوار است. جزئی کردن داستان‌های کاربری می‌تواند در اینجا به ما کمک کند. اما در نهایت، نوشتن نیازهای خوب کار سختی است و هر که هم طاووس خواهد باید جور هندوستان را بکشد. و دلیل اینکه بسیاری ازنیازمندی‌هایی که نوشته می‌شوند از کیفیت خوبی برخودار نیستند این است که تلاش کافی در مرحله نوشتن نیازمندی‌ها انجام نشده و این سختی با ضریب چند برابر در فرایند تست نهایی خود را نشان خواهد داد.
این تست‌ها برای این است که تا اطمینان حاصل شود که آنچه ساخته می شود همان چیزی است که در نظر گرفته شده است و همانطور که در نظر گرفته شده کار می کند.
