DinoПрисоединяюсь к тем, кто рекомендует CaliberRM.
Полгода работал с сабжем, но после того как ознакомился с CaliberRM, тут же перешёл на него. О чём не жалею.

PS: справедливости ради. У Калибра то же есть свои недостатки, но мне он больше нравиться.

Можно поинтересоваться, какие именно недостатки вы отметили?

Dino1. Набор команд Document Factory не богат.
2. Поведение Document Factory иногда бывает не предсказуемо. На большом наборе требований иногда его проглючивает: генерит кучу пустых листов.
3. Проблема с копированием изображений в описание требования. В описании продукта это декларируется, но у меня (и не только) не работает.

Но для меня он всё равно лучше реквизита.

С какой версией CaliberRM вы работаете? О каком количестве требований идет речь ("большой набор")? С изображениями проблем не заметил ... вставлял фотографии в несколько мегабайт. А вообще, можно было бы в частной переписке (мой e-mail есть в профайле) обсудить более детально, что не хватает в Document Factory и вашу практику использования CaliberRM.

Добрый день!
Позволю себе дать некоторые комментарии ...
AlexTheRavenЧастной переписки не надо - давайте говорить открыто, не стесняясь недостатков, ведь идеального софта не бывает.

Возможно не всем по душе обсуждение частного вопроса использования CalierRM ... но раз настаиваете ...
AlexTheRaven А не хватает Borland Document Factory, на мой взгляд, следующего:
1) Нельзя выводить названия требований разного уровня заголовками разного уровня

Во-первых, не для всех такая практика создания документов является приемлемой. В частности, гораздо чаще (в тех организациях которые используют CaliberRM и делятся информации о практике использования) встречается шаблоны для генерации документов, где разделы заранее определены (например те же ТЗ по ГОСТ, с заранее определенным количеством/названиями разделов) и требования размещаются в нутри этих разделов, без необходимости использования разных стилей (с их точки зрения достаточно отступа или нумерации).
Во-вторых, "если нельзя, но очень нужно -- то можно!" (с) ... для этого следует использовать макросы word + 2 раза запускать DocFactory (это легко можно записать в *.bat файл и запускть этот "батник"). Т.е. реализовать это технически -- возможно .
AlexTheRaven
2) Нельзя превращать трассировки в перекрёстные ссылки MS Word

Вопрос, а зачем? И что вы хотите сказать этой ссылкой в электронном документе, какую проблему решить? Ок, предположим, что хотите показать связь м/у требованиями, в печатном виде тоже можно будет воспользоваться этими ссылками??? Трассировка, это элемент управления требованиями, если есть необходимость показать трассировку м/у требованиями в документе, то возможно, стоит для этого использовать перечисление связанных требований, и делать это желательно в одтельном разделе документа.
AlexTheRaven
3) Если какого-то раздела нет - вместо него появляется пустая строка. Удаляется это, конечно, легко, но всё равно муторно...

Не совсем понятен контекст ... можно подробнее?
AlexTheRaven
4) Так медленно генерирует документы, будто бы студентами-гуманитариями писана...

Напишите быстрее :-), для этого все есть -- есть SDK CaliberRM, есть COM-модель Word :-) ... я думаю, что вы сможете неплохо на этом заработать :-).
AlexTheRaven
И вообще, прилагался бы к ней набор шаблонов, согласованных с RUP - мир был бы лучше.

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

AlexTheRaven Таки реализовал... Уже... ГОСТ - это, конечно, хорошо, но и RUP забывать не стоит. А в шаблонах артефактов RUP, например RUP VISION, как раз и предусматривает разные заголовки.

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


Что вы имеете сказать за программирование ... где программирование а где макросы ворд! ... это ж две разницы! :-)

А серьезно -- то лично я переделал в свое время шаблон Vision -- ибо мне было не удобно работать, когда каждая фича имемла стиль Heading ... пухло содержание ... либо в содержание не включать -- либо не использовать стиль Нeading для каждого требования.
Но вот не совсем по теме -- но очень интересный вопрос -- интересно как вы определяете типы требований и мапируете их на разделы RUP Vision, или разделы ТЗ по ГОСТ?

