Как составить документ с требованиями к программному обеспечению (с шаблоном)

Помните, как в школе читали романы XIX века и думали: «Это вообще тот же язык?» Скорее всего, у вас возникала такая же мысль в офисе при сотрудничестве с технически подкованными разработчиками ИИ или SEO-аналитиками. Если бы только существовал CliffsNotes для коллег.

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

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

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

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

Представьте, что у вас есть отличная идея для приложения. У вас есть представление о том, что оно должно делать и как выглядеть, но вы знаете, что нельзя просто дать разработчику устное описание и ожидать, что оно будет соответствовать вашим ожиданиям. Именно здесь на помощь приходит SRS.

Зачем нужна спецификация требований к ПО?

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

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

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

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

Что должно быть в документе SRS

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

1. Введение

Введение в SRS — это именно то, что вы ожидаете увидеть: общий обзор всего проекта. При написании введения опишите назначение продукта, целевую аудиторию и то, как она будет его использовать. Во введении обязательно укажите следующее:

• Область применения продукта: она должна быть связана с общими бизнес-целями продукта, что особенно важно, если к документу будут иметь доступ несколько команд или подрядчиков. Перечислите преимущества, задачи и цели, связанные с продуктом. 

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

• Целевая аудитория: опишите свою идеальную аудиторию. Она будет определять внешний вид вашего продукта и то, как вы его продаете. 

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

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

• Содержание: подробный документ SRS, скорее всего, будет очень длинным. Включите оглавление, чтобы все участники могли найти именно то, что им нужно. 

Введение должно быть чётким и лаконичным. Помните, что введение будет служить руководством по остальной части документа, и важно, чтобы все его участники понимали его одинаково.

2. Системные и функциональные требования

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

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

• Поведение по принципу «если/то»

• Логика обработки данных

• Рабочие нагрузки системы

• Обработка транзакций

• Административные функции

• Нормативные и комплаенс-требования

• Требования к производительности

• Подробная информация для каждого экрана

Если это кажется непосильной задачей, попробуйте выполнять требования по одному. Чем больше деталей вы включите в документ SRS, тем меньше проблем вам придётся решать в будущем. 

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

3. Требования к внешнему интерфейсу

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

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

• Аппаратные интерфейсы: характеристики каждого интерфейса между программными и аппаратными компонентами системы, такие как поддерживаемые типы устройств и протоколы связи.  

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

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

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

4. Нефункциональные требования (NRF)

В заключительном разделе SRS подробно описаны нефункциональные требования. В то время как функциональные требования говорят системе, что делать, нефункциональные требования (NFR) определяют, как ваша система будет реализовывать эти функции. Например, функциональное требование может предписывать системе распечатывать упаковочный лист, когда клиент заказывает ваш продукт. NFR же будет гарантировать, что товарная накладная будет распечатана на белой бумаге размером 10x15 см, что является стандартным размером для таких документов. 

Система может работать и без учёта нефункциональных требований, но в этом случае вы рискуете не оправдать ожидания пользователей или заинтересованных сторон. Эти требования позволяют контролировать функциональные требования, поэтому они по-прежнему включают такие атрибуты, как доступность продукта и простота использования. 

Наиболее распространенные типы NFR называются «Itys». К ним относятся:

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

• Емкость: текущие и будущие потребности вашего продукта в хранении данных, включая план масштабирования системы для удовлетворения растущих потребностей в объеме.

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

• Надёжность и доступность: как часто вы ожидаете, что пользователи будут использовать ваше программное обеспечение, и каково критическое время отказа при нормальном использовании. 

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

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

• Удобство использования: насколько легко пользоваться продуктом. 

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

Шаблон документа с требованиями к программному обеспечению

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

Практические рекомендации по составлению спецификации требований к программному обеспечению

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

Добавьте в SRS визуальные элементы

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

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

Будьте ясны и лаконичны

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

• Использовать неопределённые слова, такие как «в целом» или «примерно».

• Не используйте знак «/», который можно интерпретировать как «и» или «или».

• Использовать сложные граничные значения.

• Использование двойных и тройных отрицаний

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

Знайте своего конечного пользователя

Добавьте в SRS результаты полевых исследований и интервью с пользователями, чтобы сформировать чёткое представление о требованиях, ожиданиях и потребностях конечных пользователей. Это поможет вам представить, какие операции конечный пользователь будет выполнять с помощью программного обеспечения. Учитывайте все возможные сценарии и нюансы, которые могут произойти, и включите их в свою SRS. Помните, что разработчики будут реализовывать именно то, что вы включите в докуме��т — ни больше, ни меньше. 

Оставьте место для манёвра

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

Используйте документы с требованиями к программному обеспечению, чтобы прояснить своё видение

Составление SRS — непростая задача, но и бесконечное устранение неполадок или разрешение споров между участниками команды тоже не из лёгких. Работа, которую вы вложите в составление исчерпывающего документа с требованиями к программному обеспечению, окупится созданием потрясающего продукта, которым вы и заинтересованные стороны сможете гордиться.