дак речь у нас не о книжках, а о "поделиться опытом" и получить критику от форумчан, в том числе и в плане есть\нет в книжках, может я велосипед изобрёл :-)

Gevorg (кстати, а как вас/тебя зовут?),
Во-первых, ни в коем случае не хотел обидеть. М.б. немного резковато выразил свою т.з.
Во-вторых, Ну не вижу смысла дублировать требования, ведь ВИ - это пользовательское требование. А что реализовывать или нет и когда, - это уже планирование. Если надо детализировать ВИ, то создаем системное требование и трассируем к ВИ и все. Я делаю так.

З.Ы. Дальнейшее обсуждение имеет смысл перенести в соседнюю ветку, т.к. тут обсуждается пример.

По содержанию документа есть замечания и пожелания по дальнейшему развитию:
- источник требований не один Gevorg, но и обсуждения и результаты с форума,

Да, можно поправить. Тем более это же черновой вариант.

- в документ попали только первоначальные формулировки требований, а дополнительное требование относительно
-- учёта состояния карт (от Greesh-ы) и
-- хамовитые "разъяснения" от ТОПа относительно учёта номеров бракованных карточек в упаковке (от меня)
 в документе (или приложении) не отражены.

Да, я просто зафиксировал исходные данные, остально решил пока не трогать. Но можно и добавить, правда это так много!

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

Моя ошибка, сложно понять почему самрт-карты а не скрэтч.

Нужны следующие ближайшие доработки документа:
исправить глоссарий:
- заменить описание смарт-карты на описание скрэтч-карты от Greesh-ы (2 варианта скрэтч-карт)

Заменю

- добавить описание скрэтч-кода.

Добавлю

- добавить результаты обсуждения требований хотя бы в виде вопрос-ответ.

попробую

- добавить варианты ПЕРЕформулировок, предложенных Вами.

Я что-то переформулировал? Поправлю

сорри, что перегружаю эту работу на Вас, я ещё неделю буду очень стеснён временем.

С Вас арманьяк

К сожалению, я сам не успел, а мои студенты так и не смогли открыть Раквестный файл с Вашими результатами, но это направление меня живо интересует, я обязательно хочу "руками посмотреть" возможности связки Раквест+ЭА.

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


Ссылка для просмотра файлов проекта (RaQuest и MS Word). Участники проекта думаю могут вносить все нужные изменения.

В RaQuest я создал новую команду и троих участников Galogen, Gevorg, Greesha. Все требования внесены от лица Galogen, кроме 16, которое внесено от лица Greesha, т.е. автора.

В каких Вы книжках это прочитали?? И как это вас спасало?

дак речь у нас не о книжках, а о "поделиться опытом" и получить критику от форумчан, в том числе и в плане есть\нет в книжках, может я велосипед изобрёл :-)

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

thnx лично Вам, как модератору и всем участникам за поддержание высокой культуры общения на форуме.
такой подход обещает дать серъёзные результаты.

к примеру, - наша текущая ситуация:

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

а проблема, ЫМХО, в том, что теория требований
до сих пор отстаёт и не выдерживает проверки практикой.
Стоит только начать попытки её применять - как обнаруживаюся дыры,
при попытке самостоятельно залатать которые сильно рискуешь попасть на подозрение в ереси и неуважении мировых Гуру.

Чего мне стоило вытянуть признание Galogen-а:
"Коберн к сожалению относится к картинкам халатно - потому у него стрелочки теряют свою информативность"
http://www.uml2.ru/forum/index.php?topic=194.0

Чего стоят дебаты на форуме в русле "так является ли ВИ требованием по-сути?"...
Один почтенный мэтр однозначно называет ВИ требованием,
другой, не менее почтенный, указывает такие атрибуты у Требования_в_общем_виде, которых и в помине нет у ЮзКейса.
А уважаемые форумчане пытаются согласовать эти пазлы в цельную картину.
Я туда же, а мне: "где в книжке написано?" :-)
Не написано, свой дополнительный кусочек для пазлов  вырезал, :-)
чтоб согласовать написанное в разных книжках и
чтобы в своих задачах ВСЁ ВМЕСТЕ можно было СОГЛАСОВАНО на практике применять.

Но это уже явно отклонение от текущей темы.
Здесь бы справиться с намного меньшей задачей: толком изложить свой частный опыт.

Может, заведём отдельную тему:
"Известные разногласия и рассогласования мировых учений о требованиях"?

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

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

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

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

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

Да, прошу прекратить разговоры,  неотносящиеся к управлению требованиями.

Заводите новую тему типа "Стандартизация: нужна или нет?"

уфф, появилась маленькая передышка на работе.
попробовал "на зуб" РаКвэст и его связку с ЭА, вот первые впечатления.

По ЭА.

