Section 6.4. AnalysisDesign Innovations

6.4. Analysis/Design Innovations

6.4.1. Requirements Analysis Innovations

Plan-driven activities like use case analysis and other UML tools need modification to fit into agile methods. Agile Modeling is a strategy for developing these models within agile philosophies. The core of Agile Modeling is that there are two purposes for modeling: understanding and communication. For example, one Agile Modeling practice is "Iterate to Another Artifact" and advocates changing the type of model you are working on when you are having difficulties because the change in perspective can help resolve issues. Similarly, the practice of "Create Simple Content" advises keeping the audience of the model-building activities in mind and only modeling to the level of detail that the audience requires. Following Agile Modeling practices can help ensure that the time spent developing (and possibly maintaining) models is valuable.

As an alternative to traditional requirements gathering, some agile methods develop Automated Acceptance Tests. These tests specify the external behavior of the system, often in ways a customer can understand, and they can be run automatically at regular intervals to ensure that the system meets those requirements. Having the customer develop these tests, as XP advocates, ensures that the tests encode the customer's requirements. If anyone asks, "What should the system do under these circumstances?" the answer can be found in the appropriate acceptance test.

6.4.2. Design Innovations

As with requirements analysis, Agile Modeling allows traditional UML designs to be used in a more agile way but does not ensure that the models match the code. An extreme version of Agile Modeling is Whiteboard Design, which advocates creating models on a whiteboard in support of a design discussion. These models have only the detail required by that discussion. When the engineers finish the discussion, they record the model by taking a photograph or using a recording whiteboard. Although these records are kept for reference, there is no expectation that the code will continue to match the design in the long term. In this case, the models are truly a mechanism to support the design process but are not documentation of the resulting design.

In situations where it is important to maintain accurate design-level documentation, Closed Circuit Engineering may be an appropriate choice.

Basic structural documentation with some usage documentation can easily be generated from comments in the code using Automated Documentation Generation like that provided by javadocs. These hyperlinked documentation hierarchies can provide the high-level view of the system that has traditionally been provided by design documents. However, because it is generated from the code itself and by comments in the code, it is more likely that engineers will keep the documentation up to date. Although the structural documentation generated is thorough, the behavioral documentation depends on the level of detail that engineers build into the comments.

Test-driven Development (TDD) takes a completely different view of design and design documentation. In TDD, automated unit tests are developed (only slightly) ahead of the code. In a sense, these tests document the design of the system because they specify how the engineer expected the code to be used. For example, a banking system could have an "Account" class that another class needs to interact with in order to make a deposit. The engineer developing the other class can look at the unit tests for the Account class to find code that makes deposits, rules about what kinds of deposits are supported, and what error conditions the code detects. In this way, these unit tests document not only the structure of the system (what methods exist in which class) but also behavioral patterns within the system (how a class will react to various method calls).

In situations where there are multiple strategies for how to address a requirement, an Impact Estimation Table is a technique that weighs the costs and benefits of each option to help in the selection of a technique. This is a somewhat time-consuming activity that should rarely be required, but it is sometimes useful. An alternative to selecting a single design is to use Set Based Decision Making to keep as many options open as possible. Because we are designing for the current iteration, keeping options available will help in later iterations. However, it's important to note that this does not mean we implement a design that contains functionality not required in this iteration. It is a technique based on delaying decisions until the last possible moment.