Методи збору та виявлення вимог

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

Методи виявлення та встановлення вимог: - інтерв’ю замовника та експертів прикладного домену;

· анкетування; - спостереження; - вивчення документів та аналогічних систем; - нарада -створення прототипів; - «мозковий штурм».

13. Інтерв’ю замовника та експертів прикладного домену

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

Існують два основних типи інтерв’ю: структуроване (формальне) і неструктуроване (неформальне). Структуроване інтерв’ю готується заздалегідь, відрізняється ясністю постановки питань, а багато питань можуть бути задані заздалегідь. Неструктуроване інтерв’ю більше нагадує неформальну зустріч, якій невластиві заготовлені про запас питання або заздалегідь поставлені цілі.

Наперед сформульовані питання можна розділити на дві категорії:

· Питання з відкритою множиною відповідей (відповіді на цю категорію питань заздалегідь не готуються);

· Питання з замкнутою множиною відповідей (відповіді на цю категорію питань можна вибрати зі списку підготовлених відповідей)

Мета неструктурованого інтерв’ю – спонукати замовника до того, щоб він поділився своїми думками і під час розмови підійшов до вимог, яких бізнес аналітик міг і не чекати і, отже, не міг поставити потрібні питання.

Інтерв’ю замовника та експерта прикладного домену:

Частина 1: Визначення профілю замовника. Визначаємо ім’я, галузь в якій він працює, що він виробляє, для кого він виробляє, як вимірюється успіх діяльності компанії, які проблеми впливають на успішність діяльності компанії.

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

Частина 3: Розуміння середовища користувача. Хто такі користувачі, яка в них освіта, які в них навики в комп’ютерній області, чи мають вони досвід роботи з даним типом застосувань (додатків), яка платформа використовується, які замовник хоче використовувати платформи в майбутньому.

Частина 4: Резюме. Повторити за замовником те, що він говорив, щоб він зрозумів, чи правильно була зрозуміла інформація дана ним.

Частина 5: Пропозиції аналітика стосовно проблеми замовника. Чи дана проблема є реальною, які її причини, як вона вирішується у поточний час, наскільки важливе замовнику вирішення цього питання або проблеми.

Частина 6: Оцінка рішення, що було запропоноване. Здійснюється характеристика, при оцінці запропонованого рішення, основних можливостей рішення що нами було запропоноване. А потім задаємо додаткові питання про функціонал.

Частина 7: Оцінка можливості розповсюдження. Хто в організації потребує дане застосування, скільки користувачів буде використовувати дане застосування.

Частина 8: Оцінка необхідного рівня надійності і продуктивності. Очікування відносно надійності, продуктивності, хто буде займатись підтримкою продукту і чи треба це, чи є вимоги по ліцензуванню, які вимоги на маркування і упаковку та інше.

Частина 9: Інші вимоги. Вимоги законодавства, інформаційного середовища, інструкція та стандарти які мають бути підтримані.

Частина 10: Закінчення. Запитують чи існують питання, на які не дали відповіді (які не були задані).

Частина 11: Висновок аналітика.