# Reverse engineering (analysing an existing system)

This feature is **Coming soon**. There is no dedicated screen for analysing an existing system yet, so we are not showing screenshots of it.

The plan is to make the PM on Rails graph usable not only for new development, but also when you **fix or take over a system that is already running**. The hardest part of changing an existing system is knowing correctly how that system works today.

## Why changes go wrong

The longer an existing system has been running, the more it tends to become a black box nobody can see inside.

- You cannot tell what will break when you change something.
- The hidden rules of the form "this must never be changed" are written down nowhere.
- The code, the server configuration, the APIs, the database and the business rules are all scattered, and nobody can see the whole picture.

The result is accidents: "I touched it and something else stopped", "I deleted it and it turned out to be an important feature".

## The approach we are planning

The idea is that analysing an existing system reads the code, the configuration, the APIs, the database and the business rules, and lets you treat the connections across all of them as a single map. The following, previously scattered, becomes something you can tie to requirement cards and change tasks.

- The program code
- The server and infrastructure configuration
- The shape of the APIs and the database
- The mechanisms behind login, permissions and so on
- The business rules (what a feature is there to do)

The map that comes out of this is meant to be something people can search and view as diagrams, and something you can also hand to an AI (Claude Code, for example) as "this is how the system is built".

## How we plan to connect it to PM on Rails

1. **See how it is today** — Read the existing system and make its current state, its constraints and its hidden rules visible.
2. **Turn the gap between "it is like this" and "we want it like that" into requirement cards** — Organise that difference as PM on Rails [requirement cards](https://pmonrails.com/en/docs/demands.md).
3. **From there it is the usual flow** — Decide the scope, then stories and tasks, then implementation ([The development flow](https://pmonrails.com/en/docs/stories.md)).

> Analysing existing systems is an area we plan to extend. For now, PM on Rails itself is used mainly to manage requirement cards, requirements, stories and tasks.

---

https://pmonrails.com/en/docs/reverse-engineering