Problem Domain

Also known as the ScopeOfAnalysis? or, to an analyst, the scope. When collecting UserStories or UserRequirements, whatever, how do you decide which ones are relevant? You keep in mind some higher-level statement of what the objectives are and what people think the problems are (if people didn't think there were problems, they wouldn't be paying someone to come up with a solution, would they?). Then it's either in, out or borderline. If it's borderline, you probably want someone to agree it's out (even if you want it to be in). In the mean time, and probably afterwards, you keep it as SomethingToThinkAbout.

Is there a meaningful definition for this term or is it just jargon and thus should be binned to avoid creating confusion?

Sorry I find the above "definition" quite useless.

I suspect I'm wandering into a troll's line of fire here, but: Yes, it's a useful term, though perhaps a fuzzy one. When you're trying to solve a problem, you have to pay some attention to the problem itself and some to the tools you're using on it. Considerations related to the problem itself, that could apply equally however you chose to solve it, are given the label ProblemDomain. Considerations related to the tools, that could apply even if you were using them to solve an entirely different problem, are given the label SolutionDomain. There's a continuum between the two, of course, and most of the time you're working somewhere between the extremes. -- GarethMcCaughan

A domain is “A sphere of thought or operation; the situations where a particular science, law, etc., is applicable.” (New Shorter Oxford English Dictionary).

Problem domain (or problem space) is an engineering term referring to all information that defines the problem and constrains the solution (the constraints being part of the problem). It includes the goals that the problem owner wishes to achieve, the context within which the problem exists, and all rules that define essential functions or other aspects of any solution product. It represents the environment in which a solution will have to operate, as well as the problem itself.

Note that the customer for a software solution (the "problem owner") doesn’t necessarily recognise the existence of a problem so much as an opportunity. An engineer sees a “problem domain” as being the set of circumstances for which s/he has to provide a solution; it’s the engineer’s problem, not necessarily the customer’s.

“[A good architect] focuses as much on the problem to be solved and the various forces on the problem as he does on the solution to the problem. [The IT industry has] a tendency to focus on the solution.” (Gamma et al. (Gang of Four), Design Patterns.) In this respect, the comment below regarding a "revealing pet name" is very apposite.

— Don Mills

Not trolling - genuinely looking for a satisfactory definition. Gareth's sounds good but my jargon antennae are still twitching. What meaning would be lost if the word "domain" was dropped from "problem domain"?

To me, the problem domain and the solution domain are essentially the same domain; it is the same territory bordered by the same frame. Only inside the domain the positions of the relevant entities differ. When they are all perfectly in place they form a solution, otherwise they relatively still constitute a problem. -- Harry

In software engineering, the architecture and development of software, hardware, and networking all constitute the 'solution domain'. That is, these are the tools by which you are achieving a solution to a set of user-requirements. All software tools have limitations in achieving useful properties (such as performance, runtime upgrades, modularity). Working within the set of limitations imposed by one's tools is ascribed to the 'solution domain'. Using better or different tools (different hardware, different OS, DB, filesystem with different features, networking, etc.) can vastly change the solution domain.

The 'problem domain', then, is the user-requirements, user stories, use-cases. It's what you're getting paid to achieve. It isn't necessarily what the client tells you, either... a software developer often must go to great teeth-pulling efforts to determine the problem domain.

In software development, both of these domains constrain the developer. They may also overlap - i.e. if the user happens to require that the solution be achieved for certain commodity hardware and OS. But I would not agree that this overlap makes the concepts indistinct. The set of 'red things' overlaps with the set of 'pencils', but they are still distinct concepts, and the same can be said for the problem and solution domains.

The problem vs. solution domain view in software design serves a similar role as understanding FunctionalRequirements vs. NonFunctionalRequirements, but make a different set of distinctions between requirements. Classifying requirements can help one understand them, get one's head around them, approach them systematically. It's important because RequirementsAnalysis is important.

In ObjectOrientedProgramming - especially under the NygaardClassification - the role of the object is to model elements of the solution domain - i.e. each object models a component of the resulting program (including hardware, messages over the wire, etc.). Distinguishing problem domain from solution domain helps one understand what would need modeling within OO... i.e. one does not model the problem domain (except, perhaps, to simulate user stories and such for testing).

(from VeryLongDescriptiveNamesThatProgrammingPairsThinkProvideGoodDescriptions:)

"ProblemDomain [is] our revealing pet name for the world outside the computer."

CategoryAddress