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

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

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

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

Небольшое отступление:
UML в Rational Software Architect имеет нестандартный стереотип для пакета (<<prspective>>). Этот пакет можно использовать для моделирования альтернативных вариантов чего угодно, а пакеты с этим стереотипом игнорируются при выполнении преобразований и, по умолчанию, генерации отчетов.

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

И снова: критерий - "стоимость - эффективность". Если для каждого экземпляра документа "рисовать" свой шаблон - это никому не нужно. Но разработать в организации по одному шаблону для каждого типа документа - это вполне реально.

И еще личное мнение: если в группе нет "стандартов" (правил, соглашений), ничего серьезного она сделать не сможет. ("Тексты" соглашений могут "храниться" и в мозгу!)