THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

Published in TDAN.com January 2003

Introduction

I am constantly amazed how teams will latch on to new technologies or methodologies, get stuck, and then blame the problem on the tool or methodology. The most common "magic bullet" today is object-oriented software engineering and there are many areas that object-oriented techniques paralyze teams. The most common form of this paralysis is "Analysis Paralysis". I prefer to call this form of paralysis problem-solution confusion. In this article I will explain why many groups become paralyzed and fail when they start working with object-oriented techniques. Further I will give some suggestions on how to avoid problem-solution confusion in the future.

A confusion of "space"

Experience has shown that there needs to be a true separation between the two initial object-oriented disciplines: analysis and design. I bet if you asked 100 people about what constitutes analysis and design, 50% would not be able to give a difference between the disciplines. Another 30% would confuse design with coding while the last 20% would say analysis is with end users and design is not.

All of these point to a true confusion of something methodologists call "space". There are really two spaces we as software engineers or project managers are interested: problem space and solution space. By exploring what we mean by each of these spaces, we begin to understand the root cause of problem-solution confusion and the resultant analysis paralysis.

I have a co-worker who describes this as the "Shovel vs. Hole Problem". He is famous at his company for saying people get confused when they are analyzing the Hole (problem) vs. the Shovel (solution). If all you understand is you need to dig a hole with a shovel you may forget to ask what type of hole you need to dig. You may pick out a good gardening spade only to be embarrassed when you discover the user wanted a foundation of a house dug.

Think of the hole as a problem to solve. Given this problem what questions would help clarify the problem for someone proposing a solution (your designer)? I would ask questions like the following: What is the intended use of the hole? What am I digging through? Where do I need to store the contents of the hole? What time frame do I have to dig the hole? These questions will clarify the process and the business rules involved without jumping into a solution before we understand the problem.

Think of the shovel as a solution to the problem. Given the above problem of digging a hole, what questions would you ask as a solution provider (designer)? I would ask questions like the following: How can I make a whole that will fit their intended use? How can I dig most efficiently through the layers of ground in this area? How can I mark the exact location of the hole? How can I economically dispose the contents of the hole? How can I meet the time frame in which the hole is needed? These questions occur during the solution space. They lead to a solution based on the processes and business rules laid out in the problem space.

Software engineers begin to recognize that there is a time for problem space work and a time for solution space work. Nevertheless, many of the popular methodologies and techniques being adopted blur the differences between problem and solution space and only focus on artifacts and techniques.

Defining "spaces"

We are now much closer to the root problem of this confusion. What is problem space? What is solution space? Who performs which space and when is it performed? To answer these questions we need a firmer understanding of both problem space and solution space.

Problem space is the area of software engineering where all of the questions on business requirements and processes are answered. These business requirements and process questions usually begin with word "what."

There are two very important concepts in the problem space: what and answered. First, we want to research the problem. To successfully research a problem we need to research questions that describe what the user needs to accomplish, what the system needs to accomplish and what the interaction requires. All these questions take the form of defining the problem by identifying answers to questions beginning with word "what."

These problem space questions are documented as requirements such as business rules, actor driven process definitions (called use-cases), and system wide requirements. The main goal is to answer all of these questions to a reasonable point.

The second part of the problem-solution confusion is solution space. Solution space is the area of software engineering where solutions to a problem are developed. In solution space you capture concrete responsibility and design through models such as storyboards, class diagrams and object interaction diagrams. All of these pictures strive to answer questions that begin with the word "how".

How do you research problem space without getting away from the problem and into the solution space? You gain focus by working on the problem from the user's prospective not from the prospective of any past, current or future solution. Good problem space describes quantitatively what problem the user has asked us to solve.

For example, notice the different between the following two requirements.

1. Within an hour an e-mail containing a Microsoft Excel delimited file attachment shall be sent to the purchasing director that contains the item numbers which were received from a vendor during the use of the receiving screen scr_R0345.
2. Purchasing, Sales and Accounting all need to know about receipt of inventory to perform follow on processes. This notification shall occur no later than one hour to maintain the cycle time reduction goals of the company.

The first requirement is definitely solution space because it goes beyond the requirement or definition of a problem into how it is solved. The last requirement does a good job of defining the problem only. Focusing on the requirements and not the solution is the basic difference between problem and solution spaces.

If you can focus on only the problem in problem space and solution in solution space you set up a nice provider-consumer relationship that will benefit object-oriented project teams. You will start to see a clearer light at the end of the tunnel and an end to the analysis and design efforts that seem usually to go on forever.

So now that we are getting accustomed to problem and solution space, who performs this work? It is my experience that one person or group should research the problem. I call these people analysts. Another group should produce a solution that meets the requirements documented in the problem and propose a complete solution. This second group of people I call designers.

