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

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

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

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

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

Иванна

Менеджер по роботе с клиентами

Contact us, and we will share our case studies related to booking software development

Бесплатная консультация

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

Документ S R S может быть одним из описаний элементов данных контракта или иметь другую форму, определенную организацией.

Обычно SRS пишет технический писатель, системный архитектор или программист.

Зачем использовать SRS-документ?

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

Но это еще не все:

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

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

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

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

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

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

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

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

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

Функциональные требования состоят из двух частей: функции и поведения. Функция - это то, что делает система (например, "рассчитать налог с продаж"). Поведение определяется тем, как система это делает (например, "система должна рассчитывать налог с продаж путем умножения цены покупки на ставку налога").

Типы функциональных требований

Вот самые распространенные типы функциональных требований:

• Бизнес-правила
• Требования к сертификации
• Требования к отчетности
• Административные функции
• Уровни авторизации
• Отслеживание аудита
• Внешние интерфейсы внешние интерфейсы
• Управление данными
• Законодательные и регуляторные требования

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

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

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

Структура документа SRS

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

1. Введение

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

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

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

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

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

Описание с ограничениями. Такими ограничениями могут быть, например, такие вещи:

• Язык программирования, база данных
• Стандарты кодирования
• Коммуникационные стандарты
• Ограничения, которые могут быть наложены бизнес-логикой проекта

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

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

Мы называем функцию для проекта и даем ей уникальный идентификатор. Например, server.html.editor.

Системные возможности\Системная возможность X\Описание и приоритет. Мы подробно описываем возможности продукта. Для чего нужно? Что я должен делать? Какой приоритет ее выполнения? Из этого раздела человек, читающий CRS, должен сразу понять, для чего эта функциональность присутствует в системе.

Функции системы\Функция X\Последовательности стимулов/ответов Функция запуска триггера. Когда она запускается и как она ведет себя после запуска? Например, редактор HTML показывается, когда пользователь нажимает на ссылку меню Открыть редактор HTML

Функции системы\Функция X\Функциональные требования Подробное и подробное описание функции. Мы описываем все: как она работает, как реагирует на ошибки, что должна проверять, как отображать данные, как и куда сохраняет и т.д.

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

Описание того, как система будет взаимодействовать с внешним миром. Какие API, как получать те или иные данные и т.д. Подразделы служат для детализации требований. Какие программные интерфейсы, "аппаратные" интерфейсы, коммуникационные интерфейсы и т.д.?

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

Не функциональные требования. Некоторые требования не могут быть описаны как определенная функция, например, требования безопасности.

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

Нефункциональные требования\Атрибуты качества программного обеспечения Здесь мы описываем требования к качеству кода. Какие тесты использовать? Какие метрики использовать для определения качества кода?

Нефункциональные требования\Требования к безопасности Требования к безопасности. Если это HTML-редактор, через который можно что-то менять на сайте, то это может быть что-то вроде: через HTML-редактор не должно быть возможности поставить оболочку на сервер и т.д.

5. Предварительное расписание и бюджет

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

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

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

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

1. Создайте план на основе ваших целей

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

2. Определите цель вашего продукта

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

Целевая аудитория и целевое использование

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

• Сфера применения продукта
• преимущества
• задачи
• цели

Это должно быть связано с бизнес-целями.

Определения и аббревиатуры

Вы должны определить риски проекта в SRS в инженерии программного обеспечения. Что может пойти не так? Как я могу с этим справиться? Кто отвечает за элементы риска?

Например, если неисправность медицинского устройства может привести к травме, это один уровень риска. Зная уровень возникновения и серьезность, мы можем создать стратегию для минимизации этого риска.

3. Опишите свой продукт

Следующим шагом является описание продукта. Это новый тип продукта? Или это расширение продукта, который вы уже создали? Будет ли он интегрирован с другим продуктом? Для кого он предназначен?

Примеры требований пользователей

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

Предположения и зависимости

Какие предположения будут верными? Берем ли мы реальную технологию? Является ли основой фреймворк Windows? Вам нужно сделать предположения, чтобы лучше понять, когда ваш продукт выйдет из строя или не будет работать безупречно.

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

4. Детализируйте свои специфические требования

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

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

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

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

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

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

Типы интерфейсов:

• Пользовательский
• Аппаратный
• Программное обеспечение
• Коммуникации

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

Включают

• Производительность
• Безопасность
• Качество

5. Представление на утверждение

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

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

• Более четкие коммуникации
• Снижение затрат на техническую поддержку
• Уменьшение расходов на документацию
• Основная работа технического писателя - написание требований к программному обеспечению

Как SRS зависит от подхода к управлению проектом

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

Waterfall

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

Agile

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

Scrum

Скрам сочетает в себе элементы классического процесса с идеями гибкого подхода к управлению проектами. Результат - сочетание гибкости и структурированности.

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

Вывод

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

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