Требования: Знание UML, IDEF0, DFD, IDEF3. Умение правильно создавать UseCases.
Умение работать с Rational Rose, ERWin, BPWin, Visio.
Знание теории СУБД.
Знание систем контроля версий и учета замечаний.
Опыт работы с Oracle и Delphi.
Опыт работы в этой должности от 1 года.

Обязанности: Проведение обследования
Выявление требований
Описание бизнес-процессов
Первичная модель БД
Первичная разбивка на модули
Первичное определение прогр.интерфейсов модулей
Дизайн визуальных форм
Написание техпроекта по стандартам фирмы
Написание первичной прграммы тестирования
Составление спецификаций для программистов
Участие в рассмотрении замечаний и в их назначении.

а контакты для связи?
Непосредственно с Вами?

За знание теории СУБД нужно как минимум 5k платить )

ИМХО неплохо указать месторасположение работы...

За знание теории СУБД нужно как минимум 5k платить )

Эк ты махнул. Там же написано опыт работы с Оракл, а знание теории СУБД (имхо имелось в виду теории РБД)

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

Требования: Знание UML, IDEF0, DFD, IDEF3. Умение правильно создавать UseCases.
Умение работать с Rational Rose, ERWin, BPWin, Visio.

На самом деле достаточно сложно быть одинково компетентным и в IDEF и в UML, но более интересно другое ..неужели это все действительно используется, и притом профессионально а не "в стиле Visio"? Кроме этого, зачем использовать разные нотации, проще все на одном языке делать.

Втрой момент, умение ПРАВИЛЬНО создавать UC. Что есть "правильно"? UC это текстовые спецификации имеется ввиду или таки диаграммы UML? Если текстовые спеки, то это работа роли Аналитик, а использование IDEF0, IDEF3 -- это вчистую бизнес-процессы, т.е. грубо тянет на роль бизнес-аналитик.

Знание систем контроля версий и учета замечаний.

Конечно вопрос в каком объеме ... и КАКИХ систем ... ClearCase конфигурить -- это одно, а SourceSafe - другое ... И issue trackers, они тоже разные бывают. Может конечно сформулировано требование к skills некорректно ... а требуется всего лишь опыт пользовательской работы с таким инструментарием (опять-таки, с каким?). Но если конфигурить и еще и процесс имплементировать на них, то это имеем другую роль -- Менеджера конфигураций.

Знание теории СУБД.
Опыт работы с Oracle и Delphi.

Хм ... писать на таком RAD как Delphi (интересно, а он лицензионный? ... я уж про BPWin, ErWin и Rose и спрашивать боюсь :-)) и активно использовать UML ... хотел бы я взглянуть как это происходит, а то есть сомнения ...

Обязанности: Проведение обследования
Выявление требований

О! это точно вам нужен не проектировщик, а Аналитик ... не всякий проектировщик может выявлять требования и быть хорошим коммуникатором.

Описание бизнес-процессов

Хм, я бы это поставил перед выявлением требований ... хотя еще вопрос что принято понимать под БП в этой компании.

Первичная модель БД

Чесслово не понимаю что это ... я всегда думал что есть логическая и физическая модели БД .. ну век живи ... Но это уже ближе к Проектировщику!

Первичная разбивка на модули
Первичное определение прогр.интерфейсов модулей

О .. тут уже попахивает программной архитектурой :-)

Дизайн визуальных форм

Чесслово приходится догадываться что имеется ввиду! Юзабилити? Хочется верить что это именно так, ибо сложно себе предстваить что вы ДЕЙСТВИТЕЛЬНО в UML расписываете ВИЗУАЛЬНЫЕ ФОРМЫ ... это достаточно трудоемко и толку от этого немного. Особенно если они меняются часто .. поддерживать их актуальность в UML еще та работка.

Написание техпроекта по стандартам фирмы

Ох уж эти "стандарты фирмы" ... помесь RUP и ГОСТ :-) ... коктейль молотова.

Написание первичной прграммы тестирования

О ... а это уже роль Тест-инженера!

Составление спецификаций для программистов
Участие в рассмотрении замечаний и в их назначении.

Уфф ... просто какой-то универсальный солдат нужен! .. толкьо что его еще и код писать не заставляют. И всего-то за 2000 баксов ... такие деньги обычно аналитику, который ТЗ пишет и не береться проектировать софт ... а вы хотите чтобы и швец, и жнец ...
Общий вывод, если это сообщение не написано только HR-ом .. то встает вопрос об уровне зрелости процессов такой компании и вообще компетенции в области процессов программной инженерии ...
Ребята, я серьезно ... давайте я вам процессы поставлю, чесслово возьму вполовину меньше сумму, чем беру обычно .. ! И тогда вы сможете писать осознанно какие специалисты и с какой экспертизой вам ДЕЙСТВИТЕЛЬНО нужны.

