Что такое управление требованиями и почему их путают на трёх уровнях

Зачем управление требованиями

Требование — это то, что должно быть сделано, чтобы услуга или система решала задачу заказчика. ПрактикаПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 отвечает за то, чтобы требования были собраны, поняты одинаково всеми и дожили до конца работ без искажений.

ГОСТ Р ИСО/МЭК 20000-1 формулирует минимум коротко: требования к существующим и новым сервисам и к их изменениям должны быть определены и задокументированы 3. Дальше он же требует определить критичность сервисов, разобраться с их взаимосвязями и дублированием и расставить очерёдность запросов на изменение с учётом доступных ресурсов 3.

Практика существует, потому что провал чаще случается не в коде.

Люди путают уровни требований: бизнес-требования, пользовательские и функциональные. Руководитель перечисляет выгоды, но не знает, как работают пользователи; пользователи описывают нужные возможности, но не могут грамотно назвать функции, которые должны сделать разработчики 1.

Когда практика работает

Три вопроса, ответы на которые видны в тексте требований, а не в процессе их согласования.

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

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

Требования дожили до приёмки. Как проверить: критерии приёмки выведены из требований, а не написаны заново перед сдачей 5.

Что входит и что рядом

Три уровня требований

Разделение, без которого разговор о требованиях превращается в спор глухих 1.

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

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

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

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

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

Что на входе и что на выходе

Практика забирает разрозненное — просьбы, жалобы, планы, ограничения — и отдаёт то, по чему можно работать и что можно проверить. ITIL описывает состав этого результата: командам нужны функциональные и нефункциональные требования с приоритетами и сведения об обстановке, где решение будет работать 2.

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

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

Та часть, которую забывают чаще всего и оплачивают дороже всего. ITIL прямо включает её в результат работы наравне с функциями 2, а ГОСТ требует учитывать критичность сервисов и ограничения 3.

Что сюда входит на практике:

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

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

Что делает требование хорошим

Вигерс и Битти дают признаки, по которым имеет смысл править формулировки 1:

Совет оттуда же: неразумно требовать «моментального» выполнения операции — точная формулировка вроде «в течение пятидесяти миллисекунд» делает требование выполнимым и проверяемым 1.

Приоритеты расставляет заказчик

Один из самых практичных выводов Вигерса и Битти: разобраться, без чего работа не пойдёт, что просто полезно и чем пользователи готовы пожертвовать, должен сам заказчик — разработчики за него этого не решат 1. Разработчики дают другое — сведения о стоимости и рисках каждого требования 1.

Это разделение снимает вечный спор «почему вы не сделали всё». В списке «всё» нет очерёдности, и потому он невыполним по определению. Список с очерёдностью выполним всегда — вопрос лишь в том, где провести черту.

ГОСТ говорит о том же на своём языке: очерёдность запросов и предложений определяется исходя из бизнес-потребностей и целей с учётом доступных ресурсов 3.

Как это работает

Два места стоит объяснить отдельно.

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

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

Что с чем путают

Требования и техническое задание. Задание — форма, требования — содержание. Хорошее задание состоит из требований; плохое — из описаний экранов.

Требования и решение. «Нужна кнопка выгрузки» — решение. Требование звучит иначе: бухгалтер должен получать данные за период в виде таблицы.

Управление требованиями и бизнес-анализ. Анализ отвечает, какую задачу решаем и стоит ли; управление требованиями — чтобы найденное дожило до результата без искажений 2.

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

Кто участвует

Как измерять

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

Доля переделанных требований названа первым показателем практики. COBIT формулирует её точно: доля требований, переделанных из-за расхождения с потребностями и ожиданиями организации 4. Формулировка задаёт и причину переделки: не «требования изменились», а «мы неверно поняли, чего от нас хотят». Рядом — удовлетворённость заинтересованных сторон самими требованиями 4: показатель, который стоит снимать до начала разработки, а не после сдачи.

Риск требований меряется тем, что его не заметили. Третью цель — риск, связанный с требованиями, учтён в предложенном решении — COBIT измеряет числом инцидентовИнцидентНезапланированное прерывание услуги или снижение её качества.ITIL 4, практическое руководство по управлению инцидентами, не опознанных как риск, и долей риска, снизить который не удалось 4. Первый показатель приходит из эксплуатации и указывает назад, на разбор требований: инцидент, которого никто не предвидел, почти всегда означает, что вопрос не задавали.

Обоснование — тоже предмет измерения. Четвёртую цель COBIT — требования и предложенные решения отвечают целям обоснования по ожидаемой ценностиЦенностьПольза и выгода, которые сторона получает от услуги; величина субъективная.ITIL 4, книга ITIL Foundation и вероятным затратам — меряют двумя долями. Сколько целей обоснования закрыто предложенным решением. И сколько заинтересованных сторон это решение не согласовало 4. Вторая доля обычно не считается вовсе, а она и есть ранний признак: несогласный участник на этапе требований возвращается на этапе приёмки, только дороже.

Зрелость управления требованиями

✕

Где ломается чаще всего

Шесть мест, в порядке частоты.

Уровни перепутаны. От заказчика ждут функций, от пользователя — выгод 1.

Приоритетов нет. Список «всё нужно» невыполним, а черту в итоге проводит разработчик, исходя из своих соображений 1.

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

Требования не проверяемы. «Система должна работать быстро» — по такому требованию нельзя составить проверку 1.

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

Прослеживаемости нет. Через год никто не может ответить, почему сделано именно так.

Что говорят своды

68Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и ISO, что из этого обязательно, а что на выбор, и где брать первоисточник. У каждого свода отмечено, развивается он или давно заморожен, и есть ли действующий ГОСТ. По 51 практикам из 62 проставлено соответствие COBIT.Открыть →

COBIT выделяет определение требований отдельной целью управленияЦель управленияЕдиница описания COBIT: цель с проверяемым содержанием, у которой есть процесс того же имени.COBIT 2019, книга Governance and Management Objectives, отдельно от разработки решений 4.

ГОСТ Р ИСО/МЭК 20000-1 требует определять и документировать требования к существующим и новым сервисам и к изменениям, определять критичность сервисов и расставлять очерёдность с учётом ресурсов 3.

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

Вигерс и Битти дают содержание, которого нет в сводах: уровни требований, признаки хорошей формулировки, правило о том, что очерёдность расставляет заказчик 1.

Вывод для практики: своды говорят, что требования должны быть, и почти ничего не говорят о том, какими им быть. За этим идут в инженерные источники — и это нормально, если знать, куда именно.

Где описано

Что почитать дальше

Три соседние практики, между которыми живут требования: BANБизнес-анализ — где выясняют, что вообще нужно, SDSПроектирование сервиса — где требования превращаются в замысел, TSTПроверка и тестирование услуг — где по ним проверяют результат.