Форум Сообщества Аналитиков

Дисциплины => Системный Анализ и Требования => Тема начата: Виталий Григораш от 14 Ноября 2009, 02:38:40

Название: Управление требованиями. Атрибуты
Отправлено: Виталий Григораш от 14 Ноября 2009, 02:38:40
Привет. Друзья, те из вас, кто управляет требованиями в проектах расскажите какие атрибуты вы используете и как они помогают вам управлять требованиями?
Я на текущий момент реально использовал только тип, стереотип, фазу, идентификатор, состояние и приоритет (в порядке убывания значимости) в основном для трех целей:
1. Cтруктуризация модели требований
2. Отслеживания состояний готовности
3. Документирования
Интересно узнать в рамках обмена опытом :).
Название: Re: Управление требованиями. Атрибуты
Отправлено: mouse от 14 Ноября 2009, 15:23:36
Фаза, Тип, Название, Инициатор, Риск отмены, Необходимость разработки, Ссылка на разрабатываемую фичу
Название: Re: Управление требованиями. Атрибуты
Отправлено: SALar от 14 Ноября 2009, 19:13:34
Для начала разделите на категории:
* описательные
* управляющие

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

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

Получилось уже порядка 15 атрибутов, о том, как они помогают, я лучше расскажу попозже, когда обкатаем на проектах.
Название: Re: Управление требованиями. Атрибуты
Отправлено: Виталий Григораш от 15 Ноября 2009, 20:31:51
Тип, Состояние, Источник, Приоритет, все назначения (кому реализовывать, кому тестировать, кому проверять).. так из основного вроде все. Название, разумеется :)
Марина, как вы прописываете источник требований? Для каждого требования руками пишите Имя и Фамилию? и используете ли вы какое-либо инструментальное средство для этого?
По поводу назначения - а если человек уволился из команды или взяли нового для всех требований меняете ответственного? Это скорее всего деятельность руководителя проекта

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

Описательные:
* Тип
* Уровень.
Сергей, а вы не связываете эти два понятия? Обычно тип заключает в себе уровень абстракции
Название: Re: Управление требованиями. Атрибуты
Отправлено: SALar от 16 Ноября 2009, 12:50:44
* Чем можно заменить приоритет.
Например, Доброй Феей. Которая прилетела и для каждой фичи указала два параметра: общие трудозатраты и доллары, которые мы получим при реализации. Метод теоретический, на практике возможность его применения о-о-очень сомнительна.
Но есть другие методы. И их не один. Один из них указал Виталий. Есть еще.

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

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

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

PS. Большая часть всего этого есть в записи моего вебинара http://software-testing.ru/events/836-tuning-bugtracker.
Название: Re: Управление требованиями. Атрибуты
Отправлено: SALar от 16 Ноября 2009, 12:55:37
У нас происходило следующим образом: если проект большой и его реализуют в несколько этапов, то все требования сначала распределяются по этапам. На каждом этапе есть высокоприоритетные и низкоприоритетные (предположим). Это однако не означает, что высокоприоритетные будут реализованы в первую очередь. Просто надо понимать, что разработчик, которые не реализовал высокоприоритетные, в случае "разбора полетов" не сможет оправдаться тем, что он потратил месяц на низкоприоритетные. Для этого, собственно говоря, и придуман приоритет.
Это хорошо работает при "упаковке по времени".  Но есть команды, работающие по "упаковке по функциональности". Там атрибут "приоритет" может быть даже вреден. Важнейшим первичным там будет взаимосвязь между требованиями, вторичным - номер релиза.
Есть разные методы организации жизненного цикла. Если вы используете один, то не факт, что он лучший. Даже для вас.
Название: Re: Управление требованиями. Атрибуты
Отправлено: Galogen от 16 Ноября 2009, 13:41:05
Но есть команды, работающие по "упаковке по функциональности". Там атрибут "приоритет" может быть даже вреден. Важнейшим первичным там будет взаимосвязь между требованиями, вторичным - номер релиза.
А разве это не является приоритетом?
Название: Re: Управление требованиями. Атрибуты
Отправлено: Виталий Григораш от 16 Ноября 2009, 13:41:12
Я поняла, что речь и идет об атрибутах, используемых в средстве управления требованиями.

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

