The analysis phase has the deliverable to come up with a starting point for the rest of the project. Remember, it doesn't lead to a fixed plan! It's just an initial guide kind of thing. Both customer and developers will change their minds later on, you can safely bet on that.

Problem domain

The first thing to do in the analysis phase is to determine the problem domain in detail. The functional decision maker and the customer sit together and write down a description of the problem domain. This description shouldn’t be longer than one page.

An initial problem domain class diagram can be constructed with the customer, since he knows his own business best.

From the problem domain and the concept, a list of functional requirements is derived that describes what the application should do to fit the concept within the domain. These requirements are described using use cases and stories, which are prioritized.

This prioritization should lead to the decision whether to deliver the system in increments or not, depending on the wishes of the customer. Wait with the exact dates and detailed functionality of these increments after the functional design is constructed.

Now is the time to put together an initial team of developers that will help constructing the functional, technical, interaction and creative design. These are the bare necessities for a developer to start of with the next phase: the development phase itself.

Functional design

From the requirements list and the initial class diagram, a functional design is derived, preferably by the functional decision maker (that is, if he is not the customer). This can be done using the template FD document by the same author.

This is an initial FD, from which an initial project scheme will be made. In this FD problem domain class, use case package, use case and sequence diagrams are present.

After completion of the initial FD, plan a meeting with the developers to discuss the contents. Let them estimate the complexity of each use case and story. This will supply some insight in project duration.

Verify the correctness of the FD with the customer directly.

Initial creative design

Since the user interface is really important, the look & feel of the application should be determined in an early stage of the project. Parallel to the construction of use cases, the initial user interface guidelines should be determined.

The Design Brief

These guidelines have a lot to do with the emotion that the users of the system should experience. Therefore, it is best to send one of the designers to speak with the customer directly. It is one thing to have a functional decision maker in the team, but to translate emotion is hardly possible. This designer returns with enough information to complete the Design Brief.

By the way, the technical boundaries of the system associated with design (for example, which browsers do the users support) should not necessarily be determined by this designer, but should already be in the technical design.

The use of the Design Brief should result into one or a couple of pages that represent the feeling that the customer wants his application to have. These pages together are called the Design Template. In this template, the most important design elements are shown.

It is recommended that that just one type of design template is made, which should be adjusted according to the customers’ wishes. If more than one design is offered, the customer mostly applies for a combination anyway. This is a lot of extra work for the designers and gives a nasty competitive edge to the creative process.

Design Comps

Finally, a couple of pages of the future system are simulated, that are used as a guideline by the interaction designer to construct his interaction design. These mock-ups of the future web GUI are called design comps.

Interaction design and prototyping

The use cases (not necessarily the stories) and sequence diagrams are handed over to a creative person in the team who is or acts as an interaction designer. He uses the use cases to construct an outline of the navigation of the future system, the navigation map. Most of the pages on this map are already defined functionally in the use cases or in the sequence diagrams, especially if the WAE for UML has been used.

The interaction designer then composes pictures of each and every page. He defines where the input fields are, in which order, where the buttons are, the logos and everything else I can’t think of right now. These pictures, preferably digitized but under schedule pressure sometimes even hand-drawn, are called the Interaction Design. The Interaction Design is a key feature, and not just in WUP. During this process, the interaction designer keeps an eye on the style guidelines as defined in the comps by the creative designers too.

The next step is to create functional prototypes for each of those pages. This process results in a series of semi-interactive HTML pages that supply guidance for the developers that have to build the presentation part of the application. Take careful note of the implications of building these prototypes on the schedule: if the schedule is tight, use the ‘paper’ interaction design and forget the prototypes.

Both the navigation map and the interaction design are a powerful tool to show the customer what his application will look like. Let the functional decision maker comment on them and adjust them if necessary.

Technical design

Along with the initial design, the technical design can be started (for example using the TD template document ). This can be done by anyone from the technical developers. However, this person should have participated in the meetings that were about the functional design.

The technical design is relatively simple: the class model is directly defined from the problem domain class diagram and the rudimentary functionality of the system. The same goes for the data model.

It is no use to define in more detail. The technical design will be an initial guideline, but as the project rolls it will serve more and more as documentation instead of a guideline. In practice, solutions for problems can be figured out on the job by those who are best at this: the developers. So, during development the technical design will follow the developers, not the other way round.

One person of the technical developers should be given responsibility for keeping an eye on the TD staying up to date during the project. Every developer is responsible for the changes in TD: every time he changes something that affects the TD, he should change the TD.

Planning increments

After completion of FD, TD and initial design, a detailed project planning can be constructed.

The functional decision maker defines at the beginning of an increment which use cases should be build, based on business value, complexity and the speed of realization of the developers.

An increment is planned using the following set of actions:

• Determine which use cases and stories you need to end up with a successful product;
• Let the designated seniors estimate the PPD’s for each story and use case;
• Priorities use cases and stories;
• Estimate the speed of realization for each team member;
• Define an increment release date;
• Pick the use cases that fit in the development period according to the team’s capacity and the deadline, starting with the ones with highest priority;
• Do some risk analysis based on the chosen functionality (what can go wrong?).

Do not forget that the first release period requires more time than the rest of them, because a couple of initial things have to be taken care of. Think about the initial classes, database and of course the technical development environments, software and so on.

Furthermore, internal release cycles can be planned for. Internal releases are the releases in which the system is deployed on the test environment on a regular basis. At the moment of deployment, the development stops. This is the start of a short integration and functional test period in which the whole team takes part, thus preventing ending up with a load of bugs at the end of the increment. It is recommended to do such a test release at least every two weeks, or even every week when you are on a tight schedule.

Ready to go

Now we are ready to do some coding.