Object-oriented design fascinates me. It feels natural and intuitive. Almost everything I deal with—tangible or abstract—can be understood as an object. That’s the beauty of it. This way of thinking helps me break down even the most complex problems into manageable pieces. Let me take you through the idea of objects in object-oriented design, step by step.

When I start a software project, I don’t just write code. I ask questions. I try to understand the real world behind the system. That’s especially important when I’m working outside my comfort zone—like designing software for a dental clinic. In such cases, object-oriented elicitation becomes my go-to method. It helps me uncover, organize, and refine the requirements that drive system design. But to really understand how this works, I need to go beyond the code. I need to dive deep into requirements engineering, and even deeper into how we elicit those requirements from people who think very differently from developers. In this article, I’ll walk you through a real-world example: a dentist administration system. Along the way, I’ll show how I used object-oriented elicitation to transform complex, chaotic information into a structured and usable model.