AI-Assisted Requirements Engineering
What happens when AI can understand the requirement, the documentation, the backlog and the code? This experiment explores AI as a bridge between Product and Engineering — using an organisation’s own knowledge to turn an idea into a development-ready set of requirements.
The challenge
A Product Owner can start with a perfectly reasonable feature idea, but the information needed to make it development-ready is often spread across product documentation, the backlog, the codebase and the knowledge held by different people. The result can be missed edge cases, unanswered questions and delivery plans that are harder to break into manageable iterations.
The experiment
I connected OpenCode to JIRA, Confluence, GitHub and the filesystem through MCP. The Product Owner uses the workflow before handing requirements to developers. Rather than asking AI simply to write user stories, the experiment gives it access to the context needed to challenge and enrich the requirement.
What it produces
The workflow can help produce:
- User stories
- Acceptance criteria
- Risks and questions
- Gaps and missing requirements
- Testing considerations
- Manageable delivery iterations
The workflow
Product idea → Product Owner → OpenCode + AI → JIRA / Confluence / GitHub / Filesystem → contextual analysis → requirements, risks, gaps, questions, testing approach and delivery iterations → development team.
A real example: Right to Work
The Product Owner started with a feature to check whether a person was eligible to work in a particular country based on their residence status. By working with the codebase and the available Confluence documentation, the AI found important exceptions and edge cases, including further rules involving a wider set of documents.
The result was a much more comprehensive customer feature than the initial requirement suggested. The Product Owner was also able to break the work into manageable delivery iterations.
The result was a much more comprehensive customer feature than the initial requirement suggested. The Product Owner was also able to break the work into manageable delivery iterations.
Who benefited?
The experiment sits between several roles: Product Owner, QA, developers and Delivery Manager. The observed benefits were more systematic and comprehensive requirements, greater confidence for the Product Owner, clearer requirements for developers and more manageable delivery iterations.
What surprised me
The interesting part isn’t that AI can write a user story. It’s that it can connect information that normally lives in different places and use that context to expose things the Product Owner may not have considered.
What I learned
AI productivity isn’t just about making developers write code faster. There is a large opportunity to reduce the friction between the people who have to build, test and deliver software.
For me, this is a particularly interesting role for AI: not replacing Product or Engineering judgement, but helping people work with a much larger body of organisational context.
For me, this is a particularly interesting role for AI: not replacing Product or Engineering judgement, but helping people work with a much larger body of organisational context.
The bigger engineering question
What happens when AI becomes part of the organisation’s knowledge flow rather than another isolated tool? Requirements engineering is one small example. The same pattern could extend across architecture, testing, support and continuous improvement — anywhere useful context is distributed across people, systems and documentation.
Technology
OpenCode · MCP · JIRA · Confluence · GitHub · Filesystem · Multiple AI models
What I’d explore next
The next step would be to explore how the same context-aware approach can support architecture decisions, test design, support knowledge and continuous-improvement work — while keeping human ownership of the decisions that matter.