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

Вот мне стало интересно, а что вы подразумеваете под "Средством для управления требованиями" ?

Чем вас не устраивают неоднократно упоминавшиеся здесь:
1) Jira
2) FlySpray
3) BugZilla
4) Mantis
5) trac
6) FogBugz

все под web. Jira и FogBugz - коммерческие. Остальные Open-Source.

Borland Caliber RM

Пользовалась:

Borland CaliberRM
Rational RequisitPro

обе стоят ОЧЕНЬ хороших денег.

Рекомендовали:

Telelogic DOORS
(по цене аналогично)
Sparx Raquest
(стоит присмотреться)

Кстати, поиском по форуму воспользоваться религия не позволяет?...
Тема поднималась неоднократно.


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

Это сообщение отредактировал(а) ida - 18.12.2007, 14:05

Это действительно баг-трекеры. 

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

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

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

Средство управления требованиями - это ПО, которое выполняет обычно следующие основные функции:

1. хранение требований к ПО в виде информационных единиц БД, которые обладают уникальным идентификатором и набором атрибутов (в числе которых - текстовое описание, состояние, источник, дата, версия и т.п.)
2. предоставление доступа к требованиям участникам рабочей группы


Это сообщение отредактировал(а) ida - 28.12.2007, 09:32

А вы сами пробовали?

Обе эти функции доступны в подавляющем большинстве багтрекеров. Тот FlySpray всё это делает, бесплатен и лёгок в настройке. Неудобен в применении, но это уже другой вопрос.

Не пробовала, т.к. у меня всегда были под рукой средства управления требованиями. 
Кстати, упомянутый мною Sparx если не ошибаюсь тоже денег не стоит.


Это сообщение отредактировал(а) ida - 28.12.2007, 14:58

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

К списку перечисленных багтрекеров хочу добавить TrackStudio: http://www.trackstudio.com/
Разрабатывается в России, как следствие - и хорошая локализация, и саппорт на русском языке. 
Коммерческая, но при сопоставимой (а местами и лучшей) функциональности стоит значительно дешевле, чем Jira и FogBugz
Недавно рассматривали существующие системы (Jira, FogBugz, trac, bugzilla (в 3-ей версии появились вкусности)), в итоге выбрали именно TrackStudio.

Это сообщение отредактировал(а) mindflyer - 28.12.2007, 19:24

Подобная функциональность действительно существует и в баг-трекерах. 

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

Bose, mindflyer, мне действительно интересен один вопрос.

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

И наверное когда к вам приходят со словами: "у меня глючит винда, что мне делать?" вы всегда отвечаете: "поставь Линукс"?

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

Это сообщение отредактировал(а) ida - 29.12.2007, 09:55

 Просто те функции, которые ты озвучила как основные, хорошо реализованы и в баг-трекерах.


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

1. Поддержку иерархии требований
2. Поддержку трассировки требований
3. Ведение истории изменений требований
4. Возможность установки атрибутов требованиям
5. Возможность настройки жизненного цикла требования
6. Интеграцию с текстовым редактором

Эммм... а что означают вот эти два пункта? Можно с примерами?

mindflyer, можно конечно. Только зачем?...

Ну, например затем, что люди на форуме ещё и делятся знаниями, а не только выведывают коммерческие тайны.
Кроме того, ответ был дан немного ранее:

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

mindflyer, а вы что, аналитик?
Если нет - то вам конкретно такая система ни к чему.
Поясните задачу.

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

В данный момент ни к чему. Но в ближайшем будущем, возможно, понадобится.


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

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

- А это правда, что в Одессе всегда отвечают вопросом на вопрос?
- А зачем Вам это знать?


+1.

mindflyer, речь идет о том, что с помощью баг-трекера нельзя (насколько мне известно) создать отношения между issues примерно следующего характера:

Требование 1: Windows based user interface
Требование 1.1: Окно логина
Требование 1.2: Основное окно
Требование 1.2.1: Панель задач
Требование 1.2.2: Панель быстрого ввода

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

Добавлено через 1 минуту и 54 секунды

вот тут, если я правильно понимаю, речь идет о "прослеживаемости", т.е. возможности увидеть, в какой именно итерации/задаче требование реализуется.

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

А теперь по теме.

Инструментальные средства управления требованиями оправдывают себя в тех случаях, когда имеет место распределенная команда и большой объем работ. Т.е. я например считаю, что до 20-30 требований вам будет проще написать на листке бумаги и работать с этим листком - намного эффективнее, чем с ПО. Хотя опять же вопрос, до какой степени детализировать. Например, у меня проект на полгода начинается с 4-6 бизнес-требований. Дальше могу их размазать до 2-3 десятков функциональных. Это много или мало для вас? Все зависит от того, кто ставит задачу. Если вы хотите каждое поле в экранной форме заводить отдельным требованием, то объем вырастет на порядок. К чему я: имеет значение не только инструмент, но и кто с ним работает. Поэтому я спросила, вы аналитик или нет? Если человек не подготовлен для работы именно с требованиями (не проектирование, не написание кода, не запаривание клиентов - это довольно специфическая область, в которой, как и везде, для удовлетворительных результатов нужен опыт), то ПО его не спасет - он все равно запутается и все угробит. Поэтому совет: приобретайте навык или нанимайте человека, который умеет с ними работать. Тогда можете использовать любое ПО. Набор функций у них приблизительно один и тот же.

Это сообщение отредактировал(а) ida - 7.1.2008, 20:01

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

ida, спасибо за объяснения.


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

По мне, требования, задачи, баги должны трэкаться в одной системе. Например, http://www.targetprocess.com (не реклама). 

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

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

Это сообщение отредактировал(а) ida - 8.1.2008, 18:45

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


См.выше.

Меня кроме собственно софта интересовал процесс управления требованиями: что под этим вообще подразумевается.
В результате купил книжку Алистера Коберна Современные методы описания функциональных требований к системам. Может быть она добавит понимания сути процесса.

sandello, неа, не добавит.

По управлению требованиями есть несколько хороших глав в книге К.Вигерса "Разработка требований к программному обеспечению".

Книга А.Коберна о другом.

Мне освоить азы управления требованиями помогла книга "Разработка и управление требованиями (Элизабет Халл)"

мда.. Требования и Отчеты есть разные по определению..
И уж если требования потом переходят в ТЗ то отчеты об ошибках - только в историю.. )