Спецификация требований (requirements specification) — мост между выявлением и реализацией: она фиксирует договорённости в форме, понятной бизнесу, разработке и тестированию. Предшествует ей выявление требований (elicitation) — см. ветку 02.02.01 Интервьюирование и анкетирование и соседние техники в разделе 02.02. Выбор формата — SRS, Use Case или User Story — зависит от методологии, регуляторики и зрелости команды, но цель одна: однозначность, проверяемость и прослеживаемость. Статья описывает три базовые формы фиксации после анализа и показывает, как они сочетаются на одном проекте.

1. Суть темы

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

Цели спецификации:

Бизнес-требования (БТ) и спецификация. БТ — «зачем» и «что нужно бизнесу» — обычно остаются в Vision & Scope, BRD и смежных документах верхнего уровня. В SRS, FRD и нумерованные FR/NFR попадают производные функциональные и нефункциональные требования после анализа и декомпозиции — см. 02.03.01 Классификация требований (БТ, ФТ, НФТ). Писать в SRS формулировки в стиле «бизнес хочет повысить лояльность» вместо проверяемых FR — типичная ошибка новичка: цель спецификации — перевести БТ в однозначные ФТ/НФТ, а не дублировать мотивацию.

Три распространённые формы спецификации на уровне продукта:

ФормаСуть
SRS (Software Requirements Specification)Централизованный документ с полным набором требований
Use Case (вариант использования)Сценарное описание достижения цели актором
User Story (пользовательская история)Лёгкая Agile-карточка с фокусом на ценность и диалог

Рядом живёт Job Story — смежный формат карточки, не четвёртая «классическая» форма в том же ряду; сравнение с User Story — в 04.02 Пользовательские истории (User Stories) и Job Stories.

Рамка для User Story. В этой статье все три формы рассматриваются как способы фиксации требований после анализа. User Story при этом — прежде всего артефакт бэклога для планирования итераций: карточка + обсуждение + критерии приёмки (Acceptance Criteria), а не замена формальной спецификации в регулируемых проектах. Классики Agile прямо говорят, что истории — цели и placeholder для разговора, а не исчерпывающий каталог «система должна…». На практике команда либо дополняет бэклог опорным SRS/Use Cases, либо принимает риск недодокументированности — выбор контекста см. 04.03 Use Case vs User Story — выбор подхода.

Место SRS среди других документов. SRS — не единственный «верхний» артефакт: до него обычно идут Vision & Scope, BRD, FRD и смежные форматы верхнего уровня. FRD (Functional Requirements Document) часто выступает функциональным слоем или приложением к SRS — детали имён и разделов в 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD). Здесь — как фиксировать требования внутри выбранной формы, а не полная структура каждого документа.

Технические спецификации (контракты API, OpenAPI, AsyncAPI) — другой вид «спецификации» на стыке SA; см. 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf).

2. Ключевые понятия

SRS (Software Requirements Specification)

SRS — структурированное описание требований к программной системе. Исторически опирался на IEEE 830 (снят); актуальная опора — ISO/IEC/IEEE 29148:2018 — см. 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148).

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

Типовая структура (ISO 29148, обзорно):

  1. Введение (цели, область, определения).
  2. Общее описание (контекст, пользователи, допущения).
  3. Конкретные требования: функциональные и нефункциональные (02.03.01 Классификация требований (БТ, ФТ, НФТ)), интерфейсы. Сквозные NFR (performance, security, compliance) — с классификацией и стандартами в 08.02 Нефункциональные требования (НФТ) — классификация и стандарты.
  4. Приложения (модели, словарь данных).

Альтернатива монолитному SRS — шаблон Volere (Robertson): структурированный набор разделов вместо одного документа «с нуля». Детали формата и лицензирования — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD).

Пример фрагмента:

FR-08: Расчёт стоимости доставки Система должна рассчитывать стоимость доставки заказа на основе веса, габаритов, индекса получателя и выбранной службы доставки. Входные данные: массив товаров корзины, адрес доставки. Выходные данные: массив доступных способов доставки с указанием стоимости и срока. Бизнес-правило: если сумма заказа > 5000 руб., доставка Почтой России — 0 руб. Исключения: при отсутствии покрытия адреса возвращать ошибку DEL-001.

Идентификаторы вида FR-08, UC-05 задают якорь для 02.03.04 Трассировка требований (концепция) и 10.01.15 Шаблон матрицы трассировки.

Когда применять: фиксированный scope и бюджет (05.01 Waterfall и V-model), регулируемые отрасли, сложные системы с множеством взаимосвязей.

Use Case (вариант использования)

