Специфікація вимог – це документ, в якому міститься набір вимог до програмного продукту. Вимоги структуруються та описують логіку роботи продукту (функціональні вимоги), його зовнішній вигляд (користувацький інтерфейс), обмеження в розробці, а також нефункціональні вимоги. Для опису функціональних вимог часто використовуються користувацькі сценарії (use cases). У користувацьких сценаріях представлені варіанти того, як користувач може взаємодіяти з ПЗ. Нефункціональні вимоги описують обмеження пов'язані з дизайном продукту та його реалізацією (продуктивність продукту, безпека, надійність, сумісність, проєктні обмеження, стандарти якості).
З яких основних розділів складається специфікація вимог? Документ має стандартну структуру, яка може відрізнятися від проєкту до проєкту, але в цілому виглядає наступним чином:
- Introduction
- Overall Description
- Functional requirements
- System Features
- Interface Requirements
- Other Nonfunctional Requirements
- Other Requirements
Із шаблонами специфікацій можна ознайомитися в документах 1, 2.
Незважаючи на те, що наявність документально зафіксованих вимог вже є критерієм якості розробленого продукту, самі вимоги можуть бути описані недостатньо добре. Погано описані вимоги згубно позначаються на розумінні всіх членів команди розробки того, який продукт повинен вийти в результаті. Нечіткі вимоги можуть бути інтерпретовані членами команди по-різному, що спричинить за собою ситуацію, коли одна задача реалізується декількома фахівцями одночасно, абсолютно різними способами та в іншому вигляді. Це, звичайно, призводить до виникнення помилок в продукті, чого б не сталося, якби і самі вимоги були уточнені, протестовані та виправлені.
Як же тестуються вимоги? Щоб зрозуміти, що вимоги описані погано, потрібно звичайно ж в першу чергу розуміти, як повинні виглядати добре описані вимоги. Хороші вимоги визначаються згідно наступних критеріїв якості:
Атомарність
Відповідно до цього критерію, вимоги повинні бути описані так, щоб їх не можна було уточнити ще детальніше або розбити одну вимогу на декілька. Приклад поганої вимоги – користувач може зареєструватися та додати у профіль особисту інформацію. Реєстрація та додавання інформації це дві різні функції, які повинні бути описані і уточнені в різних пунктах специфікації. Приклад хорошої вимоги – користувач може підписатися на оновлення інших користувачів.
Завершеність
Вимоги до одного функціоналу повинні бути описані в одному пункті специфікації. Не можна допускати ситуацію, коли один і той самий функціонал описаний в різних частинах документа.
Послідовність
Вимога не повинна суперечити іншим вимогам та обмеженням системи.
Наприклад: із соціальних мереж повинен запитуватися телефонний номер користувача. Очевидно, що дана вимога суперечить обмеженням соціальних мереж, так як номер телефону є прихованою інформацією, яку соціальні мережі не надають. Користувач повинен сам ввести номер телефону, щоб система його отримала. Подібних протиріч не повинно бути і між пунктами специфікації. Наприклад, одна і та ж кнопка повинна називатися однаково у всьому документі.
Відстеження (Трасування)
Критерій, який дозволяє зрозуміти, чому було прописано саме таку вимогу. Наприклад, для сайту з продажу алкогольних напоїв вимогою може бути реєстрація тільки повнолітніх користувачів у зв'язку із законодавчими обмеженнями.
Актуальність
Критерій, який перевіряє відповідність вимог до сучасних реалій (наприклад, із законодавчого/технічного боку або з боку зручності використання продукту, актуальності його користувацького інтерфейсу). Не варто прописувати у вимогах застарілі браузери, наприклад IE, або застарілі мобільні девайси та їх ОС, тому що вони практично не використовуються.
Здійсненність
Перевірка на те, що вимогу можливо реалізувати за допомогою актуальних існуючих на даний момент технологій. Наприклад, вимога того, що система повинна давати швидкий відгук (тут потрібна конкретизація – не довше, ніж 3 секунди) при помірному навантаженні (тут також потрібна конкретизація за кількістю користувачів та виконуваних ними дій) може існувати. Але вимога відгуку менше секунди при дуже великому навантаженні – нездійсненна в сучасних реаліях вимога.
Зрозумілість (доступність)
Вимога має бути сформульована достатньо чітко, конкретно та однозначно, для того, щоб вона однаково розумілася всією командою розробки.
Верифікованість
Критерій, за яким визначається, чи можна порівняти готовий продукт з вимогою і перевірити, чи виконується вона. Якщо вимога описана дуже розмито, перевірити її не вийде. Наприклад: фото повинно завантажуватися швидко/налаштування профілю повинні бути інтуїтивно-зрозумілими/оформлення замовлення повинно відбуватись легко. Для того, щоб перевірити такі вимоги, явно необхідні уточнення, як це швидко/інтуїтивно-зрозуміло/легко.
Обов'язковість
Визначення того, наскільки важливе та пріоритетне виконання даної вимоги. Всім вимогам в специфікації повинні бути призначені важливість, стабільність та пріоритет. За допомогою цього вибираються першочергові значення для виконання командою розробки завдання.
Ідентифікація
У кожної вимоги повинен бути унікальний ідентифікатор, за допомогою якого вимога прив'язується до інших артефактів проєкту. Наприклад, в описі тест-кейса вказується ідентифікатор вимоги, яка перевіряється цим тест-кейсом.
Модифікація
Вимоги повинні бути легко модифіковані (внесення змін) за необхідності.
Повнота
Найскладніший критерій, згідно з яким вимоги повинні вичерпно описувати весь функціонал системи. Все, що система повинна виконувати, повинно бути зафіксовано у вимогах, інакше можна зробити серйозну помилку під час проєктування архітектури. Складність у тому, що на початкових етапах проєктування системи дуже важко точно вказати та описати всі функції. Вимоги спочатку описуються більш загальними твердженнями, а далі уточнюються.
Як тестуються вимоги?
Тестування вимог – це необхідний етап, що дозволяє поліпшити їх шляхом уточнення, деталізації, а також забезпечити взаєморозуміння між членами команди та уникнути різного трактування. Окрім цього, тестування вимог допоможе зрозуміти, чи можуть вони бути реалізовані загалом (чи достатньо ресурсів, часу, бюджету або можливо це з точки зору технологій).
Існують наступні техніки тестування вимог:
1. Взаємний перегляд. Підрозділяється в свою чергу на:Побіжний перегляд – автор вимог надає документ на швидкий перегляд колегам, які дають свої зауваження, рекомендації, ставлять питання у формі простого неформального обговорення.Технічний перегляд – вимоги надаються автором на перегляд групі фахівців.Формальна інспекція – вимоги проглядаються великою групою фахівців із документуванням всіх зауважень.
2. Ставити запитання. Якщо під час вивчення вимог виникають запитання – всі суперечливі моменти уточнюються у досвідчених колег або замовника.
3. Верифікація вимог. Для можливості перевірки можна спробувати створити чекліст або тест-кейс для конкретної вимоги. Якщо виходить швидко придумати перевірки для чекліста або тест-кейса – це вже непогано.
4. Уявити поведінку реалізованої системи – роботу користувача із системою, створеною за тестованими вимогами. Можливо вийде помітити незрозумілі або неоднозначні моменти в роботі з системою.
Графічна візуалізація та прототипування – зображення інформації у вигляді малюнків, схем, створення прототипу системи (користувацького інтерфейсу) допомагає краще аналізувати інформацію у специфікації, знаходити невідповідності та неточності.
Крім того, що необхідно добре протестувати вимоги та знайти неточності, потрібно правильно сформулювати і залишити зауваження до вимог. На які помилки при складанні зауважень слід звернути увагу і чого слід уникати? Ось декілька порад:
- Не змінювати формат файлу з документацією. Не потрібно видаляти або змінювати вихідний текст, потрібно залишати коментарі до тексту або пропонувати правки. Документ повинен залишатися в форматі, придатному для редагування (TXT/Excel/DOC), формат .pdf або картинки не підійдуть.
- Відзначати в коментарях слід тільки проблемні місця. Вимоги, які сформульовані добре, ніяк відзначати не потрібно. Це лише ускладнює роботу із зауваженнями, оскільки серед усіх коментарів доведеться вибирати ті, які потрібно виправляти.
- Не описувати одне і те ж зауваження в декількох місцях. Тут працює той же критерій якості, що і з самими вимогами. Якщо є необхідність писати одне і те ж зауваження до однієї і тієї ж інформації, краще це зауваження винести в кінець документа та перерахувати список пунктів, до яких воно відноситься. А в самих пунктах робити посилання на зауваження в кінці документа.
- Точно вказувати місце в тексті, до якого відноситься зауваження. Не варто виділяти весь абзац, якщо зауваження стосується до одного речення. У тому ж Word можна виділити потрібну частину тексту та написати коментар саме до неї.
- Якщо необхідно додати уточнююче запитання, його слід формулювати дуже точно та продумано. Наприклад, між запитаннями «Що таке налаштування за замовчуванням?» та «Які налаштування за замовчуванням?» велика різниця. Друге уточнює важливу для специфікації інформацію, а перше – абсолютно безглузде та некомпетентне.
- Не варто писати дуже довгі коментарі, короткий чітко сформульований та структурований текст без орфографічних помилок сприймається набагато легше.
- Не писати зауваження у вигляді критики тексту або його автора, тільки конструктивні коментарі. Категоричні зауваження в стилі «це реалізувати неможливо» також потрібно доводити.
- Не редагувати самостійно вимоги без узгодження. Вносити правки у специфікацію можна тільки після узгодження з відповідальними особами. Інакше може виникнути вкрай серйозна ситуація, коли щось в продукті реалізоване не так, як планувалося, через неузгоджені зміни у вимогах.
Дуже доступно про вимоги та їх тестування написано у книзі Святослава Куликова «Тестування програмного забезпечення. Базовий курс».
Специфікація вимог – важливий документ, який в ідеалі повинен бути описаний для кожного продукту. Добре описані вимоги спрощують роботу всієї команди розробки – програмістам легше зрозуміти, як повинен бути реалізований продукт і як правильно спроєктувати архітектуру, а для тестувальників, крім усього іншого, це ще й джерело очікуваного результату при перевірці. Вміння добре писати та тестувати вимоги – показник компетентності та професіоналізму.
