Розбираємо ази архітектури й нефункціональні вимоги

Усі статті, обговорення, новини для початківців — в одному місці. Підписуйтеся на телеграм-канал!

Вітаю, мене звати Людмила Зінченко, я Software Architect в EPAM.

У цій статті ми поговоримо про ази архітектури й нефункціональні вимоги, або non-functional requirements. Матеріал буде корисний для тих, хто тільки починає шлях в архітектурі й прагне розібратися з напрямом детальніше, а також фахівцям із певним досвідом, які хочуть систематизувати знання.

Почну з простої, однак цікавої аналогії: порівняємо Solution Architect з архітектором у класичному розумінні, тобто технологом навколишнього середовища. Уявіть, що ви клієнт і прийшли до останнього із запитом: «Спроєктуйте мені будинок». Як результат роботи ви можете очікувати на красиву картинку з гарним та сучасним зовнішнім фасадом. Але цього недостатньо. Бо архітектор також має попіклуватися про правильні розрахунки, розміри в просторі (як-от стелі, вікон, дверних проходів), місце для проведення комунікацій (електрики, водопроводу тощо) і навіть намалювати окремо, як буде проходити електропровіддя, труби і т. ін. Тобто в підсумку в архітектора буде умовно не одна картинка, а декілька, плюс креслення. І всі вони відображатимуть єдину систему з різних рівнів: фасад, планування поверхів, креслення з облаштуванням комунікацій та багато іншого.

Те саме в Solution-архітектурі. Коли ми робимо дизайн, або солюшн, то маємо піклуватися не тільки про компоненти й сервіси, з яких він складатиметься. Не можна обійтися однією гарною діаграмою. Потрібно продумати на різних рівнях, як і що виглядатиме, яка буде пропускна здатність системи, навантаження, які ресурси будуть залучені.

Клієнт чекає від архітектора варіант, який йому точно сподобається, щоб дизайн підходив за стилем, смаком та відповідав його потребам і вимогам. Наприклад, якщо це будинок, то навіщо він потрібен: для оренди, продажу чи життя? Якщо для життя, то на який період: впродовж літа чи цілого року? На скількох людей розрахований? Усе це й чимало іншого потрібно з’ясувати.

Перш ніж продовжити говорити про архітектуру і позицію Solution Architect, пояснимо певні терміни. А саме поняття бізнес-цілей, бізнес-драйверів і власне non-functional requirements, quality attribute, architecture significant requirements. Чому це важливо? Architecture in IT — це напрям в ІТ-індустрії, який має свої стандарти, сертифікати, ком’юніті, що працюють над оновленням стандартів. А ще в нього є власна термінологія, яку потрібно знати й використовувати, зокрема на співбесідах.

Business goals and business drivers

Бізнес-цілі — заздалегідь визначена мета, якої бізнес або окрема особа планує досягти за встановлений період часу.

Бізнес-драйвери — ключові вхідні дані та дії, які керують операційними та фінансовими результатами бізнесу.

Щоб розуміти, як визначити бізнес-ціль та бізнес-драйвер і навіщо, повернімося до прикладу з будинком. Коли ми поцікавимося в клієнта: «Навіщо цей будинок? Що ви хочете покращити у своєму житті?», то дізнаємося нашу бізнес-ціль. А відповідь на запитання «чи можемо ми цього досягти, використовуючи певні матеріали?» буде нашим бізнес-драйвером.

Утім, часто через нечіткість запиту клієнта архітектор ризикує оминути щось увагою. Наприклад, після спілкування із замовником нібито все зрозуміло: будинок призначений для життя на цілий рік, сім’я складається з двох людей. Проте вже на етапі експлуатації виявляється, що родина любить проводити час із друзями й раз на місяць влаштовує вечірки на 15 людей. Тоді будинок не витримує: не вистачає місця, електрика не справляється, постійно вибиває щиток тощо. Аби цього не допустити, архітектор має з’ясувати деталі такого штибу наперед і задовольнити всі потреби.

Тепер перейдемо до IT-індустрії. Уявімо таку ситуацію: компанія, продуктом якої є стримінгова платформа, звертається до архітектора з завданням «покращити систему». Навіщо? Щоб підвищити дохід. Бізнес-ціль вимірюється певним проміжком часу, тому тут її можна переформулювати так: «Ми хочемо підняти дохід на 15% до кінця року».

