Обращенное внимание на проект по созданию целевой системы необходимо, чтобы оценить внутренние ресурсы для реализации проекта. В качестве внутренних ресурсов рассматриваются время, финансы, жизненное мастерство, включая требуемые для создания системы прикладные практики. Кроме того, важно понимать свой жизненное мастерство, которое должно быть достаточно для создания целевой системы. Например, хватит ли у вас мастерства собранности, чтобы систематически посещать фитнес в течение полугода? А хватит ли собранности, чтобы в течение пары лет систематически учить иностранный язык?
Данная проработка позволяет осознать, насколько важен и кому нужен данный проект по созданию целевой системы.В процессе постоянного стратегирования, проекты и целевые системы уточняются, появляются новые или, наоборот, считаются потерявшими актуальность. Наиболее нужные и/или наиболее проработанные берутся в работу, то есть переходят на стадию «Планирования». Более подробно о выборе проектов и их планировании будет рассказано соответственно в главах 9 и 10.
В большинстве случаев личное стратегирование проводится человеком неосознанно, а на уровне предприятий при формировании целей в приоритете часто рассматривается один интерес, и не учитываются все возможные интересы. Понятие целевой системы и других систем позволяет осознанно подойти к процессу стратегирования и планирования своей рабочей и личной деятельности.
Понятия: цель как целевая система, проект как система обеспечения.
Системное описание или описание системы всегда существует, если в физическом мире выделена система 115 115 Однако, это описание может быть не полным, и не всегда это описание задокументировано. Если система выделена вниманием, то есть по крайней мере, требования к системе.
. Раз уж своим вниманием выделили систему, то значит у вас есть какие-то особые пожелания к ней, то есть вы не произвольно её выделяете 116 116 Если выделяете произвольно, то, скорее всего, у вас нет проекта и реальной деятельности, а вы просто играетесь или философствуете на тему.
из окружения. Хотя, возможно, до конца не осознаете все пожелания или не можете сразу дать полного описания системы. Тем более, что полное описание системы зависит от всех заинтересованных лиц (проектных ролей).
Системная документация или документация системы – это документы 117 117 Или артефакты, рабочие продукты.
, которые описывают систему.Описание есть всегда 118 118 Обычно на старых предприятиях имеется дядя Петя или тетя Валя, которые держат в голове все описания системы, но нет полной документации. Несмотря на отсутствие документации, системы создаются и работа выполняется.
, если есть система, но документация системы существует не всегда, ее необходимо создавать 119 119 Документация или рабочие продукты системного описания составляются с помощью определенных практик. Например, с помощью практики бухгалтерского учёта составляется рабочий продукт – бухгалтерский баланс, который является одним из описаний системы «предприятие».
или записать на каком-то физическом носителе.
Системное описание состоит из требований, архитектуры и неархитектурной части 120 120 Обычно архитектура и неархитектурная часть вместе называется проектом системы. В данном случае термин «проект» означает не деятельность, а описание (design).
. Требования описывают систему как «черный ящик» или снаружи, а архитектура и неархитектурная часть – как «прозрачный ящик» или внутреннее устройство системы. Системная документация состоит из списка требований, архитектурной документации и рабочей документации. Обсудим данные понятия подробнее.
Требования и потребности
Требованиями описывается то, что должна делать система. Упоминание «черного ящика» означает, что требованиями описывается внешнее поведение системы, выполнение её функции в надсистеме. В требованиях ничего не говорится о внутреннем устройстве системы, она представляется как «черный ящик». Например, требование к системе «легковой автомобиль»: максимальная скорость не менее 250 км/ч, вес не более 2 тонн, разгон до 100 км/ч за 3 сек и т. п.
Требования возникают у проектных ролей, как внешних, так и внутренних. Учитываются требования только тех ролей, интересы которых принято учитывать при создании целевой системы. Поэтому решение о том, какие роли учитывать непосредственно влияет на требования, а потом на архитектуру, и в последствии на воплощение системы. Инженер по требованиям в результате коммуникации с заинтересованными лицами самостоятельно определяет список требований, с которыми далее работает архитектор системы.
Читать дальше