Привет. Друзья, те из вас, кто управляет требованиями в проектах расскажите какие атрибуты вы используете и как они помогают вам управлять требованиями?
Я на текущий момент реально использовал только тип, стереотип, фазу, идентификатор, состояние и приоритет (в порядке убывания значимости) в основном для трех целей:
1. Cтруктуризация модели требований
2. Отслеживания состояний готовности
3. Документирования
Интересно узнать в рамках обмена опытом .

Фаза, Тип, Название, Инициатор, Риск отмены, Необходимость разработки, Ссылка на разрабатываемую фичу

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

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

Описательные:
* Тип
* Заголовок
* описание (сильно различаются в зависимости от типа)
* бинарный файл (рисунок/ диаграмма/...)
* Уровень. Можно вводить, но честно скажем, что лучше разносить по разным документам и называть по разному. В концепции будут проблемы. В более развернутом документе можно описать потребности. А в SRS (спецификация требований) уже писать требования на уровне юзкейсов или требований с метриками (для нефункциональных).

Сейчас как раз проходим очередной цикл доработки СУТ в части перечня атрибутов в ходе развития процесса УТ и внедрения инструмента УТ.

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

Тип, Состояние, Источник, Приоритет, все назначения (кому реализовывать, кому тестировать, кому проверять).. так из основного вроде все. Название, разумеется

Марина, как вы прописываете источник требований? Для каждого требования руками пишите Имя и Фамилию? и используете ли вы какое-либо инструментальное средство для этого?
По поводу назначения - а если человек уволился из команды или взяли нового для всех требований меняете ответственного? Это скорее всего деятельность руководителя проекта

Да в самом деле, на фига нам приоритет? Давайте все оптом реализуем!

Приоритет вполне можно заменить например фазой, если хорошенько планировать скоуп системы на каждом этапе. Он лишь показывает что важнее, а наиболее важные можно реализовывать на первых фазах. Я стараюсь определять обычно требования на первые 2 фазы (читай приоритеты - высокий и средний) и все остальное просто помечаю как future, чтобы в будущем вернуться к этим требованиям и проработать их детальней. Мое мнение

Описательные:
* Тип
* Уровень.

Сергей, а вы не связываете эти два понятия? Обычно тип заключает в себе уровень абстракции

* Чем можно заменить приоритет.
Например, Доброй Феей. Которая прилетела и для каждой фичи указала два параметра: общие трудозатраты и доллары, которые мы получим при реализации. Метод теоретический, на практике возможность его применения о-о-очень сомнительна.
Но есть другие методы. И их не один. Один из них указал Виталий. Есть еще.

* Тип и уровень.
Под типом в данном случае имелось в виду, какую характеристику качества по ГОСТ покрывает требование.

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

Если брать CMMI, то:
* часть атрибутов соответствует области усовершенствования "Управление требованиями" (2-й уровень)
* другая - "Разработка требований" (3-й уровень)
* третья относится к управлению проектами
И если для каждой конкретной команды набор атрибутов будет включать 3-15 атрибутов, то всего различных атрибутов вполне можно набрать с полсотни. Важен метод адаптации под конкретную задачу.

PS. Большая часть всего этого есть в записи моего вебинара http://software-testing.ru/events/836-tuning-bugtracker.

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

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

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

А разве это не является приоритетом?

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

Источник - это то, откуда у требования "растут ноги". Чаще всего это документ (нормативный или внутренний). Либо конкретный человек, предложивший это требование.

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

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

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

Это потрясающе! вы открыли мне глаза на этот огромный, разнообразный мир!  

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

Хочу предложить нашему руководству ввести систему управления требованиями. Сейчас пишу План по управлению требованиями.
Раздел про предлагаемые атрибуты требований я составила максимально подробно (вычеркивать всегда проще, чем добавлять).
Уважаемые господа, оцените/покритикуйте, пожалуйста список атрибутов и возможные значений для них
http://files.wyw.ru/4109309

Хочу предложить нашему руководству ввести систему управления требованиями. Сейчас пишу План по управлению требованиями.
Раздел про предлагаемые атрибуты требований я составила максимально подробно (вычеркивать всегда проще, чем добавлять).
Уважаемые господа, оцените/покритикуйте, пожалуйста список атрибутов и возможные значений для них
http://www.developmentontheedge.com/~exotica/requirements/attributes.xls

Советую идти не от атрибутов, а от понимания того, как вы будете это использовать на практике в вашем проекте, как вы будете управлять требованиями и для чего оно вам нужно? т.е как поможет решить Вашу проблему?
Именно с этого нужно начинать, чтобы доказать руководству, что возврат от вложенных усилий будет положительный.
Я так понимаю, вы ранее требованиями не управляли и сейчас основываетесь более на теоретических знаниях, чем на опыте.
Также учтите, что
1. поддержка большого количества атрибутов занимает много времени
2. часто не обосновано и не исходит от реальных потребностей

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

Маленькой компании с плохо поставленными процессами для решения этой задачи лучше всего использовать Excel,имхо. Теоретические знания можно применить в open source проектах или единомышленников среди знакомых/коллег найти и сделать какой-нибудь небольшой полезный проектик/продукт "по науке".

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

Готов составить компанию. Ситуация очень похожа. Маленькая компания и подход схожий.

2exotica: Из  какого вы города?