3.1 Джерела вимог (Requirement Sources)

Необхідно ідентифікувати всі можливі джерела вимог, значимі для вирішення завдань проекту. Тільки після цього можна визначити їх вплив на проект. Дана тема стосується питань розуміння інформованості джерел вимог і їх значимості.

Дана тема фокусується на:

• Цілях

• Знаннях предметної області

• Зацікавлених особах

• Операційному оточенні

• Організаційному середовищі

Виділення пріоритетів, однозначність вимог, переданих інженерам, зв'язок між вимогами та їх взаємний вплив одна на одну - все це є наслідком чіткого і однозначного розуміння джерел вимог.

3.2 Техніки вилучення вимог (Elicitation Techniques)

Ідентифікувавши джерела вимог ми не повинні "спочивати на лаврах". Навіть володіючи розумінням того, хто володіє необхідною інформацією, ми далеко не застраховані від проблем, пов'язаних з отриманням вимог, необхідних для подальшої роботи. Здійснення своєї професійної діяльності користувачами далеко не гарантує, на жаль, здатність ясно, чітко і однозначно сформулювати те, що вони роблять, і що саме їм необхідно для вирішення їх завдань сьогодні і завтра. Багато в чому, через те, збір вимог, найчастіше, перетворюється в такий важкий і конфліктний процес дійсно-таки вилучення, "витягування" інформації, без якої неможливо переходити до подальших проектних робіт. Непорозуміння між аналітиком і користувачем, недогляд тих чи інших аспектів, що на перший погляд здаються другорядними, неоднозначність або тим більше некоректність інтерпретації інформації, отриманих від користувачів - все це найбільш типові причини "над-витрат" (часу, грошей і т.п.) , а іноді, і повного провалу проектів.

Існує безліч практик і підходів, що дозволяють добитися дійсно стрункої системи вимог, що відповідають реальним потребам і пріоритетам замовників. Серед них можна виділити наступні:

• Інтерв’ювання - традиційний підхід витягання вимог; не варто забувати, що отримання інформації від користувача "не дорівнює" отримання вимог; інформація повинна бути проаналізована і трансформована у вимоги, таким чином, інформація від користувача є "входом" в процеси збору вимог, а самі вимоги - "виходом" цих процесів;

• Сценарії - контекст для збору користувацьких вимог, що визначає відповіді на питання "що якщо" і "як це робиться" щодо бізнес-процесів, що реалізуються користувачами;

• Прототипи - відмінний інструмент для уточнення та/або деталізації вимог; існують різні підходи до прототипування - від "паперових" моделей до пілотних підсистем, що реалізуються як самостійні (в термінах управління ресурсами) проекти або бета-версії продуктів; часто прототипи поступово трансформуються в результати проекту і використовуються для перевірки і затвердження вимог;

• "роз'яснювальні зустрічі" - в оригіналі звучить як "facilitated meetings"; досить ємний за змістом термін, що прийшов із загальної практики менеджменту і базується на ідеях співробітництва зацікавлених осіб для спільного аналізу шляхів вирішення проблем, визначення та попередження ризиків і т.п. На відміну від "звичайного", з дозволу сказати, "мозкового штурму", як виняткової форми обговорення тих чи інших завдань (часто в критичні моменти робіт над проектом), "запланований мозковий штурм" - особлива форма зустрічей учасників проекту та зацікавлених осіб з боку замовника, присвячена обговоренню тих питань, відповіді на які не можуть бути визначені в результаті звичайних інтерв'ю і які вимагають залучення більшої кількості осіб, ніж просто пари "користувач-аналітик"; я дозволили собі сконструювати російською мовою цей термін ще і як "запланований мозкової штурм ", тому що такого роду зустрічі справді зазвичай плануються із заданою періодичністю для забезпечення однозначності інтерпретації інформації, значимої для проекту і, що дуже важливо - проведення таких зустрічей до того, як пов'язані з цими питаннями ризики не перетворилися на реальні проблеми, які потребують вирішення" вчора ", а, отже, і додаткових (спочатку незапланованих) ресурсів часу, грошей і т.д.;

• Спостереження (observation) - має на увазі безпосередню присутність аналітиків та інженерів поруч з користувачем в процесі виконання останнім його робіт із забезпечення функціонування бізнес-процесів: в певній мірі можна провести аналогію з практикою присутності представника замовника у проектній групі виконавця (типова практика в eXtreme Programming " on-site customer "-" присутній замовник "); дана техніка є досить витратною, але, в той же час, дуже ефективною, а іноді - просто незамінною, особливо, якщо мова йде про досить складних і взаємозалежних бізнес-процесах;

Існують і інші, досить ефективні практики, опис яких можна знайти в літературі і які ви, напевно, самі використовуєте у своїй роботі (наприклад, Requirements Workshop, Role Playing, Storyboarding і т.п.). Деякі з них будуть також згадуватися в контексті конкретних методологій.