requirements-basics

Основы требований: Что такое требования к ПО

📚 19 вопросовПройти тест →
Лекция

Основы требований: Что такое требования к ПО

requirements-basics

Основы требований: Что такое требования к ПО

Введение: карта перед путешествием 🗺️

Если команда начинает разработку без требований, каждый понимает цель по-своему. Итог почти всегда один: переделки, споры и потеря времени.
Требования — это рабочая договорённость: что именно должно получиться, для кого это делается и как понять, что результат принят.
✅ Вывод: требования нужны, чтобы превратить идею в проверяемый результат.

Проблема → решение

Проблема: «сделайте удобно и быстро» звучит понятно, но для команды это слишком размыто.
Решение: формулировать требования в измеримой и однозначной форме: актор, действие, условие, ожидаемый результат, критерии приёмки.
✅ Вывод: чем точнее требование, тем меньше риска ошибиться в реализации.

Чем помогает и как работает

Грамотно оформленные требования помогают:
  • выровнять понимание между бизнесом, аналитикой, разработкой и QA;
  • планировать релизы по реальному объёму и приоритетам;
  • заранее находить противоречия и пробелы.
Как это работает:
  1. Собираются цели и контекст.
  2. Формируются требования разного уровня.
  3. Уточняются границы, ограничения и критерии.
  4. Требования связываются с задачами и тестами.
✅ Вывод: требования — это инструмент управления рисками, а не формальность.

Ключевые термины (простыми словами)

  • Requirement — проверяемое утверждение о нужном результате.
  • Stakeholder — участник, на которого влияет продукт.
  • Business requirement — зачем бизнесу нужна функция.
  • User requirement — что должен уметь пользователь.
  • System requirement — как должна вести себя система.
  • Functional requirement — какое действие поддерживает система.
  • Non-functional requirement — с каким качеством/ограничениями это работает.
  • Acceptance criteria — условия, по которым требование принимают.
  • Scope — что входит и не входит в текущий релиз.
  • Traceability — связь требования с целью, задачей и тестом.
✅ Вывод: единая терминология снижает недопонимание в обсуждениях.

1. Что такое требование

Назначение: зафиксировать ожидаемый результат в проверяемой форме.
Пример:
Студент может записаться на курс и увидеть его в разделе «Мои курсы».
🔎 Как это происходит на практике:
  1. Формулируется ожидаемое поведение.
  2. Уточняется, кто выполняет действие.
  3. Добавляется результат, который можно проверить.
Когда использовать: для любой новой функции или изменения поведения системы.
✅ Вывод: требование должно быть не «желанием», а проверяемым утверждением.

2. Уровни требований: Business → User → System

Назначение: разделить цель, пользовательскую ценность и техническую реализацию.
Пример:
Business: увеличить конверсию записи на курс.User: студент может записаться в 2 шага.System: API создаёт запись и возвращает статус 201.
🔎 Как это происходит на практике:
  1. Продукт фиксирует бизнес-цель.
  2. Аналитик описывает пользовательские сценарии.
  3. Команда раскладывает это в системные требования.
Когда использовать: при детализации требований для разных ролей команды.
✅ Вывод: уровни требований убирают путаницу между «зачем», «что» и «как».

3. Функциональные и нефункциональные требования

Назначение: отделить поведение системы от качества выполнения.
Пример:
FR: пользователь может оплатить курс.NFR: подтверждение оплаты приходит <= 3 сек при 200 rps.
🔎 Как это происходит на практике:
  1. Сначала фиксируется действие (FR).
  2. Затем фиксируются ограничения по качеству (NFR).
  3. Проверки для FR и NFR планируются отдельно.
Когда использовать: всегда, когда функция должна не только работать, но и работать качественно.
✅ Вывод: смешивание FR и NFR делает документ нечитаемым и непроверяемым.

4. Формула хорошего требования

