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

Что хотелось бы узнать:

Каким образом Вы управляете требованиями?

Что Вы понимаете под управлением требованиями?

Какие системы управления требованиями Вы пользуетесь и как?

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

Какой подход в формулировке требований Вы обычно используете: водопадный или итерационный?

Какое место занимает в Вашем случае моделирование?

Используете ли Вы для проверки и анализа требований имитационное или математическое моделирование?

Какие требования к системе управления требованиями Вы лично предъявляете?

Вот некоторые ссылки для затравки:
Обсуждение на форуме sql.ru
Статья "Управление требованиями и автоматизация этого процесса"
Новые приемы управления требованиями с помощью Rational RequisitePro: Часть 1. Использование архитектурных методов

>> Что Вы понимаете под управлением требованиями?
>> Какие требования к системе управления требованиями Вы лично предъявляете?
1. Удобство ввода и учета требований
2. Присвоение атрибутов для требований
3. Трассировка требований между собой
4. Трасировка требований к задачам и наоборот
5. Трасировка требований к элемнтам модели и инаоборот
6. Шаблоны требований, документов, и т.д.
7. Генерация актуальных документов на основе репозитария требований

>> Каким образом Вы управляете требованиями?
>> Какие системы управления требованиями Вы пользуетесь и как?
Сейчас пытаемся внедрить Вики для УТ

>> Как обеспечивается управление ребованиями в стиле прецедентов и стиле списков свойств системы?
И так и так

>> Какой подход в формулировке требований Вы обычно используете: водопадный или итерационный?
Скорее водопадный, но с возможностью дальнейшего уточнения

>> Какое место занимает в Вашем случае моделирование?
ДВИ, ДС, Архитектура

>> Используете ли Вы для проверки и анализа требований имитационное или математическое моделирование?
нет

Саша, спасибо за ответ. Однако если это не коммерческая тайна, хотелось бы по подробнее узнать о самой организации этого процесса., проблемах с которыми вы сталкиваетесь, с трудностями и конкретикой.
Например. Для сбора функциональных требований вы используете прецеденты. Как это делается, что первично, что вторично? Как это фиксируется, отслеживается, изменяется? Как их этого получаются нужные документы? Какие документы?
Фиксируете ли вы в репозитории видение и дополнительные требования, или фиксируете только спецификацию требований к ПО, а видение, прецеденты и т.п. являются первоисточниками?

Мы учитываем все: и видение и непосредственные требования. Есть иерархия требований, где учитываются цели, проблемы, БТр (БВИ), СВИ, функц. и нефункц. требования.
Основные проблемы:
1. Трудно поддерживать трассировку
2. Трудно назначать атрибуты для требований
3. Нельзя трасировать требования к эл. моделям

Мы учитываем все: и видение и непосредственные требования. Есть иерархия требований, где учитываются цели, проблемы, БТр (БВИ), СВИ, функц. и нефункц. требования.
Основные проблемы:
1. Трудно поддерживать трассировку
2. Трудно назначать атрибуты для требований
3. Нельзя трасировать требования к эл. моделям

А-ха. Трудности есть! Тот случай, который требует консилиума и выбора метода лечения.

1. В чем трудность поддержания трасировки? Трассировка между чем и чем, пожалуйста, поэлементно. Предлагаю взять за основу небольшой пример (кейс я предоставлю без проблем) и разыграть деловую игру. Понимаю не так много времени, но нас не должна тревожить точность требований, полнота их описания, а сам процесс!!!

2. Что значит трудно назначать атрибуты? В чем сложность?

3. Где нельзя трассировать требования к элементам моделей?

1. Трассировка между требрваниями, т.е. ФТр1 следует из БТр1
2. Ну Тр могут иметь атрибуты (статус, сложность, приоритет и т.д.), так вот чтобы назначить эти атрибуты в Вики для требования (страница в Вики) нужно извратиться, причем отчет получить по требованиям (например сколько требований потвержденно) невозможно
3. В Вики нельзя, я сейчас говорю о ней. Хотя это тоже решается с помощью генеарции html страниц из модели (Rose, EA, Pasedon, ...) и вставки прямых ссылок на эти странички.

Саша, тема, как мне думается , очень интересна многим.

Поскольку тут много профессионалов, но еще больше непрофессионалов и людей, возможно пытающихся ими стать, есть смысл обсудить это в деталях. Когда читаешь многие книги : Вигерса, Лиффенгуэлла или др. - много можно подчерпнуть, но не то как же это осуществялется на практике, от А до Я.

Ты пишешь - функциональные требования трассируются к бизнес-требованиям ибо их реализуют. А к чему трассируются бизнес-требования? Как эти требования получаются? Просто формируется список, на основании анализа первичных документов  (интервью, тех.документация, наблюдение etc)? Либо бизнес-требования формируются в ходе бизнес-моделирования?

