Requirement Model Co-builder?

I have worked in automotive R&D and systems engineering for about 15 years, across software development, systems architecture, product management, project management and requirements analysis, and have long participated in cross-team, cross-company and international project collaboration.

Through these experiences, I have grown increasingly aware that many R&D problems — on the surface development problems, testing problems or project-management problems — when traced back, are often related to requirements not being truly clarified.

A customer may provide a feature list, or several versions of requirement documents. HMI designs may contain new feature requests, and meetings and daily communication keep producing new decisions. Different information is scattered across documents, spreadsheets, images, emails and chat logs, and is often missing, contradictory or vaguely expressed.

Everyone discusses the same feature, but the model in their heads may be completely different

What makes it harder is that every participant understands the requirement based on their own experience.

The customer cares about the final experience, product cares about feature completeness, the systems engineer cares about boundaries and coordination, the software engineer cares about interfaces and implementation conditions, and the test engineer cares about exception scenarios and acceptance criteria. Everyone discusses the same feature, but the models formed in their heads may be completely different.

When the meeting ends, everyone may feel they understood. Only during development, integration or testing do the real problems surface: this condition was never defined, that exception scenario was never considered, the responsibility boundary of this module was understood differently by the two sides. So the team has to re-discuss, revise the design, rework development, or even renegotiate with the customer.

Complex requirements cannot rely on a single text document, nor be explained clearly in a single meeting. Requirements need to be co-built.

A vague requirement first needs professional analysis to be broken into goals, roles, flows, states, interactions, conditions, exceptions and boundaries. What is already clear needs to be expressed clearly; content inferred from experience cannot be treated as fact; and missing information needs to be turned into specific, answerable confirmation questions.

Diagrams are not decoration, but a model everyone can observe and modify together

Visual diagrams are very important in this process. A passage of text may produce different understandings in different people, but once flows, states and module interactions are drawn, many problems surface immediately. Diagrams are not to make the document look prettier, but to build a model everyone can observe, discuss and modify together.

But ordinary drawing tools cannot solve this either. They usually require the user to have already figured out what to draw. Users must create nodes, connections and layout themselves. Even if AI can quickly generate a diagram from text, it often just completes “text-to-diagram” without truly analyzing whether the requirement is complete, nor telling the user which content is explicitly stated in the original text, which is inferred by the system, and which still needs confirmation from both requirement sides.

This is exactly why I built the Requirement Model Co-builder

I hope it is not a tool that replaces engineers' thinking, but one that helps both requirement sides think and communicate better.

Users can input a vague requirement, an Excel list or a requirement screenshot. The system first performs professional requirement analysis, identifying features, flows, states and interaction relationships, while discovering missing information and generating confirmation questions. Then the system turns the current understanding into a visual model.

Both requirement sides can continuously clarify based on these questions and diagrams. Each answer updates the model; confirmed content gradually grows, and parts still vague stay as pending questions. Eventually, the initially scattered and vague description can gradually form a clearer, reviewable, traceable engineering requirement and diagram model.

This tool also embeds the professional understanding I accumulated over 15 years in automotive R&D and systems engineering. It cares not only about the normal flow, but also about exception paths, boundary conditions, state transitions, module responsibilities and verification methods. These are exactly what complex engineering requirements most easily miss, and most easily cause later rework.

AI does not make the final judgment, but can help us see problems earlier

I do not believe AI can replace customers, product managers, systems engineers or R&D teams in making final judgments. Whether a requirement is correct still needs to be confirmed by people who truly understand the business and the product.

What AI is better suited for is the other part of the work: helping us quickly organize information, build models, find gaps, raise questions, and promptly settle each clarification.

Let both requirement sides, before development truly begins, form a shared understanding of what they are co-building.

If it can make a requirement review more effective, let an important condition be discovered earlier, and let a rework that would otherwise happen be avoided, then this tool has produced real value.

Currently, this product is still in an early invite-only trial stage. I will continue validating with real but sanitized engineering scenarios, and I also hope to hear feedback from systems engineers, product managers, R&D engineers, test engineers and project managers.

It should not come only from my experience, but should be co-built by users in more real requirement scenarios.