Спецификация требований к программному обеспечению SRS: шаблон, рекомендации, роль и значение в ИТ

Спецификация требований к программному обеспечению является одним из ключевых артефактов разработки ИТ-продукта. Она фиксирует, что именно должна делать система, какие ограничения необходимо учитывать и каким требованиям должен соответствовать результат. В классической разработке такой документ служит ориентиром для аналитиков, архитекторов, разработчиков и тестировщиков, а в современных AI-процессах становится ещё и основным источником контекста для ИИ-агентов.

Что такое спецификация в ИТ

SRS (Software Requirements Specification) — это документ или структурированный набор артефактов, описывающий требования к программному обеспечению. Спецификация связывает бизнес-потребность с конкретным поведением системы и задаёт основу для последующих решений по архитектуре, разработке, тестированию и приёмке.

Спецификация может описывать функциональные и нефункциональные требования, пользовательские сценарии, интерфейсы, ограничения, требования к производительности, безопасности, совместимости и другие характеристики продукта. В зависимости от масштаба проекта она может представлять собой отдельный документ либо набор связанных требований, моделей и других артефактов.

Суть

Суть SRS заключается в том, чтобы превратить потребность бизнеса или пользователя в формализованное описание ожидаемого результата. Вместо общего понимания того, что необходимо создать, команда получает набор требований, по которым можно проектировать систему, реализовывать функции и проверять соответствие результата первоначальным ожиданиям.

Хорошая спецификация отвечает не только на вопрос «что должна делать система», но и фиксирует существенные ограничения и условия. Поэтому спецификация на программное обеспечение становится связующим звеном между бизнес-задачей и технической реализацией.

Расшифровка SRS

Аббревиатура SRS расшифровывается как Software Requirements Specification — «спецификация требований к программному обеспечению». В русскоязычной практике для обозначения близкого по назначению документа также используются понятия техническое задание, спецификация требований, требования к ПО.

SRS следует отличать от проектной и эксплуатационной документации. Она отвечает прежде всего на вопрос о том, каким требованиям должен соответствовать программный продукт, тогда как архитектурные документы описывают устройство системы, а эксплуатационная документация — порядок её использования и сопровождения.

Простыми словами

Если представить разработку программного продукта как строительство здания, SRS — это подробное описание того, что именно должно быть построено и каким требованиям оно должно соответствовать. Пока требования находятся только в разговорах, письмах и отдельных задачах, участники проекта могут по-разному понимать конечный результат.

Спецификация собирает эти договорённости в единый источник. Разработчик понимает, что реализовывать, тестировщик — что проверять, архитектор — какие ограничения учитывать, а заказчик — по каким критериям принимать результат. В этом смысле спецификация программных продуктов снижает неопределённость и количество разночтений между участниками проекта.

Роль и значение в ИТ-проекте

SRS выполняет роль единой точки согласования требований. На её основе могут формироваться архитектурные решения, декомпозироваться задачи, разрабатываться программный код и создаются тестовые сценарии. Чем сложнее продукт и чем больше участников вовлечено в его создание, тем выше значение такого единого источника требований.

Спецификация — это не просто описание будущей системы, а связующий слой между намерением бизнеса, инженерными решениями и проверяемым результатом.

Особенно важна SRS для крупных корпоративных систем, где требования постоянно уточняются, а разработка распределяется между несколькими командами. Для таких проектов спецификация на программный комплекс становится частью управляемого жизненного цикла продукта: изменения требований должны фиксироваться, согласовываться, отслеживаться и отражаться в связанных артефактах.

Разработка спецификации программного обеспечения

Традиционно разработка спецификации была преимущественно человеческой работой. Аналитики собирали требования у бизнеса и пользователей, архитекторы и технические специалисты уточняли ограничения, после чего формировался документ или набор документов. По мере развития проекта спецификация могла неоднократно корректироваться, дополняться и согласовываться.

Проблема классического подхода заключается не столько в создании спецификации, сколько в её дальнейшем жизненном цикле: после нескольких итераций разработки документ часто перестаёт быть актуальным источником истины.

На практике после двух-трёх существенных изменений внимание команды нередко смещается на задачи, код, тестирование и рабочие обсуждения. Спецификация постепенно превращается в архивное описание первоначального замысла, которое уже не полностью соответствует работающей системе. Возникает разрыв между тем, что было задумано, тем, что описано в документации, и тем, что фактически реализовано.

Появление ИИ-агентов меняет эту модель. В AI SDLC и AI PDLC спецификация может перестать быть статическим документом, который человек создаёт в начале проекта и периодически редактирует вручную. ИИ-агент способен постоянно анализировать требования, изменения, архитектурные решения, результаты тестирования и обратную связь, поддерживая спецификацию в актуальном состоянии.