Что значит формирование функциональных требования на основе бизнес-требований? В каком виде формируются функциональные требования? Если функциональные требования в основном фиксируются в виде прецедентов - как организовано у вас документирование и моделирование? Прецеденты являются лишь основанием для формирования списка требований или сами позиционируются как требования?

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

Я реально работаю с требованиями, и в нашей полсотне проектов есть роль "Аналитик", которую делят примерно поровну два человека. При этом значение слов "Требования" и "Аналитик" понимаю, пожалуй, только я, причём не факт, что правильно.

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

Каким образом Вы управляете требованиями?

Обычно требования содержатся в разрозненных документах или в электронной почте. При начале нового проекта или очередной итерации на изменение приложений мы сводим требования в список и отправляем его заказчику на утверждение. Заказчиков у нас много, и способ взаимодействия с каждым из них свой. В общем, "идеальный" подход к сбору требований - встречи с участием как можно большего количества заинтересованных лиц - мы только-только начали применять, и не со всеми заказчиками находим взаимопонимание.

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

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

Что Вы понимаете под управлением требованиями?

Учёт и отслеживание выполняемости. Это если в двух словах.

Какие системы управления требованиями Вы пользуетесь и как?

Собственная разработка - учёт требований объединён с учётом проектов, запросов (багов), тестов и текущих задач. Полной интеграции с разработкой и тестированием пока нет. Каждый раз, когда нужно использовать требования (разработать план тестирования, план работ, собрать документ для обсуждения с заказчиками и т. п.), это нужно делать "вручную". То есть открывать трекер, выбирать проект и читать все требования подряд.

Самые очевидные недостатки, которые будем исправлять в ближайшее время:
- отсутствует автоматическая трассировка требований на тесты и релизы - требования хранятся "сами по себе", без связи с другими объектами учёта;
- при изменении требований не сохраняются старые версии.

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

Никак не обеспечивается, и необходимость в этом пока не обнаруживалась.

Какой подход в формулировке требований Вы обычно используете: водопадный или итерационный?

Даже слов таких не знаю. То есть слова знаю, но применительно к разработке программ, а не формулировке требований.

Какое место занимает в Вашем случае моделирование?

Последнее. Максимум, что иногда используем - подобие диаграммы развёртывания при объяснениях с заказчиком. Иногда, в сложных для понимания вопросах, используем диаграммы состояний "на салфетках", которые после обсуждения выбрасываются.

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

Используете ли Вы для проверки и анализа требований имитационное или математическое моделирование?

Нет.

Какие требования к системе управления требованиями Вы лично предъявляете?

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

Спасибо за развернутый ответ и подробные комментарии.

Собственная разработка - учёт требований объединён с учётом проектов, запросов (багов), тестов и текущих задач. Полной интеграции с разработкой и тестированием пока нет. Каждый раз, когда нужно использовать требования (разработать план тестирования, план работ, собрать документ для обсуждения с заказчиками и т. п.), это нужно делать "вручную". То есть открывать трекер, выбирать проект и читать все требования подряд.

Нечто подобное используется на моей второй работе. Система называется "управление поручениями". По сути очень похоже на Вашу.

Никак не обеспечивается, и необходимость в этом пока не обнаруживалась.

А  в чем нет необходимости

в ведении требований по прецедентам? (тут я понял Вы прецеденты используете мало или вообще не используете. Это может быть вполне обусловлено решаемыми задачами. По крайней мере Лифеннгуэлл пишет об этом достаточно подробно).

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

Даже слов таких не знаю. То есть слова знаю, но применительно к разработке программ, а не формулировке требований.

Тут имелось в виду сам способ разработки. сначал требования кровь из носу, потом проект и реализация. Либо все в перемежку по спирале?

Последнее. Максимум, что иногда используем - подобие диаграммы развёртывания при объяснениях с заказчиком. Иногда, в сложных для понимания вопросах, используем диаграммы состояний "на салфетках", которые после обсуждения выбрасываются.

Ну нормальной гибкий подход А если решение удачное, репозиторий не ведёте?

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

А например?

А  в чем нет необходимости

в ведении требований по прецедентам? (тут я понял Вы прецеденты используете мало или вообще не используете. Это может быть вполне обусловлено решаемыми задачами. По крайней мере Лифеннгуэлл пишет об этом достаточно подробно).

Вот только не надо меня своей бандой пугать.

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

Тут имелось в виду сам способ разработки. сначал требования кровь из носу, потом проект и реализация. Либо все в перемежку по спирале?

