# IT Systems Analysis in 103 Current Vacancies: Process, Data, Interfaces and Solution Validation

> A reproducible analysis of 103 current vacancies maps the process, data, interface, validation and implementation work expected in IT systems analysis.

- Canonical page: https://mtfinstitute.com/insights/it-systems-analysis-103-vacancies-2026/
- Content type: Article
- Editorial category: Research & Reports
- Publisher: MTF Institute of Management, Technology and Finance
- Author: MTF Institute Research Team- Published: 2026-08-28
- Updated: 2026-08-31
- Language: English
- Topics: IT Systems Analysis, Requirements Analysis, Data Mapping, Interface Analysis, Solution Validation

## IT Systems Analysis in 103 Current Vacancies: Process, Data, Interfaces and Solution Validation

The complete open archive - a searchable PDF, the 103-row evidence dataset, data dictionary and methods appendix - is preserved at [Zenodo DOI 10.5281/zenodo.22135110](https://doi.org/10.5281/zenodo.22135110).

**MTF Institute Research Report — published research edition**  
**Evidence date:** 27 August 2026  
**Report date:** 28 August 2026  
**Institution:** MTF Institute  
**Author:** MTF Institute Research Team  
**Independent review:** Passed under the MTF Course Factory research-publication quality gate  
**Technical report number:** MTF-CF-RR-2026-08-28-16  
**Language:** English  
**Study type:** Cross-sectional descriptive vacancy analysis  
**Geographic scope:** Publicly indexed international purposive sample  
**DOI:** [10.5281/zenodo.22135110](https://doi.org/10.5281/zenodo.22135110)

## Abstract

IT systems analysis sits between an organizational need and a change to processes, data, software, interfaces or operating practice. The role is advertised under several titles, and the boundary between business analysis, systems analysis, application analysis, testing and implementation support is not always explicit. This report examines how systems-analysis work was described in 103 unique public vacancies accepted from evidence retrieved on 27 August 2026. The discovery process executed 128 reproducible public-search prompts and parsed 511 result rows. A deterministic gate accepted 108 qualifying vacancy occurrences before exact-URL deduplication, removed five repeated URL occurrences and retained 103 unique HTTPS vacancy identities.

The corpus is purposive and non-representative. It was deliberately designed to identify current roles whose advertised duties materially included requirements analysis, stakeholder discovery, process or system modeling, data or interface analysis, solution evaluation, testing, user acceptance testing, traceability, implementation support, controls or incident and problem analysis. Pure help-desk, software-development, data-analysis, hardware, infrastructure-administration and generic business-analysis roles without sufficient systems work were excluded. Adjacent titles were admitted only through a stricter evidence gate.

Requirements analysis appears in 94 vacancies (91.3%), stakeholder discovery in 88 (85.4%), process modeling in 80 (77.7%), testing or quality assurance in 79 (76.7%), documentation in 75 (72.8%), interface or integration analysis in 65 (63.1%), data analysis or mapping in 58 (56.3%) and implementation or deployment support in 56 (54.4%). The most visible coded outputs are process flows, test plans or cases, functional specifications, user stories with acceptance criteria, user-acceptance-testing materials and data maps. The findings support professional learning that connects discovery, models, requirements, data and interfaces, option evaluation, traceability, validation, implementation and post-release learning. They do not establish occupational prevalence, causation, compensation, employer endorsement or guaranteed employment outcomes.

**Keywords:** IT systems analysis; systems analyst; business systems analyst; requirements analysis; process modeling; data mapping; interface analysis; solution validation; user acceptance testing; vacancy analysis; professional learning

## Executive summary

This study asks what transferable capabilities and work products are visible in a screened sample of current IT systems-analysis vacancies. It does not attempt to define one universal occupation. It provides a transparent empirical base for an original professional course and for later practitioner, methodologist and learner review.

The accepted corpus contains 103 unique direct public vacancy identities. Sixty-eight records (66.0%) come from first-party employer or applicant-tracking-system pages, 20 (19.4%) from employer or recruiter direct postings outside the named ATS family, and 15 (14.6%) from public job-board or recruiter postings. The source balance reduces dependence on a single publisher family but does not turn the sample into a probability sample.

Role naming is varied but not arbitrary. Sixty-three accepted vacancies (61.2%) use the Business Systems Analyst family, 26 (25.2%) use the Systems Analyst family, three (2.9%) use the IT Systems Analyst family, and 11 (10.7%) use adjacent titles that passed a stronger systems-analysis evidence gate. This supports a course title centered on IT systems analysis while recognizing that learners may encounter Business Systems Analyst as the most common title family in this corpus.

The clearest finding is that systems analysis is advertised as a connected delivery practice. Requirements analysis appears in 94 vacancies (91.3%) and stakeholder discovery in 88 (85.4%). Process modeling appears in 80 (77.7%), testing or quality assurance in 79 (76.7%) and documentation in 75 (72.8%). These results favor a course that begins with problem framing and stakeholder evidence, then converts that evidence into reviewable models and requirements, and continues through validation rather than ending when a document is written.

Technical translation is also prominent. Interface or integration analysis appears in 65 vacancies (63.1%), data analysis or mapping in 58 (56.3%) and implementation or deployment support in 56 (54.4%). A learner therefore needs more than meeting facilitation. The role requires enough technical fluency to reason about system boundaries, data meaning, upstream and downstream effects, interface behavior, error paths and operational dependencies without pretending to be the software engineer or solution architect.

Delivery governance is visible in several overlapping signals. Agile or backlog work and controls or risk each appear in 47 vacancies (45.6%); user acceptance testing appears in 45 (43.7%); change and adoption support in 41 (39.8%); system modeling in 36 (35.0%); user stories or acceptance criteria in 31 (30.1%); root-cause analysis and solution evaluation in 29 each (28.2%); incident or problem analysis in 19 (18.4%); and traceability in 17 (16.5%). Lower frequency does not mean low professional importance. Some activities are described with different words, and some become essential precisely because a failure is costly.

The output profile is practical. Process flows appear in 38 vacancies (36.9%), test plans or cases in 32 (31.1%), functional specifications in 31 (30.1%), user-story and acceptance-criteria artifacts in 29 (28.2%), user-acceptance-testing materials in 28 (27.2%) and data maps in 23 (22.3%). Training or user guidance, issue and defect records, traceability matrices, backlogs, requirements documents, option assessments, interface specifications, gap analyses, root-cause reports, impact assessments and implementation plans are also present. These outputs support assessment through usable artifacts, completed examples and quality checks rather than recall alone.

The geographic field requires caution. Jurisdiction was not stated in the indexed evidence for 75 records (72.8%). The United States is stated for 20 (19.4%), Canada for five (4.9%), and India, South Africa and the United Kingdom for one each (1.0% each after rounding). The study therefore cannot describe a global distribution of systems-analysis work. It deliberately avoids inferring a vacancy location from an employer identity, a supplier location or a country mentioned in duties.

The educational implication is a four-part progression: investigate the work system; model processes, requirements, data and interfaces; evaluate and control solution decisions; and validate, implement and learn from change. Artificial-intelligence practice may assist with structuring notes, identifying ambiguities, comparing models and testing artifact completeness, but every output must be grounded in supplied evidence, checked against the case and approved by an accountable human. The corpus contains no evidence that professional responsibility can be delegated to a model.

## Research questions

1. Which systems-analysis responsibilities and skills are most frequently visible in the accepted vacancy corpus?
2. Which professional outputs are explicitly visible in the indexed vacancy evidence?
3. How are accepted roles distributed across source families and title families?
4. What geographic information can be reported without inferring unstated vacancy locations?
5. What connected workflow is implied by requirements, process, data, interface, testing, implementation and problem-analysis signals?
6. What curriculum, artifact and assessment choices are defensible from the evidence?
7. Which methodological, rights and interpretation limits constrain reuse of the findings?

## Research design and reproducible method

### Unit of analysis and dates

The unit of analysis is one unique direct public individual vacancy identity. Public evidence was retrieved on 27 August 2026 in the Europe/Lisbon time zone. The report was prepared on 28 August 2026. The study is cross-sectional: it describes the evidence available during a bounded collection and screening period. A vacancy page can change or close after that date.

The public source ledger is `it-systems-analysis-vacancy-evidence-2026.csv`. Each public row includes a direct source URL, employer or publisher label, publisher host, role title, explicitly supportable jurisdiction label, retrieval date, public freshness signal, approximate freshness in days, availability statement, coded skill and responsibility tags, coded output tags, source family, rights classification and suitability basis. Stable internal row identities, deduplication keys and short screening excerpts remain in the private reproducibility record and are not included in the public archive. [1]

### Discovery frame

The collection used 128 public-search prompts preserved in four immutable capture files. Searches combined role titles, delivery activities, countries and public ATS domains. The role frame covered IT Systems Analyst, Systems Analyst, Business Systems Analyst and closely adjacent titles. The activity frame included requirements, stakeholders, process mapping, system modeling, data mapping, integrations and interfaces, solution options, user stories, acceptance criteria, testing, user acceptance testing, traceability, implementation, change, controls, incidents and root-cause analysis.

The four captures yielded 511 parseable discovery result rows. This denominator is a discovery-row count, not a count of all vacancies on the web and not a labour-market size estimate. Search indexing, query construction, ranking, language, geographic personalization and technical accessibility shaped the result set. No authenticated research page, private marketplace feed, CAPTCHA bypass, paywall bypass, access-control bypass, provider credential or shell HTTP client was used. [2–6]

### Eligibility gate

A discovery row was eligible only when all of the following were true:

- the URL used HTTPS and represented an individual vacancy identity;
- the public title was in a primary systems-analysis title family or in a narrowly defined adjacent family;
- the indexed vacancy evidence had a crawl or publication signal no more than 180 days old;
- the indexed evidence contained no explicit closed, filled or expired signal;
- the role was not a pure software-development, data-analysis, help-desk, service-desk, hardware, network-administration or systems-administration position;
- the role evidenced at least two core systems-analysis duties;
- the evidence showed requirements analysis or stakeholder-facing discovery;
- generic job descriptions, career guides, resumes, papers, search pages and inaccessible non-vacancy content were excluded.

Adjacent titles faced an additional gate. IT Business Analyst, Business Technology Analyst, Business Applications Analyst and Functional Analyst variants had to show both requirements and stakeholder evidence, at least four core systems-analysis categories and at least one delivery category such as process modeling, interface analysis, testing, user acceptance testing, implementation or solution evaluation. This rule was designed to prevent generic business-analysis work from entering the sample merely because it mentioned technology.

### Screening result

| Screening decision | Discovery rows |
|---|---:|
| Qualifying vacancy occurrence before exact-URL deduplication | 108 |
| Excluded: non-vacancy domain or content | 143 |
| Excluded: document or generic description | 78 |
| Excluded: currency not reproducible | 71 |
| Excluded: title outside scope | 37 |
| Excluded: insufficient systems-analysis evidence | 36 |
| Excluded: generic role content | 11 |
| Excluded: index freshness over 180 days | 11 |
| Excluded: not identifiably a direct vacancy | 10 |
| Excluded: adjacent title without strong systems-analysis evidence | 6 |
| **Total parsed discovery rows** | **511** |

The 108 qualifying occurrences contained five repeated canonical URLs. After exact-URL deduplication, 103 unique accepted vacancy identities remained. The final QA confirmed 103 unique source URLs and 103 unique deduplication keys. [4][5]

### URL normalization and deduplication

Deduplication occurred in two stages. First, exact URLs were canonicalized by normalizing scheme, host and path and removing non-identity query parameters. Identity-bearing parameters such as an Indeed `jk` value were retained. When the same canonical URL appeared in more than one query result, the richer public indexed representation was retained and the repeated occurrence was recorded.

Second, the process generated a deterministic key from publisher host, normalized title and explicit requisition or path identity. This pass found no semantic cross-URL duplicate within the final eligible set. The absence of a detected semantic duplicate is not proof that two employers never syndicated the same wording; it means the deterministic identity fields did not support collapsing any additional record. The full duplicate trace remains in the private reproducibility record; the public methods appendix, corpus QA summary and archive manifest report the applicable rule and final result. [3][4][6]

### Coding procedure

Coding was deterministic, case-insensitive, overlapping and non-exclusive. Pattern groups were applied to the indexed public title and vacancy text. A category count is the number of accepted vacancies in which at least one expression for that category was detected. It is not a word count, measure of task intensity, estimate of time allocation or competency assessment.

The skill and responsibility family covers requirements analysis, stakeholder discovery, process modeling, system modeling, data analysis and mapping, interface and integration analysis, solution evaluation, user stories and acceptance criteria, traceability, testing and quality assurance, user acceptance testing, root-cause analysis, implementation and deployment, change and adoption, controls and risk, incident and problem analysis, documentation, and Agile or backlog work.

The output family covers requirements documents, functional specifications, process flows, data maps, interface specifications, user stories and acceptance criteria, traceability matrices, test plans and cases, user-acceptance-testing plans or results, solution-option assessments, impact assessments, gap analyses, issue or defect logs, implementation plans, training or user guides, backlogs and root-cause reports.

For each category, the reported percentage is:

`coded vacancy count / 103 × 100`

Percentages are rounded to one decimal place. Since codes overlap, values within or across tables must not be summed to describe a share of work. A vacancy can contribute to many categories. Absence of a tag means that the pattern was not evidenced in the retained indexed text; it does not prove that the employer did not expect the activity. [3][4]

### Deterministic quality checks

The final QA passed all recorded rules: at least 100 accepted vacancies; unique URLs and deduplication keys; non-empty required fields; exact retrieval date; HTTPS-only accepted URLs; freshness no greater than 180 days; minimal excerpts no longer than 24 whitespace-delimited tokens; at least two core systems-analysis tags per accepted row; requirements or stakeholder evidence in every accepted row; and no explicit closed signal in the retained minimal excerpt. The SHA-256 manifest for the evidence package had no mismatch at handoff. [4][5][6]

## Sample description

### Source families

| Source family | Vacancies | Share of 103 |
|---|---:|---:|
| First-party employer or applicant-tracking-system page | 68 | 66.0% |
| Employer or recruiter direct posting | 20 | 19.4% |
| Public job-board or recruiter posting | 15 | 14.6% |
| **Total** | **103** | **100.0%** |

The corpus is led by first-party or employer ATS pages. Public job-board and recruiter pages remain important because some employers expose richer current evidence there than through an indexable first-party page. Source family is a provenance classification, not a quality score. The eligibility and evidence gates applied to all families.

### Role-title families

| Role-title family | Vacancies | Share of 103 |
|---|---:|---:|
| Business Systems Analyst | 63 | 61.2% |
| Systems Analyst | 26 | 25.2% |
| Adjacent title with strong systems-analysis evidence | 11 | 10.7% |
| IT Systems Analyst | 3 | 2.9% |
| **Total** | **103** | **100.0%** |

The Business Systems Analyst family is the largest in this corpus. The narrower IT Systems Analyst label appears only three times, but the activities advertised across title families are recognizably technical and delivery-oriented. An evidence-led course can therefore use IT Systems Analysis as the capability domain while making Business Systems Analyst visible in role orientation, discovery language and search intent.

The 11 adjacent-title records should not be interpreted as a broad invitation to merge every IT Business Analyst or application role into systems analysis. They entered only because the indexed evidence crossed the stronger gate described above.

### Explicitly supportable jurisdictions

| Jurisdiction label | Vacancies | Share of 103 |
|---|---:|---:|
| Not stated in indexed public result | 75 | 72.8% |
| United States | 20 | 19.4% |
| Canada | 5 | 4.9% |
| India | 1 | 1.0% |
| South Africa | 1 | 1.0% |
| United Kingdom | 1 | 1.0% |
| **Total** | **103** | **100.0%** |

The large unstated group is a deliberate evidence boundary. Jurisdiction was assigned only when a location was explicit in the indexed title, URL path or labeled location field. A country mentioned as a supplier location, delivery partner, organizational footprint or regulated market was not treated as the vacancy location. The result is less geographically complete but more reproducible and less misleading.

No conclusion about worldwide distribution, remote-work eligibility, work authorization, employer nationality or labour demand by country can be drawn from this table.

## Findings

### 1. Requirements and stakeholder evidence define the entry point

| Skill or responsibility category | Vacancies | Share of 103 |
|---|---:|---:|
| Requirements analysis | 94 | 91.3% |
| Stakeholder discovery | 88 | 85.4% |
| Process modeling | 80 | 77.7% |
| Testing and quality assurance | 79 | 76.7% |
| Documentation | 75 | 72.8% |
| Interface and integration analysis | 65 | 63.1% |
| Data analysis and mapping | 58 | 56.3% |
| Implementation and deployment support | 56 | 54.4% |
| Agile and backlog work | 47 | 45.6% |
| Controls and risk | 47 | 45.6% |
| User acceptance testing | 45 | 43.7% |
| Change and adoption support | 41 | 39.8% |
| System modeling | 36 | 35.0% |
| User stories and acceptance criteria | 31 | 30.1% |
| Root-cause analysis | 29 | 28.2% |
| Solution evaluation | 29 | 28.2% |
| Incident and problem analysis | 19 | 18.4% |
| Traceability | 17 | 16.5% |

Requirements analysis is the most frequent coded category, appearing in 94 vacancies (91.3%). Stakeholder discovery follows in 88 (85.4%). Together, these signals position the analyst as an investigator and translator before they position the analyst as a document producer. A professional method should begin by defining the work problem, the affected actors, the evidence available, the desired outcome, the system boundary and the decision authority.

Requirements are not simply requests copied into a list. The analyst must distinguish a stated preference from a validated need, an outcome from a feature, a constraint from a habit, and a business rule from an implementation choice. Stakeholder evidence also needs structure: who performs the work, who receives the outcome, who owns data, who operates interfaces, who accepts risk and who can approve a change.

The high frequencies do not show that every employer uses the same elicitation method. Interviews, workshops, observation, document analysis, process evidence, incident records and system data can all contribute. The educational implication is to teach selection and triangulation of discovery methods rather than one universal meeting script.

### 2. Process, testing and documentation form the central delivery spine

Process modeling appears in 80 vacancies (77.7%), testing or quality assurance in 79 (76.7%) and documentation in 75 (72.8%). This cluster suggests that systems analysis is advertised as a bridge from current work to validated change.

A process model helps locate triggers, activities, decisions, handoffs, queues, exceptions, controls, outputs and system interactions. It also exposes where a request may treat a symptom rather than a cause. A current-state model should be evidence-led; a future-state model should show intentional changes and unresolved assumptions. The course implication is to teach models as decision tools, not decoration.

Testing and quality assurance appear nearly as often as process modeling. This is important because requirements are only useful when they can be checked against delivered behavior. Analysts may contribute to test conditions, scenarios, cases, data needs, acceptance criteria, defect clarification, regression scope and business sign-off. They should understand the difference between confirming that a function was built, validating that it supports the work and deciding that residual risk is acceptable.

Documentation is broad. It can include requirements catalogues, functional specifications, process flows, business rules, models, decision records, test materials, user guidance and release notes. The evidence does not support teaching volume as quality. A useful document has a clear audience, purpose, owner, version, source, status and review rule. It should make an important decision easier to understand or verify.

### 3. Data and interfaces make the role technically consequential

Interface or integration analysis appears in 65 vacancies (63.1%), and data analysis or mapping appears in 58 (56.3%). These are majority signals in the accepted corpus. They distinguish the course from generic business-analysis training that stops at process workshops and user stories.

Data analysis in systems work is concerned with meaning and movement as well as numbers. An analyst may need to identify entities, fields, definitions, sources, owners, transformations, quality rules, reference data, retention constraints and reconciliation needs. A data map should expose semantic mismatches rather than conceal them. A field named `customer`, for example, may refer to different populations in different systems; a status code may represent a workflow step in one application and a commercial condition in another.

Interface analysis asks what crosses a boundary, why, when, in what format, under which rule and with what response when something fails. It includes upstream and downstream dependencies, triggers, timing, volumes, authentication or authorization assumptions, error handling, retries, reconciliation, observability and ownership. A learner need not design production infrastructure to ask these questions. The analyst's contribution is to make the behavior and business consequence reviewable by engineers, architects, testers and operational owners.

The evidence supports a technical-fluency outcome: learners should be able to read and create system context diagrams, data maps and interface specifications; ask precise questions about dependencies; and translate technical impacts into business terms. It does not support presenting the analyst as a substitute for software engineering, cybersecurity, privacy, data governance or architecture specialists.

### 4. Implementation, Agile delivery and controls connect analysis to accountable change

Implementation or deployment support appears in 56 vacancies (54.4%). Agile or backlog work appears in 47 (45.6%), as do controls and risk. Change and adoption support appears in 41 (39.8%). These signals show that many advertised analysts remain involved after initial requirements are drafted.

In iterative delivery, analysis is refined through evidence and feedback. Backlog items need enough context, rules and acceptance conditions to support a decision without freezing every design detail too early. Refinement should surface ambiguity, dependency, risk and readiness. The analyst may help split work while preserving end-to-end value, connect stories to process and data behavior, and maintain the rationale behind scope decisions.

Controls and risk are not limited to regulated industries. Access, approval, segregation, audit evidence, data quality, exception handling, financial integrity, service continuity and change authorization can matter in any organization. The analyst should identify where a process or solution relies on a control, who owns it, what evidence it produces and what happens if it fails. Jurisdiction-specific interpretation remains outside a general course and must be escalated to qualified owners.

Implementation and change support include readiness, migration dependencies, training, communication, business sign-off, cutover assumptions, post-release stabilization and benefit observation. A successful release is not the same as successful adoption. Systems analysis should preserve the link between the original problem, the selected solution, the validation evidence and the outcome observed after deployment.

### 5. Validation, solution choice and learning from failure remain material

User acceptance testing appears in 45 vacancies (43.7%). User stories and acceptance criteria appear in 31 (30.1%). Root-cause analysis and solution evaluation each appear in 29 (28.2%). Incident and problem analysis appears in 19 (18.4%), and traceability in 17 (16.5%).

These lower-frequency signals are professionally significant. User acceptance testing tests whether the delivered change can support representative work under defined conditions. Acceptance criteria make an expectation checkable but do not replace broader scenarios, data variation, exception paths or operational readiness. Traceability connects a need or rule to a design decision, delivery item and validation result. It is especially valuable when scope changes or when a defect raises the question of what was intended.

Solution evaluation protects the organization from treating the first suggested feature as the only option. A defensible comparison identifies criteria, constraints, assumptions, benefits, costs, risks, dependencies and evidence gaps. It also separates a recommendation from the authority to approve it.

Root-cause and incident analysis extend the work into live operations. A production symptom may reflect data, configuration, interface timing, process behavior, training, access, capacity or design. The analyst should distinguish containment from cause, and cause from corrective action. Low counts in deterministic text should not remove this capability from a practical course because the cost of weak problem framing can be high.

### 6. Advertised outputs favor reviewable working artifacts

| Coded output | Vacancies | Share of 103 |
|---|---:|---:|
| Process flow | 38 | 36.9% |
| Test plan or test case | 32 | 31.1% |
| Functional specification | 31 | 30.1% |
| User story and acceptance criteria | 29 | 28.2% |
| User-acceptance-testing plan or result | 28 | 27.2% |
| Data map | 23 | 22.3% |
| Training material or user guide | 13 | 12.6% |
| Issue or defect log | 11 | 10.7% |
| Traceability matrix | 11 | 10.7% |
| Backlog | 9 | 8.7% |
| Requirements document | 8 | 7.8% |
| Solution-options assessment | 6 | 5.8% |
| Interface specification | 6 | 5.8% |
| Gap analysis | 6 | 5.8% |
| Root-cause report | 5 | 4.9% |
| Impact assessment | 5 | 4.9% |
| Implementation plan | 3 | 2.9% |

Process flows are the most frequent named output, appearing in 38 vacancies (36.9%). Test plans or cases, functional specifications, user stories and acceptance criteria, user-acceptance-testing materials and data maps form the next cluster. This supports a course built around artifacts that can be inspected by a stakeholder, engineer, tester or operational owner.

Output counts are conservative phrase detections. A vacancy may require a capability without naming the artifact, and two employers may use different names for similar work. A low output count does not establish that the artifact lacks value. Conversely, a named document should not be taught as universally required in every project. The analyst should choose the smallest artifact set that makes the decision, handoff and validation reliable.

The relationships among outputs matter more than the count of documents. A process flow can expose a requirement; a data map can reveal an interface dependency; an acceptance criterion can drive a test condition; a traceability matrix can show whether the tested behavior covers the approved need; an issue log can trigger a root-cause analysis or backlog change. Teaching these relationships makes the artifacts a working system rather than a collection of templates.

## Curriculum implications

### Proposed professional outcome

The evidence supports the following observable outcome:

> Given a bounded business situation and incomplete but usable evidence, the learner can investigate the work system, define and validate requirements, model processes, data and interfaces, compare solution options, plan validation, and prepare an accountable recommendation and delivery handoff.

This outcome is intentionally broader than writing requirements and narrower than designing or building the entire technical solution. It keeps the analyst accountable for evidence quality, clarity, traceability and validation while respecting the authority of product, engineering, architecture, security, privacy, data, operations and business owners.

### Evidence-led four-part learning progression

#### Part 1: Investigate the work system

The first learning block should cover problem framing, system boundaries, stakeholders, work outcomes, discovery planning, evidence quality, current-state process analysis and scope. Learners should practice separating symptoms, causes, requests, constraints and decisions. Requirements and stakeholder findings justify substantial depth here.

#### Part 2: Specify processes, requirements, data and interfaces

The second block should turn evidence into process models, requirements, business rules, user stories, acceptance criteria, system context, data definitions, data maps and interface behavior. The majority signals for process, integration and data justify making these topics central rather than optional appendices.

#### Part 3: Evaluate options and control delivery

The third block should cover solution criteria, feasibility and trade-offs, gap and impact analysis, non-functional needs, controls, risk, prioritization, backlog readiness, change control and traceability. Learners should show why an option is recommended and what evidence or authority is still missing.

#### Part 4: Validate, implement and learn

The fourth block should connect acceptance criteria to test conditions, test cases and user acceptance testing; cover test data, defects and sign-off; address implementation and adoption readiness; and use incidents, root-cause analysis and post-release evidence to improve the system. Validation should be present throughout the course, not isolated as a final testing topic.

### Professional artifact set

The corpus supports at least the following reusable artifact families. Each artifact delivered in the course should include a purpose statement, a usable blank template, a realistic completed example, use instructions and a quality checklist.

1. Systems-analysis problem statement and outcome frame.
2. Stakeholder and decision-rights map.
3. Discovery plan and interview or workshop guide.
4. Evidence and assumptions register.
5. System context and boundary diagram.
6. Current-state process map.
7. Future-state process map with change annotations.
8. Requirements catalogue with source, rationale, priority and status.
9. Requirements quality review checklist.
10. Business-rules catalogue and decision table.
11. User stories or use cases with acceptance criteria.
12. Data dictionary and definition register.
13. Source-to-target data map.
14. Interface catalogue and behavior specification.
15. Solution-options and trade-off matrix.
16. Gap and impact assessment.
17. Requirements traceability matrix.
18. Test strategy with conditions, cases and data needs.
19. User-acceptance-testing plan, result and sign-off record.
20. Defect and issue log with triage decision.
21. Implementation and adoption readiness assessment.
22. Root-cause analysis and corrective-action brief.

The list is an evidence-led design inventory, not a requirement to produce 22 disconnected documents. The curriculum should combine or sequence artifacts when that improves professional realism, and it should not count the same artifact twice.

### AI-assisted practice

AI practice can be useful when it is bounded by evidence and verification. Appropriate exercises include structuring discovery notes supplied in the case, identifying ambiguous or unverifiable requirements, comparing two process descriptions, suggesting missing interface questions, drafting test conditions from approved requirements and checking whether an artifact covers specified quality criteria.

The learner should always provide the case, permitted inputs, constraints, desired artifact format and quality rules. They should inspect the output for invented stakeholders, unsupported requirements, hidden assumptions, missing exceptions, unsafe data use and false confidence. Sensitive employer, customer, employee, security or production information must not be placed into an unapproved tool. The human analyst remains responsible for the recommendation, escalation and decision record.

### Assessment implications

Assessment should use one connected case rather than unrelated mini-exercises. Formative tasks can build individual artifacts, but the final applied task should have one principal deliverable. A suitable capstone is a decision-ready Systems Analysis and Validation Brief for a proposed change. It can incorporate a concise problem frame, selected model, prioritized requirements, critical data and interface effects, option recommendation, validation approach and unresolved risks without requiring the learner to assemble every course template.

Quality should be judged through observable criteria: evidence traceability; clear system boundaries; testable requirements; consistent process, data and interface models; explicit assumptions; defensible option criteria; appropriate controls; validation coverage; readable communication; and accurate statement of decision authority.

## Practical application

### Connected case

A realistic course case could involve a mid-sized service organization replacing a fragmented request-intake workflow. Customers submit requests through multiple channels; staff re-enter data into a case application; finance and operations use different identifiers; a nightly interface sends incomplete status updates; managers cannot reliably explain delays; and the organization is considering a configurable workflow platform.

The analyst's task would be to define the work problem and boundary, identify stakeholders and evidence, map the current process, clarify the data and interface problems, specify requirements and business rules, compare solution options, define acceptance and test needs, and prepare an implementation-readiness recommendation. The case can include incomplete notes, conflicting stakeholder statements, sample records, interface errors and operational constraints. Learners must distinguish what is known, what is inferred and what must be verified.

### Decision sequence

An evidence-led working sequence is:

1. Frame the observable problem and desired work outcome.
2. Establish scope, system boundaries and decision authority.
3. Identify stakeholders, evidence sources and discovery methods.
4. Model the current process, including exceptions and controls.
5. Define and quality-check requirements and business rules.
6. Analyze data definitions, mappings and interface behavior.
7. Identify solution options and explicit comparison criteria.
8. Record impacts, dependencies, controls, assumptions and risks.
9. Connect approved needs to backlog or delivery-ready specifications.
10. Define test conditions, user-acceptance-testing evidence and sign-off.
11. Assess implementation, adoption and stabilization readiness.
12. Review live evidence, defects and incidents after change.

This sequence is not a rigid project lifecycle. Iteration is expected. New data or testing evidence may change the model, requirement, option or scope. What must remain stable is the discipline of making the source and consequence of a change visible.

### Quality questions for practice

A learner should be able to answer the following questions about their work:

- What observable problem is being addressed, and whose outcome matters?
- What is inside and outside the system boundary?
- Which stakeholders supplied evidence, and who owns the decision?
- Which requirements are verified needs, which are assumptions and which are solution choices?
- Do the process, requirement, data and interface artifacts agree with each other?
- What happens on exception paths, invalid data, interface delay or partial failure?
- How were solution criteria selected, and what trade-offs remain?
- Which controls or specialist reviews are required?
- How does each critical requirement connect to validation evidence?
- What would prevent safe implementation or credible adoption?
- What live evidence will show whether the change improved the work?

## Limitations

1. **Purposive rather than representative sampling.** The corpus was designed to find strong current evidence of systems-analysis work. It is not a probability sample and cannot estimate population prevalence.
2. **Discovery-row denominator.** The 511 rows are parseable search-result rows generated by 128 prompts, not all vacancies available online.
3. **Point-in-time currency.** The evidence was retrieved on 27 August 2026. Vacancy pages can change or close later.
4. **Freshness proxy.** Public crawl or publication signals no older than 180 days were used as a reproducible currency gate. They are not a guarantee that recruitment remains open after retrieval.
5. **Search-engine effects.** Index coverage, ranking, query wording, language, location and technical accessibility shape inclusion.
6. **English-language emphasis.** The prompt and coding frame emphasize English indexed evidence and under-represent other languages.
7. **Large jurisdiction gap.** Jurisdiction is not stated for 75 of 103 accepted records. The study therefore does not support geographic labour-market conclusions.
8. **Advertised work, not observed work.** Vacancy text describes a role before appointment. It does not prove actual tasks, authority, time allocation, tools or outcomes after appointment.
9. **Heterogeneous seniority and domains.** The corpus includes varied industries, platforms, enterprise functions and seniority levels. A shared tag does not mean identical complexity.
10. **Overlapping categories.** Coding is non-exclusive. Percentages cannot be added to represent a share of jobs or work time.
11. **Deterministic pattern sensitivity.** The codebook can miss synonyms, context and implicit expectations or group adjacent expressions. Lower counts can reflect language choice.
12. **Minimal extracts.** Retained excerpts are limited to 24 whitespace-delimited tokens. They preserve a necessary evidence trace but can omit page context.
13. **No independent reliability statistic.** The final corpus passed deterministic QA, but this report does not claim an inter-rater reliability coefficient.
14. **No causal inference.** Frequency does not show that a capability or artifact causes better project, service or organizational outcomes.
15. **No labour-market sizing.** The report does not estimate vacancy volume, growth, shortage or future openings.
16. **No compensation analysis.** Compensation was not consistently available and was not analyzed.
17. **No employment prediction.** The evidence does not predict application success, appointment, retention, promotion or salary.
18. **No universal method.** Employers use different delivery methods, tools and artifact names. The report supports transferable principles, not one compulsory template set.
19. **Regulatory and specialist boundaries.** A general course cannot replace legal, privacy, security, architecture, engineering, data-governance or sector-specific review.
20. **Rights boundary.** Public factual metadata and short necessary excerpts support analysis and traceability; they do not authorize republication of complete vacancy advertisements or proprietary expression.

## Rights basis and responsible reuse

The private research evidence record retains public factual metadata, direct source URLs, short necessary screening excerpts and original derived codes. The public archive excludes those excerpts. The report is an original aggregate synthesis. It does not reproduce complete vacancy bodies, page layouts, employer logos, images, proprietary templates or large portions of any advertisement.

The source pages remain the responsibility of their respective employers and publishers. Inclusion does not imply employer endorsement, partnership or validation of MTF Institute, the report or a future course. The coding converts limited public facts into an analytic framework; it does not convert employer advertisements into an occupational standard.

The archival public dataset omits every retained screening excerpt, stable internal row identity and private deduplication key. It includes only the direct source URL, employer or publisher label, publisher host, role title, explicit jurisdiction, retrieval date, freshness signal, availability evidence, derived tags, source family, rights classification and suitability basis. Full advertisements must not be redistributed.

The report must not be used to promise employment, recognition, licensure, accreditation, salary, promotion or employer acceptance. It is not legal, cybersecurity, privacy, engineering, architecture or regulated professional advice.

## Conclusion

The 103-vacancy corpus presents IT systems analysis as a connected professional practice. Requirements and stakeholder discovery define the entry point. Process models, documentation, data maps and interface analysis turn evidence into a shared description of the work system. Solution evaluation, controls, backlog practices and traceability support accountable decisions. Testing, user acceptance, implementation, adoption and incident learning carry the analysis into delivered and operating change.

The title distribution explains why the market often uses Business Systems Analyst even when the work is strongly technical. The evidence supports an IT Systems Analysis course that makes business requirements, processes, data, interfaces and solution validation explicit. It does not support reducing the role to generic meetings, document production or software testing alone.

A credible learning design should make learners produce reviewable artifacts and explain the relationships among them. It should also teach restraint: verify the evidence, identify the owner, distinguish a recommendation from approval, involve qualified specialists and preserve traceability when the situation changes.

This report is deliberately bounded. It describes patterns in a screened, public, English-language, point-in-time and purposive sample. Its contribution is a reproducible empirical base for curriculum design and independent review, not a claim about the whole labour market.

## References

1. MTF Institute. *IT Systems Analysis public vacancy evidence dataset*. `it-systems-analysis-vacancy-evidence-2026.csv`. 103 accepted unique public vacancy identities; short source excerpts and private row identities excluded.
2. MTF Institute. *IT Systems Analysis public aggregate coding summary*. `it-systems-analysis-coding-summary-2026.json`.
3. MTF Institute. *IT Systems Analysis public corpus QA summary*. `it-systems-analysis-corpus-qa-2026.json`.
4. MTF Institute. *IT Systems Analysis public methods appendix*. `it-systems-analysis-methods-2026.md`.
5. MTF Institute. *IT Systems Analysis public data dictionary*. `data-dictionary.md`.
6. MTF Institute. *IT Systems Analysis public archive manifest*. `it-systems-analysis-archive-manifest-2026.json`.
7. Cadence Design Systems. [Business Systems Analyst](https://cadence.wd1.myworkdayjobs.com/external_careers/job/SAN-JOSE/Business-Systems-Analyst_R53408-2). Direct public traceability example.
8. Amynta Group. [Business Systems Analyst — IT (Insurance Platforms)](https://amynta.wd5.myworkdayjobs.com/en-US/global/job/Business-System-Analyst_2510-0677). Direct public traceability example.
9. QBE. [Senior Professional Business Systems Analyst](https://qbe.wd3.myworkdayjobs.com/en-US/QBE-Careers/job/Senior-Professional-Business-Systems-Analyst_358043-1). Direct public traceability example.
10. Zayo. [Business Systems Analyst for Software Operations Delivery](https://zayo.wd1.myworkdayjobs.com/en-US/Zayo_Careers/job/Business-Systems-Analyst-for-Software-Operations-Delivery_R0016911). Direct public traceability example.
11. PlayCore. [Business Systems Analyst](https://www.indeed.com/viewjob?jk=0782b61cba92990a). Represented in the accepted public-job-board family.

The selected direct pages provide traceability examples only. Aggregate counts come from the complete accepted ledger, not from this short link list.

## Appendices and inventory

### Appendix A — Evidence package inventory

| File | Role | State at report drafting |
|---|---|---|
| `it-systems-analysis-vacancy-evidence-2026.csv` | Public 103-row evidence dataset without retained source excerpts or private row identities | Published in the Zenodo archive |
| `it-systems-analysis-coding-summary-2026.json` | Public aggregate code frequencies | Published in the Zenodo archive |
| `it-systems-analysis-corpus-qa-2026.json` | Public deterministic corpus QA summary | Published in the Zenodo archive |
| `it-systems-analysis-methods-2026.md` | Public collection, screening, coding and interpretation method | Published in the Zenodo archive |
| `data-dictionary.md` | Definitions for every public dataset field | Published in the Zenodo archive |
| `it-systems-analysis-archive-manifest-2026.json` | Relative filenames, roles, sizes and SHA-256 hashes | Created only after final files pass review |

### Appendix B — Public-ledger field inventory

The public ledger contains 14 fields:

1. `source_url`
2. `employer_or_publisher`
3. `publisher_host`
4. `role_title`
5. `jurisdiction`
6. `retrieval_date`
7. `freshness_signal`
8. `freshness_days_approx`
9. `availability_evidence`
10. `coded_skill_responsibility_tags`
11. `coded_output_tags`
12. `source_family`
13. `rights_classification`
14. `suitability_basis`

### Appendix C — Reproducibility checks

| Check | Observed | Required | Result |
|---|---:|---:|---|
| Accepted unique vacancies | 103 | At least 100 | PASS |
| Unique accepted URLs | 103 | 103 | PASS |
| Unique accepted deduplication keys | 103 | 103 | PASS |
| Query prompts preserved | 128 | Non-zero and reproducible | PASS |
| Parsed discovery rows | 511 | Exact ledger denominator | PASS |
| Repeated URL occurrences removed | 5 | Full trace | PASS |
| Accepted URL scheme | 103 HTTPS | HTTPS only | PASS |
| Accepted freshness | All no more than 180 days | All no more than 180 days | PASS |
| Required accepted fields | Non-empty | Non-empty | PASS |
| Excerpt maximum | 24 tokens | No more than 24 tokens | PASS |
| Core systems-analysis categories | At least two per row | At least two per row | PASS |
| Requirements or stakeholder evidence | Present in every row | Present in every row | PASS |
| Explicit closed signal in retained excerpt | 0 | 0 | PASS |

### Appendix D — Interpretation guard

All counts and percentages describe the 103 accepted vacancies in this purposive point-in-time corpus. They do not estimate population prevalence, task intensity, time allocation, causation, compensation, hiring probability, course outcomes or employer recognition. Categories overlap and must not be summed. An unstated field must remain unstated rather than being inferred.

### Appendix E — Published archival inventory

The verified Zenodo record contains the rendered and visually reviewed PDF; the rights-reviewed 103-row public vacancy dataset; the public coding and corpus-QA summaries; the data dictionary; the methods appendix; the archival checksum manifest; and the deposited metadata record. The public dataset excludes retained source excerpts, stable internal row identities and private deduplication keys.

The published version DOI is [10.5281/zenodo.22135110](https://doi.org/10.5281/zenodo.22135110), and the direct public PDF is [available from the Zenodo record](https://zenodo.org/records/22135110/files/it-systems-analysis-103-vacancies-research-2026.pdf?download=1).

---

**Interpretation guard:** This report describes a screened public sample. It does not define a worldwide occupational standard, prove employer demand beyond the sample, promise a professional outcome or replace organization-, sector- or jurisdiction-specific authority.

## Continue learning

The capabilities examined in this report are developed in MTF Institute's [IT Systems Analysis: Process, Data, Interfaces and Solution Validation](https://mtfinstitute.com/programs/it-systems-analysis-process-data-interfaces-solution-validation/#enroll) through structured learning and applied practice.



## Citation

When citing or summarizing this material, link to the canonical HTML page: https://mtfinstitute.com/insights/it-systems-analysis-103-vacancies-2026/