Незалежно від того, наскільки ретельну роботу ви виконуєте над виявленням вимог, неможливо бути впевненим, що ви знайшли їх усі
Зелене світло не загоряється, щоб оголосити: «Ви закінчили!» Ви завжди повинні допускати появу нових вимог, що надходять протягом усього проекту. Однак надмірна швидкість зміни вимог говорить про те, що важливі вимоги були пропущені при початковому виявленні. Ця стаття, адаптована з книги Вимоги до програмного забезпечення, 3-тє видання, пропонує деякі пропозиції щодо усунення прогалин, спричинених відсутніми, неявними та передбаченими вимогами.
Відсутні вимоги
Відсутні вимоги є поширеним типом дефекту вимоги. Відсутні вимоги важко помітити, тому що вони непомітні! Наступні прийоми допоможуть вам виявити раніше не виявлені вимоги.
- Розкладіть високорівневі вимоги на достатньо детально, щоб точно виявити, що саме запитується. Розпливчаста, високорівнева вимога, яка залишає багато для інтерпретації читача, може призвести до розриву між тим, що має на увазі запитувач, і тим, що будує розробник.
- Переконайтеся, що всі класи користувачів надали вхідні дані. Переконайтеся, що кожна вимога користувача має принаймні один визначений клас користувача, який отримуватиме значення від цієї вимоги.
- Відстежуйте системні вимоги, вимоги користувачів, списки відповідей на події та бізнес-правила з відповідними функціональними вимогами, щоб переконатися, що всі необхідні функції отримано з цих джерел.
- Перевірте граничні значення на наявність відсутніх вимог. Припустимо, що в одній вимозі зазначено: «Якщо ціна замовлення менше 100 доларів США, вартість доставки становить 5,95 доларів США», а в іншій говориться: «Якщо ціна замовлення перевищує 100 доларів США, вартість доставки становить 6 відсотків від загальної ціни замовлення». Але яка вартість доставки замовлення ціною рівно 100 доларів? Він не уточнюється, тому трохи знань вимог не вистачає.
- Представляйте інформацію про вимоги кількома способами. Складно прочитати масу тексту і помітити те, чого немає. Деякі моделі аналізу візуально представляють вимоги на високому рівні абстракції — ліс, а не дерева. Ви можете вивчити таку модель і зрозуміти, що повинна бути стрілка від однієї клітинки до іншої, яка не показана; Ця пропущена стрілка означає відсутню вимогу.
- Набори вимог зі складною булевою логікою (AND, OR і NOT) часто є неповними. Якщо комбінація логічних умов не має відповідної функціональної вимоги, розробник повинен вивести, що повинна робити система, або шукати відповідь. Умови «інакше» часто не беруться до уваги. Представляйте складну логіку, використовуючи таблиці рішень або дерева рішень, щоб охопити всі можливі ситуації. Вони також дуже корисні для тест-дизайну.
- Створіть контрольний список загальних функціональних областей, які слід враховувати для своїх проектів. Приклади включають журналювання помилок, резервне копіювання та відновлення, безпеку доступу, звітування, друк, можливості попереднього перегляду та налаштування параметрів користувача. Періодично порівнюйте цей список з уже вказаними функціями для пошуку прогалин.
- Модель даних може виявити відсутні функції. Усі сутності даних, якими буде маніпулювати система, повинні мати відповідний функціонал для їх створення, зчитування із зовнішнього джерела, оновлення поточних значень та/або видалення. Абревіатура CRUD часто використовується для позначення цих чотирьох загальних операцій. Переконайтеся, що ви можете визначити функціональність вашої програми для виконання цих операцій на всіх ваших об’єктах, які їх потребують.
Остерігайтеся пастки паралічу аналізу, витрачаючи занадто багато часу на виявлення в спробі не пропустити будь-які вимоги в класичній патології водоспаду. На певному етапі вам потрібно встановити відносно стабільний базовий рівень вимог, який описує, що ви будете реалізовувати в наступному випуску або ітерації. Але ви повинні розраховувати на виконання додаткових вимог протягом усього проекту, незалежно від того, яким життєвим циклом розвитку рухається проект.
Передбачені та неявні вимоги
Одного разу я зіткнувся з командою розробників, яка впроваджувала контент-портал, призначений для багатьох речей, включаючи завантаження, редагування та публікацію контенту на веб-сайті. Існувало близько 1000 одиниць існуючого контенту, організованих в ієрархію. Команда з управління контентом припускала, що користувачі зможуть переміщатися по ієрархії, щоб швидко знаходити певну частину контенту для редагування. Вони не конкретизували вимоги щодо навігації інтерфейсу користувача.
Однак, коли розробники впровадили користувальницький інтерфейс для навігації по вмісту, вони організували весь контент на одному рівні, а не ієрархічно, і показували лише 20 елементів на екрані. Щоб знайти певний контент, користувачеві, можливо, доведеться переміщатися по 50 екранах. Трохи більше конкретизації та діалогу між розробниками та командою управління контентом могли б уникнути значних переробок.
Ви ніколи не задокументуєте 100 відсотків вимог до програмної системи. Але вимоги, які ви не вказуєте, створюють ризик того, що проєкт може запропонувати рішення, відмінне від того, що очікують зацікавлені сторони. Двома ймовірними винуватцями невиправданих очікувань є передбачувані та неявні вимоги.
Передбачувані вимоги – це ті, які люди очікують, не висловивши їх явно. Те, що ви вважаєте очевидним, може відрізнятися від припущень, які роблять різні розробники. Маються на увазі вимоги необхідні через іншу вимогу, але прямо не вказані. Розробники не можуть реалізувати функціонал, про який вони не знають. Як передбачувані, так і неявні вимоги спираються на певну частку телепатії та ясновидіння, які не є сильною технічною основою для програмного проекту.
Щоб зменшити ці ризики, спробуйте виявити прогалини в знаннях, які чекають, щоб їх заповнили неявними та передбачуваними вимогами. Запитайте: «Що ми припускаємо?» під час сеансів виявлення, щоб спробувати вивести на поверхню ці приховані думки. Якщо ви зіткнулися з припущенням під час обговорення вимог, запишіть його та підтвердіть його обґрунтованість. Люди часто вважають, що все має бути так, як було завжди, тому що вони добре знайомі з існуючою системою або бізнес-процесом. Якщо ви розробляєте систему заміни, перегляньте функції попередньої системи, щоб визначити, чи дійсно вони потрібні для заміни.
Щоб виявити неявні вимоги, вивчіть результати первинних сеансів виявлення, щоб виявити області неповноти. Чи потрібно конкретизувати більш детальну вимогу високого рівня, щоб усі зацікавлені сторони її розуміли? Чи вимога, яка може бути частиною логічного набору (скажімо, збереження неповної веб-форми), не має свого відповідника (отримання збереженої форми для подальшої роботи)? Можливо, вам доведеться повторно провести співбесіду з деякими з тих самих зацікавлених сторін, щоб вони виявили відсутні вимоги. Крім того, подумайте про нових зацікавлених сторін, які знають тему та можуть помітити прогалини.
Читайте між рядків, щоб визначити функції або характеристики, які клієнти очікують включити, не сказавши цього. Ставте запитання без контексту, запитання високого рівня та відкриті, які отримують інформацію про глобальні характеристики як бізнес-проблеми, так і потенційного рішення. Відповідь клієнта на такі запитання, як «Яка точність потрібна в продукті?» або «Чи можете ви допомогти мені зрозуміти, чому ви не згодні з відповіддю Мігеля?» може призвести до висновків, яких немає в запитаннях зі стандартними відповідями «так/ні» або «A/B/C».
Ми всі знаємо, що ви не знайдете та не задокументуєте кожну вимогу до програмної системи будь-якого розміру. Однак, якщо ви будете тримати очі відкритими для відсутніх, передбачуваних і неявних вимог, ви закриєте багато прогалин, які в іншому випадку могли б спричинити головний біль у розробці — і витрати на проєкт — у майбутньому.
Оригінальна стаття – Revealing Invisible Requirements, переклад – Іван Вільчавський. Оригінальне зображення зі статті автора.