В такой модели спецификация становится главным контекстом для работы ИИ-агентов. Агент разработки получает требования и ограничения из спецификации, агент тестирования использует их для формирования проверок, агент архитектуры — для оценки технических решений, а агент сопровождения — для анализа изменений относительно исходных требований. При этом изменения в реализации могут становиться основанием для актуализации самой спецификации.

Так формируется замкнутый цикл: намерение → спецификация → реализация → проверка → обратная связь → актуализация спецификации. Спецификация перестаёт быть одноразовым результатом аналитической работы и превращается в живой артефакт, который развивается вместе с программным продуктом.

Тренд на Specification-Driven Development (SDD)

Specification-Driven Development (SDD) развивается как подход, в котором спецификация становится центральным артефактом разработки, а программный код — производным результатом её исполнения. Такой подход особенно хорошо сочетается с AI SDLC, поскольку ИИ-агентам необходимо формализованное описание намерения, ограничений и критериев результата.

В традиционной модели значительная часть инженерной ценности сосредоточена непосредственно в коде. В SDD акцент постепенно смещается на качество и полноту спецификации: если результат реализации оказался неверным, предпочтительным объектом корректировки становится не только код, но и исходное описание требований, после чего реализация может быть создана или обновлена заново.

В SDD спецификация становится источником истины, а код — одним из результатов её реализации.

Для Enterprise это означает изменение самого процесса управления разработкой. Спецификация должна быть версионируемой, актуальной, структурированной и доступной контролируемому набору ИИ-агентов. Одновременно необходимо управлять тем, какой контекст получает каждый агент: разработчику нужен один набор сведений, тестировщику — другой, архитектору — третий.

В результате SDD выходит за пределы обычного документа с требованиями. В связке с AI-Disrupt PDLC спецификация становится частью архитектуры разработки и управления контекстом. Чем больше работы передаётся ИИ-агентам, тем выше значение способности организации поддерживать актуальное и структурированное описание намерений продукта.

Практические рекомендации

Хорошая SRS должна быть не просто подробным описанием будущей системы, а рабочим артефактом, с которым могут одинаково работать бизнес, аналитики, разработчики и тестировщики. Требования должны быть однозначными, проверяемыми, связанными с исходными потребностями и достаточно структурированными, чтобы их можно было использовать на следующих этапах жизненного цикла программного продукта.

Формулируйте требования так, чтобы их можно было проверить

Одно из главных требований к SRS — возможность объективно определить, выполнено ли условие. Формулировки вроде «интерфейс должен быть удобным», «система должна работать быстро» или «отчёт должен формироваться оперативно» допускают несколько трактовок. Для разных участников проекта одно и то же требование может означать совершенно разные результаты.

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

Отчёт по продажам за месяц должен формироваться не более чем за 10 секунд
при объёме выборки до 500 000 записей.

Такую формулировку уже можно использовать при проектировании и тестировании. В общем случае каждое существенное требование должно отвечать на вопрос: каким способом будет доказано его выполнение? Это один из базовых признаков качественного требования.

Отделяйте потребность от способа реализации

SRS должна описывать прежде всего что требуется получить от системы, а не заранее навязывать разработчикам конкретный способ реализации. Если техническое решение зафиксировать слишком рано, команда может лишиться возможности выбрать более простой, надёжный или экономичный вариант.

Например, вместо такой записи:

Добавить кнопку «Повторить» в нижней части формы
и реализовать её через отдельный REST-метод.

лучше сформулировать требование через ожидаемое поведение:

Пользователь должен иметь возможность повторно отправить
неуспешно обработанную заявку без повторного ввода данных.

Конкретный элемент интерфейса, API, механизм очередей или способ хранения состояния могут быть определены позже в проектной и архитектурной документации. Такой подход снижает связанность требований с реализацией и позволяет изменять техническое решение без пересмотра исходной потребности.

Разделяйте бизнес-цели и требования к системе

В SRS полезно сохранять различие между результатом, которого хочет добиться бизнес, и поведением программного продукта, необходимым для его достижения. Бизнес-требование отвечает на вопрос о том, зачем нужен проект, а системное — что должна делать система.

Например, бизнес-цель может быть сформулирована следующим образом:

Сократить долю заявок, обрабатываемых более 24 часов,
с 18% до 5%.

Связанные с ней системные требования могут выглядеть так:

Система должна автоматически назначать заявку ответственному
сотруднику не позднее 30 секунд после её регистрации.

Система должна отправлять руководителю уведомление,
если заявка находится без обработки более 8 часов.

