Виды требований 

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

«Когда группа людей начинает обсуждать требования, они обычно начинают с проблемы терминологии. Разные эксперты, говоря об одном и том же документе, могут называть его пользовательскими требованиями, требованиями к ПО, бизнес-требованиями, функциональными требованиями, системными требованиями, требованиями к продукту или проекту, пользовательской точкой зрения, функцией или ограничением. Имена, которые они применяют к различным требованиям, также различаются.

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

Вигерс К., Битти Д. Разработка требований к программному обеспечению //М.: Русская редакция. – 2004.

Но какие все-таки по существу бывают требования и чем они отличаются друг от друга?

Широко цитируемые авторы профессиональной литературы, отраслевые методологи и эксперты, международные и российские стандарты предлагают различные способы классификации требований. Учитывая, что все классификации естественным образом проистекают из попыток систематизировать типовые процессы и деятельность участников команды разработки они по своей сути очень схожи. Наиболее авторитетными источниками являются международные стандарты IEEE 830 (1998 и 2011) и ISO/IEC/IEEE 29148 (2018), предлагающие универсальные рекомендации для разработки требований. 

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

Определение разных видов требований

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

(вместо функций сделать бизнес требования)

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

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

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

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

«В CRM должна быть предусмотрена возможность просмотра данных о продажах менеджера за месяц» - это утверждение содержит в себе желаемые возможности использования системы. 

Более частные требования, соответственно являются производными от бизнес-требований и пользовательских требований и пытаются ответить на вопросы "как это может быть реализовано?": 

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

«При нажатии на "Отобразить завершенные продажи" должны отображаться продажи только со статусом "Завершена"» - это пример функционального требования.   

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

«Ежедневно должны создаваться резервные копии данных о продажах» - это пример нефункционального требования.   

В последующих уроках каждый вид требований будет более подробно рассмотрен. 

Иерархия требований

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

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

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

Рассмотрим пример связанных требований, которые могут относиться к разработке различных компонентов системы:

  1. Бизнес-требование: Конфиденциальные данные клиентов, хранящиеся в CRM-системе должны быть защищены от утечек информации.

  2. Пользовательское требование: Доступ к конфиденциальным данным должен осуществляться только после успешной аутентификации.

  3. Функциональное требование: Должны быть реализованы механизмы аутентификации при помощи использования других внутрикорпоративных систем через SSO (Single Sign-On).

  4. Нефункциональное требование: Защита передаваемых данных должна осуществляться с использованием шифрования TLS/SSL и обеспечение защиты от атак, таких как инъекции SQL и CSRF (межсайтовая подделка запросов).

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

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

Соотнесение требований и результатов разработки 

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

На рисунке 1.2 эта связь представлена в контексте каждого этапа разработки. V-модель также иллюстрирует разные уровни разработки, где каждый уровень соответствует определённому этапу. Хотя процессы на каждом уровне могут незначительно отличаться, основной принцип использования требований остаётся неизменным, что будет детально рассмотрено во второй главе. На рисунке 1.3 показано, как инженерия требований фокусируется на каждом из уровней разработки.

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

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

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

  1. Требования заинтересованных сторон

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

  2. Требования к системе в целом

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

  3. Требования к компонентам

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

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

Резюме

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

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

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