Спецификация требований к программному обеспечению (SRS)

3 декабря 1999 года аппарат NASA Mars Polar Lander замолчал при посадке на Марс. Комиссия по расследованию установила наиболее вероятную причину: при выпуске посадочных опор датчики касания поверхности дают кратковременный ложный сигнал — это поведение было известно инженерам, и бортовая программа должна была его игнорировать. Но в требованиях к программному обеспечению это событие не было описано, и разработчики программы его не учли. Ложный сигнал сохранился в памяти, и на высоте около 40 метров, когда включилась логика обработки касания, программа выключила тормозной двигатель. Знание существовало в системных требованиях, но не попало в спецификацию требований к программному обеспечению (Software Requirements Specification, SRS) — и миссия стоимостью более ста миллионов долларов была потеряна. За два с небольшим месяца до этого, в сентябре 1999 года, погиб Mars Climate Orbiter: спецификация интерфейса требовала передавать импульс в ньютон-секундах, а наземная программа подрядчика выдавала фунт-секунды.

Спецификация требований к программному обеспечению — документ, который полно и однозначно описывает, что должна делать программа и с какими характеристиками: функции, внешние интерфейсы, производительность, ограничения проектирования, атрибуты качества — надёжность, безопасность, сопровождаемость. SRS — последний документ требований перед проектированием: из него берут задания разработчики, по нему пишут тесты, по нему принимают систему. В российской практике его роль чаще всего выполняет техническое задание по ГОСТ 34.602 (на автоматизированную систему) или ГОСТ 19.201 (на программу).

Каждое требование, которого нет в спецификации, будет реализовано так, как его поймёт разработчик. Иногда это понимание стоит миссии.

Происхождение и исследовательская база спецификации требований к ПО (SRS)

От практики 1970-х к IEEE 830

Документы требований к программам использовались уже в середине 1970-х, а в 1983 году Институт инженеров электротехники и электроники (IEEE) формализовал их назначение и содержание. Первая редакция стандарта IEEE 830 вышла в 1984 году и была одобрена Американским национальным институтом стандартов; стандарт пересматривался в 1993 и 1998 годах. IEEE 830-1998 «Recommended Practice for Software Requirements Specifications» стал самым цитируемым документом в области: он задал и состав SRS, и критерии её качества. Параллельно военное ведомство США использовало собственные описания документов — например, описание данных DI-IPSC-81433A для SRS в рамках MIL-STD-498.

Восемь характеристик хорошей SRS по IEEE 830

IEEE 830-1998 определяет хорошую спецификацию через восемь свойств. Корректная — каждое требование действительно нужно программе. Однозначная — каждое требование допускает ровно одно толкование. Полная — содержит все существенные требования к функциям, производительности, ограничениям, атрибутам и внешним интерфейсам, описывает реакцию программы на все возможные входы, включая ошибочные, и не содержит заглушек «будет определено позже». Непротиворечивая — требования не конфликтуют друг с другом. Ранжированная по важности и/или стабильности — у требований есть приоритет и оценка того, насколько они вероятно изменятся. Проверяемая — для каждого требования существует конечный и разумный по затратам процесс, которым человек или машина может проверить, что программа ему соответствует. Модифицируемая — структура позволяет менять требования легко, полно и согласованно, без дублирования. Трассируемая — происхождение каждого требования ясно, и на него можно сослаться в проектировании, коде и тестах.

Структура SRS по IEEE 830

Шаблон стандарта делит документ на три части. Введение: назначение документа, область действия продукта (что он делает и чего не делает), определения и сокращения, ссылки, обзор. Общее описание: перспектива продукта (его место среди других систем), функции продукта, характеристики пользователей, ограничения, допущения и зависимости. Конкретные требования — самая объёмная часть: внешние интерфейсы, функции, требования к производительности, логическая структура базы данных, ограничения проектирования, атрибуты программной системы (надёжность, доступность, безопасность, сопровождаемость, переносимость). Стандарт предлагает несколько способов организовать конкретные требования — по режимам работы, классам пользователей, объектам, функциям, стимулам — и подчёркивает, что выбор зависит от продукта.

ISO/IEC/IEEE 29148: SRS в семействе документов

