祝融说。

Toss a sentence like "I need an order management system" at AI, and 30 seconds later it gives you a plan with 15 tables and 23 APIs. The problem is -- the workflow it guessed might be completely different from your company's actual process.

You are building an equipment borrowing management system. The product manager throws you one sentence: "Build a borrowing request feature." You open your AI tool and repeat this sentence. AI takes 30 seconds and generates a plan with 5 database tables and 12 API endpoints. You look at the plan and feel something is off -- but you cannot quite put your finger on it. You let it continue coding anyway.

Two weeks later, the feature is done. You demo it to the business department. They take one look and say: "No, that is not how our process works."

You realize that AI assumed the process was "Request -> Approve -> Check Out -> Return," but your company's actual process is "Request -> Pick Up -> Use -> Return -> Inspect." And "pick up" and "check out" are two completely different actions -- picking up is the employee taking equipment from the warehouse, while checking out is the warehouse manager recording the equipment's departure. AI treated them as if they were the same thing.

The problem started at step one. You threw a vague requirement at AI. AI cannot read minds -- it can only "guess" the most likely implementation from its training data. And guessing is the most expensive thing in engineering.

2.1 Why Requirements Analysis Is the First Step

Most AI coding failures do not stem from "AI cannot write code," but from "AI built the wrong feature."

You describe a requirement, AI understands one version, and you had a different version in your head. By the time AI produces the code, you realize it is not what you wanted. The cost of reworking at this stage is far higher than getting it right upfront.

The root cause is: Requirements in the human mind are vague, but code must be precise.

When you say "build a borrowing request feature," your mind holds a complete business context -- who can borrow, what they can borrow, how long they can borrow it for, when borrowing is allowed and when it is not. But when this sentence reaches AI, all that context is lost. AI can only "guess" the most likely implementation from its massive training data. And the "borrowing request" in its training data could be library book borrowing, tool room equipment borrowing, or enterprise fixed asset borrowing -- these three systems are vastly different.

You might think: "No problem, I will fix it after AI builds it." But there is a hidden cost here: fixing a requirement during the coding phase costs more than 10 times what it costs during the requirements analysis phase. Fixing during coding means rewriting code, re-running tests, and re-doing acceptance. Fixing during requirements analysis means changing a single line of text.

Requirements Analysis solves this problem -- it transforms the vague ideas in your head into a structured document that both humans and AI can understand precisely. Its core output is not code -- it is a "precisely aligned description that both sides agree on."

2.2 Core Methods of Requirements Analysis

From One Sentence to a Table

Suppose the user says: "I want to build an order management system."

This sentence is far too vague for AI. AI might interpret it as:

• An e-commerce order management system (with logistics, refunds, reviews)
• A restaurant order management system (with tables, dishes, kitchen printing)
• An enterprise procurement order management system (with approvals, reconciliation, payments)

These three systems are vastly different. Starting to code without requirements analysis almost guarantees rework.

Requirements analysis turns that one sentence into a table:

Using Event Storming

Event Storming is a method for understanding business through "events." The name sounds technical, but the core idea is simple: Use language that business people understand -- first describe "what happened," then derive "what needs to be done."

The traditional approach is the "feature list method." The analyst asks business people: "What features do you want the system to have?" Business people answer: "Borrowing management, equipment management, personnel management." The analyst takes this list and designs the system. This method has a fundamental flaw: a feature list is a product of the technical perspective, not the business perspective. Business people do not really care about the "borrowing management" module -- they care about "what happens after an employee submits a borrowing request." When you throw "borrowing management" at AI as a feature, it does not know whether your process is "approve first, then check out" or "pick up first, then register." It can only guess a generic default process.

Event Storming changes the question. Instead of asking "what features does the system need," it asks "what events happen in the business." This shift in questioning moves the conversation from "technical solutions" to "business processes."

Let us walk through a complete example of Event Storming.

