
- •4. Інженерія систем і програмного забезпечення
- •4.1. Складні та великі системи
- •4.1.1. Властивості систем: емерджентність, адитивність, еквіфінальність
- •4.1.2. Відкриті та закриті системи; класифікація за призначенням, походженням, видом елементів, способом організації
- •4.1.3. Спільне та відмінності складних і великих систем
- •4.2. Моделі систем
- •4.2.1. Склад і структура системи; моделі типу чорної та білої скриньки.
- •4.2.2. Концептуальні, математичні і комп’ютерні моделі
- •4.2.3. Зв’язок між системою та моделлю. Ізо- та гомоморфізм
- •Гомоморфізм
- •Гомоморфізм Гомоморфізм Ізоморфізм
- •4.3. Інформаційні системи
- •4.3.1. Поняття, цілі, значення, класифікація за функціональністю, масштабом, сферою застосування
- •4.3.2. Забезпечення інформаційних систем: організаційне, інформаційне, математичне, програмне, технічне, лінгвістичне, методичне, правове.
- •4.4. Аналіз вимог
- •4.4.1. Класифікація вимог до програмного забезпечення. Джерела та методи збирання вимог
- •4.4.2. Вимоги користувача (варіанти використання та історії користувачів).
- •4.4.3. Функціональні та нефункціональні вимоги, обмеження, структуризація функціональних вимог.
- •4.5. Проєктування програмного забезпечення
- •4.5.1. Види проєктування: структурне, обєктно-орієнтоване, архітектурне, інтерфейсне
- •4.5.2. Парадигми проєктування: функціональна декомпозиція згори вниз, архітектура, орієнтована на дані, об'єктно-орієнтований аналіз та проєктування, подієво-керована архітектура
- •4.5.3. Ідентифікація класів предметної області. Uml-діаграми ієрархії класів: моделювання підсистем, класів та зв’язків між ними
- •4.5.4. Проєктування сценаріїв реалізації варіантів використання на основі uml-діаграм послідовностей та комунікації
- •4.5.5. Основні патерни проєктування mvc, Abstract Factory, Facade, Decorator, Flyweight, Visitor, Observer, Proxy, Strategy, Chain of Responsibility
- •4.6. Реалізація програмного забезпечення
- •4.6.1. Вимоги до оформлення коду: стиль, розбиття на структуровані одиниці, найменування змінних, класів, об’єктів.
- •4.6.2. Засоби автоматичної ґенерації програмного коду
- •4.6.3. Налагодження: Точки зупинки (Breakpoints), Спостереження за змінними (Variable Watch), Виведення на консоль (Console Output), Налагоджувач (Debugger), Аналізатори коду (Code Analyzers)
- •4.6.4. Керування конфігурацією програмного забезпечення та контроль версій
- •4.6.5. Постійна інтеграція/постійне впровадження (Continuous Integration/Continuous Delivery)
- •4.7. Забезпечення якості: спільне та відмінності процесів тестування, верифікації, валідації
- •4.7.1. Тестування методами білої та чорної скрині
- •4.7.2. Рівні тестування: модульний, інтеграційний, системний, валідаційний.
- •4.7.3. Розробка через тестування (Test-driven development)
- •2. Види тестування зручности використання:
- •3. Проведення ефективного тестування зручности використання
- •4. Вирішення крайніх випадків в тестуванні зручности використання
- •4.8. Командна робота, підходи до розробки програмного забезпечення (пз)
- •4.8.1. Класичні моделі розробки пз: каскадна (водопадна), ітераційна, інкрементна
- •4.8.2. Промислові технології розробки. Rup, msf, Agile, Scrum, Extreme Programming (xp), Kamban.
- •4.8.3. Ролі та обов'язки у команді проекту, переваги командної роботи, ризики та складність такої співпраці
- •3. Ролі членів групи в моделі процесу розробки
- •4.8.4. Основні етапи планування і виконання іт проекту. Життєвий цикл іт проекту.
4.4.3. Функціональні та нефункціональні вимоги, обмеження, структуризація функціональних вимог.
У світі розробки програмного забезпечення та управління проектами розуміння різниці між функціональними та нефункціональними вимогами має вирішальне значення. Ці дві категорії вимог відіграють ключову роль у формуванні успіху проекту. У цій статті ми розглянемо ключові відмінності між функціональними та нефункціональними вимогами, їхнє значення та те, як вони впливають на процес розробки.
Функціональні вимоги, часто скорочені як FR, представляють основні функціональні можливості або особливості, якими повинна володіти система програмного забезпечення, щоб відповідати призначеній меті. Простіше кажучи, ці вимоги визначають, що повинна робити система. Вони описують взаємодію між програмним забезпеченням і його користувачами, а також поведінку програмного забезпечення за різних умов.
Характеристика функціональних вимог. Функціональні вимоги зазвичай мають такі характеристики:
Специфіка: вони детальні та конкретні, залишаючи мало місця для двозначності. Вони окреслюють точні функції, входи та виходи системи.
Можливість перевірки: функціональні вимоги можна перевірити та підтвердити, щоб переконатися, що програмне забезпечення працює належним чином.
Орієнтація на користувача: вони тісно узгоджені з потребами та очікуваннями користувача, гарантуючи, що програмне забезпечення виконує заплановану мету.
Змінність: функціональні вимоги можуть змінюватися протягом проекту, оскільки відгуки користувачів і потреби бізнесу розвиваються.
Приклади функціональних вимог:
Автентифікація користувача: система повинна дозволяти користувачам створювати облікові записи, входити в систему та скидати свої паролі.
Кошик для покупок: система повинна дозволяти користувачам додавати товари до свого кошика для покупок, переглядати вміст кошика та переходити до оформлення замовлення.
Функція пошуку: система повинна забезпечувати функцію пошуку, яка дозволяє користувачам знаходити продукти за ключовими словами.
Функціональні вимоги формують основу проекту програмного забезпечення та керують командою розробників у створенні бажаних функцій.
Нефункціональні вимоги, часто скорочені як NFR, доповнюють функціональні вимоги, вказуючи, як програмна система повинна виконувати певні функції. Вони визначають якості, характеристики та обмеження системи, а не її специфічні особливості. По суті, нефункціональні вимоги встановлюють стандарти продуктивності, безпеки та зручності використання системи.
Нефункціональні вимоги мають такі характеристики:
Якісні: на відміну від функціональних вимог, які зазвичай є кількісними, нефункціональні вимоги зосереджені на якісних аспектах, таких як продуктивність, надійність і безпека.
Глобально: нефункціональні вимоги застосовуються до всієї системи та впливають на її загальну поведінку.
Стабільність: вони, як правило, більш стабільні протягом життєвого циклу проекту, зміни відбуваються рідше порівняно з функціональними вимогами.
Вимірність: Хоча нефункціональні вимоги може бути важко точно визначити кількісно, їх все одно можна виміряти та протестувати.
Приклади нефункціональних вимог:
Продуктивність: система має завантажувати веб-сторінку менш ніж за 3 секунди навіть за 100 одночасних користувачів.
Безпека: система має відповідати галузевим стандартам безпеки та протоколам шифрування.
Масштабованість: програма повинна мати змогу обробляти 50% збільшення трафіку користувачів протягом шести місяців без погіршення продуктивності.
Нефункціональні вимоги гарантують, що програмне забезпечення працює ефективно та відповідає очікуванням користувачів щодо продуктивності, безпеки та інших критичних аспектів.
Чим функціональні вимоги відрізняються від нефункціональних вимог?
Функціональні вимоги, як випливає з назви, опишіть функції системи, яка буде розроблена. Це опис того, якою буде система і як вона функціонуватиме для задоволення потреб користувачів. Вони забезпечують чіткий опис того, як система має реагувати на конкретну команду, функції та те, що очікують користувачі.
Нефункціональні вимоги пояснюють обмеження та обмеження системи, яка буде спроектована. Ці вимоги не впливають на функціональність програми. Крім того, існує поширена практика підкласифікації нефункціональних вимог на різні категорії, наприклад:
Інтерфейс користувача
Надійність
Безпека
продуктивність
технічне обслуговування
Стандарти
Підкласифікація нефункціональних вимог є хорошою практикою. Це допомагає під час створення контрольного списку вимог, які мають відповідати створеній системі.
Нефункціональні вимоги такі ж важливі, як і функціональні. Якщо функціональні вимоги визначають, що повинна робити система, то нефункціональні вимоги описують, як вона буде це робити. Наприклад, нова програма надасть нам остаточний список усіх підключених користувачів. Це частина функціональних вимог. Якщо у вимозі зазначено, що система працюватиме лише в системах Windows і Linux, це буде частиною нефункціональних вимог.
Єдина відмінність між ними полягає в тому, що система не може функціонувати без задоволення всіх функціональних вимог. З іншого боку, система дасть вам бажаний результат, навіть якщо вона не задовольняє нефункціональним вимогам.
Розуміння відмінностей між функціональними та нефункціональними вимогами має важливе значення для успіху проекту. Хоча функціональні вимоги визначають, що повинна робити система, нефункціональні вимоги визначають, як вона повинна це робити. Ці два типи вимог доповнюють один одного і повинні розроблятися паралельно, щоб забезпечити повне розуміння обсягу та цілей проекту.
Співпраця між бізнес-аналітиками, розробниками, тестувальниками та зацікавленими сторонами має вирішальне значення для виявлення, документування та визначення пріоритетів обох типів вимог. Синергія між функціональними та нефункціональними вимогами гарантує, що кінцевий продукт відповідає очікуванням користувачів, одночасно відповідаючи продуктивності, безпеці та іншим критичним критеріям.
Висновок. Функціональні вимоги зазвичай описують, що повинна робити система, тоді як нефункціональні вимоги накладають обмеження на те, як система функціонує. Збираючи вимоги до проекту, важливо враховувати обидва типи, щоб створити вичерпний список, який слугуватиме основою для ваших зусиль щодо розробки.
Нефункціональні вимоги (Non-Functional Requirements):
- Бизнес-правила (Business Rules) – визначають обмеження, які залежать від предметної області та властивостей автоматизованого об’єкта.
- Зовнішні інтерфейси (External Interfaces)
- Атрибути якості (Quality Attributes) – описують додаткові характеристики продукту в різних «вимірах», важливих для розробників та/або користувачів.
- Обмеження (Constraints) – формулювання умов, модифікуючих вимоги чи набори вимог, звужуючи вибір можливіх рішень з їх реалізації.
Нефункціональні вимоги (NFR) — це обмеження, накладені на систему, які визначають її атрибути якості. Зазвичай вони позначаються такими прикметниками, як безпека, продуктивність і масштабованість. Нефункціональні вимоги важливі, оскільки вони допомагають забезпечити відповідність системи потребам користувача.
Нефункціональні вимоги можна розділити на дві категорії:
Атрибути якості: Це характеристики системи, які визначають її загальну якість. Приклади атрибутів якості включають безпеку, продуктивність і зручність використання.
Обмеження: Це обмеження, накладені на систему. Приклади обмежень включають час, ресурси та середовище.
Що входить до функціональних вимог (структуризація)