Предлагаю вниманию общественности шаблон концепции системы автоматизации, выполненный в максимально строгом анкетном стиле, который у нас получился.
Его назначение в том, чтобы вправить мозги ретивым пользователям и программистам, которые при разработке системы начинают выдвигать и реализовывать требования к форме и цвету кнопок в обход постановки корневых целей и задач.
Естественно, это не единственно верный и не единственно возможный шаблон, но возможно кому-то он пригодится.
Шаблон выполнен на стыке RUP Vision, ТЗ по ГОСТ 34.ХХ (от которого мало что осталось) и рекомендаций Коберна по написанию вариантов использования.
Предложена детализация вплоть до текста вариантов использования (что не вполне ложится в формат концепции, но так было надо...).
Мы предполагаем, что попытка заполнить шаблон в начале разработки или внедрения системы автоматизации приведет автора к осмыслению истинных целей и задач автоматизации.

Авторы документа Orekh и Boatman.

Прошу критиковать и задавать вопросы.

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

во-вторых, имхо стоит явно разделить интересы Заинтересованных лиц ВНЕ системы, с точки зрения на неё как ПОЛНОСТЬЮ ЧЁРНЫЙ ЯЩИК, и задачи пользователей ВНУТРИ системы, и связанные с этими задачами цели и функции системы.

Вообще, типичный сценарий работы с заказчиком выглядит так:
1. Для начала работ над проектом нужна концепция - Хм, ну я же вам объяснил насчёт того, что нужна система как у конкурента А, только штоб интерфейс поживее.
2. Нет, нужно расписать проблемы и ключевые требования - Ок, вот у нас тут Леночка написала чего-то (1 неделя).
3. Но тут нет x, y, z, которые крайне важны для успеха проекта - Ну так скажите, что там должно быть!
4. Вот вам шаблон - Ок, мы заполнили, смотрите (через 2 недели)
5. Но тут вещи x, y, z написаны неправильно - Ок, а как правильно? Может у вас есть образец?
6. Правильно вот так, вот так и вот так, держите образец - Ок, вот заполнили по образцу (ещё 1 неделя)
7. Теперь лучше, но возникает ряд вопросов... (собственно, пошла работа).

Не знаю, имхо лучше всего сразу устраивать совместную рабочую сессию на полдня, как у Лефингвелла, самому с их слов заполнять правильным образом документы, чем бодаться с шаблонами. Хотя конечно при первичном обращении, когда ещё не понятно, стоит ли работать с заказчиком, альтернативы анкете нет.

Ещё возникла идея насчёт универсальной цели системы - "обеспечить выполнение интересов заинтересованных лиц", всё

Не знаю, имхо лучше всего сразу устраивать совместную рабочую сессию на полдня, как у Лефингвелла, самому с их слов заполнять правильным образом документы, чем бодаться с шаблонами. Хотя конечно при первичном обращении, когда ещё не понятно, стоит ли работать с заказчиком, альтернативы анкете нет.

Так этот документ и заполняется Аналитиком на основе интервьюирования.

1. Не хватает Рисков проекта. 
2. Сценарии я бы писал в стандартном виде как предлагает тот же РУП
3. Согласен с Денисом - бизнес модель (БМВИ и МБО) и глоссарий нужен.

Как вы думаете, этот шаблон для документа "Видение" (Vision) может подойти или есть лучше варианты, если есть, где можно достать?

Классический RUPовский vision можно достать, собственно, в RUP. Он, правда, на английском.

Так есть и русский вариант

Если вам не сложно будет, можете вариант документа  "виденеие" в стиле RUP-а выложить. Буду благодарен!

Если вам не сложно будет, можете вариант документа  "виденеие" в стиле RUP-а выложить. Буду благодарен!

Вам нужен пример?? К сожалению не могу по корпоративным правилам. Если РУПовский шаблон  и пример на русском, то выкладываю.

Благодарю! Будем разбираться. 

Добрый день.
Не подскажите, не есть ли где-нибудь сравнение() документа Vision  и ТЗ по 34му ГОСТу???

Давайте с этого и начнем.
ТЗ по ГОСТ 34 (далее просто ТЗ) предназначено для описания требований к разрабатываемой системе.
Документ Vision предназначен для описания образа и границ проекта, но некоторые пункты документа Vision соответствуют пунктам ТЗ, отсюда и возник вопрос.
Думаю спросите зачем мне это нужно???
Отвечаю:
В данный момент работаю с системой DOORS, задача разработать требования к АС Технологического проектирования (упоминал о ней как-то в одном из постов), так вот тут возникает делема, с одной стороны хочеться формировать требования как советуют нам великие мужи этого дела (Вигерс и иже с ними), с другой же стороны, поскольку система предназначена для гос предприятий, то нужно оформить ТЗ по ГОСТ, и отсюда вытекают ограничения к организации требований.
Вот!

Есть еще ГОСТ на НИР и на технико-экономическое обоснование, посмотрите их.

Ну как я понимаю, что ТЗ консолидирует в себе информацию, полученную на ранних этапах, или я не прав?
Образовался еще одни вопрос.
ГОСТ 24.202-80 регламентирует Требования к содержанию документа «Технико-экономическое обоснование»,  этот документ появляется после  этап "1.1.Обследование объекта и обоснование необходимости создания АС"?

Посмотрите мой доклад на SECR 2006, возможно это будет вам полезно (про мэппинг м/у ГОСТ и представлением того же Вигерса) http://secr.ru/2006/upload/files/63.pdf

Спасибо. Прояснило некоторые моменнты.
Юрий, а какой вы подход у себя используете???

Сказать у себя, очень сложно ... т.к. могут быть ньюансы -- у разных клиентов по-разному. Но обычно я беру за основу "классификацию" требований по Вигерсу, смотрю на специфику работы клиента ... и делаю необходимую кастомизацию.
Вот недавно делал комбинацию SRS и части Vision (бизнес-требования и фичи), т.к. должен был быть ОДИН документ "ТЗ" (ГОСТ тут не причем, заказчик банк с западным капиталом). Причем в качестве требований были восприняты "на ура" юзкейсы, детализации и др. представлений даже решили не делать ... ну заказчик всегда прав :-).