This course contains the use of artificial intelligence.

Nobody can tell you what they want. They can tell you what they currently do, what annoys them about it, and what they saw somewhere else and liked.

Turning that into something a team can build is the entire job, and it is not a documentation job.

Why specifications fall apart

The requirement was written down exactly as it was said, which means it captured a proposed solution rather than the problem behind it. The acceptance criteria say "the system should be user-friendly", which cannot be tested and therefore cannot be finished. Two stakeholders wanted opposite things and both were recorded, so the conflict was postponed to delivery, where it costs ten times more. And a change request arrives, gets accepted because refusing feels obstructive, and the timeline moves by an amount nobody calculated.

What the course teaches

Thirty-four lessons organised by how requirements are actually obtained. Framing first: telling a symptom from a problem, the Problem, Goal, Constraint, Metric structure, user stories with acceptance criteria in Given-When-Then form, the BRD and SRS, and the definition of ready. Plus AS-IS and TO-BE modelling, where the gap between the two is your requirement set, and impact analysis for the change requests that arrive later.

Then elicitation in three modes, because each one surfaces different information. One to one: structured interviewing, STAR questions applied to how work is done today, active listening as a technique, and comparing what different people told you when they disagree.

Workshops, surveys and modelling

Then the group workshop: preparing it, deciding who is in the room, running it without the loudest voice winning, prioritising as a group with conflicting needs, and closing with a list and named owners rather than a set of notes.

Then in writing, at scale: survey types, question wording and how it biases the answer, scale choice, the length at which quality collapses, the report, and turning responses into a plan. Then process modelling: methodology, BPMN, tools, and running a description project from concept through defending it with management.

And finally validation. Six lessons on critical thinking, because a requirement is an assertion about the future and most of them are wrong in ways you can detect early. Strong reasoning against weak, anchoring, confirmation bias, verifying what a stakeholder told you, and deciding when the information is incomplete.

Who is teaching this

Mike, the number one HR instructor on Udemy. More than 1.6 million course enrolments, over 150,000 professionals trained, PHRi and SHRM-CP certified, HRCI representative in more than 10 countries. I built the people function of the unicorn Preply and worked at Wargaming, Alfa-Bank and iDeals. I have specified systems that were built exactly as written and turned out to solve the wrong problem, which is the most instructive way to learn this.

What is included

• Lifetime access to all course materials

• Active instructor support in the Q&A section

• Udemy Certificate of Completion

• Practical assignments and real business cases

• A section with additional courses, tools and resources

One habit to start with

The next time someone gives you a requirement, ask what they do today and what happens if nothing changes. Both answers are usually more useful than the requirement itself, and neither is what they came to tell you. Enrol now and start the first lesson today.