Business areas

Business areas group related work, such as customer management or scheduling. The interface calls them Modules. One area can contain several functions and pages; the offer allowance counts areas rather than individual screens.

Before you start — Identify the business process to group and review the areas already present. Check the offer allowance before adding scope. An area should have a clear purpose, even when its workflow uses information from another area.

Review the available areas

Read an area’s purpose before interpreting its function and page counts; the count alone does not explain the agreed scope.

1. Open Modules.
2. Read the area name, Status, function count and page count.
3. Click Configure on the area concerned.
4. Review its purpose and the associated application or administration functionality.

The selected area gives context to its analysis, pages and construction. Use Refresh when you want the list to read the latest state.

Create a business area

Name the area after a coherent business responsibility and describe the tasks that make that responsibility useful.

1. Click Create a module.
2. Enter Module name, using a name distinct from the existing areas.
3. Fill in Module description and Module purpose with the user tasks it should cover.
4. Click Create the module.

Note — Once your modules reach the offer allowance (included modules plus any additional modules ordered), the button reads Order a module instead and opens the one-time order for one additional module. See Project offers.

The area is created and its preparation can begin. For example, describe the booking actions and rules, rather than writing only “booking”.

An orders area might contain a list, an order record and confirmation actions. They belong to one business responsibility even though several pages are involved. A separate stock-management responsibility should be reviewed as part of the project scope rather than inferred from one order page.

Resolve questions before construction

A question identifies a decision needed before the area can be built reliably; answer it in its own context.

1. Open the area and look for Waiting for information.
2. Click Answer on the relevant item.
3. Explain the expected rule in Your answers, then click Submit my answers.
4. Return to the area and follow the updated preparation state.

The response is attached to the area and its next preparation state is visible.

See Clarifications for examples of a useful answer.

Prepare the data storage when requested

Complete this prerequisite only when the area requests it, then verify the installation result rather than repeating the request.

1. Open the area's overview from the application tools.
2. Read the Database state.
3. When Database to create is offered, click Create.
4. Review the confirmation page, then click Create the database.
5. Return to the area to check the resulting state.

The overview confirms the resulting storage state or identifies the failure that still needs attention.

Note — Wait when another database creation is underway. If the attempt fails, read the displayed message and follow the available retry action; a requested creation is not yet a completed installation.

Follow the next evolution

An evolution describes a new business requirement; keep its purpose distinct from a correction to an existing page.

1. Open the area's evolution view.
2. Review the recorded changes and use Request an evolution when you need to describe a new requirement.
3. Explain the result you want and follow the request from its relevant project view.

The requirement is recorded with its area context and can be followed through the corresponding project work.

Important — Changes to the planned behavior and changes to a page already built have different entry points. Use Specifications for the planned scope and Studio for an existing page.

Resolve an area-readiness problem