Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
BDD in .NET: Binding Gherkin Scenarios to the Bookstore API with Reqnroll 3
SpecFlow reached end of life on December 31, 2024; the current way to run Gherkin scenarios in .NET is Reqnroll 3, with the Reqnroll.xunit.v3 package for xUnit v3. We bind Bookstore's institutional order scenarios to the API on .NET 10: project setup, step definitions, context injection, WebApplicationFactory, a diagnostic hook for failures, living documentation with the HTML formatter and filtering by tag, plus a pitfall observed under Turkish culture.
Executable Specifications with Gherkin: Given-When-Then, Rule, Scenario Outline and Writing Declarative Scenarios
Gherkin turns the rules and examples found in Example Mapping into a specification that stakeholders can read and a test runner can execute; a good scenario describes the business rule, not the UI. Using Bookstore's institutional order rules, we cover Feature, Rule, Background, Scenario Outline, Examples and data tables, declarative versus imperative scenarios, the Turkish keyword decision and Gherkin anti-patterns.
Non-Functional Requirements: The ISO/IEC 25010:2023 Quality Model, Making Them Measurable and Where to Record Them
A non-functional requirement states what quality a behaviour must have, and it only works when written with its environment, measure and owner. We cover the nine characteristics of ISO/IEC 25010:2023 and what changed since 2011, turning "make it fast" into a scenario built from data and measurement, accessibility (WCAG 2.2), KVKK, audit and security requirements for institutional orders, and where to record them: acceptance criteria, the Definition of Done, ADRs or fitness functions.
Acceptance Criteria and Example Mapping: Clarifying Rules with Examples
Acceptance criteria are a story's conditions of acceptance, and they work best when every rule has concrete examples under it. Using Bookstore's institutional discount and partial shipment cards, we cover rule-based and scenario-based criteria, how they differ from the Definition of Done and Definition of Ready, a four-colour Example Mapping session, and deciding at the end whether a story is ready, should be split or needs investigation.
Story Mapping and Splitting Stories: Walking Skeleton, Vertical Slices and Choosing the First Release
A story map arranges stories left to right by the user's flow and top to bottom by priority, exposing the gaps a flat backlog hides and anchoring the first release on an end-to-end walking skeleton. We draw Bookstore's institutional order map, choose the skeleton and release slices, split large stories by rules, data, exceptions, workflow steps, manual-first and spikes, and explain why splitting by layer is a bad idea.
From Use Cases to User Stories: The 3Cs, INVEST and When Use Cases Are Still Better
A use case is the map showing the whole and its branches, while a user story is a unit of delivery from that map that gives value on its own; not every alternative flow has to become a story. We split Bookstore's institutional order use case into seven stories and acceptance conditions, covering Jeffries' card-conversation-confirmation trio, the limits of the "As a / I want / so that" template, the INVEST check, epics versus stories versus tasks, and when use cases are still better.
Requirements Elicitation: Uncovering the Real Need with Interviews, Observation, Workshops and Prototypes
Elicitation is not gathering requirements that already exist; it is uncovering unspoken needs with interviews, observation, document analysis, workshops and prototypes, then confirming them with stakeholders. For Bookstore's bulk orders from schools and libraries we build a stakeholder map, run a "tell me about the last time" interview, observe customer service, surface conflicts in a workshop, test a one-day Angular prototype, and produce a glossary and an open questions list.
What Is a Requirement and Why Is It Misunderstood? Types, Qualities of a Good Requirement and Separating Problem from Solution
A requirement is not a screen but a statement of a need together with its constraints and conditions. Using Bookstore's bulk ordering feature for schools and libraries, we cover business, stakeholder, functional, non-functional, constraint and transition levels, the qualities of a good requirement in ISO/IEC/IEEE 29148, hunting vague words, and finding the problem behind a solution sentence like "an Excel upload screen".
Communicating Estimates and When the Plan Slips: Updating, Delivering Bad News Early and Replanning
When a plan slips, the first move is to deliver the bad news right away together with options; choosing between cutting scope, moving the date or adding people is a business decision, and adding people to a late project rarely saves the date. Bookstore's update after three sprints shows scope grew to 142 points and the full scope slipped to March 26; we compute the options in C# and write a one-page estimate note.
Risk Management in Software Projects: Pre-Mortem, Risk Register, Probability × Impact and Retiring Risk Early
Managing risk means surfacing it early with a pre-mortem, comparing probability × impact with the buffer and putting the riskiest work at the start of the plan. In Bookstore's Institutional Orders register, total exposure is 21.6 days, more than the scope buffer; an ERP spike and pair work bring it down to 4.9 days in three sprints. We cover ROAM, risk burndown and risk vs issue with C# code.
Release Planning: Velocity Ranges, Burn-Up, Fixed Date or Fixed Scope?
A release date comes not from one average velocity but from a range derived from past sprints; if the date is fixed, scope flexes in MoSCoW layers. Bookstore's 130-point Institutional Orders plan lands between February 12 and March 12, and the Must scope fits by March 1 even in the bad case. We also answer the same question with Monte Carlo and see why the two methods disagree.
Estimation Beyond Points: Three-Point/PERT, Wideband Delphi, Work Breakdown and Reference Class Forecasting
To estimate uncertain work, break it down, give each piece three points, simulate the total instead of adding numbers up, and check the result from the outside against how similar past work drifted. For Bookstore's bulk order slice, a C# simulation shows the sum of most likely durations (21 days) holds only 3.1% of the time, the 85% value is 28 days, and the figure corrected with past epics is 34 days.