Етап формулювання вимог

Метою цього етапу є детально описати вимоги клієнта до системи.

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

Причинами трудності з клієнтами є:

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

2. великі системи, як правило, використовуються великою кількістю користувачів, тому можливі протиріччя в самому середовищі користувачів по використанню системи

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

Вимоги клієнтів до системи описуються на різних рівнях:

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

2. специфікація вимог (це опис…)

3. …

1. Вступ (цілі, можливості в контексті системи)

2. Опис розвитку системи (можливі майбутні зміни)

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

4. Опис не функціональних вимог

5. Модель системи

6. Словник термінів

Крім того, документ з опису вимог при потребі повинен містити додаткову інформацію:

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

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

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

4. вимоги до БД

5. план тестування

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

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

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

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

Для усунення таких незручностей використовують формальні примітки. Формальні примітки усувають двозначності і ускладнюють розуміння вимог клієнтом. Тому рекомендують формальні примітки використовувати в кінці не спеціалізованого опису. На практиці у більшості випадків функціональні вимоги подаються у формі очікуваного результату, а не алгоритму. Цей опис завжди є декларативним. І в деяких випадках виникає необхідність для специфічних функцій описувати і алгоритм. Як правило, функціональні вимоги формуються для визначення зовнішніх зв’язків, оскільки функції системи повинні бути відомі не тільки користувачам, а й іншим взаємодіючим системам, тому під функціями системи не повинно розуміти тільки функції програми.

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

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

На прктиці використовуються ці два методи опису функцій:

1. знизу вверх

2. зверху вниз

Не функціональні вимоги

Описуються основні функції системи.

Поділяються на:

1. вимоги до продукту (система повинна використовувати все що необхідне для системи…)

2. вимоги до процесу (система повинна підтримувати певний стандарт…)

3. зовнішні вимоги – це вимоги до роботи з зовнішніми системами.

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

Для успішного виконання вимог необхідно:

1. постійна співпраця з відповідними представниками клієнта

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

3. перевірка завершеності і послідовності вимог

4. короткий опис нефункціональних вимог

Етап аналізу

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

Для того щоб якісно виконати цей етап необхідно:

1. Залучати до виконання цього етапу відповідних професіоналів з проблемної області

2. Підтримання необхідних стандартів

3. Визначення правильності та перевірка концепцій

4. Прозорість

5. Логічність

6. Послідовність ведення документацій

7. Глобальне розуміння розробниками системи без деталізації особливості

За результатами виконання цього етапу отримаємо:

1. Покращений документ по вимогах

2. Словник даних по системі

3. Документ, що описує створену модель:

1. Діаграма класів

2. Діаграма випадків використання

3. Діаграма дій

4. Діаграма станів

5. Звіт, який описує визначення класів, ознак відносин, методів і т.д., що використовуються в системі

4. Графік етапу проектування

5. Попереднє визначення людей та команд на розробку

Дата добавления: 2014-01-05