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

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

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

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

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

В рамках нашего курса мы рассмотрим два варианта, по которым можно двигаться, и их комбинацию.

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

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

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

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

Из чего этот документ будет состоять?

Большую часть его элементов мы с вами уже рассматривали.

• Формулировка задачи. В отдельных случаях постановка задачи доступна нам сразу, однако в рамках бизнес-анализа мы, как правило, ее уточняем.
  
  
• Документирование и формализация заинтересованных лиц и их отношение к проекту. Ключевые заинтересованные лица, которые были выявлены, и их потребности.
  
  
• Цели и задачи. В рамках целей и задач мы фиксируем бизнес-аспекты результатов, которые мы хотим получить. Мы на них остановимся подробнее дальше.
  
  
• Раздел, связанный с требованиями. Поскольку мы говорим о решениях, принятых на уровне бизнеса, эти бизнес-требования должны быть на текущий момент известны, также как часть функциональных требований и нефункциональных требований.
  
  
• Заключение — это некоторые рекомендации команды, которая осуществляла бизнес-анализ, с точки зрения целесообразности выполнения этого проекта, разделения его на какие-то части и другие комментарии, которые команда хочет зафиксировать.
  
  
• Глоссарий и, обязательно, список источников, на основании которых были сформированы эти бизнес-требования. Бывает ситуация, когда бизнес-аналитик не имеет доступа к конечным пользователям и формирует требования исходя из имеющейся первичной документации. Такой вариант также возможен, однако нужно убедиться, что эти источники достаточно свежие, и, в случае дальнейшей работы с этим документом, понимать, какова достоверность разработанных требований.
  
  

Итак, вопросы которые требуют небольшого пояснения:

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

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

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

И, как правило, туда входит время, бюджет …

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

И другие ограничения. Например, в одном из проектов была ситуация, когда заказчик, создавая большое и сложное решение, ограничил перечень возможных использованных СУБД в связи с наличием определенных контрактов. Как бы проектировщикам не хотелось использовать другие решения, с учетом наличия этих ограничений, приходилось принимать их во внимание.

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

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

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

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

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

Концепция решения — это документ, о котором говорят: "Если бы вам нужно выбрать только один документ, в котором вы будете фиксировать требования к системе, то это должна быть концепция или vision".

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

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

Соответственно, концепция состоит из следующих разделов:

Первый раздел — это введение.

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

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

Поэтому в каждом документе должно быть небольшое введение, в котором обозначается:

• Назначение документа и границы (то есть какую часть системы или какой временной период охватывает это решение).
  
  
• Определения и аббревиатуры, которые мы используем. Как правило, в введении используется пять-шесть ключевых терминов, понимание которых является ключевым для всего проекта.
  
  
• Ссылки на другие документы.
  
  

Если мы готовим небольшой документ (а общая рекомендация к размеру концепции документа —это порядка 25-30 страниц значимого текста), обзор документа не является обязательным. Однако, если разрабатывается концепция большого решения для, к примеру, 10-20 категорий пользователей, включающая в себя десятки бизнес-процессов, то обзор документа крайне желателен.

Следующий раздел концепции — это позиционирование продукта, позиционирование решения.

В общем случае этот раздел состоит из трех частей:

• Описание рыночной или организационной возможности: какую задачу мы хотим решить, или, другими словами, какие предпосылки привели к тому, чтобы мы инициировали этот проект. Это может быть ситуация проблемы, или это может быть ситуация некоторой бизнес-возможности (business opportunity).
  
  
• Описание проблемы: можно использовать ту же формулировку задачи, которая описывает критерии успешности для заинтересованных лиц
  
  
• Позиционирование продукта, которое мы с вами также уже изучали.
  

Третий раздел — концепция и описание пользователей и заинтересованных лиц.

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

Если вы разрабатываете и создаете продукт — это основной раздел, с которым работает product manager, а не аналитик, и, соответственно, в нем необходимо сфокусироваться на таких вопросах: какие есть перспективы развития продукта, какие возможности продукт создает компании, предположения и зависимости (связанные с рынком).

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

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

И здесь же фиксируются constraints — ограничения, аналогичные тем, что мы с вами рассмотрели в business required documents, и quality ranges — характеристики качества, касающиеся того, какое качество должно быть у продукта. Это более глубокая, более детальная проработка, чем просто набор нефункциональных требований, и мы с вами их обсудим в будущем в отдельном модуле.

И завершают работу над концепцией следующие разделы.

1. Раздел, связанный с приоритетами реализации.
   
   
2. Раздел других требований к продукту может содержать ограничения, которые могут быть вызваны законодательством, либо требования каких-то специальных организаций, которые необходимо выполнить для того, чтобы наш продукт был более качественным.
   
   
   • Как правило, для разработки программного обеспечения, если это не медицина или бухгалтерия, особых ограничений не возникает. Но вот, например, в Евросоюзе и Соединенных Штатах разные законы в разных штатах и в разных европейских странах, и проработка разделов, связанных с соответствием требованиям законодательства, может оказаться очень серьезной задачей. На этапе концепции нам нужно, по крайней мере, четко зафиксировать, каким стандартам и законам мы должны соответствовать.
     
     
3. Раздел Требования к Документированию, естественно, исторический. Чаще всего в современных проектах требования к документации — это достаточно простая часть проекта. Тем не менее, когда вы начинаете задумываться над тем, какие документы вы будете предоставлять в рамках решения для ваших пользователей, что поможет им овладеть вашим решением, овладеть вашим продуктом, это очень часто сильно влияет на то, как вы воспринимаете сам продукт. Поэтому я очень рекомендую не пропускать этот раздел и обязательно обсуждать с другими участниками проекта требования к документации.
   
   
4. В качестве приложения, как правило, прикладывается табличка, в которой фиксируются все дополнительные характеристики, возможности, их приоритет, их сложность и другие атрибуты, которые мы рассмотрим в разделе управления требованиями.