Indicate Primary or Secondary Behaviour

« Table of Contents »
Previous « Indicate Positive or Negative Behaviour

The Behaviour Specification Handbook

Effective Behaviour Specification Descriptions

Indicate Primary or Secondary Behaviour

A low-level technical design typically identifies the need for some components that are not immediately obvious from the core business requirements. Some software components in a solution may exist purely to enable or support the functionality of other components that are more obviously required. Similarly, even within a component that exists directly to fulfil a core business requirement, some behaviours within that component may exist purely to enable or support other behaviours.

To help team members better understand the solution and design, it can be helpful to distinguish between these two types of behaviours:

  • Primary Behaviours; and
  • Secondary Behaviours.

A Primary Behaviour is a behaviour that has been identified and defined as a direct result of attempting to fulfil a core business requirement. Examples of Primary Behaviours include:

  • Validation logic;
  • Notifications of expected error messages;
  • Business rules (including auditing);
  • Business errors; and
  • Workflow or routing logic.

A Secondary Behaviour, in comparison, is typically a lower-level behaviour required in the solution in order to enable or support the functionality of a Primary Behaviour. These types of behaviours typically are not thought of or identified by business people. A Secondary Behaviour is in no way less important than a Primary Behaviour — in fact, from one perspective, a Secondary Behaviour is more important because a specific Primary Behaviour is dependent upon and cannot function correctly without that Secondary Behaviour. Examples of Secondary Behaviours include:

  • Exception handling;
  • Transaction or data consistency concerns;
  • Data storage and retrieval;
  • Performance concerns; and
  • Logging functionality.

In my experience, including “Primary” or “Secondary” in the Behaviour Specification Description allows everyone reading the Behaviour Specification or test report to quickly and easily understand whether the behaviour exists directly to fulfil a core business requirement or is required due to lower-level, secondary concerns.

Next » Unique Within Their Feature File