Before digging deeper into the process itself, let’s define the WUP toolkit first.

Domain Classes

An entity is a functional unit that acts in the problem domain for which the web app is being build. In object orientation, the entities are translated in classes of the system. The Domain Class Diagram is the UML model in which these classes are shown.

The determination of the classes

A class model is determined through a series of steps . This is done in brainstorm sessions. Preferably, the whole team joins these sessions. If this is not possible, at least the functional decision maker and a couple of technical developers should be present.

• Identify all possible class candidates from the problem domain and use cases (if present);
• select the classes from the list of candidates;
• make a model dictionary;
• identify associations;
• identify attributes;
• identify operations;
• generalize using inheritance (Be careful! This is not supported by all programming languages);
• make constraints;
• iterate along these steps.

An example of a Domain Class Diagram

The result of the described session could lead to the following diagram. This simple example is taken from the design of an online sales system.



[this picture is based on an illustration by Martin Fowler]

Requirement description

The description of requirements of the systems can be divided in three parts: the use cases, their stories and the system requirements.

Use cases

The business requirements that describe the outside functionality of the system are defined in UML use cases. Use cases are short descriptions of the behavior of the system, from the point of view of the user. A use case describes explicitly the interaction between user or actor and the system, where the system is considered a black box.

A use case has a name, preconditions, a description, exceptions, post conditions and a priority.

The functional decision maker defines the use cases. He determines their business value and therefore their priority.

The use case list can be altered to a test list by reverting the use cases to questions. By asking these questions, the abilities of the system to satisfy the requirements can be checked easily.

Use case packages

The complete system functionality is described in functional parts or packages of use cases. One of these could be the client interface, or an administration module.

A package can be shown by means of a UML Use Case Package Diagram, as is done for an online sales system in the diagram below.



[this picture is based on an illustration by Martin Fowler]

Stories

In a use case, the system is considered a black box. This means that internal logic is not described or even mentioned.

In WUP, a use case has one or more stories. Careful, we use a different kind of story than XP does! Stories describe the steps to be taken within the system to realize a use case. Stories are not part of UML, but are part of WUP because it is a very direct way of describing what the system has to do.

The functional decision maker and the developers define the stories of each use case together, as opposed to the use cases themselves, which are defined by the functional decision maker. A story is a unit that can be implemented, and can be considered a direct task for the developers.

A story can be technical, but can also be meant to be dealt with by a designer or a writer. The functional decision maker should not be bothered with this distinction. The developers themselves sign up for realizing a use case or individual stories.

Story estimation

The developers estimate the complexity of each story and therefore the complexity of each use case. Each developer signs in to realize a couple of stories.

These estimates are expressed in PPD. A PPD means a Perfect Project Day or a day of development for a senior developer without external complications.

A story has, in general, a realization period with a maximum of 2 or 3 PPD. If the number of PPD’s is higher than that, the team should consider splitting the story.

Speed of realization

The speed of realization for different developer levels can be estimated like this:

• Senior 1 PPD/day
• Medior 0.8 PPD/day
• Junior 0.6 PPD/day
• Trainee 0.4 PPD/day

Using these assumptions, the duration of the project can be estimated considering the resources of the team.

It’s as simple as this: for each developing team member, multiply the number of days he or she is present each week by their specific daily speed. This leads to the number of PPD’s each week per person. Sum up these numbers for the whole team; this leads to the team’s week production. Divide the total project amount of PPD’s (all use cases summed up) by the team’s week performance. This results in the duration of the project in weeks.

If this duration doesn’t fit the deadline, use cases with low priority should be discarded from the to-do list. This procedure should be repeated until the list of use cases satisfies the deadline of the project.

For more information about this, take a look at the document duration estimation by the same author.

Priority

The functional decision maker has to determine the priority of every use case and every story.

The priority indicates which use cases are to be realized and which are not in the case of a limited number of PPD’s. To deploy before the deadline is more important than details in the functionality!

Priority P is quantified with an A, B or C.

• P = A This is core functionality. The system cannot exist without it.
• P = B The system could work without this piece of functionality, but it’s still relatively important.
• P = C If there are PPD’s left before the deadline exceeds, they could be spent on functionality with priority C, but it’s not a disaster if the functionality isn’t built.

Of course you could also use MoSCoW, or anything else.

Within a use case, the stories can accordingly be prioritized. Usually, the total priority of a use case reflects the average priority of its stories.

Notation of use case and stories

A use case with its stories could be found in a WUP Functional Design in the following notation.

Title
Actor
Preconditions
Relations
Description
Exceptions
Postconditions
Stories		P	PPD

The left-open fields must be filled in.

Use case diagrams

WUP does not use UML use case diagrams by default, since one of its first priorities is to supply a functional design that can be adjusted in the blink of an eye. Obviously, it takes more time to adjust pictures than plain text.

However, if a functional design has over, let’s say, 50 use cases, it is advisable to strategically add use case diagrams to get an overall view of certain parts of the process. The developers will thank you.

Sequence diagrams

A sequence diagram shows the interaction of the actor and the entities of the problem domain within a use case through time. This interaction is already implicitly defined in a use case and its stories, but the sequence diagram supplies a different view on each use case. The diagram relates the classes with the use case and the stories.

Apart from the problem domain classes, a sequence diagram uses web system classes if necessary. These system classes are usually defined in stories that tell from the interaction between business logic and presentation, for example. The business logic classes usually literally represent the problem domain classes, while presentation classes have limited system-related functions. These system classes represent objects like ‘server page’ , ‘form’ and ‘client page’.

Within sequence diagrams the WAE (Web Application Extension) for UML is used to define these web-related system classes. This extension uses metamodel classes or stereotypes that stand for the objects in a web architecture.

An example of a sequence diagram is shown of a use case that describes a part of an online sales system.



[this picture is based on an illustration by Martin Fowler]

System requirements

System requirements are technical requirements that describe the rules to which the system must comply. These system requirements are not related to any action of an actor and are thus described in the Technical Design.

System requirements can be described in textual format, and are about things like choice of platform, performance and so on.