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

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

у нас уже обзначилось распределение ролей в изучаемом нами процессе управления требованиями по участникам обсуждения:
- Вы, greesha, - законный эксперт по формулировкам и пониманию СУТИ каждого требования,
- я взял себе роль ведущего манагера по требованиям, которому просто губительно вникать в суть требований, и без того вокруг них работы полно,
- Galogen добровольно (и очень добросовестно) взялся за работу моего подчинённого-исполнителя,
но на самом деле - это для него должно быть только в режиме парт-тайма,
его главная роль - ВНЕ самого процесса: учредитель проекта,
в рамках которого нужно:
-  построить и запустить "стендовый" процесс управления требованиями,
-  собрать на результатах методический материал для проведения курса своим студентам.

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

Galogen, ещё +1, в буквальном смысле, -  золотой самородок в Вашу копилку метод-материалов:
для менеджмента требований - это то, что обязательно должно быть внесено в Глоссарий, и на что обязательно нужно проставить ссылки из описаний соответствующих требований.

для курса по дизайну - это образец ответа на 5баллов из пяти,
по вопросу "что такое сретч-карта":
коротко, точно, ёмко, понятно.

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

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


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

Разные ответы на этот вопрос ведут к созданию разных систем. Отвечающих одим и тем же требованиям. Это означает, конечно, что требования неполны.


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

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

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

полностью согласен, более того,
я уже опытно знаю, что это - просто ересь.

похоже - нужно уточнить так:
мне нужно абстрагироваться от РЕШЕНИЯ проблем с вниканием в суть,
а "пользоваться готовеньким"  - так это  обязательно:
эдак озадачить Вас и других участников форума, чтоб проясняли и детализировали, что значит каждая формулировка в описании требований,
и самому - собирать и оценивать результаты,
а черновую работу по занесению и отслеживанию актуальности данных по требованиям переложить на Эдуарда в роли своего помощника.

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

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

Или я пока требования фиксирую скажем в Excel? И выкладываю.

С чем сразу нужно определиться?
1. типы требований (по-русски | по-ангельски)
2. статусы требований (аналогично)
3. приоритеты требований (аналогично)
4. риски (аналогично)
5. сложность (аналогично)
6. стабильность (аналогично)
7. дополнительные атрибуты по требованиям?
8. формировать ли требования по группам с соотвествующей нумерацией внутри группы или делать сквозную нумерацию без префикса группы, а группировать через тип требования

Вы говорите об "управлении требованиями" как о втором уровне зрелости CMMI (вон каких я умных слов нахватался ), когда предполагается, что требования разработаны заказчиком. Но пример, похоже, не соответствует этому условию - первые требования появляются из общей концепции системы, которую мы пропустили (или только я пропустил?) Эти начальные требования отсутствуют - значит, либо нужно их тоже перечислить (смоделировав второй уровень), либо разработать самостоятельно, выявив реальные потребности заказчика (третий уровень).
Обе задачи, наверное, могут использоваться как учебные.

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

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

Ну и для наглядности

Ну пока типа бизнес требования в некоторой соподчиненности


Это функциональные требования. Выбраны по признаку "система должна"

...как мы будем обмениваться информацией хотя бы. Есть ли у коллег RaQuest в каком-либо виде?

на д.м. у меня есть ЕА, что нужно, чтобы подключить к нему RaQuest и смотреть результаты "вживую"?

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

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

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

а мне:
- регистрить для него задачи,
- принимать от него и регистрить в СУТ результаты,
- принимать решения на основании этих результатов.

на д.м. е меня есть ЕА, что нужно, чтобы подключить к нему RaQuest и смотреть результаты "вживую"?

Ничего не нужно кроме лицензии. Однако, елси мы управимся за месяц можно спокойно скачать оценочную месячную версию с сайта производителя www.raquest.com

Затем установить программу и все.

Сейчас я использую RaQuest 2.4 (лицензионный) академическая лицензия обошлась в 75 долларов.
и ЕА 7.0 815 билд (пока не лицензионный) академ лицензия стоит 65 долларов. Но после покупки раквеста подожду.

я сформировал список требований в RaQuest используя формат rde. Другой тип форматов eap. Несовсем точно понимаю в чем их отличие. Оба хорошо открываются с помощью Access.
В rde файле фактически хранятся текстовые описания.Однако если в меню выбрать Tools/Run EA, то автоматически загружается EA и все текстовые требования превращаются в графическое представление.
Далее я создаю в каждом пакете требования по графической диаграмме и перетаскиваю требования.
Если создавать графические связи в ЕА, то эти связи потом будут отображаться и в матрице трассировки требований в раквесте.

