Как ни парадоксально это звучит, но улучшение прослеживаемости требований не приведёт к улучшению качества. - это скажем так, моё утверждение :)
Сама концепция написания АЗ и ТЗ утратила актуальность. Процессы согласования, утверждения и планирования отнимают слишком много бесценного и дорого времени. Мой рецепт не претендует на универсальность, но для моих задач он работал и работает прекрасно. Метод был уже описан западными авторами, но, как мы все понимаем, методология в чистом виде нигде не применяется, а всегда добавляются свои специфические примеси или наоборот, что-то убирается. Данный метод можно назвать "Быстрое прототипирование", предпосылками для такого метода является, то что люди в сотни раз быстрее воспринимают визуальные (графические) концепции, чем текстовые описания, таким образом, если делать быстрые графические прототипы (1-2 дня) и запускать цепочку согласования, то обратную связь можно получить за те же 1-2 дня, далее 1 день на агрегацию и подготовку короткого описания 1-3 страницы, вместо 15 как раньше. После согласования, этап подготовки спецификации для разработчиков (1 день).
Также привествуются создание универсальных моделей прототипов, например, которые описывают некоторые стандартные особенности без привязки в функциональности, таким образом на этапе тестирования и подготовки тест-кейсов/тест-планов по конкретной функциональности учитывают "стандартные" поведенческие особенности, что приводит к общему улучшению качества.
Ещё очень эффективным инструментом лечения всяких болячек в софте является следование практикам ISO 9001 в частности сбор обратной связи с клиентов, проведение советов по качеству, надзор внутри организации за процессами (на сколько качественно они выполняются и т.п.). Это глобальная тема, но при желании можно её осилить.
P.S. Для создания быстрых прототипов можно использовать разный софт, но мне больше все полюбился Balsamiq. Для описания требований есть ещё Rational RequisitePro (
www.caseclub.ru/articles/requisite.html), более глобальный инструмент с моделированием процессов Aris, но я считаю что это уже олдскул и надо решать эти задачи вышеописанным методом.
P.S. Чтобы было понимание всё о чём я писал работало на численности разработчиков от 15 до 120, а то мало ли у Вас там тысячи :)
