be said about the importance of getting it down and basing architectural decisions off of it--decisions that will impact the rest of the project going forward.
Let's say your project team is using SCRUM or XP and producing user stories, and you have a healthy backlog in place to drive the next several sprints (i.e., iterations). I suggest pulling your product owner/customer's high-priority user stories from the backlog and creating an initial class "blitz" from the backlog. A class blitz is nothing more than quickly sketching out, in a low-tech fashion, the analysis classes identified from the requirement models produced to date. If the team has produced a conceptual data model-even a sketch or rough draft of it-you're that much better off.
Architects and developers on an agile project are already part of the delivery team, so nothing should be "thrown over the wall" to you. People in this position should think about design each day.
I blitz a high-level class diagram from the backlog. This is primarily driven from the nouns I find in the backlog of user stories. These eventually become entity classes. (The unified modeling language (UML) suggests three types of classes: entity, control, and interface.)
If the delivery team has given any thought to themes (some functional area, user group, story group, or anything else that makes sense for the product owner ), then that theme is an early indicator of a possible class or classes that will act as the software "conductors" for the related stories. If themes are absent, as designer you need to find them. Why? Themes become essential to your design: they are the control classes. Control classes provide for the demarcation point where transactions begin and end. They coordinate with the other classes to ensure the business rules are enforced. Should something go wrong along the way, it's the control classes that roll back any changes that have been made as a result of the transaction.
Once you understand the design structure with classes, you should explore interactions with a bit of sequence diagramming. A sequence diagram illustrates how your classes carry out the work specified in user stories. In most cases, you only need to create sequence diagrams for the highest-priority stories. Remember, on an agile project you want to eliminate waste (unused artifacts) and rework. So fewer sequence diagrams should be your mantra; focus on those that will help you visualize the design flow prior to coding.
While I have seen marvelous results with agile projects, I also see a very high amount of rework done as a result of not having a clear understanding of the overall architectural pattern the application will follow.
I recently worked on a project where there was disagreement on how the data retrieved from the backend database would be delivered to the other objects in the design. At the center of the debate was whether or not the data should be delivered as a Microsoft dataset object or as a lightweight class that wrapped the data. It wasn't until the third sprint that reason won out and the lightweight-class approach was chosen. It turned out that two other projects in a different department had already made the same decision on prior projects. Teams must stop, pause, consider, and decide. A fair amount of heavy lifting was required to go back and modify the code from the first three sprints as a result of this late architectural decision. I know some readers will say that agile methods accept rework as part of the planning for future iterations. That said, a small amount