Решения Visure


Поддержка
Зарегистрируйтесь
Логин
Начните бесплатную пробную версию

Как написать документы системных требований (SRS)

Как написать документы системных требований (SRS)

Содержание

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

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

Спецификация требований к программному обеспечению против спецификации бизнес-требований

Люди иногда смешивают концепции программного обеспечения и спецификаций бизнес-требований. На самом деле они оба совершенно разные.

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

#
Спецификация требований к программному обеспечению (SRS)
Спецификация бизнес-требований (BRS)
1.
Он определяет функциональные и нефункциональные требования, которые присутствуют в программном обеспечении.
Это официальный документ, в котором описываются различные требования, предъявляемые клиентом/заинтересованными сторонами.
2.
Он основан на Спецификации бизнес-требований (BRS).
Он выводится из требований и взаимодействий клиента.
3.
Он создается системным аналитиком, системным архитектором или бизнес-аналитиком.
Он создается бизнес-аналитиком.
4.
В нем также на высоком уровне описаны как технические, так и функциональные характеристики программного обеспечения.
Он описывает функциональные характеристики программного обеспечения на очень высоком уровне.
5.
Он имеет дело с ресурсами, которые предоставляет компания.
Он имеет дело с бизнес-требованиями.
6.
Он описывает, как бизнес функционирует при использовании программного обеспечения или приложения.
Он определяет потребности клиента. Документ используется от начала до конца проекта.
7.
Таблицы и варианты использования включены.
Таблицы и варианты использования не включены.

Основные компоненты SRS

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

  • Бизнес Драйверы – В этом разделе описаны причины, по которым заказчик хочет построить систему. Этот раздел также включает проблемы, с которыми клиент сталкивается при использовании текущей системы, и возможности, которые предоставит новая система.
  • Бизнес-модель – В этом разделе обсуждается бизнес-модель, которую должна поддерживать система. Кроме того, он включает различные другие детали, такие как организационный и бизнес-контекст, основные бизнес-функции и блок-схемы процессов системы.
  • Функциональные и системные требования – В этом разделе обычно подробно описываются требования, которые организованы в иерархическую структуру. Функциональные требования находятся на верхнем уровне, а подробные системные требования перечислены в виде подпунктов.
  • Варианты использования системы – Этот раздел состоит из схемы вариантов использования унифицированного языка моделирования (UML), объясняющей все ключевые внешние объекты, которые будут взаимодействовать с системой, и различные варианты использования, которые им придется выполнять.
  • Технические требования – В этом разделе обсуждаются все нефункциональные требования, составляющие техническую среду, и технические ограничения, в которых будет работать программное обеспечение.  
  • Системные качества – В этом разделе определяются многочисленные качества системы, такие как надежность, удобство обслуживания, безопасность, масштабируемость, доступность и ремонтопригодность.
  • Ограничения и предположения – В этом разделе описаны все ограничения, накладываемые на конструкцию системы с точки зрения заказчика. Здесь также обсуждаются различные предположения инженерной группы о том, чего ожидать во время разработки.
  • Критерии приема – Подробная информация обо всех условиях, которые должны быть выполнены перед передачей системы конечным потребителям, обсуждаются в этом разделе.

Структура СГД

1. Введение -

Во введении объясняется значение SRS в целом, его возможности для вашей команды и его структура.

1.1. Цель

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

Этот раздел должен быть коротким: достаточно 1-2 абзацев.

1.2. Целевая аудитория

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

1.3. Использование по назначению

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

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

1.4. Объем

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

В этом разделе должны быть описаны:

  • Ожидается, что все типы пользователей будут взаимодействовать с системой
  • Все основные части архитектуры

1.5 Определения и сокращения

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

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

2. Общее описание

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

2.1 Потребности пользователей

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

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

2.2 Допущения и зависимости

Предположения — это предположения команды о продукте и его возможностях, которые будут правильными в 99% ситуаций. Естественно предположить, например, что платформа, помогающая водителям ориентироваться в ночное время, будет использоваться преимущественно в ночном режиме.

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

3. Особенности системы и требования

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

3.1 Функциональные требования

указываются в списке функций, которые будут выполняться в системе. Эти критерии касаются вопроса «что будет создано?» а не "как" и "когда".

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

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

Функциональные требования составляют значительную часть спецификации системных требований. Чтобы охватить все необходимые функции системы, вам понадобится 4-5 страниц информации. Некоторые команды разбивают их по темам, чтобы документ было легче читать.

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

В зависимости от проекта требования к внешнему интерфейсу могут состоять из четырех типов:

  • Интерфейс пользователя
  • Программный интерфейс
  • Аппаратный интерфейс
  • Интерфейс связи

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

3.3 Системные требования

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

Создание системных требований перед началом создания продукта может показаться сложным, но это необходимо. Разработчики должны придерживаться требований к оборудованию, чтобы им не пришлось перезапускать проект позже. Мобильные приложения (с множеством переменных, которые необходимо учитывать) и приложения, требующие высокой реактивности (игры, любой продукт с VR/AR или IoT), особенно уязвимы.

3.4 Нефункциональные требования 

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

