Модальні дієслова в технічній літературі: Must, Should, May, Might

Модальні дієслова - це маленькі слова, які мають величезну вагу в технічному письмі. Різниця між * « вам слід перезапустити сервер » * і * « вам слід перезапустити сервер » * полягає у різниці між обов’ язковою інструкцією і рекомендацією. Вибір неправильного моду може створити вразливості безпеки, юридичні проблеми або просто заплутати читача щодо того, що насправді потрібно.

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

---

У цій статті мова йде про технічні засоби письма

У повсякденній розмові модали часто взаємозамінні. У технічному письмі вони не є:

• ** Must ** → вимога, що не підлягає обговоренню; невдача означає, що система не працюватиме або небезпечна
• ** Слід ** → сильна рекомендація; можуть існувати дійсні причини для відхилення
• ** May ** → необов’ язковий; дозволений, але не обов’ язковий
• ** Може ** → можливість в майбутньому або за певних умов

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

---

RFC 2119: Технічний стандарт написання

Рішення 2119 визначає ключові слова для документів стандартів IETF. Вони широко прийняті за межами IETF — документація API, внутрішні технічні специфікації і проектні документи використовують ті ж самі конвенції.

Якщо документ явно посилається на RFC 2119, ці ключові слова буде записано ВСІМА РЕГИСТРАЛЬНИМИ СЛОВАМИ:

“Ключеві слова MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, і OPTIONAL в цьому документі мають бути інтерпретовані так, як описано в RFC 2119.”

---

МІСТО / МІСТО НЕ (обов’ язкове)

** МІСТО** вказує на ** абсолютну вимогу**. Несумісність означає, що реалізація пошкоджена, не відповідає або небезпечна.

Context	Example
API requirement	”Every request MUST include a valid Authorization header.”
Security	”Passwords MUST be hashed using bcrypt or Argon2 before storage.”
Protocol	”The client MUST close the connection if it receives a 401 response.”
Configuration	”The database_url field MUST be set before starting the application.”

** MUST NOT ** абсолютно забороняє дію:

“Клієнтам НЕ ДОЗВОЛЯЄТЬСЯ повторювати спроби виконання запитів, які повертають код стану 422, без спочатку виправлення невірних параметрів.”

“Токени API НЕ МОЖНА включати до параметрів запиту URL — їх МІСЯЦЬ передати у заголовку Authorization.”

Еквівалент малих літер: «must» / «required»

У документації з прози (а не у формальних специфікаціях) малі літери * « must » * мають те саме обов’ язкове значення:

“Користувачі повинні перевірити свою адресу електронної пошти, щоб отримати доступ до додаткових функцій.”

---

Не слід / Не слід (рекомендовано)

** SHOULD ** означає, що описана поведінка настоятельно рекомендується, але ** існують дійсні причини ** відхилятися від неї за певних обставин. Розробник може вибрати не дотримуватися вимоги SHOULD, але повинен розуміти наслідки.

Context	Example
Performance	”Clients SHOULD implement exponential backoff for 429 responses.”
Error handling	”Services SHOULD return a correlation ID in every error response.”
API design	”Endpoints SHOULD use plural nouns: /users, /orders.”
Security	”Applications SHOULD enforce HTTPS redirects at the load balancer layer.”

** НЕ ПОТРІБНО ** позначає щось, що не рекомендується, але не заборонено:

“Розмір відповідей не повинен перевищувати 1 МБ, якщо клієнт не запитає більшу кількість даних.”

Пастка “Треба”

Найбільш поширена помилка: використання SHOULD, коли ви маєте на увазі MUST.

Якщо розробник проігнорує інструкцію SHOULD, і система зазнає аварії, не пройде перевірку безпеки або спричинить неправильну поведінку — вам слід було написати MUST.

“Заголовок Content-Type МІСТОЗНАЧЕННЯ application/json.”

Якщо запит без цього заголовка зазнає невдачі, цей заголовок має бути MUST. Резерв НЕОБХІДНО для випадків, коли відхилення має вартість, але іноді виправдано.

---

May/OPTIONAL (дозволено)

** МОЖЕ ** вказує на те, що поведінка або можливість є повністю необмеженою. Викликач або реалізація можуть вибрати, включати його або ні, без обов’язку.

“Поле metadata МОЖЕ містити будь-який чинний об’єкт JSON з додатковим контекстом.”

• “Клієнти МОЖУТЬ кешувати відповіді протягом 5 хвилин за допомогою значення у заголовку Cache-Control.” *

• “Параметр include_archived є НЕЗБЕРЕЖНИМ. Якщо не вказано, типово виключаються архівовані елементи.”*

Можуть літати

• ** MAY ** = дозволено (надання дозволу)
• ** CAN ** = здатний (технічні можливості)

❌ “Сервер може повернути перенаправлення 303.” (це означає, що це дозволено, або що він має технічні можливості?) ✅ “Сервер МОЖЕ повернути перенаправлення 303 на альтернативний ресурс.” (ясно дозволено, не обов’язково)

---

Можливості (англ. Possibilities)

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

