2. Етап визначення вимог

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

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

Труднощі на цьому етапі виникають з наступних причин:

• клієнт не знає, як цілі можуть бути досягнуті ( існує багато способів досягнення цілей)

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

• люди, що організовують замовлення і користувачі – це різні люди. Думка замовників може бути критичною на цьому етапі, але вони, можливо, не враховують деяких потреб користувачів.

Вимоги клієнта можна описати на різних абстрактних рівнях:

• визначення вимог ( загальний опис, який проводиться після обговорення деталей з представниками клієнта)

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

• специфікація ПЗ - завершений формальний опис вимог

Опис вимог повинен:

• бути повним і послідовним;

• описувати, як поводиться система, як вона організована;

• розглядати будь-які обмеження системи;

• бути легким у розвитку;

• брати до уваги можливі майбутні зміни;

• описувати виключення.

Основна помилка на цьому етапі полягає в зосередженості на типових ситуаціях і нехтування виключеннями. І користувачі, і аналітики мають таку схильність.

Вимоги до ПЗ можуть бути розділені на два типи:

• Функціональні вимоги. Вони описують функції (операції, дії), що виконуються системою;

• Нефункціональні вимоги. Вони описують обмеження функціональності.

Вимоги повинні міститися в відповідному документі, який повинен містити в собі наступні розділи:

• вступ - цілі, можливості і контекст системи. Ця частина містить результати стратегічного етапу

• опис розвитку системи - опис можливих змін

• опис функціональних вимог

• опис атрофованих вимог

• модель системи

• словник

Крім того цей документ може містити додаткову інформацію:

• специфікація функціональних вимог

• специфікація нефункціональних вимог

• вимоги до устаткування

• вимоги до баз даних

• індекс

• плани тестування

2.1. Функціональні вимоги

Функціональні вимоги описують функції, що виконуються системою. Вони можуть включати в себе вимоги дозовнішніх систем.

Часто для опису вимог використовується неспеціалізована мова, при цьому виникають деякі незручності:

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

• гнучкість неспеціалізованої мови, яка дозволяє виражати той же самий вміст в різних формах. Це може призвести до упущення суперечливих вимог, сформульованих в різноманітних формах одних і тих самих функцій.

Формальна примітка може усунути двозначність, але при цьому може виявитись важкою для сприйняття клієнтом. Таким чином, формальна примітка може тільки підсумовувати неспеціалізований опис.

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

Функціональні вимоги сформульовані, щоб визначити зовнішні зв'язки. Функції системи повинні бути відомі користувачам і іншим взаємодіючим системам. Під функціями системи ми не повинні розуміти тільки функції програми.

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

Практично клієнти не завжди розуміють або цікавляться загальними функціональними можливостями системи і обговорюють специфічні функції, які потім об’єднані аналітиком системи. Таку методику називають знизу-вверх.

Більшість розробників використовує обидва методи. Аналітик системи повинен розглянути спочатку загальні функції, а потім інформацію, зібрану у користувачів. Таким чином розділення і об’єднання опису застосовується в процесі формулювання вимог.