Analysis Review

In this section, we zip through the modeling activities that took place to analyze the domain model and use cases for release 2 of the mapplet (focusing on the “Filter Hotels” use case).

Robustness Diagrams

Figure 8-4 shows the robustness diagram for the “Filter Hotels” use case.

Figure 8-4: Robustness diagram for the “Filter Hotels” use case

As you can see, this diagram covers two basic scenarios: filtering by amenity and filtering by hotel chain.

MODELING QUESTION: WHAT IF A USE CASE CHANGES HALFWAY THROUGH A RELEASE INCREMENT?

Once development begins, a mid-development change would likely cause hacking of the code to shoehorn the last-minute changes into a system that was designed for something else. So an understandable reaction to this problem is to forbid changes to the requirements once the design and programming stages are under way. This is the dreaded requirements freeze that agile methodologies generally stick their noses up at.

In “old-school” waterfall projects with iterations of 6 months or more, requirements freeze would have been a serious problem (and often was, with large systems delivered that went wide of what the customer really wanted). But keeping the iterations short (a month or less) reduces the problem.

Agile methodologies handle this in different ways. In the Scrum process, for example, the requirements are absolutely not allowed to change during a monthly sprint. The requirements can be juggled around and changed only at the start of the next sprint. Alternatively, XP actively embraces change, whether midway through an iteration or not.

In ICONIX Process, use cases aren’t frozen until you’ve completed robustness analysis.You expect that the first-draft use case will change (i.e., it will be revised and improved) during the disambiguation phase of design. So ICONIX Process not only allows the requirements to change, but also expects them to change (and pretty much demands that they have any ambiguity squeezed out of them) in the middle of each release increment.

In other words, in ICONIX Process, you don’t baseline the behavior requirements until you’ve done a bit of exploratory design—at the conceptual design level of abstraction. When you’re applying ICONIX Process in an agile context, each release includes requirements definition (first-draft use cases), requirements analysis/preliminary design (robustness analysis), and then detailed design (sequence diagrams).

You hope that the use cases don’t change in the middle of detailed design—but if they have to, then they do, and this is still preferable to coding up incorrect requirements and then ripping out the incorrect code later.