Business Requirements
Normative Approach to Behavior Modeling
Askhat Omarov, Rustem Kamun and Timur Umarov
Department of Computer Engineering, Kazakh-British Technical University, 59 Tole bi str., Almaty, Kazakhstan
Keywords:
Business Modeling, Organizational Semiotics, Deontic Logic, Responsibility, Requirements Formalization,
Normative Positions, MEASUR.
Abstract:
This paper attempts to formalize abstract requirements by amalgamating the MEASUR methodology with
deontic logic and the limited version of the theory of normative positions. This amalgamation is performed
in a manner that would potentially decrease the complexity inevitably embedded in the formalized abstract
requirements so as to be able to target a wide range of non-technical users involved in the initial stages of
software development lifecycle. This amalgamation is embraced by an artifact which represents a business
model that avoids specifying software systems as a highly technical document and is rather referred to as a
computational independent model of the MDA framework of software development.
1 INTRODUCTION
Business process engineering represents a critical
area of concern in enterprise. It is becoming in-
creasingly important to specify structured initial re-
quirements for the business model which will (i)
best fit the environment and the market demands
and (ii) adapt to different changes that may happen.
Since organizations are modeled using different the-
ories, approaches, and solutions, it is our belief that,
whichever approach is taken, the questions of com-
plexity of modeling tools and insufficient depth of in-
formation description still remain.
Different new trends in requirements elicitation
and gathering for the overall process of information
systems’ engineering were revealed. Among these
approaches we can underline the one, which relates
organizations to a set of interacting agents and enti-
ties while recognizing these objects via signs. This
paradigm of modeling is regarded as organizational
semiotics and represents an emergent discipline that
studies the nature, characteristics, and features of in-
formation and how this information can be interacted
between agents in the most optimal way within the
contexts of organizations and business domains. OS
finds its roots in semiotics and treats organizations as
information systems, within which information is cre-
ated, processed, distributed, stored and used.
The concept of organizational business modeling
of the enterprise is driven by principles of adapting
business processes to ever-changing market condi-
tions in order to provide better services and products
to clients. This is practically achieved by modeling
individual business tasks and connecting them into
logically organized activities to form workflows that
would rapidly and effectively respond to the environ-
ment changes. Participants (humans or machines) are
intimately related to these workflows by controlling
and executing them in one way or another, subject
to the knowledge possessed and the roles that these
participants play. Equally important is the concept of
contractual relationships formed among participants
over the course of their interaction with an emphasis
on social aspects of an organizational setting. How-
ever, most of the business processes with different
functional ontological descriptions and annotations
still lack complete operational semantics being de-
fined within the requirements specifications.
In our attempt to address this problem, we relate
to the following theories. One school of thought, led
by Stamper and Liu, espouses a natural framework for
the notions of behavioral patterns, roles, and relation-
ships, conceptualized via the philosophy of language
and communication, the theory of speech acts, and
computational semiotics. Another school of thought,
led by Kanger, P¨orn, and Lindahl, supports so called
the theory of normative positions which is a combi-
nation of deontic logic and logic of action and agency
to provide a formal account of complex social inter-
actions within organizations. As such concepts are
186
Omarov A., Kamun R. and Umarov T.
Business RequirementsNormative Approach to Behavior Modeling.
DOI: 10.5220/0005425901860195
In Proceedings of the Fourth International Symposium on Business Modeling and Software Design (BMSD 2014), pages 186-195
ISBN: 978-989-758-032-1
Copyright
c
 2014 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

