Все мы прекрасно знаем о том, как разрабатывается ПО. Подумали 10 минут и сразу пошли кодить. Цикл создания программного обеспечения состоит из многих ключевых моментов. Это такие моменты как планирование, создания архитектуры, создание SRS, создание дизайна и тд и тп.
Что такое SRS ?
SRS — Software Requirement Specification — специальная документация для ПО которая содержит в себе информацию о том, как должна себя вести система, какие функции должна выполнять, какую нагрузку должна выдерживать и тд.
Зачем оно надо ?
Все предельно просто. Вы используете ТЗ (велосипед), я использую SRS (машину). Надеюсь аналогия получилась ясная? 🙂
Структура SRS
Ниже приведена структура на англ языке в raw виде. Чуть ниже в статье мы рассмотрим каждый пункт более подробно
- Introduction
- Purpose
- Document conventions
- Intended Audience and Reading Suggestions
- Project scope
- References
- Product perspective
- Product features
- User classes and characteristics
- Operating environment
- Design and implementation constraints
- User documentation
- Assumptions and dependencies
- System feature X (таких блоков может быть несколько)
Коротко об #SRS и Решение
- Description and priority
- Stimulus/Response sequences
- Functional requirements
- User interfaces
- Software interfaces
- Hardware interfaces
- Communication interfaces
- Performance requirements
- Safety requirements
- Software quality attributes
- Security requirements
И так со структурой разобрались, теперь перейдем к разделам и тому, что в них надо писать.
Базовые требования ко всем разделам SRS
- Кратко, четко. Описывает все предельно кратко и четко. Насколько это возможно.
- Без двусмысленных описаний. Человек читающий SRS должен понимать именно то, что написано, а не что-то другое. Закон Мерфи: Если Вас могут понять неправильно, Вас поймут неправильно. Избегайте этого
- Простота и «читабельность». Не используйте каких либо слишком заумных оборотов. Красота в простоте 🙂
- DFD-диаграммы. Спецификация не может быть полной если мы не знаем что на входе в описываемый софт, а что на выходе. Все должно быть четко нарисовано.
- Степень детализации. Это эвристический параметр. Его можно определить так: если я могу свободно изложить информацию о функционале и написанное не вызывает у меня смущения, если требования однозначны и не подлежат никакому двоякому пониманию, если требования в достаточной для меня мере описывают поведение функционала, то проработку SRS можно считать завершенной
Пояснение каждого пункта структуры SRS
Introduction Purpose
В данной секции описываем приложение или продукт, функционал которого будет описываться в SRS.
Что такое SRS за 10 минут
Introduction Document conventions
Здесь мы описываем все непонятные технические слова или термины которые встречаются в SRS. Заметьте, что описание непонятного слова не может содержать другое непонятное слово. Старайтесь расписать как можно подробнее термин который Вы используете простым и понятным всем языком. Не экономьте на этой секции потому, что чем больше вы распишете непонятных вещей, тем проще будет потом проектировать.
Introduction References
В данной секции мы пишем ссылки на литературу в которой можно найти основания использованных технологий и фактов. Допустим можно вставлять RFC если вы пишете приложение работающее с TCP/IP, вставлять ссылки на документы на которые вы ссылаетесь и тд. Ссылки и их описание должны быть максимально полными, чтобы в случае чего (линк умер просто) можно было нагуглить этот материал.
Overall Description Product features
В данном разделе мы описываем части функционала на высоком уровне. Более детально каждая часть функционала будет описана в своем разделе ниже. Тут желательно разместить DFD-диаграмму которая покажет общее взаимодействие системы.
Overall Description Operating environment
Как понятно из названия раздела тут мы описываем окружение в котором будет работать продукт. ОС, версии компиляторов, базы данных, сервера, софт, железо и другие вещи которые необходимы для работы вашего продукта.
- Язык программирования, база данных
- Стандарты кодирования
- Стандарты обмена данными
- Ограничения накладываемые Operational Enviroment, допустим совместимость только с ФФ
- Ограничения которые могут быть наложены бизнес-логикой проекта
Overall Description User documentation
Описываем какая документация нужна для пользователей данного продукта. Возможно это книга по HTML если это HTML редактор.
System features System feature X
Называем фичу проекту и даем ей уникальный идентификатор. Например, server.html.editor. Уникальный идентификатор дается для того, чтобы потом где то в тикетах ваших не писать — «а вот та хреновина, которая позволяет редактировать хтмл»
System features System feature X Description and priority
Описываем детально фичу продукта. Для чего она? Что должна делать? Какой у нее приоритет выполнения. Из этого раздела читающему срс человеку должно сразу стать понятно зачем этот функционал присутствует в системе.
System features System feature X Stimulus/Response sequences
Триггер запуска фичи. Когда она запускается и как себя ведет при запуске? Например, HTML редактор показывается при нажатии пользователя на ссылку меню Открыть HTML редактор
System features System feature X Functional requirements
Подробное и детальное описание фичи. Описываем все: как работает, как реагирует на ошибки, что должно проверять, как отображать данные, как и куда что сохраняет и тд
External interface requirements
Описание того как система будет взаимодействовать с внешним миров. Если будет конечно. Какие API, как получить те или иные данные и тп. Подразделы служат для детализации требований. Какие софт интерфейсы, «железячные» интерфейсы, комуникационные интерфейсы и прочее.
Non functional requirements
Не функциональные требования. Есть требования которые невозможно описать как какую то фичу, например, требования к безопасности.
Non functional requirements Performance requirements
Требования к производительности. Это не фича, однако налагает определенные ограничения. Допустим база данных проекта должна выдерживать 1000 запросов в секунду и тп. Эти требования приводят к колоссальной работе по оптимизации проекта.
Non functional requirements Software quality attributes
Тут мы описываем требования к качеству кода. Какие тесты использовать? Какие метрики использовать для определения качества кода? Сколько кода должно быть покрыто тестами?
Non functional requirements Security requirements
Требования по безопасности. Если это HTML редактор, через которые можно изменять что-то на сайте, то это может быть нечто вроде: через HTML редактор не должно быть возможности поставить shell на сервер и тп
Appendix A: Glossary
Приложение. Иногда в SRS пытаются вставлять описание протоколов и тд и тп. Этого делать не нужно. Однако иногда нужно таки прояснить какую то концепцию. Для этого существует этот раздел.
Вставляем ссылочки на такие пояснения. Такой себе словарик.
Appendix B: Analysis Models
Раздел определяет какие диаграммы нужно использовать при написании SRS. Например, DFD, какие то общие диаграммы взаимодействия и работы
Appendix C: Issues list
Данный раздел используется для очень формальных SRS. Описывает пункты TBD(To Be Done) — что в будущем надо еще сделать, но тут не описано.
Заключение
SRS не является обязательным для использования, однако может помочь в средних и больших проектах. Использование SRS показывает Ваш профессиональный уровень как разработчика.
P.S. прошу сильно не винить — первая статья более или менее среднего масштаба на хабре. Исправления в синтаксисе приветствуются (стараюсь писать грамотно, однако 7-ми классное образование по русскому языку накладывает свой отпечаток.)
- srs
- software requirements specification
- rules
Источник: habr.com
SRS: что такое и зачем это нужно разработчикам
Как правило, заказчики и разработчики говорят на разных языках. Клиент представляет внешнее поведение системы: что она будет делать и как с ней будут работать конечные пользователи. Программисты же думают о продукте с точки зрения его внутренних характеристик.
16 790 просмотров
Понять друг друга им помогает бизнес-аналитик, он превращает потребности клиента в требования, а требования в задачи для разработчиков. Первоначально это делается путем составления спецификаций требований к программному обеспечению (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 важен, потому что это единый источник информации, который предотвращает недопонимание как между менеджером проекта и командой, так и между заказчиком и аутсорс-компанией.
Источник: vc.ru
SRS не нужен: объясняем, почему ТЗ — это прошлый век
Как говорится, без ТЗ — результат хз. Во многих сферах это действительно так работает: без четкого технического задания сотрудник или подрядчик не может качественно выполнить задачу. В IT технические задания для проектов разработки давно изжили себя. С приходом agile- и SCRUM-методологий больше не нужно писать 40-страничные документы и подробно объяснять каждое решение. В статье разберемся, почему пора забыть об SRS документе, и чем заменить сложное техзадание.
Время чтения: 7 минут
SMS? BTS? CMS? SRS!
SRS (software requirements specification, спецификация требований к программному обеспечению ) — документ с требованиями к приложению, по-нашему — техническое задание. В эсэрэску входят требования и ограничения по функциональности и производительности SRS составляют для прозрачного взаимодействия заказчика и подрядчика.
SRS обычно пишут простым «клиентским» языком, потому что и составляется он на основе мнения клиента. Чтобы начать сотрудничество, подрядчику необходимо узнать, чего хочет заказчик, понять желания и бизнес-цели. На основе информации с нескольких созвонов на стороне подрядчика составляют SRS документ.
У SRS документа есть ряд особенностей.
Выглядит пугающе. С одной стороны, удобно, когда любой проект можно поместить в понятный шаблон, с другой — есть риск попасть в жесткие рамки, внутри которых пропадет индивидуальность продукта.
Структура SRS документа включает в себя детальное описание каждой части будущего приложения. Проблема в том, что 90% информации в таком документе — вода; настоящую пользу несут разве что картинки — примеры дизайна и описания работы сложных алгоритмов. Допустим, если бы у Tinder был SRS, то там бы был алгоритм мэтчинга. И еще 37 страниц ненужной инфы.
Структура спецификации требований к программному обеспечению выглядит так:
- Введение
- Цели
- Соглашения о терминах
- Предполагаемая аудитория и последовательность восприятия
- Масштаб проекта
- Ссылки на источники
- Видение продукта
- Функциональность продукта
- Классы и характеристики пользователей
- Среда функционирования продукта (операционная среда)
- Рамки, ограничения, правила и стандарты
- Документация для пользователей
- Допущения и зависимости
- Функциональный блок X (таких блоков может быть несколько)
- Описание и приоритет
- Причинно-следственные связи, алгоритмы (движение процессов, workflows)
- Функциональные требования
- Требования к внешним интерфейсам
- Интерфейсы пользователя (UX)
- Программные интерфейсы
- Интерфейсы оборудования
- Интерфейсы связи и коммуникации
- Требования к производительности
- Требования к сохранности (данных)
- Критерии качества программного обеспечения
- Требования к безопасности системы
- Приложение А: Глоссарий
- Приложение Б: Модели процессов предметной области и другие диаграммы
- Приложение В: Список ключевых задач
Релевантность
Прозрачность
Здесь речь о терминах и языке. Используйте язык клиента, но не переборщите с упрощением, эвфемизмами и литературными приемами. Не стоит писать о волшебном труде мастеров кода и гениальных выдумках повелителей картинок. Лучше быть излишне конкретным, чем двусмысленным. Спецификация требований к программному обеспечению — не шедевр мировой классики, поэтому даже самые элементарные стилистические правила можно игнорировать во имя ясности.
Сокращения, аббревиатуры, названия — в документе они должны не должны отличаться. На первый взгляд — мелочь, но поскольку документ носит официальный характер, ошибаться в подобных моментах не стоит. Вот так надо и не надо:
Рейтинг по важности
Никаких «два пишу, четыре в уме»! Если на исполнение того или иного требования уйдет много времени, стоит поставить для него высокий приоритет. В целом ранжирование требований по важности и стабильности — хорошая идея. Под стабильностью мы понимаем, насколько точно поставили задачу, и придется ли что-то менять в процессе исполнения.
И хотя SRS — это документ с жесткой регламентацией, систематически в него можно и нужно вносить изменения. Правда, это не так легко, как кажется — SRS документ далеко не гибкая форма. Больше всего от этого страдают стартапы: в MVP приложения часто нужно вносить правки, а спецификацию требований к программному обеспечению менять забывают.
Даже в крупных компаниях, которые любят бумажки и бюрократию, можно часто найти Confluence с документацией 5-летней давности. Зачем делалось? Конечно, для галочки!
SRS в России и за рубежом
За семь лет работы мы заметили, что отношение к SRS документам в России и за рубежом значительно отличается. Пытаемся понять, почему в России так любят бумажки, и как «продать иностранцу дизайн-концепт по цене SRS».
Заказчики из России часто просят составить SRS документ. Здесь принято делать большие отчеты ко всему, что происходит вокруг, поэтому даже современная IT-сфера не обходится без кучи бумажек.
А вот зарубежные клиенты SRS требуют редко. Они охотно принимают наши правила и соглашаются на гибкую модель работы. Есть, конечно, и принципиальные заказчики.
READ MORE Большой брат оказался реальностью: как с этим связаны разработчики из Purrweb