Що в цьому випадку може бути бізнес-драйвером? Наприклад, для стримінгової платформи розширення аудиторії зумовить збільшення кількості підписок, за які користувачі платять, і таким чином збільшиться дохід. Це один з варіантів розвитку бізнесу.

Інший шлях може полягати в додаванні функцій та процесів, що потребуватиме збільшення кількості співробітників. Ці оновлення будуть автоматизовані, для цього можна створити додатковий відділ або команду. Основний ресурс і драйвер у цьому випадку — це співробітники, які обслуговуватимуть нові функції.

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

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

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

Тож є ціла система визначення нефункціональних вимог. Це quality attributes workshops, Q&A-сесії, документація в певному вигляді та ін.

Non-functional requirements

Якщо перейти власне до визначення нефункціональних вимог, то варто згадати про типи функціональних вимог загалом. Вони діляться на функціональні та нефункціональні. Все, що відповідає на запитання «що система має робити?», — це функціональні вимоги. А «як саме?» — нефункціональні.

Нефункціональні вимоги (non-functional requirements) — набір специфікацій, які описують можливості роботи системи та обмеження і можуть бути явними або неявними.

NFR складаються з quality attribute requirements, або QAR (не плутати з QA, що тестує), і constraints. Quality attribute — це щось маленьке, конкретне, вимірюване; можна оцінити, наскільки це адресує потреби стейкголдерів. Constraints — це обмеження, які входять до non-functional requirements. Наприклад, якщо система має використовувати певну технологію або модуль, який не можна змінювати, — це констрейнт. Бюджет і вартість розробки теж можуть бути constraints.

Отже, non-functional requirements складаються з:

1. Quality attribute requirements (QAR) — вимоги до якості, які вимірюються й оцінюються.
2. Constraints — обмеження або обмежувальні умови, які впливають на розробку системи (наприклад, використання певної технології або дотримання бюджету).

Software quality attributes допомагають оцінити його якість з різних кутів зору. Їх можна широко класифікувати на п’ять типів: якості дизайну, якості під час виконання, системні якості, якості з погляду користувача та якості, що не пов’язані з часом виконання. Однак, якщо розглядати детальніше, існує принаймні 14 різних атрибутів, а у вікіпедії їх узагалі перелічено понад 50. Є різні класифікації за різними стандартами, і вони постійно оновлюються.

Ось основні quality attribute requirements:

1. Performance — наскільки швидко система обробляє запити та з якою затримкою.
2. Scalability — наскільки система може збільшити свої ресурси в умовах зростання навантаження.
3. Usability — наскільки зручним є інтерфейс для користувачів, зокрема доступність (accessibility).
4. Maintainability — наскільки легко підтримувати та вдосконалювати систему.
5. Reliability — наскільки система може витримувати фейли й відновлюватись.
6. Availability — наскільки система доступна для користувачів без перерв.
7. Security — наскільки система захищена від несанкціонованого доступу й атак.
8. Portability — наскільки легко переносити систему між різними середовищами.
9. Integration — наскільки система інтегрована з іншими системами.
10. Extensibility — наскільки легко розширювати систему новими компонентами або функціями.
11. Flexibility — наскільки легко змінювати або замінювати компоненти системи.
12. Compatibility — наскільки система сумісна з іншими системами або середовищами.

Введемо ще одне поняття — architecture significant requirements, адже не всі вимоги, що ми збираємо, впливають на архітектурні рішення.

Отже, architecture significant requirements (ASR) — це сукупність functional і non-functional requirements, які суттєво впливають на архітектуру системи. Зміна, додавання або видалення ASR призведе до змін в архітектурі системи.

Щоб ефективно візуалізувати та подати non-functional requirements замовнику, можна використовувати діаграми у формі дерева. Ось як це можна зробити на прикладі реальної системи (анонімізовано):

1. Root node: основний корінь діаграми — це загальна категорія вимог, наприклад utility.
2. Branches: від кореня відходять гілки, які уособлюють основні категорії вимог, такі як Performance, Security, Usability тощо. Ці категорії відображають quality attributes, які ми можемо виміряти та оцінити.
3. Leaves: кінцеві елементи гілок — це конкретні вимоги або атрибути якості. Вони охоплюють як functional, так і non-functional requirements. Найсвітлішим кольором зображені architecture significant requirements.