1. Странно, создаю в ЭА требование и класс, который его реализует, создаю связь.
Открываю свойства класса,  в закладке Links вижу связь с требованием.
Открываю свойства требования - закладки Links нет вААще.

2. А где же полноценные диаграммы коммуникации в ЭА?
Сиквенс-есть, а коммуникации - нету, а тем более автоматического преобразования их друг в друга.
Что это? Я чего-то не нахожу, или у меня старая версия ЭА? (v7.08)

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

4. Ещё про сценарии. Очень хочется выделить сценарии ЮзКейса отдельными элементами диаграммы,
чтобы ссылаться на них трассировочными связями от требований или других элементов диаграмм.
Например, чтобы можно было наглядно показать, что подключение отдельной дополнительной
компоненты необходимо для реализации только одного альтернативного сценария (или нескольких, но из разных ВИ).
Пока не вижу в ЭА стандартных средств для этого.
И уж совсем очевидная потребность:
связать определённый сценарий ВИ хотя бы с соответствующей Сиквенс-диаграммой, раз уж нет полноценных диаграмм коммуникации.


5. Вот, хотелось чтобы требование типа
"Система должна обеспечивать до 3тыс позиций у одной товарной накладной"
Можно было явно притрассировать к мощности связи на диаграмме классов, ан-нет, -
трассировать требование можно только к "квадратику или овальчику".
Даже просто на связь сослаться трассировкой ниЗЗя, хотя требований типа
"Интерфейс Z между компонентами А и Б должен удовлетворять требованиям стандарта Х" - море.
В Визио - там есть возможность создать на линии "точку привязки"
и цеплять к ней конец другой стрелочки, неужели Архитект не даёт подобных возможностей?.


6. Требования, ишью и реквесты в ЭА нарисованы одинаковой фигурой
- наталкивает на мысль, что между ними должно быть много общего.
Не случайно, наверное, многие изобретательные разработчики приспосабливают баг-трекеры к управлению требованиями.
В СтарТиме - так там баг трекер прямо так и оперирует не с БАГом, а с чейндж-реквестом.


По РаКвесту.

1. Нет Ишьёв и чейндж-ревестОв.
Если в ЭА велось обсуждение проблемы, или было заказано изменение требования в чейндж-реквесте,
то всего этого не увидишь в РаКвесте.

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

3. Сильно раздражает отсутсвие  прав на редактирование диаграмм зависимости требований.
Не гарантирую чистоту эксперимента, но у меня получалась такая досадная ситуация:
Открываю диаграмму зависимости требований в РаКвесте - автоматически сгененрированная картинка не нравится.
Открываю ЭА, нахожу соответствующую диаграмму, правлю расположение, сохраняю.
Открываю эту же картинку снова в РаКвесте - он снова её переделывает на свой автоматический манер.
Снова иду в ЭА, смотрю картинку там, надеюсь увидеть свой сохранённый вариант размещения алементов,
 но оказывается, РаКвест и её "подправил".

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

Gevorg, рад что Вы снова с нами
Вообще у нас главный специалисто по ЕА - Irr, подождем ее ответов. Где-то у нас ведется тема типа FAQ, советую повторить пост там, и подождать, что скажет наш ЕА гуру.
Тем не менее беру на себя смелость прокомментировать

1. Странно, создаю в ЭА требование и класс, который его реализует, создаю связь.
Открываю свойства класса,  в закладке Links вижу связь с требованием.
Открываю свойства требования - закладки Links нет вААще.

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

2. А где же полноценные диаграммы коммуникации в ЭА?
Сиквенс-есть, а коммуникации - нету, а тем более автоматического преобразования их друг в друга.
Что это? Я чего-то не нахожу, или у меня старая версия ЭА? (v7.08)

Ну не знаю, диаграмма communication есть. Другое дело, что автопреобразование как в розе, к сожалению нет. Почему - вопрос к ЕА. Однако чтобы задать этот вопрос, нужно быть владельцем.
Предлагаю скинуться и купить на мое имя академическую лицензию (требуется доказательство) Тогда я от вашего имени могу задавать вопросы ЕА.

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

Наверное никакого. Скорее всего просто такова метамодель в ЕА.

4. Ещё про сценарии. Очень хочется выделить сценарии ЮзКейса отдельными элементами диаграммы,
чтобы ссылаться на них трассировочными связями от требований или других элементов диаграмм.
Например, чтобы можно было наглядно показать, что подключение отдельной дополнительной
компоненты необходимо для реализации только одного альтернативного сценария (или нескольких, но из разных ВИ).
Пока не вижу в ЭА стандартных средств для этого.
И уж совсем очевидная потребность:
связать определённый сценарий ВИ хотя бы с соответствующей Сиквенс-диаграммой, раз уж нет полноценных диаграмм коммуникации.

