Information Technology Reference
In-Depth Information
unacceptably rigid constraints on the independence and evolutionary potential
of the federation members. Note that the federation itself can be considered
as a community at a higher level of abstraction, and thus can be reused in
higher-level specifications, like any other individual community.
14.4
Capturing Requirements
The formal approach taken in the enterprise language is aimed at improv-
ing communication between business stakeholders and designers of the system,
but, at the same time, bringing a level of rigour needed to link it to the de-
tailed design of the system. This is of particular importance when using tools
to support model-based development; these tools need to provide traceability
linking requirements, features in the design and elements of the subsequent im-
plementation. Rigour is achieved by the adoption of a precise set of modelling
concepts, carefully selected to reflect the typical business language and jargon,
such as the concepts of process, policy, party, accountability, delegation and so
on. These modelling concepts allow the expression of the expected structures
and behaviour of a projected enterprise or system, either a completely new
one or an intended extension of an existing system.
There are various techniques that can be used to facilitate the develop-
ment of business structures and processes based on the elicitation of business
requirements and business rules, making use of interviews with stakeholders.
For example, standard use cases or business scenarios provide a way of ex-
pressing business and system requirements using structured natural language,
reflecting a specific fragment of a system. Typically, several use cases can be
combined to arrive at a broader and more generic business model expressed
using the enterprise language concepts. These models are more amenable to
automated checking than loose collections of use cases. Ideally, a software
development tool should provide traceability between requirements and the
resulting elements of the enterprise model, to ensure that when requirements
change, the elements of the enterprise model that may be affected can be
highlighted; increasingly, tools are providing support for such features.
From a modelling point of view, requirements capture has two interesting
features. The first is that the relation between a requirements model and a de-
sign is a particularly extreme form of refinement, in which the assertions made
in the requirements must remain true when an initially underspecified system
element is completely replaced by a design compliant with some architecture
chosen by the designer. The second feature of requirements modelling is that
it will often bring into play some roles and responsibilities not appearing at
all in the eventual design, covering things like ownership of the system, its
associated runtime and implementation costs, and so on.
