Как написать бизнес-требования? Бизнес-специалисту – как разговаривать на одном языке с ИТ

– ожидания должны быть формализованы до метрик или категорий, которые позволили ли бы определить меру соответствия ситуации этим ожиданиям;

– для метрик и категорий определены целевые значения.

В реальности так бывает редко. Обычно ожидания сродни мечте или иллюзорному образу «светлого будущего». При этом воля (или драйв, как нынче модно говорить) имеется, а, значит, есть и движение к мечте.

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

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

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

Итак, ключевые факторы начала разработки это:

– Желание, или даже мечта, драйв;

– Возможность привлечь для создания решения необходимые ресурсы;

– Понимание целей того, что собрались сделать, и вера в бизнес-полезность этого.

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

Немного остановимся, на том, что такое требование и каковы его свойства.

Глава 2. Немного о требованиях

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

Детально требования и все аспекты работы с ними проработаны книгах по управлению требованиями, например, Карла Вигерса и соавторов. Приведем необходимый для дальнейшего изложения минимум, а за остальным предлагаем обратиться к упомянутой классике.

Итак, выделяются следующие виды требований:

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

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

Ограничение – ограничение на выбор вариантов, доступных разработчику при проектировании и разработке решения

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

Функциональное требование – описание требуемого поведения системы в определенных условиях. Функциональные требования описываются в форме традиционных утверждений со словами «должен» или «должна».

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

Среди нефункциональных требований обычно выделяют:

Требования по удобству использования – достаточно сложно формализуемый пункт, но часто важный, например, «размещение заказа из корзины должно выполняться не более, чем двумя кликами мыши».

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

Требования к безопасности – все, что касается обеспечения информационной безопасности и защиты информации, включая требования по криптографической защите.

Требование к доступности и надежности – необходимые параметры, определяющие доступность системы, простои (например, по рабочим дням с 9:00 до 18:00 московского времени, с не более, чем двумя перерывами обслуживания в день продолжительностью до 5 минут), резервирование данных и вычислительных средств.

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

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

Источников требований к ИТ-решению не так много. Вот основные из них:

– Лицо, принимающее решения по проекту и эксперты его команды, то есть те, кого абстрактно именуют заказчиком. Они имеют мечту и представление о том, чего хотят добиться ИТ-решением и потому являются основным источником требований.

– Нормативно-регулятивное окружение бизнеса. Это законодательство, регуляторные требования, обычаи делового оборота, внутрикорпоративные и даже этические нормы, в пределах которых должно строиться ИТ-решение.