Start here: your first system
You don't need a methodology. You need one page that answers six questions before you build, and the discipline to keep it true.
- You have a one-page template you can apply to a real system this week.
- You know which parts of classical systems engineering to ignore while you're small.
10.1The one-pager
This fits on one side of a sheet and replaces most of what people mean by "doing systems engineering". Write it before the build, then update it when reality disagrees.
1 PURPOSE One sentence with a number or observable outcome.
"Hold 21 °C ±0.5 °C using the least energy."
2 BOUNDARY What is inside (we design it) / outside (we design against it).
3 ELEMENTS The 3–7 things that must exist. Include people and procedures.
4 INTERFACES For each crossing: content, timing, failure behavior, owner.
5 REQUIREMENTS 8–15 testable statements, each with an acceptance method.
6 RISKS Top 5 by severity × likelihood. Mitigation and owner each.
7 V&V For each requirement: how you'll prove it, and who decides.
8 LIFECYCLE How it deploys, how it's monitored, how data leaves, how it dies.Eight headings, one page. If a project needs more than this, the extra belongs in appendices that reference it — not in a parallel universe of documents.
10.2Thirty days, four milestones
| Week | Do | Artefact |
|---|---|---|
| 1 | Write the purpose, the boundary and the elements. Interview one real user and one operator. | One-page system definition, half a page of notes |
| 2 | Turn the notes into 8–15 requirements with acceptance methods. Find the interfaces — including the ones nobody owns. | Requirements table with a "method" column; an interface list |
| 3 | Run one trade study on the decision that's hardest to reverse. Score it, test the weights, write the six-line record. | One page: alternatives, criteria, weights, result, revisit condition |
| 4 | Write the V&V table and the top five risks. Build the first requirement end to end, including its test. | Traceability table, risk list, one working vertical slice |
10.3What to ignore while you're small
- SysML and full MBSE tooling. Useful at scale, a career in itself at small scale. Plain text and one diagram are enough until they aren't.
- Formal certification processes. Unless a regulator requires it, borrow the thinking, skip the paperwork.
- Weighted scoring for reversible decisions. Just decide and write one line about why.
- A process for every document. Six artefacts that stay current beat thirty that don't.
- The word "shall" in every sentence. Use it where mandatory means something; elsewhere plain language is clearer.
How do you know the practice is working? Three signs, in order. You stop being surprised by integration failures, because the interfaces were named. Arguments about priorities turn into arguments about criteria, which is a much shorter argument. And when someone asks "why is it like this?", there is a document with a date on it instead of a shrug and a name.
Keep a decision log: date, decision, alternatives considered, what would make you revisit. One line each. Twelve months of that log is the most valuable engineering document most teams never write — it is the difference between an organization that remembers and one that re-litigates.
Systems engineering has a reputation for ceremony because large programs generate a lot of paper. The discipline underneath is simple and a bit uncomfortable: say what the whole thing is for, name the boundary, make the interfaces explicit, and prove the thing against the need rather than against your intentions. That takes an hour to learn and a career to get good at. You have the hour.
What is the highest-value thing to write before starting a new system?
60-second recap
- One page, eight headings. Purpose, boundary, elements, interfaces, requirements, risks, V&V, lifecycle.
- Four weeks to a defensible system definition — each week ends with something readable.
- Skip the ceremony, keep the thinking. No SysML, no certification ritual, no scoring for reversible calls.
- Keep a decision log. It's the only organizational memory that survives staff turnover.