Цитировать
Этот атрибут нужен для трассировки (трассируемость - одно из качеств хороших требований, как мы помним).
А как быть с требованиями других уровней абстракций? или у Вас таковых не было? Для них вы источником ставили другое требование? Обычно источник требования (человек или документ) и источник в части прослеживаемости - это разные вещи.
Например, требования я получаю от представителя заказчика и ставлю его источником, но далее я детализирую его, добавляю еще несколько связанных и тд (источник уже я сам). Устанавливаю связь трассировки между требованиями и в данном случае использую атрибут типа "связь".
Как я понял у Вас эти два атрибута были связаны в одно?
Название: Re: Управление требованиями. Атрибуты
Отправлено: SALar от 16 Ноября 2009, 14:24:32
Это потрясающе! вы открыли мне глаза на этот огромный, разнообразный мир!  :o
Значит мне показалось.
Ни в одной фирме, из тех в которых я работал последнее десятилетие не использовалось управление через приоритеты.
Название: Re: Управление требованиями. Атрибуты
Отправлено: exotica от 24 Ноября 2009, 13:47:22
Хочу предложить нашему руководству ввести систему управления требованиями. Сейчас пишу План по управлению требованиями.
Раздел про предлагаемые атрибуты требований я составила максимально подробно (вычеркивать всегда проще, чем добавлять).
Уважаемые господа, оцените/покритикуйте, пожалуйста список атрибутов и возможные значений для них
http://files.wyw.ru/4109309


Название: Re: Управление требованиями. Атрибуты
Отправлено: Виталий Григораш от 24 Ноября 2009, 14:07:36
Хочу предложить нашему руководству ввести систему управления требованиями. Сейчас пишу План по управлению требованиями.
Раздел про предлагаемые атрибуты требований я составила максимально подробно (вычеркивать всегда проще, чем добавлять).
Уважаемые господа, оцените/покритикуйте, пожалуйста список атрибутов и возможные значений для них
http://www.developmentontheedge.com/~exotica/requirements/attributes.xls
Советую идти не от атрибутов, а от понимания того, как вы будете это использовать на практике в вашем проекте, как вы будете управлять требованиями и для чего оно вам нужно? т.е как поможет решить Вашу проблему?
Именно с этого нужно начинать, чтобы доказать руководству, что возврат от вложенных усилий будет положительный.
Я так понимаю, вы ранее требованиями не управляли и сейчас основываетесь более на теоретических знаниях, чем на опыте.
Также учтите, что
1. поддержка большого количества атрибутов занимает много времени
2. часто не обосновано и не исходит от реальных потребностей




Название: Re: Управление требованиями. Атрибуты
Отправлено: exotica от 24 Ноября 2009, 14:30:09
Вы правы, не занималась, точнее занималась неглубоко, так как компания небольшая, поэтому очень неформальный подход к проектной документации и требованиям.
А поскольку дальше хотелось бы развиваться только как аналитик, сейчас набираюсь знаний. Начиталась уже "выше крыши", а применить пока негде (у нас все эти знания не востребованы).
Название: Re: Управление требованиями. Атрибуты
Отправлено: Nikolay от 24 Ноября 2009, 14:53:29
Маленькой компании с плохо поставленными процессами для решения этой задачи лучше всего использовать Excel,имхо. Теоретические знания можно применить в open source проектах или единомышленников среди знакомых/коллег найти и сделать какой-нибудь небольшой полезный проектик/продукт "по науке".
Название: Re: Управление требованиями. Атрибуты
Отправлено: Бабихин Максим от 24 Ноября 2009, 17:55:39
Теоретические знания можно применить в open source проектах или единомышленников среди знакомых/коллег найти и сделать какой-нибудь небольшой полезный проектик/продукт "по науке".

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

2exotica: Из  какого вы города?
Название: Re: Управление требованиями. Атрибуты
Отправлено: oduduka от 25 Ноября 2009, 00:48:19
Вряд ли на маленьком проекте или в маленькой компании от работы "по науке" будет заметный полезный эффект... Эксперимент, конечно, дело благородное, но слова стартап и опенсорс немного не вяжутся со словами ПУТ, атрибуты требований и т.п. Или это стереотип? :)
Название: Re: Управление требованиями. Атрибуты
Отправлено: exotica от 25 Ноября 2009, 06:09:20
2exotica: Из  какого вы города?

Новосибирск
Название: Re: Управление требованиями. Атрибуты
Отправлено: exotica от 25 Ноября 2009, 06:11:06
Вряд ли на маленьком проекте или в маленькой компании от работы "по науке" будет заметный полезный эффект... Эксперимент, конечно, дело благородное, но слова стартап и опенсорс немного не вяжутся со словами ПУТ, атрибуты требований и т.п. Или это стереотип? :)
Да, мне тоже сложно себе это представить. Более реальный вариант, это набраться знаний (опыт в принципе есть, хоть и не глубокий), а потом пойти работать в крупную организацию именно по этому направлению.
Название: Re: Управление требованиями. Атрибуты
Отправлено: Nikolay от 25 Ноября 2009, 09:43:41
Вряд ли на маленьком проекте или в маленькой компании от работы "по науке" будет заметный полезный эффект...
Возможно, но я бы не стал обобщать.