Suppose you are building an equipment borrowing management system. You gather the business team for a requirements discussion. Instead of asking "what features does the system need," you ask: "From the moment an employee borrows equipment to when it is returned, what happens along the way?"

The business team would say:

Employee submits request -> Supervisor approves -> Warehouse checks out equipment -> Employee picks up equipment -> Employee is using it -> Employee returns equipment -> Warehouse inspects equipment condition -> Equipment is checked back in

These are "business events." Notice that events are described in the past tense -- "submitted," "approved," "checked out" -- because events are things that have already happened, not things that will happen.

From these events, you can derive Commands -- who triggered each event? The "submit request" event was triggered by an "employee," so the command is "submit borrowing request." The "approve" event was triggered by a "supervisor," so the command is "approve request."

Continuing the derivation, you get Aggregates -- what core data do these events and commands operate on? Borrowing requests, equipment, employees, warehouse records -- these are all aggregates.

Finally, you can identify Bounded Contexts -- which events and aggregates belong to the same business domain? Borrowing requests and approvals belong to the "Borrowing Management" context. Equipment check-out and check-in belong to the "Inventory Management" context. Employee information belongs to the "Personnel Management" context.

Let us compare the results. Using the traditional feature list method, you would get:

Feature List:
1. Borrowing Management: request, approve, query
2. Equipment Management: add, edit, delete, query
3. Personnel Management: add, edit, delete

Using Event Storming, you would get:

Business Event Flow:
Employee submits request -> Supervisor approves -> Equipment checked out -> Employee picks up -> In use -> Return -> Inspect -> Check in

Bounded Contexts:
1. Borrowing Management Context: request, approval
2. Inventory Management Context: check-out, check-in, inspection
3. Personnel Management Context: employee information maintenance

See the difference? The feature list tells you "what modules the system has." The event flow tells you "how the system works." The latter naturally includes the dependency relationships in the business process -- you cannot build the check-in feature before the request feature, because check-in happens after the request. This dependency is explicit in the event flow but invisible in the feature list.

Event Storming has a hidden benefit: it aligns business people around "events," not "technical solutions." Business people may not understand "databases," "APIs," or "bounded contexts," but they definitely know the difference between "an employee submitting a request" and "a warehouse checking out equipment." When you say "let us list the business events," business people can participate without any barriers. When you say "let us design the database tables," business people fall silent.

This is why Event Storming is the core method for requirements analysis -- it describes business in the language of business, not the language of technology.

2.3 Requirements Analysis Outputs

After completing requirements analysis, you should produce two documents:

REQUIREMENTS.md

Contains:

1. Project Overview -- One sentence describing what the project does
2. User Roles -- Who uses the system, what each role can do
3. Feature List -- Prioritized list of features
4. Business Events -- Event flow of core business processes
5. Data Entities -- Preliminary core data model
6. Constraints -- Technical constraints, time constraints, compliance requirements

Disagreement Records

In the requirements analysis process, there is one often-overlooked but extremely important output: disagreement records.

Requirements analysis is about "making decisions." But most people only focus on "what was ultimately decided" and ignore "what was abandoned." Why is recording what was abandoned important? Because every abandoned option represents a trade-off -- and someday in the future, when the project environment changes, that trade-off may need to be revisited.

Let us look at a real example.

In a project's MVP phase, the product manager requested support for "partial refunds." After discussion, the team decided not to include it in the first release, but recorded the disagreement:

Disagreement 1: Should partial refunds be supported?
    Decision: Not supported in the first release.
    Reason: The MVP phase needs to control scope. Partial refunds involve
    complex amount splitting logic and additional integration work with
    the payment gateway.
    Impact Scope: Order state machine, refund flow, financial reports.
    Recorded: 2025-03-15

Six months later, as the business grew rapidly, users started frequently requesting partial refunds. The team opened the disagreement record and immediately understood why it was not done originally, what the impact scope was, and what needed to be done to support it. They started designing directly from this record, avoiding repeated discussions and re-exploration of the same ground.

