AI Can Draft Software Requirements. Can It Understand Your System?

AI is very good at making a software idea sound more complete than it really is.

Give a language model a rough feature request and it can turn it into user stories, acceptance criteria, technical recommendations, database changes, API requirements, and a tidy implementation plan. In a few minutes, an informal idea can start to look like a well-scoped software project.

That can be genuinely useful. It can also create a new problem: a requirement can sound technically convincing without being grounded in how the software actually works.

If the AI hasn’t seen the codebase, data model, integrations, architecture, existing functionality, user workflows, or history behind the system, it’s working from an incomplete picture. Language models can produce plausible but unsupported information when they don’t have enough evidence, a behavior NIST refers to as “confabulation” and OpenAI describes as hallucination. (NIST)

For software teams, that means AI can be a useful participant in requirements gathering, but it shouldn’t become the source of truth.

The source of truth is still the business, the users, and the software itself.

Can AI be used for software requirements gathering?

Yes. AI can help teams organize stakeholder input, summarize documentation, identify questions, draft user stories, compare alternatives, and turn an early idea into something concrete enough to discuss.

Research into requirements engineering has found promising uses for LLMs in elicitation and specification, and Art+Logic itself notes that LLMs can help digest and simplify requirements documents. (arXiv) (arXiv)

The important distinction is between drafting a requirement and validating one.

An AI-generated requirement should be treated as a hypothesis about what the software needs, not as proof that the requirement is necessary, correctly scoped, or technically appropriate.

That distinction matters most when the AI is discussing an existing application, because mature software already contains decisions that may not be visible in the prompt.

Why can AI-generated requirements sound right when they aren’t?

Language models are designed to produce coherent responses from the information available to them. When important context is missing, the resulting answer can still be detailed, organized, and persuasive, even though some of its assumptions aren’t grounded in the real system. NIST specifically identifies confidently stated false or erroneous content as a risk of generative AI. (NIST)

That creates an unusual requirements problem.

Imagine someone asks an AI tool:

"We need to build a custom notification system so customers can receive real-time status updates.""

The AI might propose a notification service, new database tables, message queues, preferences management, delivery tracking, and several API endpoints.

All of that could be technically reasonable, but it could also be unnecessary.

Perhaps the application already uses a third-party service that supports most of the requested functionality. Maybe status updates already exist but aren’t exposed in the current interface. Perhaps the real problem is that one integration is delayed, so adding a notification platform would simply make incorrect information arrive faster.

The AI hasn’t necessarily made a bad technical recommendation. It has answered the question it was given without knowing enough about the system behind the question.

That is why polished technical language shouldn’t be confused with discovery.

A feature request and a software requirement aren’t the same thing

Clients and users usually describe software in terms of the solution they can imagine:

“We need a dashboard.”

“We need an AI assistant.”

“We need another API.”

“We need to rebuild this module.”

Those requests matter because they tell the development team where someone is experiencing friction. However, good software discovery still has to determine what problem sits underneath the proposed solution.

A request for a dashboard may really be a reporting problem. A proposed AI agent may actually be a workflow-integration problem. A request to rebuild a module may come from one recurring defect that could be addressed much more narrowly.

This is one reason Art+Logic’s design process begins with discovery and research around business goals, users, features, functionality, and measures of success rather than immediately treating the first proposed solution as the specification. (Art+Logic)

AI can make the initial idea easier to explore, but it shouldn’t remove that step.

In fact, because AI can produce a detailed solution so quickly, the discovery step becomes even more important. Otherwise, a team can spend considerable effort implementing a very sophisticated answer to the wrong question.

The codebase is part of the requirements

For an existing product, some requirements are written in project plans and tickets, while others are encoded in the application itself.

A particular calculation may contain an exception because of a long-standing customer agreement. A database field that looks obsolete may still feed a report used elsewhere in the organization. An odd-looking workflow may exist because the system has to accommodate an external integration that was never documented properly.

None of those things necessarily appear in a conversational description of the feature.

That means the development team needs to compare the requested change with what the system actually does.

Repository-level software engineering research reflects the importance of this broader context: solving realistic maintenance tasks requires understanding code across files, architecture, and repository structure rather than reasoning about a small isolated snippet. (arXiv)

AI tools can help with that work. They can search a codebase, trace references, summarize modules, identify related tests, and surface places where a proposed change might have an effect. But someone still needs to decide what those findings mean.

The code can show that an exception exists. It can’t always tell you whether the exception is still required.