В 2011 году IEEE 830 был заменён международным стандартом ISO/IEC/IEEE 29148 «Системная и программная инженерия — процессы жизненного цикла — инженерия требований», действующая редакция — 2018 года. Стандарт объединил прежние IEEE 830, IEEE 1233 (спецификация требований к системе) и IEEE 1362 (концепция эксплуатации) и выстроил семейство документов: спецификация бизнес-требований (BRS), спецификация требований заинтересованных сторон (StRS), спецификация требований к системе (SyRS) и SRS. В структуре SRS по 29148 появился отдельный раздел «Верификация»: для каждого требования указывается, как оно будет проверено. Стандарт также расширил перечень характеристик требования — необходимость, свобода от реализации, однозначность, полнота, единичность, выполнимость, проверяемость, корректность, соответствие — и добавил характеристики набора требований: полнота, непротиворечивость, достижимость, ограниченность.

Российская линия: ГОСТ 34.602 и ГОСТ 19.201

В России функцию SRS выполняет техническое задание. Для автоматизированных систем действует ГОСТ 34.602-2020 «Техническое задание на создание автоматизированной системы» (введён с 2022 года вместо ГОСТ 34.602-89). Он требует десяти обязательных разделов: общие сведения; цели и назначение создания системы; характеристика объектов автоматизации; требования к автоматизированной системе (к структуре системы в целом, к функциям и задачам, к видам обеспечения, общие технические требования); состав и содержание работ по созданию; порядок разработки; порядок контроля и приёмки; требования к подготовке объекта автоматизации; требования к документированию; источники разработки. ТЗ по ГОСТ 34 шире SRS: кроме требований к программе оно описывает работы, приёмку и подготовку заказчика. Для отдельных программ действует ГОСТ 19.201-78 из Единой системы программной документации.

Эмпирика: дефекты требований и их поиск

Адам Портер, Лоуренс Вотта и Виктор Базили в серии экспериментов («Comparing Detection Methods for Software Requirements Inspections: A Replicated Experiment», IEEE Transactions on Software Engineering, 1995) сравнили способы инспекции SRS: свободное чтение, чтение по чек-листу и чтение по сценариям, когда каждый рецензент ищет определённый класс дефектов. Чтение по сценариям находило заметно больше дефектов, чем свободное чтение и чек-лист. Алан Дэвис с соавторами («Identifying and Measuring Quality in a Software Requirements Specification», 1993) предложил измеримые атрибуты качества SRS. Хеннинг Феммер с соавторами (Journal of Systems and Software, 2017) показали, что многие дефекты можно обнаружить автоматически по «запахам» требований: субъективные формулировки, неоднозначные наречия и прилагательные, превосходные степени, отрицания.

Ключевые идеи и принципы спецификации требований к ПО (SRS)

Требование, для которого нельзя назвать способ проверки, ещё не требование — это пожелание, отложенный спор на приёмке.

Принцип: SRS описывает «что», а не «как»

Спецификация описывает внешне наблюдаемое поведение и характеристики программы, а не её устройство. «Система должна хранить историю изменений заказа не менее трёх лет» — требование; «использовать таблицу orders_history в PostgreSQL» — проектное решение, место которому в архитектурной документации. Исключение — ограничения проектирования, которые действительно наложены извне: обязательная платформа, стандарт, закон.

Принцип: одно требование — одно утверждение с идентификатором

Каждое требование записывается отдельно, получает уникальный идентификатор (FR-012, NFR-004) и формулируется одним предложением с модальным глаголом «должна». Составные требования «система должна делать А и Б» разбиваются: иначе нельзя ни проверить, ни отследить, ни отложить одну часть.

Принцип: шаблоны формулировок снимают двусмысленность

Подход EARS (Easy Approach to Requirements Syntax), предложенный Алистером Мавином и коллегами из Rolls-Royce в 2009 году, задаёт несколько шаблонов: постоянное требование («Система должна…»), по событию («Когда <событие>, система должна…»), по состоянию («Пока <состояние>, система должна…»), нежелательное поведение («Если <нежелательное условие>, то система должна…»), необязательная функция («Где <функция включена>, система должна…»). Шаблоны заставляют явно назвать условие, а значит — описать реакцию на ошибки, которую чаще всего забывают.

Принцип: нефункциональные требования — с числами

Требования к производительности, надёжности и удобству — самые частые источники споров. Они записываются измеримо: «95 % запросов поиска возвращают результат не дольше чем за 2 секунды при 500 одновременных пользователях», «доступность в рабочие часы — 99,9 % за месяц». Для каждого — метод измерения. Стоимость каждой следующей «девятки» доступности растёт непропорционально пользе — поэтому число выбирают из бизнес-потребности, а не «с запасом».

