Greesha, моя классификация вовсе не претендует на истину. Скорее это попытка хоть что-то предприянть в данной ситуации.

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

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

Кроме того, пока все сводится к анализу требований, а не управлению.

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

При этом не понятны роли и обязанности участников. Кто же все-таки у нас кто.

Если все-таки мы в данном контексте сосредоточены на исполнении поручений, тогда можно предложить такую ролевую расстановку:

Автор задачи, поручения, или автор требования. Генерирует требование.
Менеджер. Принимает задачу, определяет исполнителя, контролирует выполнение
Исполнитель: выполняет задачу, анализирует требование, принимает по нему решение
Рецензент: проверяет требование (возможно это и есть автор задачи)

Хотелось бы так же понять каков цикл работ.

Я не знаю как это происходит или как это должно происходить, могу пока только предполагать.

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

Смотрите пример регламента и распределения ответственности ролей в документе Апланы: http://pmprofy.ru/content/rus/58/588-article.asp

Greesha, моя классификация вовсе не претендует на истину. Скорее это попытка хоть что-то предприянть в данной ситуации.

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

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

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

Мне не кажется, что события развиваются в хаотическом порядке. Всего-то нужно дать начальные данные (vision) по проекту "учёт карт" - главным образом, с какой целью разрабатывается система. Gevorg ответил, что она заказчик - коммерсант, он закупает карты крупным оптом по одной цене и продаёт мелким оптом по другой. Осталось выяснить цели создания "системы учёта карт" и взаимосвязь этого учёта с поступлением средств на счёт компании. (Если взаимосвязи нет, то получается, что разрабатываются две разные системы).

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

Вернемся чуть-чуть назад.

После некоторой дискуссии с Gevorg, он предложил. что занятия по управлению требованиями должны состоять примерно в следующем:
1. дается некоторый набор требований (10-15) однозначно понимаемых, трассируемых
2. студенту предлагается классифицировать требования
3. составить матрицу трассировки
4. задать вопросы

Я высказался в том смысле, что требования без конкретного контекста и цели могут быть интерпритированны совершенно по разному и необязательно неверно

Кажется мы пришли к мнению, что это действительно так.

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

Хотелось бы все-таки понять с чего начинается управление требованиями и каков примерный порядок действий по их управлению, а также какие действия сюда следует включать, и как это можно оформить с помощью каких-либо инструментов (в частности RaQuest)

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

Здесь ведь тоже возможны разные подходы. Можно сконцентрировать внимание именно на приёмах управления требованиями (что-то вроде рисования палочек в прописи), а можно рассматривать управление требованиями в рамках всего жизненного цикла проекта (если они уже знакомы с моделями ЖЦ). Соответственно, и задачи практикума разные.

И пара уточняющих вопросов по пунктам.

1. дается некоторый набор требований (10-15) однозначно понимаемых, трассируемых

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

2. студенту предлагается классифицировать требования

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

3. составить матрицу трассировки

Имеется в виду трассировка требований на тесты?

Я высказался в том смысле, что требования без конкретного контекста и цели могут быть интерпритированны совершенно по разному и необязательно неверно

Кажется мы пришли к мнению, что это действительно так.

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

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

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

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

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

Здесь ведь тоже возможны разные подходы. Можно сконцентрировать внимание именно на приёмах управления требованиями (что-то вроде рисования палочек в прописи), а можно рассматривать управление требованиями в рамках всего жизненного цикла проекта (если они уже знакомы с моделями ЖЦ). Соответственно, и задачи практикума разные.

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

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

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

Исходя из некоторых систем классификации, которые им уже знакомы из теоретического курса?

Да это предположение. Я буду читать курс по анализу требований и собираю под него материал и ищу способ его подачи.

Или из системы классификации, предлагаемой используемым инструментом?

Вообще RaQuest не предлагает никакой классификации. CaliberRM - предлагет. Здесь можно основываться на SWEBOK.

Или выбрать классификационные признаки самостоятельно, исходя из каких-то особенностей создаваемой системы?

Вероятно - это было бы лучшим способом, но мне неизвестна классификация требований, контекстно зависящая от конкретики задачи. Существуют разные признаки для классификации: по статусу, по стабильности, по сложности - это управляемые классификации, есть классификация FRUPS+ - которая мне понятна и близка. Есть классификация вигерса, лиффенгуэлла и им подобным. Разница на мой взгляд не принципиальная, можно оттолкнуться от той которую мы выработаем.

Имеется в виду трассировка требований на тесты?

Ну не обязательно. Матрица трассировки требований между собой, между требованиями и UC, между требованиями и проектными решениями, между требованиями и тестами. Последнее конечно самое важное.

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

У меня тоже, кажется, именно это я в свой фразе и подчеркивал.

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

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

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

Скорее всего нужно будет дать описание такого процесса.

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

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

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

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

ещё раз приношу извинения за отсутствие на форуме, тема очень интересная и очень хочется завершить начатое,

