3.2 Domains and Requirements

Requirements"-->

Dividing a system into its subject matters helps us control an undifferentiated mass of requirements by assigning each requirement to the appropriate domain. Domain requirements then drive the modeling for each domain.

When we model a domain, we use the vocabulary of that domain and no other. The bookstore domain will include concepts such as "add item to order" and "provide credit card number," but there is no statement of how these behaviors might be achieved. The domain modeler assumes that somewhere, somehow, a collection of mechanisms exists that can satisfy these statements.

For our purposes in organizing modeling, we want to work with requirements that affect a single domain. The vocabulary of a domain-level requirement is completely within the subject matter at hand, and each domain-level requirement employs a vocabulary consistent with the domain. But consider the following typical requirements:

Add item to order: The customer selects a book from the catalog page by specifying a quantity in a text box and pressing the Add Item button next to the catalog entry.

Check out order: A returning customer simply enters his account number and password. The password appears as a row of asterisks. The order is then processed using the credit card and shipping address already on file for the customer.

These requirements commingle application and user interface vocabulary. (The latter is shown in italics.)

With knowledge of the potential domains in the system, we can partition these system-level requirements, allocating each to an identified domain. The first requirement above becomes two separate requirements, each for a single domain:

Online Bookstore: Customer adds an item to an order by specifying a book and quantity.

User Interface: The catalog menu allows selection of items and quantities via a page containing a table with a check box, a text box, and a button on each row.

Each individual domain-level requirement applies to a single domain, so that modeling for each domain may proceed. Working by domains not just by individual requirements or functional areas helps avoid fragmented systems that fail to exploit opportunities for commonality and reuse.

If you have no prior knowledge of the domains in the system, you can still partition requirements based on their distinct vocabularies. For example, the partitioned requirement for the preceding user interface example still contains two vocabularies, one associated with a GUI toolkit with pages, tables, check boxes and the like; and another separate domain, an application user interface that identifies the specific kinds of menus, such as the catalog menu. Separate these into two domains:

(Application) User Interface: A catalog menu allows selection of items and the selection of quantities.

(HTML) GUI: A page contains a table with a check box, a text box, and a button on each row.