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

Понять друг друга им помогает бизнес-аналитик, он превращает потребности клиента в требования, а требования в задачи для разработчиков. Первоначально это делается путем составления спецификаций требований к программному обеспечению (Software requirements specification или SRS).

Что такое SRS

Software requirements specification — один из самых важных документов в разработке программного обеспечения. Он описывает работу ПО, его функции и нагрузки. Проще говоря, SRS предоставляет всем участникам дорожную карту для проекта.

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

Преимущества SRS

• Software requirements specification является основой проекта. Документ закладывает базу, которой будут следовать все участники команды разработки.
• Спецификации требований к программному обеспечению — это способ более четкой коммуникации. Этот инструмент помогает быть уверенным в том, что все участники процесса правильно понимают друг друга. 
• Написание SRS также может минимизировать общее время и затраты на разработку. Команды разработчиков встроенных систем особенно выигрывают от использования SRS.
• Такая документация помогает избежать дальнейших улучшений и изменений в проекте, которые задерживают завершение или приводят к дополнительным расходам. 

Как выглядит

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

В YuSMP Group SRS обычно выглядит так:

Роль

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

Блок/фича

Функциональности обычно представляем в виде блоков или таблицы, которая включает в себя три раздела — это пользовательская история, бизнес-правила (UseCases) и валидация (на схеме показываем, что требования к фиче выполнены).

Пользовательская история

Этот раздел отображает сценарий использования конкретной фичи. Подробнее о пользовательских историях можно узнать здесь.

UseCases (Бизнес-правила)

Внутри пользовательских историй мы размещаем бизнес-правила или UseCases. Это перечень условий, при котором фича будет работать так, как нужно клиенту.

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

Зачем мы используем SRS

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

Но это еще не все:  

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

Еще SRS важен, потому что это единый источник информации, который предотвращает недопонимание как между менеджером проекта и командой, так и между заказчиком и аутсорс-компанией.