new and not usually discussed in the wider fields of
enterprise software engineering. Similarly, use of for-
mal methods such as B and Event-B is a rare prac-
tice in the software engineering community for their
inherent complexity in the software specification pro-
cess. On the contrary, there also exist informal busi-
ness process specification languages such as BPMN,
BPEL, and WWF which are easier and handy in use.
There are several attempts to formalize require-
ments and provide formal semantics for unstructured
or semi-formal requirements specifications. The au-
thors in (Ponsard and Dieul, 2008) address this by
bridging the semantic gap between the semi-formal
requirements and formal models using a goal-oriented
approach and regulation modeling and further refine
them into formal specifications. Besides formaliza-
tion an important role in developing, for example,
critical systems is played by validation. This is thor-
oughly addressed by (Cimatti et al., 2010), in which
the authors describe their methodology and a series of
techniques for formalization and validation of high-
level abstract requirements. The language used is a
combination of first-order, temporal, and hybridlogic.
Reliability as one of the most important properties of
any systems, including critical ones, is raised by (van
Lamsweerde, 2001) while discussing requirements
engineering in terms of developing high-quality re-
quirements. The arguments is built in the light of the
related techniques for goal-oriented description of re-
quirements, multiparadigm specification and so on.
This paper describes our approach and explains
bearing of the modeling methodologies on informa-
tion systems. We try to describe how the relatively in-
formal methodology can incorporate normative tech-
niques to make this language structured and com-
puter interpretable for future machine use to imple-
ment model transformations. Because these concepts
form a common root for modern logic and therefore
formal methods, we find that we can potentially ex-
ploit our framework via model transformation ideas
to derive a method for developing better business pro-
cesses models from business requirements models.
Our approach amalgamates the MEASUR methodol-
ogy with the limited version of the theory of norma-
tive positions. This provides an additional level of
semantics by “attaching” the notion of responsibility
to the agents. The paper proceeds as follows:
• Section 2 provides an overview of the methodol-
ogy MEASUR and gives a flavor of the normative
approach in business modeling;
• Section 3 describes the proposed approach of for-
malizing MEASUR and defines the so-called nor-
mative tableaux;
• Section 4 provides an example of applying the
approach in the example of making an electronic
purchase and gives normative tableaux of several
communication acts; and
• Section 5 briefly elaborates on future work of the
research group.
2 BACKGROUND
In his definition of speech acts (Searle, 1969; Searle,
1971), Searle emphasizes the importance of so called
proper circumstances in which speech acts have to be
used. Uttering speech acts in proper circumstances
causes construction or alteration of the world, e.g.
creating an obligation. Searle also calls these proper
circumstances rules of use. In our following discus-
sion, term norms will be used to designate rules of
using speech acts effectively.
2.1 Methodology MEASUR
Method for Eliciting, Analyzing and Specifying User
Requirements (MEASUR) represents a radically new
set of norm-oriented methods for business systems
modeling and requirements specification for software
development (Liu, 2000). MEASUR is a result of
more than 30 years of research. The idea of MEASUR
is that it sees the organizations as information systems
with the set of agents, their corresponding set of po-
tential actions (affordances) and set of norms which
govern agents behavior. MEASUR offers five phases
for business modeling and software development of
which three the most important phases are problem
articulation methods, semantic analysis method and
norm analysis method.
The general ontological theory is concerned with
fundamental questions of classifying everything that
exists in the world into different categories, describ-
ing that everything while it exists, and seeking to
elicit possible hierarchies and dependencies among
the things that make up that everything. Liu (Liu,
2000) defines the term everything as constituent no-
tions such as thing, entity, individual, universal, par-
ticular, substance, event, process and state. These no-
tions are embraced with the general ontological study.
Although there are different types of ontologies
related to knowledge and its representation, the only
type of ontology that semantic analysis is relevant to
is that which recognizes only our own behavior in ac-
cordance with our own ambiance. This type of ontol-
ogy can be defined as a collection of representational
data that models a certain domain of knowledge or
discourse. Everything that exists in the world is de-
pendent on the agents behavior. In other words, the
Business Requirements - Normative Approach to Behavior Modeling
187

meaning of a thing is related to the ability of the agent
to recognize that thing as a particular entity.
Knowledge representation is an image of the
world in our minds and is created by our perceptions
of reality. The representation that we perceive, a sur-
rogate, represents a substitute for the real entity it-
self. The correspondence between the entities and
their surrogates forms the semantics for the represen-
tation. What we learn about the surrounding world
forms our understanding about it. This understanding
allows us to recognize the things that we know. Other
things that we do not possess any knowledge about
and hence cannot recognize them, do not exist in the
sense of such entities in the world. By recognition we
mean assigning meaning to things and knowing their
properties. As we learn more about the world, the on-
tology changes accordingly. In other words, the pos-
sessed knowledge shapes a repertoire of our behavior.
With relation to the semantics, Liu (Liu, 2000)
introduces the term affordance and defines it as a
pattern of behavior of a human (or agent) which he
learns through perceiving an ambient world. What an
agent does is directed by his knowledge. The pro-
cess of learning, or gaining knowledge about a cer-
tain set of facts, is in intimate relationship with the
behavior and this relationship is bipartite. On the one
hand, an agent learns the environment through his ac-
tions. On the other hand, the agents set of actions
constrained by his behavior manifests knowledge that
he possesses.
In any particular environment, whether an orga-
nization or a community, actions of its participants 1
must conform to the internal rules of behavior. Here
the term behavior ensues from a social or a business
context. Every agent has a set of certain actions to
perform in accordance with the external conditions.
The rules that members must adhere to is also re-
ferred to as norms. In the technical context, we are
modeling the interaction between machines and hu-
mans, which can universally be referred to as agents.
In terms of (Liu, 2000), the process of acting within
the required norms represents invariant patterns of be-
havior or mechanisms of agents. Agents interact with
each other which inevitably creates different relation
patterns. The questions of modeling and formalizing
these relations between agents is studied by the theory
of normative positions.
The MEASUR methodology is a set of methods
for business modeling and requirements specification
for information systems. MEASUR can be used to
analyze and specify an organization’s business pro-
cesses. As a traditional software system develop-
ment lifecycle, MEASUR methodology of informa-
tion systems modelling and requirements specifica-
tion for software system development is divided into
the following three stages (Liu, 2000):
1. Articulation of the problem, where a business
requirements problem statement is developed in
partnership with the client.
2. Semantic Analysis, where the requirements prob-
lem statement is encoded as an ontology, identify-
ing the main roles, relationships and actions.
3. Norm Analysis, where the dynamics of the state-
ment are identified as social norms, deontic state-
ments of rights, responsibilities and obligations.
The processes of the first stage are comparable to
other well known approaches to requirements speci-
fication. The last two stages require some elaboration
and have their own unique associated notations.
The ultimate deliverable of these three stages is
what we will refer to as a normative ontology. A nor-
mative ontology consists of what might be called a
semi-formal requirements document, in the sense that
it can be understood readily by clients, business ana-
lysts and developers. This model breaks down an in-
formation system into a set of business data, commu-
nicating agents (stakeholders, departments, computer
programs) and business processes that agents can in-
voke in order to manipulate data between each other.
The model consists of a role-and-relationships ontol-
ogy together with a set of norms that formally define
the structure and expected and permitted interactions
within an organization and its processes.
2.2 The Normative Perspective
The theory of normative positions is based on the fun-
damental principles of deontic logic. Deontic logic is
a formal system and represents a field of symbolic
logic which is concerned with normative concepts
such as obligation, permission, and prohibition used
in contractual relationships for classifying actions and
states of affairs. The word deontic comes from Greek
and means “of that which is binding”. Standard De-
ontic Logic (SDL, KD, or simply D) is the most stud-
ied and axiomatically defined system of deontic logic.
SDL 1) represents a monadic deontic logic because its
deontic operator is a one-place operator, 2) builds on
propositional logic, and 3) is formally specified by a
Kripke-style semantics. SDL uses the following nota-
tion to denote its main concepts: ObA stands for it is
obligatory that A and PeA – it is permissible that A.
Deontic logic have not yet found wide application
in technical areas such as Computer Science. How-
ever, deontic modalities could be efficiently used in
specifying technical requirements for different busi-
ness domains. For instance, modality obligatory may
Fourth International Symposium on Business Modeling and Software Design
188