Without this record, what would have happened? A new developer seeing the current state of "partial refunds not supported" might assume it was "forgotten" rather than "intentionally excluded." They might spend a lot of time debating "should we do it" -- when that debate had already happened six months ago.

The core value of disagreement records is: allowing "past decision rationale" to travel through time and provide context for future decisions.

The format does not need to be complex. The key information is three things: what the disagreement was, what was decided, and why. The format is as follows:

Disagreement N: [Question description]
    Decision: [Final choice]
    Reason: [Why this choice was made]
    Impact Scope: [Which modules this decision affects]
    Recorded: [YYYY-MM-DD]

Record the key disagreements and decisions identified during the requirements analysis process:

Disagreement 1: Should the order status include "Cancelled"?
    Decision: Yes. Users can cancel an order at any status (except "Completed").
    Reason: The business side requires flexible cancellation.

Disagreement 2: Should partial refunds be supported?
    Decision: Not supported in the first release, recorded in the "future versions" list.
    Reason: The MVP phase needs to control scope.

2.4 Practice: How to Use AI for Requirements Analysis

You can use the Requirements Analysis skill to do requirements analysis:

Help me analyze the requirements for this system.

Project: An internal equipment borrowing management system.

Known information:
- Employees can borrow equipment
- Borrowing records need to be logged
- Equipment must be returned on time
- Administrators can view all borrowing records

AI will guide you through confirming requirements step by step, ultimately producing REQUIREMENTS.md.

Key techniques:

1. Provide a reference point: If you have experience with similar systems, use it as a reference for AI

   Similar system: Library management system. But the difference is that
   equipment needs to be inspected after return.
   

2. Define boundaries clearly: Tell AI what is "in this release" and what is "for later"

   Not in the first release: reservation feature, equipment maintenance workflow,
   automatic reminders.
   

3. Ask for examples: Have AI provide specific sample data

   Please provide a complete borrowing flow example with all data fields.
   

2.5 Common Requirements Analysis Mistakes

Mistake 1: Over-abstraction

"Build a generic workflow engine that supports all kinds of business scenarios."

This is the most common trap in requirements analysis. Generic equals vague. AI cannot design what you want for "generic."

Correct approach: Start with a specific scenario, then abstract into a generic solution. "First build an approval workflow for leave requests, then we will see if we can abstract it into a generic engine."

Mistake 2: Feature pile-up

"This system needs: order management, user management, product management, inventory management, financial management, reporting, push notifications, permission management..."

When the feature list exceeds 10 items, the focus of requirements analysis should shift from "adding features" to "setting priorities."

Correct approach: Distinguish between MVP (Minimum Viable Product) and subsequent releases. "First release only: order management + user management. Other features will be added in subsequent releases."

Mistake 3: Ignoring non-functional requirements

"A system handling 1,000 orders per day vs. 1 million orders per day requires completely different technical architectures."

Non-functional requirements (performance, security, availability, scalability) directly impact architecture design. If you do not specify them, AI might choose a solution that does not fit your scale.

Correct approach: Define non-functional requirements during the requirements analysis phase. "Data volume: about 100 orders per day, total data volume not exceeding 100,000 records. High concurrency is not needed. But data security requirements are high because financial information is involved."

Chapter Summary

Requirements analysis is the process of turning "a one-sentence requirement" into "precise structured instructions that AI can execute." Its core method, Event Storming, starts from business events, aligns business people using language they are familiar with, and naturally derives commands, aggregates, and bounded contexts. The outputs are REQUIREMENTS.md and disagreement records -- the former tells AI "what to do," and the latter preserves "why it was done this way" for the future. Remember: one extra hour spent on requirements analysis can save ten hours during the coding phase. In the next chapter, we will discuss how to transform these requirements into an executable architectural blueprint.