Юрий, ну тебя торкнуло Хэнесси и сигара
Или народ так сосокучился по хоть какой-нить теме в разделе Работа

Да уж, торкнуло, реально ... просто я вчера несколько злой был. Приехал в одну контору (правда опоздал на встречу на 30 минут, каюсь -- пробки мать их ... еще не разу в этом году 2 часа не добирался автобусом до ВДНХ самое долгое было 1,20) а там  народ вопрошает меня про возможности одного инструментального средства для RDM. Я у них спрашиваю, расскажите хотябы как вы работаете, как и для чего хотите использовать. Они в ответ ... мы вот о CMMI думаем, об уровне 2 (!!!!). Я им поясняю -- типа отлично ребята, но я не продаю лицензии на инструментарий, а мои деньги -- это сервисы вокруг него, процессы, тренинги ... Вот и говорю, расскажите как вы работаете и для чего собираетесь инструмент пользовать ... чтоб я мог подсказать какие-то моменты.
На что получаю интересный, но контрпродуктивный ответ "типа рассказывай, а мы если что спросим" и фраза, которая меня УБИЛА напрочь ... "мы вам тут расскажем, а вы пойдете и будете это применять в других компаниях". Я даже растерялся что ответить, чтобы не обидеть людей ... ведь ЕСЛИ РЕЧЬ ИДЕТ ТОЛЬКО О ВЫХОДЕ НА 2 уровень CMMI, ТО КОМУ ИНТЕРЕСНЫ ТАКИЕ ПРОЦЕССЫ (а точнее их отсутствие), когда половина контор стремится на 3-й прыгнуть? Другой вопрос если бы они на CMMI 5 метили с 3 или 4, я бы не обиделся :-).
Результат общения был предсказуем ... одна леди, которая как раз и говорила что типа рассказывай а мы спросим, заявила что она ничего не поняла. Напрасно я вещал им про то что такое вообще требования и в чем отличие использования иструментария от документно-центричного подхода :-). Что и логично ... Ну неужели настолько все плохо с процессами в конторе, что боятся другим поведать как они работают, даже В ОБЩЕМ ВИДЕ ... ? Хотя нужно отдать должное одному из участников встречи -- который похоже был в теме инструментария и процессов. Он единственный задавал вопросы грамотно ...

Не RUP-ом единым ... никто не говорит, что нужно адаптировать именно RUP. И на самом деле я не являюсь таким уж ярым адептом RUP :-). Да, я на самом деле имею предствление о том что такое RUP. Но я имею предстваление и о других методологиях и стандартах. И естественно я не стану рекомендовать адаптировать RUP, в случае, если заказчику нужно просто создавать документацию требований :-) и управлять изменениями. Да, можно рекомендовать некоторые практики которые описаны в т.ч. и  в RUP. Кроме этого, кто сказал что RUP не масштабируется на команду из 3 человек???
Второй момент, если в компании действительно поставлен процесс, и проекты большие .. то такое объявление врядли появиться. Но возможна и другая ситуация ... контора маленькая, и нужен универсальный солдат, который будет ВСЕ это делать. Но позвольте, если проект маленький ... НА КОЙ ТАКАЯ ФОРМАЛИЗАЦИЯ? Это не оправдано в таких проектах (имеется ввиду например проектирование визуальных форм на UML) и документация -- "спецификация для разработчиков". Да, можно еще одно предположение в оправдание такой формализации сделать, что разработчики на аутсорсинге или удаленно работают. Но это врядли.
Более реальна ситуация (опять-таки это только мое предположение "сидящего в кресле с Хэнесси и сигарой умника") когда действительно используется весь этот зоопарк (IDEF, UML) или людям совершенно бЭз разницы на чем будут "нарисованы бизнес-процессы", т.е. обчный бардак :-), когда просто заказчику пудрят мозги, типа "смотрите какие мы крутые картинки рисуем".
Я насмотрелся на такое .. видел я типа ТЗ, с картинками на UML ... только value от них небольшое. Просто как обычно удовлетворение амбиций начинающих изучать UML и пихающих его куда ни попадя, т.к. нет достаточно четкого предстваления о том как методически правильно его использовать (сам через это прошел ;-) в свое время).

Хм ... писать на таком RAD как Delphi (интересно, а он лицензионный? ... я уж про BPWin, ErWin и Rose и спрашивать боюсь :-)) и активно использовать UML ... хотел бы я взглянуть как это происходит, а то есть сомнения ...

В Тройке-Диалог в конце незабываемых 1990-х использовался RAD - правда, не Delphi, а Power Builder.
Но UML они использовали активно при этом. Причем не совсем на детском уровне.