Да такого явно нет, однако можно использовать обновляемые нотации (может это поможет как-то: http://www.uml2.ru/index.php?option=com_content&task=view&id=119&Itemid=48)

5. Вот, хотелось чтобы требование типа
"Система должна обеспечивать до 3тыс позиций у одной товарной накладной"
Можно было явно притрассировать к мощности связи на диаграмме классов, ан-нет, -
трассировать требование можно только к "квадратику или овальчику".
Даже просто на связь сослаться трассировкой ниЗЗя, хотя требований типа
"Интерфейс Z между компонентами А и Б должен удовлетворять требованиям стандарта Х" - море.
В Визио - там есть возможность создать на линии "точку привязки"
и цеплять к ней конец другой стрелочки, неужели Архитект не даёт подобных возможностей?.

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

6. Требования, ишью и реквесты в ЭА нарисованы одинаковой фигурой
- наталкивает на мысль, что между ними должно быть много общего.
Не случайно, наверное, многие изобретательные разработчики приспосабливают баг-трекеры к управлению требованиями.
В СтарТиме - так там баг трекер прямо так и оперирует не с БАГом, а с чейндж-реквестом.

ачто такое реквесты? Я что-то не нашел такого элемента. Вы имели в виду feature? Или change?

По РаКвесту.

1. Нет Ишьёв и чейндж-ревестОв.
Если в ЭА велось обсуждение проблемы, или было заказано изменение требования в чейндж-реквесте,
то всего этого не увидишь в РаКвесте.

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

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

аналогично

3. Сильно раздражает отсутсвие  прав на редактирование диаграмм зависимости требований.
Не гарантирую чистоту эксперимента, но у меня получалась такая досадная ситуация:
Открываю диаграмму зависимости требований в РаКвесте - автоматически сгененрированная картинка не нравится.
Открываю ЭА, нахожу соответствующую диаграмму, правлю расположение, сохраняю.
Открываю эту же картинку снова в РаКвесте - он снова её переделывает на свой автоматический манер.
Снова иду в ЭА, смотрю картинку там, надеюсь увидеть свой сохранённый вариант размещения алементов,
 но оказывается, РаКвест и её "подправил".

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

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

Опять же пример - и формулировка вопроса. Отправлю разрабочикам и буду ждать ответа

Ну не знаю, диаграмма communication есть. Другое дело, что автопреобразование как в розе, к сожалению нет.
 Почему - вопрос к ЕА. Однако чтобы задать этот вопрос, нужно быть владельцем.

да я сам видел возможность создать диаграммы с таким названием,
только попробуйте в ней мессиджи прикрепить к коммуникативным ассоциациям.... :-)
я не нашёл, поэтому и выразился в порыве возмущения, что нет диаграмм коммуникации.
Irr, что, действительно всё так печально в ЭА, или я чего-то не замечаю?

Строите модель объектов в communication.
Далее проводите ассоциации.
ПКМ по ассоциации выбираем добавит собщение от ... к
вносите сообщение, либо создаете операцию

Как использоватьто что уже сделано в sequence точно не знаю, искал долго.

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

Осуществляя бешенный поиск в справке и в интернете, обнаружил на форуме самого EA презабавное сообщение.
Оказывается есть некий аддонс, позволяющий конвертировать communication в sequence, но кажется не наоброт. При этом какие-то траблы при работе в 7 версии, типа в 6.5 усе корректно. Однако все равно есть проблемы с синхронизацией.

Интересно на что же рассчитывает ЕА? Или это такой коммерческий ход. Насколько я понял аддонсы многие становятся доступны после покупки струмента

два вопроса:
1. Триал-период в раквесте закончился, как работать дальше?
2. Куда и как выкладывать свои правки в раквестном файле, который я открываю и всю работу по-сути делаю в ЭА?

Свяжитесь со мной лично. Я дам Вам некоторые цу.

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

Почитал дискуссию. Некоторые соображения.
По тому считать или нет ВИ требованиями. Зависит от той модели которую вы для себя приняли и как интерпретируете ВИ и даже то, как вы их пишите. Лично мне не очень понятно для чего нужно дополнительное ТРЕБОВАНИЕ: "Реализовать UC12", хотя прошу заметить, что это ВОВСЕ не требование (по определению требований), а чистой воды TASK, который как правило уже относиться к заданию на проектирование или реализацию и по сути это уже отнсится к конфигуправлению.

Лично мне не очень понятно для чего нужно дополнительное ТРЕБОВАНИЕ: "Реализовать UC12", хотя прошу заметить, что это ВОВСЕ не требование (по определению требований), а чистой воды TASK,

сорри за неточность:
Название: UC12 ДОЛЖЕН быть реализован(или НЕ реализован в данном проекте).
Покрываемая бизнес-потребность: BR007
Источник требования: должностная инструкция менеджеру А отдела Х.
и т.д.
Насколько я знаю, традиционные шаблоны такие атрибуты в ЮзКейс не включают.