Step: Describe responsibilities

A responsibility is a statement of something an object can be asked to provide. Responsibilities evolve into one (but usually more) operations on classes in design; they can be characterized as:

• The actions that the object can perform.
• The knowledge that the object maintains and provides to other objects.

Each analysis class should have several responsibilities; a class with only one responsibility is probably too simple, while one with a dozen or more is pushing the limit of reasonability and should potentially be split into several classes.

That all objects can be created and deleted goes without saying; don’t restate the obvious unless the object performs some special behavior when it is created or deleted. (Some objects cannot be removed if certain relationships exist.)

Finding Responsibilities

Responsibilities are derived from messages in collaboration diagrams. For each message, examine the class of the object to which the message is sent.    If the responsibility does not yet exist, create a new responsibility that provides the requested behavior.

Other responsibilities will derive from non-functional requirements. When you create a new responsibility, check the non-functional requirements to see if there are related requirements which apply. Either augment the description of the responsibility, or create a new responsibility to reflect this.

Documenting Responsibilities

Responsibilities are documented with a short (up to several words) name for the responsibility, and a short (up to several sentences) description.  The description states what the object does to fulfill the responsibility, and what result is returned when the responsibility is invoked.