Handling the knowledge acquired during
the requirements engineering process
- a case study -

Paolo Donzelli
Presidenza del Consiglio dei Ministri
Ufficio per l’Informatica, la Telematica e la Statistica
Via della Stamperia 8, 00187 Roma, Italy
p.donzelli@governo.it

Roberto Setola
Presidenza del Consiglio dei Ministri
Ufficio per l’Informatica, la Telematica e la Statistica
Via della Stamperia 8, 00187 Roma, Italy
r.setola@governo.it


ABSTRACT
Performing the requirements engineering process for software-
intensive systems, characterized by a high organizational impact,
requires the analysts to handle a large amount of information,
related to desires, needs, and constraints of a vast number of
completely different stakeholders. The paper presents an
organization modeling-based requirements engineering
framework, where advanced requirements engineering techniques
are combined with software quality modelling approaches to
support the analysts in capturing, and formalising the knowledge
embedded in the organisation, from which the sought system
functionality and quality attributes may be derived. The collected
knowledge will not only support the specific project but will
represent an organizational asset to be exploited for future
systems/organization evolution. As a case study, the paper reports
on an on-going project concerned with the development and
introduction, within the Italian Office of the Prime Minister, of a
Electronic Record Management System, as a first step towards a
paperless knowledge workplace.
Keywords
Requirements Engineering - Agents - Soft and Hard Goals -
Process Modeling - Quality Modeling
1. INTRODUCTION
The rapid evolution of the Information and Communication
Technologies (ICT) and the wide diffusion of the Internet are
dramatically changing the scenario in which organizations have to
operate, providing, at the same time, huge opportunities for
modernizing and improving their operational processes.
Consequently, both in the private and in the public sectors,
organizations are going through a deep re-thinking of their
business processes, aiming at new work models and at faster and
cheaper interactions with the external environment: partners,
services and products providers, customers and citizens.
Within complex organizations, as the case of central government
units, every change must be carefully planned, in order to
maximize return of investments, minimize risks, and prevent
undesired side-effects. The ICT managers must operate to
guarantee that the new system will be accepted by the
organization, becoming an organic component of the business
process for which has been devised.
This paper reports on an on-going project aiming at introducing an
Electronic Record Management System within the main
administrative and decision-making processes of the Italian Office
of the Prime Minister: a first step towards a paperless knowledge
workplace. Such a system is at the moment used by more than 300
employees and handles a flow of about 200.000 document/year,
but we expect it to reach about 2000 users and 2 million
documents/year by the end of 2003. It supports both paper-based
and electronic documents (i.e. documents electronically signed),
and presents a multitude of internet-based access channels (e.g.
PCs, PDAs, phones, mobile phones, etc.), to provide a friendly
and efficient working environment.
The high impact of the system upon the organizational context,
mainly due to its classical bureaucratic and highly paper-
dependent structure, the many and very different classes of
stakeholders, and finally, the clear presence of clashing interests
have suggested the use of an advanced goal-oriented organization
modeling-based requirements engineering (RE) framework [1,2].
A firm understanding of the application context and, in particular,
the capability of envisioning and managing the impact of the new
software system upon it [1, 2] are in fact essential for a successful
implementation.
Envisioning the impact that a software system will have on its
application context is a difficult task. Organisations are made of
people, and the goals, the expectations, the needs of all the
stakeholders, directly or indirectly involved (e.g. final users,
customers, business and information technology managers,
procurement people, maintainers, developers, etc.), have to be
explicitly addressed, analysed and captured from the outset of the
project. The software system and its application context form a
larger social-technical system that has to be treated and analysed
as a whole: the overall needs of such social-technical system are
the ones to be fulfilled [2].
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee proovided that copies
are not made or distributed for profit or commercil advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
SEKE '02, July 15-19, 2002, Ischia, Italy.
Copyrigh 2002 ACM 1-58113-556-4/02/0700...$5.00.
- SEKE '02 - 673 -

