Денис, а где ты это уже сказал. Насчет ГОСТов?

Насчет RUP. Я конечно не его знаток, я только учусь.

Но вот смотрю книгу Лармана Применение UML 3-е издание (стр.65) - характерный рисунок дисциплин унифицированного процесса (2.7) и (2.. Видно, что львиная доля бизнес-моделирования приходится на стадию Развития.
Идем далее. стр. 68. Таблица примерный набор инструментов (Development Case {не удачный перевод, имхо})
и видим Бизнес-моделирование - артефакт: Модель предметной области. Фаза Развитие - начало. Тогда как артефакты требований начинаются на стадии Начало.
Реально, конечно, все идеть паралелльно и зависит от проекта.

Денис, а где ты это уже сказал. Насчет ГОСТов?

На предущей странице большой пост. Эд, открой описание первой стадии работ по ГОСТ и смотри содержание документа, создаваемого на ней.

Насчет RUP. Я конечно не его знаток, я только учусь.

Но вот смотрю книгу Лармана Применение UML 3-е издание (стр.65) - характерный рисунок дисциплин унифицированного процесса (2.7) и (2.. Видно, что львиная доля бизнес-моделирования приходится на стадию Развития.
Идем далее. стр. 68. Таблица примерный набор инструментов (Development Case {не удачный перевод, имхо})
и видим Бизнес-моделирование - артефакт: Модель предметной области. Фаза Развитие - начало. Тогда как артефакты требований начинаются на стадии Начало.
Реально, конечно, все идеть паралелльно и зависит от проекта.

Эд, а тебе вот эта классическая диаграмма ни о чём не говорит?


На мой взгляд Ларман не эксперт по бизнес-моделированию, он свою область компетенции достаточно хорошо описал в названии - "An Introduction to Object-Oriented Analysis and Design and Iterative Development".

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

1. Я согласен, что автоматизация взаимодействия может менять содержание бизнес-процессов, но может и не изменять. И то и другое может иметь место и зависит от того из-за чего нам пришлось задаваться таким вопросом. Для меня представляется значимым, что, например, бухгалтерский учет возник существенно раньше, чем возникли системы, его автоматизирующие. Соответственно, первый автоматизатор бухгалтерского учета не имел значимых прототипов, которые он мог бы взять за образец.
С другой стороны автоматизация биржевых расчетов (особенно в 80-е годы) сделала возможным массовое применение сложных производных финансовых инструментов типа свопов, опционов на свопы и пр., что вызвало определенный культурный шок на рынке ценных бумаг. Сама запись по книгам учета брокерских операций стала фактически эквивалентом ценной бумаги. Даже для того, чтобы просто обратить эту запись в "бумажную" бумагу надо заплатить 25 долларов (при стоимости бумаг от 3 до 100 долларов делает целесообразность такого действия вообще проблематичным).
А электронный (безбумажный) билет, который сейчас внедряют авиакомпании - от билета в этом объекте одно название. Целый пласт возможных действий с бумажным билетом (типа экспертиза фальсификатов) для электронного билета приобретает совсем другую форму. Получается вроде и билет и не-билет одновременно.

2. Не очень понятно, на какой стадии  нужно решать вопрос о необходимости автоматизации того или иного процесса вообще и  в каких рамках нужно принимать решения об этом. Был случай, когда функциональное подразделения банка заказчика хотело иметь весьма навороченный отчет, который необходимо представлять в соответствии с требованиями ЦБ. Когда оценили трудоемкость разработки отчета, выяснилось, что за непредоставление этого отчета было предусмотрено наказание в виде существенно меньшей суммы денег, чем требовала разработка и предполагаемая поддержка отчета. Не очень понятно, можно ли было бы «отловить» эту ситуацию на этапе НИР или концепции? Не очень понятно, что могло бы заставить составителей ТЗ от Заказчика (прежде всего – ИТ-отдел) задаться  вопросом о необходимости реализации этого отчета при  написании ТЗ?
Решение было найдено потому, что ИТ-специалисты банка в силу ряда обстоятельств были интегрированы в "основную" деятельность по управлению деятельностью банка, что можно считать скорее исключением, чем правилом.   Но какие методики, стандарты  могли бы позволить «отлавливать» такие ситуации, соединяя представления разных специалистов ?

1. Я согласен, что автоматизация взаимодействия может менять содержание бизнес-процессов, но может и не изменять. И то и другое может иметь место и зависит от того из-за чего нам пришлось задаваться таким вопросом.

Я не говорил, что меняются бизнес-процессы. Меняются взаимодействия. Взаимодействия, для моделирования которых целесообразно применение use-case'ов.

Бизнес-процесс поездки может выглядеть так:
1. Принятие решения о поездке.
2. Покупка билета.
3. Сбор вещей.
4. Поездка.

Где 2 включает:
2.1 Определение возможных поездов.
2.2. Определение подходящего рейса.
2.3. Справка о наличии билетов.
2.4. Заказ билета.
2.5. Оплата билета.
2.6. Получение билета.

В результате автоматизации состав и порядок 2 (бизнес-процесса) может не поменяться. Поменяется то, как именно выполняется 2.1, 2.2 и т.д. (взаимодействия). И как именно поменяется, до этапа проектирования взаимодействия с системой - не ясно, потому что для этого нужно знать возможности системы.

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

Опять-таки смотрим документ ГОСТ 34.601-90. Комплекс стандартов на автоматизированные системы АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ.

Стадии и Этапы работ
1. Формирование требований к АС
1.1. Обследование объекта и обоснование необходимости создания АС.
1.2. Формирование требований пользователя к АС.
1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания)
...

1. На этапе 1.1. "Обследование объекта и обоснование необходимости создания в АС" общем случае проводят:

а) сбор данных об объекте автоматизации и осуществляемых видах деятельности;
б) оценку качества функционирования объекта и осуществляемых видах деятельности, выявление проблем, решение которых возможно средствами автоматизации;
в) оценку (технико-экономической, социальной и т.д.) целесообразности создания АС.

