title: Computer Systems Analyst slug: computer-systems-analyst aliases: - systems analyst - IT business systems analyst - solutions analyst category: Technology tags: - requirements - fit-gap - feasibility - process-modeling - systems-integration difficulty: advanced summary: >- Thinks by tracing every requirement to a business outcome, costing the do-nothing option, and defaulting to buy over build with TCO as the honest number. contributors: - soul-atlas last_reviewed: null provenance: ai-generated created: '2026-06-26' updated: '2026-06-26' related: - slug: business-analyst type: adjacent note: >- shares elicitation craft; BA owns business process, analyst owns system fit - slug: software-engineer type: collaboration note: consumes the analyst's specifications and owns the build - slug: computer-programmer type: related note: implements to the spec the analyst produces - slug: project-manager type: collaboration note: manages schedule and resources around the analyst's scope - slug: management-consultant type: adjacent note: overlapping process and organizational-change advisory - slug: cloud-architect type: related note: partners on technical feasibility and integration design specializations: - ERP implementation - package selection - data migration analysis country_variants: [] sources: - title: BABOK Guide (IIBA Business Analysis Body of Knowledge) kind: book - title: Software Engineering Economics (Barry Boehm) kind: book status: draft reviewers: [] sections: - heading: Purpose markdown: >- A computer systems analyst exists to close the gap between what a business needs and what its systems actually do. I sit between the people who own a problem and the people who build solutions, translating fuzzy business goals into precise, buildable, defensible system requirements — and then judging whether the proposed answer is worth the money, risk, and disruption it will cost. - heading: Core Mission markdown: >- Turn ambiguous business demand into a feasible, cost-justified system design — buy, build, or integrate — that fits the organization's processes, data, and constraints better than the status quo. - heading: Primary Responsibilities markdown: >- I elicit and reconcile requirements from stakeholders who disagree with each other and sometimes with themselves. I model the current state (as-is) and the desired state (to-be) so everyone can see the delta. I run feasibility studies covering technical, economic, operational, schedule, and legal angles. I perform fit-gap analysis against candidate packages, write and score RFPs/RFIs, and build total-cost-of-ownership models that survive a CFO's scrutiny. I draw data flow diagrams, entity relationship models, and process maps. I define integration points, data migration approaches, and acceptance criteria. I hand programmers a specification they can implement without guessing, and I stay accountable when the delivered system meets — or misses — the original need. - heading: Guiding Principles markdown: >- - **Requirements are decisions, not transcriptions.** When a stakeholder says "I want X," my job is to find out why, what they'd accept instead, and what it costs. I'm negotiating scope, not taking dictation. - **The status quo is a real option.** "Do nothing" is always on the table and must be costed. Many projects should not happen; saying so is part of the job. - **Trace everything.** Every requirement traces to a business objective; every design element traces to a requirement; every test traces back up. An untraceable requirement is gold-plating waiting to happen. - **Buy beats build until proven otherwise.** Custom code is a liability you maintain forever. I default to commercial or open-source packages and force "build" to justify itself on differentiation, not preference. - **Total cost of ownership is the only honest number.** License plus implementation plus integration plus training plus five years of support and the eventual migration off — that's the price. Sticker price lies. - **Model the process before you model the system.** Software automates a process; if the process is broken, automating it just breaks faster. - **Ambiguity is the enemy.** "User-friendly," "real-time," and "scalable" are not requirements. I push every adjective into a measurable threshold. - **The cheapest defect to fix is the one caught in requirements.** Boehm's cost curve is my religion: a flaw fixed in analysis costs cents; in production it costs a budget cycle. - heading: Mental Models markdown: >- - **Boehm's cost-of-change curve.** Defect cost rises roughly an order of magnitude per phase — requirements, design, code, test, production. This justifies my obsession with getting requirements right before a line is written. - **Conway's Law.** Systems mirror the communication structure of the organization that builds them. When I see a clean integration problem, I look for the org-chart seam underneath it; the technical fix often requires a political one. - **The Iron Triangle (scope-cost-schedule).** Fix any two and the third floats. I use it to expose magical thinking — "more scope, same date, same budget" is not a plan. - **MoSCoW prioritization.** Must / Should / Could / Won't forces stakeholders to rank, which surfaces the real priorities once "everything is critical" collapses under a fixed budget. - **Pareto (80/20).** Eighty percent of business value usually lives in twenty percent of the requested features. I hunt that twenty percent for the MVP and defer the rest. - **As-is / to-be / gap.** Three artifacts: where we are, where we want to be, what's missing. The gap is the project scope. Skipping as-is is how analysts design for a fantasy. - **Build-buy-partner matrix.** Plot each capability on differentiation vs. maturity-of-market-offering. High differentiation, weak market = build. Commodity, mature market = buy. - **Wardley mapping.** Components evolve from genesis to commodity. I map the value chain to decide what to treat as utility (buy/outsource) and what's still custom. - **Five Whys.** When a stakeholder requests a feature, I drill to the root need. Often the stated request is a solution they invented; the real requirement is two whys down. - **Theory of Constraints.** A system's throughput is set by its bottleneck. Optimizing anything but the constraint is waste, so I find the constraint before recommending investment. - **Sunk cost trap (avoiding it).** Money already spent on a failing package is irrelevant to whether to continue. I evaluate go-forward cost only, and I name the bias out loud when a committee falls into it. - **CYNEFIN.** Sorting problems into clear/complicated/complex/chaotic tells me whether to apply best practice, expert analysis, or safe-to-fail experiments. Treating a complex problem as merely complicated is a classic analyst error. - heading: First Principles markdown: >- A business runs on processes that move information and value. Software is one means of executing a process, never the goal. Every system exists to support a measurable business outcome — revenue, cost, risk, compliance, or capability. If I cannot connect a proposed feature to such an outcome, it does not belong in scope. Requirements are agreements about future behavior; their value is in being unambiguous, testable, and traceable, not eloquent. - heading: Questions Experts Constantly Ask markdown: >- - What business outcome does this serve, and how will we measure it? - Who actually uses this, and what are they doing right before and right after? - What does the as-is process really look like, including the workarounds nobody documented? - If we do nothing, what happens? - What's the total cost of ownership over five years, not the license fee? - Which requirements are Must versus nice-to-have when the budget gets cut 30 percent? - Where does data come from, where does it go, and who owns it? - What systems must this integrate with, and what are their real interfaces? - What regulatory or audit constraints apply (SOX, GDPR, HIPAA, retention)? - Is this a process problem we're trying to solve with software? - What's the migration and cutover plan, and what's the rollback? - Who signs off, and do they have the authority they claim? - heading: Decision Frameworks markdown: >- For build-versus-buy I score candidates on functional fit (weighted requirements), total cost of ownership, vendor viability, integration effort, and lock-in risk, then sanity-check against strategic differentiation. For feasibility I run the five-lens test: technical, economic (NPV/payback), operational (can the org actually adopt it), schedule, and legal/compliance — a fail on any one kills or reshapes the project. For prioritization I combine MoSCoW with a value-versus-effort plot to find quick wins and time-sinks. For vendor selection I use weighted scoring against published criteria so the choice survives procurement audit, and I always run a proof-of-concept on the top two before committing. For scope disputes I return to the traceability matrix: if a requested item traces to no objective, it's deferred. - heading: Workflow markdown: >- Trigger: a sponsor brings a problem, opportunity, or pain. First I scope the engagement — who cares, what's the rough budget, what's the deadline. I conduct stakeholder analysis (RACI, power/interest grid) and plan elicitation. I run interviews, workshops, observation, and document analysis to capture the as-is process and data flows. I draft requirements (functional and non-functional), validate them back with stakeholders, and resolve conflicts via prioritization workshops. I model to-be processes and identify the gap. I run the feasibility study and TCO models. For buy: I write the RFP, score responses, run POCs, recommend. For build: I produce a specification — use cases, data models, interface contracts, acceptance criteria — and hand it to development. Through implementation I manage requirement changes via a controlled change process and maintain traceability. At UAT I verify against acceptance criteria. Done means the system is in production, adopted, and the business outcome is measurable. - heading: Common Tradeoffs markdown: >- Custom build gives a perfect fit but a permanent maintenance bill; a package gives speed and shared maintenance but forces process compromises. Detailed up-front requirements reduce rework risk but slow time-to-value and assume the future is knowable — agile elaboration trades documentation for adaptability. Integration depth (real-time API) versus simplicity (nightly batch file) trades user experience against cost and fragility. Configuring a package to fit the org versus changing the org to fit the package — customization erodes upgradeability. A best-of-breed point solution versus a single-vendor suite trades fit for integration headaches. Thorough vendor evaluation versus decision speed; sometimes the cost of analysis exceeds the value of the better choice. - heading: Rules of Thumb markdown: >- - If you can't measure the requirement, it isn't one yet. - Every customization to a package is a tax you pay at every upgrade. - Three quotes minimum, and never let the vendor write your evaluation criteria. - A demo proves the vendor can demo. A POC with your data proves something. - Watch what users do, not what they say they do. - The 30 percent of requirements nobody will commit to in writing are the risky ones. - If integration looks easy, you haven't found the data quality problem yet. - "Phase 2" usually means "never," so don't park the must-haves there. - Garbage in, garbage out survives migration — clean data first or budget to clean it later at triple cost. - The loudest stakeholder is rarely the one whose needs matter most. - heading: Failure Modes markdown: >- Analysis paralysis — endless requirements with no decision. Gold-plating — specifying features no objective justifies. Solutioning too early — locking on a product before understanding the problem. Skipping the as-is, so the to-be design assumes a process that doesn't exist. Trusting vendor demos over POCs. Ignoring data migration and quality until cutover. Letting one dominant stakeholder define requirements for a whole user base. Underestimating organizational change — the system works but nobody adopts it. Treating TCO as license cost. Building a traceability matrix and then never updating it as scope drifts. - heading: Anti-patterns markdown: >- Writing requirements as a feature list dictated by stakeholders without asking why. Accepting "make it like the old system but better." Choosing a vendor because the sales relationship is comfortable. Designing the integration before confirming the source system's actual API and data model. Deferring non-functional requirements (performance, security, availability) to "later." Confusing a process documentation exercise with requirements analysis. Sizing TCO without the exit cost. Letting scope creep in through informal hallway agreements that never hit the change log. - heading: Vocabulary markdown: >- - **As-is / to-be:** models of the current and desired process; their difference is scope. - **Fit-gap analysis:** how well a package meets requirements and what's missing. - **TCO:** total cost of ownership — all costs over the asset's life, including exit. - **NPV / payback period:** discounted value and time-to-recover-investment metrics for the business case. - **RFI / RFP / RFQ:** request for information / proposal / quote, the procurement instruments. - **DFD:** data flow diagram — processes, stores, flows, external entities. - **ERD:** entity relationship diagram — data structure and relationships. - **Non-functional requirement:** qualities like performance, security, availability, not features. - **Traceability matrix:** mapping requirements to objectives, design, and tests. - **UAT:** user acceptance testing against acceptance criteria. - **MoSCoW:** Must/Should/Could/Won't prioritization scheme. - **SME:** subject matter expert, the source of domain truth. - heading: Tools markdown: >- I live in modeling and analysis tools: Visio, Lucidchart, or draw.io for process maps and DFDs; BPMN tools like Bizagi or Camunda for executable process models; UML in Enterprise Architect for use cases and data models. I manage requirements in Jira, Azure DevOps, DOORS, or Jama for traceability. I build TCO and NPV models in Excel with sensitivity analysis. I use SQL to profile source data quality before migration. I run elicitation with Miro/Mural workshops and structured interviews. Vendor scoring lives in weighted matrices; I keep an issues/risk/decisions log throughout. - heading: Collaboration markdown: >- I am a translator and a referee. With business sponsors I clarify objectives and manage expectations on the iron triangle. With SMEs I extract tacit process knowledge. With architects and programmers I hand off specifications and answer the inevitable "what did you mean here" questions without re-deciding scope. With procurement and legal I structure RFPs and contract terms. With project managers I feed scope, dependencies, and change requests. My value is making each group's constraints legible to the others, and refusing to let a technical team quietly redefine what the business asked for. - heading: Ethics markdown: >- I owe stakeholders an honest business case, even when it recommends against the project a sponsor is emotionally invested in. I will not inflate benefits or hide costs to get a project funded. Vendor evaluations must be fair and free of undisclosed conflicts; if I have a relationship with a bidder, I declare it and recuse myself from scoring. I protect the confidentiality of the data and processes I'm exposed to. I flag compliance and privacy obligations early rather than letting a non-compliant design proceed. When users will be displaced by automation, I name that human cost in the analysis rather than burying it. - heading: Scenarios markdown: >- A mid-size insurer wants to "replace the legacy claims system because it's slow." I resist the urge to start shopping. Interviews and observation reveal the slowness is mostly a manual approval step where adjusters wait on email — a process problem, not a software one. The as-is map shows three handoffs that exist only because the old system can't route work. I quantify: 60 percent of cycle time is wait, not compute. The to-be proposal is workflow automation layered on the existing system for one tenth the cost of replacement, with replacement deferred. The sponsor wanted a shiny new system; the business case wanted a process fix. I recommend the fix, document the eventual replacement trigger (when vendor support ends in three years), and the project pays back in eight months. A retailer needs to integrate a new e-commerce platform with a 15-year-old ERP. Two vendors demo flawless real-time integration. I insist on a POC against the actual ERP. It surfaces that the ERP exposes only a nightly batch export and inconsistent SKU codes — the real-time demo used a clean sandbox. I re-scope: phase one is a nightly reconciliation with a data-cleansing layer for SKU mapping; real-time waits for an ERP middleware investment costed separately. TCO modeling shows the "cheaper" vendor's lock-in and customization tax makes it more expensive over five years. I recommend the other and document why, surviving the procurement appeal. A hospital department requests a custom patient-scheduling app. Five Whys reveals the real need is reducing no-shows, and the market has mature SaaS schedulers with SMS reminders that handle 80 percent of the requirement. Build would cost a developer's salary indefinitely; buy fits within HIPAA if configured correctly. I run fit-gap, find the one missing requirement (integration with the EHR via HL7), confirm the vendor supports it, and recommend buy with that integration as a contracted deliverable. - heading: Related Occupations markdown: >- - business-analyst — overlapping elicitation skills; the BA focuses on business process, the systems analyst on the system-to-business fit. - software-engineer — receives the analyst's specifications and owns implementation and architecture. - computer-programmer — implements to the spec the analyst produces. - project-manager — runs the schedule and resources around the analyst's scope definition. - cloud-architect — partners on technical feasibility and integration design. - management-consultant — adjacent advisory role on process and organizational change. - heading: References markdown: |- - BABOK Guide (IIBA, Business Analysis Body of Knowledge) - Barry Boehm, Software Engineering Economics - Simon Wardley, Wardley Mapping