Юлий Минькин, руководитель проектного офиса
При создании автоматизированных систем (АС) и разработке программного обеспечения, требования играют ключевую роль. Они определяют, какие функции должны выполняться в программном обеспечении, что еще необходимо для работы пользователей и бесперебойного функционирования АС. Наличие четких и понятных требований является критически важным для успеха проекта, ведь без них, участники проекта не смогут создать качественное ПО, которое соответствует ожиданиям пользователей, в рамках отведенных сроков и бюджета.
Есть одна существенная проблема, которая зачастую мешает эффективной работе с требованиями в процессе выполнения проекта - это разное толкование этого понятия. Это проблема возникла не на пустом месте, понятий термина “требование” действительно много и разобраться в них, даже подготовленному специалисту, не просто.
Например, несколько определений, которые упоминаются в общеизвестных источниках:
- согласно ГОСТ Р 59194-2020, требование - требуемая (ожидаемая) количественная или качественная характеристика или свойство объекта, а также связанные ограничения и условия.
- согласно ISO 9000:2015, требование - это потребность или ожидание, которое установлено, обычно предполагается или является обязательным. согласно Rational Unified Process (RUP), требование - это условие или возможность, которой должна соответствовать система.
- IEEE 830-1998 (Институт Инженеров по Электротехнике и Радиоэлектронике) трактует требование более комплексно: условия или возможности, необходимые пользователю для решения проблем или достижения целей.
условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам.
документированное представление условий или возможностей для пунктов 1 и 2.
Как видно из приведенных определений, есть, по сути, два толкования этого термина:
- требование пользователя, которая выражается через его потребность или ожидание.
- требование к системе.
Таким образом, зачастую проектные команды, выполняющие проект по заданной технологии, не понимают, на каком этапе проектных работ с какими видами требований им предстоит работать.
На мой взгляд, лучше всего работу с требованиями осветил Карл Вигерс [1], в соавторстве с Битти Джой.
Карл Вигерс (Karl Wiegers) - американский специалист в области разработки программного обеспечения и автор нескольких книг, посвященных этой теме. Он является экспертом в области управления требованиями и процессами разработки ПО. Карл Вигерс также работал в качестве консультанта по вопросам разработки программного обеспечения для различных компаний и организаций. Его книги, включая "Разработка требований к программному обеспечению", являются популярными среди разработчиков ПО и проектных менеджеров.
Есть еще одно обстоятельство, осложняющее эту проблему. В РФ существует, и широко применяется, свой национальный стандарт (ГОСТ), регламентирующий технологию создания АС. В документах, относящихся к ГОСТ 34, понятие “требование” также затрагивается, но, к сожалению, не раскрывается достаточно, чтобы работать с ними без осложнений.
ГОСТ 34 - это сленговое выражение для обозначения пакета национальных стандартов Российской Федерации, которые используются при создании автоматизированных систем (на основании цифры 34, входящей систему обозначения большинства этих документов).
В этой статье мы рассмотрим, как требования, описанные и систематизированные Карлом Вигерсом, соотносятся с употреблением этого термина в действующих документах ГОСТ 34. Что должно привести читателя к более глубокому пониманию работы с требованиями, в отечественной практике.
Описание требований у К.Вигерса
Что касается работы К.Вигерса, то он сам не дает определение понятия “требование", а ссылается на “любимую” формулировку, предложенную Иеномом Соммервиллем и Питом Сойером:
Требования это спецификация того, что должно быть реализовано. В них описано поведение системы, свойства системы или ее атрибуты. Они могут служить ограничениями в процессе разработки системы.
При этом, в его работе есть подробная классификация и описание уровней и видов требований (рис.1)
Как видно из рисунка 1, автор выделяет три уровня, которые включают следующие виды требований и ограничений:
- Бизнес-требования (business requirements) - содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансирует проект, т.е. спонсоры АС (собственники бизнеса или топ-менеджеры). Например, предприятие хочет на 25% снизить затраты на доставку продукции клиенту.
- Требования пользователей (user requirements) - описывают цели или задачи, которые пользователи должны иметь возможность выполнять с помощью продукта, который в свою очередь должен приносить пользу кому-то.
- Функциональные требования (functional requirements) - определяют функциональность ПО, которую разработчики должны разработать, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Они содержат положения с традиционными терминами «должен» или «должна». Например, «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
- Спецификация требований к ПО (software requirements specification, SRS) - документ, где описывается ожидаемое поведение системы. Используется при разработке, тестировании, гарантии качества продукта, управлении проектом и в связанных с проектом функциях.
- Термином системные требования (system requirements) - описывает требования к продукту, который содержит компоненты или подсистемы АС, подразумевая программное обеспечение, оборудование и персонал.
- Бизнес-правила (business rules) - включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес-правила не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Однако они часто налагают ограничения.
- Внешние интерфейсы и ограничения - описание взаимодействия между ПО и пользователем, другой программной системой или устройством. Речь идет о подключениях к другим программным системам, аппаратным устройствам и пользователям, а также коммуникационные интерфейсы.
- Атрибуты качества (quality attributes) - представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям. Другие нефункциональные требования описывают внешние взаимодействия между системой и внешним миром, а также ограничения дизайна и реализации.
- Ограничения (constraints) - касаются выбора возможности разработки внешнего вида и структуры продукта.
Отражение требований в стандартах ГОСТ
В документах ГОСТ Р 59793-2021, ГОСТ 34.602-2020, ГОСТ Р 59795-2021 термин “требование” упоминается очень ограниченно, только в контексте выполнения определенных этапов проектных работ и заполнения документации. Немного больше понимания в этом вопросе дает стандарт ГОСТ Р 59194-2020 “Управление требованиями, основные положения”, но все же недостаточно и не в контексте создания АС.
Ниже представлен перечень документов, составляющих основу ГОСТ 34 серии (введены в действие в начале 2022 года, взамен устаревших стандартов конца 80-х годов):
- "Термины и определения", ГОСТ Р 59853-2021
- “Стадии создания“, ГОСТ Р 59793-2021
- "Техническое задание на создание автоматизированной системы", ГОСТ 34.602-2020
- "Виды, комплектность и обозначение документов", ГОСТ 34.201-2020
- "Виды испытаний автоматизированных систем", ГОСТ Р 59792-2021
- "Требования к содержанию документов", ГОСТ Р 59795-2021
Выполнение работ с требованиями содержит стандарт ГОСТ Р 59793-2021 “Стадии создания“, в котором предусмотрены эти работы только на первых трех стадиях:
- Формирование требований к АС, включает сбор и спецификацию требований пользователей.
- Разработка концепции АС, где выполняется сравнение вариантов концепции АС на соответствие требованиям пользователей.
- Техническое задание - формирование системных требований (требований к системе).
Отражение требований по Вигерсу в документах ГОСТ
Теперь, попытаемся отразить в таблице 1 виды требований и отражение их в структуре проектных работ ГОСТ Р 59793-2021:
Из приведенной таблицы видно, чьл все виды требований и ограничений по К. Вигерсу, находят свое полное отражение в документации ГОСТ 34 серии.
Этот вывод имеет большое значение для проектных специалистов, так как он позволяет более эффективно использовать в отечественной практике опыт зарубежных авторов по работе с требованиями. А особенности применения национальных стандартов ГОСТ, создают необходимость более глубокого их изучения, что, в свою очередь, будет способствовать более грамотной разработке проектной документации и успешному выполнению проектов по созданию АС.
Список используемой литературы:
- Разработка требований к программному обеспечению. 3-е изд., дополненное / Пер. с англ. — М. : Издательство «Русская редакция» ; СПб. : БХВ-Петербург, 736 стр.
- ГОСТ Р 59793-2021
- ГОСТ 34.602-2020
- ГОСТ Р 59795-2021
- ГОСТ 34.201-2020
- ГОСТ Р 59792-2021
