Появляется критерий «соответствие ожиданиям», то есть:
– ожидания должны быть сформированы;
– ожидания должны быть формализованы до метрик или категорий, которые позволили ли бы определить меру соответствия ситуации этим ожиданиям;
– для метрик и категорий определены целевые значения.
В реальности так бывает редко. Обычно ожидания сродни мечте или иллюзорному образу «светлого будущего». При этом воля (или драйв, как нынче модно говорить) имеется, а, значит, есть и движение к мечте.
Особенность мечты, как мы все знаем из многочисленных трудов по мотивации, в том, что пока не выстроен более-менее измеримый и непротиворечивый образ этой мечты, движение носит хаотический характер, а шансов достичь цели немного.
Более того, велик шанс не понять, что цель уже достигнута и разочароваться. Увы, все тоже самое, часто с куда большими затратами, верно и для создания ИТ-решений.
Чем более размыты и абстрактны ожидания, тем меньше шансов на удовлетворенность результатами проекта.
Итак, ключевые факторы начала разработки это:
– Желание, или даже мечта, драйв;
– Возможность привлечь для создания решения необходимые ресурсы;
– Понимание целей того, что собрались сделать, и вера в бизнес-полезность этого.
Пока мы говорили о желании, мечте, но всем известно, что разработка ведется на основе требований. И если мечты и желания исследуются поэтами, писателями, психологами, то требования – область деятельности аналитиков, менеджеров продуктов и разработчиков.
Немного остановимся, на том, что такое требование и каковы его свойства.
Глава 2. Немного о требованиях
Детально требования и все аспекты работы с ними проработаны книгах по управлению требованиями, например, Карла Вигерса и соавторов. Приведем необходимый для дальнейшего изложения минимум, а за остальным предлагаем обратиться к упомянутой классике.
Итак, выделяются следующие виды требований:
Бизнес-требование– высокоуровневая бизнес-цель организации или заказчиков системы, в то же время под бизнес-требованием может пониматься достаточно детализированное требование любой другой категории, если его выполнение прямо связано с достижением бизнес-цели заказчика, а отклонение от него ведет к не достижению или неполному достижению этой цели. Обычно, говоря о подготовке качественных бизнес-требований, имеют в виду эту расширенную трактовку.
Бизнес-правило– политика, предписание, стандарт или правило, определяющее или ограничивающее некоторые стороны бизнес-процессов. По своей сути это не требование к программному обеспечению (ПО), но оно служит источником нескольких типов требований к ПО.
Ограничение –ограничение на выбор вариантов, доступных разработчику при проектировании и разработке решения
Требование к взаимодействию –описание взаимодействия с пользователем, другой программной системой или устройством.
Функциональное требование– описание требуемого поведения системы в определенных условиях. Функциональные требования описываются в форме традиционных утверждений со словами « должен » или « должна ».
Нефункциональное требование– описание свойства или особенности, которым должна обладать система, или ограничение, которое должна соблюдать система.
Среди нефункциональных требований обычно выделяют:
Требования по удобству использования– достаточно сложно формализуемый пункт, но часто важный, например, «размещение заказа из корзины должно выполняться не более, чем двумя кликами мыши».
Требования к производительности– нагрузочные характеристики системы по количеству пользователей, запросов, профилю нагрузки, объему данных и т.п.
Требования к безопасности– все, что касается обеспечения информационной безопасности и защиты информации, включая требования по криптографической защите.
Требование к доступности и надежности– необходимые параметры, определяющие доступность системы, простои (например, по рабочим дням с 9:00 до 18:00 московского времени, с не более, чем двумя перерывами обслуживания в день продолжительностью до 5 минут), резервирование данных и вычислительных средств.
Далее покажем основные пути, как из мечты или представлений формируются требования.
Читать дальше