Get told when a verified record lands on this occupation → · Mark which of these tasks are yours (VOLO Pro, free during the launch) →
Business analyst
Works out what a business actually needs from a change or a system and writes it down so it can be built and checked: interviews stakeholders, maps processes, writes requirements and user stories, runs workshops, and checks at acceptance that what was delivered does what was asked. Language models now draft requirement documents and user stories, and US federal agencies use AI to generate them; studies find the drafts quick but in need of validation, and the interviews that surface unspoken needs still need people.
Draft one set of user stories with a language model from your own notes, and record what you had to correct before a developer could use them.
This is not a probability of losing your job. It combines how much of the role's task load is exposed to automation with how far adoption has actually gone — useful for comparing occupations on one consistent basis, and for nothing else.
Written for business analysts who elicit and document requirements for business and IT change — in-house, in consultancies and in agile teams. Data analysts, product managers, management consultants and the owners of business systems have their own pages. The evidence is two US federal agencies' own inventory entries, a company pilot, two research evaluations of language models on requirements work and US labour projections for the occupations that include business analysts; it establishes what tools draft and where they are in use, not how analysts' time has changed.
What is actually changing#
The unit of analysis is the task, not the job title. A role is not replaced — its task mix shifts.
Each tile is one task. Its size is how much of the job it is; its colour is where the task is heading. Click a tile to see what the judgement does not establish.
Simulated interviews with students as stakeholders; nothing here measures real projects or analysts' hours.
Inventory entries describe systems, not their effect on staff; the studies use a university project, one consulting project and a small pilot.
An inference from how the work is described; no primary source recorded here measures process-mapping work or tools' share of it.
The projections cover wider occupations that include consultants and systems analysts, and count jobs rather than tasks.
No primary source recorded here measures acceptance or change-management work; it is an inference.
Is this your job? Say so and this page narrows to your share of it.
A job title is a bundle of tasks bought together, and no two people hold the same bundle. Nothing is sent anywhere — it stays in this browser.
Read all 5 tasks in full — direction, reasoning and limits →
Recent changes#
United States. The statistics bureau projects that employment of management analysts will grow 10 percent from 2025 to 2035, much faster than the average, with about 94,100 openings a year. O*NET lists business analyst among the job titles reported for this occupation, which also includes management consultants; the page itself does not mention business analysts or AI. It counts jobs, not tasks.
A named person with standing publicly predicted something, on a date, in an attributable statement. It is recorded so that who said what, and when, stays checkable — and it never moves a task's assessment, because a prediction is not an observation. Its value arrives later: the record sits on the same page as the evidence about that occupation, so anyone reading the forecast reads the record of what happened next beside it. That is the reckoning; this site publishes no verdict on whether a forecast came true.
United States. The statistics bureau projects that employment of computer systems analysts will grow 8 percent from 2025 to 2035, much faster than the average, from 544,400 to 587,200, with about 32,900 openings a year, and says that as organisations continue to rely on and expand IT, including artificial intelligence, computer systems analysts will be hired to design and install new systems. O*NET files IT business analyst among this occupation's job titles. It counts jobs, not tasks.
A named person with standing publicly predicted something, on a date, in an attributable statement. It is recorded so that who said what, and when, stays checkable — and it never moves a task's assessment, because a prediction is not an observation. Its value arrives later: the record sits on the same page as the evidence about that occupation, so anyone reading the forecast reads the record of what happened next beside it. That is the reckoning; this site publishes no verdict on whether a forecast came true.
United States, Veterans Health Administration. The agency's inventory entry, marked deployed and developed in-house, says its human-centered design team uses large language models and custom agents, and that the system streamlines tasks such as analysing user feedback, generating user stories, summarising workshop outcomes and refining user personas, with faster insights and less manual labour for staff. It is the agency describing its own system; it does not report effects on staffing or the quality of the stories.
An employer has put it into production. Can move the baseline — weighted by scale and how similar the setting is.
One project at an IT consulting company, where language models generated functional design specifications and user stories from elicitation summaries and templates, assessed by the company's expert analyst. The analyst estimated drafting time savings of 10% to 15%; some user stories stayed unaddressed across all models because knowledge owned by analysts can be tacit and absent from the elicitation documents; and the authors conclude that the models can enhance early documentation but cannot replace human intervention, with expert analysts still needed for accuracy and completeness.
Small-scale trial in a real setting. Tells us the deployment conditions are being tested, not that they hold — so one pilot is never enough on its own; two independent ones are.
An academic chatbot evaluated in 33 simulated stakeholder interviews, with students playing stakeholders. It made a similar number of common mistakes as a human interviewer and elicited up to 73.7% of all requirements. The authors write that human-led interviews are still valuable and necessary for highly sensitive or complex elicitation, where interpersonal dynamics play a crucial role in uncovering unspoken requirements.
A demo, benchmark or paper shows the task can be done. Updates what the technology can do — not what employers will do.
United States, Social Security Administration. The inventory entry, marked deployed with an operational date of 1 October 2024 and a purchased vendor platform, says the generative component accelerates legacy modernisation by automatically analysing COBOL and other legacy code, generating consistent business requirements documentation and refactoring code into modern languages, which reduces manual effort for document creation. It recovers requirements from existing code rather than eliciting them from people.
An employer has put it into production. Can move the baseline — weighted by scale and how similar the setting is.
A study comparing GPT-4 and CodeLlama with human benchmarks in drafting a requirements specification for a university student-club management portal, graded on eight criteria. It reports that the models can match the output quality of an entry-level software engineer, and that human documents took 4 to 24 hours once the requirements were specified while the model drafts took 7 to 47 times less time, though they were hard to get right the first time. The requirements were given, not elicited.
A demo, benchmark or paper shows the task can be done. Updates what the technology can do — not what employers will do.
Austria, the IT division of a postal group. Researchers and company staff implemented an autonomous LLM-based agent system to improve user story quality and evaluated it with 11 participants across six agile teams. The paper says the system's outputs currently require manual validation by the product owner to align with project goals and stakeholder expectations, and six survey participants found the rewritten descriptions too long. It is a small pilot at one company.
Small-scale trial in a real setting. Tells us the deployment conditions are being tested, not that they hold — so one pilot is never enough on its own; two independent ones are.
What this means for you#
If you are starting out, expect language models to draft requirement documents and user stories faster than you can type them, and expect your value to lie in what they cannot do: getting the real need out of people, noticing what was left unsaid, and checking the draft against it.
Expect less time writing and more time eliciting, negotiating and validating. The analysts in demand will be those who can run the hard conversations and judge whether a machine-drafted specification is right.
Your options#
Four directions, each with its real constraints and one thing you can test this week. Continuing as you are is a legitimate choice — it just has to be a chosen one.
Stay, and move your time from writing to eliciting and validating
Drafting is where tools are strongest; the research recorded here still leaves interviews on sensitive matters and validation with people.
Teams may expect more output per analyst once drafting is faster.
Draft one set of user stories with a language model from your own notes, and record what you had to correct before a developer could use them.
Move towards process and change work
Getting departments to agree and people to adopt a new way of working is negotiation that tools summarise but do not do.
Change roles are judged on adoption, which is slower and harder to show than delivered documents.
Pick one process you documented and find out whether people actually work that way now.
Move into product management
Deciding what to build and why sits next to the analyst's work and depends on the same judgement about what people need.
Product roles carry ownership of outcomes and are fewer than analyst roles.
Ask a product manager you work with which of their decisions last month relied on your requirements.
Common questions#
Not on present evidence. Language models draft requirement documents and user stories, and US federal agencies use AI to generate them, but the studies recorded here still have people validate the drafts and lead interviews on sensitive or complex needs, and US projections expect the occupations that include business analysts to grow.
We do not answer that with a number of years. A signal to watch instead: whether machine-drafted requirements start going to developers without an analyst validating them, and whether interview bots are trusted with complex, sensitive elicitation. Neither is what the evidence shows today.
It can draft them. A study found GPT-4 drafts of a requirements specification comparable to an entry-level engineer's and 7 to 47 times faster once requirements were specified; at a postal group's IT teams, an agent's improved user stories still needed the product owner to validate them.
US projections expect management analysts to grow 10 percent and computer systems analysts 8 percent from 2025 to 2035; both include business analysts. The work is shifting from writing documents towards eliciting, negotiating and validating.
What these judgements rest on#
1 of 5 task judgements on this page are backed by a verified event and 4 are platform inference, each labelled where it appears. Behind them sit 2 technology dimensions, a reconstructed trajectory since language models reached the public, and 8 verified events.
See which technologies, how it got here, and the method →
Where it sits in the official classification: skills, knowledge, related jobs →
Other roles in the same function#
A company divides its work into functions before it divides it into jobs. These sit in Technology & data alongside this one — a fact about org charts, not a judgement that they are similar or that they are changing in the same direction.
Junior software developer · Experienced software engineer · Frontend developer · Backend developer · Data engineer · Machine learning engineer · AI researcher · Software tester / QA engineer · Data analyst · Data scientist · Business systems owner · IT support specialist / helpdesk · Security analyst (SOC) · DevOps / platform / SRE engineer · Network engineer · Technical writer / documentation engineer
