Five Common Systems Analysis Mistakes on IT Projects

Here are five mistakes that repeatedly create trouble on large enterprise projects. My examples come mainly from banking and fintech, where vague requirements, legacy integration, regulatory constraints, and competing stakeholder expectations become expensive quickly.

1. Requirements without verifiable meaning

The requirement “We need a convenient way for corporate clients to transfer funds” leaves too much open to interpretation. Without scenarios, transaction types, limits, and acceptance criteria, business and engineering may be aiming at different outcomes.

What helps

Give every requirement clear acceptance criteria, and attach metrics to goals that are genuinely measurable. Cover the main flow, alternatives, and boundary conditions. Review the wording with business, engineering, and QA before implementation; involve the BA in the domain work when the role exists.

2. Ignoring the architectural environment and integrations

A new capability has to fit into a live technology landscape. Overlooking legacy systems, payment gateways, data ownership, or interface constraints produces weak estimates and forces the team to revisit the design during implementation.

What helps

Review the architecture artifacts and current interface contracts. Identify limits around throughput, latency, availability, data formats, and security. Agree on integration and migration choices with architects, system owners, and fellow analysts.

3. Weak grasp of the domain and its regulation

A technically sound design may still fail business or compliance requirements. Applicability matters: PCI DSS covers payment account data and systems that can affect the security of that environment. KYC and AML obligations depend on the rules applicable to the organisation, customer, and transaction. Copying every control into every specification is not a substitute for analysis.

What helps

Determine which rules apply to the product, its data, and its operations. Bring in compliance, legal, information security, and domain experts before the design is fixed. Preserve the source of each mandatory requirement in the traceability chain.

4. Under-worked negative scenarios

In fintech, error handling, boundary conditions, and partial failures are part of the core behavior. A dropped connection, malformed payment details, an exceeded limit, a repeated request, or an unavailable API should have a defined outcome for both the system and the user.

What helps

Include negative and boundary scenarios in requirements and acceptance criteria. With QA, operations, and security, review timeouts, retries, idempotency, recovery, and invalid input wherever they apply.

5. No early validation of concepts

Documentation that receives no feedback from engineers, architects, or users creates a false sense of readiness. Once code, integrations, and user training depend on a flawed assumption, correcting it can require changes across several parts of the solution.

What helps

Validate the riskiest assumptions first and work in short feedback loops. A UI prototype may fit one problem; an engineering spike, API contract, or scenario review may fit another. Match the validation method to the risk.

---

Systems analysis on a large project connects business goals with architecture, data, security, regulation, and operations. The quality of the work is not measured by document length. It shows in shared understanding and in how early the team exposes risk.

Follow one request to a verifiable decision

Consider an illustrative request to transfer money between a company’s accounts. At first it looks like a form with an amount and a button. The system also needs to know who can initiate the transfer, whether a second approval is required, which balance to show, when the operation is complete, and what happens after a lost connection.

I start with one complete scenario: the initiator selects permitted accounts, enters an amount, reviews the payment details and confirms the action. Then I change the conditions: permissions have been revoked, the balance has changed, confirmation arrives twice, or a dependency is unavailable. These variants expose decisions hidden by the screen design.

Ambiguity	Decision to agree	Acceptance check
“Available account”	Access rule and source of authority	Only permitted accounts are visible
“Transfer complete”	Final state and authoritative confirmation	Success is not shown before confirmation
“Try again”	Retry rules and operation identity	A timeout retry does not create another transfer
“Current data”	Allowed age and response to delay	Stale state is identified clearly

This is a teaching example, not a particular banking system. Real answers depend on the product, payment process, and architecture. Analysis creates value by resolving them before separate teams embed incompatible assumptions.

What a leader should inspect before implementation

I would ask for a trace from goal to scenario, rule, contract, and acceptance check. These need not share one document. For each critical requirement, the chain should lead to the person who confirmed the decision.

An unknown answer becomes a visible investigation with an owner. For example, establish how an external API behaves after a timeout before choosing the retry mechanism. Uncertainty is normal; treating it as a finished decision is dangerous.

A short cross-role review helps. The analyst explains the scenario, an engineer identifies implementation boundaries, QA challenges assumptions, and the product owner checks the outcome. Finding a disagreement here is useful. Finding it after release means a defect or expensive rework.

Discuss a requirements and architecture review →

---

Originally published on my Telegram channel @it_underside.

Yours, DPUPP