# Шаблон документа с требованиями к программному обеспечению: бесплатные этапы SRS > Скачайте шаблон документа с требованиями к программному обеспечению от Asana и узнайте, как составить SRS, используя ключевые разделы, примеры и лучшие практики для согласованной работы команды. Source: https://asana.com/resources/software-requirement-document-template ## Как составить документ с требованиями к программному обеспечению (с шаблоном) #### Сводная информация Спецификация требований к программному обеспечению (SRS) — это комплексный план разработки программного обеспечения, в котором подробно описано, как должен работать продукт, и который направляет вашу команду разработчиков в процессе создания. В этом руководстве рассматриваются основные компоненты документа SRS, включая бизнес-требования, потребности конечных пользователей и технические спецификации, а также приводятся пошаговые инструкции по его созданию и лучшие практики, позволяющие обеспечить согласованность действий межфункциональных команд на протяжении всего процесса разработки. Иногда крайне важно, чтобы отделы, находящиеся на противоположных концах организации, работали вместе, даже если они говорят на разных технических языках. Если вы когда-либо работали в [межфункциональной команде](/resources/cross-functional-team), вы знаете, как сложно бывает держать всех в курсе происходящего. Документы со спецификацией требований к программному обеспечению могут помочь менеджерам проектов, менеджерам продуктов и бизнес-аналитикам разбить общие концепции на задачи, которые каждый участник команды может выполнять в процессе разработки. В этом руководстве мы расскажем, что такое документ SRS, что в него включить, как его написать пошагово, а также поделимся лучшими практиками, которые помогут вашей команде работать над достижением общей цели. ## Что такое документ со спецификацией требований к программному обеспечению (SRS)? Документ спецификации требований к программному обеспечению (SRS) — это подробное описание того, как должен работать программный продукт и как ваша команда разработчиков должна его создавать. В нём перечислены требования, ожидания, дизайн и стандарты для будущего проекта, в том числе: - **Бизнес-требования:** цели высокого уровня, определяющие цель проекта - **Требования конечного пользователя:** потребности и ожидания вашей целевой аудитории - **Технические спецификации:** функциональность продукта, описанная в технических терминах Представьте, что у вас есть отличная идея для приложения. У вас есть видение того, что оно должно делать и как должно выглядеть, но вы знаете, что не можете просто дать устное описание разработчику и ожидать, что он оправдает ваши ожидания. Здесь на помощь приходит SRS. - [Бесплатный шаблон требований к программному обеспечению](https://asana.com/resources/download-software-requirement-template) ## Зачем использовать SRS? Если у разработчиков нет чётких указаний при создании [нового продукта](/resources/product-development-process), вы можете потратить больше времени и средств, чем ожидали, пытаясь добиться того, чтобы программное обеспечение соответствовало вашим представлениям. Документ SRS помогает избежать этого, предоставляя единый источник достоверной информации для всей вашей команды. Основные преимущества использования SRS: - **Согласованность между командами:** от маркетинга до технического обслуживания все работают на основе одного и того же набора требований - **Чёткое общение:** у заинтересованных сторон есть единый ориентир на протяжении всего процесса разработки - **Отслеживание изменений:** по мере выполнения итераций продукта все стороны могут проверять обновления в документе, чтобы избежать путаницы Если ваша команда всё ещё определяет более широкий бизнес-контекст, лежащий в основе вашего программного обеспечения, объедините SRS с [шаблоном документа бизнес-требований](/templates/business-requirements-document), чтобы определить цели, объём и показатели успешности, прежде чем документировать технические детали. ## Что должно быть в документе SRS Базовая структура документа SRS состоит из четырёх частей: введения, системных и функциональных требований, требований к внешнему интерфейсу и нефункциональных требований. ### 1. Введение Введение в SRS — это именно то, что вы ожидаете: общий обзор всего проекта. При написании введения опишите назначение продукта, целевую аудиторию и то, как эта аудитория будет его использовать. Во введении обязательно укажите: - **Область применения продукта:** [область применения](/resources/scope-management-plan) должна быть связана с общими бизнес-целями продукта, что особенно важно, если доступ к документу будет у нескольких команд или подрядчиков. Перечислите преимущества, задачи и цели, предусмотренные для продукта. - **Ценность продукта:** почему ваш продукт важен? Как он поможет вашей целевой аудитории? Какую функцию он будет выполнять или какую проблему решит? - **Целевая аудитория:** опишите свою идеальную аудиторию. Она будет определять эстетические аспекты вашего продукта и то, как вы будете его продвигать. - **Предполагаемое использование:** представьте, как ваша аудитория будет использовать продукт. Перечислите предоставляемые вами функции и все возможные способы использования вашего продукта вашей аудиторией в зависимости от её роли. - **Определения и аббревиатуры:** в каждой отрасли или компании есть свои уникальные аббревиатуры или жаргон. Приведите определения терминов, которые вы используете в SRS, чтобы все стороны понимали, что вы хотите сказать. - **Содержание:** подробный документ SRS, скорее всего, будет очень длинным. Добавьте оглавление, чтобы все участники могли найти именно то, что им нужно. Введение должно быть чётким и лаконичным. Помните, что введение задаст тон для остальной части SRS, и важно, чтобы все, кто будет использовать документ, интерпретировали его одинаково. ### 2. Системные и функциональные требования После введения пора перейти к более конкретным вопросам. Функциональные требования описывают особенности и функции, которые позволяют вашей системе работать по назначению. Используйте обзор в качестве ориентира, чтобы убедиться, что ваши требования соответствуют основным потребностям пользователя, когда будете вносить детали. К числу самых распространённых функциональных требований относятся: - Поведение по принципу «если/то» - Логика обработки данных - Системные рабочие процессы - Обработка транзакций - Административные функции - Нормативные требования и требования соответствия - Требования к производительности - Детали операций, выполняемых для каждого экрана Если это кажется неподъёмным, попробуйте заниматься требованиями по одному. Чем больше деталей вы включите в документ SRS, тем меньше проблем вам придётся решать впоследствии. По мере того как вы углубляетесь в детали требований, так же важно, чтобы ваши вспомогательные материалы были последовательными и простыми для понимания. Шаблон [технической документации](/templates/technical-documentation) может сэкономить время, сократить количество ошибок и обеспечить наличие чётких и актуальных инструкций для всех. ### 3. Требования к внешнему интерфейсу Требования к внешнему интерфейсу — это типы функциональных требований, которые обеспечивают надлежащее взаимодействие системы с внешними компонентами, такими как: - **Пользовательские интерфейсы:** ключ к удобству использования приложения, который включает, помимо прочего, представление контента, навигацию по приложению и помощь пользователю. - **Аппаратные интерфейсы:** характеристики каждого интерфейса между программными и аппаратными компонентами системы, такие как поддерживаемые типы устройств и протоколы обмена данными. - **Программные интерфейсы:** соединения между вашим продуктом и другими программными компонентами, включая базы данных, библиотеки и операционные системы. - **Интерфейсы обмена данными:** требования к функциям обмена данными, которые будет использовать ваш продукт, например, электронные письма или встроенные формы. Встроенные системы зависят от требований к внешнему интерфейсу. Вам следует включить такие элементы, как макеты экрана, функции кнопок и описание того, как ваш продукт зависит от других систем. ### 4. Нефункциональные требования (NFR) В заключительном разделе вашего SRS подробно описаны нефункциональные требования. В то время как функциональные требования указывают системе, что делать, нефункциональные требования (NFR) определяют, как ваша система будет реализовывать эти функции. Функциональные требования Нефункциональные требования Определяют, что делает система Определяют, как работает система Пример: печать товарной накладной, когда клиент размещает заказ Пример: распечатать товарную накладную на белой бумаге размером 4 x 6 дюймов Сосредоточьтесь на функциях и возможностях Сосредоточьтесь на таких качественных характеристиках, как скорость, безопасность и удобство использования Хотя система может работать и в том случае, если вы не выполните NFR, вы рискуете не оправдать ожидания пользователей или заинтересованных сторон. Эти требования контролируют функциональные требования, поэтому они по-прежнему включают такие атрибуты, как доступность продукта и простота использования. Самые распространённые типы NFR называются «Itys». Вот они: - **Безопасность:** что необходимо для обеспечения защиты любой конфиденциальной информации, которую ваше программное обеспечение собирает у пользователей? - **Способность:** нынешние и будущие потребности вашего продукта в объёме хранилища, включая план того, как ваша система будет масштабироваться для удовлетворения растущих потребностей. - **Совместимость:** минимальные требования к оборудованию для вашего программного обеспечения, такие как поддержка операционных систем и их версий. - **Надёжность и доступность:** как часто, по вашим ожиданиям, пользователи будут использовать ваше программное обеспечение и каково критическое время отказа при нормальном использовании. - **Масштабируемость:** максимальные рабочие нагрузки, при которых ваша система будет по-преж работать так, как ожидается. - **Ремонтопригодность:** как ваше приложение должно использовать непрерывную интеграцию, чтобы вы могли быстро развертывать функции и исправлять ошибки. - **Удобство использования:** насколько легко пользоваться продуктом, что часто подтверждается [тестированием удобства использования](/templates/usability-testing). К другим распространённым типам нефункциональных требований относятся требования к производительности, нормативные требования и требования к окружающей среде. ## Как написать документ SRS Первый шаг — понять, что должно быть в SRS. Следующий шаг — собрать всё воедино. Следование чёткому процессу поможет вам не упустить ни одной критически важной детали и обеспечить согласованность действий всех заинтересованных сторон с самого начала. Вот простой пошаговый подход к написанию эффективного документа SRS: - **Создайте набросок.** Прежде чем приступить к написанию, создайте структуру документа. Вы можете использовать наш шаблон документа с требованиями к программному обеспечению в качестве отправной точки, чтобы подготовить все необходимые разделы. - **Определите назначение и область применения продукта.** В сотрудничестве с заинтересованными сторонами чётко определите, для чего предназначен продукт, кто будет его использовать и какую ценность он принесёт бизнесу. Эта информация ляжет в основу вашего введения. - [Соберите требования](/resources/requirements-gathering)**от всех заинтересованных сторон.** Опросите конечных пользователей, руководителей бизнеса и команду разработки, чтобы понять их потребности и ожидания. Это поможет обеспечить, чтобы конечный продукт решал нужные проблемы для нужных людей. - **Детализируйте функциональные и нефункциональные требования.** Это самая подробная часть документа. Чётко опишите, что должна делать система (функциональные требования), и стандарты качества, которым она должна соответствовать (нефункциональные требования), такие как производительность и безопасность. - **Получите обратную связь и Подтверждение.** Поделитесь черновиком со всеми заинтересованными сторонами для проверки; [реестр заинтересованных](/templates/stakeholder-register) лиц поможет не упустить ни одного ключевого рецензента. Формальный процесс рассмотрения помогает выявить любые неясности или разногласия на раннем этапе, что позволяет сэкономить время и ресурсы в дальнейшем. ## Шаблон документа с требованиями к программному обеспечению Готовы начать свой собственный проект по разработке программного обеспечения? На этапе [инициации проекта](/resources/project-initiation) ваш SRS послужит основой для разработки. Наш шаблон SRS охватывает все четыре ключевых компонента отличного документа SRS, предоставляя вам и вашей команде ценную аналитику о продукте, который вы будете разрабатывать. Не забудьте, что требования должны быть подробными, чёткими и лакорактными, чтобы у всех сторон было общее видение. ## Лучшие практики по написанию документа SRS Цель SRS — обеспечить, чтобы каждая команда в каждом отделе работала над достижением чёткой цели. При этом есть несколько лучших практик, которым следует следовать, чтобы ваш SRS выполнял свою задачу. ### Дополните SRS визуальными материалами Включение визуальных элементов, таких как диаграммы, схемы и модели, поможет членам команды лучше понять процесс. Они особенно полезны при иллюстрации основных функций и работоспособности вашего программного обеспечения. Один из методов, который можно попробовать при мозговом штурме по проекту, — это составление ментальной карты, которая позволяет упорядочить идеи, функции и сценарии и проследить связи между ними. Создайте ассоциативную карту, чтобы структурировать свои мысли, объединяя идеи. Сосредоточьтесь на основных функциях программного обеспечения и на том, как они связаны друг с другом; подробные спецификации будут указаны в SRS позже. - [Читать статью «Двадцать девять методик коллективного обсуждения: эффективные способы раскрытия творческого потенциала»](/resources/brainstorming-techniques ) ### Будьте ясны и лаконичны Последнее, чего вы хотите, — это чтобы ваши разработчики сомневались в себе при создании вашего продукта. Постарайтесь не оставлять участникам команды возможности проявить творческий подход и заполнить пробелы. При описании требований к программному обеспечению укажите как можно больше деталей и избегайте: - Использования расплывчатых слов, таких как «_в целом»_ или _«примерно»_ - Объединения терминов с помощью символа «/», который может быть истолкован как «и» или «или» - Использования сложных граничных значений - Использования двойного и тройного отрицания Официальная экспертная оценка — это хороший способ выявить неясности в вашем документе SRS. Запланируйте его рассмотрение с каждым участником, чтобы сравнить понимание требований и внести необходимые изменения. ### Знать своего конечного пользователя Добавьте в SRS результаты полевых исследований и интервью с пользователями, чтобы обеспечить чёткое понимание требований, ожиданий и потребностей конечных пользователей. Учитывайте все возможные сценарии и нюансы, потому что ваши разработчики будут реализовывать именно то, что вы включите в документ, ни больше, ни меньше. ### Оставьте место для гибкости Ваше SRS — это живой документ, то есть вы будете добавлять новые функции и изменения с каждой итерацией. Учитывайте это, сохраняя гибкость требований на случай, если результат не будет соответствовать вашим ожиданиям. Эффективное [управление требованиями](/resources/requirements-management) включает в себя ведение учёта всех изменений во избежание недоразумений. Участники должны иметь возможность проследить каждое требование до его первоначальной версии и увидеть, кто, когда и почему внес изменение. ## Используйте документы с требованиями к программному обеспечению, чтобы прояснить свою концепцию Создать SRS непросто, но и бесконечное устранение неполадок или разрешение споров между участниками команды — тоже непростая задача. Работа, которую вы вложили в составление исчерпывающего документа со спецификациями требований к программному обеспечению, окупится потрясающим продуктом, которым вы и ваши заинтересованные стороны сможете гордиться. Готовы внести ясность в свой следующий проект по разработке программного обеспечения? [Начните работу](/create-account) с Asana, чтобы управлять SRS вместе с задачами проекта, обеспечивая согласованность действий всей команды от требований до запуска. ## Часто задаваемые вопросы о документах с требованиями к программному обеспечению #### Каковы ключевые элементы документа с требованиями к программному обеспечению? Комплексный документ SRS включает четыре основных раздела: введение, функциональные требования, нефункциональные требования и требования к внешнему интерфейсу. #### В чём разница между SRS и BRD? В BRD объясняется_, зачем_ нужен проект, и излагаются общие бизнес-цели, а в SRS подробно _описываются_ технические и функциональные спецификации, необходимые команде разработчиков. #### Какого объема должен быть документ SRS? Фиксированного объёма нет; он зависит от сложности вашего программного обеспечения. Цель состоит в том, чтобы изложить информацию тщательно и ясно, а не в том, чтобы уложиться в определённое количество страниц. #### Кто отвечает за написание документа SRS? Составлением SRS обычно руководит менеджер проекта, менеджер по продуктам или бизнес-аналитик, который собирает информацию от разработчиков, дизайнеров, команд по обеспечению качества и руководителей компании. - [Управление проектами](/resources/project-management) - [ССВУ-анализ: что это и как им пользоваться (с примерами)](/ru/resources/swot-analysis) Управление проектами Планирование проектов #### Автор текстов Ищете способ выделить свою компанию среди конкурентов? ССВУ-анализ — это техника, используемая организациями для распознавания сильных и слабых сторон, возможностей и угроз в целя ... - [Восемь шагов по созданию плана действий в непредвиденных обстоятельствах](/ru/resources/contingency-plan) Бизнес-стратегия Планирование проектов #### Автор Никому не хочется, чтобы основной план провалился. Но иметь хорошо проработанный план Б — лучший способ быть готовым к любой ситуации. Если у вас есть полноценный резервный план, ... - [Повышение эффективности организационного совещания по проекту за 10 действий](/ru/resources/project-kickoff-meeting) Планирование проектов #### Автор Вы вложили массу усилий в запуск своего проекта, однако порой кажется, что проект сходит с намеченного пути ещё до своего начала. Это связано с тем, что все участники и заинтересо ... - [Что такое анализ заинтересованных лиц и почему он важен?](/ru/resources/project-stakeholder) Управление проектами Планирование проектов #### Автор Представьте, что ваш проект — это фильм, претендующий на «Оскар». Вы победили и теперь должны подняться на сцену и произнести торжественную речь. Кого вы будете благодарить?В упра ... - [How to write a software requirement document (with template)](/ru/resources/software-requirement-document-template) Планирование проектов Управление проектами - [Автор текстов](/author/team-asana) Иногда крайне важно, чтобы отделы, находящиеся на противоположных концах организации, работали вместе, даже если они говорят на разных технических языках. Если вы когда-либо работ ...