well model the requirement that a system must check
whether a buyer have enough money in his back ac-
count before making a purchase in an on-line or phys-
ical store; and modality permissible can be applied to
specify a rule that a bank may check (it is permissi-
ble that bank checks) credit history of a client before
issuing a loan. More on the definition and a Kripke-
style possible world semantics for SDL can be found
in (McNamara, 2006).
The theory of normative positions was originally
inspired by analytical study of law and originated in
the works of Stig Kanger (Kanger, 1972; Kanger,
1985), Ingmar P¨orn (P¨orn, 1970; P¨orn, 1977), and
Lars Lindahl (Lindahl, 1977; Lindahl, 1994). The
Kanger- Lindahl theory is characterized by attempts
to apply modal logic – mainly standard deontic logic,
the field of logic concerned with obligations and per-
missions – and the logic of action and agency to the
concepts of legal and normative relations which Wes-
ley Newcomb Hohfeld (1879–1918), an American ju-
rist, had regarded to as the fundamental legal concep-
tions of jurisprudence (Hohfeld, 1964). These nor-
mative relations are alternatively referred to as nor-
mative positions that take the forms of obligations,
permissions, duties, and rights of agents of a com-
munity, society or some other form of organization.
By agents here we mean humans, machines, or both.
The Kanger-Lindahl theory also embraces the formal
representation of more complex normative positions
such as entitlement, authorization and responsibility.
Besides the areas of legal knowledge representa-
tion (e.g. representation of laws, regulations, legal
contracts, etc.), where the theory of normative posi-
tions found its initial application, there are also other
areas such as Computer Science, where the theory
contributed much for formal representation of rela-
tions between agents. For example, Jones and Sergot
(Jones and Sergot, 1992; Jones and Sergot, 1993) de-
scribe a modified version of the Kanger-Lindahl the-
ory and attempt to apply it to the problem of access
control and security policies specifications and analy-
sis for databases. In (Jones and Sergot, 1993), authors
illustrate by an example of library regulations for gov-
erning the procedures of loaning books that the use of
formal methods in developing system specifications
have to be taken seriously whenever it is necessary
to analyze an ideal case and an actual one and see
how the actual behavior deviates from that of ideal.
Use of such formal methods as deontic logic can help
in revealing the possibility of violations, i.e. those
deviations that had actually occurred. According to
Jones and Sergot (Jones and Sergot, 1993), the use of
deontic logic will in general allow (i) to reason with
the specifications developed, (ii) to be able to test the
internal consistency of the system specifications as a
whole, and (iii) to use theorem provers to implement
and test different components of the system.
In the works of Kanger, P¨orn, and Lindahl
(Kanger, 1972; Kanger, 1985; P¨orn, 1970; P¨orn,
1977; Lindahl, 1977; Lindahl, 1994), deontic logic
was merged with logic of action and agency to pro-
vide a formal account of complex social interactions
within organizations, which can be related to the tech-
nical context by applying it to the multi-agent envi-
ronment. Theyintroducea so-called relativisedmodal
operator which is designated as E
a
, where a represents
a responsible agent. The approach is partially simi-
lar to that of dynamic logic in the sense that it also
assumes that an action, if performed, should bring
about a certain state of affairs. For example, expres-
sion [a]A would mean that after performing action a
it is necessarily the case that A holds. In other words,
a must bring about A. Analogously, haiA means that
after performing action a it is possibly the case that A
holds, or a might bring about A.
However, in the theory of normative positions all
actions are associated with their respective responsi-
ble agents which makes the semantics comparatively
more expressive. When modeling business systems
using this theory we now have to deal with the ele-
ment of agent’s responsibility embedded in the pro-
cess of bringing about new states of affairs. The over-
all concept is formalized by
E
a
A, (1)
which is read as “agent a sees to it that A is the case”
or similarly “agent a brings it about that A”. It is im-
portant to note that actions in this case represent a re-
lationship between agents and the state of affairs that
these agents bring about.
The following expressions are properties for the
action operator. The first axiom schema implies that
the action operator is a success operator:
⊢ E
a
A → A. (2)
It is read as: if agent a brings it about that A then A
is indeed the case. The second property represents a
rule of inference:
I f ⊢ A ↔ B then ⊢ (E
a
A ↔ E
a
B). (3)
Although the approach of combination of deontic
logic with action logic is reminiscent of that of dy-
namic logic by its rules and operators, the theory of
normative positions provides higher expressivity in a
way that, unlike in dynamic logic: (i) by using op-
erator E
a
A one can express different atomic positions
agent a can be in with respect to a particular state of
affairs A; and (ii) using E
a
operator gives another im-
portant advantage, namely, one can also formalise a
Business Requirements - Normative Approach to Behavior Modeling
189

