Conceptual modelling refers
to specifying, visualizing, and documenting models of for instance the context
of use, a business model, or a software system. The perspective of the terms in
this category is rather technical.
Context of use
refers to the characteristics of the users,
tasks, and the organisational and physical environment. [ISO 9241-11] Context of use may also describe the
cognitive, motivational and emotional characteristics of the different users, tasks, cooperative behaviour, articulation work and
the organisational and physical environment. This is done out of observations
of real work and interviews, including the reflexive point of view of actors on their context of
use. Analyses the possible conflicts of interest or need between different
types of actors. Tries to anticipate different ways in which a new tool or
method could affect the content of the observed tasks and activities, including
the network and collaborative behaviour. Analyses both norms and practices.
Human-centred design activities (1) Understand and specify the context
of use, (2) specify the user and organisational requirements, (3) produce
design solutions, (4) evaluate design against requirements. [ISO 13407]
Human-centred design principles refer to (1) the active involvement
of users and a clear understanding
of user and task requirements,
(2) an appropriate allocation of function
between users and technology, (3) the iteration of design solutions, (4) multi-disciplinary
design. [ISO 13407]
The Unified
Modelling Language (UML) is a notation for specifying, visualising, and
documenting models of software systems,
including their structure and design. UML can be used for business modelling
and modelling of other non-software systems,
for instance ontologies.
[UML 2002]
UML diagram types
UML defines twelve types of diagrams, divided into three categories: Four
diagram types represent static application structure; five represent different
aspects of dynamic behavior; and three represent ways you can organize and
manage your application modules.
Structural Diagrams include the Class
Diagram, Object Diagram, Component Diagram, and Deployment Diagram.
Behavior Diagrams include the Use Case
Diagram (used by some methodologies during requirements gathering);
Sequence Diagram, Activity Diagram, Collaboration Diagram, and Statechart
Diagram.
Model Management Diagrams include
Packages, Subsystems, and Models. [UML 2002]
Actor refers to something with behavior (able
to execute an if statement). It might be a mechanical system, computer system, a
person, an organisation or some combination. [Cockburn 2000]
Actor types
An external actor is an actor outside the
system under discussion. A primary actor is
a stakeholder who requests the system to
deliver a goal. Typically but not always, the primary actor initiates the interaction with the system. The primary actor
may have an intermediary initiate the interaction with the system, or may have
the interaction triggered automatically on some event. A stakeholder
is an external actor, which is entitled to
have its interests protected by the system, and satisfying whose interests
requires the system to take specific actions. Different use cases can have
different stakeholders. A supporting or
secondary actor is a system against which the system under discussion has a
goal. An off-stage or tertiary actor is a
stakeholder of a use case who is not the primary actor. An internal actor is either the system under
discussion (system under discussion) itself, a subsystem of the system under
discussion, or an active component of the system under discussion. [Cockburn
2000]
Business
use case. The phrase business use case is a short-cut phrase
indicating that the use case puts the emphasis
on the operation of the business rather than the operation of a computer system. It is possible to write a
business use case at any goal level, but only at enterprise or organization
scope. [Cockburn 2000]
Collaboration diagram. In UML, a diagram showing the same
information as the sequence diagram but
in a different form. The actors are placed around
the diagram, and interactions are shown as
numbered arrows between actors. Time is shown only by numbering the arrows.
[Cockburn 2000]
Interaction. A message, a sequence of
interactions, or a set of interaction sequences. [Cockburn 2000]
Scenario. A scenario is a sequence of action
and interactions that occurs under certain
conditions, expressed without ifs or branching. [Cockburn 2000]
Sequence diagram. In UML, the diagram showing actors
across the top, owning columns of space, and interactions
as arrows between columns, with time flowing down the page. It is useful for
showing one scenario graphically. [Cockburn
2000]
Use
case A use case
expresses a contract between the stakeholders
of a system about its
behavior. It describes the system’s behavior and interactions
under various conditions as it responds to a request on behalf of the
stakeholders, the primary actor, showing how the
primary actor’s goal gets delivered or fails. The use case collects together
the scenarios related to the primary actor’s
goal. [Cockburn 2000]
Use case types
A use case brief is a one-paragraph
synopsis of the use case. A casual use case
is one written in simple, paragraph, prose style. It is likely to be missing
project information
associated with the use case, and is likely to be less rigorous in its
description than a fully dressed use case. A fully
dressed use case is written with one of the full templates, identifying actors, scope, level, trigger condition, precondition,
and all the rest of the template header information, plus project annotation
information. A black-box use case does
not mention any components
inside the system under
discussion. Typically used in the system requirements document. A white-box use case mentions the behavior
of the components of the system under discussion in the description. Typically
used in business process modeling.
A summary-level use case is one
that takes multiple user-goal sessions to complete, possibly weeks, months or
years. Sub use cases can be any level of use case. Marked graphically with a
cloud or a kite. The cloud is used for use cases that contain steps at cloud or
kite level. The kite is used for use cases that contain user-goal steps. A user-goal use case satisfies a particular
and immediate goal of value to the primary actor.
Typically performed by one primary actor in one sitting of 2-20 minutes (less
if the primary actor is a computer), after which they can leave and proceed
with other things. Steps are user-goal or lower. Marked graphically with waves.
A subfunction use case is one
satisfying a partial goal of a user-goal use case or of another subfunction. Steps
are lower-level subfunctions. Marked graphically with a fish or a clam. Using
the clam signifies that the use case is too low level and should not be written
at all.
System use case. The phrase system use
case is a short-cut phrase indicating that the use case puts the emphasis on
the computer or mechanical system
rather than the operation of a business. It is possible to write a system use
case at any goal level and at with any scope, including enterprise scope. A
system use case written at enterprise scope highlights the effect of the system
under discussion on the behavior of the enterprise. [Cockburn 2000]
Use case
diagram. In UML, the diagram
showing the external actors, the system
boundary, the use cases as ellipses, and arrows
connecting actors to ellipses or ellipses to
ellipses. It is primarily useful as a context diagram and table of contents.
[Cockburn 2000]