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

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

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, неа, не добавит.

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

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

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