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

Рисование мелом на доске (лучше - цветным маркером) вполне работает и на больших проектах (несколько лет разработки). И оно становится настоящей документацией, если сфотографировать и выложить в систему ведения дока. А если что изменилось - нарисовать новую и опять сфотографировать, с простой схемой это легче, особенно если она появляется в обсуждении, а не имеет персонального авторства. Естественно, часть артефактов должна быть не в таком виде, например, диаграмма классов системы предпочтительна электронная - чтобы поддерживать актуальность. А вот эскиз формы - зачем он? Когда форму сделают - на нее всегда можно посмотреть живьем. Если оценивать количественно, то большинство артефактов постановки может быть легким, а меньшинство, хотя и самое существенное - сделано в полноценном виде.

Рисование мелом на доске (лучше - цветным маркером) вполне работает и на больших проектах (несколько лет разработки). И оно становится настоящей документацией, если сфотографировать и выложить в систему ведения дока. А если что изменилось - нарисовать новую и опять сфотографировать, с простой схемой это легче, особенно если она появляется в обсуждении, а не имеет персонального авторства. Естественно, часть артефактов должна быть не в таком виде, например, диаграмма классов системы предпочтительна электронная - чтобы поддерживать актуальность. А вот эскиз формы - зачем он? Когда форму сделают - на нее всегда можно посмотреть живьем. Если оценивать количественно, то большинство артефактов постановки может быть легким, а меньшинство, хотя и самое существенное - сделано в полноценном виде.

Метод фотографирования нарисованного мелом очень хорош при адекватном применении, обратного я и не утверждал. Но не универсален и не серебрянная пуля. Есть своеи плюсы, но и минусов хватает.
Критичен не общий размер и длительность проекта сами по себе (тут меня поймали на слове), а:
- количество и частота изменений - начиная с некоторого предела задолбаешся перерисовывать
- число участников обсуждения архитектуры конкретного модуля (малокритично впрочем - могут потом фотографии посмотреть)
И, к тому же, не всем подходит - лично мне проще набросать диаграмки в case чем нарисовать что-то аккуратно от руки - разьве только что-то для себе, чтобы никто не видел:))
То что артефакты постановки должны быть максимально легкими в минимально достаточном количестве и качестве - согласен. Волпрос только в том, что входит в этот минимальный набор в каждом конкретном случае.
Что касается необходимости проектирования внешнего вида интерфейсных форм вообще - то это отдельный дискуссионный вопрос.
Иногда можно обойтись - достаточно определить состав полей, источники данных, их свойства и поведение, а морду форм программист сам нарисует.
В других случаях, наоборот, надо согласовывать дизайн форм с заказчиком - тогда это даже не проектирование форм, а определение требований к ним, и выполняется на этапе анализа требований.
Хроошее компромисное решение - нарисовать прототипы форм в том же интсрументе, в котором ведется разработка, но без функциональности, назвать это прототипом и всем показывать. Но - это, как правило, не могут сделать аналитики, они могут только увидеть результат и раскритиковать.
А еще бывают извращенцы, которые прототипы форм рисуют в ворде псевдографикой (вот сейчас наверняка найдется кто-нибудь, кто кинет в меня помидором, и раскажет, как это удобно:)))

Алгоритм действий для разработчика это должно быть:

Алгоритм действий для разработчика это должно быть:
Цитировать:
Открой редактор кода
Напиши #include <stdio.h>
Напиши void main() {
…

Нет, для этого существует старый добрый псевдокод:))
Кстати, кроме смеха, эффективный, хотя и очень трудоемкий метод, программисты любят.
Стоит использовать, например, для документирования критичных ХП и триггеров в базе данных.
Что попроще - просто русский структурированный естественный язык в стиле описания сценариев (см. ход процесса use case и другие).

В таком варианте - полностью согласен. Мне, кстати, тоже проще накидать диаграммы в visio, чем от руки - когда один делаю, а вот при коллективном обсуждении и проработке - наоборот, на доске проще. Так что всякий инструмент хорош к месту. А что касается форм - то я имел ввиду сложные формы, где надо располагать области и описывать взаимодействие. Тут, кстати. мне лично мне не хватает средства моделирования в котором можно было бы прикинуть форму с характерным наполнением модельными данными под разными разрешениями и размерами шрифтов, а надо бывает... Наверное, действительно можно в конечном инструменте, но слишком напоминает "модель паровоза в натуральную величину"...

Ну на это у нас прогеры аргумент такой выдают: "Вы кто, системные аналитики или бизнес? Вот и пишите конкретно что программировать, какие данные в какие поля таблиц складывать"...

Говорят ПОЧТИ правильно - не обязаны прогеры разбираться в хитросплетениях финансовых алгоритмов, у них от своих забот голова пухнет. Вот только адресовать свой вопрос они должны не аналитикам, а проектировщикам. У аналитиков своих забот хватает, про поля таблиц они могут ничего не знать.
Для этого нужен специальный человек, который на первый взгляд, вообще не понятно в чем разбирается: он хуже знает бизнес, чем аналитик, и хуже программирование, чем программист. Зато может выступать переводчиком с аналитического на программерский:))