You will find that although these people work two sides of the same coin they have specialized skills. The analysts need to relate well with business and other IT people while utilizing skills like facilitation and consensus building. The designers need to have a problem solver mentality as well as understand the tools and technologies available for use with the solution.

Performing Analysis in Problem Space

What techniques allow analysts to work in problem space effectively? Experience has shown that you need five things to document most analysis of problem space.

1. A clearly defined problem statement and project charter helping put a rough edge on the scope of the problem space to be researched.
2. Use case diagram (also known as a context diagram) illustrating how the business users (actors) and external systems interact within the problem space and how the use cases once generalized interact with each other.
3. Use case(s) describing the primary and alternate ways the actor(s) use the system.
4. A requirements traceability matrix to list and document all requirements and show how they relate to other artifacts.
5. (Optional) Contracts to document the discrete responsibilities each part of the system must perform to work in concert to produce the common desired result.

All five of these documents together answer all of the problem space and work to produce a clear and concise picture of the problem to be solved and the requirements to be implemented. After this progresses to a comfortable and reviewed state, design can start.

Performing Design in Solution Space

The designer needs to be able to synthesize a problem to produce an efficient and complete solution. The solution space should be filled with lots of models. These models describe for construction, verification and implementation people how the problems are being solved and how the requirements are being met. Remember those questions begin with the word "how."

Many people learn a lot from a graphical representation of the solution but the designer also needs to document the solutions to the problems in written form. The written form will serve as a checklist to prove that the problem space and solution spaces are completely overlapping. When reviewing a design this checklist is sometimes the only way to determine completion of the solution space questions.

What techniques serve to produce a well-documented design? The following all are used at some point to design a project. Each of the following deliverables serves a purpose to document part of the solution space.

1. Class diagram containing all responsibilities (methods), relationships, attributes, and abstractions of the solution. This answers the question of how the code segments to produce the desired solution.
2. Sequence based object interaction diagrams (OIDs) to document the implementation of contracts, essential system behavior, and complex or creative solutions to a problem. This answers how the code works together to solve the problem. It can serve as a roadmap for construction and repair of the software system.
3. Collaboration based object interaction diagrams (OIDs) to document the timing and dependencies (sometimes referred to as coupling of code) of the system. This answers what code is needed to be in place to implement a solution.
4. State-Transition diagrams to document both the transition of the user interface through different states as well as complex portions of the code, which progress through different states. This answers how different parts of the solution work together to produce the desired system behavior.
5. Storyboards to illustrate how the user interface will function. These document how the user will interact with the solution.
6. Updated Requirements Traceability Matrix to show how and where each problem space requirement is met in the solution. This is a cross-reference between the problem and solution space documentation.

Transitioning from Problem to Solution Space

Even bigger to solving the problem of problem versus solution space is the transition period. Although the problem space artifacts exist there needs to be some method of clearly making the transition from problem to solution space. The following describes a proven series of techniques to get the problem and solution space transition performed.

Review all use cases and the context diagram content to determine if 70-80% of the problem space is addressed. This assessment is based on your current understanding of the problem. Remember that you can iterate and repeat this entire process if you learn more during the process.

1. Review all requirements and contracts to determine if they discuss the problem, are not a direct solution and are verifiable.
2. Produce a candidate class list by performing noun analysis on the use cases. Noun analysis involves identifying unique nouns in the use case documents. Once all nouns are discovered all attributes, synonyms (including business language synonyms), data types, and derivable attributes (like date-range or average cost) are removed.
3. Take the remaining candidate classes and use them with the use-cases in a CRC (class responsibility and collaboration) exercise. Using the use cases you assign (in business user language) which candidate class has the responsibility, collaboration, and information (attributes) to implement a process flow described in the use case(s). This normally involves multiple classes and lets the analysis and design people work together to translate the problem space language into design language. All of this documentation can be produced on 5x7 index cards as the CRC process describes.
4. Remove any empty or collaboration only classes.
5. Create a class diagram called an "analysis class diagram" from the resultant CRC cards. With documented relationship dependencies from the collaborations.
6. Use the analysis class diagram as a guide to sub-divide the work (componentize) and begin producing the design (solution space) artifacts for each documented responsibility, contract and requirement.

Conclusion

I have described how using object-oriented analysis and design can produce a problem-solution confusion called analysis paralysis. Remember that this paralysis comes from not understanding three basic principles:

1. Problem space and solution spaces are different.
2. Problem space describes questions that begin with the word "what" while solution space describes the questions that begin with the word "how."
3. Using noun-analysis, CRC and use cases, you can transition from problem space to solution space naturally.

Investigate the artifacts and processes that I have described in this article. Work to get your processes and team members better focused on which part of the project they are working: problem or solution space. This clarity will help produce faster, easier and more complete projects. The downstream processes of construction, verification and implementation will be better off with this avoidance of problem-solution space confusion.

This article was previously published in the Journal of Conceptual Modeling published by InConcept. Visit the Journal of Conceptual Modeling by clicking here.