Хотел бы задать вопрос общественности форума, особенно той ее части, которая реально работает с требованиями на практике и имеет насущную потребность в управлении ими.
Я реально работаю с требованиями, и в нашей полсотне проектов есть роль "Аналитик", которую делят примерно поровну два человека. При этом значение слов "Требования" и "Аналитик" понимаю, пожалуй, только я, причём не факт, что правильно.
На самом деле, "управление требованиями" у нас в зачаточном состоянии, хотя раздел "Требования" в нашем внутреннем трекере задач существует уже года два. Ситуация такая: специального образования аналитика ни у кого нет, я пытаюсь быть локомотивом внедрения более-менее внятных подходов к разработке. Собственно, это в моих интересах и входит в мои обязанности.
Каким образом Вы управляете требованиями?
Обычно требования содержатся в разрозненных документах или в электронной почте. При начале нового проекта или очередной итерации на изменение приложений мы сводим требования в список и отправляем его заказчику на утверждение. Заказчиков у нас много, и способ взаимодействия с каждым из них свой. В общем, "идеальный" подход к сбору требований - встречи с участием как можно большего количества заинтересованных лиц - мы только-только начали применять, и не со всеми заказчиками находим взаимопонимание.
Вычленение требований, их формализация и классификация (в текстовой форме) - это задача наших аналитиков. Они же добавляют требования в трекер либо в виде отдельных записей, либо в виде готовых документов (когда нет смысла разбивать документ на части).
Использование трекера пока не является обязательным, но "настоятельно рекомендуется". Постепенно все привыкают к тому, что это удобно.
Что Вы понимаете под управлением требованиями?
Учёт и отслеживание выполняемости. Это если в двух словах.
Какие системы управления требованиями Вы пользуетесь и как?
Собственная разработка - учёт требований объединён с учётом проектов, запросов (багов), тестов и текущих задач. Полной интеграции с разработкой и тестированием пока нет. Каждый раз, когда нужно использовать требования (разработать план тестирования, план работ, собрать документ для обсуждения с заказчиками и т. п.), это нужно делать "вручную". То есть открывать трекер, выбирать проект и читать все требования подряд.
Самые очевидные недостатки, которые будем исправлять в ближайшее время:
- отсутствует автоматическая трассировка требований на тесты и релизы - требования хранятся "сами по себе", без связи с другими объектами учёта;
- при изменении требований не сохраняются старые версии.
Как обеспечивается управление требованиями в стиле прецедентов и стиле списков свойств системы?
Никак не обеспечивается, и необходимость в этом пока не обнаруживалась.
Какой подход в формулировке требований Вы обычно используете: водопадный или итерационный?
Даже слов таких не знаю.
То есть слова знаю, но применительно к разработке программ, а не формулировке требований.
Какое место занимает в Вашем случае моделирование?
Последнее. Максимум, что иногда используем - подобие диаграммы развёртывания при объяснениях с заказчиком. Иногда, в сложных для понимания вопросах, используем диаграммы состояний "на салфетках", которые после обсуждения выбрасываются.
Чаще всего используются старые добрые блок-схемы алгоритмов, в том числе в тех ситуациях, где вроде бы самое подходящее место для вариантов использования.
Используете ли Вы для проверки и анализа требований имитационное или математическое моделирование?
Нет.
Какие требования к системе управления требованиями Вы лично предъявляете?
В двух словах не выразить, а на подробное изложение сейчас нет времени.