normative interpersonal relationship by means of iter-
ating the action operators:
E
a
E
b
A. (4)
The examples of using this form of iteration can be
demonstrated by the following:
E
a
¬E
a
A and ¬PeE
b
¬E
a
A
(5)
where the former effectively implies that agent a re-
frains from seeing to it that A and the latter means that
the agent b is forbidden to prevent agent a from see-
ing to it that A. The detailed definition is described by
Jones and Sergot in (Jones and Sergot, 1993).
The main building block of our proposed method-
ology for formalizing requirements is a tableau. It
effectively uses the MEASUR constructs and the nor-
mative positions for describing the roles of the agents.
A deeper analysis of the approach is required for
clearer understanding of how MEASUR and the nor-
mative perspective are combined. We describe it in
the next section.
3 FORMALIZING MEASUR
MEASUR and, in particular, NORMA, is a curiously
mongrel beast. Its originator, Roland Stamper, while
having a firmly applied background in system devel-
opment, was influenced by ideas from philosophy of
language and the expressive possibilities of deontic
logic. However, in spite of drawing upon these ideas
to develop the language and approach, it was always,
first and foremost, a semiformal approach to require-
ments analysis, lacking a full formal semantics for
analysis and reasoning.
The way in which MEASUR currently treats
norms is analogous to the use of OCL within UML,
that is syntaxes of OCL and UML are based on for-
mal languages, but within their respective methods
they do not have a precise semantics, which we give
for MEASUR. In this paper, we provide what might
be called a faithful formalization of MEASUR by re-
stricting its norms to precisely the kind of logical lan-
guage that inspired its notion of behavioral norm: that
is, a limited version of deontic logic, combined with
notions of agency inspired by the theory of normative
positions. This will be defined as a first-order logic
together with a straightforward semantics.
3.1 Normative Tableaux
The language proposed in this paper is somewhat
more complex, due to its relational nature and con-
formance to an ontology. However, we need not study
the full set of formulae given: we restrict our attention
to a subset of normative formulae that correspond to
the informal schema for behavioural norms given in
Definition 3.1.
A MEASUR normative definition is of the form:
if trigger occurs and the pre-condition is satisfied,
then agent performs an action so that post-condition
is Obliged/Permitted/Impermissible from resulting.
Importantly, MEASUR norms never contain deontic
quantifiers within the trigger, pre-condition or post-
condition statements. Furthermore, actual communi-
cation acts are only mentioned in the post-condition:
the trigger and pre-condition statement only refer to
relations from the ontology. All three elements of the
definition can refer to agents and entities, however.
Finally, the prescription of an agent’s responsibility
and a given deontic obligation are only given in the
implication of the constraint.
We can therefore restrict our attention to a subset
of behavioral norms for a given ontology that natu-
rally preserves these syntactic constraints within our
formalization, now defined.
Definition 3.1 (Formal behavioral norms for an ontol-
ogy). The set of behavioral norms is defined to be any
formula of the form
G → E
a
DPost (6)
where
• D is a deontic operator Ob (obligatorily) or Pe
(permissibly).
• The only free variables occurring in G and DEF
are agent or entity variables from Var
AGENT
and
Var
ENT ITY
.
The idea of a behavioral norm is to associate
knowledge and information with agents, who pro-
duce and are responsible for it. From a philosophical
perspective, truth is then defined as something that
an agent brings about and is responsible for. From
the perspective of determining how to implement a
normative ontology as a workflow-based system, we
view agents as corresponding to subsystems, business
entities to specifications of data and behavioral norms
to expected dynamic interaction protocols between
subsystems.
MEASUR and, in particular, our logical restric-
tion of MEASUR, allows much flexibility when de-
tailing the intended meaning of communication acts.
This can be done by clarifying assertions. When it
comes to the question of implementation of a com-
munication act, an analyst will always ask the client:
what is entailed by this act? The client will then ex-
plain what changes the act is expected to make on the
Fourth International Symposium on Business Modeling and Software Design
190

