Хочу пожаловаться.
Вчера показывала Менеджеру проекта со стороны заказчика ТЗ.
К ТЗ есть приложения, в них есть диаграммы. Я делала в нотации UML.
Система большая, одни модули пишу я, другие - К. К сделала приложения в виде блок- схем (между прочим, не учитывая реальную нотацию блок схем).
Менеджер пректа со стороны заказчика говорит мне, сделай приложения в нотации блок схем, как у К, чтобы был единый стиль всего ТЗ. Я говорю - у меня тут по ролям - чтобы было понятно, кто что конкретно делает. Он- в виде блок схем разработчику понятнее.
1. Какой разработчик, если ТЗ для бизнес-пользователя пишут...
2. Заставляют делать БЛОХ- схемы - это же 70е годы .... Менеджер тот молодой - лет 30..
Компания заказчика крупная - с филиалами в разных городах России, не гос.

Не понял, мысль оборвалась не начавшись ...

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

Если придётся всё-таки аргументировать нотацию лично, то надо будет сделать фактически мини-консалтинг своими силами, в защиту UML может помочь Юра Булуй.

В принципе если скажем use-case diagram и use-case представить в виде таблицы и нумерованной структуры, соответственно, то это может быть универсальным понятным всем форматом представления.

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

Может просто К замочить?

Насколько я понимаю в ТЗ Вы публикуете поясняющие схемы, может пояснения в виде блок-схем оказалось гораздо понятнее, чем UML?

2. Заставляют делать БЛОХ- схемы - это же 70е годы

Блок-схемы действительно до сих являются самым наглядным способом представления последовательности действий для всех причастных к IT, и так будет ещё долгие годы. ИМХО, UML-ские нововведения вроде замены большого ромбика на маленький квадратик ничего по-настоящему нового к ним не добавили.

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

Может просто К замочить?

=)))
Да ладно, пусть живет =)
Главное вместе на один проект не попадать.

Нарисовала уже эти блох схемы =) Заказчик смотрит.

Такой вот вопрос назрел: кто занимался согласованием ТЗ.
Сколько раз заказчик может на доработку отправлять? Пока сроки не иссякнут? =) Причем, он смотрит как менеджер проекта с их стороны, а бизнес пользователям ещё показывал ни разу. Мне кажется, сначала надо уточнить все ли правильно с точки зрения бизнеса, а не то, какое значение будет настраиваемым или менять названия разделов структуры ТЗ (минус ТЗ не по госту).

Блок-схемы действительно до сих являются самым наглядным способом представления последовательности действий для всех причастных к IT, и так будет ещё долгие годы. ИМХО, UML-ские нововведения вроде замены большого ромбика на маленький квадратик ничего по-настоящему нового к ним не добавили.

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

Это не гос заказчик. У них в официальном документе "Стандарт Компании №..." диаграммы в различных нотациях присутствуют, и ни одной блок схемы...

А что, реально помогают эти блок-схемы/UML в понимании текста? Может просто текстом описать требования? А динамику описать в виде сценариев :-), и пусть обчитаются :-). Что за софт хоть на который ТЗ делается, какая область деятельности? И какие и для чего использовались диаграммы UML?

А Что за софт хоть на который ТЗ делается, какая область деятельности? И какие и для чего использовались диаграммы UML?

Документооборот Компании. Сибирская Угольная Энергетическая Компания- www.suek.ru.
В основном Договора, распорядительные документы, входящие, исходящие, внутренние...
Разработка на Lotus.
У них скати Саперов много и активно сейчас трудятся.
Юмл использовала обычные для пользователей - юз кейсы и активити.

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

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