Based upon i* [3], the proposed RE framework has been designed
to provide an environment within which both the stakeholders and
the analysts could easily work and interact to understand the
application context (as it exists), envision possible solutions (as
could exists), and compare feasible alternatives. The application
results show how the framework supports the analysts in
capturing and formalizing the knowledge embedded in the
organisation, from which the final system functionality and
quality attributes may be derived. Abstraction mechanisms are in
fact provided to gather, discover, understand, organize and reason
about any piece of information the analysts (and the stakeholders)
have to deal with during the whole RE process, but also to make
the acquired knowledge accessible and reusable in the post-
deployment phase.
The remainder of this paper is organised as follows. Section 2
introduces the framework, by briefly describing its main
characteristics. Section 3 elaborates some of the aspects
introduced in Section 2, by showing some extracts from the case
study. Finally, Section 4 concludes by discussing some of the
observed benefits, mainly in terms of knowledge handling.
2. THE RE FRAMEWORK
The framework is designed to allow the analysts to deal with the
WHAT and the HOW of the organisational context (i.e. the tasks
performed by the organisation, and the way in which they are
performed), but also to explicitly model the WHY (i.e. the
underlying reasons), expressed in terms of organisational goals.
This enables the analysts and the stakeholders to focus on the
‘right’ system for a given context, to design (or re-design) the
encompassing process that fully exploits the system’s capabilities
[4], and to improve their capacity to identify, justify and validate
the system requirements [3,5,6].
The framework tackles the modelling effort by breaking the
activity down into more intellectually manageable components,
and by adopting a combination of different approaches, on the
basis of a common conceptual notation.
Agents are used to model the organisation [3,7]. The
organisational context is modelled as a network of interacting
agents (any kind of active entity, e.g. teams, humans and
machines, one of which is the target system), collaborating or
conflicting in order to achieve both individual and organisational
goals. Goals [3,5,6] are used to model agents’ relationships, and,
eventually, to link organisational needs to system requirements.
According to the nature of a goal, a distinction is made between
hard goals and soft goals.
A goal is classified as hard when its achievement criterion is
sharply defined. For example the goal “to make a document
available” is a hard goal, being easy to check whether or not it has
been achieved (i.e., is the document available, or not?).
For a soft goal, instead, it is up to the goal originator, or to an
agreement between the involved agents, to decide when the goal
is considered to have been achieved. For example, the goal “to
make a document easily and promptly available” is a soft goal,
given that as soon as we introduce concepts such as “easy” and
“prompt”, different persons usually have different opinions. In
comparison to hard goals, therefore, soft goals can be highly
subjective and strictly related to a particular context. For such a
reason, explicitly focusing on soft goals enables the analysts to
highlight quality issues (e.g. the concepts of prompt and easy)
from the outset, making explicit the semantics assigned to them
by the stakeholders. While a hard goal will lead to a set of
functions (functional requirements) that the software system will
have to provide, a soft goal will be refined into more precise sub-
ordinate soft goals, for reducing its initial fuzziness, until,
eventually, it can be expressed as a set of hard goals and
constraints upon them (non-functional requirements).
Distinguishing goal modeling from organizational modelling, and
then, further distinguishing between hard goal modelling and soft
goal modelling, helps to reduce the complexity of the modelling
effort. The proposed framework, therefore, supports three inter-
related modelling efforts (see Figure 1): the organisational
modelling, the hard goal modelling and the soft goal modelling.
During Organization Modelling, the organisational context is
analysed and the agents and their goals identified. Any agent may
generate its own goals, may operate to achieve goals on the behalf
of some other agents, may decide to collaborate with other agents
for a specific goal, and might clash on some other ones. The found
goals will then be refined, through interaction with the involved
agents (i.e. the stakeholders), by hard goal and soft goal
modelling.
The Hard Goal Modelling seeks to determine how the agent can
achieve a hard goal placed upon it, by decomposing them into
more elementary subordinate hard goals and tasks (where a task is
a well-specified activity, leaving little room for initiative). Of
course, the granularity of refinement of a hard goal into
subordinate hard goals and tasks depends on the level of
capability and autonomy of the agent. So, for example, while the
hard goal “make a document available” could be clear enough for
a human agent, it might need to be translated within an
organisation (or a system) into a set of actions (tasks).
RE
Framework
constraints
hard goals
mapping to
organisation so
ft g
oa
lshard goals
Organisational
Structure
Modelling
Hard Goal
Modelling
Soft Goal
Modelling
Development
Flow
Verification
Flow
Elicitation &
Validation
Flow
stakeholders &
analysts

Figure 1 - The Requirements Engineering Framework
The Soft Goal Modelling aims at producing the operational
definitions of the soft goals that emerged during the organisational
modelling, sufficient to capture and make explicit the semantics
that are usually assigned implicitly by the involved agents [8,9,10]
and to highlight the system quality issues from the start. A soft
goal is refined in terms of subordinate soft goals, hard goals, tasks
and constraints. Resulting soft goal, in turn, will have to be
- SEKE '02 - 674 -