Под классикой я понимал Водопадную модель (http://en.wikipedia.org/wiki/Waterfall_model), из которой выросло в том или ином виде большинство стандартов. И уже потом они вобрали в себя agile-подходы. Так вот, requiremenrs - бизнес-аналитик, design - системный аналитик и архитектор.

Я не имею ввиду ограничить сообщество системным анализом, потому как действительно столь детальное ролевое деление сейчас встречается редко, обычно выделяют роль "аналитик", который занимает позицию между заказчиком и разработчиком, но при этом ограничиваться частью requirements я бы считал неправильным, тем более что по факту, я уверен, многие аналитики занимаются не только этой частью. О чем и был мой пост.

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

Кажется, я недавно встречал такие требования к должности "аналитик" в описании вакансии на одном из сайтов 

У меня была мысль сделать на ЛАФ доклад "Почему системные аналитики не занимаются системным анализом", как раз на тему что обычно ожидают от системного аналитика и что он на самом деле может дать проекту. Но в этом году не сложилось приехать...
Насчет обязаностей - с моей точки зрения самое правильное определение дает (как это не смешно) Википедия: http://en.wikipedia.org/wiki/System_analyst:

A systems analyst researches problems, plans solutions, recommends software and systems, and coordinates development to meet business or other requirements.

Это, как бы, отличительное качество системного аналитика, присущее роли.
А дальше, в разделе "Чем может заниматься аналитик", можно найти все из вышеперчисленных занятий:

...
 * Interact with customers to learn and document requirements that are then used to produce business requirements documents.
 * Write technical requirements from a critical phase.
 * Help programmers during system development, ex: provide use cases, flowcharts or even Database design.
...
...
 * Document requirements or contribute to user manuals.
 * Whenever a development process is conducted, the system analyst is responsible for designing components and providing that information to the developer.
...
 

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

И спасибо Максиму за простое определение

Так вот, requiremenrs - бизнес-аналитик, design - системный аналитик и архитектор

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

Например, в исходном обсуждении в гугл групс было такое пожелание:

Максим прав, хочется услышать больше именно про проектирование. Например, про принципы проектирования систем определенного назначения, например CRM. Тема неисчерпаемая.

В ответ могу предложить доклад о том, как мы проектировали и прототипировали интерфейсы веб-клиента CRM-системы взамен устаревшего десктоп-клиента. Таким образом, если на ЛАФ-2012 наш доклад был о процессе прототипирования в компании в целом, то теперь мы можем показать, как это работает на конкретном проекте. Интересен был бы такой доклад?

p.s. Максим, благодарю за упоминание моего доклада. Все мысли и идеи, представленные в нём, я собрал в статье на Хабре, приглашаю к обсуждению.

Но, наверное, не все так - кто-то из аналитиков делает диаграммы классов/ER-диаграммы, описывают поведение объектов системы? И там есть свои проблемы и решения.

От мне интересно на каких проектах востребовано что-то большее нежели Use case/User Story/GUI Mock up?
3 год в аналитике, для успеха проекта наличие UML и ER диаграм не влияло на разработку.

И если делать UML/ER  диаграммы как показать роботодателю и заказчику ихнюю нужность?

От мне интересно на каких проектах востребовано что-то большее нежели Use case/User Story/GUI Mock up?

Оказывается есть такие проекты.
Например в ваших проектах есть справочники - где и как они хранятся? А ролевая модель?
А сущности , точнее объекты предметной области и логические взаимосвязи между ними  как Вы показываете.
Вот Задача - написать разработчику что делать, перечень полей, и т.п.
То здесь нам  ER поможет. Или просто деятельность какую-нибудь описать.

И не обязательно их Заказчику показывать, если это для разработчика.

Оказывается есть такие проекты.
Например в ваших проектах есть справочники - где и как они хранятся? А ролевая модель?
А сущности , точнее объекты предметной области и логические взаимосвязи между ними  как Вы показываете.
Вот Задача - написать разработчику что делать, перечень полей, и т.п.
То здесь нам  ER поможет. Или просто деятельность какую-нибудь описать.

И не обязательно их Заказчику показывать, если это для разработчика.

Да есть, как правило в состояние на момент старта проекта. При предложение пересмотреть/передизайнить заказчики( в даном случае) девелоперы не понимают зачем им ето нужно. А ПМ зачем на ето тратить еще время.

И если делать UML/ER  диаграммы как показать роботодателю и заказчику ихнюю нужность?

Диаграммы — это инструмент:

1. Быстрой передачи информации. В случае, если используются простые неформальные диаграммы или ARIS eEPC/VAD. Не UML, и даже наверное не BPMN.
2. Обеспечения качества требований. Для анализа полноты, что ничего не забыли из того, что должно как-то отразиться в требованиях — входы/выходы, последовательности, связи. Для этого подходят DFD, UML, ER, BPMN.

Диаграммы 1 могут быть понятны и полезны заказчику при прикладывании оправданных усилий с вашей стороны.
Диаграммы 2 — это ваша внутренняя кухня. Заказчику они на фиг не сдались, также как и покупателю современного телевизора схемы его внутренней разводки. Если повезёт, они также могут быть полезны разработчику для цели 1. Но обычно на это рассчитывать не стоит.

Объяснять работодателю необходимость конкретных видов диаграмм — это всё равно, что объяснять необходимость теодолита для геодезиста.

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

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

Спасибо огромное за описание подхода.