That answer may require the product owner, an operations employee, a long-time user, or someone who understands the customer relationship behind it.

Good requirements are grounded in several kinds of evidence

There usually isn’t one perfect source for a software requirement.

The clearest picture comes from comparing several sources:

• What stakeholders say the business needs
• How users actually perform the work
• What the existing application currently does
• What the data shows about real usage
• Which integrations and external systems are involved
• What existing tests say should remain true
• Which security, regulatory, or contractual constraints apply
• What the organization is trying to accomplish after the change

This is where experienced software developers add value that goes well beyond implementation.

They can look at a proposed requirement and ask whether the capability already exists, whether the suggested approach fits the architecture, whether it creates unnecessary complexity, and whether a smaller change could accomplish the same business result.

Those questions can save more time than generating the code faster.

AI should help discovery ask better questions

The safest way to use AI during requirements gathering isn’t to ask it to decide what should be built. It’s to use it to make the discovery process more thorough.

For example, after reviewing appropriate project materials, an AI tool might help generate questions such as:

• Which existing workflows could this feature affect?
• Does the system already contain similar functionality?
• Which users need this capability, and which users shouldn’t have access?
• What happens when the underlying data is incomplete?
• Which external systems does the workflow depend on?
• Are there existing business rules that could conflict with the proposed behavior?
• What would make the feature unsuccessful even if it works technically?
• How will we know the change improved the business process?

That is a much healthier role for AI.

Instead of using confidence as a substitute for context, the tool helps the team identify context that still needs to be gathered.

Requirements should describe the outcome before prescribing the implementation

One simple way to reduce ungrounded scope is to separate the desired outcome from the proposed technical solution.

Instead of:

“Build a new event-processing service and add a real-time notification API.”

start with:

“Customers need to know when an order changes status without contacting support.”

Now the development team can investigate the actual system.

Perhaps the right answer is a new service and API. Perhaps it’s a small change to an existing integration, a webhook that already exists but isn’t being used, or a better interface around information the application already has.

This distinction also makes software projects easier to measure.

The success criterion isn’t whether the team built the requested architecture. It’s whether customers receive accurate status information with less friction.

That outcome-oriented framing fits Art+Logic’s broader custom software approach, which emphasizes software tailored to an organization’s specific processes, security requirements, users, and changing business needs. (Art+Logic)

Legacy modernization makes grounding even more important

The gap between plausible requirements and real system behavior becomes particularly important during legacy modernization.

Long-lived applications often contain years of operational knowledge that isn’t fully documented. Business rules may be distributed across source code, database procedures, integrations, configuration files, reports, tests, and manual workarounds.

A prompt that says, “Convert this application to a modern framework” doesn’t contain that history.

Art+Logic has encountered this problem directly. In one healthcare modernization project, earlier attempts at broad AI-driven conversion produced software that compiled while removing or disabling important application functionality. Art+Logic instead used a phased approach in which AI accelerated repetitive implementation work while developers remained responsible for architecture, review, testing, and validation. (Art+Logic)

That experience points to a broader modernization principle: before deciding how to rebuild something, the team needs to understand what it actually does.

AI can be very useful during that discovery. Art+Logic uses AI-assisted analysis to help identify patterns, map dependencies, and generate documentation for legacy systems that may no longer be well understood, while experienced engineers determine what should be preserved, changed, or removed. (Art+Logic)

The distinction matters because modernization isn’t a transcription exercise.

A strange piece of code may be obsolete technical debt, or it may encode a business rule that still matters. An unused-looking integration may truly be ready for retirement, or it may run once a month for an important customer. A workflow may deserve redesign rather than exact reproduction.

AI can help expose those questions much faster, but domain experts and developers still have to answer them.

The best requirement may be “don’t build it”

One of the most valuable results of software discovery is discovering that a requested feature doesn’t need to be built.

Perhaps an existing capability can be extended. Maybe the problem belongs in another system. A commercial service may already solve it adequately, or a small process change may create more value than a custom feature.

This can be difficult to see when an AI tool has already generated an impressive implementation plan.

The specificity of the plan creates momentum. Once there are tables, endpoints, milestones, and acceptance criteria, the proposed solution starts to feel inevitable. It isn’t.

A good development partner should still be willing to ask whether the project needs that complexity in the first place.

Art+Logic’s modernization framework makes a similar point with legacy software: retain, retire, rehost or replatform, refactor or rearchitect, and rebuild or replace are all legitimate options, depending on the business need and the condition of the system. Rebuilding isn’t automatically the most modern or responsible answer. (Art+Logic)