Эксперимент, конечно, дело благородное, но слова стартап и опенсорс немного не вяжутся со словами ПУТ, атрибуты требований и т.п. Или это стереотип? :)
Слово стартап я не упоминал. "Эксперимент" действительно благородное дело, особенно если у него есть четкие цели. На младших курсах института я принимал участие в подобных "экспериментах", в роли разработчика для того, чтобы попрактиковаться в конкретной технологии. Аналитик в команде(3 чел-ка:аналитик+pm,разработчик+тестер,разработчик+тестер) тоже был, правда не из студентов. Цели эксперимента были достигнуты - мы получили опыт разработки, аналитик - протестировал свои методики/подходы. Пользовался ли аналитик средством управления требованиями(СУТ) не знаю, ибо на тот момент меня мало интересовал этот вопрос. При этом не вижу причин, которые могли бы помешать использовать СУТ в проектах такого рода, по крайней мере в ходе проекта можно понять каким образом оптимизировать процесс взаимодействия в команде, оптимизировать метамодель атрибутов требований итп. Конечно возникает вопрос: "А целесообразно ли использовать СУТ в проектах такого рода?". Ну,а если у проекта цель сделать определенное ПО по опреденной методике, почему бы нет?
Название: Re: Управление требованиями. Атрибуты
Отправлено: Виталий Григораш от 25 Ноября 2009, 10:20:15
стартап и опенсорс, "по моему скромному мнению" здесь не причем. Открытый исходник это вообще модель поставки продукта и относится к реализации более (не путать с ситуацией когда много народа кодят удаленно по кускам что-то общее без всяких спек). Есть такие опенсорс проекты, которые требуют не только аналитики но и много чего большего.

Планировать процесс и управление требованиями можно и нужно всегда. Просто вы начали не с того. Атрибуты это один из самых последних моментов в планировании управления требованиями. Начните с заинтересованных лиц, типов требований, попробуйте организовать трассировку (если есть время), сгруппировать требования, понять какие документы вы делаете и какие действительно нужны.
Для того, чтобы донести прогресс до руководства:
1. Выпишите список текущих проблем, которые вы хотите решить в части аналитики
2. Изучите текущий процесс и найдите слабые стороны в работе
3. Подумайте и предложите методы улучшения. Что-то типа плана развития (лучше внедрять их потихоньку и смотреть как они будут жить).
4. С предложениями уже стоит пойти к руководству и говорить, что Вы видите такие-то пути решения проблем, и такой-то предполагаемый эффект

Если руководство не принимает, всегда можно попробовать "снизу".
После того, как вы улучшите слабые места и докажите, что процесс приносить значение, можно развиваться далее и писать уже "мега-гига RMP" и внедрять новые технологии.
Не надо начинать строить дом с крыши.
Название: Re: Управление требованиями. Атрибуты
Отправлено: Григорий Печенкин от 25 Ноября 2009, 11:36:27
Вряд ли на маленьком проекте или в маленькой компании от работы "по науке" будет заметный полезный эффект... Эксперимент, конечно, дело благородное, но слова стартап и опенсорс немного не вяжутся со словами ПУТ, атрибуты требований и т.п. Или это стереотип? :)

Это не стереотип, это проблема. :)

Работа "по науке" сразу предполагает использование бОльшего количества людей и ресурсов. Она обеспечивает, в первую очередь, стабильность и предсказуемость результатов. Стартапы часто не могут себе этого позволить, да многим их них это на начальном этапе и не нужно.

А open source - это вообще другая тема. Насколько я знаю, многие самые известные open source продукты разрабатываются таки "по науке", при поддержке крупных и известных компаний.
Название: Re: Управление требованиями. Атрибуты
Отправлено: exotica от 25 Ноября 2009, 12:50:41
Виталий, большое спасибо за совет!
Название: Re: Управление требованиями. Атрибуты
Отправлено: Nikolay от 25 Ноября 2009, 13:44:39
Стартапы часто не могут себе этого позволить, да многим их них это на начальном этапе и не нужно.
Тему стартапов вообще было бы интересно обсудить, наверное в отдельном топике.