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

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

Дві категорії вимог

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

Що відноситься до категорії?

По суті, до функціональним вимогам насамперед зараховують різні атрибути якості продукту. А саме - вимоги, що визначають якісні характеристики розробки (програмного забезпечення, інформаційної системи). Це, звичайно, надійність, масштабованість, продуктивність продукту. Однак велике значення мають і такі нефункціональні вимоги: Обмеження. Тобто умови, що обмежують вибір будь-яких рішень щодо втілення в життя окремих вимог (або наборів вимог). Вони звужують різноманітність вибору інструментів, стратегій, засобів при розробці структури (архітектури), так і зовнішнього вигляду інформаційного якого програмного продукту. Бізнес-правила. Сюди відносяться керівні правила, політика, принципи, положення, якось обмежують певні аспекти бізнесу. Наприклад, вони можуть визначати склад і правила виконання будь-яких бізнес-проектів. Що можна віднести до цієї категорії? Корпоративну політику, всілякі урядові постанови і укази, промислові стандарти, обчислювальні алгоритми. Всі правила, що впливають на розробку системи, продукту, використовуються під час роботи над проектом. Пропозиції щодо реалізації. У групу входять конкретні пропозиції, які оцінюють можливість застосування певних архітектурних і технологічних рішень. Зовнішні інтерфейси. Опис ключових аспектів взаємодії продукту з іншими системами та операційної середовищем. Насамперед, це вимоги до API системи або продукту, а також вимоги до API інших систем, з якими планується інтеграція розроблюваного продукту. Пропозиції з перевірки, тестування розроблюваного програмного забезпечення. Це ряд доповнень до вимогам, що вказує, як те чи інше вимога повинно бути перевірено на практиці. Юридичні вимоги. До ліцензування продукту, наявності патенту та ін. Важливо відзначити, що нефункціональні вимоги до системи попередньо визначаються і фіксуються. Тільки після цього фахівець може приступити до розробки продукту.

Приклади вимог

Щоб мати більш чітке уявлення про нефункціональних вимог до інформаційної системи, розглянемо ряд прикладів: Обмеження. "Дана розробка ведеться тільки на платформі вендора Х". "При аутентифікації користувача в інформаційній системі повинні використовуватися лише біометричні методики ідентифікації". Бізнес-правила. "При відвантаженні продукту менеджер зобов'язаний запитати у бухгалтера підприємства рахунок-фактуру і транспортно-товарні накладні". "Замовлення буде вважатися скасованим, якщо оплата за рахунком не надійшла постачальнику протягом 14-ти днів". Зовнішні інтерфейси. "Забезпечити запис у журнал операційній системи таких подій: повідомлення про старт і зупинки сервісу Х". "Забезпечити запис у журнал розроблюваної програми параметрів даних її модулів: ядра, сканера, антивірусної бази. Інформація повинна бути занесена до журналу як при запуску, так і при відновленні його модулів".

Як визначати дані вимоги?

Ми розібрали конкретні приклади функціональних вимог. А тепер інше важливе питання: "Як їх визначати у відношенні конкретного продукту?"
Насамперед фахівці складають шаблон, в якому перераховуються головні типи нефункціональних вимог до продукту. Насамперед він потрібен для того, щоб не упустити яку-небудь позицію з цього списку. Джерелами для складання подібних шаблонів розробники зазвичай вибирають наступне: ГОСТ (державний стандарт РФ) 34-ї серії. Книга "Розробка вимог до програмного забезпечення" (автор - К. Вігерс). Зокрема, потрібно звернути увагу на розділ "Додаток Г". В ньому містяться конкретні приклади документації з вимогами. Давайте розглянемо тепер, хто конкретно займається цією роботою.

Діяльність з визначення вимог до продукту

Розробкою функціональних і нефункціональних вимог до системи займаються спеціальні робочі групи. Їх члени визначають не тільки, але і перевіряють, стверджують дані приписи.
А що стосується нефункциональной категорії, то для її визначення важливо залучити до роботи не тільки користувачів і аналітиків, але і ключових розробників продукту, архітекторів системи, а також групу тестувальників. Чому це важливо? Архітектор, скажімо, буде сприймати нефункціональні вимоги в якості вхідних даних для вибору і проектування архітектури програми. А група тестування буде за ним планувати відповідні сценарії навантажувального тестування. Саме з допомогою останніх буде перевірятися виконання функціональних вимог. За великим рахунком, це стосується атрибутів якості.

Ролі учасників робочої групи

Давайте тепер розглянемо, які ролі розподіляються між членами групи фахівців, які визначають і затверджують нефункціональні вимоги до продукту: Користувачі. Ці учасники дають оцінку значень параметрів, які і визначають нефункціональні вимоги. Системний аналітик. Даний учасник збирає, аналізує, систематизує та документує нефункціональні вимоги. Ключові розробники і системний архітектор. Яку роль виконує ця група? Беруть участь у визначенні, аналізі нефункціональних вимог, так і перевіряють їх на ступінь втілення в життя. Група тестування. Також бере участь у визначенні, аналізі переліку нефункціональних вимог до програми. Додатково розробляє сценарії тестування для даних приписів.

Сценарій для визначення вимог

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

Система отримує сигнал про подію, ініціюванні розсилку електронних повідомлень. Система здійснює розсилку повідомлень користувачам зі списку А, використовуючи для цього шаблон Б. Для відправлення послань використовується сервіс Ст. У разі неможливості завершення операції система робить повторну спробу розсилки повідомлень.

Формування вимог до продукту за сценарієм

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

Важливі критерії вимог

Самі нефункціональні вимоги повинні строго відповідати цілому ряду якісних критеріїв до їх змісту:
Повнота (як окремої вимоги, так і повного їх переліку). Що це означає? Вимога повинна містити в собі всю необхідну інформацію для його втілення в життя. Однозначність. Вимога не повинно суперечити ні самому собі, ні іншим пунктам зі списку. Усі працюючі з ним фахівці повинні розуміти його однаково. Коректність окремої вимоги, що забезпечує системну несуперечність. Необхідність. Реалізація цієї вимоги дійсно потрібна користувачам. Здійсненність. Втілити це вимога життя реально. Проверяемость. Повинно забезпечувати однозначну перевірку його реалізації. Ми з вами познайомилися з таким поняттям, як нефункціональні вимоги до програмного продукту, інформаційної системи. Також розібрали їх конкретні приклади, на відміну від функціональної категорії, критерії якості категорії. Ви знаєте, які групи фахівців яким чином створюють та затверджують дані приписи.