Принцип: полнота — включая ошибки и границы

Полная спецификация описывает реакцию на все классы входов: корректные, некорректные, граничные, отсутствующие. История Mars Polar Lander — пример того, как неописанное «нештатное» событие становится катастрофой: требование «игнорировать сигнал касания до включения логики посадки» существовало на системном уровне, но не было записано в требованиях к программе.

Принцип: трассируемость вверх и вниз

Каждое требование SRS ссылается на источник — бизнес-требование, сценарий использования, системное требование, норму закона — и на элементы проекта и тесты, которые его реализуют и проверяют. Матрица трассировки показывает, какие требования не покрыты тестами и какие функции не имеют требований. Цепочка начинается в документе бизнес-требований (BRD) и проходит через сценарии использования.

Принцип: каждый раздел заполнен или явно не применим

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

Принцип: верификация закладывается в спецификацию

По ISO/IEC/IEEE 29148 для каждого требования заранее определяется способ проверки — тест, демонстрация, анализ или инспекция. Если способ назвать нельзя, требование непроверяемо и должно быть переписано до передачи в разработку, а не на приёмке.

Принцип: SRS живёт под управлением изменений

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

Ограничения, слепые зоны и критика спецификации требований к ПО (SRS)

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

Полнота недостижима на старте. В проектах с высокой неопределённостью попытка написать полную SRS до начала разработки приводит к документу, который устареет раньше, чем будет утверждён. Это главная претензия гибких подходов к «тяжёлой» спецификации, родом из каскадной модели. Компромисс — постепенное уточнение: стабильные разделы (интерфейсы, ограничения, атрибуты качества) фиксируются рано, функции — итерациями.

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

Стандарты описывают структуру, а не качество. Заполненный по всем разделам ГОСТ 34.602 или IEEE 830 документ может состоять из непроверяемых формулировок. Шаблон — необходимое, но не достаточное условие хорошей SRS.

ТЗ по ГОСТ 34 часто превращается в договорной документ. В российской практике техническое задание нередко пишут как приложение к контракту — с оглядкой на юридические последствия, а не на ясность требований. Тогда в нём больше общих формулировок и меньше проверяемых требований.

Чем методика не является. SRS — не документ бизнес-требований: «зачем» описывается в BRD. Это не проектная документация: архитектура и устройство — в техническом проекте. И это не пользовательская документация: SRS пишется для разработчиков, тестировщиков и приёмки, а не для конечных пользователей.

Типовые ошибки при составлении спецификации требований к ПО

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

«Система должна быть удобной», «быстро работать», «обеспечивать высокую надёжность». Такие требования невозможно ни реализовать однозначно, ни принять: каждый вкладывает своё.

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

Ошибка 2: решения вместо требований.

В SRS описаны таблицы базы данных, классы и экраны. Разработчики связаны решениями, принятыми без проектирования, а настоящая потребность за ними не видна.

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

Ошибка 3: описан только успешный путь.

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

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

Ошибка 4: пустые разделы без объяснения.

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

Как избежать: каждый раздел шаблона либо заполнен, либо помечен «не применимо» с коротким обоснованием, которое согласовано с заказчиком.

Ошибка 5: нет трассировки.

Требования не связаны ни с бизнес-целями, ни с тестами. При изменении потребности непонятно, что переделывать, а при приёмке — что проверено.

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

Ошибка 6: интерфейсы описаны по договорённости, а не в документе.

Форматы обмена, единицы измерения, протоколы «понятны всем». Mars Climate Orbiter погиб из-за того, что одна программа выдавала фунт-секунды там, где спецификация интерфейса требовала ньютон-секунды.

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

Ошибка 7: SRS утверждена и забыта.

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

Как избежать: изменения — только через согласованные версии с журналом изменений и оценкой влияния.

Главное, что нужно знать о спецификации требований к ПО (SRS)

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

• IEEE 830 (1984, 1993, 1998) задал структуру и восемь характеристик хорошей SRS; с 2011 года его заменяет ISO/IEC/IEEE 29148, где SRS — часть семейства BRS, StRS, SyRS, SRS с отдельным разделом верификации.

• В России роль SRS выполняет ТЗ по ГОСТ 34.602-2020 (десять обязательных разделов) или ГОСТ 19.201-78 для программ.

