Так, вчера мы разобрали первый сценарий, при котором повторное использование требований будет особенно полезно, - разработку семейства продуктов, а сегодня разберём второй случай - реинжиниринг и замену системы 🧐

👉 При реинжиниринге или замене системы всегда повторно используются часть требований из исходной версии системы, даже если эти «требования» никогда не излагались в письменном виде. Это может быть полезно для понимания логики работы системы и выявления возможностей для улучшения.

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

❗ Внимание ❗ Только не поддавайтесь искушению для экономии времени повторно задействовать слишком большую часть старого проекта, упуская при этом новые возможности.

Вообще, мы советуем собирать повторно используемые артефакты в общее хранилище и обеспечивать управление этой информацией как общекорпоративным активом. Так вы сможете оптимизировать разработку не одного конкретного проекта, а сразу многих 😌