Author: adminknowledgeserf

Збір вимог до програмного забезпечення (software requirements elicitation) —один із найважливіших етапів у розробці програмного забезпечення, під час якого аналітики, розробники або продакт-менеджери виявляють, формулюють і документують функціональні й нефункціональні потреби зацікавлених сторін (стейкхолдерів).

Помилки на цьому етапі призводять до:

• невідповідності продукту очікуванням клієнта
• перевитрат бюджету
• затримок у розробці
• переробок і конфліктів

Основні методи збору вимог

1. Інтерв’ю (Interviews)

Суть: Один з найпоширеніших методів — бесіда з окремими користувачами чи стейкхолдерами для виявлення їхніх очікувань, проблем, потреб.

Типи:

• Структуроване — з чітким планом і питаннями.
• Неструктуроване — у вільній формі.
• Напівструктуроване — поєднання двох підходів.

Приклад: Інтерв’ю з бухгалтером, щоб дізнатися, які звіти йому потрібні в ERP-системі.

Переваги:

• Дозволяє глибоко розуміти контекст.
• Можна задавати уточнюючі питання.

Недоліки:

• Вимагає часу.
• Результати залежать від досвіду аналітика та щирості користувача.

Коли використовувати: На ранніх етапах проєкту для виявлення ключових потреб.

2. Опитування (Surveys, Questionnaires)

Суть: Розсилка форм із запитаннями для великої кількості користувачів, щоб зібрати статистику, думки чи побажання.

Типові формати:

• Закриті питання (із варіантами відповідей)
• Відкриті питання

Приклад: Опитування працівників компанії про бажаний функціонал у новій системі відстеження робочого часу.

Переваги:

• Ефективно при великій кількості респондентів.
• Дані легко агрегуються.

Недоліки:

• Мало глибини.
• Може бути низька якість відповідей.

Коли використовувати: Коли треба зібрати узагальнені думки від широкої аудиторії.

3. Фокус-групи (Focus Groups)

Суть: Організація дискусії з 5–10 учасниками, які представляють типових користувачів. Обговорюють функціональність, очікування, можливі проблеми.

Приклад: Фокус-група лікарів для обговорення майбутньої медичної інформаційної системи.

Переваги:

• Генерація ідей у динаміці.
• Виявлення різних точок зору.

Недоліки:

• Домінування окремих учасників.
• Важко модераувати.

Коли використовувати: У B2C або B2B проєктах, де важливі думки кінцевих користувачів.

4. Спостереження (Observation / Job Shadowing)

Суть: Аналітик спостерігає за тим, як користувач виконує свої завдання в реальному робочому середовищі. Іноді — взаємодіє з ним (active observation).

Варіанти:

• Пасивне — без втручання.
• Активне — з питаннями, уточненнями, взаємодією.

Приклад: Спостереження за працівником складу, який обробляє замовлення, щоб виявити вимоги до нової WMS (Warehouse Management System).

Переваги:

• Виявлення прихованих, неочевидних вимог.
• Розуміння реального процесу.

Недоліки:

• Вимагає часу.
• Поведінка користувача може змінюватися під спостереженням.

Коли використовувати: У складних процесах, де користувач сам не може чітко описати свої дії.

5. Прототипування (Prototyping)

Суть: Створення початкової (навіть дуже спрощеної) версії продукту чи інтерфейсу для збору зворотного зв’язку.

Види прототипів:

• Low-fidelity (паперові макети, wireframes)
• High-fidelity (інтерактивні UI-моделі)

Приклад: Макет мобільного застосунку для керування доставкою, створений у Figma.

Переваги:

• Краще розуміння потреб користувачів.
• Зниження ризику непорозумінь.

Недоліки:

• Займає час на розробку прототипу.
• Користувачі можуть подумати, що система вже готова.

Коли використовувати: Для візуалізації складних інтерфейсів або перевірки гіпотез.

6. Workshops (Робочі сесії, воркшопи)

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

Формати:

• Семінари з фасилітатором
• Картування процесів (process mapping)
• User journey mapping

Приклад: Воркшоп із відділами HR і IT для проєктування системи управління персоналом.

Переваги:

• Швидка генерація вимог.
• Узгодження між сторонами.

Недоліки:

• Складність організації.
• Потреба в досвідченому модераторі.

Коли використовувати: Коли потрібно зібрати думки кількох груп одночасно.

7. Аналіз документів (Document Analysis)

Суть: Вивчення наявних специфікацій, технічних документів, процесів, політик, звітів тощо.