Use Case — текстовое описание последовательностей взаимодействия актора (пользователя или внешней системы) с системой для достижения конкретной цели (определение Алистера Коберна).

Связь с FR. Текст Use Case редко заменяет нумерованные FR в регулируемых проектах: чаще дополняет их, раскрывает ветвления и питает тест-сценарии. SRS и Use Case — не взаимозаменяемые формы одного уровня детализации, а пара «атомарное требование ↔ сценарий поведения».

Уровни детализации (Коберн):

  • Brief (краткий): один абзац — основной успешный сценарий.
  • Casual (неформальный): несколько полей в произвольной форме.
  • Fully Dressed (полный): все потоки, пред- и постусловия — шаблон: 10.01.02 Шаблон Use Case.

Структура полного Use Case:

  • Имя и ID, акторы, цель, предусловия, постусловия.
  • Основной успешный сценарий (Main Flow).
  • Альтернативные и исключительные потоки.
  • Специальные требования (локальные НФТ для этого UC).

Пример фрагмента:

UC-05: Оформление заказа Актор: Зарегистрированный покупатель. Предусловие: покупатель авторизован, в корзине есть товары. Основной поток:

  1. Покупатель нажимает «Оформить заказ».
  2. Система отображает форму с адресом доставки и списком товаров.
  3. Покупатель подтверждает адрес, выбирает способ доставки.
  4. Система рассчитывает стоимость доставки.
  5. Покупатель выбирает способ оплаты и нажимает «Оплатить».
  6. Система перенаправляет на страницу платёжного шлюза. Альтернативный поток (3a): адрес вне зоны доставки — система информирует и предлагает изменить адрес. Постусловие: заказ создан в статусе «Ожидает оплату».

Когда применять: сложные сценарии с ветвлениями и исключениями; нужна связь с UML — 03.02.01 Диаграмма прецедентов (Use Case Diagram). Для тяжёлых потоков с параллельными ветками иногда дополняют текст диаграммой деятельности — 03.02.02 Диаграмма деятельности (Activity Diagram).

У классического Use Case нет обязательного блока Acceptance Criteria — проверяемость обеспечивается через потоки, связанные FR и тест-кейсы.

User Story (пользовательская история)

User Story — краткое описание функциональности с точки зрения пользователя, сфокусированное на ценности.

Классический шаблон (Kent Beck, XP):

Как {роль пользователя}, я хочу {действие/возможность}, чтобы {ценность/цель}.

Пример:

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

Три составляющие (3C, Ron Jeffries):

  • Card (карточка): краткая формулировка — якорь для обсуждения, не спецификация.
  • Conversation (обсуждение): детали выясняются в диалоге команды и стейкхолдеров.
  • Confirmation (подтверждение): Acceptance Criteria — делают историю тестируемой. Форматы (rule-oriented, Gherkin/BDD) и практика написания — 02.04.02 Критерии приёмки (Acceptance Criteria).

НФТ в User Story. Истории плохо переносят сквозные нефункциональные свойства; их выносят в отдельные записи, раздел SRS или шаблон NFR — 02.03.01 Классификация требований (БТ, ФТ, НФТ), 08.02 Нефункциональные требования (НФТ) — классификация и стандарты, 10.01.12 Шаблон нефункциональных требований (NFR). Подробнее о форматах и Job Stories — 04.02 Пользовательские истории (User Stories) и Job Stories; шаблон карточки — 10.01.01 Шаблон User Story.

Когда применять: итеративная разработка (05.02 Scrum и Kanban (аналитик в Agile)), продуктовые команды с высокой неопределённостью.

3. Как применяется в работе аналитика

В спецификацию попадает уже отобранное и приоритизированное — после MoSCoW, WSJF или иной техники из 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано). Фиксация без приоритизации раздувает объём и затрудняет согласование.

Сравнение форматов

КритерийSRSUse CaseUser Story
ФокусПолный набор функций системыЦель актора и сценарий достиженияЦенность для пользователя
ДетализацияВысокаяСредняя–высокая (потоки и исключения)Низкая–средняя (детали — в обсуждении и AC)
ФормаДокумент-монолитСтруктурированный текст + диаграммаКарточка + Acceptance Criteria
Гибкость при измененияхНизкаяСредняяВысокая
ТрассируемостьПолная (явные ID и связи)UC → FR / тест-кейсы / сценарииStory → AC → тест (часто через RM-инструменты — 02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence))
Типичный контекстWaterfall, регулируемые системыЛюбая методология, сложные потокиAgile, Lean

Job Story в таблицу не включена: это альтернатива формулировки карточки, а не отдельный уровень спецификации — см. 04.02 Пользовательские истории (User Stories) и Job Stories.

