Если не знать точное значение каждого слова, легко попасть в ловушку: один человек понимает «system requirement» как «то, что сказал заказчик», другой — как «техническое требование к системе». В результате — конфликты, переделки и потерянное время.
| № | Термин | Официальное определение (упрощённый перевод) | Пояснение простыми словами и пример из нашей библиотеки |
|---|---|---|---|
| 4.1 | requirement требование | Утверждение, идентифицирующее способность, характеристику или качественный атрибут системы или продукта, необходимый для удовлетворения контракта, стандарта, спецификации или других формально навязанных документов. | «Система должна делать вот это». Пример: «Система должна обеспечивать поиск книги за ≤ 500 мс». |
| 4.2 | stakeholder заинтересованная сторона | Лицо или организация, имеющие интерес в системе. | Все, кого касается проект: читатель, владелец NAS, администратор, регулятор (152-ФЗ). |
| 4.3 | stakeholder requirement требование заинтересованной стороны | Требование, исходящее от стейкхолдера. | То, что хочет стейкхолдер. Пример: «Я как читатель хочу читать книгу в браузере одним кликом». |
| 4.4 | system requirement системное требование | Требование, определяющее, что должна делать система для удовлетворения стейкхолдеров. | Техническое требование к всей системе. Пример: «Система должна хранить до 500 000 книг локально». |
| 4.5 | software requirement требование к программному обеспечению | Требование к программному обеспечению (подмножество system requirement). | Только про ПО. Пример: «Модуль Search должен использовать MeiliSearch». |
| 4.6 | functional requirement функциональное требование | Требование, определяющее функцию системы или её компонента. | Что система делает. Пример: «Система должна отображать обложку и аннотацию книги». |
| 4.7 | non-functional requirement нефункциональное требование | Требование, определяющее качественный атрибут или ограничение на функцию. | Как хорошо делает. Пример: «Поиск должен работать за ≤ 500 мс». |
| 4.8 | interface requirement требование к интерфейсу | Требование к интерфейсу между системой и внешними сущностями или между компонентами. | Пример: «REST API должен использовать JSON и OpenAPI 3.1». |
| 4.9 | performance requirement требование к производительности | Нефункциональное требование к времени отклика, пропускной способности и т.д. | Подтип non-functional. Пример: «99-й перцентиль поиска ≤ 300 мс». |
| 4.10 | design constraint ограничение проектирования | Ограничение на способ реализации требования. | Пример: «Использовать только Docker». |
| 4.11 | verification верификация | Подтверждение, что продукт соответствует своим требованиям (правильно ли построено?). | Тесты, ревью кода. |
| 4.12 | validation валидация | Подтверждение, что продукт удовлетворяет нуждам стейкхолдеров в условиях эксплуатации (то ли построено?). | Демо заказчику, UAT. |
| 4.13 | traceability трассируемость | Способность проследить историю, применение или местоположение элемента. | Связь USR-001 → SYS.REQ.001 → SW.FUNC.001 → TEST-001. |
| 4.14 | baseline базовая линия | Формально утверждённый набор требований в определённый момент времени. | «Версия требований 1.0 от 27.12.2025 — утверждена». |
| 4.15 | user пользователь | Лицо или организация, использующая систему в её предполагаемом окружении. | Конечный читатель библиотеки. |