2 Странник
Конечно, программеры любят псевдокод. Им тогда ничего делать не надо, переписал его на языке - и все. Только... Тогда их работа - уровня тупой секретарской (есть квалифицированная секретарская, не путать), записал слова начальника - набил в файле. Нужны ли сейчас такие программеры? И согласны ли они получать как секретари?

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

2 maksiq

Вообще-то моя реплика про псевдокод была ироничным ответом на конкретную фразу:
Алгоритм действий для разработчика это должно быть:
Цитировать:
Открой редактор кода.....и т.д.
и содержала в себе большую долю шутки (смайлики там были )
Но и серьезный остаток тоже там есть.
Любые тяжелые методы анализа и проектирования стоит применять выборочно, только тогда когда в них есть обоснованная необходимость. Это относится кстати говоря и к графическим нотациям - тома диаграмм бизнес-процессов производят конечно впечатление на неискушенных клиентов и начальников, но отношение практической пользы для разработки к трудозатратам у них весьма сомнительное (IMHO конечно, может кому и помогает).
Расписывать сколько-нибудь подробно все подряд в системе - это совершенно бездарное занятие (среди всего прочего - программисты быстрее кодируют, чем проектировщик пишет ). Но критические и сложные для понимания процедуры документировать может быть в некоторых случаях целесообразно. IMHO стоит подробно документировать серверные процедуры, реализующие бизнес-логику и ограничения  (разделение логики по слоям - другой вопрос). Не увлекаясь при этом подробностями - только логику упрощенно, без деталей реализации - что откуда берется и куда кладется.  Перегнать потом в PL/SQL или TSQL, оптимизировать и отладить - задача простая, но не тупо тривиальная. Нотация будет конечно не вполне классический псевдокод (как в учебниках инфоматики) - скорее русский естественный структурированный язык:).

По второму пункту - нашт программисты много чего умеют. В некоторых (вполне успешных) проектах и аналитика нет - программисты сами выпытывают требования у клиента. Но все же разделение труда придумано не зря - не может один человек одинаково хорошо все уметь

Проектировать базу должен именно аналитик - так только он знает каким образом будут использоваться данные, которые лежат  в базе. 

Какой аналитик? Системный или бизнес?

Что касается бизнес-аналитика, соглашусь с постом Эдуарда:

Проектировать БД должен проектировщик, аналитик может представить возможную структуру данных и типы значений. А проектировать БД будет проектировщик.

Смотри: http://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B1%D0%B0%D0%B7_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85

Уровень аналитика - Концептуальное (инфологическое) проектирование
Уровень проектировщика (дата бейс архитектора) - Логическое (даталогическое) проектирование
Уровень администратора БД - Физическое проектирование

Тут, кстати. мне лично мне не хватает средства моделирования в котором можно было бы прикинуть форму с характерным наполнением модельными данными под разными разрешениями и размерами шрифтов, а надо бывает...

Rational Requirements Composer не пробовали? есть там работа с раскадровками в том числе возможности моделирования экрана
http://www.ibm.com/developerworks/ru/library/r-1118_zhuo/index.html

LDV, спасибо, но судя по описанию - это не то, что мне нужно. Там раскадровки преимущественно для web, у нас формы на MS с качественным гридом (и это надо смотреть). Ну и линейка Rational - она дорогая.

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

Верно! Именно так, как говорите и должно быть, никак иначе!
Программист, на то он и программист, чтобы программировать, а также записывать все то, что он делает.
Я, аналитик. В задачи входит описать ТО, что нужно получить от системы
Программист - видит описание - создает классы, формирует код, все это фиксирует в программе

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

Я, аналитик. В задачи входит описать ТО, что нужно получить от системы
Программист - видит описание - создает классы, формирует код, все это фиксирует в программе

В этой схеме, на мой взгляд, отсутствует роль специалиста, который скажет КАК должна работать система. А это очень необходимо, потому что:
- ТО, что нужно получить от системы можно реализовать множеством различных способов;
- далеко не каждый из этих способов них удовлетворит заказчика.
Поэтому необходим ктото, во-первых поймет КАК должна быть реализована система, чтобы удовлетворить ожидания заказчика, а во-вторых согласует с заказчиком это (путем демонстрации прототипа, просто на словах или рисованием на бумажке - не важно) и возмет на себя ответственность за то, что выбранный способ реализации - верный (т.е. удовлетворяет заказчика).
Эти все функции, как мне кажется, возложены на роли архитектора и дизайнера UI. Хотя, конечно, часто, роли архитектора и дизайнера UI совмещают с ролью аналитика или программиста...
Коллеги, я прав или ошибаюсь?

Уровень аналитика - Концептуальное (инфологическое) проектирование

Прочитала: "мифологическое" проектирование

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

Заказчику не нужно знать как система реализована.
Ему нужно выполнение его задач. Чем меньше заказчик знает о внутреннем устройстве системы, тем крепче он спит и счастливее выглядит.
К сожалению, в силу нечеткости границы между анализом и проектированием, трудно полностью исключить детали реализации из того, что согласовывается с заказчиком.
Это сильно тормозит процесс.

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

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

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