Каким образом происходит процесс внесения изменений в требования ?
Как я себе представляю:
есть набор требований, некоторые из них реализованы. После оценки возникает изменение некоторых из реализованных требований. Создаются запросы на изменение, они подписываются сторонами, что дальше ?
Допустим требования ведутся в RequisitePro и требование №379 изменилось, что происходит ?
Просто меняется треобвание №379, и его статус, или создаётся дополнительное требование и требование №379 трассируется в него, или как-то ещё ? Какие ещё действия происходят при этом ?

Здравствуйте, BalTun, Вы писали:

BT>Каким образом происходит процесс внесения изменений в требования ?
BT>Как я себе представляю:
BT>есть набор требований, некоторые из них реализованы. После оценки возникает изменение некоторых из реализованных требований. Создаются запросы на изменение, они подписываются сторонами, что дальше ?
BT>Допустим требования ведутся в RequisitePro и требование №379 изменилось, что происходит ?
BT>Просто меняется треобвание №379, и его статус, или создаётся дополнительное требование и требование №379 трассируется в него, или как-то ещё ? Какие ещё действия происходят при этом ?

Изменяется требование и его статус. После чего autosuspect по traceability автоматом выцепляет требования которые "под подозрением" на то что тоже должны поменяться.

Здравствуйте, Anatolix, Вы писали:

A>Здравствуйте, BalTun, Вы писали:

BT>>Каким образом происходит процесс внесения изменений в требования ?
BT>>Как я себе представляю:
BT>>есть набор требований, некоторые из них реализованы. После оценки возникает изменение некоторых из реализованных требований. Создаются запросы на изменение, они подписываются сторонами, что дальше ?
BT>>Допустим требования ведутся в RequisitePro и требование №379 изменилось, что происходит ?
BT>>Просто меняется треобвание №379, и его статус, или создаётся дополнительное требование и требование №379 трассируется в него, или как-то ещё ? Какие ещё действия происходят при этом ?

A>Изменяется требование и его статус. После чего autosuspect по traceability автоматом выцепляет требования которые "под подозрением" на то что тоже должны поменяться.

Ок, а как отследить, что все CR учтены в требованиях ?
В каком виде хранится CR, как-нибудь делали линки CR с требованиями ? М.б. CR тоже стоит хранить в том же реквизите как требование с новым типом (какой-нибудь CREQ), и его трассировать в требования, которые по нему должны измениться ? чтобы потом autosuspect'ом вылавливать, изменили ли соответствующие требования, или нет ? Или есть какие-нибудь ещё варианты более-менее надежного отслеживания изменений?

Здравствуйте, BalTun, Вы писали:

BT>Здравствуйте, Anatolix, Вы писали:


BT>Ок, а как отследить, что все CR учтены в требованиях ?
BT>В каком виде хранится CR, как-нибудь делали линки CR с требованиями ? М.б. CR тоже стоит хранить в том же реквизите как требование с новым типом (какой-нибудь CREQ), и его трассировать в требования, которые по нему должны измениться ? чтобы потом autosuspect'ом вылавливать, изменили ли соответствующие требования, или нет ? Или есть какие-нибудь ещё варианты более-менее надежного отслеживания изменений?

Если использовать при этом ClearQuest, то это решит вопрос хранения. А если использовать связку RquisitePro и ClearQuest, то это на 90% решает проблему. Правда подразумевается. что в проекте таки не нулевой менеджмент.

BT>Ок, а как отследить, что все CR учтены в требованиях ?

Мы делаем так.
Есть в калибре отдельная категория требований — "Запросы на изменения".
Туда складываются запросы, связанные с изменением требований.
Есть атрибут, указывающий состояние запроса.
После того, как запрос на изменение обратан, состояние запроса на изменение изменяется.

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

С помощью отчётопостроителя я в три клика нахожу перечень не завершенных запросов на изменения...