Привет участникам форума.

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

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

Вы когда ни будь задумывались «Что думает заказчик когда видит наш документ после получения его на согласование?». «Какие мысли у него возникают в голове?».

Думаю что то на подобие:
«Для чего они все это делают, пустая трата времени, запрограммировали бы сразу и не тратили бы и свое и мое время»
«Ничего не понятно в документе, непонятные диаграммы, схемы. Зачем же так подробно описывать, они бы еще как свет в комнате включать описали»
«Ну, в чем смогу разобраться сделаю замечания, а в чем нет, потом разберемся когда запрограммируют»

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

У аналитика же при отсылке документа возникают несколько другие мысли:

«Ну, что смогли выяснить, то согласуем, что нет Заказчик сам виноват, не рассказывал ничего, а я все равно свою работу выполнил».

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

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

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

В итоге,  ошибки начинают проявляться на стадии тестирования (ведь именно в этот момент бизнес кидает на проработку Системы все силы) Заказчик начинает тратить значительные затраты и человеческие ресурсы на изменение документации, доработку Системы или, что происходит чаще, просто отказывается от ведения документации по причине ее не состоятельности(следствие невнимательного согласования) и нежелании ждать и тратить, и просто дорабатывает Систему на коленке (По моему так разрабатывается 80% процентов ПО у нас).

Хотя, для сокращения затрат необходимо прикладывать максимум сил именно на этапе проектирования и моделирования Системы. Да, это долгосрочные вложения ресурсов, но прибыль и экономия очевидна.

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



 

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

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

Теперь насчет представления документа заказчику в виде UML, eEPC, IDEF0 и т.п. Да, конечно, заказчик совсем не обязан понимать все это, потому он должен требовать описания втакой форме, которую он понимает! Если это не возможно или обременительно )за предоставления адаптированного документа разработчик может потребовать некоторую сумму сверху), заказчик может воспользоваться услугами независимого эксперта или иметь в штате достаточно грамотного в этой области человека. Вне всякого сомнения заказчику совершенно не имеет смысла знать как разрабатывается ПО.

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

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

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

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

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

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

Нельзя отдавать на откуп документ требований Заказчику, если он безотвественно подходит к делу. Надо разжевать и положить в рот (прочитать ТЗ вместе с ним) и сделать нужные исправления. А то получите то что имеете....

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

ArtemyY, я возможно повторю то, что говорится в источниках, на которые ссылается Galogen, но тем не менее.

ТЗ - это не (просто) результаты обследования, это совместный документ, служащий для фиксации принятых решений. Он помогает в дальнейшей коммуникации по проекту, но сам по себе является лишь картиной, слепком коммуникации на момент своего написания. Поэтому когда ТЗ высылается заказчику на согласование, он должен получать не кота в мешке, а на 90% известный документ. Следовательно и нотация должна быть выбрана и согласована ещё на первых встречах по сбору требований, если не раньше.

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

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

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

Если заказчиков уровня директоров/начальников отделов много, то нужно объяснять необходимость менеджера проекта со стороны Заказчика, который будет участвовать в согласовании и приоритезации требований с соотв. полномочиями, иначе вы останетесь один на один с Лебедем, Раком и Щукой и все эти животные останутся несчастными и во всём обвинят вас.

ArtemyY, я возможно повторю то, что говорится в источниках, на которые ссылается Galogen, но тем не менее.

ТЗ - это не (просто) результаты обследования, это совместный документ, служащий для фиксации принятых решений. Он помогает в дальнейшей коммуникации по проекту, но сам по себе является лишь картиной, слепком коммуникации на момент своего написания. Поэтому когда ТЗ высылается заказчику на согласование, он должен получать не кота в мешке, а на 90% известный документ. Следовательно и нотация должна быть выбрана и согласована ещё на первых встречах по сбору требований, если не раньше.

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

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

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

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

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

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

Если заказчиков уровня директоров/начальников отделов много, то нужно объяснять необходимость менеджера проекта со стороны Заказчика, который будет участвовать в согласовании и приоритезации требований с соотв. полномочиями, иначе вы останетесь один на один с Лебедем, Раком и Щукой и все эти животные останутся несчастными и во всём обвинят вас.

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

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

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