elements of the ontology. We encode this description
as a definition DEF of the act A, of the form
A → DEF (7)
and
DEF → A (8)
henceforth abbreviated as
A ↔ DEF (9)
where DEF is any MEASUR formula not involving
communication acts, both A and DEF sharing the
same free variables.
We are now ready to define our formal notion
of a MEASUR requirement analysis document. Es-
sentially, it consists of an ontology and pairs of
behavioral norms and definitions, called normative
tableaux.
Definition 3.2 (Normative tableaux). A requirements
specification prescribes the action an agent is obliged
(or permitted) to perform given the preconditions
hold and consists of pairs of behavioural norms, each
paired with definitions of the form
REQ = {(G
i
→ E
b i
D
i
A
i
, A
i
↔
DEF
i
| i = 1, . . . , n} (10)
where
• each D
i
is a deontic operator Ob or Pe.
• A
i
is a single communication act.
• The only free variables occurring in G
i
, DEF
i
and
A
i
are agent or entity variables from Var
AGENT
and Var
ENTITY
.
Each pair is called a normative tableaux.
A model M is a collection of these requirement
pieces prescribed for some system and said to satisfy
REQ if it validates the quantified conjunction of all
REQ’s normative tableaux. That is, M satisfies REQ
when
M |=



∀x
1
: T
1
• . . . , x
n
: T
k
•
G
1
→ E
b
1
D
1
A
1
∧ A
1
↔ DEF
1
∧. . . ∧
G
n
→ E
b
n
D
1
A
n
∧ A
n
↔ DEF
n



(11)
where x
1
: T
1
, . . . , x
n
: T
k
is the list of all free variables
contained in the formulae of the tableaux.
A model for an ontology together with a set of be-
havioral norms B
1
, . . . , B
n
is one in which each norm
is true for M. Depending on the model and the inter-
pretation, this might be an abstract representation of a
system execution, or might actually be an implemen-
tation of the specification: for example, one in which
each possible world corresponds to an actual system
state.
4 THE METHODOLOGY IN USE
This section will describe the methodology of speci-
fying norms within the framework of new improved
MEASUR. These norms specify, given certain condi-
tions are true, an agent is obliged / permitted / imper-
mitted to see to it that certain state of affairs is true.
These types of normative specifications are not de-
scriptive enough for requirements engineers to model
changes in states of affairs with the necessary depth of
data definition. Therefore, we need additional annota-
tions for our norms, which we refer to as definitions.
We hereafter present this norm/definition pair as so
called normative tableaux.
In formalizing MEASUR, we illustrate norms as
communication acts that are enabled by an agent, us-
ing the elements of agency and action of the theory
of normative positions. In the framework of new im-
proved MEASUR, in order to specify norms we use
so called normative tableaux. Tableau is a table for
defining norms and their data definitions. In other
words, each normative tableau illustrates a norm as a
pre-condition and a responsibility expression that re-
lates an agent to a particular communication act taken
from MEASUR ontology. A tableau also provides
further notation for these norms in the form of defi-
nitions, so that each norm is paired with its definition.
All norms have their definitions to obtain a certain
depth of data definition and to be able to manipulate
with these data. We need these definitions within our
new MEASUR in order to provide ways for require-
ment engineers to define and describe data in conjunc-
tion with ontologies.
4.1 Case Study
The subject of our example is to process an order
made by a customer using her credit card. The mean-
ing of processing an order embraces herein such ac-
tivities as receiving a new order, processing its data
(price, customer’s credit card information), invoicing
and dispatching an order, interactions with warehouse
and rejecting an order. In performing these activi-
ties in the order specified, we examine interaction be-
tween three involved players in an organized manner.
The first player, which starts the whole process of
ordering is Customer. This player orders products,
thereby creating a new instance of order and sends it
to the electronic ordering system, which further pro-
cesses it in a sequence specified below. The electronic
ordering system eOrder initiates one activity after an-
other and at some point starts interaction with yet an-
other player called Warehouse. All these activities
and communications between different players shift
Business Requirements - Normative Approach to Behavior Modeling
191

the order from one state to another. All orders have a
strict correspondence with its particular customer and
all orders are stored in the system during their pro-
cessing until they are rejected. The activity of rejec-
tion removes the order from the system and cancels
the correspondence with its particular customer.
The activities of making a purchase using our sys-
tem is of the following order:
1. When a customer makes an on-line order, he ini-
tiates an interaction with the electronic ordering
system by creating a new instance of the order and
changing the status of this order to “received”.
2. Electronic ordering system initiates the next ac-
tivity which processes this new order by checking
order’s data and customer’s solvency. If this check
is successful, then the status of this order changes
from “received” to “pending”. Otherwise, if the
order’s total cost is higher than customer’s credit
card limit, then the status of his order changes to
“rejected”, which starts the rejecting process by
removing the order from the system.
3. When the order’s state changes to “pending” and
if the product ordered is in stock, the system ini-
tiates the process of invoicing it by changing its
status to “invoiced”.
4. If the order is not available in the stock, then
the electronic ordering system initiates a com-
munication to the warehouse by starting the “re-
quest
increase” activity.
5. After successful invoicing, the order’s status
changes to “dispatched” to indicate that the order
is dispatched.
The diagram for this example may be similar to
UML’s sequence or activity diagrams. But, it is dif-
ferent in the way of providing more expressive defini-
tions for activities, interactions, and the notion of re-
sponsibility. We will employ this example to illustrate
the use of the MEASUR methodology its formalized
version.
We first represent knowledge as a domain ontol-
ogy encompassing such entities as agents, actions,
and relationships between them. The ontologies of
MEASUR’s semantic analysis are similar to those of,
for example, OWL: they decompose a problem do-
main into roles and relationships. Ontologies enable
us to identify the kinds of data that are of importance
to business processes. A key difference with OWL is
the ability to directly represent agents and actions as
entities within an ontology. This is useful from the
perspective of business process analysis, as it enables
us to identify tasks of a workflow and relate them to
data and identify what agent within the organization
has responsibility for the task.
In our treatment, affordances are viewed as clas-
sifications of things within a business system, with
an ontology defining a type structure for the system.
An actual executing system consists of a collection
of affordance instances which possess the structure
prescribed by the ontology and obey any further con-
straints imposed by an associated set of norms.
In our case study, we model an electronic ordering
system. The purchasing system player eOrder is re-
lated to the Customer agent and the Warehouse agent.
Customer orders products from eOrder by initializ-
ing the interaction. eOrder receives data describing
the order and performs further processing which nor-
mally includes checking availability of the product in
the system, customer’s solvency, invoicing, dispatch-
ing, and rejecting. If processing is successful, the sys-
tem files an invoice for the purchase and subsequently
dispatches it. If the product is unavailable, eOrder
sends a request to the warehouse to increase the stock
to further proceed with the order. If processing is un-
successful, eOrder rejects the order.
An ontology for the purchasing system is given in
Fig. 1. Agents are represented as ovals and business
entities as rectangles with curved edges. Communica-
tion acts and relations are shown as rectangles, with
the former differentiated by the use of an exclamation
mark ! before the act’s name.
All affordances (including agents and business en-
tities) have a number of typed attributes, defining the
kinds of states it may be in. We permit navigation
through an affordance’s attributes and related affor-
dances in the object-oriented style of the OCL.
The system involves processes that cross the
boundaries of two subsystems: a customer agent, an
order processing system, and a product warehouse
system. These three subsystems are represented as
agents in the ontology, Customer, eOrder and Ware-
house, respectively. By default all agents except for
Customer contain start and end attributes.
An order is associated with its customer, defined
by the ordered
by relationship holding between the
customer agent and order entity. An order can stand
in an ordered relationship with the eOrder agent, af-
ter it has been successfully processed. Communica-
tion act !receive
order corresponds to the initial re-
ception of data. The Processing communication act
further deals with the newly arrived order and checks
whether the client’s credit limit allows for the pur-
chase. Namely, it checks whether the total cost of
the purchase is less than the credit limit of the cus-
tomer. This condition results in the following out-
comes: if the credit limit is lower than the total cost
of the purchase then the system rejects the order, oth-
erwise it initiates the invoicing process (denoted by
Fourth International Symposium on Business Modeling and Software Design
192

WAREHOUSE
start, end : Bool
stock_increase_request :
Bool
EORDER
start : Bool, end : Bool,
in_stock : Bool, invoiced :
Bool, processing : Bool
CUSTOMER
name : String
limit : Float
ORDERED_BY
! RECEIVE_ORDER
! PROCESSING_SUCCESSFUL
receiving order
process
ing order
ORDERED
! INVOICE_IF_AVAILABLE
invoic
ing order
reject
ing order
! REJECT_ORDER
r
equest
increase
! REQUEST_INCREASE
dispatching order
! DISPATCH_ORDER
ORDER
status: {received,
pending, invoiced,
dispatched, rejected}
total : Float
! PROCESSING_UNSUCCESSFUL
Figure 1: Example normative ontology.
the invoice if available communication act). It does
so if the stock contains enough amount of the product
for the order. If not, then the system requests to in-
crease the stock by initiating request
increase, which
sets flag stock
increase request to true. Finally, the
system dispatches the order by dispatch order.
4.2 Behavioral Norms and Definitions
All norms described here strictly follow the norm-
definition relationship (9) and take form according to
(10). Consider the communication act !receive
order
from our example, corresponding to the initial recep-
tion of data by the order processing system. The idea
that this reception can only occur over orders that
are not yet processed is captured by the normative
tableaux shown in (12) and (13). Both relationships
and communication acts are represented as logical re-
lations in our language, but communication acts are
not used in pre-conditions, and may only be placed
after a Deontic operator.
Communication acts often define resulting
changes of state on related agents and entities. As
shown in our ontology in Fig. 1, receive order relates
three affordances: agents Customer and eOrder and
business entity Order, instances of which are used
as arguments for this communication act. As such,
this communication act should affect the following
relationships ORDERED and ORDERED
BY that
are involved in relating the pertinent affordances.
The meaning of the behavioral norms are extracted
from additional definitions, which represent their
equivalent meaning. An equivalent meaning of the
reception of an order entails a change of state of
affairs to include a newly arrived order, the status
becomes set to “received”, and the system initiates
the processing stage by setting its attribute to true.
This is formalized by the norm
∀cc : Customer• ∀oo : Order• ∀e : eOrder•
¬ordered
by(oo, cc) ∧ ¬ordered(oo, e) →
E
e
Ob receive order(oo, cc, e) (12)
and its definition
∀cc : Customer• ∀oo : Order•
∀e : eOrder • receive
order(oo, cc, e) ↔
ordered by(oo, cc) ∧ ordered(oo, e)∧
oo.status = received ∧ e.processing = ⊤ (13)
The norm (12) and its definition (13) form a sin-
gle normative tableau for the communication act !re-
ceive
oder. Note that we have employed the conven-
tions and assumptions just given. So determinacy is
implicit, and we are quantifying over individual for-
mulae, to indicate types of variables. However, im-
portantly, all variables – for example, oo and cc –
should be understood as denoting the same possible
interpreting object in the semantics.
To further proceed with the new order we define
a norm for processing the data received. This norm
Business Requirements - Normative Approach to Behavior Modeling
193

effectively defines the requirement to check the pay-
ment (in order to be able to proceed with the order
in a successful manner, it is important that the total
for the purchase does not exceed the limit value in the
credit card) and order related data. It should also be
noted that another requirement to enable this norm is
that the order should already be received from a par-
ticular customer. In order to model a system which
behaves in a discrete fashion, norm processing is split
into two cases: process successful
∀cc : Customer• ∀oo : Order • ∀e : eOrder•
ordered
by(oo, cc) ∧ ordered(oo, e)∧
oo.status = received ∧ e.processing = ⊤∧
oo.total < cc.limit →
E
e
Ob process
successful(oo, cc, e) (14)
with its definition
∀cc : Customer• ∀oo : Order • ∀e : eOrder•
process
successful(oo, cc, e) ↔
oo.status = pending (15)
and process
unsuccessful
∀cc : Customer• ∀oo : Order • ∀e : eOrder•
ordered
by(oo, cc) ∧ ordered(oo, e)∧
oo.status = received ∧ e.processing = ⊤∧
oo.total ≥ cc.limit →
E
e
Ob process
unsuccessful(oo, cc, e) (16)
with its definition
∀cc : Customer• ∀oo : Order • ∀e : eOrder•
process
unsuccessful(oo, cc, e) ↔
oo.status = rejected (17)
If the pre-conditions of process
successful hold then
the norm changes the status to pending, as it is de-
picted in (14), which enables the !invoice
if available
communication act. Otherwise, the system initiates
rejecting of the order by setting status to rejected as it
is illustrated in (16). Below we show the norm and its
definition for invoicing.
∀cc : Customer• ∀oo : Order • ∀e : eOrder•
ordered
by(oo, cc) ∧ ordered(oo, e)∧
oo.status = pending∧ e.in
stock = ⊤ →
E
e
Ob invoice if available(oo, cc, e) (18)
∀cc : Customer• ∀oo : Order • ∀e : eOrder•
invoice
if available(oo, cc, e) ↔
oo.status = invoiced∧ e.order
invoiced = ⊤ (19)
Invoicing the order and increasing the stock are fol-
lowed by the dispatching process. We depict its defi-
nition.
∀cc : Customer• ∀oo : Order• ∀e : eOrder•
ordered
by(oo, cc) ∧ ordered(oo, e)∧
oo.status = invoiced →
E
e
Ob dispatch
order(oo, cc, e) (20)
∀cc : Customer• ∀oo : Order• ∀e : eOrder•
dispatch
order(oo, cc, e) ↔
oo.status = dispatched (21)
Dispatching relates Customer to eOrder and Order
and uses their instances for pre-conditions and to
change the state of affairs towards updating the sta-
tus to dispatched. This communication act finishes
the ordering process. If processing was not success-
ful, in other words if pre-conditions for norm pro-
cess unsuccessful were true, then the eOrder system
rejects the order in accordance with the norm in (22).
∀cc : Customer• ∀oo : Order• ∀e : eOrder•
ordered
by(oo, cc) ∧ ordered(oo, e)∧
oo.status = rejected →
E
e
Ob reject
order(oo, cc, e) (22)
and its definition
∀oo : Order • ∀e : eOrder•
reject
order(oo, cc, e) ↔
¬ordered(oo, e) ∧ ¬ordered by(oo, cc) (23)
According to Fig. 1, there exist other communication
acts such as invoice
if available and dispatch order
and their norm-definition pairs can also be defined
in a similar way we have defined tableaux (12)–(23).
The norm-definition relationship is important as ex-
pression in the definition part of the tableaux fur-
ther elaborates each norm that precedes this defini-
tion. For example, the norm with its arguments re-
ceive order(oo,cc,e) defined in (12) has a meaning of
mapping certain objects together while defining a new
instance of the order, in that:
• ordered
by(oo, cc) means that instance of order
oo is mapped to the instance of an abstract ma-
chine cc (that models a customer),
• ordered(oo, e) means that instance of order oo is
mapped to the instance of machine e (that models
a system),
• oo.status = received means that the status should
now change its value to received, and
Fourth International Symposium on Business Modeling and Software Design
194

• e.processing= ⊤ means that the processing status
of the system should now change to processing to
invoke the next norm.
All other subsequent norms are similar in the way
they are read.
5 CONCLUSION
In this paper, we have shown an approach of combin-
ing the MEASUR methodology and the limited ver-
sion of the theory of normative positions to model
norms and normativeontologies. The level of abstrac-
tion pertinent to this approach effectively corresponds
to early stages of business modeling. The model that
we obtain as a result is a piece of knowledge which
can (semi-formally) describe a functional structure of
a company (e.g., stakeholders, departments, people,
business processes, communications between these
processes, etc.).
The approach described in this paper represents a
combination of MEASUR with the theory of norma-
tive positions limited to the kinds of norms used in
this methodology and describe business rules which
specify interaction between two agents for achieving
certain goals. Since the MEASUR methodology is
a set of methods for business modeling and require-
ments specification for information systems, it can be
used to analyze and specify an organization’s busi-
ness processes. The term affordance is introduced in
this paper as a set of actions formed by the knowledge
that an agent gains from existing in the environment
and learning by interacting. The artifact developed
can effectively be used as a high-level structured re-
quirements specifications that can be turned into more
concrete models using a range of different transfor-
mation and refinement techniques (e.g. Model-driven
Architecture or refinement of B-based models), which
will be the subject of our future work. We intend
to see how the developed methodology can be useful
in both developing formalized and structured require-
ments and semantically better fit the modular design
specifications using formal languages such as B and
Event-B.
REFERENCES
Cimatti, A., Roveri, M., Susi, A., and Tonetta, S. (2010).
Formalization and Validation of Safety-Critical Re-
quirements. EPTCS.
Hohfeld, W. (1964). Fundamental Legal Conceptions As
Applied in Judicial Reasoning. Dartmouth Publishing.
Jones, A. and Sergot, M. (1992). Formal Specification of
Security Requirements Using the Theory of Norma-
tive Positions. Proceedings of the Second European
Symposium on Research in Computer.
Jones, A. and Sergot, M. (1993). On the Characterization
of Law and Computer Systems: The Normative Sys-
tems Perspective. Deontic Logic in Computer Science:
Normative System Specification.
Kanger, S. (1972). Law and Logic. Theoria.
Kanger, S. (1985). On Realization of Human Rights. Ac-
tion, Logic and Social Theory.
Lindahl, L. (1977). Position and Change – A Study in Law
and Logic. D. Reidel Publishing Company.
Lindahl, L. (1994). Stig Kanger’s Theory of Rights. Logic,
Methodology and Philosophy of Science.
Liu, K. (2000). Semiotics in Information Systems Engineer-
ing. Cambridge University Press.
McNamara, P. (2006). Deontic Logic. Stanford Encyclope-
dia of Philosophy.
Ponsard, C. and Dieul, E. (2008). From Requirements Mod-
els to Formal Specifications in B. ReMo2V.
P¨orn, I. (1970). The Power of Logic. Blackwell Oxford.
P¨orn, I. (1977). Action Theory and Social Science: Some
Formal Models. D. Reidel, Dordrecht.
Searle, J. (1969). Speech acts: An Essay in the Philosophy
of Language. Cambridge University Press.
Searle, J. (1971). The Philosophy of Language. Oxford
University Press.
van Lamsweerde, A. (2001). Building formal requirements
models for reliable software. Reliable Software Tech-
nologies.
Business Requirements - Normative Approach to Behavior Modeling
195