Разделение уровней помогает сохранить связь между целями бизнеса и конкретными функциями программного продукта. При этом одно бизнес-требование может быть реализовано несколькими системными требованиями, а изменение бизнес-цели должно позволять быстро определить, какие элементы SRS затронуты.

Присваивайте требованиям устойчивые идентификаторы

В небольшой спецификации требования ещё можно находить по заголовкам и поиску по тексту. В крупном проекте такой подход быстро перестаёт работать. Поэтому каждому требованию следует присваивать уникальный и сохраняющийся идентификатор.

Например, для разных типов требований можно использовать собственную систему обозначений:

BUS-014 — бизнес-требование
FUN-027 — функциональное требование
QAL-009 — требование к качеству
DAT-016 — требование к данным
INT-011 — требование к интеграции

Идентификатор позволяет связать требование с задачей в backlog, архитектурным решением, тест-кейсом, дефектом или результатом приёмки. Такой подход формирует трассируемость и помогает увидеть, какие требования реализованы, проверены или изменены.

Определяйте границы каждого требования

Даже формально правильное требование может оказаться слишком широким. Если одна запись описывает сразу несколько функций, ролей, условий и исключений, становится сложно определить, что именно было изменено и что именно необходимо проверить.

Например, вместо одного большого требования:

Система должна обеспечивать работу менеджера с заказами,
включая создание, изменение, поиск, согласование,
отмену и формирование отчётов.

лучше выделить несколько самостоятельных требований. Тогда каждое из них можно отдельно приоритизировать, реализовать и проверить:

FUN-041. Пользователь должен иметь возможность создать заказ.

FUN-042. Пользователь должен иметь возможность изменить заказ
до момента его передачи на согласование.

FUN-043. Пользователь должен иметь возможность найти заказ
по номеру, клиенту или периоду создания.

Декомпозиция не должна превращать SRS в набор чрезмерно мелких технических указаний. Цель состоит в том, чтобы каждое требование описывало самостоятельное проверяемое поведение или характеристику системы.

Связывайте требования с их источником и результатом

Полезно фиксировать не только само требование, но и его происхождение: бизнес-цель, потребность пользователя, нормативное ограничение, договорное условие или другое требование более высокого уровня. В дальнейшем это позволяет понять, зачем вообще существует конкретная запись в SRS.

Например, требование к автоматическому уведомлению можно связать с бизнес-целью по сокращению времени обработки заявки, а затем — с задачей разработки и тестом:

BUS-014 → FUN-027 → DEV-1834 → TEST-092 → результат приёмки

Такая цепочка особенно полезна при изменениях. Если бизнес-цель отменяется или меняется, команда может быстро определить, какие функции, задачи и тесты больше не нужны либо требуют пересмотра. Двунаправленная трассируемость также помогает обнаруживать функциональность, которая появилась в системе без понятного исходного требования.

Описывайте не только штатную работу, но и исключения

Типичная ошибка SRS — подробно описывать успешный сценарий и почти не фиксировать поведение системы при отклонениях. На практике именно такие ситуации часто становятся источником дефектов и споров между заказчиком и исполнителем.

Для каждой значимой функции стоит определить, что происходит, если пользователь допустил ошибку, внешняя система недоступна, данные не прошли проверку или операция была выполнена параллельно другим пользователем.

Например:

При недоступности сервиса проверки контрагента
система не должна завершать оформление договора.
Пользователю выводится сообщение о временной недоступности,
а операция сохраняется в статусе «Требует проверки».

Отдельное описание исключительных сценариев делает спецификацию более полной и одновременно облегчает подготовку негативных тестов. Для требований к надёжности особенно важно заранее определить обнаружение ошибки, реакцию системы и возможность восстановления.

Не смешивайте требования с проектной документацией и обсуждениями

По мере работы над проектом SRS легко превращается в архив всей связанной информации. В неё начинают переносить протоколы встреч, коммерческие предложения, переписку, альтернативные архитектурные решения и идеи, которые ещё никто не утвердил.

В результате документ становится большим, но не более полезным. В самой SRS целесообразно оставлять актуальный набор согласованных требований, а сопутствующую информацию распределять по соответствующим артефактам: схемы и модели — в приложениях или проектной документации, задачи — в backlog, решения — в журнале архитектурных решений, обсуждения — в протоколах.

При этом ссылки между артефактами должны сохраняться. SRS не обязана содержать всю информацию о проекте, но должна позволять быстро перейти к материалу, который объясняет конкретное требование или решение.

Фиксируйте критерии приёмки одновременно с требованием

Требование без критерия приёмки оставляет пространство для субъективной оценки. Исполнитель может считать задачу завершённой, поскольку функция работает, а заказчик — неудовлетворённым, потому что ожидал другого поведения.

Поэтому для существенных требований стоит сразу определять условия, при которых оно считается выполненным. Например:

Требование: пользователь должен иметь возможность отменить заказ
до момента его передачи в доставку.

Критерий приёмки:
если заказ находится в статусе «Новый» или «Подтверждён»,
операция отмены доступна пользователю;
после передачи заказа в доставку операция отмены недоступна.

Критерии приёмки могут непосредственно использоваться при подготовке тестов. Это сокращает расстояние между SRS и проверкой готового продукта и позволяет ещё на этапе анализа обнаружить неоднозначные формулировки.

Ведите единый словарь терминов

Одинаковые слова в разных частях проекта должны обозначать одно и то же. Если в одном разделе используется «клиент», в другом «заказчик», а в третьем «контрагент», необходимо определить, являются ли это синонимами или разными сущностями.

Для этого в SRS полезно иметь глоссарий с ключевыми понятиями, сокращениями, статусами и специфическими терминами предметной области. Например:

Заявка — зарегистрированное обращение клиента,
имеющее уникальный номер и текущий статус обработки.

Исполнитель — сотрудник, которому назначена заявка
для выполнения основного действия по ней.

Единый словарь особенно важен для больших команд и AI SDLC. И человек, и ИИ-агент должны одинаково интерпретировать названия сущностей, ролей и состояний. Это снижает риск того, что один и тот же термин будет использован в разных значениях при анализе требований, генерации кода или подготовке тестов.

Поддерживайте SRS как изменяемый, но контролируемый артефакт

Спецификация не должна рассматриваться как документ, который один раз согласовали и больше не открывали. В реальном проекте меняются бизнес-процессы, интерфейсы, интеграции, нормативные требования и приоритеты. Поэтому каждое существенное изменение должно иметь версию, автора, дату, причину и понятный статус согласования.

При этом важно не просто хранить историю изменений, а оценивать их последствия. Изменение одного требования может затронуть архитектуру, код, интеграции, тесты и пользовательскую документацию. Чем лучше построена трассируемость, тем быстрее команда сможет определить масштаб такого воздействия.

Для AI SDLC этот принцип становится ещё важнее. Если SRS является основным источником контекста для ИИ-агентов, устаревшая спецификация способна привести к генерации неверного кода, тестов или документации. Поэтому перспективная модель предполагает живую спецификацию, которая постоянно синхронизируется с изменениями продукта и используется как актуальный источник контекста для последующих этапов разработки.

Шаблон спецификации

Универсального состава SRS для всех проектов нет: для крупной корпоративной системы, отдельного модуля и небольшого доработочного проекта целесообразно использовать разные варианты шаблона.

При этом структура должна оставаться достаточно стабильной, чтобы участники проекта понимали, где искать нужную информацию. Внутри документа не следует дублировать одни и те же сведения в нескольких разделах — лучше использовать перекрёстные ссылки.

1. Общая информация о документе

Первый раздел идентифицирует сам документ и объясняет, для какого продукта он подготовлен. Здесь также фиксируются правила оформления, версия спецификации и круг участников, которые отвечают за её содержание и согласование.

1.1. Название и назначение

Указывается полное название программного продукта, системы, подсистемы или конкретного релиза. Если SRS относится только к части крупной системы, необходимо обозначить её границы и связь с остальными компонентами.

В этом же разделе фиксируется назначение документа: для кого он подготовлен и какие задачи должен решать. SRS может использоваться бизнес-заказчиком, аналитиками, архитекторами, разработчиками, тестировщиками, руководителями проекта и специалистами сопровождения.

Название продукта:
Корпоративная система управления заявками

Назначение документа:
Спецификация описывает требования к модулю регистрации,
маршрутизации и контроля исполнения заявок клиентов.
Документ используется для проектирования, разработки,
тестирования и приёмки версии 2.0.

1.2. Соглашения и правила оформления

Здесь описываются правила, по которым оформляется SRS: система нумерации, обозначения типов требований, используемые термины, правила выделения обязательных и справочных сведений, формат таблиц и диаграмм.

Единые соглашения особенно важны для больших документов. Они позволяют добавлять новые требования без изменения логики нумерации и облегчают последующую обработку спецификации как структурированного источника данных.

FUN — функциональное требование
NFR — нефункциональное требование
DAT — требование к данным
INT — требование к интеграции
BRL — бизнес-правило

Формат идентификатора:
[тип]-[трёхзначный номер]

1.3. Версии документа

Вместо создания множества файлов с названиями вроде «SRS_final», «SRS_final_2» и «SRS_точно_финал» историю документа лучше вести непосредственно в SRS. Для каждой версии фиксируются номер, дата, автор, характер изменения и основание для него.

