System Design

You've spent a lot of time with the business experts, reviewing the specifications, and perhaps even talking with potential end users or end user surrogates. Your input to the system design may be valuable, especially if the business experts don't participate in design meetings.

Depending on your level of interest and expertise in system architecture and design, you may find design meetings tedious and hard to follow. Programmers and architects may go off on obscure tangents. If they're not practicing XP, they may be trying to see way too far into the future. Do what you can to tactfully help keep the meetings focused on what the customers need now. Be alert for developer misunderstanding of the requirements, and clarify the customers' needs. Make sure the business experts' criteria for quality are considered in making design decisions.

Raise the issue of testability in the design meetings. A system that's easy to test will get released faster. Think about how you'll test various parts of the system, and ask for features or hooks that might make it easier for you to write test scripts.

If the programmers didn't participate in creating or reviewing requirements, they might find a feature that would be difficult to implement. You can facilitate a conversation between business experts and programmers to make adjustments. This may produce something close enough to the business experts' needs more quickly than meeting the original requirement. In a traditional development shop, this may be the business experts' last chance to change their collective mind until after the first production release.