1. Даже качественный документ не отменяет личных коммуникаций. Как уже говорил Денис, действительно нужно "разжевывать" документ заказчику, некоторые положения требований и например те же юзкейсы/сценарии нужно в комиксах показывать (при необходимости) ... это я о storyboarding в расширенном понимании. Вам, как аналитику, нужно нарисовать в воображении заказчика КАРТИНКУ ... тогда у заказчика и появиться понимание. И если сначала показать в комиксах, а потом написать формальным языком (и приложить комиксы :-)), то как правило это позволяет улучшить ситуацию с пониманием.
2. Не согласен с утверждением что юзкейсы малопонятны нетехническому человеку. Скорее всего вопросе КАК их писать и как иллюстрировать.
3. Не следует подменять ТРЕБОВАНИЯ описанием бизнес-процессов. БП в данном случае больше нужны чтобы понять КАК РАБОТАЕТ организация (для того чтобы эти процессы автоматизировать, а не реинженирить). Если конечно вы понимаете под БП то же что и я, а не ERP-шный подход с их "функциональной архитектурой" и т.п. ... где под БП они запросто понимают то, что описывается collaboration диаграммами в модели дизайна по, тому же классическому RUP.
4. Проблему "длинных" проектов с изменяющимися людьми/потребностями/процессами и соответственно требованиями на декларативном (и практическом) уровне методологи уже решили. Именно ответом на них было появление а) итерационной модели ЖЦ б) соответствующих методологий (тот же RUP и гибкие (agile) методологии). Вопрос только в том КАК вы с заказчиком договорились работать. Идеальный вариант при таких условиях -- time & materials ... но наша реальность -- это fixed price. Но при этом, чего греха таить, эта price как правило включает риски связанные с переделкой софта, на так ли ;-) (иначе откуда такие гигантские бюджеты на создание не слишком сложных систем в госсекторе ... даже с учетом откатов).
4. Ни одна методология или классный документ не сможет ни чем помочь, если со стороны заказчика нет драйвера этого проекта ... тот кому этот проект действительно нужен и поможет решить массу очевидных проблем. Или попросту если заказчик слабо заинтересован в результатах.
5. greesha, я был рад вас увидеть на семинаре по Scrum в Люксофте. Вы таки им заинтересовались по следам моих рекомендаций :-). Отвечая на вашу ситуацию и как вы сами слышали на семинаре ... должен быть тот самый Product Owner ... и не важно внутри он вас (ваш маркетниг -- т.е. то что вы пишите как "мы сами себе заказчики") или на стороне заказчика. Проблемы с английским - это частная проблема, которая при готовности инвестировать в это деньги со стороны вашего менеджмента -- решаема, а не проблема методологии :-). Тендеры, и их требования, не означают того, что вы не будете общаться с заказчиком в процессе разработки если его таки выиграете. Если при таком тендере заказчик не желает с вами общаться вообще, значит можно быть уверенном в том, что победитель уже известен (с ним уже пообщались), а всем остальным отведена роль статистов.

Иногда нет возможности сесть с каждым согласующим и разъяснить ему все особенности разработки документа требований. Когда согласующих 1-2, то да это оптимальнее, но когда 4-8 то думаю уже разумнее создать именно "адаптивный документ". В моем случае на всем нашем проекте в данный момент с нами взаимодействует порядка 40-60 человек из бизнеса(при этом есть "текучка" в данном круге, ~5% в месяц). Ко всем не подойдешь... 

40-60 согласующих - это какой-то страшный перебор. Надо поставить перед руководством проекта со стороны заказчика жесткое требование сократить число согласующих до разумного. На практике, я бы сказал, что при наличии примерно 7-10 согласующих лиц у заказчика приходится вводить внутри команды отдельную проектную роль - "согласующий", и на 100% специальный выделенный человек будет ходить по этим согласующим у заказчика, и с ними общаться. Иначе что-то согласовать в разумные сроки нереально. Причем это от типа заказчика (гос / не гос), по-моему, мало зависит.

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

Ну, это я попытался дополнить высказывания "аксакалов форума", с которыми в этой ветке полностью согласен.

5. greesha, я был рад вас увидеть на семинаре по Scrum в Люксофте. Вы таки им заинтересовались по следам моих рекомендаций :-). Отвечая на вашу ситуацию и как вы сами слышали на семинаре ... должен быть тот самый Product Owner ... и не важно внутри он вас (ваш маркетниг -- т.е. то что вы пишите как "мы сами себе заказчики") или на стороне заказчика.

Да, я туда действительно пошёл по Вашей "наводке".

Дело в том, что мы ведём параллельно несколько разнородных проектов. Фактически в команде из шести человек, каждый обычно работает над задачами, относящимся к разным проектам: программисты работают над разными приложениями, тестировщик изучает третье, "аналитики" общаются каждый со своими "закреплёнными" клиентами (слово "аналитики" я взял в кавычки, потому что для меня они аналитики, а для руководства - скорее, поддержка клиентов). Поэтому SCRUM "в чистом виде" мы вряд ли сможем внедрить, но некоторые очень полезные идеи я из семинара для себя вынес. Впрочем, это уже оффтоп.

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

В России чаще всего так и есть.
 
А вот в Иране, например, тендеры проводятся "по-честному", по крайней мере, у меня сложилось такое впечатление. Сначала оцениваются предложения по набору формальных признаков - технические характеристики, наличие сертификатов, демонстрация некоторых принципиальных возможностей (например поддержка языка фарси - она либо есть, либо нет). Ну и цена, конечно.
А уже после тендера, если удалось зацепиться, начинается реальная работа с заказчиком.

