I have to document my program for a school project and we have section called "problem domain" but I have no idea what to discuss in this section.

So the question is: What should be discussed in the problem domain?

  • 2
    Problem domain = Programm topic/theme/subject Dec 19, 2011 at 11:37
  • Given the way you have formulated your question, the answer @qes provided pretty much closes it. If you want any more specific advice you will need to give a few details as to what your program is about.
    – Mike Nakis
    Dec 19, 2011 at 11:42
  • Because if you can't tell us what your program is about, you don't know the problem domain.
    – JeffO
    Dec 19, 2011 at 15:52
  • The problem domain is your problem, plus everything else related that might solve for it. I generally think of it as, "everything that might take me to the solution". If, for example, if your project is "get the piggies to market alive as profitably as possible", your problem domain is piggy life requirements, transportation, containers, cost factor concerns across all nodes, etc.
    – duggi
    Jan 30, 2021 at 22:21

5 Answers 5


I write embedded software for telecommunications equipment. My problem domain is ethernet, voice, and video protocols. In other words, all the stuff that has nothing to do with the language I'm programming in, but that I still must understand in order to write the software. If you're making a website for selling photography services, the problem domain is photography and ecommerce. If you write firmware for military aircraft, the problem domain is weapons, sensors, and control systems. Get the picture?

  • 7
    Absolutely correct. And in the commercial-software business, folks who know the problem domain are frequently referred to as Subject Matter Experts (SMEs), rather than programmers, because their value to and role in the organization is different from (and often higher than) programmers. Jan 16, 2012 at 14:02
  • @Karl Bielefeldt thank u. You are my today's day saver. Nov 20, 2014 at 8:55

From the Wikipedia article on problem domain:

A problem domain is the area of expertise or application that needs to be examined to solve a problem. A problem domain is simply looking at only the topics you are interested in, and excluding everything else.

It is the area where the problems your application is intended to solve, belong to.

  • @Murph, edits during the first 5 minutes of a post aren't recorded explicitly. Dec 19, 2011 at 13:40
  • Can you provide an example pls? Dec 19, 2011 at 14:47
  • @PéterTörök never an (entirely) bad day when you learn something new (-:
    – Murph
    Dec 19, 2011 at 16:14
  • 1
    @SamanthaCatania, in the case of the project I am currently working on, the problem domain is car rentals. A central area in this is vehicle checkout&checkin itself, but apart from this, there are many other subdomains, such as: fleet management, revenue management, rates etc. Dec 19, 2011 at 16:25
  • Note that a problem domain can be very specific, e.g. inventory management, as it's done by our company's New York state region. But probably no more specific than this; smaller "domains" are typically considered single problems. Feb 10, 2017 at 22:24

Not everyone writes compilers, bug trackers, frameworks, or other straight computery software packages.

Some people write software for the sand and gravel industry. Some people write software for monitoring refinery refraction towers. Some people write software to control the manufacturing of plastic grocery bags. Some people write software to fill ketchup packets.

Those are all problem domains, where in order to write good software, you need to know a bit about the domain, e.g. ready-mix concrete.

  • 1
    A compiler writer also have a problem domain, among other things; CPU architecture. Apr 16, 2013 at 9:02

Ian K. Bray in his book An Introduction to Requirements Engineering (p9) defines the problem domain as the following :

That part of the universe within which the problem exists.

For example, in the case of a lift control system, it would include any existing hardware (lifts, motors, buttons, indicators, sensors, etc.), the building characteristics (number of floors and lift-shafts), the anticipated pattern of usage, the characteristics of the users, the lift usage policy of the client (e.g. should users be discouraged from using a lift for short journeys?) and so on.

Within the lift control problem domain, the problem, as stated above, is, ’a control system is needed that will make more efficient use of the lifts in this building’. In practice, we usually refine the problem into a whole set of sub-problems but, for now, just note that in order to solve the problem(s), it is clearly necessary for the solution system to produce some effects within the problem domain. It is these desired effects that constitute the requirements.

So, the problem domain can equally well be regarded as that part of the world within which the new, solution system (sometimes shortened to SS) will operate and will produce the required effects. Since software-based solution systems are often called applications, the problem domain may be called the application domain.


I see it like this:

The problem domain: The reason the software needs to be built and the environment and industry for which the built system needs to be of use.

Not the answer you're looking for? Browse other questions tagged or ask your own question.