• Каждое требование — одно утверждение с идентификатором, источником, приоритетом и способом проверки.

• Каждый раздел шаблона заполнен или помечен «не применимо» с обоснованием.

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

Хорошая SRS отвечает на вопрос тестировщика «как я пойму, что это сделано?» для каждого требования — ещё до того, как написана первая строка кода.

План внедрения спецификации требований к ПО (SRS)

Неделя 1. Основа и стандарт. Соберите входные документы: BRD, сценарии использования, системные требования, нормативные ограничения. Выберите стандарт — ГОСТ 34.602-2020, если документ договорной и речь об автоматизированной системе, или IEEE 830 / ISO/IEC/IEEE 29148 для программного продукта. Заведите шаблон со всеми разделами и заполните введение и общее описание.

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

Неделя 3. Качество и ограничения. Запишите требования к производительности, надёжности, безопасности, удобству и сопровождаемости — с числами и методами измерения. Добавьте ограничения проектирования. Для каждого раздела, который не нужен, запишите обоснование.

Неделя 4. Верификация и согласование. Для каждого требования определите способ проверки. Проведите инспекцию по сценариям: один рецензент ищет неоднозначность, другой — неполноту, третий — противоречия. Исправьте найденное, постройте матрицу трассировки, утвердите версию.

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

Как реализовать этот план с помощью фрейма «Спецификация требований к программному обеспечению (SRS)» в OrgDevTools

Фрейм «Спецификация требований к программному обеспечению (SRS)» — бесплатный тренажёр на странице методики. Он проверяет главное условие полноты: заполнены все разделы выбранного стандарта. Вверху фрейма — переключатель стандарта («ГОСТ 34.602-2020 (ТЗ на АС)» — выбран по умолчанию — или «IEEE 830-1998 (SRS)») и счётчик заполненных разделов.

Вкладка «1. Разделы» — недели 1–3 плана

Список разделов выбранного стандарта: для ГОСТ 34.602-2020 — 13 строк (десять обязательных разделов, при этом раздел «Требования к АС» разложен на четыре подраздела), для IEEE 830-1998 — 16 строк (введение, общее описание, конкретные требования). У каждого раздела — подсказка, что в нём должно быть, четыре кнопки статуса («Пусто», «Черновик», «Заполнено», «Не применимо») и поле, куда пишется, что в разделе или ссылка на документ. Если выбран статус «Не применимо», поле становится обязательным — без обоснования раздел не засчитывается, рамка поля красная. Статусы двух стандартов хранятся отдельно, переключение стандарта их не стирает.

Вкладка «2. Качество требований» — неделя 4 плана

Восемь карточек характеристик хорошей SRS по IEEE 830: корректна, однозначна, полна, непротиворечива, ранжирована, проверяема, модифицируема, трассируема. На каждой — проверочный вопрос; карточка отмечается кликом.

Вкладка «Визуализация»

Карта разделов стандарта плитками: зелёные — заполнены, фиолетовые — не применимы с обоснованием, красноватые — начаты, но не засчитаны, серые — пустые. Ниже — полоса заполненности по статусам со счётчиками и шкала из восьми характеристик качества.

Вкладка «Итоги»

Вердикт вычисляется автоматически: если ни один раздел не засчитан — подсказка начать; если есть незасчитанные разделы — число заполненных и первый проблемный раздел с причиной («не заполнен», «в черновике», «отмечен „не применимо“ без обоснования»); если разделы заполнены, но не подтверждена какая-то характеристика качества — первая такая характеристика; иначе — что спецификация готова к согласованию. Ниже — список всех незасчитанных разделов и неподтверждённых характеристик, в рабочей тетради — кнопка создания задачи с этим списком.

Чего фрейм не делает

Фрейм не читает текст спецификации: статус «Заполнено» и отметки качества ставит сам пользователь, фрейм проверяет только полноту по разделам и наличие обоснований. Он не ведёт реестр отдельных требований, их идентификаторы и матрицу трассировки, не поддерживает структуру ISO/IEC/IEEE 29148 отдельным вариантом и не проверяет формулировки на «запахи». Печатный документ — шаблон «SRS — спецификация требований к системе» в разделе «Шаблоны» Библиотеки: его можно забрать к себе в Базу знаний, заполнить, распечатать или сохранить в PDF. Сами функциональные требования удобно готовить во фрейме методики сценариев использования, где у каждого требования проверяются источник и способ проверки.