• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· словник

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

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

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

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

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

· індекс

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· вимоги продукту, наприклад "можуть використовуватися тільки клавіатура і миша "

· вимоги процесу, наприклад "система повинна виконувати за стандартом XXA/2002"

· зовнішні вимоги, наприклад "система повинна працювати з базою даних, описаною в документі YYYB/2001, і ніякі зміни в базі даних недопустимі"

Ці вимоги повинні бути зрозумілими, тобто повинен бути метод перевірки виконання умов. Такі вимоги як: "зручний", "надійний", "ефективний" не можуть бути перевірені, отже, вони не відповідають формулюванню.

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

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

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

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

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

3. Аналіз

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

Мета проектування полягає в тому, щоб визначити, як система повинна бути реалізована.

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

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

Проект розпочинається з вибору моделі в області проблеми і передбачає визначення, яка повинна бути система. Проте, обов'язки системи зазвичай - підмножина змодельованої моделі в аналізі.

Чинники успіху при аналізі є:

· залучення професіоналів;

· підтримка необхідних стандартів, наприклад, в примітці;

· правильність і перевірка концепції;

· прозорість, логічність і послідовність документації;

· глобальне розуміння системи без деталізації особливостей.

За результатами аналізу отримують:

· покращений документ по вимогам;

· словник даних;

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

o діаграми класу

o діаграма випадків використання

o діаграма дій

o діаграми станів

o звіт, що описує визначення класів, ознак, відносин, методів і т.д.;

· графік етапу проектування;

· попереднє призначення людей і команд.

Читайте також:

1. I визначення впливу окремих факторів
2. II. Визначення мети запровадження конкретної ВЕЗ з ураху­ванням її виду.
3. II. Вимоги безпеки перед початком роботи
4. II. Вимоги безпеки праці перед початком роботи
5. II. Вимоги до складання паспорта бюджетної програми
6. II. Мотивація навчальної діяльності. Визначення теми і мети уроку
7. III. Вимоги безпеки під час виконання роботи
8. III. Вимоги безпеки під час виконання роботи
9. III. Вимоги до учасників, складу груп і керівників туристських подорожей
10. IV. Вимоги безпеки під час роботи на навчально-дослідній ділянці
11. IV. ВИМОГИ ПРОФЕСIЇ ДО IНДИВIДУАЛЬНО-ПСИХОЛОГIЧНИХ ОСОБЛИВОСТЕЙ ФАХIВЦЯ
12. Ocнoвнi визначення здоров'я

Переглядів: 2287