Сосуществование форматов на одном проекте

На практике форматы не исключают друг друга и не выстраиваются в жёсткую иерархию «сверху вниз»:

  • Waterfall / enterprise: Vision & Scope или BRD → SRS с нумерованными FR/NFR; Use Cases — для самых сложных потоков; User Stories могут не использоваться.
  • Agile: бэклог из User Stories (эпики → features → stories) — единица поставки; Use Cases — опорная документация для 2–3 сквозных сценариев, без прохождения всего бэклога через UC; минимальный SRS или living spec — для регуляторики и интеграций. Living spec не должен превращаться в устаревший монолит: версионирование и жизненный цикл — 02.05.05 Жизненный цикл требования, 07.05 Системы контроля версий (Git) для документации.
  • Гибрид: epic/feature группирует stories; один Use Case декомпозируется в несколько stories; FR из SRS трассируются к UC и stories через общие ID — см. 02.03.04 Трассировка требований (концепция).

Типовой waterfall/enterprise-срез и параллельные ветки в Agile — на схеме ниже. Стрелки к «Тесты / реализация» показывают, что любая форма может быть опорой для разработки и проверки, а не обязательный конвейер.

flowchart TB
    BRD[Vision / BRD с БТ]

    subgraph spec [Параллельные формы спецификации]
        SRS[SRS / FRD]
        UC[Use Cases]
        US[User Stories + AC]
    end

    TR[Тесты / реализация]

    BRD --> SRS
    BRD --> UC
    BRD --> US
    SRS --> TR
    UC --> TR
    US --> TR

Выбор формата

Контекстные триггеры — без повторения сценариев из 04.03 Use Case vs User Story — выбор подхода:

  • Регуляторика, контракт на поставку, фиксированный scope → опора на SRS/FRD.
  • Ветвистые сценарии с исключениями → Use Case (полный или brief).
  • Итерации, частые изменения, продуктовый фокус → User Stories с AC.

Золотое правило: фиксируйте требования настолько формально, насколько нужно для минимизации рисков недопонимания — и не более того (принцип KISS).

ИИ в работе со спецификацией

LLM ускоряют черновики SRS, Use Case и User Story, задают уточняющие вопросы и подсвечивают неоднозначности в тексте. Риски те же, что при любой автогенерации: галлюцинации, неявный контекст, устаревшие ссылки на снятые стандарты (например, IEEE 830 вместо ISO/IEC/IEEE 29148). ИИ не заменяет рецензирование аналитиком и стейкхолдерами. Промпты, кейсы и ограничения — 11.03 Промпт-инжиниринг для аналитика, 11.07 Практические кейсы применения LLM в анализе; при выборе уровня формальности ориентируйтесь на золотое правило выше.

4. Типовые ошибки и ограничения

ОшибкаПоследствиеЧто делать
Один формат «на все случаи»Избыточная бюрократия или, наоборот, дыры в сложных потокахСопоставить контекст с таблицей сравнения форматов (раздел 3); детали — 04.03 Use Case vs User Story — выбор подхода
БТ в SRS вместо ФТ/НФТНепроверяемые «хотелки», разрыв трассировкиБТ — в BRD/Vision; в SRS — декомпозированные FR/NFR — 02.03.01 Классификация требований (БТ, ФТ, НФТ)
User Story без ACНепроверяемый бэклогConfirmation в 3C; форматы — 02.04.02 Критерии приёмки (Acceptance Criteria)
НФТ «внутри» историйПотеря performance, security, complianceВыносить в отдельные NFR — 08.02 Нефункциональные требования (НФТ) — классификация и стандарты, 10.01.12 Шаблон нефункциональных требований (NFR)
SRS без ID и трассировкиНевозможность impact analysis при измененияхВвести FR-/UC-ID; матрица — 02.03.04 Трассировка требований (концепция)
Use Case вместо FR в регулируемом проектеПробелы в аудите, дублирование с SRSUC дополняет FR, не заменяет нумерованные требования
Use Case для каждого CRUDЗатраты на поддержку без отдачиBrief или story для простых операций
Доверие к LLM-черновику без V&VОшибки в контракте и реализации02.04.01 Верификация и валидация (V&V), 08.04 Рецензирование и инспекции (техники Фейгана)
Путать спецификацию продукта и API-контрактРазмытые границы ответственности BA/SAПродуктовые формы — здесь; контракты — 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf)

Ограничения форматов:

Перед передачей в разработку имеет смысл пройти 10.04 Чеклист аналитика перед стартом разработки.

Связи с другими разделами базы

Источники и дополнительные материалы

Книги и стандарты

Статьи и онлайн-ресурсы