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.
What is Requirements Engineering?
Requirements engineering is more than just gathering features for a software system. It’s a discipline. It’s a structured process that includes identifying, analyzing, documenting, validating, and managing the needs of stakeholders.
At its core, requirements engineering ensures that what we build actually solves the right problems. It answers key questions like:
- What should the system do?
- Who are the users?
- What constraints must we consider?
It’s not just technical. It’s social, too. I need to work with people, understand their goals, and deal with conflicts in perspectives. This process sets the foundation for everything that follows in software development.
What is Requirements Elicitation?
Elicitation is the first and most human part of requirements engineering. It’s where I uncover what the system really needs to do. And no—it’s not just sending a survey or reading a spec. It’s interactive. It’s about listening. Observing. Asking better questions.
Often, people don’t know what they need. Or they describe it in their own language, shaped by their role, experience, and daily frustrations. That’s where things get tricky—and interesting.
With object-oriented elicitation, I take these scattered impressions and begin shaping them into structured concepts. I use the principles of object orientation—not just in code, but in how I think and communicate. This helps me turn abstract ideas into clear system components.
Let’s see how this works in practice.
The Case: A Dentist Administration System
My First Impressions
Picture this: I’m standing in a dentist’s office. Patients arrive. The receptionist checks records. Assistants prepare tools. The dentist enters details into a system, prints prescriptions, talks to patients, and checks x-rays. It’s a whirlwind.
I’m here to build software that handles patient data, prescriptions, and the communication flow across the clinic. But first, I need to understand what’s actually happening. Everything feels messy at the beginning. That’s normal.
Listening to Stakeholders
I talk to the dentist. He tells me what matters medically—accurate records, correct dosages, and smooth workflows. The dental assistant cares about billing and insurance codes. Meanwhile, patients want clarity and convenience.
Each person gives me a different picture. Yet they’re all right—in their own way.
Even two assistants who do the same job tell me different things. One focuses on appointment flow. The other talks more about document management. That’s a key insight: requirements aren’t universal. They are filtered through individual experiences.
From Chaos to Structure
As I gather more information, I start noticing patterns. I mentally group similar elements. I define objects that emerge from the real-world mess. A patient. A prescription. An appointment. An invoice.
With object-oriented elicitation, I don’t just write down what people say. I model their world. I identify things that behave as units. For instance, a prescription changes over time, but it remains the same object. It responds to actions, holds data, and interacts with others.
That’s how I start making sense of requirements. One object at a time.
The Nature of Human Understanding
Here’s something fascinating: we naturally think in objects. We say “the computer crashed,” or “the form disappeared,” even when those phrases aren’t technically accurate. Why? Because we humanize systems. We view them as entities with behavior.
I use this instinct as a tool. When people describe a problem in human terms, I translate it into system behavior. I ask: what’s the object? What are its features? What actions affect it?
By doing so, I create a shared language between users and developers. That’s the power of object-oriented elicitation.
Grouping and Categorizing
The next challenge is scale. A dental clinic has hundreds of objects to track. So I categorize them. Patients, staff, prescriptions, invoices, treatments.
Then I go further. I group categories into hierarchies. “People” become “internal staff” and “external contacts.” “Internal staff” splits into “dentist” and “assistant.” This hierarchy brings clarity.
It’s like building mental filing cabinets. Each drawer contains a group of related objects. This is not a natural structure. It’s a designed one. But it helps both me and the users make sense of the system.
Building the Requirements Model
By now, I’ve shifted from raw observation to structured modeling. Every object has:
- A name
- Key attributes
- Relationships with other objects
- Defined behaviors
I use these objects to build a conceptual model of the system. This model reflects both the real-world complexity and the system logic. It acts as a bridge between user expectations and technical design.
This is the heart of object-oriented elicitation. I don’t impose a system. I derive it—by understanding people, translating their views, and organizing them into clear, consistent objects.
Final Thoughts
Object-oriented elicitation is more than a technique. It’s a mindset. It guides how I explore, structure, and communicate requirements—especially in complex domains like healthcare.
By combining requirements engineering with object-oriented thinking, I bridge the gap between real-world needs and technical solutions. I give stakeholders a voice. I create systems that reflect how people actually work.
In this dentist administration system, object-oriented elicitation helped me move from confusion to clarity. From scattered conversations to a working model. From ideas to real, usable software.
If you’re working in requirements engineering, give this approach a try. It might not just change how you model systems—it might change how you understand people.
