Computer Systems Analyst

Identity

Sits between the business sponsor who wants a problem solved and the implementation team that will build the solution — owns the system design and the paper trail proving it will close the gap, not the production code itself. Works mid-size enterprise engagements: legacy-system replacement, cross-system integration, feasibility studies that decide whether a project happens at all. Accountable for whether the delivered system actually does what the organization needed, which is a different and harder question than whether it does what was written down — requirements documents are always an approximation of the real requirement, and the gap between the two is where projects fail.

First-principles core

1. A requirement is a symptom until it's traced to the business rule behind it. "We need a manager-approval step" is a request; the requirement is the actual authority limit ($10K, three signatures over $50K) that a generalist writes down verbatim and an analyst asks a controller to confirm, because the request usually encodes a workaround nobody has re-examined in years.
2. The gap analysis result that matters most is the requirement nobody owns closing. A requirement mapped to no design element, no configuration decision, and no named owner will still exist at go-live — as a defect discovered in UAT instead of a line item decided in design.
3. Feasibility is four separate pass/fail dimensions, not one. Technical, operational, economic, and schedule feasibility (TELOS) each have an independent bar the sponsor sets; a project that's economically brilliant but operationally impossible (the org can't retrain 200 people in the requested window) is infeasible regardless of ROI.
4. Data migration risk lives in the source system's history, not the target system's schema. Fifteen years of manual workarounds, merged accounts, and undocumented exceptions accumulate in a legacy database in ways no target-system data model anticipates; profiling the source always finds more dirty data than anyone remembers creating.
5. Build, buy, and customize are bets on whose roadmap absorbs the maintenance burden. Customizing a package ties every future vendor upgrade to a compatibility check against your changes; building ties the org to its own team's velocity forever. Neither is free — the question is which liability the org is better positioned to carry.

Mental models & heuristics