Настоящая ценность заключается в том, что трудно определить нефункциональные требования. Дать определение таким фразам, как «параллелизм» или «переносимость», сложно, поскольку они могут иметь различное толкование для всех вовлеченных сторон. В результате мы выступаем за присвоение каждому нефункциональному требованию оценки. Вы можете пересмотреть требования вашего проекта в любое время, чтобы увидеть, удовлетворяет ли текущая система первоначальным ожиданиям.

Каких ошибок следует избегать при составлении спецификации системных требований?

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

  • Пренебрежение включением всеобъемлющего глоссария: Содержит ли ваша SRS жаргон, с которым знакомы только люди в отрасли? Если это так, создайте простой для понимания раздел словаря и включите в него определения любых малоизвестных слов или выражений. Это поможет всем пользователям понять как цель документа, так и терминологию.
  • Создание беспорядка путем объединения идей: Структурируйте свой документ упорядоченным образом и доставляйте информацию читателям в логической последовательности. Во избежание недопонимания или путаницы не смешивайте концепции по всему тексту.
  • Незнание потребностей и желаний целевой аудитории: Чтобы понять ожидаемый результат от программного обеспечения, важно понять, кто будет его использовать, а также какие результаты ожидаются. Например, предположим, что приложение было создано для создания отчетов. Некоторые из его требований должны подразумевать, как пользователи могут нажимать определенные кнопки для получения различных документов. Чтобы по-настоящему понять, что требуется от этой программы отчетности, а также определить, кто будет ее использовать, вы должны иметь представление как о пользователях, так и об их ожиданиях в отношении функциональности.  
  • Быть двусмысленным: Убедитесь, что ваши потребности однозначны. SRS сформулирован так, чтобы избежать недоразумений, поэтому очень важно убедиться, что документ не вызывает путаницы. Для каждой функции или описания условия убедитесь, что вы не включаете функции, которые еще не были указаны.

Лучшие практики написания документов SRS

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

  • Используйте ясный и краткий язык:
    • Избегайте технического жаргона и сокращений, которые не всегда понятны. Используйте ясный и понятный язык, гарантируя, что все заинтересованные стороны смогут легко понять содержание.
  • Включите наглядные пособия:
    • Улучшите понимание, включив диаграммы, блок-схемы и макеты вместе с текстовыми описаниями требований. Визуальные средства могут обеспечить более интуитивное представление сложных концепций и поведения системы.
  • Приоритетные требования:
    • Четко определите приоритет каждого требования. Используйте такие ярлыки, как «необходимо», «должно быть» и «неплохо иметь», чтобы указать относительную важность различных функций. Расстановка приоритетов помогает команде разработчиков сосредоточиться в первую очередь на критически важных функциях.
  • Держите его в курсе:
    • Поддерживать контроль версий документа SRS. Регулярно обновляйте документ, чтобы отразить любые изменения в требованиях проекта, его объеме или отзывах заинтересованных сторон. Ведите четкий журнал изменений, чтобы отслеживать изменения с течением времени.
  • Вовлекайте заинтересованные стороны:
    • Тесно сотрудничать со всеми соответствующими заинтересованными сторонами на протяжении всего процесса разработки SRS. Участвуйте в обсуждениях, собирайте отзывы и следите за тем, чтобы их потребности и ожидания были точно отражены в документе. Такое участие способствует общему пониманию целей проекта.
  • Будьте всеобъемлющими:
    • Не оставляйте места для интерпретаций и предположений. Предоставьте подробное и исчерпывающее описание каждого требования, включая функциональные и нефункциональные аспекты. Двусмысленность в требованиях может привести к недоразумениям и задержкам проекта.
  • Используйте структурированный формат:
    • Организуйте документ SRS в четко определенные разделы, такие как «Введение», «Требования заинтересованных сторон», «Архитектура системы», «Функциональные требования», «Нефункциональные требования», «Ограничения», «Допущения», «Зависимости» и «Матрица прослеживаемости». Структурированный формат облегчает читателям поиск конкретной информации.
  • Обеспечьте тестируемость:
    • Пишите требования таким образом, чтобы облегчить тестирование и проверку. Каждое требование должно быть проверяемым, что позволит тестировщикам создавать тестовые сценарии, проверяющие, соответствует ли система указанным критериям. Четкие критерии приемлемости для каждого требования имеют важное значение.
  • Избегайте двусмысленности:
    • Будьте бдительны, устраняя двусмысленность в требованиях. Используйте точный язык, избегайте расплывчатых терминов и следите за тем, чтобы не было места для множественных интерпретаций требований. Неясности могут привести к недопониманию и переработке проекта.
  • Учитывайте будущую масштабируемость:
    • Подумайте о долгосрочной масштабируемости программной системы. Предусмотрите потенциальные будущие потребности и убедитесь, что документ SRS их учитывает. Такой упреждающий подход может сэкономить время и ресурсы в будущем.
  • Просмотрите и подтвердите:
    • Проведите тщательную проверку документа SRS с заинтересованными сторонами, включая клиента, команду разработчиков и профильных экспертов. Устраните любые несоответствия, несоответствия или двусмысленности, возникающие в процессе проверки. Валидация гарантирует, что документ точно отражает цели проекта.
  • Получите официальное одобрение:
    • После завершения разработки документа SRS получите официальное одобрение и подпись от клиента или спонсора проекта. Это формализует соглашение о масштабах и требованиях проекта, обеспечивая четкую основу для разработки.

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

Заключение

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

Не забудьте поделиться этим постом!

Топовое