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

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

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

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

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

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

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

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

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

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

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

Среди традиционных способов сбора требований упомянем такие как:

– Проведение фокус-групп типичных пользователей.

– Работа с пользователями для выяснения назначения продукта.

– Проведение интервью для выявления требований.

– Проведение совместных семинаров.

– Наблюдение за пользователями на рабочих местах.

– Разработка и раздача опросных листов.

– Анализ документов.

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

Если говорить о ведении разработки в зависимости от формы требований, стоит выделить следующие подходы:

– со слов, без документирования;

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

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

Ознакомимся детальнее с каждым из перечисленных подходов.

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

Так в чем же сильные и слабые стороны такого подхода? Какие условия необходимы для достижения успеха проекта при его реализации?

Сначала определим, что такое разработка «со слов». Это метод ведения разработки ИТ-решений, когда не разрабатывается никаких технических спецификаций требований в письменном виде (схемы и эскизы – тоже письменные документы), а все необходимые требования излагаются разработчику заказчиком устно.

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

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

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

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

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

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

Ценна и возможность оперативной обратной связи разработчика с заказчиком – можно просто быстро устно спросить, получить ответ и сразу брать его в разработку.

Недостатки не столь очевидны, но они есть:

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

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

– отсутствие возможности восстановления истории требований. Это негативно влияет на ведение изменений, может привести к «хождению по кругу», когда одно и то же требование то возникает, то пропадает в последовательных правках решения;

– практическая сложность и высокая стоимость поддержки и развития как сторонними разработчиками, так и самим автором по истечении времени. Это произойдет потому, что требования, под которые построена система, забудутся или просто будут неизвестны новому разработчику, принятые технические решения и их обоснование, известное только первоначальному разработчику, будет непросто понять и развить (в том числе, возможны ошибочные представления, ведущие к нарушению работоспособности ИТ-решения при попытках его модификации и развития);

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

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

Таким образом, решение разрабатывать «со слов» целесообразно для небольших задач без необходимости сопровождения и развития, выполняемых в хорошо сработанных командах, где заказчик и разработчик отлично понимают детали бизнес-процесса и идеи друг друга с полуслова.

В иных случаях шанс достижения цели разработки «со слов» без разочарований невелик.

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

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