4.2. Process

Analysis concerns describing the user requirements (the problem description), and design concentrates on creating a solution that meets the requirements (the solution definition). The exact boundary between the two is hard to determine, especially with iterative development. A feedback cycle occurs between the two phases.

Objects created in the design phase often reflect the real-world objects referred to in the requirements. If you state the object definitions in the requirements clearly, the software object definitions will be clear as well. Lack of clarity in what the software objects really should do feeds back into requirements clarification . For Sam's system, understanding the difference between a CDDisc and a CDRelease not only clarifies the requirements, but also yields two potential classes. As the CDDisc class is developed, questions regarding how its methods should work might help discover ambiguities in the requirements. ^[*]

^[*] The design classes might not reflect the classes in the requirements precisely. They might differ by behavior, services, attributes, or relationships. However, the requirement classes do form a good initial starting point for the design classes.

4.2.1. Analysis Paralysis

Analysis paralysis occurs when you become stuck trying to complete your understanding of the requirements to be implemented. You become so stuck, always feeling that you need to learn yet one more thing, you cannot move on to design.

Gary K. Evans, a reviewer, points out, "Another cause is fear: fear that you might miss something. Some people have personalities that force them to try to anticipate and plan for every possible event before they are willing to move forward. Some organizations create cultures of impossible expectations where any failure is regarded severely, so people adapt by staying in the analysis mindset as long as possible. Some development processes force issues up-front that should not be considered until much later in the process, because the process tries to 'control away' the fear of failure."

You do not want to spend a lifetime specifying your system requirements. Nevertheless, you should spend some time understanding the basic abstractions, the basic use cases, and how everything interacts .

One cause of analysis paralysis is trying to specify every detail in a system. Some details are important, and others aren't. Determining what is important at each development step is key. Deciding what details are essential and unessential can be difficult. I found a few suggestions to be helpful. Any details dealing with appearance are unessential. You do not need to know the text for a label of a dialog box until you code it. Implementation details are usually unessential ”for example, the particular database that will be used (Oracle or MySQL). The relationship count between two concepts is usually essential ”for example, whether the relationship between CDDisc and CDRelease is one-to-one, one-to-many, or many-to-many.

Experience can help distinguish between the essential and unessential details. Examine your previous projects to determine which details discovered after the start of design and coding created major changes in the design.

4.2.2. Design Paralysis

Similar to analysis paralysis, you can also suffer from design paralysis . You are suffering from design paralysis if you do not want to start coding until the details of every class are determined. (Some people use the same term , analysis paralysis, to describe both of these situations.) One way to determine if you have a sufficient class design is to work through the use cases using the classes you created. If you can perform all the use cases, it's highly probable that you have captured the meaningful classes.

To work through each use case, you can create a Unified Modeling Language (UML) sequence diagram. An alternative fun way to perform the use cases is with a group of developers. Each developer takes on the role of one or more classes. One developer reads the use case, pausing at each step. The developers for the classes participating in the use case acknowledge the responsibilities of their classes in implementing each step.

Due to changes in requirements, a design might have to be changed. There is probably no fixed set of requirements for any given system. ^[*] However, the overall design that you create at the beginning should at least fulfill the initial use cases.

^[*] Changes in requirements are inevitable. Capers Jones (http://www. softerra .com/files/conflict.pdf) suggests that requirements change at a rate of 1% or more per month.

SAILING THE WAVES

When windsurfing over a series of waves, you need to think about the upcoming waves even while you are riding the current one. If you fail to do this, you might find your board's tip submarining into a subsequent wave, causing an unpleasant fall.

You know the waves will change, especially the ones farther away, but you are not sure how they will change. So the best you can do is to sail the current condition of the wave and be prepared to change your plans when the waves change.