Наша ситуация примерно описана вот здесь:
http://www.uml2.ru/forum/index.php?topic=219.msg4016#msg4016

С августа не очень много изменилось, но какие-то подвижки, конечно, есть.

Ну нормальной гибкий подход А если решение удачное, репозиторий не ведёте?

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

А например?

Порылся в документах, не нашёл.

Зато нашёл вот такую диаграмму в концептуальном документе. Просто для иллюстрации. Интересно, если использовать только UML, какая диаграмма здесь должна быть и как она выглядела бы?

Вот только не надо меня своей бандой пугать.

Да Лиффенгуэлл вроде не из банды. Он вроде сам по себе, хотя и о том же...

прецеденты (не люблю я это слово)

Мне тоже не совсем нравится. Просто слово компактнее варианта использования

Зато нашёл вот такую диаграмму в концептуальном документе. Просто для иллюстрации. Интересно, если использовать только UML, какая диаграмма здесь должна быть и как она выглядела бы?
[skip] тут диаграмма смотри в предыдущем посте [/skip]

Диаграмму такую сделать наверное возможно. Она как я понял отражает некий объектный поток наложенный на красивую картинку размещения. В принципе такие картинки UML-CASE позволяют сделать например с использованием activity diagram или communication diagram

Гриша,

Просто надо всех заставить говорить только на ЮМЛ, тогда и будут все картинки в ЮМЛ, а не художественные изыски (это к теме про безмолвное моделирование)

Просто надо всех заставить говорить только на ЮМЛ, тогда и будут все картинки в ЮМЛ, а не художественные изыски (это к теме про безмолвное моделирование)

А зачем? По этой картинке ни у одного из клиентов не возникало вопросов.

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

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

Мне повезло на прошлой работе в этом смысле:
- Софтовая фирма,
- один постоянный Заказчик,
- основная масса работ - сопровождение унаследованного ПО,
- ПО реально необходимо, активно и широко используется,
- требования на доработки поступают постоянно и в большом количестве,
- сроки их реализации очень жёсткие,
- ситема большая, досталась в наследство от нескольких компаний-разработчиков,
- сотавляющие компоненты разнородные по всем направлениям: среда разработки, культура разработчиков, архитектурные принципы,
- что их объединяет: общий заказчик-потребитель, общая предметная область, общий на данный момент разработчик,
- но сами требования на доработку достаточно простые и маленькие по объёму.

От руководства пришло задание: сконструировать и внедрить автоматизированный процесс управления всем этим зверинцем.
StarTeam и Caliber, как инструменты, были в качестве необсуждаемой данности.

3 месяца укрощения средств и войны с партизанскими инициативами от местных очень активных и не менее дремучих аналитиков дали кучу интересных результатов.
Работа для меня была очень интересная, рассказывать можно много, пока приведу тезисы, в порядке их всплывания в памяти.

1. Опытно проявилась правильность принципа из CMMi: управление требованиями осваивается на ступеньку раньше, чем дизайн требований.
процесс управления требованиями уже был поставлен и даже был принят аналитиками, а до толкового дизайна, тем более - с использованием диаграмм, - было ещё ой как далеко.
Самое кино было в том, что наиболе резвые из аналитиков ухватились за Caliber, как за свой родной инструмент, и давай его активно применять для всего, чего угодно, кроме главного: дизайна требований.
Ладно,управление требованиями, - это родное,
но умудриться притянуть за уши Caliber для менеджмента проектных задач, учёта трудозатрат исполнителей и в качестве системы управления версиями всех артефактов - это уже было слишком.
Ещё раз, "опыт военных действий" подтверждает теорию: менеджмент требований осваивается раньше, чем дизайн оных.

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

3. Трассировка между требованиями - задача менее приоритетная,
чем трассировка от требования - к коду и тест-кейсу, которые это требование закрывают и проверяют,
и к проектным задачам, имеющим какое-то отношение к требованию.

4. Заявленная Борландом совместимость приобретённых продуктов для пресловутой полной поддержки цикла ALM на деле имеет кучу хомутов и граблей.
Нужно крепко исхитриться, чтобы заставить эти средства (в моём случае: StarTeam, Caliber, Delphi, MS-Project) согласованно работать по обеспечению цикла разработки ПО.

5. Если задачу версионного управления и трассировки более-менее удалось решить родными Борландовскими средствами, то задачи отчётности без примочек-доработок оказались практически НЕ решаемыми.
Спрашивал у знающих людей из Питера - они тоже с этим намучились.

6. Те же знающие люди рассказывали легенды про решение аналогичной мощности на базе интеграции СабВершин-Джира-Телелоджик Дорз.
Но доработки по обеспечению этой интеграции обошлись компании в хорошую копеечку.