Пріоритезація нефункціональних вимог

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

Пріоритети бізнесу та технічної команди часто відрізняються. Наприклад, бізнес може вважати певну функціональність менш важливою (low priority), тому що вона не має прямого впливу на дохід або задоволення клієнтів. Водночас для технічної команди ця функціональність критична (high або medium priority) в рамках забезпечення стабільності, безпеки або масштабованості системи.

Для ефективної пріоритезації вимог використовують різні категорії пріоритетів, такі як high, medium і low. Наприклад:

• High priority: вимоги, які мають найбільший вплив на досягнення бізнес-цілей або стабільність системи. Їх задовольняють насамперед.
• Medium priority: вимоги, які важливі, але не критичні. Мають бути реалізовані після вимог з високим пріоритетом.
• Low priority: вимоги, які можуть бути корисними, але не є критичними для поточного релізу. Їх можна відкласти на пізніший час.

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

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

Що далі

Отже, ми розглянули важливу термінологію і докладно поговорили про нефункціональні вимоги. І якщо підсумувати, що з ними робити, інструкція виглядатиме так:

1. Визначити бізнес-цілі й бізнес-драйвери. Це етап спілкування із замовником і детальних обговорень. Лише від уміння правильно скласти й поставити запитання буде залежати успіх цього етапу, і для цього є різні техніки.
2. Збирання і документація нефункціональних вимог. Буває, що замовник не знає, які нефункціональні вимоги підійдуть. Тоді варто запропонувати йому варіанти й подати це у вигляді таблиці, текстового документа або діаграми, наприклад utility tree.
3. Пріоритезація. Процес пріоритезації має бути прозорим, гнучким та визначатися двома сторонами — і бізнесом, і технічною командою.
4. Адресування вимог.

Й ось нарешті на четвертому кроці ми доходимо до адресування (задоволення) вимог, що є, напевно, найцікавішим кроком для всіх інженерів. Тоді йдеться вже власне про створення архітектури, про дизайн архітектури. Результатом можуть бути діаграми, іноді із супутнім описом.

Якщо ми згадаємо аналогію з будинком, де є багато різних креслень з різних рівнів, то в архітектурних діаграмах буде діяти те саме правило: систему не можна описати поглядом лише з одного розрізу — потрібно більше кутів.

Саме тому існують цілі типології та підходи для візуалізації, такі як C4 Model і 4+1 View Model, їхній мікс тощо. За цим принципом на систему можна дивитися з різних перспектив. Наприклад, у C4 Model виділяють такі чотири діаграми:

1. System context diagram.
2. Container diagram.
3. Component diagram.
4. Code diagram.

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

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

Це досить об’ємна тема, тож я наведу тут лише один маленький приклад з адресуванням security.

Для адресування кожної quality attribute є цілий набір технік і патернів. Наприклад, для security такими можуть бути Federated identity, Gatekeeper, Valet key тощо.

Якщо ми як архітектори обираємо певний патерн, то маємо пояснити чому. Наприклад, система, яку ми створюємо, має декілька доменів, і є вимога, щоб користувачі могли залогінитись у всі ці домени за допомогою одних і тих самих логіна й паролю. Отож Federated identity тут ідеально підходить. Тоді ми обираємо цей патерн і наносимо його на діаграму, де і всі компоненти. Також, якщо частиною адресування вимоги security є використання HTTPs замість HTTP, шифрування даних чи використання закритої мережі, або whitelisting, ми також маємо відобразити це на діаграмах.

Нижче наведено приклад, як можна намалювати Federated identity pattern. На діаграмі бачимо, що відображена лише маленька частина системи, показано, як ми адресуємо security саме цим патерном.

Висновок

Основна помилка, яку я помічаю, — застосовування патернів і технік просто тому, що вони популярні, хайпові. Проте завжди важливо розуміти, звідки ноги ростуть, та починати аналіз згори — з бізнесу, бізнес-цілей — і вже тільки тоді складати список актуальних для конкретної системи вимог (ASR). І як останній фінальний етап — підбирати техніки й патерни, що можуть допомогти у вирішенні завдання. Бо кожен дизайн (архітектура) чи патерн вирішує певну проблему, вимогу. А в голові архітектора має бути чітка зв’язка, яку вимогу / проблему ми вирішуємо. Лише тоді можливо побудувати дійсно якісну систему.