• « Запит може перевищити час очікування під час високої завантаженості сервера. » * “Очищення кешу може призвести до підвищеного навантаження бази даних на 1-2 хвилини.”
• “Використання пам’ яті може збільшитися під час початкового процесу індексування.” *

Може проти може в технічному письмі:

• • « Процес може зазнати невдачі » * → існує ймовірність невдачі (можливість)
• • « Клієнти можуть повторити запит » * → клієнтам дозволено повторити запит (дозвіл)

---

Вільний від обов’язків

Word	Usage
will	Describing guaranteed behaviour: “The API will return a 200 status on success.”
shall	Formal synonym for MUST (older spec style, less common now): “The server shall validate the token signature.”
must	Current preference for mandatory requirements

У сучасному технічному письмі, віддавайте перевагу will для опису поведінки системи і must для встановлення вимог.

“Якщо термін дії токена закінчився, сервер поверне 401. Клієнти ** повинні ** запитати новий токен за допомогою кінцевої точки оновлення.”

---

Практичні приклади за типом документа

Документація API

## Authentication

All API requests MUST be authenticated using a Bearer token.

Include the token in the Authorization header:
Authorization: Bearer YOUR_TOKEN

Tokens MUST NOT be embedded in the request URL.

Expired tokens will return a 401 Unauthorized response. 
Clients SHOULD implement automatic token refresh using the 
/auth/refresh endpoint.

Runbook

## Deployment Checklist

Before deploying:
- You must notify the on-call engineer at least 30 minutes before.
- You should verify the staging environment is healthy.
- You may skip the staging verification for hotfixes, but must document the reason.

During deployment:
- You must monitor the error rate for 10 minutes after the rollout.
- If error rate exceeds 1%, you must immediately initiate a rollback.

Реєстр архітектурних споруд

## Decision

All inter-service communication MUST use mTLS for authentication. 
Plain HTTP between services in the internal network MUST NOT be permitted.

Services SHOULD use gRPC where low-latency bidirectional streaming is 
required. REST over HTTPS MAY be used for synchronous request-response 
calls where gRPC integration overhead is not justified.

---

Поширені помилки

1. надмірне використання MUST

Не все обов’язково. Використання MUST для рекомендацій послаблює всі інші ваші вимоги MUST.

❌ “Розробники МІСТЯТЬ дотримуватися стилю повідомлень про затвердження.” ✅ “Розробники СОВІТУЄМО дотримуватися стилю керівництва для повідомлень про затвердження.” (якщо несумісність не блокує CI — тоді МІСЯЦЬ)

2-й. Використання SHOULD, коли ви маєте на увазі MUST

Як описано вище: якщо відхилення призведе до аварії системи або створить проблему безпеки, скористайтеся MUST.

3-й. Поєднання мови RFC 2119 з неофіційною мовою

Непослідовне змішування формального MUST/SHOULD з випадковим «будь ласка, переконайтеся» або «рекомендується, що» плутає читачів щодо рівня відповідності.

4-й. Пасивні конструкції, що приховують актора

❌ “Треба переконатися, що тайм- аут налаштовано.” ✅ “Оператор повинен налаштувати тайм- аут перед розгортанням.”

Друга версія неоднозначна щодо того, хто відповідальний.

5-й. Використання “необхідно” як синонім “МІСЯЦЬ”

• « Вам слід автентифікуватися » * звучить обов’ язково, але у технічному письмі воно слабше, ніж * « Ви повинні автентифікуватися » * — воно також є розмовним і має змінне значення.

---

Швидка референсна картка

Modal	Obligation	Example
MUST	Absolute requirement	”Requests MUST include an API key.”
MUST NOT	Absolute prohibition	”Tokens MUST NOT be stored in localStorage.”
SHOULD	Strong recommendation	”Clients SHOULD retry on 503 with backoff.”
SHOULD NOT	Not recommended	”Responses SHOULD NOT exceed 10MB.”
MAY / OPTIONAL	Permitted, not required	”The lang parameter MAY be included.”
will	Guaranteed behaviour	”The server will return 200 on success.”
might	Uncertain possibility	”The process might take up to 5 minutes.”
can	Technical capability	”The CLI can output JSON with —format=json.”

---

Практичні вправи

Переписати кожне речення за допомогою правильного модального дієслова:

1. “Рекомендується використовувати HTTPS для всіх викликів API.”
2. • « Після завершення роботи вам обов’ язково слід закрити з’ єднання з базою даних. » *
3. “Можливо додати параметр fields для фільтрування відповіді.”
4. • “Вам слід включити тіло запиту для запитів POST.” *
5. “Кеш іноді може містити застарілі дані після оновлення.”

** Пропоновані відповіді: **

1. “Клієнти ДОВЖЕНІ використовувати HTTPS для всіх викликів API.”
2. • « Після завершення програми слід закрити з’ єднання з базою даних. » * (або МІСЯЦЬ)
3. “Клієнти МОЖУТЬ додати параметр fields для фільтрування відповіді.”
4. • “Запити POST МІСТЯТЬ тіло запиту.” *
5. Правильно як є — “може” підходить для невизначеності.

---

Зв’язок з читанням

• Активний проти. Співавтор технічної літератури
• Писання документації API англійською
• Англійська мова для перегляду кодів