Определение архитектуры требований

Записаться

Здравствуйте коллеги! Мы продолжаем изучение области знания Анализ требований и определение дизайна, свода знаний по бизнес анализу BABOK версии 3.0. Мы с вами уже подробно рассмотрели задачи 7.1, 7.2 и 7.3. Мы разобрали что такое Специфицирование и моделирование требований, чем верификация отличается от валидации. И в ходе выполнения задачи 7.4 нам предстоит определить архитектуру требования.

Для вас, я думаю будет интересным - что же такое архитектура требования. Попробуем разобраться. Итак, в BABOK заявляется такое назначение задачи, что цель состоит в том чтобы гарантировать, что требования совместно поддерживают друг друга для полного достижения цели. Что это означает? Фактически говоря, что у нас построена такая архитектура требования, что все они связаны друг с другом наиболее эффективным образом. Это способствует достижению нашей цели. Здесь, возможно, играют роль все - и связь требования между собой, и уровень детализации требования, и взгляд на наши требования. Об этом мы сейчас подробно поговорим.

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

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

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

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

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

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

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

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

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

Полнота и связь требований. Архитектура требования – это, некая совокупность требований. А раз это совокупность, значит это какая-то связь. Мы должны четко понимать как требования связаны между собой и при построении архитектуры учитывать эти связи. Важным элементом является то, что у нас эта архитектура. Я привел пример, где требования у нас висят в воздухе на невидимых ниточках, но в реальности это будет не так. Требования у вас будут в какой-то информационной системе. Они будут лежать в каком-то репозитории, к ним будет иметь доступ определенный круг лиц с определенными правами. Например, если человек логинится в систему, он видит все требования или только те требования, которые ему нужны, или требования себя и других коллег? В каком виде он их видит? Архитектура информации по бизнес анализу это то как вы выстроите отражение. Именно эта архитектура требований в своей информационной системе очень важна. Давайте посмотрим какие заинтересованные стороны вам могут помочь в определении архитектуры требований.

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

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

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

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

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

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

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