The same principle applies to feature development. Sometimes, the best technical decision is to write less software.

How should teams use AI for project scoping?

A useful AI-assisted discovery process keeps AI inside an evidence loop.

First, define the business problem in plain language and identify what outcome would make the project worthwhile. Then gather the relevant source material: existing documentation, representative workflows, code, integrations, data definitions, user feedback, and technical constraints.

AI can help summarize and connect those materials, but its output should lead to questions rather than immediately becoming scope.

From there, developers and domain experts can validate the assumptions together. They can confirm whether proposed functionality already exists, identify edge cases, determine which parts of the system are affected, and decide whether the technical approach fits the larger architecture.

Only after that work should the team turn the result into implementation-ready requirements and acceptance criteria.

The process isn’t slower because people are involved. It’s designed to avoid accelerating the wrong work.

Where Art+Logic fits

Art+Logic builds and modernizes custom software for organizations whose requirements don’t fit neatly into off-the-shelf products. Our work includes AI software development, legacy modernization, complex web and cloud applications, UX and product design, integrations, and the recovery of software that needs experienced engineering before it can move forward reliably. (Art+Logic)

That makes requirements discovery especially important.

A client brings knowledge about its customers, operations, industry, and goals, while Art+Logic’s developers and designers investigate how those needs intersect with the software that already exists.

AI can make that investigation faster by helping teams navigate code, summarize material, surface dependencies, and explore alternatives. It can also make requirements easier to communicate and refine.

What it can’t do on its own is decide which assumptions are true.

That still requires a development process grounded in the actual system and the people who depend on it.

Convincing isn’t the same as correct

AI is going to become increasingly useful throughout software development, including the part that happens before anyone starts writing code.

That’s a good thing. Requirements gathering has always involved large amounts of information, ambiguity, iteration, and documentation, so there are plenty of places where AI can help.

The risk appears when polished output creates more confidence than the available evidence supports.

A ten-page specification produced in minutes can still be based on the wrong assumptions. A detailed technical plan can solve functionality the application already has. A plausible recommendation can ignore a business rule that never made it into the prompt.

The answer isn’t to stop using AI for requirements.

It’s to ground the AI in the same evidence good software teams have always needed: the real system, the real workflow, the real users, and the business outcome the project is supposed to create.

Because the goal isn’t to produce requirements faster, it’s to build the right thing.

FAQs

Can AI be used for software requirements gathering?

Yes. AI can help summarize stakeholder input, organize documentation, draft user stories, identify questions, and explore possible requirements. Its output should still be validated against the actual software, user workflows, business rules, and technical constraints.

Why can AI-generated software requirements be wrong?

AI works from the context it receives and can produce plausible but unsupported information when important context is missing. A requirement may therefore sound technically reasonable while duplicating existing functionality, conflicting with the architecture, or overlooking an important business rule.

Should AI-generated requirements be treated as project scope?

Not without review. AI-generated requirements are more useful as a starting point for discovery. Developers, domain experts, and stakeholders should validate whether the requirement is necessary, accurate, technically appropriate, and connected to a measurable business outcome.

How can AI improve software discovery?

AI can help developers search and summarize large amounts of information, identify related code, map dependencies, draft documentation, organize stakeholder feedback, and surface questions that need further investigation. These capabilities can accelerate discovery without replacing human validation.

Why is codebase context important when defining software requirements?

Existing applications contain functionality, dependencies, business rules, and historical decisions that may not appear in written requirements. Reviewing the codebase helps teams determine whether a proposed feature already exists, which components it affects, and what behavior needs to be preserved.

How can AI help with legacy modernization requirements?

AI can help analyze large legacy codebases, map dependencies, summarize behavior, generate documentation, and identify patterns that may need migration. Developers and domain experts still need to determine which behavior is important, which technical debt can be removed, and which business rules must survive modernization.

Can AI reduce software project scope?

Potentially. By helping teams investigate existing functionality and alternatives, AI can surface cases where a requested feature may be unnecessary or where a smaller change could solve the underlying problem. The final scope decision should still be based on verified system and business context.

What is the role of a software developer when AI can generate requirements?

Developers help determine whether proposed requirements match the actual architecture, data, integrations, security model, existing functionality, and business needs. They turn stakeholder goals into technically grounded requirements and identify where a proposed solution may create unnecessary complexity.