Назначение: писать требования одинаково и прозрачно.
Шаблон: Актор → Действие → Объект → Результат/условие
Пример:
Авторизованный студент может записаться на курс, после чего курс появляется в «Мои курсы».
🔎 Как это происходит на практике:
  1. Выбирается актор и сценарий.
  2. Формулируется действие без технического шума.
  3. Добавляется проверяемый результат.
Когда использовать: при написании каждого функционального требования.
✅ Вывод: шаблон защищает от размытых и двусмысленных формулировок.

5. Scope, ограничения и допущения

Назначение: задать границы и снизить риск разрастания задач.
Пример:
Scope: запись и отмена записи на курс.Не входит: мобильное приложение и сертификаты.Ограничение: использовать текущий платежный шлюз.Допущение: пользователь авторизован.
🔎 Как это происходит на практике:
  1. Команда фиксирует, что входит в релиз.
  2. Явно записывает, что не входит.
  3. Отмечает технические и бизнес-ограничения.
Когда использовать: в начале каждой инициативы и при планировании релиза.
✅ Вывод: без границ даже хороший документ требований быстро теряет контроль.

6. Критерии приёмки

Назначение: определить, когда требование считается выполненным.
Пример:
Дано: студент авторизован.Когда: нажимает «Записаться».Тогда: курс появляется в «Мои курсы».
🔎 Как это происходит на практике:
  1. Для ключевого требования пишутся проверяемые условия.
  2. QA и продукт синхронизируют трактовку результата.
  3. Критерии включаются в тест-кейсы.
Когда использовать: для всех требований уровня Must и рисковых сценариев.
✅ Вывод: критерии приёмки превращают требование в проверяемый контракт.

7. Атрибуты и трассируемость

Назначение: управлять требованиями на всем цикле разработки.
Пример:
ID: FR-1Приоритет: MustИсточник: Product ownerСвязанный тест: TC-42
🔎 Как это происходит на практике:
  1. Требованию присваивается ID и приоритет.
  2. Фиксируется источник и статус.
  3. Добавляются ссылки на задачу и тест.
Когда использовать: при работе с бэклогом, спецификациями и релизной проверкой.
✅ Вывод: трассируемость позволяет быстро понять, что реализовано и что проверено.

Сравнение: хорошее vs слабое требование

КритерийСлабоеХорошее
Формулировка«сделать удобно»«запись за <=2 клика»
Проверяемостьнетесть критерии
Границыне определеныscope зафиксирован
Связь с тестамиотсутствуетесть ID и тест-кейс

Часто спрашивают на собеседованиях

  • Что отличает требование от пожелания?
  • Как различать FR и NFR на практике?
  • Зачем фиксировать scope отдельно?
  • Что такое acceptance criteria и кто их пишет?
  • Почему трассируемость важна для QA и релиза?
✅ Вывод: на собеседовании важно показывать не теорию, а рабочую логику применения.

Типичные ошибки

Ошибка 1: Непроверяемые формулировки

❌ «Интерфейс должен быть удобным» ✅ «Запись на курс выполняется не более чем за 2 клика»

Ошибка 2: Отсутствие актора

❌ «Можно отменить запись» ✅ «Студент может отменить запись до старта курса»

Ошибка 3: Смешение требования и решения

❌ «Сделать кнопку зелёной» ✅ «Кнопка записи видна без прокрутки на первом экране»

Ошибка 4: Нет критериев приёмки

❌ «Запись работает» ✅ «После записи курс отображается в “Мои курсы”»

Best Practices

  • Пишите требования как проверяемые утверждения.
  • Всегда указывайте актора и ожидаемый результат.
  • Разделяйте FR и NFR отдельными блоками.
  • Явно фиксируйте scope, ограничения и допущения.
  • Добавляйте критерии приёмки и связи с тестами.

Заключение

🎯 Требования — это рабочая договорённость команды.
🎯 Хорошее требование всегда можно проверить.
🎯 Границы и критерии приёмки экономят время всей разработки.
Теперь вы можете отличать «идею» от полноценного требования и формулировать основу для качественного релиза.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «Основы требований: Что такое требования к ПО»

Пройти тест →