Gains:
- Ability to distinguish functional and non-functional requirements and write clear, measurable requirement expressions with the support of artificial intelligence
- Ability to use artificial intelligence with structured prompts to extract user story, acceptance criteria and scope limit from interview notes
- Getting into the habit of checking AI-generated requirements for ambiguity, contradiction, and missing rules and confirming them with stakeholders
Requirements analysis is the task of defining in a complete, clear and verifiable way what a system should do. It is one of the stages where the MIS specialist produces the most value; because a mistake here grows exponentially at the end of the project. There are two basic types of requirements analysis. The functional requirement describes the job the system should do: “The system should email the customer when it confirms the order.” Non-functional requirement describes how the system should be: qualities such as performance, security, usability and accessibility. "The report screen should open in less than 2 seconds at average load" is a non-functional requirement.
A good requirement has three characteristics: it is clear (it has a single interpretation), it is measurable (it has a testable threshold), and it is traceable (it is clear what business need it comes from). "The system must be fast" meets none of these; “fast” is subjective, cannot be measured, cannot be tested. At this stage, AI is a powerful aid in drafting requirements and catching ambiguous wording; but only the stakeholder decides which business rule is real.
User Story and Acceptance Criteria
A common format in modern requirements writing is the user story: "As a [role], for [purpose], I want [feature]." Example: "As a sales representative, I want discount calculation from the mobile screen so that I can make quick quotes in the field." The story is short and business-oriented; It does not impose a technical solution.
Every story should have acceptance criteria: testable conditions that must be met for the story to be considered "ok". A frequently used pattern is the "Given/When/Then" pattern: "Given: the customer is in the VIP segment. When: orders over 10,000 TL. Then: the system applies a 5% discount." This pattern eliminates ambiguity because it clearly connects the condition and the expected outcome.
Tip: When writing a user story to the artificial intelligence, be sure to say "generate at least 2 acceptance criteria in the Given/When/Then format for each story." When the model is forced to produce benchmarks, hidden gaps in the requirement become visible.
Step by Step: AI-Assisted Requirements Extraction
Step 1 — Collect raw input. Call logs, emails, existing screenshots, complaint lists. The more real input, the less fabrication.
Step 2 — Extract the first set of stories. Give raw input to artificial intelligence and have it produce user story drafts. This step is not a complete list, but a first step.
Step 3 — Add acceptance criteria. Generate Given/When/Then criteria for each story. A story for which criteria cannot be produced actually means that it is not sufficiently defined.
Step 4 — Scanning for contradictions and gaps. Ask AI “are there any contradictions, duplications, or undefined situations between these requirements?” Ask and have it checked. Filter the result as a human.
Step 5 — Prioritize and confirm. Prioritize stories with stakeholders based on business value and urgency. The priority decision belongs to the business unit, not the AI.
Don't Forget Non-Functional Requirements
Most of the projects have difficulties in the field because they forget the non-functional ones while writing the functional requirements. A report may work “correctly,” but if it takes 45 seconds to open, no one will use it. The following table shows commonly overlooked non-functional requirement types and measurable writing examples.
Genre
bad expression
measurable expression
Performance
"Must be fast"
"Query response < 2 sec at average load"
accessibility
"Everyone should be able to use it"
"WCAG 2.1 AA compliant; full keyboard navigation"
Security
"It should be safe"
"Personal data is encrypted at rest; access is role-based"
availability
"Should be easy"
"New user completes the order in 3 steps without training"
Availability/continuity
"Shouldn't crash"
"Monthly uptime ≥ 99.5%"
Three Mini Cases: By the Numbers
Case 1 — The price of an unmeasurable need. The screen, which was developed in a bank with the requirement that "the report screen should open quickly", opened in 22 seconds under field load. The developer thought he was providing the word "fast" in his environment (2 seconds). If the requirement had been written as "< 3 sec at peak hour, actual throughput", the problem would have been caught in testing. The redevelopment cost 3 weeks and measurable additional cost.
Case 2 — Gap captured by acceptance criteria. While writing the acceptance criteria for the "system applies discount" story in an e-commerce project, the stakeholder noticed that what would happen if the discount conflicted with the coupon and VIP discount was not discussed at all. A single Given/When/Then question prevented the double discount error before go-live; This error caused serious revenue loss in similar projects.
Case 3 — AI-made rule. In an HR project, AI added the sentence “leave request is automatically approved within 24 hours” to the requirements draft. No such automatic approval was discussed in the meeting; The model had made up a rule that seemed “reasonable.” Next to each requirement, the expert writes “source: which interview/document?” By adding the column, he removed 4 unsourced sentences.
Weak Prompt / Strong Prompt
Weak prompt:
Write user stories for this project.
Powerful prompt:
Your role: You are an MIS business analyst.Extract user stories from the interview note below.Rules:- Format: “As a [role], for [purpose], I want [feature].”- Write AT LEAST 2 acceptance criteria for each story in Given/When/Then format.- Add a “Source” column next to each story: which sentence did it come from?- Label [UNCERTAIN] any rule that is not clear in the note; fitting.- Write measurable non-functional requirements (performance, security, accessibility) in a separate section. Interview note:[text]
Powerful prompt enforces story format, acceptance criteria, source traceability and non-functional requirements all at once; This makes it easier to control the output.
Four Copiable Templates
1) Requirements clarification:
Review the requirement below. Mark each statement that is vague, incommensurable, or open to more than one interpretation and write a clarifying question for each. Don't make up the answer. Requirement: [text]
2) Contradiction scanning:
In the list of requirements below, find items that contradict each other, are repetitive, or leave logical gaps. Report each finding with item numbers and a one-sentence justification. List: [text]
3) Generating acceptance criteria:
Write at least 4 acceptance criteria for the following user story in Given/When/Then format, including limit and exception cases. Also list any points that remain unclear. Story: [text]
4) Scope outline:
Draft the "In Scope" and "Out of Scope" items as a two-column table according to the following requirements. Label [CONFIRMATION REQUIRED] for any item you are unsure of. Requirements: [text]
Common mistakes
- Thinking the solution is a need. "Add a dropdown menu" is a solution, not a requirement. The requirement says "the user must be able to select the country from the defined list"; The IT team designs the solution.
- Skipping non-functional ones. Simply writing down “what to do” and forgetting “how to be” (speed, security, accessibility) is the most common and most expensive loophole.
- Using immeasurable adjectives. Words like "fast, easy, safe, user-friendly" are invalid without a threshold.
- Not noticing the rule that the AI has made up. The model may add “reasonable” but not actually spoken rules; Ask for resources for every need.
- Leaving the prioritization to AI. What to do first is a business value decision; The business unit gives this.
Caution: The most dangerous sentence in requirements analysis is "everyone already knows this". Unspoken assumptions do not make it into the documentation, never make it into the code, and emerge in the field. Ask AI “what is assumed but not written in this requirement?” makes these hidden assumptions visible.
In summary
Requirements analysis defines what the system should do in a clear, measurable and traceable way. Functional requirements describe the job, non-functional requirements describe the qualities, and the latter is often forgotten. User story and Given/When/Then acceptance criteria are powerful tools that eliminate uncertainty. Artificial intelligence significantly accelerates the production of storyboards, acceptance criteria, conflict detection and clarifying questions; However, the correctness of the business rule, scope and priority decision, and the source of each sentence are the responsibility of the human. Do not finalize any requirement that is unsourced and immeasurable.
Application task
Write a one-paragraph business request for an imaginary “online appointment system” (e.g., “Clients should be able to make appointments online, staff should be able to see calendars”). (1) Create at least 5 user stories and 2 acceptance criteria for each with a strong prompt from this request. (2) Find at least 2 hidden gaps in the criteria produced by the model (e.g. double appointment at the same time, cancellation rule). (3) Include at least 3 non-functional requirements in a measurable form. (4) Identify at least 3 items as "Out of Scope". (5) Mark a rule that the model might have made up and write how you would confirm it.
checklist
- [ ] I wrote functional and non-functional requirements separately.
- [ ] Every requirement is clear, measurable and testable.
- [ ] Each story has Given/When/Then acceptance criteria.
- [ ] I can trace the source (conversation/document) of each requirement.
- [ ] I marked the possible rules that the AI had made up and left them for confirmation.
- [ ] I did the prioritization together with the business unit.