Initial Modeling
During Cycle 0 you will likely be required to do some initial requirements and architectural modeling (see www.agilemodeling.com/essays/amdd.htm) for several reasons.
- First, the prioritized stack of requirements that you implement during development iterations/cycles has to come from somewhere.
- Second, you need a basis for your initial cost and schedule estimates.
- Third, you need to have at least an initial consensus as to the architecture to build your project team—it's of little use staffing your team with Java experts if you're building the system using mainframe COBOL.
When building business applications, I've found that the initial requirements modeling effort needs to focus on the development of a high-level usage model, a slim domain model, and a user interface (UI) model. The process that you're following drives the choice of your usage model—an XP team creates user stories, whereas an Agile Unified Process (AUP) team writes point-form use cases. The domain model should identify the main business entities (Customer and Account in a bank, for instance) and the relationships between them. During Cycle 0, you don't need to identify either the data attributes or the behaviors of the entities—this level of detail will be identified on a just-in-time (JIT) model-storming basis during development cycles. For the UI model, you may just need to draw a few whiteboard sketches of critical screens or you may need to do some UI prototyping, something you want to do after identifying the actual platform you'll be deploying to. The UI is the system to your stakeholders, and you need to convince them that you are able to understand their needs and deliver something usable that meets those needs. For complicated systems, a UI flow/navigation diagram may also be needed.
The goal of your initial architecture modeling effort is to try to identify an architecture that has a good chance of working. This is often done by the technical people on the team working together around a whiteboard, sketching and discussing what they believe will work. At this point, your goal is to come to a shared understanding of a reasonable architectural strategy, it is not to create mounds of documentation. As we identify the initial architecture, we'll try to ensure that it reflects the realities of the enterprise architecture, something that is much easier to accomplish when one or more enterprise architects roll up their sleeves and get actively involved with our project.