Таким образом можно упростить связывание и редактирование связей в ЕА и иметь возможность отбора и манипулирования требованиями в раквесте

Вы только, как Учредитель Проекта и Потребитель его результата, дайте визу на функциональные обязанности нашим ролям в процессе управления требованиями:

Gevorg, а мы согласие greesha получили на экзекуцию?

Однако когда я писал ему ответ, я имел в виду немного другой аспект. А именно организацию практических занятий с моим личным участием и участием студентов. Greesha и ВАС рядом не будет. Буду только я азм есть.

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

Забавная троица 3G, может нам домен срочно забронировать под таким соусом?

Ключевой фразой, триггером понимания проблемы служит слово "мотивированный".

Очень сложно студента мотивировать.

Дополнительный аспект это жизненный опыт - который играет страшно немаловажную роль.

Вы как Учредитель Проекта и Потребитель его результата, дайте визу

Ему:

а мне:

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

Вопросы по требованиям:

003 Необходимо использование БАР-кодов для номеров скретч-карт
      1. Что такое БАР-код

004 Необходимо использование БАР-кодов для секретных кодов скретч-карт
      2. Каким образом считывается секретный код, т.е. как определяется считывание именно секретного кода, а не номера карточки

006 Система должна позволять регистрировать набор номеров скрэтч-карт путём ввода начального и конечного значения диапазона номеров
013 Система должна давать возможность вводить номера карт, которые попадают в диапазон номеров для регистрации, но которые являются исключением, и регистрации не подлежат
      3. в пояснении было написано, что регистратор вводит вручную номер бракованной карты - неясность с БАР-кодом и использованием оборудования для его ввода

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

008 Регистрация в Системе прихода средств на счёт компании должна выполняться на основании информации из банка
      5. Предлагется переформулировка - Система должна регистрировать приход средств на счёт компании на основании информации из банка
      6. Уточнить что такое информация из банка (квитанция, переданная каким-либо образом, автоподтверждение ИС банка)

009 Регистрация в Системе прихода средств на счёт компании должна выполняться на основании телефонного звонка от финансового директора
      7. Чем отличается регистрация по звонку финдиректора, когда она происходит, чем отличается от требования 008. Вопрос коррелирует и к требованию 015
      8. Переформулировка: Система должна регистрировать приход средств на счёт компании на основании
телефонного звонка финансового директора

      9. Чем отличаются кроме формулировки требования 005 и 011

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

распределения ещё не было, объявления - тоже,
я по-осторожничал, и написал, что ОБОЗНАЧИЛИСЬ роли и их распределение между участниками форума :-)
1. Вы, как инициатор темы и заявитель Основной своей Потребности -
получаетесь и Спонсор, и Инициатор зародившегося проекта:
- Это именно Вам в первую очередь нужно собрать методический материал для ВУЗ-овского курса "Управление требованиями".
- именно Вашей активностью на форуме держится вся работа вокруг этого,
- именно в контексте Ваших интересов и пожеланий должна вестись работа в рамках данной темы.

2. С другой стороны - Вы взяли на себя часть работ по управлению требованиями:
- настроить соответствующее ПО,
- научиться им пользоваться и научить других,
- вносить туда, в это хранилице, требования, из процесса, который мы строим на форуме,
- поддерживать требования в актуальном состоянии и доносить все изменения до остальных участников проекта.
А это всё - обязанности Менеджера Требований, но только часть, поэтому пришлось ввести роль Джуниор Реквайеремент-манагера и открыто сказать, что фактически - Вы её уже исполняете.

И та и та роль в контексте Исполнитель - Заказчик нашей гипотетической разработки ПО лежит в области Исполнителя.
по первой роли, Вы - Инициатор ВНУТРЕННЕГО проекта,
по второй -  "рабочее звено" во внешнем проекте: написание заказного ПО.

Есть ли у коллег RaQuest в каком-либо виде?
Или я пока требования фиксирую скажем в Excel? И выкладываю.

Даже если у коллег нет RaQuest'а, тебе не зачем фиксировать все в Excel, ведь raQuest умеет делать экспорт в эксель. И импорт из csv. Заодно и проверим, хорошо ли он это умеет делать. Так что не надо мучицца ;-)