Выполните эти 5 простых шагов, чтобы написать документ спецификации требований к программному обеспечению (SRS)
21 марта 2023 г.За свою карьеру я видел десятки документов SRS для проектов разного размера, использующих как гибкие, так и каскадные методологии разработки.
Некоторые были лучше, чем другие, но критически важно то, что теперь я могу легко отличить хороший от того, который будет проигнорирован.
И если никто не читает ваш SRS, у вас останутся такие проблемы, как конфликты функций, несвязанные данные, члены команды, не понимающие, соответствует ли функция, которую они создают, тому, что попросила команда продукта, и этот список можно продолжить. .
На протяжении всей этой статьи я буду углубляться в то, что нужно для создания такой системы, которая будет служить единственным источником правды для вашего процесса разработки. SRS, на которую все участники процесса могут ссылаться, чтобы принимать инженерные решения и создавать предварительные заявки на разработку для этапа планирования разработки. Тем самым увеличивая шансы на успешное выполнение технической части вашего продукта.
Но сначала я хочу кратко указать, когда вы должны (и не должны) его использовать.
Вам действительно нужен документ SRS?
Короткий ответ на этот вопрос:
<цитата>"Обычно ранняя версия нового продукта или MVP не содержит достаточного количества функций, чтобы нуждаться в документе SRS"
Благодаря экономичным и гибким методологиям двое детей с небольшим опытом или без него могут буквально создать приложение в своей комнате в общежитии.
Это вызвало смену парадигмы. В настоящее время команды стартапов берутся за дело, берутся за дело и, как правило, оставляют такие процессы, как документация SRS, позади.
Даже здесь, в Altar, мы помогли нескольким основателям создать продукты, которые принесли миллионы (например, как эта компания) без использования документа SRS. Обычно мы используем документ SRS только в средних и крупных проектах, которые состоят, например, из более чем 50 экранов и более двух сервисов.
Если вы создаете большой продукт, продолжайте читать, и я расскажу вам обо всем, что вам нужно для написания SRS.
Если вы создаете стандартный MVP или первую итерацию своего продукта, может быть достаточно объяснить ваш продукт вашей команде разработчиков с точки зрения объем продукта, эпики или диаграмма BPMN, если у вас есть один или более точные прототипы.
Что такое документ спецификации требований к программному обеспечению (SRS)?
Спецификация требований к программному обеспечению (SRS) – это документ, в котором содержится подробный обзор вашего программного продукта, его назначения, требований и функций.
Типичный документ SRS включает:
* Цель вашего продукта, включая предполагаемую аудиторию, предполагаемое использование и эффективность. объем продукта. * Обзор вашего продукта, включая потребности ваших пользователей, а также предположения и зависимости, связанные с вашим продуктом. * Подробное изложение ваших конкретных требований, включая функциональные требования, требования к интерфейсу, системным функциям и нефункциональные требования.
Теперь давайте рассмотрим, чем это может быть вам полезно.
Зачем создавать документ SRS?
SRS действует как схема вашего проекта, и каждая команда, участвующая в процессе разработки, будет ей следовать.
Это держит всех на одной странице, от команды разработчиков, группы обеспечения качества, эксплуатации, обслуживания и группы продукта.
Документ со спецификацией требований к программному обеспечению также может помочь вам принимать решения о вашем продукте в течение его жизненного цикла, например, когда создавать новую функцию или закрывать функцию, которая стала избыточной, или ваши пользователи просто игнорируют ее.
Однако важно отметить, что при правильном выполнении SRS может и должна сократить время и затраты на разработку.
Не давайте посмотрим, как можно создать исчерпывающий документ SRS.
Как написать документ SRS за 5 шагов
- Создать схему
- Определите свою цель
- Напишите обзор своего продукта
- Уточните системные требования
- Внедрите SRS
1. Создать схему
Как и при составлении любого документа, очень важно начать со структуры, и SRS не является исключением.
Если вы решите создать его для себя, вот базовый, легкий, непонятный план, который даст вам представление:
Схема документа «Спецификация требований к программному обеспечению» (SRS)
- Введение
1.1 Цель
1.2 Предполагаемая аудитория
1.3 Использование по назначению
1.4 Область применения
1.5 Определения и сокращения 2. Общее описание
2.1 Потребности пользователей
2.2 Допущения и зависимости 3. Особенности системы и требования
3.1 Функциональные требования
3.2 Требования к внешнему интерфейсу
3.3 Системные функции
3.4 Нефункциональные требования
После того, как вы создали структуру для своей SRS, пришло время приступить к ее конкретизации. Все начинается с цели.
2. Начните с цели
В этом разделе документа SRS укажите назначение продукта, начиная с:
Предполагаемая аудитория/использование
Определите, какие заинтересованные стороны будут использовать SRS и как они будут ее использовать. Скорее всего, это будут разработчики, специалисты по обеспечению качества, эксперты по продуктам и руководители проектов.
Тем не менее, может быть целесообразно поделиться этим документом с заинтересованными сторонами из других отделов, таких как маркетинг и продажи.
Область продукта
Здесь вы описываете свой продукт с точки зрения бизнеса. Включите преимущества, цели и задачи. Это поможет согласовать все отделы, в каком направлении продвигается ваш продукт и почему.
В Altar наша команда по продуктам создала собственный процесс именно для этого. Посетите этот ресурс от нашего соучредителя Дэниела, чтобы получить дополнительную информацию. В нем он шаг за шагом описывает точный процесс.
Глоссарий терминов
Здесь укажите любые термины, относящиеся к вашему продукту. Это гарантирует, что все находятся на одной странице, независимо от технических возможностей или отдела.
Кроме того, включите сюда любые ссылки (например, если вам нужно включить какие-либо юридические документы или документы с передовой практикой).
3. Обзор вашего продукта
В этом разделе опишите функциональность вашего продукта. Опишите любые неформальные требования, чтобы дать контекст конкретным техническим требованиям, рассмотренным в следующем разделе.
Короче говоря, расскажите, что вы создаете и для кого вы это делаете.
Потребности пользователей
Очень важно указать потребности пользователей (также называемые классами пользователей или характеристиками пользователей) в обзоре.
Перечислите всех основных или дополнительных пользователей, которые будут использовать продукт на регулярной основе, и определите их путь использования продукта.
Это снова гарантирует, что вся команда находится на одной странице и сосредоточена на вашем конечном пользователе на протяжении всего процесса разработки продукта.
Предположения и зависимости
Этот раздел вашего SRS используется для описания любых факторов, которые могут помешать вам выполнить требования вашего проекта.
Например, делаете ли вы предположения о своем продукте, которые могут быть ложными? Если они окажутся ложными, каков будет план их исправления?
Наконец, зависит ли ваш проект от каких-либо внешних факторов? Например, интеграция со сторонним SaaS может привести к проблемам с соглашением об уровне обслуживания и т. д.
4. Подробные системные требования
После того, как у вас есть общее представление о вашем продукте, пришло время детализировать его. Помня о потребностях ваших пользователей, пришло время дать подробный обзор вариантов использования вашего продукта, а также нефункциональные требования.
Начнем с краткого описания вариантов использования и нефункциональных требований в документе SRS.
Как написать варианты использования в документе SRS
Сценарий использования описывает, как ваш пользователь будет взаимодействовать с вашим продуктом в формате простой истории. Создание варианта использования поможет вам поставить себя на место конечного пользователя.
Для начала создайте полный список конечных пользователей вашего продукта. Затем возьмите этих пользователей по одному и:
* Разбейте их взаимодействия на варианты использования (один случай для одного взаимодействия) * Опишите последовательность событий для каждого случая. * Напишите подробное описание того, что делает пользователь и как на это отреагирует система
Повторяйте этот процесс для каждого пользователя, пока не закончите свой список.
Нефункциональные требования
Ваши нефункциональные требования так же важны, как и функциональные. Они включают в себя производительность, безопасность, надежность и эффективность. качество. Вот пример того, как написать нефункциональное требование для датчика LIDAR автомобиля:
Датчики LIDAR автомобиля должны отправлять данные на приборную панель со скоростью от 10 Мбит/с до (включительно) 100 Мбит/с.
После того, как вы напишете варианты использования и перечислите нефункциональные требования, а также предоставите любую соответствующую дополнительную информацию, вы будете готовы передать ее заинтересованным сторонам.
5. Внедрите свой документ SRS
Убедившись, что все команды довольны и документ подписан, пришло время его реализовать.
Сделайте его доступным для всей команды в печатном виде или в формате PDF на общем диске. Или даже в файле MD на таких платформах, как confluence, notion или monday.com.
Это означает предоставление документа всем командам, участвующим в процессе разработки вашего продукта, платформе управления заявками или реестре кода.
Это жизненно важный шаг, так как если ваш SRS не потребляется регулярно, его существование не имеет смысла.
Подведение итогов
Как я уже говорил в начале этой статьи, в быстро меняющихся средах стартапов, где основатели вынуждены работать все быстрее и быстрее, документация, такая как SRS, часто остается позади. Если у вас есть подходящая команда, это не так. обязательно плохо.
При этом, если вам нужно создать его, важно убедиться, что вы следуете рекомендациям, перечисленным выше.
Это гарантирует, что вы создадите SRS, четко сообщающую ключевые требования всем членам вашей команды, что сократит время и затраты на разработку. Дополнительным преимуществом является то, что он может помочь вам принимать решения о жизненном цикле вашего продукта в дальнейшем.
Если у вас есть дополнительные вопросы, связанные с написанием документа SRS, свяжитесь со мной здесь – я буду рад ответить ответить на любые ваши вопросы.
Спасибо, что прочитали.
Эта статья была ранее опубликована здесь нашим техническим директором & ; Партнер Клаудио Тейшейра
Клаудио Тейшейра
Клаудио – партнер и технический директор Altar.io. Ранее он работал техническим руководителем полного цикла и техническим директором в нескольких стартапах и компаниях в Лондоне и Амстердаме. В настоящее время он занимается исследованиями машинного обучения на периферии.
Оригинал