Reverse Engineering, или обратная разработка, — это метод извлечения информации о существующем решении для формулирования требований. Этот процесс особенно важен, когда нужно обновить, изменить или заменить устаревшую систему, а также при интеграции различных решений. При этом важно помнить, что бизнес заинтересован не в самом процессе, а в его результате. Необходимо четко определить цели и границы такого анализа, чтобы избежать ненужных затрат времени и ресурсов.
Для обратной разработки можно использовать различные источники: интервью с тех-специалистами, эксперименты с системой, анализ данных и исходного кода, а также изучение тикетов. Не менее важны интервью с пользователями, изучение их взаимодействий с системой, и анализ документации. Однако, стоит помнить, что даже проверенные источники могут быть неточными, поэтому необходимо перепроверять информацию и внимательно выбирать уровень детализации, чтобы не увязнуть в незначительных деталях.
Важно различать, как система работает сейчас (As-Is) и как она должна работать в будущем (To-Be). Восстановленные требования должны описывать текущее состояние, а изменения следует фиксировать отдельно. При сборе информации стоит помнить, что пользователи могут быть необъективными: они могут забывать детали, путать факты с предположениями и перескакивать на идеальные сценарии. Поэтому важно использовать сочетание различных методов и источников для получения полной картины.
Особенности взаимодействия с различными стейкхолдерами также играют важную роль. Например, технические специалисты хорошо разбираются в том, как работает система, но не всегда понимают бизнес-логику. Операционная поддержка может не замечать свои ошибки, а спонсоры могут быстро забывать о деталях. Поэтому, важно не полагаться на мнение одного человека, а собирать информацию от разных групп, чтобы получить полное и объективное представление о системе.
Изображение носит иллюстративный характер
Для обратной разработки можно использовать различные источники: интервью с тех-специалистами, эксперименты с системой, анализ данных и исходного кода, а также изучение тикетов. Не менее важны интервью с пользователями, изучение их взаимодействий с системой, и анализ документации. Однако, стоит помнить, что даже проверенные источники могут быть неточными, поэтому необходимо перепроверять информацию и внимательно выбирать уровень детализации, чтобы не увязнуть в незначительных деталях.
Важно различать, как система работает сейчас (As-Is) и как она должна работать в будущем (To-Be). Восстановленные требования должны описывать текущее состояние, а изменения следует фиксировать отдельно. При сборе информации стоит помнить, что пользователи могут быть необъективными: они могут забывать детали, путать факты с предположениями и перескакивать на идеальные сценарии. Поэтому важно использовать сочетание различных методов и источников для получения полной картины.
Особенности взаимодействия с различными стейкхолдерами также играют важную роль. Например, технические специалисты хорошо разбираются в том, как работает система, но не всегда понимают бизнес-логику. Операционная поддержка может не замечать свои ошибки, а спонсоры могут быстро забывать о деталях. Поэтому, важно не полагаться на мнение одного человека, а собирать информацию от разных групп, чтобы получить полное и объективное представление о системе.