40-60 согласующих - это какой-то страшный перебор. Надо поставить перед руководством проекта со стороны заказчика жесткое требование сократить число согласующих до разумного. На практике, я бы сказал, что при наличии примерно 7-10 согласующих лиц у заказчика приходится вводить внутри команды отдельную проектную роль - "согласующий", и на 100% специальный выделенный человек будет ходить по этим согласующим у заказчика, и с ними общаться. Иначе что-то согласовать в разумные сроки нереально. Причем это от типа заказчика (гос / не гос), по-моему, мало зависит.

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

Да, конечно 40-60 пользователей всего на проекте взаимодействет. По отдельному ТЗ 4-8 человек.
У нас так и есть, каждую категорию представляет лицо из отдела ИТ. Вот только этот человек не всегда может грамотно разъяснить и объяснить несмотря на то что он из ИТ. Опять приходим к тому что проще описать весь материал необходимый при согласовании в адаптивном документе.

Ну, это я попытался дополнить высказывания "аксакалов форума", с которыми в этой ветке полностью согласен.

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

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

У нас так и есть, каждую категорию представляет лицо из отдела ИТ. Вот только этот человек не всегда может грамотно разъяснить и объяснить несмотря на то что он из ИТ.

Мы у себя такую ситуацию идентифицируем как один из стандартных рисков при выявлении требований. "Лицо из отдела ИТ" не может выступать представителем какой-либо категории пользователей, за исключением категории "пользователи отдела ИТ". Потребности конечных пользователей должен выражать в проекте конечный пользователь, а не ИТ-шник. Тут ситуация сложная. Сотрудники отделов ИТ заказчика - это наши союзники - им, в итоге, внедрять и поддерживать то, что мы сделаем. Поэтому дружить с ними надо однозначно. Но то, что они не могут представлять интересы "бизнеса" - это, по-моему, очевидно. Достаточно посадить рядом человека из бизнеса и ИТ-шника, который думает, что он понимает потребности бизнеса, и попросить ИТ-шника рассказать своими словами, как устроен бизнес. В 90% случаев человек из бизнеса через пол-минуты начинает нервничать и встревать со словами "да нет же, все совсем не так"... Это типовая ситуация; смотрим это кино у каждого первого заказчика. Привлекайте ИТ-шников как экспертов. Но не как представителей категорий пользователей

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

Я бы не противопоставлял. То, что "нужно сначала правильно организовать работу на проекте" - это сомнению не подлежит.

Насчет адаптивного документа - я не писал, что "он не нужен". Но, честно говоря, я не до конца понимаю, что за документ вы хотите написать.
Изначально термин "адаптированный документ" возник в ответе Galogen'а:

Теперь насчет представления документа заказчику в виде UML, eEPC, IDEF0 и т.п. Да, конечно, заказчик совсем не обязан понимать все это, потому он должен требовать описания втакой форме, которую он понимает! Если это не возможно или обременительно )за предоставления адаптированного документа разработчик может потребовать некоторую сумму сверху), заказчик может воспользоваться услугами независимого эксперта или иметь в штате достаточно грамотного в этой области человека. Вне всякого сомнения заказчику совершенно не имеет смысла знать как разрабатывается ПО.

Здесь речь про то, что если "заказчик UML не понимает", то надо написать требования тем языком, который он понимает. Но мне в данном случае кажется, что порядок действий несколько перепутан. Опять же, сошлюсь на "буквари", требования изначально и должны излагаться на языке бизнеса. Именно так, чтобы их понял прежде всего заказчик. А дальше вы можете уже для проектной команды сделать отдельный документ, где перевести все требования на технический язык.

Вы же говорите о документе, в котором:

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

Это не документ с требованиями, это некий организационный документ. Я бы сказал, что-то типа Устава проекта. Если вы его напишете и согласуете с Заказчиком, вреда не будет. Если же вы сможете заставить его еще и выполнять те процедуры, которые вы там пропишете - можете смело ставить себе памятник при жизни, набирать Учеников и писать книгу "Как заставить заказчика исполнять регламент проекта". 

В-общем, пишите, да обрящете. Либо ваш документ заработает, либо вы приобретете ценный жизненный опыт

Да, термин адаптивный документ заимствовал у Galogen'а, надеюсь не против.

Нет, думаю это не устав проекта.
Основная цель документа сделать из заказчика(эксперта предметной области) полноценного участника команда. Он должен четко понимать свое место, задачи и копметенции. Он должен понимать цену ошибки, понимать что если в документе останется не точно изложеная мысль, упущена деталь то по сути ошибка будет сделана в:
1. функциональном дизайне(у нас так называется документ c описанием интерфейсов, запросов, алгоритмов с детализацией до базы).
2. в системе
3. В тестовой документации.
Соответвенно необходимо провести работы по устранению ошибки в документации, в системе выполнить повтороное тестирвание. 

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

Т.о. документ должен содержать следующие разделы:

1. Описание жизненного цикла разработки ПО (этапность).
2. Описание структуры проектной команды.
3. Описание ошибок в документе требований, последствия ошибок.
4. Описание использованных нотаций.