A practical system-analysis methodology for real delivery:
from the first request and requirements to implementation, verification and current system knowledge.
Русская версия · Start with Foundation · Open Practice · See real applications
Note
SSAD is not about producing documents.
It is about solving system-analysis problems through the real delivery cycle, while documentation becomes the structured trace of that reasoning.
SSAD is a way to build and maintain system knowledge as a connected model of the real system rather than as a set of independent documents.
To do that, the analyst establishes system boundaries, responsibility areas and owners, places canonical knowledge with the appropriate owner, and reconnects local models into a coherent system view. The result makes it clear what is known, where it came from, who is responsible for it, where the canonical answer lives, how knowledge is connected, and what must be revisited when the system changes.
flowchart LR
S[Real system] --> B[Boundaries]
B --> R[Responsibilities]
R --> O[Ownership]
O --> M[Local models]
M --> C[Connections]
C --> Y[System synthesis]
Core principle:
Structure knowledge like the system. Give important facts a canonical owner. Always reconnect local models into a coherent system view.
SSAD does not prescribe a universal requirements/, api/, database/, diagrams/ tree. The knowledge structure emerges after the real boundaries and responsibility areas of the specific system are understood.
| If you need to... | Start here |
|---|---|
| understand the approach itself | 01 · Foundation |
| take a task from request to delivery | 02 · Workflow |
| deeply analyze a system | 03 · Analysis |
| decide where knowledge should live | 04 · Knowledge Structure |
| review a solution and work with the team | 05 · Collaboration |
| assess the impact of a change | 06 · Change |
| get a short working checklist | 07 · Practice |
| see SSAD applied to real systems | 08 · Examples and Applications |
Foundation
↓
Workflow
↓
Analysis
↓
Knowledge Structure
↓
Collaboration
↓
Change
↓
Practice + Applications
Already working on a concrete task? You do not need to read the repository front to back. Open 07-practice/ and follow the checklist into the deeper chapters you need.
flowchart LR
A[Pre-analysis] --> B[Requirements]
B --> C[Analysis & Design]
C --> D[Specification]
D --> E[Review]
E --> F[Grooming]
F --> G[Delivery Support]
G --> H[Verification]
H --> I[Knowledge Update]
E -. new evidence .-> C
G -. implementation facts .-> C
H -. mismatch .-> D
SSAD does not replace the delivery process with its own lifecycle. It explains what system knowledge should exist at each stage, how it should be validated and where it should live.
Once boundaries and responsibility areas are clear, the analyst deepens the relevant perspectives:
Boundaries
→ Responsibilities
→ Ownership
→ Behavior
→ States
→ Data
→ Interfaces
→ Integrations
→ Flows
→ Trust
→ Failures
→ Synthesis
This is a default reasoning order, not a waterfall. New evidence may reopen any earlier question.
SSAD separates two different problems:
HIERARCHY
→ where canonical knowledge lives
LINK GRAPH
→ how knowledge relates to other knowledge
Storage is hierarchical. Knowledge is graph-connected.
A local document may repeat enough context to remain readable, but it should not become a second independent version of truth.
Do not duplicate knowledge. Duplicate context when useful.
flowchart TD
P[Product / Business / Client] <--> SA[System Analyst]
SA <--> K[SSAD knowledge]
K <--> D[Development]
K <--> Q[QA]
K <--> A[Architecture / Integration / Ops]
D --> E[Implementation evidence]
Q --> E
A --> E
E --> K
Different participants contribute different evidence and hold different authority.
A developer may be the best source for a fact about the current implementation without being the owner of the corresponding product or architecture decision. Review, grooming, implementation and QA therefore do not merely consume analysis — they can change it.
SSAD is currently documented against three materially different real systems.
branch-danya-dev/aveli-system-analysis
Aveli validates SSAD against:
- Flutter frontend and backend boundaries;
- local professional data;
- server-controlled account and access;
- RevenueCat/store billing evidence;
- bounded offline trust;
- integrations, failures and end-to-end flows.
Compact route: 08-examples/aveli/
Repository Structure
↓
Access Ownership
↓
Offline Trust
↓
System Synthesis
branch-danya-dev/enterprise-workplace-os-migration
This application validates SSAD against a distributed enterprise migration where the system crosses workplaces, support domains, infrastructure tooling, planning and operational recovery.
Compact route: 08-examples/enterprise-workplace-migration/
Responsibility Structure
↓
Global Status Decomposition
↓
Evidence & Readiness
↓
Technical Projection
branch-danya-dev/revit-rebar-autodim-analysis
This application validates SSAD where the analyzed system executes inside Autodesk Revit and must separate host-owned validity/mechanics from plugin-owned analytical meaning.
Compact route: 08-examples/revit-rebar-autodim/
Host Boundary
↓
View-Space Geometry
↓
Semantic Reference
↓
Generated Output Ownership
The three applications deliberately have different repository structures:
Aveli
→ product-shaped ownership
Enterprise Workplace Migration
→ distributed transformation ownership
Rebar AutoDim
→ host-authority + generated-state ownership
The shared methodology appears in the reasoning model, not in a mandatory folder tree.
SSAD is compatible with existing engineering practices and tools.
It does not replace UML, BPMN, C4, OpenAPI, ADRs, schemas, backlog practices, user stories or a team's architecture standards.
It answers a different question:
How do we combine heterogeneous analytical knowledge into one coherent, navigable and maintainable model of a specific system?
01-foundation/ principles
02-workflow/ real SA lifecycle
03-analysis/ analytical toolkit
04-knowledge-structure/ knowledge architecture
05-collaboration/ team ↔ knowledge loop
06-change/ change mechanics
07-practice/ task-based checklists
08-examples/ examples + real-world applications
assets/ supporting visuals
Historical structures remain available in Git history rather than competing with current knowledge.
Start: 01 · Foundation
Have a task right now: 07 · Practice
Want to see real applications: 08 · Examples and Applications
Contribute: CONTRIBUTING · Direction: ROADMAP