Ключ к успеху крупного проекта - грамотная декомпозиция задач.
Сначала делается общее видение проекта (аналитиком или ПМом), в котором охвачены все границы проекта. Этот документ - охватывает весь проект.
В нем упор идет на бизнес-цель и бизнес-процессы. Видение как раз подходящий документ для красивых и больших картинок, которые так любят руководители:)

Хм. Вот эти "документы" мне бы и разработать. Только с Ваших слов мне не совсем ясно как и что именно входит в каждый.
Говоря о слонах... До начала обсуждения на этом форуме я его и видел. А теперь передо мной стадо слонов. И каждого надо есть по частям... 

И дело должно быть направлено не на следование формальной нотации, а на максимально качественное выявление и описание требований, если говорить об аналитике.

Ясно. Буквоедство плохо. Понимание реалий, живых тенденций хорошо.
С какой стороны начать?... Вот в программировании, условно скажем, в начале изучаются лексические основы языке, далее структуры обработки информации (линия, ветвление, цикл) и т.д. Вот что мне именно отрезать у слона и съесть первым?

Понимаете, это сложный момент. Нет однозначного ответа. Есть некоторые рекомендации в рамках некоторого подхода или практики.

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

Читаю http://book.uml3.ru - может позже смогу более точно "понять" что мне нужно.

Как говорится, слона надо есть по частям.
Ключ к успеху крупного проекта - грамотная декомпозиция задач.

Хотелось бы дополнить... Разделение на части начинается на уровне аналитика. Функциональные требования делятся на фичи и варианты использования. В свою очередь ВИ делятся на потоки. Разработчики, дизайнеры, архитекторы, тестировщики также работают с каждым ВИ или потоком ВИ в отдельности. На уровне архитектуры/дизайна система также разбивается на части - слои, подсистемы, компоненты, сервисы. Таким образом, работая с каждой частью в отдельности, слон съедается частями.

Я понимаю, что задачи решаемые системными аналитками сложные. Я понимаю, что они даже сложнее, чем я могу понять.

Задачи не сложнее, чем решает программист (а лично на мой взгляд - даже проще). Просто в другой плоскости.

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

Вы всерьез вознамерились заняться боксом по книге? С намерением "прям завтра" выйти на профессиональный ринг (пусть даже всего на один матч)? Последствия представляете? Ну, для тех, кто на Вас поставит и лично для Вас?

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

Только сейчас нужен результат и нужен быстро.

Полностью соглашусь с Леонидом. Он высказал похожие на мои мысли. Впрочем они очевидны.

Спрошу лишь. Можете ли вы точно объяснить
1 - какой результат вам нужен
2 - почему быстро

Спасибо.

Хм. Вот эти "документы" мне бы и разработать. Только с Ваших слов мне не совсем ясно как и что именно входит в каждый.
Говоря о слонах... До начала обсуждения на этом форуме я его и видел. А теперь передо мной стадо слонов. И каждого надо есть по частям... 

Состав документа - это уже проще и можно посмотреть в википедии.
Главная проблема у вас, как я понял, не знаете за что схватиться первым. Для этого я стащил из интернета картинку, которую приложу к цитате ниже.

Ясно. Буквоедство плохо. Понимание реалий, живых тенденций хорошо.

Воистину так!

С какой стороны начать?... Вот в программировании, условно скажем, в начале изучаются лексические основы языке, далее структуры обработки информации (линия, ветвление, цикл) и т.д. Вот что мне именно отрезать у слона и съесть первым?

Теперь о главном.
Вот картинка из книги Вигерса, которую я стащил откуда-то. Ей сто лет в обед, но она не теряет актуальности.


1. Функционал всегда отталкивается от бизнеса. Никто не разрабатывает коммерческое ПО просто так, ради опыта или использования крутых технологий.
2. Самое первое - надо понять что будет делать ПО. Т.е. какую глобальную бизнес-потребность оно будет удовлетворять.
3. Как раз эти бизнес-требования и записываются в видение проекта в документ "об образе и границах проекта".
4. Когда такой документ создан, следующий шаг - определение функционала, который удовлетворит бизнес-цель.
5. Для того чтобы определить весь нужный функционал, надо общаться с заинтересованными лицами. Можно использовать например диаграмму вариантов использования из UML. А можно и не использовать:)
6. Когда функционал определен, он разбивается на задачи. Под каждую задачу пишется ТЗ. Разработчики разрабатывают, тестеры тестируют. Дальше уже дело техники.

И последнее. То что сейчас нужно - просто влезть в дело с головой. Как только начнешь делать что-то на практике, появится прогресс, появятся конкретные вопросы по конкретным процессам. Пойдет дело:)

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

Маленький оффтоп.
Жизненный опыт подсказывает, что порядка 2/3 личного состава команд разработки (от тестировщика до руководителя проекта) именно этим и занимаются.

Маленький оффтоп.
Жизненный опыт подсказывает, что порядка 2/3 личного состава команд разработки (от тестировщика до руководителя проекта) именно этим и занимаются.

Печально, если так!
Хорошо, я уточню формулировку:)
Никто не заказывает коммерческое ПО просто так, ради опыта или использования крутых технологий.

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