Кроме того, если посмотреть множество примеров там, то можно увидеть много всякой чуши. А именно происходит путаница ГОСТовского технического проекта и консалтерского системного.

Подтверждаю, что указанный источник нужно очень аккуратно воспринимать в качестве референса. Там документы ОЧЕНЬ разного качества.

Я считаю, что ТЗ - документ, фиксирующий предварительную договорённость относительно обязательств разработчика. Элементы концепции, варианты использования и требования там нужны в объёме и абстракции, позволяющих зафиксировать рамки системы, и не больше. Описание архитектуры и средств реализации - только для соответствия стандартам, поэтому - максимально абстрактное. Описания бизнес-процессов там не нужны - как описать рамки ориентированной на БП системы, если БП до этого не изучены? Зачем пытаться уместить всё в ТЗ - есть много других документов .
Но с другой стороны, практика - главный критерий всего. Если у Вас есть положительный опыт создания, утверждения и использования ТЗ, включающего всё выше перечисленное, этим опытом обязательно нужно поделиться.

У меня подходит к концу проект, в котором целый этап был посвящен написанию ТЗ ровно по ГОСТ 34.602. Не то, чтобы это первое ТЗ по ГОСТ у меня, но такого трепетного отношения мы к нему еще не проявляли, к тому же со временем приходит все новое понимание старых вещей. Хорошо или плохо, но мы, естественно написали этот документ.
Из вопросов которые я мог бы осветить в потенциальной статье мне наиболее интересны следующие:
- Место концепции в ТЗ
- Место описания бизнес-процессов в ТЗ
- Место вариантов использования и других требований в ТЗ

Чуть менее интересно, по причине того, что это может быть очень по разному у всех
- Что мы писали в определеннных разделах (наше толкование ГОСТ)
- Последовательность разработки

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