Приклад: Аналіз документації старої CRM-системи перед створенням нової.

Переваги:

• Допомагає зрозуміти поточні процеси.
• База для порівняння “як є” vs “як має бути”.

Недоліки:

• Документи можуть бути застарілими або неповними.

Коли використовувати: На старті, особливо при заміні чи інтеграції з існуючими системами.

8. Use Cases / User Stories / Scenarios

Суть: Опис конкретних дій користувача з системою, щоб зрозуміти функціональні вимоги.

Формати:

• Use Case (формальний опис з умовами, діями)
• User Story (наприклад: “Як менеджер, я хочу бачити звіт про продажі, щоб аналізувати продуктивність”)
• Сценарії (step-by-step interaction)

Переваги:

• Фокус на поведінці системи.
• Дає контекст.

Недоліки:

• Потребує досвідчених аналітиків.

Коли використовувати: У системах із великою кількістю ролей та дій.

9. Мозковий штурм (Brainstorming)

Суть: Колективне генерування ідей без критики з метою зібрати максимум варіантів.

Приклад: Сесія з маркетологами для ідей майбутнього мобільного застосунку для клієнтів.

Переваги:

• Висока креативність.
• Може дати нестандартні рішення.

Недоліки:

• Не завжди структуровані результати.
• Не кожна ідея практична.

Коли використовувати: На ранніх етапах, коли ще немає чіткого бачення продукту.

10. Рев’ю існуючих систем (Interface Analysis / Benchmarking)

Суть: Аналіз зовнішніх або внутрішніх систем, щоб зрозуміти, як вони працюють, і що можна поліпшити.

Приклад: Вивчення функціональності конкурентного мобільного банкінгу.

Переваги:

• Можна запозичити вдалі рішення.
• Виявлення недоліків у поточному продукті.

Недоліки:

• Ризик копіювання без глибокого розуміння.
• Може обмежити креативність.

Коли використовувати: Для редизайну систем або створення MVP.

Як обрати метод?

Умова	Рекомендовані методи
Велика кількість користувачів	Опитування, Фокус-групи
Складні/технічні процеси	Спостереження, Аналіз документів
Новий продукт	Мозковий штурм, Прототипування
Ітеративна розробка	User Stories, Воркшопи
Багато зацікавлених сторін	Інтерв’ю, Workshops

Software Requirements (Вимоги до ПЗ) — це структурований опис функцій, характеристик та обмежень, які повинна мати програмна система, щоб відповідати очікуванням замовника, користувачів та інших зацікавлених сторін.

Іншими словами — це відповіді на запитання:

• Що має робити програма?
• Як вона повинна працювати?
• Для кого вона створюється і в яких умовах буде працювати?

Основні цілі вимог

1. Зрозуміти потреби користувача
   • Визначити, які проблеми треба вирішити
   • Які задачі автоматизувати або спростити
2. Служити основою для розробки
   • Вимоги — це вихідна точка для розробників, дизайнерів, тестувальників і менеджерів
3. Зменшити ризики непорозумінь
   • Узгоджений документ із вимогами запобігає суперечкам і повторній розробці
4. Забезпечити можливість тестування
   • Вимоги повинні бути перевірюваними: по ним створюються тест-кейси

Класифікація вимог

1. Функціональні вимоги (Functional Requirements)

Це вимоги, які описують конкретну поведінку або функціональність системи.

Вони відповідають на питання: “Що повинна робити система?”

Приклади:

• Користувач повинен мати змогу зареєструватися, використовуючи email і пароль.
• Система має надсилати лист підтвердження після реєстрації.
• Адміністратор може видалити обліковий запис користувача.

2. Нефункціональні вимоги (Non-Functional Requirements)

Ці вимоги описують якість системи, як вона виконує свої функції.

Вони відповідають на питання: “ЯК повинна працювати система?”

Приклади:

• Система повинна обробляти не менше 500 запитів на секунду.
• Інтерфейс має бути доступним для людей із вадами зору (відповідність WCAG).
• Додаток має працювати офлайн.

Сюди входять:

• Продуктивність
• Безпека
• Масштабованість
• Надійність
• Зручність інтерфейсу (usability)
• Сумісність із платформами (Windows, iOS, Android тощо)

3. Бізнес-вимоги (Business Requirements)

Це високорівневі цілі проєкту або продукту з погляду бізнесу.

Приклади:

• Надати клієнтам можливість купувати квитки онлайн.
• Оптимізувати витрати на обробку заявок на 20% протягом півроку.
• Зменшити кількість дзвінків до служби підтримки.

4. Системні вимоги (System Requirements)

Це вимоги до технічного середовища, в якому працюватиме система.

Приклади:

• Підтримка ОС: Windows 11, Ubuntu 22.04.
• Робота на сервері з мінімум 8 GB RAM та 4 CPU.
• Підключення до бази даних PostgreSQL.

Як формуються вимоги?

1. Збір вимог (Requirements Elicitation)

Це процес збору інформації про те, що потрібно системі. Залучаються:

• Замовники
• Кінцеві користувачі
• Бізнес-аналітики
• Архітектори / розробники

Методи:

• Інтерв’ю
• Опитування
• Аналіз існуючої системи
• Спостереження
• Воркшопи
• Аналіз конкурентів

2. Аналіз і документування

Вимоги формулюються в структурованому вигляді:

• У вигляді документа SRS (Software Requirements Specification)
• У вигляді User Stories (у Agile-проєктах)
• У вигляді Use Case діаграм або UML-діаграм

3. Перевірка та валідація

Потрібно переконатися, що:

• Вимоги точно описують те, що потрібно
• Вони не суперечать одна одній
• Вони реалістичні (можна реалізувати з доступними ресурсами)
• Вони такі, що можуть бути перевірені (можна протестувати результат)

Хто бере участь у роботі з вимогами?

Роль	Що робить
Бізнес-аналітик	Збирає та формулює вимоги
Product Owner	Визначає пріоритети функцій (у Scrum)
Розробник	Оцінює складність реалізації
Тестувальник (QA)	Готує тест-кейси на основі вимог
Архітектор	Визначає, як технічно реалізувати вимоги

Як виглядає документ з вимогами (SRS)?

Типовий зміст:

1. Вступ
2. Опис системи
3. Функціональні вимоги
4. Нефункціональні вимоги
5. Інтерфейси користувача
6. Обмеження
7. Глосарій термінів

Якими мають бути хороші вимоги?

Вимоги повинні бути:

• Чіткими — без двозначностей
• Повними — охоплювати всі сценарії
• Такими, що можна перевірити — можна протестувати
• Послідовними — не суперечити одна одній
• Зрозумілими — написаними зрозумілою мовою

Приклад вимоги:

User Story (Agile формат):

Як користувач, я хочу мати змогу змінити свій пароль, щоб забезпечити безпеку свого акаунта.

Acceptance Criteria:

• Користувач може змінити пароль зі сторінки профілю
• Стара комбінація логін-пароль має бути підтверджена
• Новий пароль має містити щонайменше 8 символів
• Після зміни пароля автоматично виконується вихід з усіх пристроїв

Висновок

Вимоги до ПЗ — це основа всієї розробки. Від того, наскільки правильно та повно вони сформульовані, залежить:

• чи отримає замовник те, що очікує;
• чи зможе команда реалізувати продукт у строки;
• чи буде система зручною, ефективною та безпечною.

Чіткі вимоги = менше багів, менше переробок, більше задоволених користувачів.

Data Flow Testing — це тип білого (white-box) тестування програмного забезпечення, який фокусується на відстеженні потоку даних у програмі для виявлення потенційних помилок, пов’язаних із використанням змінних.

Основна ідея:

В Data Flow Testing аналізується, як змінні оголошуються, ініціалізуються, використовуються та знищуються в програмному коді. Головна мета — виявити логічні помилки, які можуть виникнути через неправильне використання змінних.

Основні поняття:

• Def (Definition) — місце, де змінна отримує значення (наприклад, через присвоєння або введення).
• Use (Usage) — місце, де змінна використовується (наприклад, у виразах, умовах тощо).
• Kill (Undefined) — момент, коли змінна перестає бути дійсною (наприклад, вихід за межі області видимості).

Приклади помилок, які може виявити Data Flow Testing:

• Використання змінної до її ініціалізації.
• Непотрібне або ніколи не використане присвоєння (мертві змінні).
• Множинне присвоєння без проміжного використання.
• Невикористані значення, що зберігаються в змінних.

Як працює:

1. Код представляється у вигляді Control Flow Graph (CFG) — граф, де вузли — це інструкції або блоки коду, а ребра — переходи.
2. Для кожної змінної визначаються точки:
   • де вона оголошується/отримує значення (Def);
   • де вона використовується (Use).
