I wrote previously about Actors, Actions, Objects and Attributes when writing requirements. Although there are common ideas in different description techniques, this has nothing to do with object orientation per se.

There are many ways to describe a system:

1. •Aggregation;
   

2. •Relationships;
   

3. •Inheritance;
   

4. •States and transitions;
   

5. •Messages and sequences.
   

Some of these techniques describe system behaviour, most of them describe systems from a purely static view.

When it comes to requirements, we are primarily interested in two perspectives:

1. •System behaviour;
   

2. •The attributes (properties) of the system.
   

We are not primarily interested in describing relationships between system entities, although we can do this if we need to. Relationships and aggregations are mostly addressed during architecture and design activities.

When we describe behaviour, we have three fundamental building blocks:

1. •Actors who initiates transactions in the system;
   

2. •Actions who describes the transactions;
   

3. •Objects who receives the Actions, or is subjected to the Actions.
   

Actors are entities in the system. Many writes “The System” in their requirements, which makes the whole system an Actor. I try to persuade people to be more precise. It is often better to write the “Firewall”, or the “DHCP server”, or the “Database Client” from a readers perspective; it increases the understanding of the requirements. Actors can also be human beings, such as “the User”, “the System Administrator”, or even “the Customer”. Actors are always nouns.

Actions, on the other hand, are verbs. When you work with Graphical User Interfaces, you learn that all controls (buttons, check boxes, menus) start with a verb, such as “Open”, “Save”, “Show”, or “Print”. Verbs are an excellent way to describe behaviour.

Objects are also entities in the system. Entities can be Actors in one requirement and Objects in another. Objects fulfill another important role: they describe key properties of the system. When we describe system properties, we use:

1. •Objects;
   

2. •Attributes and their values.
   

An Object has an Attribute who has a value, for example:

1. •The Dispenser weights 650 kg.
   

2. •The font process colour is Pantone 125.
   

3. •The Radar frequency is 3.5 GHz.
   

In all these requirements, we have Objects (Dispenser, Font, Radar), attributes (weight, process colour, frequency) and values (650 kg, Pantone 125, 3.5 GHz).

I use the present tense when I write requirements (you may have noticed this). I think it gives simplicity. If I must write “The Firewall shall block ...” instead of “The Firewall blocks”, it only adds clutter for a reader.