ID	Версия	Дата	Автор	Изменение	Основание
VER-001	0.1	12.03.2026	Аналитик	Создан первоначальный вариант	Старт сбора требований
VER-002	0.2	18.03.2026	Аналитик	Добавлены требования к маршрутизации	Результаты интервью с бизнесом
VER-003	1.0	25.03.2026	Владелец продукта	Версия согласована	Протокол согласования №12

1.4. Участники и согласование

Необходимо определить участников, которые формируют, проверяют и утверждают требования. При этом не обязательно включать в список всех сотрудников проекта: важно зафиксировать тех, кто имеет отношение к принятию решений.

ID	Участник	Роль	Ответственность	Статус
PAR-001	Иванов А.А.	Владелец продукта	Определяет бизнес-приоритеты и утверждает требования	Утверждает
PAR-002	Петрова Е.С.	Бизнес-аналитик	Формирует и актуализирует SRS	Подготавливает
PAR-003	Сидоров М.В.	Архитектор	Проверяет архитектурные ограничения и интеграции	Согласует
PAR-004	Кузнецова О.В.	Руководитель тестирования	Проверяет тестируемость требований	Согласует

2. Назначение и границы проекта

Этот раздел определяет, какую проблему решает программный продукт, для кого он создаётся и где заканчивается его область ответственности. Чёткие границы позволяют не допустить неконтролируемого расширения проекта.

2.1. Цель документа и проекта

Необходимо кратко описать бизнес-проблему и назначение создаваемого программного продукта. Формулировка должна быть понятна не только техническим специалистам.

Цель проекта:
сократить среднее время обработки клиентской заявки
с 36 до 12 часов за счёт автоматической маршрутизации,
контроля сроков и уведомления ответственных сотрудников.

2.2. Границы проекта

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

ID	Область	Входит в проект	Не входит в проект
SCP-001	Регистрация заявок	Создание, редактирование и поиск заявок	Регистрация обращений через голосового бота
SCP-002	Маршрутизация	Автоматическое назначение ответственного	Оптимизация маршрутов выездных сотрудников
SCP-003	Отчётность	Операционные отчёты по заявкам	Корпоративное хранилище данных

2.3. Ссылки и связанные материалы

Здесь перечисляются документы, стандарты, регламенты, спецификации интерфейсов, архитектурные документы и другие материалы, на которые опирается SRS. Не следует копировать их содержимое в спецификацию без необходимости.

Для каждого внешнего материала желательно указывать название, версию, дату и место хранения. При изменении внешнего документа необходимо проверить, не повлияло ли это на требования SRS.

3. Общее описание системы

Раздел даёт целостное представление о продукте до перехода к отдельным требованиям. Здесь описываются контекст системы, её окружение, пользователи, основные процессы, ограничения реализации и зависимости.

3.1. Краткое описание продукта

Нужно простыми словами объяснить, что делает система и какое место она занимает в ИТ-ландшафте. Для нового продукта можно описать его назначение, а для замены существующего — указать, какую систему он заменяет и почему.

Система предназначена для централизованного управления
клиентскими заявками. Она принимает обращения из CRM,
распределяет их между исполнителями, контролирует сроки
и передаёт результаты обработки обратно в CRM.

3.2. Пользователи и роли

Роли следует описывать через реальные рабочие задачи и права. Абстрактная роль «пользователь» мало помогает при проектировании доступа и функциональности.

ID	Роль	Назначение	Основные действия	Доступ
USR-001	Оператор	Регистрация обращений	Создаёт и редактирует заявки	Только свои подразделения
USR-002	Исполнитель	Обработка заявок	Принимает заявки, меняет статусы, добавляет результат	Назначенные заявки
USR-003	Руководитель	Контроль работы подразделения	Просматривает заявки и отчёты	Все заявки подразделения
USR-004	Администратор	Настройка системы	Управляет ролями, справочниками и параметрами	Полный административный

3.3. Основные бизнес-процессы

Перечисляются процессы, которые должна поддерживать система. Для сложных решений к описанию можно добавить BPMN-диаграммы, карты процессов или таблицы последовательности операций.

1. Регистрация обращения.
2. Проверка данных.
3. Определение ответственного подразделения.
4. Назначение исполнителя.
5. Выполнение работы.
6. Контроль срока.
7. Закрытие обращения.
8. Формирование отчётности.

3.4. Операционная среда

Описывается окружение, в котором будет работать программный продукт: операционные системы, браузеры, серверная инфраструктура, базы данных, сетевое окружение и другие программные компоненты.

Клиентская часть:
Chrome и Edge — две последние стабильные версии.

Серверная часть:
Linux, контейнерная среда, PostgreSQL.

Интеграционная среда:
корпоративная шина обмена сообщениями.

3.5. Ограничения реализации

