What I’ve learned is this: writing down a requirement is only the starting point. The real work is in managing it — refining, validating, prioritizing, and adjusting as things change.
I’ve completed 4 out of 6 courses in the Microsoft Business Analyst certification so far. The early modules — Excel, data handling, and Visio — felt familiar. They helped sharpen what I already knew.
But once I moved into requirement gathering and requirement engineering, things shifted. The process felt abstract at first: new terminology, layered structure, different ways of thinking.
Then it started to click. I learned how to:
- Define requirements clearly — not just describe what I assumed
- Distinguish between functional and non-functional needs
- Break down what stakeholders actually expect — and why clarity matters so much
- See how weak requirements lead to bigger risks than missing features
Later modules introduced tools like backlog management, epics, and user stories — all aimed at structure, clarity, and continuous refinement.
I’ve started noticing how often structure shapes clarity — not just in projects, but in how I approach decisions.
Two more courses to go. Still learning. Still showing up.