Explore
Уложитесь в мой дедлайн?
Oops! Something went wrong while submitting the form.
SRS (software requirements specification, спецификация требований к программному обеспечению) — документ с требованиями к приложению, по-нашему — техническое задание. В эсэрэску входят требования и ограничения по функциональности и производительности SRS составляют для прозрачного взаимодействия заказчика и подрядчика.
SRS обычно пишут простым «клиентским» языком, потому что и составляется он на основе мнения клиента. Чтобы начать сотрудничество, подрядчику необходимо узнать, чего хочет заказчик, понять желания и бизнес-цели. На основе информации с нескольких созвонов на стороне подрядчика составляют SRS документ.
У SRS документа есть ряд особенностей.
Выглядит пугающе. С одной стороны, удобно, когда любой проект можно поместить в понятный шаблон, с другой — есть риск попасть в жесткие рамки, внутри которых пропадет индивидуальность продукта.
Структура SRS документа включает в себя детальное описание каждой части будущего приложения. Проблема в том, что 90% информации в таком документе — вода; настоящую пользу несут разве что картинки — примеры дизайна и описания работы сложных алгоритмов. Допустим, если бы у Tinder был SRS, то там бы был алгоритм мэтчинга. И еще 37 страниц ненужной инфы.
Структура спецификации требований к программному обеспечению выглядит так:
Как бы ни хотелось рассказать в SRS документе о преимуществах компании или идеях, которые пришли в голову уже в процессе разработки, делать это запрещено. У документа — четкая цель, а значит, такое же четкое содержание. SRS всегда отражает функциональность и технические характеристики продукта.
Здесь речь о терминах и языке. Используйте язык клиента, но не переборщите с упрощением, эвфемизмами и литературными приемами. Не стоит писать о волшебном труде мастеров кода и гениальных выдумках повелителей картинок. Лучше быть излишне конкретным, чем двусмысленным. Спецификация требований к программному обеспечению — не шедевр мировой классики, поэтому даже самые элементарные стилистические правила можно игнорировать во имя ясности.
Сокращения, аббревиатуры, названия — в документе они должны не должны отличаться. На первый взгляд — мелочь, но поскольку документ носит официальный характер, ошибаться в подобных моментах не стоит. Вот так надо и не надо:
Никаких «два пишу, четыре в уме»! Если на исполнение того или иного требования уйдет много времени, стоит поставить для него высокий приоритет. В целом ранжирование требований по важности и стабильности — хорошая идея. Под стабильностью мы понимаем, насколько точно поставили задачу, и придется ли что-то менять в процессе исполнения.
И хотя SRS — это документ с жесткой регламентацией, систематически в него можно и нужно вносить изменения. Правда, это не так легко, как кажется — SRS документ далеко не гибкая форма. Больше всего от этого страдают стартапы: в MVP приложения часто нужно вносить правки, а спецификацию требований к программному обеспечению менять забывают. Даже в крупных компаниях, которые любят бумажки и бюрократию, можно часто найти Confluence с документацией 5-летней давности. Зачем делалось? Конечно, для галочки!
За семь лет работы мы заметили, что отношение к SRS документам в России и за рубежом значительно отличается. Пытаемся понять, почему в России так любят бумажки, и как «продать иностранцу дизайн-концепт по цене SRS».
| Россия 🇷🇺 | Зарубеж ✖️🇷🇺 |
|
Заказчики из России часто просят составить SRS документ. Здесь принято делать большие отчеты ко всему, что происходит вокруг, поэтому даже современная IT-сфера не обходится без кучи бумажек. Иногда мы вынуждены делать подобные документы, потому что заказчик — крупная госструктура, где без отчетов, как известно, никуда. Про одного из таких заказчиков написали кейс «Большой брат оказался реальностью». Читайте по ссылке ниже 👇 |
А вот зарубежные клиенты SRS требуют редко. Они охотно принимают наши правила и соглашаются на гибкую модель работы. Есть, конечно, и принципиальные заказчики. Однажды клиент настаивал на составлении SRS документа, потому что хотел уйти на разработку к другому подрядчику. Мы его «переобули»: сделали гибрид SRS и нашего стандартного описания дизайна, добавили иллюстрации. Ему понравилось и он остался с нами! |
Мы в Purrweb не делаем SRS документы. Это принципиальная позиция, от которой мы отступали всего пару раз — напоминаем, что количество наших проектов перевалило за 250. Мы не тратим время на бумажную волокиту и бюрократию и сохраняем ресурсы клиента. Выделили пять основных причин, почему SRS не нужен.
SRS сожрет ваше время и не поперхнется косточкой менеджера по продажам. Сколько времени уйдет на составление документа? Мы попросили нашего операционного директора оценить эту задачу. Цифры говорят сами за себя:
Все дело в высокой детализации SRS документа. Сбор нужной информации может затянуться — бизнес-аналитикам придется подойти к дизайнерам, разработчкам, тестировщикам, тимлидам. Внутри спецификации требований к программному обеспечению много технических моментов, которые тяжело осмыслить человеку, далекому от разработки. За время, которое тратится на SRS, мы успеваем провести один спринт и прийти к заказчику с первыми результатами. Мы уверены: это лучше, чем бумажка.
Как бы хорошо и подробно менеджеры не прописали требования на старте проекта, буквально ВСЁ может пойти не так в ЛЮБОЙ момент. Так что время + силы, затраченные на составление SRS мягко говоря «не окупятся». Скорее всего, ваши бизнес-аналитики почувствуют себя бесполезными. Из всего документа, на который они потратят 80 часов рабочего времени, клиенту пригодится 15-20%.
Все остальное в SRS документе — вода, налитая в угоду бюрократии. Такие документы составляют в крупных компаниях для эффекта «создания бурной деятельности» и отчета ради отчета, который в 9 из 10 случаев даже не откроют.
SRS не совместим с гибким подходом к разработке. Невозможно смотреть на пустой экран и видеть будущее приложение с точностью до кнопки. Однако методика составления SRS документа утверждает обратное: нужно составить подробный план действий с детальным описанием каждого шага еще до того, как команда приступит к работе.
Подобный подход неплохо мэтчится с моделью Waterfall — «каскадной разработкой». Особенность ватерфола в том, что все стадии создания проекта идут по порядку. Сначала делают весь дизайн, потом всю разработку, затем все тестируют, и если находят баги, исправляют в уже готовом приложении. Возвращение к предыдущему шагу не предусматривают, поэтому каждый этап важно сделать «на отлично». На наш взгляд, крайне идеалистическая модель. Никакой SRS не спасет от ошибок или срочных задач, которые не предусмотрели в спецификации требований к программному обеспечению.
Так что компании, которые используют agile и SCRUM-методологии, отказываются от SRS документов. Там (и здесь) работают спринтами. Тестирование проходит в конце двухнедельной итерации, поэтому баги находятся сразу. Так разработчику не приходится перелопачивать весь код, чтобы найти поломку.
Такая модель удобна не только для компании разработки, но и для клиента. С agile подходом вы всегда на связи с проектным менеджером, а значит, владеете актуальной информацией по проекту. Не приходится все время обращаться к SRS документу, данные в котором могут устареть на первой же итерации.
Мы в Purrweb поддерживаем коммуникацию с каждым клиентом, особенно если на проекте специфические условия. Например, в кейсе Headcount у клиента были ограниченные сроки, поэтому он сильно вовлекался в разработку и микроменеджерил все наши шаги. Подробнее про скоростную разработку приложения для финтех сферы читайте тут 👇
Откроем страшную тайну: мы бы не пользовались SRS, даже если бы клиент настаивал его подготовить. Документ лежал бы мертвым грузом на рабочих столах разработчиков. Когда нас впервые попросили составить SRS документ, мы просто скачали шаблон из интернета и кастомизировали под заказчика. Спойлер: стартапер этого даже не заметил. Думаем, он его и не открывал. Да и мы не открывали.
«А что не так со стартапом?», — спросит владелец стартапа. Со стартапом все в порядке, а вот с SRS документом все еще нет. Пока другой подрядчик будет составлять документ с подробным описанием функциональности будущего приложения, мы уже сделаем первую версию дизайна и покажем его клиенту.
Purrweb выбирает такой подход исходя из целевой аудитории — у нас это стартапы, которые приходят за MVP (минимально жизнеспособным продуктом). Вместо того, чтобы тратить время и деньги заказчика и наши людские ресурсы на некрасивый SRS, мы предлагаем клиенту сэкономить и сразу начать дизайн.
Почему дизайн — first, расскажем в следующем блоке.
{{tg-banner}}
Вместо тысячи слов и десятков страниц ненужной информации мы предлагаем заказчикам подход design first. Это значит, что сразу после того, как мы подтверждаем сотрудничество, начинает работать дизайн-команда. Не бойтесь, дизайнеры не надизайнят «что надо и не надо» — все детали аккаунт менеджер и заказчик обсуждают на созвонах, бизнес-аналитик оценивает стоимость проекта. Мы получаем от клиента антиреференсы, иногда наработки по дизайну — так что всегда есть от чего оттолкнуться.
Потому что дизайн — это часть будущего продукта, а SRS документ — всего лишь набор слов, собранный в строгую структуру.
Как делаем мы: вместо больших документов прописываем пользовательские истории. По юзер сториз делаем дизайн, на основе дизайна оцениваем разработку, делаем архитектуру и структуру базы данных. И только на этапе разработки делаем небольшой документ — описываем, как работает логика на бэкенде или какой-то сложный алгоритм. Важно: это не официальный документ. Мы можем даже не передать его клиенту, а сделать «чисто для себя» и хранить в readme в репозитории.
С таким подходом легко вносить изменения на любом этапе. Даже если к концу разработки отвалится, например, админка, которую делали в середине проекта, разработчику ничего не стоит вернуться и все «поднять». И главное — никаких сложных документов, волокиты, бюрократии и прочих страшных вещей из мира отчетов.
Мы лояльно относимся к любым хотелкам заказчика: хочет кастомные чат, календарь и видеозвонки? Пожалуйста! Нравится следить за каждым шагом разработки? Без проблем, будем созваниваться чаще. Но если речь заходит о спецификации требований к программному обеспечению, мы до последнего будем предлагать клиенту альтернативные решения.
SRS документ не соответствует ценностям agile-подхода, не несет пользы клиенту и отнимает как наши, так и его ресурсы. Мы в Purrweb давно делаем все иначе: работаем по SCRUM, не морочим заказчикам голову огромными ТЗ, а разрабатываем понятные интерфейсы с удобным дизайном.
Хотите заказать приложение в Purrweb? Ниже есть форма для e-mail 👇
SRS (Software Requirements Specification) — международный стандарт описания требований по IEEE 830, тогда как ТЗ — российский аналог по ГОСТ 34. Принципиальное отличие: ТЗ чаще описывает функциональность с позиции заказчика, SRS — с позиции системы и пользователя. На практике оба документа решают одну задачу: зафиксировать требования до начала разработки. В российских компаниях термины нередко используются как синонимы.
По стандарту IEEE 830 SRS должен содержать: общее описание системы и её окружения, функциональные требования, нефункциональные требования (производительность, безопасность, масштабируемость), ограничения и допущения, варианты использования (use cases). На практике объём документа — от 20 до 100 страниц в зависимости от сложности проекта. Для MVP команды часто ограничиваются пользовательскими историями вместо полного SRS.
SRS обычно готовит бизнес-аналитик совместно с системным аналитиком и представителями заказчика. Для типового проекта средней сложности подготовка занимает от 2 до 6 недель. По оценке Purrweb, около 80 часов работы аналитика дают документ, из которого реально используется 15–20% информации. Стартапы всё чаще заменяют полный SRS набором user stories и прототипом.
Да, и это распространённая практика. Agile-методологии (Scrum, Kanban) изначально не предполагают фиксированных требований в виде объёмного документа. Вместо SRS команды используют бэклог продукта с user stories, критерии приёмки и прототипы. Это позволяет менять требования в процессе, не переписывая спецификацию. Полный SRS оправдан в проектах с жёстко фиксированным scope: госзаказ, банковское ПО, медицинские системы.
Современные команды используют комбинацию: бэклог с user stories (кто, что, зачем), прототипы и дизайн-макеты в Figma, acceptance criteria в формате Given/When/Then, и API-документацию для интеграций. Подход design-first — сначала утверждённый дизайн, потом разработка — позволяет выравнивать ожидания без объёмного текстового документа и сокращает число правок на 30–40%.
Для большинства MVP — нет. Классический SRS предполагает стабильные требования, но у стартапа они меняются после каждого теста с пользователями. Составить полный SRS для MVP стоит от 150 000 до 500 000 ₽ и занимает 4–8 недель, которые лучше потратить на прототипирование. Достаточно краткого product brief (1–3 страницы), экранов в Figma и приоритизированного бэклога для запуска первой версии.
В классическом Waterfall-проекте изменения в SRS фиксируются через процедуру change request: аналитик вносит правки, документ проходит повторное согласование. Это занимает от 3 до 10 рабочих дней и нередко блокирует команду. В Agile-проектах этой проблемы нет: требования живут в бэклоге и обновляются перед каждым спринтом без формальной бюрократии. Поэтому для проектов с нестабильным scope SRS проигрывает живому бэклогу.
.svg)
%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1).png)
%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1).png)
%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1).png)