Здесь фиксируются ограничения, которые действительно влияют на возможные способы реализации: обязательная технологическая платформа, корпоративные стандарты, требования инфраструктуры, нормативные ограничения или необходимость совместимости с существующими системами.

При этом не следует превращать требования в заранее выбранные технические решения без объективной причины. Ограничение должно иметь понятное основание.

3.6. Допущения и зависимости

Допущения фиксируют условия, которые считаются выполненными при подготовке требований. Зависимости показывают, от каких внешних систем, команд, данных или инфраструктуры зависит работа продукта.

Допущение:
справочник сотрудников будет предоставляться заказчиком
в согласованном формате.

Зависимость:
авторизация пользователей выполняется через корпоративный
сервис единого входа.

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

Функциональные требования составляют центральную часть SRS. Они описывают конкретное поведение системы: какие действия она выполняет, какие данные обрабатывает, как реагирует на действия пользователей и что происходит в штатных и исключительных сценариях.

4.1. Таблица функциональных требований

Для крупных систем требования удобно группировать по функциям, бизнес-процессам, пользовательским ролям или подсистемам. Каждый вариант допустим, если выбранная структура помогает быстро находить нужное требование.

ID	Функция	Требование	Приоритет	Критерий приёмки
FUN-001	Создание обращения	Система должна позволять оператору зарегистрировать обращение с указанием клиента, темы и описания.	Высокий	После сохранения создаётся уникальный номер обращения.
FUN-002	Маршрутизация	Система должна автоматически назначать обращение подразделению по категории обращения.	Высокий	Для каждой категории определяется соответствующее подразделение.
FUN-003	Поиск	Система должна позволять искать обращения по номеру, клиенту и статусу.	Средний	Результаты поиска соответствуют заданным параметрам.
FUN-004	Уведомления	Система должна уведомлять исполнителя о назначении нового обращения.	Средний	Уведомление формируется не позднее 60 секунд после назначения.

4.2. Сценарии и исключения

Для сложных функций необходимо описывать предусловия, основной сценарий, альтернативные сценарии и реакцию на ошибки. Например, если внешний сервис недоступен, SRS должна определять, повторяется ли запрос, сохраняется ли операция в очереди и что видит пользователь.

Основной сценарий:
1. Оператор открывает форму обращения.
2. Выбирает клиента.
3. Указывает категорию.
4. Вводит описание.
5. Система проверяет данные.
6. Система сохраняет обращение.

Исключительный сценарий:
если сервис проверки клиента недоступен,
система сохраняет обращение со статусом «Ожидает проверки».

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

Нефункциональные требования описывают характеристики продукта: производительность, доступность, безопасность, масштабируемость, удобство использования, сопровождаемость и другие свойства. Они должны быть сформулированы так, чтобы их можно было измерить или проверить.

5.1. Таблица нефункциональных требований

ID	Категория	Требование	Критерий проверки
NFR-001	Производительность	Форма списка обращений должна открываться не более чем за 2 секунды при наличии до 100 000 записей.	Время открытия не превышает 2 секунд.
NFR-002	Доступность	Система должна обеспечивать доступность не менее 99,5% в течение календарного месяца.	Показатель подтверждается журналом мониторинга.
NFR-003	Безопасность	Пользователь не должен иметь доступа к обращениям, не входящим в область его полномочий.	Проверка выполняется для каждой роли.
NFR-004	Масштабируемость	Система должна поддерживать увеличение количества активных пользователей до 2 000 без изменения прикладной логики.	Проводится нагрузочное тестирование.

5.2. Основные категории качества

В зависимости от продукта могут отдельно описываться производительность, доступность, надёжность, безопасность, удобство использования, масштабируемость, сопровождаемость, переносимость, аудит и другие характеристики.

Формулировка «интерфейс должен быть удобным» недостаточна. Например, требование можно заменить на конкретные условия: основные операции выполняются не более чем за четыре действия, сообщения об ошибках содержат причину и способ исправления, а форма поддерживает клавиатурную навигацию.

6. Требования к данным

В этом разделе описывается, какие данные система получает, хранит, изменяет, передаёт и удаляет. Важно отделять логическую модель данных от физической реализации базы данных: SRS должна прежде всего описывать объекты и их свойства, а не структуру конкретных таблиц БД.

6.1. Сущности

ID	Сущность	Назначение	Связи	Жизненный цикл
ENT-001	Обращение	Хранение информации о запросе клиента	Связано с клиентом и исполнителем	Создано → В работе → Закрыто
ENT-002	Клиент	Идентификация заявителя	Имеет множество обращений	Активен → Архивирован
ENT-003	Исполнитель	Сотрудник, выполняющий обращение	Связан с подразделением	Активен → Неактивен

