Одна из задач BABOK - "Поддержка требований для повторного использования".
При разборе этой задачи в BABOK Study Group разгорелась горячая дискуссия:

1. Нужно ли тратить дополнительное время и силы для приведения в порядок требований перед их «консервацией», для повторного использования в будущем? И кто это будет делать?
2. Может ли аналитик самостоятельно провести качественную ревизию своих же требований? И кто должен «мотивировать» другого аналитика помогать?
3. Правильно ли, вообще, повторно использовать требования?

И еще:
- Кто может оценить степень важности такой работы?
- Окупится ли потраченное время?
- Кто должен контролировать, чтобы данная работа выполнялась?

Основные умозаключения здесь - http://just-analyze-it.com/?p=103

А какие у вас мысли?

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

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

Правильно Экономит время.

Степень важности может оценить аналитик. Попробуйте написать требования с нуля и пользуясь примером - оцените трудозатраты.

Приведу данные из статьи Управление требованиями к IT-проектам

Разработка большой и сложной системы не может быть завершена за один подход — итерацию. Это может быть связано как с большой сложностью самой системы, так и со сложностью ее адаптации. Тем не менее, возможно уменьшить объем работы для разработчиков за счет повторного использования кода из одного проекта в другом. Для того, чтобы выявить возможность повторного использования кода необходимо найти требования, которые данный код реализуют. Такие требования очень часто встречаются в продуктах, автоматизирующих одну и ту же предметную область на разных организациях, например, бухгалтерский учет или документооборот. Задача повторного использования требований является одной из задач решаемых управлением требований.

Так вот.
Повторное использование равно применение точно таких же технических решений или нет?
В этой же статье говориться что требования должны обладать 10 характеристиками.
Соответственно это все надо оформить. А когда (времени всегда не хватает)?

Если я сам буду эти требования использовать когда-то, то думаю разберусь.
А вот для других это будет сложнее.

И еще, если можно, давайте попробуем на примере какого либо требования.
Кто, например, использовал ранее "законсервированное требование" и как оно звучало?

Мои ответы на вопросы Ichy:
1. Я бы не стала надеяться на то, что консервация возможна и на это будет выделено время. В моей практике просто стараюсь сразу писать требования так, чтоб они были понятны не только мне, и их можно было переиспользовать без дальнейшей доточки. (т.е. все работы по причесыванию лучше делать при рождении требования). Соблюдение при этом кучи правил, например, 10 из указанной статьи, не всегда возможно, иногда я сознательно делаю по-другому (например, далеко не всегда соблюдаю атомарность, если потребителям это будет мешать)
2. Самостоятельно провести ревью своих требований - сложно, у меня это нормально получается через определенный период времени, когда  уже работаю на другом проекте. В этом случае эти требования как чужие, читаю, как в первый раз. Когда есть возможность, с удовольствием даю требования на ревью коллегам. Но в любом случае мои  требования будут читать согласанты - бизнес, разработчики, архитекторы, иногда тестеры. Большую часть ошибок они найдут.
Мотивировать другого аналитика на ревизию требований - имхо - должен начальник аналитиков, который отвечает и стремится к повышению квалификации своих сотрудников и обмену информацией по функциональным областям. (т.е. 2 цели - повысить качество требований и распространить знания в команде)
3. При эволюционном развитии продуктов   - правильно! это позволяет закрыть большие дыры в описании системы там, где есть унаследованный функционал

Согласен с Irr.

Небольшая отсебятина:
* Отдельно, наверное, не надо готовить требования для переиспользования. Если требования написаны согласно Вигерсу и проверены рецензентами/согласователями, то они в принципе уже готовы к переиспользованию. Нужно только, чтобы другой аналитик знал про них. Последнее можно достигнуть: распостронять знания между аналитиками или иметь мегомозг, который знает что и где лежит, чтобы переиспользовать.
* Я, например, всегда переиспользую свои требования на фрилансовых проектах. Это также полезно, если компания делает много однотипных проектов.