There is a persistent conversation happening in the business analysis community about whether requirements documents are dead. The people who say yes point to agile practices, AI-generated code, and the acceleration of build cycles. The people who say no point to every enterprise project that went sideways because nobody wrote anything down.
Both groups are missing the more interesting question, which is not whether requirements work still matters but where it has moved and what it looks like now.
The short answer: requirements work has migrated, and looks different for different levels of detail. It is more continuous and less phase-based. It’s based on assets and structured knowledge AI has access to. It’s constantly evolving and the details are in sync with the actual code (production and dev environments). The process, collaboration, and how we think about requirements has changed.
Why the Old Model Made Sense
To understand where requirements work has moved, it helps to understand why the traditional model existed in the first place.
When software development was expensive and slow, the cost of discovering a misunderstanding late in a project was enormous. If a team spent six months building something based on a wrong assumption about what the user needed, the rework cost was catastrophic. Requirements documents were a hedge against that risk. Get everything defined upfront, get it approved, and then build to spec. The document was the contract that protected everyone.
The model made sense in that environment. It was a rational response to the economics of software development at the time.
What Changed
The economics changed. Building software got faster and cheaper. Iteration became possible and then standard. The cost of a wrong assumption early in a project dropped dramatically when you could test it with a prototype in two weeks instead of six months.
The neuroscience of engagement is clear: business teams prefer interacting with prototypes over static text and diagrams. A skilled facilitator who can generate prototypes on the fly, and pivoting as the conversation evolves is far more effective. This approach engages stakeholders, accelerates progress, and uncovers the real problem faster.
The requirements practices at many organizations have not fully kept pace. Some teams moved to agile practices but retained heavyweight documentation habits. Others swung too far in the other direction, abandoning structured analysis entirely in the name of speed.
Now AI is accelerating the change again. Code generation tools mean that a working prototype can be generated in requirements conversation. The window between idea and testable artifact is collapsing. The traditional requirements phase, where analysis work was batched and documented before any building began, is increasingly misaligned with the pace of development.
Many call out “compliance” as the reason for heavy documentation, ignoring that AI can reverse engineer the documentation after the prototype and subsequent system is built. The reasons and excuses for “documentation” as the process are falling apart. Those that keep making excuses are being seen as irrelevant. Those that use dynamic assets and lightweight AI generated “documentation”, and AI rapid prototypes as decision making and conversation tools are seeing huge benefits.
Where Requirements Work Went
It went continuous and in parallel to development. The most valuable requirements work now happens continuously and in parallel to development, not as a handoff document to developers. Its the deep thinking that shapes the problem definition, while we work through key scenarios in a prototype. What are we actually trying to solve? Who will use this? What does success look like? What are the boundaries of what we are building? What are the risks that will surface if we get this wrong? These questions and conversations while co-creating together, with multiple “skill lenses” are critical. Skill lenses include business architecture, business analysis, process, customer experience, user experience, data, development cyber security, and testing lenses.
This work is more collaborative and less document-centric than the old model. It involves stakeholders, developers, and BAs working together to build shared understanding, not a BA working alone to produce a spec for others to review.
As AI takes over more of the build process, the analytical work that matters is increasingly about evaluation, not documentation. When AI generates code or content or decisions, a human still needs to determine whether what was generated is correct, complete, appropriate, and aligned with the business intent. That evaluation work requires the same analytical thinking that requirements work has always required. It requires structures thinking and structures analysis practices and techniques.
In an environment where builds happen in days rather than months and where requirements can be tested and refined quickly, the analytical work does not stop at a gate. It runs alongside development, iterating as learning accumulates.
What the New Requirements Work Looks Like
The artifacts have changed more than the thinking. Instead of a 50-page requirements document, you might see a concise problem definition, a working prototype, a set of acceptance criteria or scenarios with expected results, written in plain language, a prototype brief, or an AI prompt specification that defines what good output looks like for a given task. All of these co-created with AI as a thinking partner of course and pointed at the organizational assets to help AI get the context right.
The skills are the same: elicitation, analysis, synthesis, communication. The format has adapted to the environment.
One of the most important shifts is toward outcome-based requirements. Rather than specifying exactly how something should work, outcome-based requirements describe what the system needs to achieve and let the development team, including AI tools, figure out the how. This requires more trust in the build team and more clarity about the intended outcome. It is a harder kind of requirements work to do well, and it is where a lot of organizations are struggling.
Another significant shift is toward requirements that explicitly address AI behavior. When an AI system is part of the solution, requirements need to specify not just what the system does but how it handles uncertainty, what its error behavior looks like, what information it needs to make good decisions, and what the oversight model is for its outputs. This is a new category of requirements work that most BAs were not trained for and that most requirements methods do not address well.
The Risk of Abandoning Structure
Here is the tension worth naming: the acceleration of build cycles and the availability of AI development tools has led some teams to abandon structured requirements work entirely. Move fast, build something, see what happens.
This works sometimes, for small, low-stakes, easily reversible things. It does not work for the complex, high-stakes enterprise systems that most BAs are involved in. When an organization deploys an AI system without clearly defined requirements for how it handles edge cases, who oversees its decisions, and what good output looks like, they are creating risk they may not see until it surfaces in production.
The requirements work did not go away. For high-stakes work, it became more important. It just needs to happen faster, in a more continuous, structured and collaborative way, and with a more sophisticated understanding of what AI systems need in order to be specified well.
What This Means for BAs
The BAs who thrive in this environment are the ones who have updated their mental model of what requirements work is for. It is not documentation. It is a shared understanding. It is a risk reduction. It is the thinking that makes the build work worth doing. The risk has moved, from high cost coding cycles, to missing structured context.
That thinking can be expressed in a document. It can also be expressed in a conversation, a prototype, a set of acceptance criteria, or a collaborative session with a development team. The form follows the need.
What does not change is the rigor. The careful thinking about what the problem is, who is affected, what success looks like, what the risks are, and what the boundaries are. That work is as valuable as it has ever been. In many environments, it is more valuable because the cost of getting it wrong has not gone down just because the cost of building has.
If you want to develop a current, practical approach to requirements work in an AI environment, my 5 new AI/BA (live online, interactive, instructor led) courses cover exactly this. We work through how requirements practices are evolving, what the new artifacts look like, and how to do the analytical thinking that makes AI-assisted development actually work. Find more info at maven.com/angela-wick.