6.2. Поля и атрибуты

ID	Сущность	Поле	Тип	Обязательность	Правило
FLD-001	Обращение	Номер	Строка	Да	Уникальный идентификатор
FLD-002	Обращение	Дата создания	Дата/время	Да	Заполняется системой автоматически
FLD-003	Обращение	Категория	Справочник	Да	Значение выбирается из утверждённого справочника
FLD-004	Обращение	Комментарий	Текст	Нет	До 4 000 символов

6.3. Получение, целостность, хранение и удаление данных

Необходимо определить источники данных, правила их проверки, резервного копирования, хранения, архивирования и удаления. Для интеграционных данных важно отдельно описать, какая система считается источником мастер-данных.

6.4. История изменений

ID	Событие	Что фиксируется	Кто имеет доступ	Срок хранения
HIS-001	Создание обращения	Автор, дата, исходные значения	Оператор, руководитель, администратор	3 года
HIS-002	Изменение статуса	Старый и новый статус, автор, дата	Руководитель, администратор	3 года
HIS-003	Изменение исполнителя	Предыдущий и новый исполнитель	Руководитель, администратор	3 года

6.5. Отчёты

Если система формирует отчёты, здесь перечисляются их назначение, состав показателей, фильтры, группировки, правила сортировки и периодичность обновления. Детальный визуальный макет можно вынести в приложение.

7. Требования к интерфейсам

Интерфейсы определяют, каким образом пользователь и внешние компоненты взаимодействуют с системой. Для сложных решений их следует описывать отдельно от внутренней реализации.

7.1. Пользовательский интерфейс

ID	Экран	Назначение	Основные элементы	Результат
UI-001	Список обращений	Просмотр и поиск обращений	Фильтры, таблица, сортировка, поиск	Список соответствует заданным условиям
UI-002	Карточка обращения	Просмотр и изменение обращения	Данные клиента, статус, комментарии	Изменения сохраняются с фиксацией автора
UI-003	Отчёты	Анализ работы подразделения	Фильтры, показатели, экспорт	Формируется отчёт за выбранный период

7.2. Программные и коммуникационные интерфейсы

Для каждого интерфейса фиксируются назначение, участники обмена, формат данных, направление передачи, правила обработки ошибок и требования к безопасности. Если интерфейс сложный, его детальное описание можно вынести в отдельную спецификацию.

8. Интеграции

Интеграционные требования лучше выделять отдельно, поскольку взаимодействие с внешними системами часто является одним из главных источников рисков проекта. Важно определить не только сам факт интеграции, но и состав передаваемых данных, владельца данных и правила обработки сбоев.

ID	Система	Назначение	Объекты обмена	Источник данных	Способ обмена
INT-001	CRM	Получение клиентских обращений	Клиент, обращение	CRM	REST API
INT-002	ERP	Получение сведений о заказах	Заказ, статус заказа	ERP	Очередь сообщений
INT-003	Корпоративный каталог	Авторизация пользователей	Учетная запись, роль	Каталог	LDAP/SSO

9. Бизнес-правила

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

ID	Правило	Условие	Результат	Приоритет
BRL-001	Ограничение закрытия	Обращение не имеет результата обработки	Закрытие обращения запрещено	Высокий
BRL-002	Маршрутизация VIP-клиента	Клиент имеет специальный признак	Обращение направляется выделенной группе	Высокий
BRL-003	Контроль срока	До окончания SLA осталось менее 2 часов	Руководителю отправляется предупреждение	Средний

10. Ограничения и допущения

Ограничения фиксируют условия, которые команда не может свободно изменить. Допущения отражают то, что считается истинным на момент разработки требований. Разделение этих понятий помогает выявлять проектные риски до начала разработки.

10.1. Ограничения

• система разворачивается в инфраструктуре заказчика;
• не допускается изменение типовой конфигурации ERP;
• обработка персональных данных выполняется в соответствии с корпоративными и нормативными требованиями;
• клиентская часть должна работать в утверждённых браузерах;
• система должна использовать существующий корпоративный механизм аутентификации.

10.2. Допущения и зависимости

• заказчик предоставляет тестовые данные до начала интеграционного тестирования;
• структура справочника подразделений не изменяется до запуска первой версии;
• внешняя система предоставляет API с согласованным уровнем доступности;
• пользователи проходят обучение до промышленного запуска.

11. Приоритеты требований

Приоритет позволяет определить, какие возможности являются обязательными для релиза, а какие могут быть перенесены. Не стоит присваивать максимальный приоритет всем требованиям: если всё является критически важным, приоритизация перестаёт выполнять свою функцию.

