Chapter 4
“Things” in the problem domain
Problem domain - the specific area (domain) of the users’ business need that is within the scope of
the new system
“Things” are those items users work with when accomplishing tasks that need to be remembered
Examples - products, sales, shippers, customers, invoices, payments, etc.
These “Things” are modelled as domain classes or data entities
Two techniques for identifying things
Brainstorming Technique
A technique used to identify problem domain classes in which developers work with users to
identify classes by thinking about different types of things they use in their work
Use checklist of all of usual types of things typically found and brainstorm to identify domain
classes of each type
Are there any tangible things? Are there any organizational units? Sites/locations? Are there
incidents or events that need to be recorded?
Steps
1. Identify a user and a set of use cases
2. Brainstorm with the user to identify things involved when carrying out the use case
3. Use the types of things (categories) to systematically ask questions about potential things, such
as:
Are there any tangible things you store information about? Are there any locations involved? Are
there roles?
4. Continue to work with all types of users and stakeholders to expand the brainstorming list
5. Merge the results, eliminate any duplicates, and compile an initial list
Noun Technique
A technique to identify problem domain classes (things) by finding, classifying, and refining a list
of nouns that come up in in discussions or documents
Identify all of the nouns that come up when the system is described and determine if each is a
domain class, an attribute, or not something we need to remember
, Does end up with long lists and many nouns that are not things that need to be stored by the
system
Difficulty identifying synonyms and things that are really attributes
Good place to start when there are no users available to help brainstorm
Steps
1. Using the use cases, actors, and other information about the system— including inputs and
outputs—identify all nouns.
For the RMO CSMS, the nouns might include customer, product item, sale, confirmation,
transaction, shipping, bank, change request, summary report, management, transaction report,
accounting, back order, back-order notification, return, return confirmation…
2. Using other information from existing systems, current procedures, and current reports or forms,
add items or categories of information needed.
For the RMO CSMS, these might include price, size, colour, style, season, inventory quantity,
payment method, and shipping address.
3. As this list of nouns builds, refine it. Ask these questions about each noun to help you decide
whether you should include it:
Is it a unique thing the system needs to know about?
Is it inside the scope of the system I am working on?
Does the system need to remember more than one of these items?
Ask these questions to decide to exclude it:
Is it really a synonym for some other thing I have identified?
Is it really just an output of the system produced from other information I have identified?
Is it really just an input that results in recording some other information I have identified?
Ask these questions to research it:
Is it likely to be a specific piece of information (attribute) about some other thing I have
identified?
Is it something I might need if assumptions change?
4. Create a master list of all nouns identified and then note whether each one should be included,
excluded, or researched further.
5. Review the list with users, stakeholders, and team members and then define the list of things in
the problem domain.
“Things” in the problem domain
Problem domain - the specific area (domain) of the users’ business need that is within the scope of
the new system
“Things” are those items users work with when accomplishing tasks that need to be remembered
Examples - products, sales, shippers, customers, invoices, payments, etc.
These “Things” are modelled as domain classes or data entities
Two techniques for identifying things
Brainstorming Technique
A technique used to identify problem domain classes in which developers work with users to
identify classes by thinking about different types of things they use in their work
Use checklist of all of usual types of things typically found and brainstorm to identify domain
classes of each type
Are there any tangible things? Are there any organizational units? Sites/locations? Are there
incidents or events that need to be recorded?
Steps
1. Identify a user and a set of use cases
2. Brainstorm with the user to identify things involved when carrying out the use case
3. Use the types of things (categories) to systematically ask questions about potential things, such
as:
Are there any tangible things you store information about? Are there any locations involved? Are
there roles?
4. Continue to work with all types of users and stakeholders to expand the brainstorming list
5. Merge the results, eliminate any duplicates, and compile an initial list
Noun Technique
A technique to identify problem domain classes (things) by finding, classifying, and refining a list
of nouns that come up in in discussions or documents
Identify all of the nouns that come up when the system is described and determine if each is a
domain class, an attribute, or not something we need to remember
, Does end up with long lists and many nouns that are not things that need to be stored by the
system
Difficulty identifying synonyms and things that are really attributes
Good place to start when there are no users available to help brainstorm
Steps
1. Using the use cases, actors, and other information about the system— including inputs and
outputs—identify all nouns.
For the RMO CSMS, the nouns might include customer, product item, sale, confirmation,
transaction, shipping, bank, change request, summary report, management, transaction report,
accounting, back order, back-order notification, return, return confirmation…
2. Using other information from existing systems, current procedures, and current reports or forms,
add items or categories of information needed.
For the RMO CSMS, these might include price, size, colour, style, season, inventory quantity,
payment method, and shipping address.
3. As this list of nouns builds, refine it. Ask these questions about each noun to help you decide
whether you should include it:
Is it a unique thing the system needs to know about?
Is it inside the scope of the system I am working on?
Does the system need to remember more than one of these items?
Ask these questions to decide to exclude it:
Is it really a synonym for some other thing I have identified?
Is it really just an output of the system produced from other information I have identified?
Is it really just an input that results in recording some other information I have identified?
Ask these questions to research it:
Is it likely to be a specific piece of information (attribute) about some other thing I have
identified?
Is it something I might need if assumptions change?
4. Create a master list of all nouns identified and then note whether each one should be included,
excluded, or researched further.
5. Review the list with users, stakeholders, and team members and then define the list of things in
the problem domain.
