Якщо ви не знаєте, куди ви йдете, ви потрапите в інше місце. – Йогі Берра
Що ми розглянемо:
- чому важливі вимоги;
- що робить вимоги добрими;
- метод MOSCOW для пріоритизації вимог;
- методи перетворення цілей клієнта на вимоги;
- техніка мозкового штурму;
- методи запису вимог, такі як формальні специфікації, користувацькі історії та прототипи.
Що таке вимога?
Вимоги – це функції, які повинен забезпечувати ваш застосунок. Збирайте вимоги від замовника та використовуйте їх, щоб направляти своїх розробників, зрештою, використовуйте вимоги, щоб перевірити, чи виконана робота.
Розпливчасті вимоги можуть бути корисними, але водночас викликають проблеми.
Добрі вимоги – Чіткі
Добрі вимоги – чіткі, лаконічні та легко зрозумілі. Нормально використовувати жаргон, якщо він зрозумілий і добре визначений. Вимоги не можуть бути розпливчастими або погано визначеними.
Розпливчаста – «Покращити планування прийомів»
Чітка – «Скоротіть початкові вікна прийомів до не більше ніж 2 годин, дотримуючись 90% усіх запланованих прийомів».
Недвозначні
Якщо вимогу можна задовольнити декількома різними способами, то вона має неоднозначність.
Неоднозначна — “Картографічний застосунок, який знаходить найкращий маршрут від точки А до точки Б” (що таке “найкращий” маршрут??)
Недвозначна — ” Картографічний застосунок, який знаходить найкоротший маршрут від точки А до точки Б” (довжина маршруту може бути виміряна фактично, тому це є недвозначна вимога і гарна метрика)
Сумісні
Вимоги не можуть суперечити одна одній.
Розповсюджене вираз у програмному інжинірингу: “Швидко, якісно, дешево. Оберіть два.” Ідея в тому, що ви можете обміняти швидкість розробки, якість розробки та вартість, але не можете перемогти в усіх трьох вимірах. Працюють тільки три можливі комбінації:
➤ Побудувати щось швидко з високою якістю і високою вартістю.
➤ Побудувати щось швидко та недорого, але з низькою якістю.
➤ Побудувати з високою якістю та низькою вартістю, але протягом довгого часу. Намагайтеся підтримувати нові вимоги у відповідності з існуючими вимогами.
Приорітезовані
Виключите всі “непогано мати” вимоги з проекту для того щоб залишитися у графіку.
Часом замовники мають труднощі з визначенням, без яких вимог вони зможуть обійтися. Вони будуть сперечатися, скаржитися та, загалом, вести себе так, ніби ви питаєте, кого з їхніх дітей вони хочуть пожертвувати дінго. Нажаль, якщо вони не зможуть знайти достатньо великий бюджет та графік, їм доведеться зробити певний вибір.
Піддаються перевірці
Вимоги повинні бути такими, що можна протестувати та перевірити, бо як інакше ви дізнаєтесь, що ви відповідаєте вимогам?
Іноді перевірка може бути каверзною, тому ви повинні добре визначити свої тести та процеси вимірювання.
Метод MOSCOW
MOSCOW – це акронім, який допоможе вам запам’ятати загальну систему пріоритизації функцій застосунку. Приголосні у слові MOSCOW позначають наступне:
M – Must (Мусить) – Це обов’язкові функції, які повинні бути включені, інакше проект зазнає невдачі.
S – Should (Слід) – Це важливі функції, які слід включити, якщо це можливо.
C – Could (Можливо) – Це бажані функції, які можна відкинути, якщо вони не вміщаються у графік.
W – Won’t (Не буде) – Це повністю необов’язкові функції, які узгодили замовники, що їх не буде включено до поточного релізу, але вони можуть бути додані в майбутньому релізі, якщо на це є час.
Слова, яких слід уникати
Уникайте двозначних або суб’єктивних прикметників.
Порівняльні слова – це слова, такі як “швидше”, “краще”, “більше”, “блискучіше”. Наскільки швидше? Визначте «краще», наскільки ще? Вони повинні бути кількісно визначені.
Неточні прикметники – слова, такі як “швидкий”, “надійний”, “зручний для користувача”, “ефективний”, “гнучкий” тощо. Вони виглядають чудово в маркетингових матеріалах, але є надто неточними для використання у вимогах.
Неясні команди – слова, такі як “мінімізувати”, “максимізувати”, “покращити” та “оптимізувати”. Якщо ви не використовуєте їх у технічно алгоритмічному сенсі, то це просто модний спосіб сказати “зроби все що можеш”. Потрібно зробити ваші цілі більш конкретними там, де це можливо.
Категорії вимог
Вимоги, орієнтовані на аудиторію
Ці категорії зосереджені на різних аудиторіях, які будуть використовувати вимоги. Ми використовуємо бізнес-орієнтовану перспективу, щоб класифікувати вимоги на основі людей, які найбільше про них піклуються.
Бізнес-вимоги
визначають високо рівневі цілі проекту та те, що сподівається досягти замовник за допомогою проекту. Часом розпливчасті цілі є неминучими в бізнес-вимогах, але якщо це можливо, спробуйте перенести їх у бізнес-кейс. Бізнес-кейс – це скоріше маркетинговий документ, що намагається обґрунтувати проект.
Добре – “написати систему, яка може отримати записи клієнта менше ніж за 3 секунди або знайти найближчий магазин пончиків, який працює о 2 годині ночі”.
Погано – “підвищити мораль в відділі з розгляду скарг клієнтів на 15 відсотків ” (Що б взагалі це могло значити?)
Користувацькі вимоги
вимоги користувача, іноді називаються “вимогами зацікавлених сторін”, описують, як проект буде використовуватися можливими кінцевими користувачами. Часто включають ескізи форм, скрипти, що показують кроки, які виконають користувачі для завершення завдань, сценарії використання та прототипи.
Іноді ці специфікації дуже детально описують, що саме мусить робити застосунок. Іншим часом вони вказують на те, що користувач повинен досягнути, але не обов’язково визначають, як саме це виконає застосунок.
Ви хочете зробити свої вимоги гнучкими але без невизначенності. Якщо ви занадто конкретні, ви можете обмежити розробників, змушуючи брати на себе зобов’язання щодо дизайну, який не обов’язково є оптимальним.
Добре: “Дозволити користувачу вибрати начинку для своєї піци”.
Погано: “Дозволити користувачеві встановлювати прапорець біля того, яку начинку він хоче для своєї піци “.
Дозвольте UX дизайнеру вирішувати, чи є прапорець найкращим варіантом, а не інженеру вимог. Просто опишіть функціонально те, що користувач повинен мати можливість виконати, але не ЯК це робити.
Викладіть потреби проекту без обов’язкового зазначення конкретного підходу.
Функціональні вимоги
Заява бажаних можливостей проекту. Вони подібні до вимог користувача, оскільки вони описують, що повинен робити проект, але не обов’язково ЯК це має бути виконано, проте ці вимоги не обов’язково повинні бути спрямовані на користувача. Вони можуть описувати, наприклад, вимоги для backend серверу, вимоги до API, з якими можуть взаємодіяти розробники тощо.
Технічно, більшість вимог користувача також можуть вважатися функціональними вимогами, оскільки вони описують щось, що буде робити застосунок.
Нефункціональні вимоги
Нефункціональні вимоги не описують, що має РОБИТИ застосунок, але натомість вони є кваліфікаторам результатів додатка.
Погано: “Дозволяє користувачам замовити гоночну дошку, використовуючи онлайн-форму”
Добре: “Додаток повинен підтримувати до 20 користувачів одночасно”
Вимоги впровадження
тимчасові функції, необхідні для переходу до використання нової системи, що будуть виключені пізніше. Вимоги до реалізації не завжди пов’язані з програмуванням, вони можуть включати ручні операцій, такі як, наприклад, введення даних чи завдання, такі як наймання нового персоналу, придбання нового обладнання, підготовка навчальних матеріалів і фактичне навчання користувачів роботі з новою системою.
FURPS
акронім для категорій вимог.
Функціональність (Functionality) – що повинен робити застосунок
Зручність (Usability) – як повинен виглядати і відчуватися застосунок
Надійність (Reliability)- доступність системи (наприклад, час роботи проти простою)
Продуктивність (Performance) – ефективність системи (час обчислення, продуктивність і так далі)
Підтримка (Supportability) – наскільки легко підтримувати застосунок
FURPS +
додає деякі категорії вимог, які були відсутні на думку розробників.
Обмеження дизайну — обмеження на дизайн, які обумовлені такими речами, як ОС, платформа, мережа, база даних тощо. Інструменти, які ви використовуєте, можуть накладати обмеження на ваші проекти.
Вимоги до реалізації – обмеження на саме програмне забезпечення. Наприклад, вам може знадобитися відповідність стандартам CMMI (Capability Maturity Model Integration) або ISO 9000.
Вимоги інтерфейсу – Обмеження на інтерфейси системи з іншими системами.
Фізичні вимоги – обмеження на обладнання та фізичні пристрої, які використовуватиме система. (Повинно бути встановлено на iPad, має працювати в киплячій кислоті тощо).
Оригінальна стаття – Requirements Gathering in Software, переклад – Катерина Стригунівська, ревью – Іван Вільчавський. Оригінальне фото dsl ThisisEngineering RAEng з сайту Unsplash.