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 – Ivan Crojach Karačić Dec 19 '11 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 '11 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 '11 at 15:52
up vote 23 down vote accepted

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?

  • 5
    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. – Ross Patterson Jan 16 '12 at 14:02
  • @Karl Bielefeldt thank u. You are my today's day saver. – William Francis Gomes Nov 20 '14 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. – Péter Török Dec 19 '11 at 13:40
  • Can you provide an example pls? – Samantha Catania Dec 19 '11 at 14:47
  • @PéterTörök never an (entirely) bad day when you learn something new (-: – Murph Dec 19 '11 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. – Péter Török Dec 19 '11 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. – Paul Brinkley Feb 10 '17 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. – Prof. Falken Apr 16 '13 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.

protected by gnat Feb 10 '17 at 20:08

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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