Problem Domain:
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.
It is called scope of analysis, When collecting user stories or User
Requirements 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 Something to think about.
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.
Solution Domain:
While the Problem Domain defines the environment where the solution will
come to work, the solution domain defines the abstract environment where the
solution is developed. The differences between those two domains are the cause
for possible errors when the solution is planted into the problem domain.
In respect to a given problem (or set of problems), the solution domain (or solution space) covers all aspects
of the solution product, including:
·
The process by which the solution is
arrived at;
·
The environment in which it is
constructed;
·
The design, construction, testing,
operation, and functions of the solution product itself.
Confusing the problem with
the solution is one of the
great dangers of IT projects, resulting in software that may be a very good
solution to some problem, but
not to the specific set of problems its users face. See the quotation from
Gamma et al. under Problem
domain
0 comments:
Post a Comment