Двозначність вимог

У ряді проблем і недоліків вимог двозначність виступає, мабуть, найбільш критичним чинником ризику проекту, що закладається у фазі формування вимог. Двозначність (невідповідність властивості ясності, визначеності) закладає під проект «бомбу уповільненої дії». На практиці вимога, сформульована двозначним чином, може привести до різних його інтерпретацій представниками розробника і замовника. Розробник, керуючись своєю інтерпретацією, визначить на її основі архітектурний базис, створить аналітичні і проектні моделі і зрештою створить програмний код. Як свідчать дослідження, ціна виправлення помилки зростає приблизно на порядок при переході між робочими потоками (від аналізу вимог до проектування, від проектування до реалізації і т. ін.).

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

«Шліфовування» продукту

Під «шліфуванням» розуміють такі ситуації, коли розробники додають функції, яких немає в специфікації, але їм здається, що це сподобається користувачам. Найчастіше ж клієнтам не потрібні такі надмірні можливості, виходить, що час, відведений на реалізацію, витрачається даремно. [1]

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

Інша сторона «шліфування» полягає в тому, що група представників замовника неоднорідна за своєю структурою і може виникнути ситуація, коли представник замовника, що формулює «найдорожчі» вимоги, не має відповідних повноважень. Це – специфіка вітчизняних підприємств, де іноді усе буває влаштовано досить неформально.

Мінімальна специфікація

Створювати повну документацію вимог відповідно до вищевикладених принципів, або обмежитися нарисом вимог на 2-3 сторінки, як це найчастіше відбувається у невеликих проектах, – діло смаку. Проте, для роботи «не за правилами», по-перше, мають бути об'єктивні передумови, по-друге, – мають бути усвідомлені переваги та ризики такого вибору.

Мінімальна специфікація доречна, якщо має місце наявність одночасно трьох обставин:

а) ціна контракту і розміри проекту такі, що розробка розгорнутого ТЗ економічно недоцільна;

б) колектив розробника має достатній рівень професіоналізму і досвіду виконання проектів у суміжних галузях, щоб уміти створювати за стислою специфікацією продукт, який пройде приймання замовником;

в) між замовником і розробником існують конструктивні стосунки і обидві сторони розуміють і приймають ризики міні-специфікації.

Інший варіант роботи за міні-специфікацією: замовник і розробник розуміють, що створення розгорнутої специфікації відтягує закінчення випуску готового продукту, що головна мета проекту - продукт, а не документація і готові до тісної співпраці у процесі його створення. Це шлях так званих agile – методологій розробки ПЗ, детальніше див. [2].

Головний ризик застосування міні-специфікації полягає в тому, що вони базуються на людському чиннику. Гарні і конструктивні стосунки між сторонами повинні зберегтися на протязі всього проекту від початку, інакше у сторін виникнуть істотні проблеми із формальним доказом того, що повинна робити програма, оскільки міні-специфікація для цього недостатньо повна.