In the wildly fluctuating state, the answer is "Are you kidding? Who knows what this will be like in two weeks!"
In the varying state, the answer is "Somewhat similar, but of course the details are likely to change."
In the relatively stable state, the answer is "Pretty likely, although a few things will probably be different."
Other ways to determine the stability may include measuring the "churn" in the use case text, the diagrams, the code base, the test cases, and so on (I have not tried these).
Figure 4-5. A project map: a low-precision version of a project plan.
Precision
Precision is a core concept manipulated within a methodology. Every category of work product has low-, medium-, and high-precision versions.
Here are the low-, medium-, and high-precision versions of some key work products.
The Project Plan
The low-precision view of a project plan is the project map (Figure 4-5). It shows the fundamental items to be produced, their dependencies, and which are to be deployed together. It may show the relative magnitudes of effort needed for each item. It does not show who will do the work or how long the work will take (which is why it is called a map and not a plan).
Those who are used to working with PERT charts will recognize the project map as a coarse-grained PERT chart showing project dependencies, augmented with marks showing where releases occur.
This low-precision project map is very useful in organizing the project before the staffing and timelines are established. In fact, I use it to derive timelines and staffing plans.
The medium-precision version of the project plan is a project map expanded to show the dependencies between the teams and the due dates.
The high-precision version of the project plan is the well-known, task-based GANTT chart, showing task times, assignments, and dependencies.
The more precision in the plan, the more fragile it is, which is why constructing GANTT charts is so feared: it is time-consuming to produce and gets out of date with the slightest surprise event. Behavioral Requirements / Use Cases Behavioral requirements are often written with use cases.
The lowest level of precision version of a set of use cases is the Actors-Goals list, the list of primary actors and the goals they have with respect to the system (Figure 4-6). This lowest-precision view is useful at the start of the project when you are prioritizing the use cases and allocating work to teams. It is useful again whenever an overview of the system is needed.
Figure 4-6. An Actors-Goals list: the lowest-precision view of behavioral requirements.
The medium level of precision consists of a one-paragraph brief synopsis of the use case, or the use case's title and main success scenario.
The medium-high level of precision contains extensions and error conditions, named but not expanded.
The final, highest level of precision includes both the extension conditions and their handling.
These levels of precision are further described in (Cockburn 2000).
The Program Design
The lowest level of precision in an object-oriented design is a Responsibility-Collaborations diagram, a very coarse-grained variation on the UML object collaboration diagram (Figure 4-7). The interesting thing about this simple design presentation is that people can already review it and comment on the allocation of responsibilities.
A medium level of precision is the list of major classes, their major purpose, and primary collaboration channels.
A medium-high level is the class diagram, showing classes, attributes, and relationships with cardinality.
A high level of precision is the list of classes, attributes, relations with cardinality constraints, and functions with function signatures. These often are listed on the class diagram.
The final, highest level of precision is the source code.
Figure 4-7. A Responsibility-Collaboration diagram: the low-precision view of an object-oriented design.
These levels for design show the natural progression from Responsibility-Driven Design (Beck 1987, Cunningham URL-CRC) through object modeling with UML, to final source code. The three are not in opposition, as some imagine, but rather occur along very natural progression of precision.
As we get better at generating final code from diagrams, the designers will add precision and code-generation annotations to the diagrams. As a consequence, the diagrams plus annotations become the "source code." The C++ or Java stops being source code and becomes generated code.
The User Interface Design
The low-precision description of the user interface is the screen flow diagram, which states only the purpose and linkage of each screen.
The medium level of precision description consists of the screen definitions with field lengths and the various field or button activation rules.
The highest precision definition of the user interface design is the program's source code.
Figure 4-8. Using low levels of precision to trigger other activities.
Working with "Precision"
People do a lot with these low-precision views. During the early stages of the project, they plan and evaluate. At later stages, they use the low-precision views for training.
I currently think of a level of precision as being reached when there is enough information to allow another team to start work. Figure 4-8 shows the evolution of six types of work products on a project: the project plan, the use cases, the user interface design, the domain design, the external interfaces, and the infrastructure design.
In looking at Figure 4-8, we see that having the actor-goal list in place permits a preliminary project plan to be drawn up. This may consist of the project map along with time and staffing assignments and estimates. Having those, the teams can split up and capture the use-case briefs in parallel. As soon as the use-case briefs—or a significant subset of them—are in place, all the specialist teams can start working in parallel, evolving their own work products.
One thing to note about precision is that the work involved expands rapidly as precision increases. Figure 4-9 shows the work increasing as the use cases grow from actors, to actors and goals, to main success scenarios, to the various failure and other extension conditions, and finally to the recovery actions. A similar diagram could be drawn for each of the other types of work products.
Because higher-precision work products require more energy and also change more often than their low-precision counterparts, a general project strategy is to defer, or at least carefully manage, their construction and evolution.
Figure 4-9. Work expands with increasing precision level (shown for use cases).
Stability and Concurrent Development
Stability, the "likelihood of change," varies over the course of the project (Figure 4-10).