полный цейтнот на работе, надеюсь за  выходные что-то успею

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

Gevorg, все нормально. Сами часто втаких ситуациях бываем и будем...
Но ждем Вашей руководящей линии

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

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

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


по нашему стендовому проекту 
"Разработка заказного ПО для торговца пластиковыми карточками".

Краткое описание деятельности Заказчика:
Крупнооптовая закупка скрэтч-карт от крупного провайдера услуг в Столице
и мелкооптовая ПЕРЕпродажа мелким реализаторам карточек из провинциальных городов.
Финансовые потоки между Провайдером и Фирмой просты и прозрачны, уже автоматизированы в бухгалтерском ПО.
Между Фирмой и реализаторами существуют 2 вида денежных потоков:
- БНР, тоже автоматизированный в бухгалтерском ПО и
- рассчёт наличными, особо больное место в бизнесе, ведётся на грани нарушения законодательства,
крайне нуждается в реинжиринге, правильном учёте и автоматизации.
--!! Управленческий учёт отсутствует, сведение отчёта по какому-либо из Реализаторов
- всегда проблема, решение которой не обходится без скандала.

Роли у Заказчика:
- ТОП. Хозяин бизнеса, Раздражителен, скандален, даже временами хамлив.
Скрывает особенности своих бизнес-процессов, поскольку имеет с ними ряд серъёзных проблем.
Реально - под видом разработки и внедрения заказного ПО хочет провести реинжиринг своего бизнеса.


Финансовый директор. имеет только громкое название.
На самом деле, главная его обязанность  -
ездить по провинциальным городам и "трусить должников".

Бухгалтер.
Добросовестно сводит балланс по безналичным рассчётам и отбивается всеми способами
от попыток нагрузить её учётом движения наличных средств и карточек.
Разрабатываемую систему рассматривает как инструмент агрессии в свою сторону.

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

Финансовый и бизнес-аналитик. Появляется намного позже.
Занимается построением полноценного управленческого учёта
на основе уже реализованной в нашем ПО функциональности и своих дополнительных хотелок.
Одна из них - возможность принимать от Провайдера и учитывать номера использованных скретч-карт.
Счастливая находка для эффективного обнаружения фактов задержки Реализаторами средств от уже проданных карт.

Роли у Разработчика:
- Менеджер требований(RM). В полном смысле должнен быть "держателем" самих требований и работы с ними.
Пребывает в полной уверенности, что 80% работы с требованиями не несут в себе проблем касательно их сути,
Требования либо уже понятны, либо работа с ними требует только поверхностного понимания сути
при большой важности глубокого понимания контекста в проекте.
из оставшихся 20%  надеется часть спихнуть на энергичного и начитанного (а главное - низкооплачиваемого) помощника,
а что останется из уж совсем трудного - пригласит (на сэкономленные средства) стороннего эксперта-аналитика.
Ленивый прагматик до мозка костей.

- Младший менеджер требований(jRM).
Имеет большой теоретический багаж, опыт работы c CASE-средствами, энергичен и работоспособен.
При недостатке опыта в работе с требованиями и отсутствии "груза ответственности за конечный результат",
активно и добросовестно берётся за любую посильную черновую работу.

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

Это пока только моё представление по стендовому проекту.
Дальше обещаюсь изложить своё понимание ролей в проекте, учредителем которого является Galogen, как инициатор темы.
Здесь мне уже не получится быть в роли ленивого и полуграмотного по части понимания "физической сути" требований :-)

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

Отлично, Gevorg. Очень интригующая постановка.

Особенно мне понравился момент про низкооплачиваемого добросовестного помощника, видать с меня писался, а гуру-эксперт не иначе greesha.

По существу.
Я буду по совместительству стенографистом нашей команды. есть ли пожелания по стилю оформления.
Данный документ я полагаю можно назвать как характеристика объекта автоматизации. Только для внутреннего использования.

Кстати задачи и роли, а также возможно характеристики можно фиксировать в gantt project, где то на сайте есть ссылка: в поиски набрать gantt project/

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

а гуру-эксперт не иначе greesha.

"Царь у вас какой получился типичный... На нашего Буншу похож!"

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

"Царь у вас какой получился типичный... На нашего Буншу похож!"

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

Greesha, это мое предположение, возможно ошибочное

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

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

Абсолютно. Причем кажется это уже обозначилось даже раньше, чме просто были опубликованы требования. Но наверное это неизбежный процесс притирки, а может gevorg нас проверял.

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

Не совсем понимаю, что именно обозначилось раньше?

Если речь идёт о том, что общие представления о деятельности Заказчика были у меня в голове ДО того, как я писал список требований?
То да, часть представлений уже была, но часть пришлось додумывать  и упрощать по ходу обсуждения в “10-и страницах флуда”.

Или о том, что участники форума уже сами пришли к тому же представлению, а я только повторил?