Про требования

Этот текст был написан пару или тройку лет назад. Он есть результат моего сугубо субъективного видения. Сюда я его публикую только по той причине, что в него вошли все (или почти все) базовые вещи, на которые мне потребуется ссылаться в случае изложения каких-либо мыслей относительно аналитики. Да, это примитивы, но я буду очень признателен за любые замечания и комментарии.

Что такое требования

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

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

Исходя из такого определения требованиями можно считать:

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

Инвариантность видения требований

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

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

Ньюанс заключается в том, что изложенные выше интересы находятся в разных плоскостях: интересы Заказчика лежат в плоскости Бизнеса, а интересы Разработчика – в плоскости технической реализации.

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

Традиционная схема выполнения аналитических работ

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

Для начала надо бы съездить пообщаться с Заказчиком и попытаться понять, чего он хочет от системы, каковы его ожидания. Это важно, поскольку без этого совершенно не понятно, с чего начинать работу и что делать. Это отправная точка. Конечно, Заказчик прессует бизнес-терминами, но куда уж без них. Правда есть единственный момент. Дело в том, что Заказчик – это именно Заказчик. Т.е. человек, который заказывает систему, а соответственно за нее платит. Т.е. это не рядовой сотрудник компании. Скорее всего он из топ-менеджмента, и то, что он расскажет, технические моменты вряд ли будет содержать, зато стратегических будет навалом (таких, как бизнес-цели, бизнес-ожидания).

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

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

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

Иными словами, аналитик готовит модель as is и модель to be. Модель as is иллюстрирует текущее состояние бизнеса, как Пользователи выполняют свою работу (в рамках бизнес-процессов компании) в настоящий момент. Модель to be показывает, каким образом Пользователи будут участвовать в выполнении процесса в условиях, когда будет внедрена проектируемая система. Т.е. модель to be является не просто описанием процесса, а описанием процесса, в котором указывается, когда и зачем Пользователи будут использовать проектируемую систему.

Когда бизнес-процесс to be описан, аналитик получает описание, в котором не только представлена логика выполнения процесса, но и озвучены основные функции системы, необходимые для информационно-аналитической поддержки этого бизнес-процесса. И вот в этот момент рассмотрение требований в плоскости бизнеса заканчивается и мы переходим в плоскость техническую. Аналитик приступает к проработке функций системы.

Анализ на этой стадии каждый делает как ему нравится. Мне лично близка идея сценариев использования. Это когда для каждой функции системы, озвученной в процессе to be, описывается сценарий, показывающий, как в рамках этой функции взаимодействуют проектируемая система и Пользователи, проектируемая и смежные системы. Детализация этого описания должна быть ровно такой, чтобы сценарий давал четкое однозначное представление об описываемом взаимодействии. Это довольно тонкая грань, поскольку с одной стороны читатель сценария должен его понять и осознать всю его логику, а с другой стороны описание сценария не должно содержать детали, отвлекающие от сути взаимодействия.

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

Отступление: зачем нужны детальные требования

А ведь ответ на этот вопрос не так очевиден, как кажется. И попасть с ним в ступор очень и очень просто. Казалось бы, описали процессы to be, определили сценарии использования – сажай дизайнера и пусть проектирует систему.

Но не все так просто. Проблема заключается в том, что сценарии определяют взаимодействие некоторого субъекта (будь то смежная система или Пользователь) с проектируемой системой. Т.е. акцент в сценарии делается на внешнюю по отношению к использующему субъекту сторону поведения системы.

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

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

Второй пример: всегда ли можно в бизнес-процесс включить сценарии управления справочниками системы? Далеко не всегда, поскольку во многих случаев ведение справочников делается вне бизнес-процесса. Кроме того, описание ведения справочников в бизнес-процессе перегружает читателя информацией, мало имеющей отношение к процессу, и тем самым создает риск неадекватного восприятия предложенного описания. Писать на каждый справочник отдельные сценарии? Но это оправдано только тогда, когда управление справочником представляет собой довольно сложное взаимодействие Пользователя с системой, а такая ситуация далеко не всегда встречается. Поэтому гораздо проще определить требования к ведению справочников и включить их в детальные требования.

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

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

Уровни требований

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

• требования на уровне бизнеса;
• требования на уровне пользователей;
• детальные требования.

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

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

Детальные требования – это требования, определяющие скоп всех функций системы и логику их выполнения, а также регламентирующие условия, которые должны быть выпонены для функционирования системы в соответствии с предъявляемыми к ней требованиями.

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

Иерархия

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

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

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

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

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

Т.е. получение последующего уровеня требований обеспечивается детализацией требований предыдущего уровня.

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

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

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

 

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