3. Створюються шляхи Def-Use: від точки присвоєння до точки використання без повторного присвоєння.
4. Тест-кейси створюються для покриття всіх таких шляхів.

Переваги:

• Виявляє логічні помилки на ранньому етапі.
• Дає глибше розуміння того, як обробляються дані в програмі.
• Корисний для критичних систем, де надійність важлива.

Data Flow Testing — важливий метод для виявлення помилок, пов’язаних з неправильним використанням змінних. Це тестування не просто перевіряє, чи працює програма, а й як вона оперує даними всередині — що робить його дуже корисним для підвищення якості програмного забезпечення.

Control Flow Testing (тестування керування потоком) — це один із підходів до структурного (white-box) тестування, який фокусується на логічному потоці виконання програми або окремої функції. Мета — перевірити всі можливі шляхи, якими може пройти виконання програми, щоб виявити помилки в логіці, умовах або переходах.

Основні терміни:

• Control Flow Graph (CFG) — граф керування потоком, у якому вузли представляють блоки коду (наприклад, оператори або групи інструкцій), а ребра — можливі переходи між цими блоками залежно від умов.
• Блок (Basic Block) — послідовність інструкцій, що виконується без розгалужень.

Основні види контрольного тестування потоку:

1. Statement Coverage (Покриття операторів):
   • Перевіряє, чи всі інструкції коду були виконані хоча б один раз.
2. Branch Coverage (Покриття гілок / умов):
   • Перевіряє, чи всі можливі гілки (true/false) умов були пройдені.
3. Path Coverage (Покриття шляхів):
   • Перевіряє всі можливі унікальні шляхи виконання коду. Найглибший рівень, але часто складний для реалізації через велику кількість можливих шляхів.

Мета Control Flow Testing:

• Виявити:
  • логічні помилки;
  • помилки умовного переходу;
  • пропущені шляхи;
  • нескінченні цикли або недосяжний код.

Приклад:

def absolute_value(x):
    if x >= 0:
        return x
    else:
        return -x

Для цього прикладу Control Flow Testing має охопити два шляхи:

• коли x >= 0 (гілка if);
• коли x < 0 (гілка else).

Переваги:

• Дає глибоке розуміння внутрішньої логіки програми.
• Допомагає виявити складні, умовно-залежні помилки.

Підбиваючи підсумок, Control Flow Testing — це ефективний підхід до внутрішнього тестування логіки програмного забезпечення, що дозволяє виявити помилки, які можуть залишитися непоміченими при тестуванні лише на основі вимог або специфікацій (тобто без доступу до коду).

Loop Testing — це тип тестування програмного забезпечення, що належить до категорії білого ящика (white-box testing). Основна мета loop testing — перевірити правильність циклічних конструкцій (loops) у програмному коді.

Що саме тестується?

Тестуються цикли різного типу:

• for
• while
• do-while
• рекурсивні виклики (у деяких випадках)

Основні типи циклів, що тестуються

1. Прості цикли (Simple Loops). Цикл з однією умовою, наприклад:

for i in range(5):
   print(i)

2. Вкладені циклик (Nested loops). Один цикл всередині іншого.

for i in range(3):
    for j in range(2):
        print(i, j)

3. Залежні цикли

4. Cкладні цикли

Основна мета loop testing:

• Перевірити:
  • Вхід у цикл (чи виконується хоча б раз)
  • Вихід з циклу (чи коректно завершується)
  • Повторення (чи виконується потрібну кількість разів)
• Виявити:
  • Нескінченні цикли
  • Пропущені умови
  • Неправильні межі ітерацій

Типові тести:

1. Zero Iteration (нуль разів) — цикл не виконується зовсім
2. One Iteration (один раз)
3. Typical Iteration (звичайна кількість разів)
4. Max Iteration (максимально допустима кількість)
5. Beyond Max (понад межу) — для виявлення помилок переповнення

Приклад (Python):

def count_positive(nums):
    count = 0
    for num in nums:
        if num > 0:
            count += 1
    return count

Loop Testing тут перевірить:

• Порожній список ([])
• Список з 1 елементом ([5])
• Список з позитивними й негативними значеннями ([-1, 2, 3])
• Інші граничні випадки (дуже великий список, змішані значення, межа між негативним і позитивним (-1, 0, 1), усі значення негативні тощо)

Loop Testing — це важлива техніка для виявлення логічних помилок у циклах, особливо коли програма має багато ітерацій або вкладені цикли. Застосовується переважно розробниками чи тестувальниками, що мають доступ до коду.