AlexTheRaven
Если какого-то раздела нет - вместо него появляется пустая строка. Удаляется это, конечно, легко, но всё равно муторно...Ну например:
<<hierarchy>>.<<name>>
<<description>> Важность требования: <<Benefit>>

Есть требование самого нижнего уровня. Содержание требования понятно из названия, дополнительного описания не имеет, поле <<description>> - пустое. Но вместо того, чтобы не ставить ничего, Document Factory упрямо вставляет перенос каретки.


По идее пустые значения атрибутов требований -- это все равно что значение NULL в поле таблицы БД (по смыслу) ... если ПОКА не определено это значение по какой-либо причине -- имеет ставить "TBD", а если по смыслу значение отсутствует -- то об этом следует честно в документе и сказать (чтобы не напрягать читателя) -- ставить значение "отсутствует" :-) ...

AlexTheRaven
Для многих электронная форма удобнее бумажной. А перекрёстные ссылки в электронной формк - это удобно.

Удобно -- это ambiguous term, которых как известно стоит избегать в требованиях :-) ... посему я не зря спросил -- что вы хотите сказать такой ссылкой в электронном документе? Физический смысл ссылки какой?

Calm авторчто вы хотите сказать такой ссылкой в электронном документе? Физический смысл ссылки какой?

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

авторгде программирование а где макросы ворд! ... это ж две разницы! :-)
Как ни называйте написание программного кода, суть не меняется.

С уважением.

:-) ... Уважаемы Calm, я вполне адекватно воспринимаю окружающий меня мир и людей его населяющих ... Что такое ссылка -- это общеизвестно, и не вызывает необходимости пояснять ... но я не могу добиться ответа ПОЧЕМУ трэйсы в требованиях должны быть выражены в виде ссылки и ЧТО означает в данном случае эта ссылка (т.е. по сути КАК используется трассировка в конкретном случае, как интерпретируются треэйсы) ... посему и спрашиваю. Может вы сможете адекватно пояснить?

AlexTheRaven
Я могу. Смысл ссылки в документе с требованиями прост. Одно требование связано с другими. Перед тем, как реализовывать первое - нужно обратить внимание на второе, от которого оно зависит (FROM). Щёлкнуть по ссылке, перейти и почитать. И ещё посмотреть, что от этого требования зависит (TO).


Подход не универсален. В частности не учитывается работа с печатными документами, которая встречается не редко. Вы документацию требований не подписываете у заказчика?

AlexTheRaven
Не говорите мне, что я делаю неправильно. Потому что это


"Не спрашивайте, и вам не ответят" :-) (с). (не всопринимайте это серьезно)

AlexTheRaven
а) Работает
б) Удобно для всех, кроме меня. Мне приходится проставлять эти ссылки вручную - шитьё бисером. Удобство совсем не двусмысленный термин; удобство->прирост мотивации->прирост производительности->прирост денег.


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

enter your choice ...

AlexTheRaven
В RUP Vision мапим,
1-е 3 уровня WHAT в 5.Возможности продукта
1-е 3 уровня DSGN в 9. Прочие требования к продукту.
после чего убираем слово "должен"


Все остальные разделы Vision вы заполняете прямо в Ворд?

AlexTheRaven
В RUP SRS мапим все требования, сколько бы уровней ни было.


Какие типы требований на какие разделы? Или часть разделов как в Vision заполняется прямо в шаблоне Word?

AlexTheRaven
Раздел для WHAT зависит от значения пользовательского атрибута "Area", принимающего значения
Functionality
Usability
Reliability
Performance
Supportability

DSGN всегда попадает в Design Constraints.

ГОСТом не пользуемся.

Т.е. вы не выделяете отдельный тип требований как атрибуты качества в инструментальном средстве?

AlexTheRaven Ruby ... обратите внимание на стиль ответов Calm ...
IMHO Calm классно отвечает. По-простому, без словоблудия, иногда жёстко, но по делу.

2 AlexTheRaven: Подождем ответа Calm ... пусть и он выскажет свою точку зрения ... изучим.

2 Ruby: Я посмотрел на ссылку ... value от этих ответов пока не понял, поэтому не могу составить впечатление об уровне знаний этого человека, в частности в области разработки и управления требованиями. Если он действительно специалист в этой области, то будет интересно обсудить с ним вопросы по этой теме. Посмотрю на историю его ответов в целом, может ситуация прояснится.