Приоритет	Значение	Пример
Критический	Без требования система не может выполнять основное назначение	Регистрация обращения
Высокий	Необходимо для полноценной работы основного сценария	Автоматическая маршрутизация
Средний	Важно для эффективности, но допускает временный обходной сценарий	Расширенный поиск
Низкий	Дополнительная возможность	Экспорт отчёта в дополнительный формат

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

Критерии приёмки определяют, каким способом будет подтверждено выполнение требований. Их следует формировать одновременно с требованиями, а не оставлять на конец проекта.

Требование:
пользователь может отменить обращение до начала его исполнения.

Критерии приёмки:
1. Для обращения в статусе «Новое» доступна операция отмены.
2. После отмены статус меняется на «Отменено».
3. В истории сохраняются автор и время операции.
4. Для обращения в статусе «В работе» операция недоступна.

13. Матрица трассируемости

Матрица показывает связь между бизнес-целями, требованиями, задачами разработки и тестами. Она особенно полезна в крупных проектах, где количество требований и связанных с ними артефактов становится значительным.

Пример матрицы:

Бизнес-цель	Требование	Задача	Тест	Статус
Сократить время обработки	FUN-002	DEV-314	QA-088	Выполнено
Снизить количество ошибок	NFR-003	DEV-327	QA-104	На проверке
Повысить прозрачность работы	FUN-004	DEV-341	QA-119	Запланировано

14. Глоссарий

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

ID	Термин	Определение	Примечание
GLS-001	Обращение	Зарегистрированный запрос клиента, обрабатываемый системой.	Основная сущность системы
GLS-002	Исполнитель	Сотрудник, которому назначено выполнение обращения.	Имеет соответствующую роль
GLS-003	SLA	Согласованный показатель или набор условий, определяющих допустимые сроки обслуживания.	Используется в правилах контроля сроков

15. Локализация и интернационализация

Если продукт потенциально используется в разных регионах, необходимо заранее определить требования к языкам, форматам дат и времени, валютам, часовым поясам, адресам, телефонным номерам и другим региональным параметрам.

Язык интерфейса: русский.

Формат даты: ДД.ММ.ГГГГ.

Время: 24-часовой формат.

Часовой пояс:
определяется настройкой подразделения пользователя.

16. Мониторинг, аудит и журналирование

Для корпоративных систем важно определить, какие события должны фиксироваться и какие показатели необходимо контролировать. Это может включать ошибки интеграций, действия пользователей, изменение прав доступа, критические операции и показатели производительности.

Система должна фиксировать:
— вход и выход пользователя;
— изменение прав доступа;
— изменение статуса обращения;
— удаление данных;
— ошибки интеграционного обмена.

Для каждой записи аудита фиксируются:
дата, время, пользователь, операция и объект изменения.

17. Миграция и переход с существующей системы

Если новый продукт заменяет существующее решение, в SRS необходимо определить требования к переносу данных и переходу на новую систему. Следует заранее определить состав мигрируемых данных, правила преобразования и требования к проверке результата.

В новую систему переносятся обращения,
созданные за последние 24 месяца.

Не переносятся технические журналы и временные записи.

После миграции количество перенесённых обращений
должно совпадать с количеством записей,
прошедших контроль в исходной системе.

18. Приложения

В приложения выносятся материалы, которые дополняют SRS, но не должны перегружать основной текст. При этом приложение остаётся частью комплекта требований и должно иметь собственную версию, если оно влияет на понимание требований.

18.1. Модели и диаграммы

• BPMN-диаграммы бизнес-процессов;
• контекстные диаграммы;
• диаграммы состояний;
• ER-диаграммы;
• UML-модели;
• карты интеграций.

18.2. Макеты и дополнительные материалы

• прототипы экранов;
• примеры отчётов;
• спецификации API;
• таблицы справочников;
• примеры входных и выходных сообщений;
• дополнительные нормативные и технические материалы.

При этом SRS не должна становиться хранилищем всей проектной документации. Если отдельный материал уже существует, рациональнее дать на него устойчивую ссылку и сохранить в самой спецификации только информацию, необходимую для понимания требования.

19. Рекомендуемая логика использования шаблона

На практике SRS целесообразно строить как единый структурированный источник требований, а не как большой текстовый документ, который создаётся в начале проекта и затем перестаёт обновляться. Требования должны быть связаны между собой, иметь идентификаторы, приоритеты, критерии приёмки и историю изменений.

Для AI SDLC такой подход приобретает дополнительное значение. Структурированная SRS может использоваться не только аналитиками и разработчиками, но и ИИ-агентами как источник контекста: отдельные агенты получают требования, связанные с конкретной функцией, интерфейсом, интеграцией или тестом. Поэтому требования к структуре SRS постепенно выходят за рамки удобства чтения документа и становятся частью архитектуры самого процесса разработки.