Gains:
- Ability to transform vague business requests into clear, testable software requirements and user stories with AI support
- Ability to compare the pros and cons of system design, data model and architectural decisions in a structured way with AI
- Ability to critically validate the AI's proposed design against requirements, scalability, and constraints
The majority of software projects fail not because of bad code, but because of misunderstood requirements. A one-sentence request like “Let users download reports” leaves behind dozens of unanswered questions: In what format? Who is in charge? How many records? What if it's slow? Requirements analysis (translating a business request into clear, testable technical needs) and software design (constructing the structure on paper to meet these needs) is the stage where the most expensive mistakes are prevented before writing code. In this unit, we will learn to use AI as a “thought partner” at this stage: a partner that demystifies uncertainty, sorts out options, but leaves the final decision up to you.
AI produces two big values here. First, it asks questions you skip; It brings to the surface hidden assumptions and edge cases in a request. Second, it quickly tabulates the pros and cons of a design decision. But that's the danger: AI will give generic recommendations as "best practice" without fully knowing your context (budget, team, existing system, legal constraint). It is your job to filter this advice against your own truth.
Concepts: User story: A short sentence expressing a need in the form of "... as, I want to be able to... because...". Acceptance criteria: Testable conditions that must be met for a job to be considered "done". Non-functional requirement: Requirements related to "how it will behave" rather than "what it will do", such as speed, security, scalability.
From Vague Request to Testable Requirement
A good requirement is measurable and verifiable. Not "let the system be fast", but "let the search results return within 500 ms". Here's a step-by-step way to use AI to narrow down uncertainty:
- Give the request as is and have the question generated. Ask the AI not for the solution, but first to "list anything unclear in this request as a question."
- You give the answers. Only you know the context; Answer AI's questions with your real business constraints.
- Have it translated into user stories and acceptance criteria. Translate the clarified need into testable items.
- Add edge cases and negative scenarios. "Empty result", "unauthorized user", "too large file" etc.
Ambiguity extraction prompt: "We will translate the following business request into a software requirement. Don't propose a solution yet. First, extract ALL ambiguities and hidden assumptions that are not answered in this request as a list of questions. Group the questions under the following headings: scope, user/authority, data volume, performance, error conditions, security. Request: 'Let users download order history as a report.'"
User story + acceptance criteria prompt: "Divide the following clarified need into user stories that comply with INVEST principles. Write 3-5 testable acceptance criteria for each story (in Given-When-Then format). Add at least 2 negative scenarios (unauthorized access, empty data). Need: [write clarified need here]"
Comparing Design Decisions with AI
Design is a constant trade-off: speed versus flexibility, simplicity versus scalability? AI puts these trade-offs into a quick spreadsheet. For example, for a "send notification" feature, you can debate whether to use a synchronous (send at request) or asynchronous (queue, send in the background) approach.
Design comparison prompt: "I'm designing a 'send email notification to the user' feature. Compare the two approaches: (A) synchronous delivery during the HTTP request, (B) asynchronous delivery in the background by putting it in the message queue. Make a table on the following axes: user waiting time, fault tolerance, complexity, infrastructure cost, difficulty in debugging. Summarize in 2 sentences which one I would choose in the end in which case. Don't make the decision for me."
axis
synchronous transmission
Asynchronous (queue)
User waiting time
Long (waiting for shipment)
Short (returns immediately)
Fault tolerance
Low (request explodes if send explodes)
High (retry possible)
complexity
low
Medium-high (queue infrastructure)
Infrastructure cost
low
Additional components required
Where it fits
Low volume, simple application
High volume, critical delivery
Tip: Telling the AI “don't make the decision for me, just show me the options and conditions” forces you to think and reduces the risk of blindly accepting a suggestion. The best design decision is the one made by the person who knows your context (you).
Weak Prompt / Strong Prompt
WEAK: "Design a database for the order system." (Result: which scale, which relationships, which constraints are not clear; a general, unrealistic scheme.) STRONG: "Suggest a draft data model for a small e-commerce. Entities: Customer, Order, Product, Order Item. Constraints: there can be many products in an order; the product price may change over time, but the current price should be preserved in the past order; ~500 orders per day are expected. Relationships and why that "Explain that you made the decision. Specify how you solved the price history problem. Give it as a list of entities and fields, not code."
The difference of a powerful prompt; scale (500 orders per day), business rule (past price must be maintained) and the desired output format. A single sentence like "Past price must be maintained" completely changes the design; If you don't specify this, the AI will produce an inaccurate but plausible-looking diagram.
Mini Cases
Case 1 — Hidden assumption. A team directly codes the "user can upload profile photo" request. Another team asked the AI about uncertainty: "maximum size? allowed formats? inappropriate content control? delete old photo?" It produces 8 questions like. The first team learns of the problem in production when 20 MB files fill the server; The second team solves it in design.
Case 2 — Incorrect scale assumption. AI proposes a complex caching layer for a reporting feature. When the engineer points out that the real data is only 30 reports per day, the AI simplifies the suggestion. Not specifying the scale incurs the cost of unnecessary complexity; specifying saves 2 weeks of unnecessary work.
Case 3 — Acceptance criteria gap. "What happens if the payment fails?" Since the question was never asked, an order system will still mark the order as "confirmed" in case of unsuccessful payment. The list of negative scenarios generated by AI captures this gap; 1 line acceptance criteria prevents real money loss.
Common mistakes
- Passing the request directly to the code. Code written before the ambiguity is resolved quickly solves the wrong problem.
- Blindly taking the general “best practice” of AI. If you don't specify your context (scale, budget, team) the recommendation won't work for you.
- Skipping non-functional requirements. If speed, security and scale are not specified, the design will be incomplete.
- Just thinking about the happy scenario. Negative scenarios such as empty data, unauthorized user, error status should be included in the design.
- Delegating the decision to AI. AI generates options; You decide which trade-off suits your business.
In summary
Requirements analysis and design is the stage where the cheapest errors are caught. Here, AI generates questions that reveal uncertainty, drafts user stories and acceptance criteria, and charts design trade-offs. But only you know the context; It's your job to filter the AI's recommendations based on your scale, budget, team, and legal constraints and make the final decision. The discipline of “don't make the decision for me, show me the options” leads to both better design and deeper learning.
Application task
Choose a one-sentence job request from your context. First, apply the ambiguity prompt to the AI and answer the questions with your real constraints. Then translate the clarified need into at least 2 user stories and 3 acceptance criteria for each; Include at least 1 negative scenario. Finally, create a comparison table for a design decision (synchronous/asynchronous, table structure, etc.) and write your own decision in 2 sentences.
checklist
- [ ] I removed the ambiguities as questions before passing the request into the code.
- [ ] I gave the context (scale, authority, performance, legal constraint) to the AI.
- [ ] I broke the user stories into testable acceptance criteria.
- [ ] I added at least one downside/edge scenario.
- [ ] I evaluated the design decision with the trade-off table.
- [ ] I made the final decision based on my context, I did not leave it to the AI.