Спринт 2/14: Разработка требований → Тема 1/4: Требования: что это такое и кто с ними работает → Урок 4/4

Типы требований

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

Даня

Все уровни требований запомнил, можем приступать к работе?

Артём

Подожди, это ещё не все требования, которые нам нужно будет учитывать.

Типы требований

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

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

Все типы требований влияют на проектирование ПО.

Требования к данным

Начнём с требований к данным. Их нет на схеме выше, и сейчас объясним почему.

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

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

Требования к данным, как правило, присутствуют в той или иной степени на всех уровнях требований. Именно поэтому они не упоминаются на схеме как отдельный тип требований.

Бизнес-правила

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

Бизнес-правила:

Не включаются в спецификацию требований к ПО, но иногда их можно добавить в приложение к спецификации. Бизнес-правила не являются требованиями к ПО, так как находятся за пределами ПО.
Влияют на бизнес-требования, пользовательские и функциональные требования к ПО. Бизнес-правила ограничивают их, так как определяют, какими функциями должна обладать система.
Пример бизнес-правила: «Согласно политике компании, оплатить бонусами можно не более 30% стоимости товара».

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

Например, если в процессе работы над требованиями политика компании изменилась: теперь бонусами можно оплатить до 50% стоимости товара. Это значит, что нужно пересмотреть текущие требования и изменить их при необходимости.

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

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

Дата отгрузки заказов не может быть раньше даты заказа.

Бизнес-правило

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

Необходимо сократить сроки отгрузки заказов до одного часа

Бизнес-требование

Требование. Бизнес-цель — сократить сроки отгрузки заказов

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

Бизнес-правило

Правительственное постановление, регулирующее отношения между истцом и ответчиком.

Международные банковские переводы осуществляются посредством SWIFT сообщений

Бизнес-правило

Отраслевой стандарт, регулирующий международные банковские переводы

Требования к системе

Требования к системе — требования к продукту, который содержит множество компонентов или подсистем.

Требования к системе:

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

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

Система необязательно должна содержать ПО. Однако если ПО необходимо для работы системы, оно является одним из её компонентов.

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

Цена продукта на кассе в магазине должна считываться со штрихкода

Требование относится ко всей системе. Штрихкод будет считан сканером, а потом обработан ПО для определения цены продукта.

Аппаратное обеспечение компании работает только на операционной системе Windows

Требование относится ко всей системе. Разрабатываемое ПО также должно быть совместимо с операционной системой Windows.

Сигнал от авиадиспетчера к пилоту должен передаваться в течение трёх секунд

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

Разработчики ПО должны использовать операционную систему Windows

Это требование к проекту.

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

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

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

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

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

Функциональные требования	Нефункциональные требования
Что?	Как?
Пример: Клиент должен получать СМС-оповещение о списании бонусных баллов.	Пример: СМС должно отправляться клиенту в течение пяти секунд (требование, описывающее быструю реакцию системы).

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

Приложение работает безотказно 99% времени.

Это требование к надёжности приложения.

В приложении должна быть возможность проверять статус заказа.

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

Приложение доступно 24/7.

Это нефункциональное требование, которое относится к доступности приложения.

Приложение работает на устройствах iOS и Android, в браузерах Yandex Browser (начиная с версии 22.1.0.2510), Safari (начиная с версии 15.2), Chrome (начиная с версии 96.0.4664).

Это требование к функции переноса/возможности перенести приложение на другие устройства.

Приложение переведено на русский и английский языки.

Это требование к локализации приложения.

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

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

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

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

Бизнес-правило

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

Как пользователь я хочу настроить автоматическое списание платежей через веб-сайт

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

Описывает потребность пользователя настраивать автоматическое списание платежей онлайн.

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

Требование к системе

У этого требования есть бизнес-цель — снизить количество просроченных платежей.

На сайте должна быть возможность выбора карты для списания платежа

Пользовательское требование

Это требование с описанием конкретной функции ПО.

Для приёма платежа платёжной системе необходим CSV-код

Требование к системе

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

Приложение должно поддерживать одновременное списание платежей у 1000 пользователей

Требование к системе

Это требование касается свойств приложения — как именно оно должно поддерживать одновременное списание платежей.

Подведём итоги

В этом уроке мы познакомились с типами требований. Они не относятся к уровням требований, но также влияют на проектирование ПО. Среди типов требований:

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