Услуга «Разработка функциональных и нефункциональных требований (ФТТ)» — это подготовка полного, согласованного и проверяемого набора требований к новой системе или доработке существующей: какие функции нужны, как они должны работать и каким нефункциональным критериям (производительность, нагрузка, безопасность, отказоустойчивость, доступность) должна соответствовать система. На выходе заказчик получает комплект документов ФТТ, по которому команда разработки или подрядчик может оценивать, проектировать, реализовывать и принимать результат без домыслов и переделок.
Кому нужна услуга
Заказчикам новой IT-системы: есть идея и потребность, но нет ясного, проверяемого описания того, что именно нужно построить.
Компаниям с доработками: система уже работает, но запросы на изменения размыты, разработчики трактуют их по-своему, объём работ каждый раз пересматривается.
Продуктовым командам и владельцам продукта: требуется единый источник требований для планирования, оценки и приоритизации бэклога.
Руководителям IT и цифровизации: нужен контроль, что подрядчик делает то, что заказано, и что закупка/поставка соответствует потребностям бизнеса.
Бизнес-заказчикам, которые не понимают язык разработки: нужно прозрачное ТЗ, которое можно прочитать, проверить и принять.
Проектам под внешнюю разработку или тендер: без формализованных ФТТ невозможно корректно сравнить предложения и зафиксировать ответственность.
Что нужно от вас на входе
Цель и бизнес-задача системы/доработки. Определяет, ради какого результата разрабатываются требования и по каким критериям оценивать достаточность функций.
Пользователи, роли и ключевые сценарии работы. Требования формулируются от реальных процессов и ролей, а не от абстрактной функциональности.
Существующие процессы, регламенты, инструкции. Показывают, что автоматизируем, где узкие места и что менять нельзя без отдельного решения.
Описание текущей системы и интеграций (если есть). Фиксирует границы системы, точки интеграции и ограничения по данным и интерфейсам.
Ограничения проекта: регуляторные, ИБ, технические, организационные. Учитываются в нефункциональных требованиях и в приёмке, чтобы результат был реализуемым.
Доступ к экспертам (заказчик, ИТ, ИБ, поддержка). Согласование требований с теми, кто их будет реализовывать, эксплуатировать и проверять.
Комплект документов, который вы получаете
Описание услуги — наш стандарт качества: заранее видно, какие документы вы получите и зачем нужен каждый.
Документ | Формат | Для чего нужен |
|---|---|---|
Документ функциональных требований | Markdown/DOCX + версия в базе знаний | Описывает функции, сценарии, роли, правила, данные, интерфейсы и точки интеграции. |
Документ нефункциональных требований | Markdown/DOCX/таблица | Фиксирует производительность, нагрузку, безопасность, отказоустойчивость, доступность и их измеримость. |
Реестр требований | Таблица (Excel/Google Sheets/система) | Единый список требований с ID, приоритетом, источником, статусом и связью с целями. |
Глоссарий и модель данных | Markdown/таблица/схема | Устраняет разное понимание терминов и объектов между бизнесом и разработкой. |
Матрица трассировки | Таблица | Связывает требования с целями, сценариями и тест-кейсами для контроля полноты и приёмки. |
Перечень открытых вопросов и решений | Таблица/чек-лист | Фиксирует нерешённые вопросы, ответственных и принятые решения, снимает неопределённость. |
Протокол согласования требований | DOCX/запись в системе | Фиксирует версию, участников согласования и основание для перехода к реализации. |
План выполнения услуги
Этап | Что делаем | Результат этапа |
|---|---|---|
1. 1. Бриф и рамка | Проводим встречу с заказчиком: цель, границы системы, пользователи, ограничения, критерии успеха. | Зафиксированная рамка проекта и список источников информации. |
2. 2. Изучение контекста | Анализируем процессы, документы, текущую систему, интервьюируем экспертов и пользователей. | Карта процессов, ролей и проблем, список ограничений. |
3. 3. Сбор и структурирование требований | Формулируем функциональные требования по сценариям, ролям, данным и интеграциям. | Черновик функциональных требований с ID и приоритетами. |
4. 4. Разработка нефункциональных требований | Определяем и делаем измеримыми требования по производительности, нагрузке, безопасности, отказоустойчивости, доступности. | Черновик нефункциональных требований с критериями проверки. |
5. 5. Модель данных и глоссарий | Описываем ключевые сущности, атрибуты, связи и единый понятийный аппарат. | Согласованная модель данных и глоссарий. |
6. 6. Трассировка и приоритизация | Связываем требования с целями и сценариями, расставляем приоритеты и отмечаем зависимости. | Матрица трассировки и приоритизированный реестр требований. |
7. 7. Согласование | Проводим ревью с бизнесом, ИТ, ИБ и поддержкой, снимаем замечания и противоречия. | Согласованная версия ФТТ и протокол согласования. |
8. 8. Передача и сопровождение запуска | Передаём комплект документов, проводим разбор для команды, фиксируем порядок изменений требований. | Команда понимает, что делать, и знает, как менять требования управляемо. |
Чек-лист качества
Перед сдачей исполнитель проверяет результат по этому списку:
Каждое требование имеет уникальный ID, формулировку, источник, приоритет и статус.
Функциональные требования описаны через сценарии и роли, а не через общие фразы.
Нефункциональные требования измеримы: есть метрика, условие и способ проверки.
Все ключевые данные и интеграции описаны, включая форматы обмена и ограничения.
Глоссарий покрывает все термины, по которым возможны разночтения.
Матрица трассировки связывает требования с целями и сценариями.
Открытые вопросы и принятые решения зафиксированы с ответственными.
Требования не противоречат друг другу и ограничениям проекта.
Документы согласованы с бизнесом, ИТ, ИБ и поддержкой.
Версия документов зафиксирована, понятен порядок внесения изменений.
Критерии приёмки работ
Работа считается выполненной, когда выполнены все пункты. Критерии фиксируем вместе с расчётом — до начала работ.
Полнота. Проверяется, что каждая цель и сценарий из брифа закрыты требованиями, а матрица трассировки не имеет разрывов.
Однозначность. Проверяется, что требование нельзя прочитать двояко: ревью бизнеса и разработки даёт одинаковую трактовку.
Измеримость нефункциональных требований. Проверяется, что для каждого требования есть метрика, условие и способ проверки.
Согласованность. Проверяется отсутствие противоречий между требованиями, ограничениями и моделью данных.
Готовность к использованию. Проверяется, что по ФТТ можно оценить объём работ, составить бэклог и тест-кейсы без дополнительных уточнений.
Управляемость изменений. Проверяется, что зафиксирован порядок внесения изменений и назначены ответственные за актуальность требований.
На проверку результата — 3 рабочих дня. Замечания в рамках согласованного объёма устраняются без доплаты.
После сдачи: результат остаётся рабочим инструментом
Все материалы остаются в вашем пространстве OrgDevTools — их можно дорабатывать без исполнителя:
База знаний и регламенты. ФТТ, глоссарий и протоколы согласования хранятся в едином пространстве с версиями и правами доступа, команда всегда работает с актуальной версией.
Проекты и задачи. Требования из реестра превращаются в задачи и эпики, статусы и приоритеты синхронизированы с реестром требований.
Процессы (BPMN). Сценарии и процессы, описанные в ФТТ, визуализируются как схемы, по которым удобно проверять полноту и логику требований.
Цифровой двойник. Модель данных и связи требований поддерживаются в цифровом двойнике, что помогает видеть влияние изменений на систему и процессы.
AI-советник OrgDevTools. AI-советник OrgDevTools помогает команде после сдачи: отвечает на вопросы по регламентам и базе знаний, находит нужные требования и связанные с ними процессы, напоминает о правилах внесения изменений. Это снижает зависимость от исполнителя и ускоряет онбординг новых участников.
Чем эта услуга не является
Не является разработкой, внедрением или настройкой системы — это подготовка требований к ней.
Не заменяет проектную документацию, архитектурное проектирование и технический дизайн.
Не включает тестирование, сопровождение и приёмку готовой системы.
Не включает юридическую экспертизу и оценку соответствия регуляторным требованиям — такие требования фиксируются со слов заказчика и профильных экспертов.
Стоимость и сроки
Стоимость рассчитывается после брифа: зависит от масштаба компании, числа подразделений и глубины проработки. Расчёт и состав работ фиксируем до начала — без сюрпризов в конце.
Частые вопросы об услуге «Разработка функциональных и нефункциональных требований (ФТТ)»
Чем ФТТ отличается от ТЗ?
ФТТ — это структурированный набор требований: что система должна делать и каким критериям соответствовать. ТЗ — более широкий документ, который может включать ФТТ, а также условия, порядок работ и приёмки. Мы готовим именно требования, которые становятся основой ТЗ.
Когда нужны нефункциональные требования?
Всегда, если система работает с пользователями, данными и нагрузкой. Без них нельзя проверить производительность, безопасность и отказоустойчивость, а приёмка сводится к субъективным оценкам.
Что если требования изменятся после сдачи?
Мы фиксируем порядок внесения изменений и ответственных. Изменения оформляются как новая версия требований, чтобы команда понимала, что именно поменялось и как это влияет на объём работ.
Можно ли по ФТТ оценить бюджет и сроки разработки?
Да, ФТТ даёт достаточную основу для оценки. Конкретные сроки и стоимость разработки определяет исполнитель после ознакомления с требованиями; стоимость нашей услуги рассчитывается после брифа.
Кто должен участвовать в согласовании?
Бизнес-заказчик, ИТ, информационная безопасность и поддержка. Это те роли, которые будут реализовывать, эксплуатировать и проверять систему.
Как понять, что требования готовы?
По критериям приёмки: полнота, однозначность, измеримость нефункциональных требований, согласованность, готовность к использованию и управляемость изменений. Каждый критерий проверяется на ревью.
Заказать услугу
Опишите задачу в заявке ниже — уточним детали, пришлём расчёт и план работ.