Для того, чтобы проект был успешным продукт, создаваемый в проекте, должен удовлетворять требованиям заинтересованных лиц, фокусирующих их потребности.
Требования
Требования отражают то, что хочет от продукта заинтересованное лицо, в первую очередь потребитель. Требования отражают потребности и ценность, которую обеспечит продукт, реализовав возможности для потребителя, и то, каким образом возможности будут развиваться в рамках разработки нового продукта. Требования устанавливают рамки и ограничения работы посредством определения того, что должно быть достигнуто. Требования определяются в отношении характеристик (характеристик качества) продукта. Требование, это утверждение однозначно идентифицирующее операционную, функциональную или конструкционную характеристику или ограничение продукта или процесса, которое должно быть проверяемым или измеримым и необходимым для приемки.
Требования состоят из набора элементов требований. Элементы требований могут быть доведены до сведения и записаны в различных формах и с различным количеством подробностей. Элементы требований всегда документируют и отслеживают. Элементы требования являются субальфами Альфы "Требования".
В узком смысле термин "требование", понимается как набор ограничений, накладываемых на результат и на способ его достижения. В более широком смысле требования также могут иметь предписывающий характер для поведения объекта, системы. Требование не следует смешивать с целью. Цель есть образ результата, который мы хотим получить; задача есть действие, которое направлено на достижение цели; требования есть ограничения, накладываемые на характеристики результата или на способ его достижения.
Требования появляются на стадии разработки концепции системы и управляются в ходе всего ее жизненного цикла. По мере того как система материализуется в ходе успешных шагов по ее разработке, требования обретают все более конкретную и детальную форму.
Хорошо управляемые требования гарантируют, что все члены инженерной команды имеют четкое понимание того, что должно быть достигнуто, тем самым направляя усилия на достижение общей цели. Такое согласование помогает снизить риски, избежать расползания области действия и гарантировать, что продукт будет соответствовать ожиданиям заинтересованных сторон. Кроме того, требования – это не просто список функций. Они являются основой, на которой строится архитектура продукта (системы), и если их не понимать четко, архитектура будет иметь недостатки с самого начала. Архитектурно значимые требования служат руководящими принципами для принятия проектных решений на протяжении всего процесса разработки продукта в ходе проекта.
Следует заметить, что господствующее в настоящее время определение понятия "Качество", представленное в серии стандартов ИСО 9000, тесно связано с понятием "Требование", а именно: "Качество есть степень соответствия совокупности присущих характеристик требованиям". Понимание качества в таком виде допускает, что все требования заинтересованных лиц к Продукту детально, полно, непротиворечиво и точно определены еще до начала создания Продукта и закреплены в соглашении. В дальнейшем требования используются для приемки (верификации) разработанного продукта. По существу такое допущение является сильным. Часто требования потребителя (пользователя) окончательно не определены, либо расплывчаты, что сопровождается конфликтами между потребителем и инженерной командой. Вместе с тем, считается целесообразным потратить время на выявление и анализ требований, нежели нести высокие риски через весь цикл создания продукта проекта.
Виды требований
В состав требований входят не только требования заинтересованных лиц, имеющих право их формирования (https://dzen.ru/a/aOwAf-euIUGE2g3z?share_to=link), но и иные, важные с точки зрения проектирования требования.
В общем случае требования разделяются на:
- бизнес-требования;
- требования заинтересованных лиц;
- требования к решению (функциональные и нефункциональные).
Бизнес-требование отвечает на вопросы "Почему это нужно?" или "Зачем я этого хочу?" и представляет собой отображение целей, задач и результатов, объясняющих, для чего было инициировано проектирование продукта, и каким образом будет оцениваться успех его реализации. Бизнес-требования конкретизируют потребности бизнеса и очерчивают границы продукта.
Требование заинтересованного лица отвечает на вопрос "Что нужно?" и детализирует потребности отдельной заинтересованной стороны или целой группы. Они формулируют все возможные допущения и ограничения с точки зрения компетенции и функциональных обязанностей заинтересованной стороны, у которой соответствующие требования были выявлены.
Требование к решению отвечает на вопрос "Что я хочу?" и описывает возможность или качество решения, удовлетворяющие требованиям заинтересованного лица. Требования к решению могут быть функциональными и нефункциональными:
- функциональные требования описывают что система (или её часть) должна делать, поведенческую возможность, которую должно предоставлять решение;
- нефункциональные требования описывают особенности эксплуатации: производительность, информационную безопасность, удобство использования и выражаются в измеримых показателях, которые являются своего рода ограничениями варианта реализации (дизайна) решения.
Если не выполняется функциональное требование, считается, что результат не достигнут, произошел отказ. Невыполнение не функционального требования не означает отказа всей системы.
Требования к решению/системные требования вбирают в себя все выявленные ранее требования, которые были согласованы для реализации в текущей версии продукта, при этом они формулируются и детализируются так, чтобы можно было передать их в разработку.
Подходы к формированию и управлению требованиями
Существуют несколько общепризнанных методов выявления и анализа требований.
- В рамках проектов создания оборонной продукции порядок определения и документирования требований регламентирован в ГОСТ РВ 0015–201 "СРПП ВТ Тактико-техническое (техническое) задание на выполнение опытно-конструкторских работ". Или аналогичный стандарт для гражданской продукции ГОСТ 15.016 "СРПП Техническое задание. Требования к содержанию и оформлению".
- INCOSE (Международный совет по системной инженерии) в 2023 году выпустил итоговую сводку по руководству по написанию требований (подробнее здесь: https://habr.com/ru/articles/757160/). Так, формулировка требования по INCOSE – это результат формального преобразования одного или нескольких источников, потребностей или требований более высокого уровня в согласованное обязательство того, что продукт (решение) будет выполнять определенную функцию или обладать определенным качеством в рамках определенных ограничений с приемлемым риском.
- Guide to the Business Analysis Body of Knowledge® (BABOK) – всемирно признанный стандарт в сфере бизнес-анализа, определяет требование как пригодное для практического использования представление решения в виде условия или возможности, которые необходимы заинтересованной стороне для достижения цели, инициированной потребностью. Из 6-ти областей знаний BABOK 2 области посвящены непосредственной работе с требованиями: "Управление жизненным циклом требований" и "Анализ требований и определение дизайнов". Притом, что BABOK представляет собой профессиональный свод знаний, в отличие от отечественных ГОСТов и зарубежных стандартов по разработке технического задания, он носит рекомендательный характер и не претендует на жесткую регламентацию процедур (подробнее здесь: https://babok-school.ru/).
- Из отечественных стандартов требования к проектируемой системе в форме технического задания также регламентируют:
- ГОСТ 34.602 "Техническое задание на создание автоматизированной системы";
- ГОСТ 19.201 "Техническое задание, требования к содержанию и оформлению".
Стандарты отличаются по специфике применения. ГОСТ 34.602 описывает техническое задание на автоматизированную систему в то время, как ГОСТ 19.201 ориентирован только на разработку программного обеспечения.
В общем случае разработка требований состоит из нескольких этапов.
- Выявление требований: сбор, понимание, рассмотрение и выяснение потребностей.
- Анализ: проверка целостности и законченности.
- Спецификация: документирование требований.
- Проверка правильности: согласование и утверждение.
Формулирование и документирование требований
Уровень детализации и требования к формулировке зависит от отрасли и внутренних норм организации.
Так, например, в соответствии с правилами, установленными INCOSE формулировка требования должна иметь следующую структуру: [Условие] [Субъект] [Действие] [Объект] [Ограничение/Действие].
Например: В состоянии моря 1 [Условие], Радиолокационная система [Субъект] должна определить [Действие] цели [Объект] в радиусе [Действие или Ограничение] 100 морских миль [Значение].
В самом простом варианте структура формулировки может иметь вид: [Субъект] [Действие] [Объект].
Существуют несколько общеупотребимых способов документирования требований:
1. Техническое задание
Если решением является комплект, комплекс, изделие, сооружение, информационная или программно-информационная система то техническое задание (ТЗ) на его разработку содержат требования к решению: функциональные и нефункциональные. На практике формирование такого комплексного ТЗ по всем правилам является длительным и итеративным процессом с множеством циклов согласования между Потребителем и Инженерной командой.
2. Пользовательский сценарий (Use case)
Use case – это сценарий взаимодействия пользователя (или пользователей) с Продуктом для достижения конкретной цели. Юзкейсы содержат следующие сведения:
- кто использует продукт;
- что пользователь хочет сделать;
- цель пользователя;
- шаги, которые делает пользователь, чтобы совершить определенное действие;
- описание того, как продукт реализует действия пользователя.
3. Пользовательские истории (User story)
User story - общее описание функций продукта, написанное как бы от имени пользователя. В User story формулируется, чем функционал продукта ценен для пользователя. Обычно User story имеют форму нескольких простых предложений, имеющих один и тот же образец: Как (пользователь) я хочу (цель), чтобы (причина). Пользовательские сценарии и истории широко используются при разработке программного обеспечения.
Состояния Альфы "Требования":
- Требования сформулированы: Потребитель признает, что существует потребность в новом Продукте.
- Требования ограничены: Определены масштаб нового решения, аспекты возможности, которые должны быть рассмотрены, и механизмы управления и принятия новых или измененных элементов требований.
- Требования непротиворечивы: Требования обеспечивают непротиворечивое описание существенных характеристик нового продукта.
- Требования приемлемы: Требования описывают продукт для потребителя.
- Требования удовлетворены: В итоговый продукт внедрено достаточно требований, для того чтобы потребитель признал, что данный продукт в полной мере удовлетворяет его потребность, и продукт можно признать законченным.
Отношения между Альфами
Альфа "Требования" находится в отношениях с другими альфами областей интересов "Клиент", "Решение" и "Деятельность".
- Требования фокусируются потребностями заинтересованных лиц, их формирующих и воспринимаемой ими ценностью. Поскольку первоначальный вариант требований для продукта редко бывает основан на исчерпывающем анализе, инженерная команда и заинтересованные лица должны предполагать, что требования могут уточняться в ходе проекта.
- Заинтересованные лица требуют, чтобы их требования удовлетворялись в продукте. Таким образом, требования являются элементом проверки и приемки со стороны заинтересованных лиц.
- Требования должны быть реализованы в продукте.
- Требования определяют объем и ограничивают работы, выполняемые инженерной группой в ходе проекта.