Analysing The Problem Domain

I think everyone would agree that defining the problem would be a good first step in arriving at a solution, and yet I'm a bit lost finding details on how one goes about this. For instance, it would seem like the UseCase or UserStory would be as applicable in its basic form to defining an interaction or behavior that we want to correct, but I always see them used to describe a prospective solution or desired feature. Assuming you aren't studying a business function that you want to automate, but rather a function that is in itself a problem ("Joe forgot his coffee on the roof of his car"), would anyone have advice on how to begin? I'd prefer to really dig down into who Joe is, and why he is so forgetful before I start coming up with my solution (cup on a rope?).

Anyhow, having extracted all the wisdom possible from the GrokTheProblemDomain and ProblemDomainExpertReviewers, I'd be mighty obliged if someone could give a short dissertation on their process in this area.

-- JamesWhite

I think it's about building a mental model of the problem domain and using your reasoning processes to explore the transitive implications and problems. Not sure a step-by-step solution is possible. -- AnonymousDonor

That is certainly an option, but I think it could be argued that the same option exists for developing a solution. I was actually on this course when I began to realize that perhaps my solution wouldn't address the real problems, or the issues of greatest import. Those deficiencies would almost certainly be highlighted when I presented my solution to people within the process I sought to fix, but I imagine there must be a more efficient method.

Actually, it's a bit funny that I came up with that proposal "cup on a rope" using what I thought was a rational method. While it ensures that the cup will travel with Joe, and that he can open the car door without needing to place the cup on a surface, it fails to address the problem that Joe is forgetful and would be just as likely to forget his "cup on a rope" at home as the cup on the roof. If I had broken down the problem and identified forgetfulness as the primary issue, my solution would have been far superior ("Talking Cup"). Does that make sense?

-- JamesWhite

The ProblemDomain is a big word. It includes a lot of things. Is there any process that would have guaranteed you would have created the talking cup is the first solution? I don't know of one because the solution generation process itself changes the ProblemDomain. There are obvious things like involve more perspectives, simulate, do surveys, look at existing solutions, lateral thinking, attribute matrixes, etc. Still there are no guarantees. -- AnonymousDonor

Yes, perhaps I am misusing the term, though it certainly is open to that sort of misinterpretation. I think most people use the term to imply "The Old Solution Domain" (the manual business process or old software solution) and SolutionDomain to imply "The New And Improved Solution Domain" (the new software solution). I would prefer "The Way it Used to Not Work" (the broken business process), "The Way it Should Work" (the ideal process), and "The Way We Made it Work" (the attempt to automate the ideal process). That would really allow you to differentiate between the problem case, the solution case, and the implemented case (which is not always representative of the optimal solution). Now I just need a flashy name for that methodology. -- JamesWhite

I guess this is equivalent to building a mental model, but as a procedure try listing the sequence of steps that lead to the undesired outcome and then arguing about where best to intercept that sequence. Analysis might show it to be a good idea to get Joe to give up coffee and get more sleep, and also to cycle to work rather than go by car. He'd either end up fitter, less tired, less stressd and so less forgetful to boot or else very seriously pissed off with the business consultancy he hired to solve his coffee problem :-) . -- AnonymousDonor

That's a good idea. I think applying the sequence or activity diagram to pinpoint where things go awry is probably a useful method. Though I am a bit wary of the removal of caffeine, Joe is entirely useless without the 'nectar of the beans'. -- JamesWhite

I would consider "the removal of caffine" to be a constraint on the set of solutions. The only way to expose these constraints to present the candidate solution to the Customer. -- Echo

One of the earliest methodologies already knew how to tackle this problem. The SystemsDevelopmentLifeCycle had a 'systems investigation' phase which aimed at learning the problem domain in all its detail. The next phase 'systems analysis' is for problem finding and solving. Systems investigation is geared towards reconstructing context; systems analysis examines how that context should be changed. During these stages, people in various roles are interviewed, organizational charts are examined and normal methods of work are observed. In some ways, the customer is involved to a greater extent even than XP. We have outgrown the SDLC, but some of the techniques are still valuable. -- ChrisSteinbach

SystemsAnalysis pre-dates SoftwareDevelopment and many of its techniques are still valuable. ClearRequirements have always been a holy grail and there is no reason to suppose anyone will ever figure out how to do it consistently. If they do, they probably won't be your client, in any event. UserStories seem preferable to ClearRequirements because no-one expects them to be treated as a binding contract term. In practice, ClearRequirements should always be assumed to be unclear (in the absence of strong evidence to the contrary), and in that case, they, like UserStories are SomethingToThinkAbout, an island in the archipelago of the ProblemDomain. If you swim and dive and sail around the archipelago for long enough, you get to know it well enough to see how it might fit together. It helps if you are making maps as you go. Which is why, as GeraldWeinberg says: "The documentation is nothing, the documenting is everything".

Don't think about software requirements too early (think about BusinessRequirements instead; it's never too early to think about those). This is the message I get from modern SystemsAnalysis. The software solution is only part of a larger solution. Forget this and you become a software salesman and not a problem solver. Even if all your competence is tied to software (which I doubt it is), it is better for your client if you identify the bigger picture. Pinpoint the cultural and organizational changes required to support training and administration. You should see software development first as an intervention, then as an aid. UserStories are great for specifying software requirements, but not all that good at analysing real world problems. (See also XpCritique for similar comments). -- ChrisSteinbach

See SoftSystemsMethodology

I have added a page on MessingAboutInProblems to connect to the work of Colin Eden and others. -- RalphHodgson

CategorySolutions