When I begin a software project, I don’t just write code—I ask questions to understand the real world behind the system. This becomes crucial when I work in unfamiliar domains, like developing software for a dental clinic. In such cases, object-oriented elicitation is my key approach. It helps uncover, organize, and refine requirements for effective system design. By applying object-oriented elicitation, I can turn complex real-world details into clear, structured, and actionable models.
What Is Object-Oriented Elicitation?
I use object-oriented elicitation as an analytical approach within requirements engineering. It does not replace interviews, observation, workshops, document analysis, or other elicitation techniques. Instead, it gives me a structure for interpreting what I discover.
I look for identifiable concepts in the domain. Then I examine their properties, responsibilities, states, relationships, and interactions.
For example, a dental practice may contain concepts such as:
- Patient
- Appointment
- Treatment
- Prescription
- Dentist
- Invoice
- Insurance claim
However, identifying these concepts is only the beginning.
A domain concept becomes useful when I understand what it represents, how it changes, what rules apply to it, and how it relates to other concepts.
Therefore, object-oriented elicitation moves my analysis beyond simple feature lists.
From Stakeholder Statements to Domain Knowledge
Requirements rarely arrive as complete and precise statements. Stakeholders describe their work from different perspectives.
A dentist may focus on treatments and medical documentation. A receptionist may focus on appointments and patient records. An administrative employee may focus on invoices and insurance claims.
These descriptions can overlap. They can also contradict each other.
Instead of treating this variation as a problem, I use it as information. Each statement reveals part of the domain.
For example, I may hear:
“Patients sometimes cancel their appointments.”
At first, this sounds simple. However, I can investigate it systematically:
- What is an appointment?
- Who can cancel it?
- Which appointment states exist?
- Can every appointment be cancelled?
- How late may a patient cancel?
- What happens after cancellation?
- Does the clinic charge a fee?
- Does the system notify anyone?
As a result, one ordinary stakeholder statement can reveal concepts, states, business rules, events, and system behavior.
Good elicitation does not stop when I understand what happens. I also investigate under which conditions it happens and what consequences follow.
A Dental Practice as an Example
Suppose I need to analyze a new administration system for a dental practice.
First, I observe the work itself. Patients arrive. Staff schedule appointments. Dentists document treatments. Prescriptions refer to patients. Invoices refer to treatments. Insurance information affects billing.
I do not immediately design software screens or database tables. Instead, I build a conceptual view of the domain.
For instance, I may identify:
Patient
A person who receives treatment and has administrative and medical information.
Appointment
A scheduled period that connects a patient with a practitioner, time, and purpose.
Treatment
A clinical activity performed for a patient.
Prescription
A medical instruction that belongs to a patient and contains specific medication information.
Invoice
A financial document based on billable services.
At this stage, these concepts describe the problem domain. They are not yet software components.
I keep the domain model separate from the technical design because premature design decisions can distort the requirements.
I Examine Responsibilities, Not Only Data
A weak object-oriented analysis often produces nothing more than boxes containing attributes.
I avoid that.
Instead, I ask what each concept is responsible for within the domain.
An appointment may have to:
- represent a scheduled interaction;
- maintain its current status;
- refer to a patient and practitioner;
- obey scheduling rules;
- support cancellation or rescheduling.
Similarly, a prescription may have to maintain information about its patient, medication, dosage, issuing practitioner, and validity.
This perspective matters because requirements describe behavior as well as information.
Therefore, I ask two basic questions for every important concept:
What does this concept need to know?
What needs to happen to or through this concept?
The answers help me identify both information requirements and behavioral requirements.
I Model States and Changes
Many requirements only become visible when I ask how something changes over time.
An appointment might move through states such as:
Scheduled → Confirmed → Completed
Alternatively:
Scheduled → Cancelled
A prescription might move from created to issued and later to expired.
These transitions expose rules.
For example:
- A completed appointment cannot be cancelled.
- Only authorized staff may issue a prescription.
- An expired prescription cannot remain valid.
- Cancelling an appointment may trigger a notification.
Therefore, state analysis helps me discover requirements that a static list of attributes would miss.
Whenever the state of a domain concept matters, I investigate the events that change it and the rules that restrict those changes.
I Analyze Relationships
Complex systems rarely consist of isolated concepts.
A patient books appointments. An appointment can lead to a treatment. A treatment can create billable services. These services can appear on an invoice.
Consequently, I examine relationships explicitly.
I ask questions such as:
- Can one patient have several appointments?
- Can an appointment contain several treatments?
- Can a treatment exist without an appointment?
- Who creates a prescription?
- Can several invoices relate to one treatment?
- What happens to related records if something changes?
These questions reveal cardinalities, dependencies, ownership rules, and lifecycle constraints.
They also expose ambiguity.
For example, a stakeholder might say that an invoice “belongs to an appointment.” Another stakeholder may say that invoices refer to individual treatments. I then need to clarify the actual business rule.
From Elicitation to a Conceptual Model
Once I understand the important concepts, I can represent them in a model. Depending on the purpose, I may use UML classes, associations, dependencies, states, or other suitable notation.
However, the diagram comes after the analysis.
I use the model to express knowledge that I have elicited; I do not let the notation determine what the domain must contain.
The attached image fits best at this point because it shows the transition from elicited knowledge to a structured model. It should not appear earlier in the article. Otherwise, readers may confuse object-oriented elicitation with the act of drawing UML diagrams.
I Do Not Turn Every Noun Into a Class
A common shortcut in object-oriented analysis is to extract nouns from stakeholder statements and treat them as candidate classes.
This can help with exploration. However, I do not treat it as a rule.
Consider this sentence:
“The receptionist sends the patient an appointment confirmation by email.”
The nouns include receptionist, patient, appointment confirmation, and email. Yet they do not automatically represent four classes.
Instead, I ask what each term means in the domain and whether I need to represent it explicitly.
The same principle applies to verbs. A verb may indicate behavior, but it may also describe a workflow, an external service, or an informal activity.
Language gives me clues for modeling, not finished model elements.
This distinction prevents artificial models that mirror sentence structure instead of business reality.
I Add Business Rules and Constraints
Objects and relationships alone cannot describe a system sufficiently.
Therefore, I also identify the rules that govern them.
For example:
- A patient must exist before staff can create an appointment.
- Only qualified practitioners may perform specific treatments.
- A prescription requires an issuing practitioner.
- Certain services require specific billing codes.
- Access to medical information depends on authorization.
These constraints often determine the most important requirements.
Moreover, they help me distinguish ordinary behavior from exceptional situations.
If a rule says that an appointment requires a registered patient, I also ask what should happen when staff try to schedule an unregistered person.
That question may reveal another requirement.
I Validate the Model With Stakeholders
A model has little value if only I understand it.
Therefore, I review the concepts, relationships, states, and rules with the people who know the domain.
I use the model to ask precise questions:
“Can a treatment exist without an appointment?”
“Can two dentists work on the same treatment record?”
“Who may change a prescription after it has been issued?”
“What happens to an invoice when a billing error occurs?”
This makes the model an elicitation instrument in its own right. Stakeholders can confirm it, reject it, or add missing information.
As a result, modeling and elicitation become iterative activities.
I model what I learn, validate the model, discover gaps, and then return to elicitation.
From the Domain Model to Requirements
Finally, I translate the validated domain knowledge into explicit requirements.
For example, domain analysis may show that an appointment can have the states scheduled, confirmed, cancelled, and completed.
From this, I can derive requirements such as:
“The system shall allow authorized staff to cancel a scheduled or confirmed appointment.”
I can then define an acceptance criterion:
Given a confirmed appointment, when an authorized employee cancels it, the system changes its status to cancelled and records the cancellation.
This creates traceability from domain knowledge to requirement and from requirement to verification.
However, I do not try to generate every requirement mechanically from the model. Some requirements concern usability, security, performance, legal obligations, interfaces, or organizational processes. I need additional elicitation techniques for them.
When I Use Object-Oriented Elicitation
I find this approach especially useful when a domain contains many interacting concepts, complex information structures, clear responsibilities, or important state changes.
It works well for systems such as:
- healthcare administration;
- insurance systems;
- logistics;
- banking;
- inventory management;
- customer management;
- booking systems;
- enterprise applications.
However, I do not force every problem into an object-oriented structure. Process models, use cases, state models, decision models, data models, or simple textual requirements may explain some aspects better.
The purpose of modeling is not to use a particular notation. The purpose is to reduce ambiguity and improve understanding.
Final Thoughts
Object-oriented elicitation helps me transform fragmented stakeholder knowledge into a structured view of a complex domain.
I identify important concepts. Then I investigate their responsibilities, information, states, relationships, interactions, and governing rules. Next, I validate that understanding with stakeholders. Finally, I use the resulting model to formulate clearer and more testable requirements.
The greatest value does not come from drawing classes or interfaces. It comes from asking better questions.
When I treat object-oriented thinking as a tool for understanding the domain rather than as an early software design exercise, it becomes a powerful part of requirements engineering.
What’s Next?!
Now that you’ve seen how object-oriented elicitation helps transform real-world complexity into clear system models, it’s time to strengthen your foundation. In my next article, “,” I’ll explain the key principles that give structure and meaning to every model. Join me to explore the essential building blocks of requirements modeling and discover how precise terminology leads to more consistent and effective system design.
Now that you’ve seen how object-oriented elicitation helps transform real-world complexity into clear system models, it’s time to strengthen your foundation. Continue with Terms and Concepts in Requirements Modeling to explore the key principles that give structure and meaning to every model. Then, take the next step with Object Name, State, and Behavior in Object-Oriented Programming to understand how objects become more precise through their identity, properties, and actions. Together, both topics help you create clearer models and support more consistent system design.
Start Where Successful Software Projects Begin
Start with Requirements Engineering to see how strong software ideas become clear, usable, and realistic project goals. It shows how well-defined requirements create focus, connect people, and support smarter decisions from the beginning. As a result, you can understand how requirements engineering turns early thoughts into software solutions that create real value.
If I want to deepen that understanding, I continue with Requirements Modeling. There, I explore Modeling Concepts, Process Modeling with BPMN, and UML to see how models make requirements easier to visualize, structure, and communicate. Together, these perspectives help me connect business needs, workflows, and system structures in a clearer and more practical way.