METHODOLOGY FOR INFORMATION SYSTEMS
REQUIREMENTS DEVELOPMENT TEAMS
Pedro Rodrigo Caetano Strecht Ribeiro
Dissertation developed under supervising of Prof. João Pascoal Faria
in the Faculty of Engineering of the University of Porto
1. Motivation
The mission of the Project of Information Systems
(PSI) of FEUP is the development and maintenance
of information systems. With a policy of continuous
improvement, it aims to define a systematic and
rigorous process of developing requirements for
software systems. This work attempts to respond to
this need seeking to define and validate an orderly
requirements development process that can be
performed systematically and with easily predictable
outputs, thus contributing to increase the maturity of
the organization.
2. Main goals
The main goals of this work are:
• Rigorous definition of a methodology for
requirements development appropriate to the kind
of projects developed by PSI taking advantage of
existing methodologies as much as possible.
• Implementation of this methodology to the
specification of a system for student management
thus allowing its validation and evaluation of
results achieved
3. Work description
This work was structured in three phases. It began
with a study of the requirements engineering process
based on a generic methodology. Then, it was
developed a new methodology combining the
introduction of innovative aspects with the reuse of
aspects of other methodologies. Finally, this
methodology was applied in the specification of a
new system for student management (WebGA).
3.1. Requirements engineering process
The requirements engineering process is a structured
set of activities which are followed to capture,
organize, document and maintain the requirements of
a system. These set out the services that should be
provided, define constraints and supply domain
information to system developers. An accurate
requirements specification allows a system to be
conceived to adequately respond to the needs of its
customers.
The use of techniques and models are tools for
implementing the activities of the requirement
engineering process in a systematic way and predict
their execution. The process is actually divided in
requirements development, to discover new
requirements early in the software development cycle
and requirements management, to monitor their
changes and relevance of inclusion in the system.
This work fits in the first of these sub-processes.
According to the Kotonya-Sommerville generic
methodology, the requirements development process
has four main steps:
• Elicitation, using techniques to discover
requirements from various sources of information
(stakeholders, legislation, existing systems,
domain information, etc.)
• Analysis and negotiation, discussing and
analyzing the discovered requirements, in order
to reach an agreement to decide which ones
should be included in the system.
• Specification and documentation, formalizing
requirements in an appropriate level of detail and
precision to include then in their specification
document, which will be used in the subsequent
stages of the software development cycle.
• Validation, inspecting the requirements
specification document, in order to detect
problems and suggest changes.
3.2. The proposed methodology
It is proposed a methodology for developing
requirements based on the main steps of Kotonya-
Sommerville. However, this is not a generic
methodology, since its implementation is based on
the following assumptions:
• Is should be used only for the specification of
medium-sized information systems with
significant administrative weight and with
restrictions imposed by law.
• It has to be formed a specification team to
prepare and implement activities during the
requirement engineering process;
• Assignment of the requirement engineer role to a
person with exclusive dedication to the project.
Figure 1 represents an overview of the proposed
requirements development methodology, in which it
is possible to identify three phases:
• Requirement sources identification and planning,
to identify the sources of information (from
which requirements can to be discovered), assign
a specification team, to make a plan of meetings
 (including a breakdown of the system in several
parts) and produce a preceding study (a document
that summarizes the basic knowledge about the
business).
• Requirements analysis by functional areas, where
by means of a collaborative effort, the
specification team holds a series of meetings to
thoroughly examine each part of the system. The
requirements engineer, using this analysis,
completes it adding business models (using the
Eriksson-Penker methodology) and produces a
base-specification document (bringing together
supporting information relevant to the area
analyzed) for each part of the system.
• Requirements specification and documentation,
describing in a consistent manner the functional
(incorporating them in use cases) and non-
functional requirements of the system. Each part
of the system in brought together and integrated
with information already included in the
preceding study. It is produced a requirements
specification document in accordance with a
model derived within this methodology.
Requirement sources Preceding
identification and planning study
Specification Plan of Requirements
team meetings sources
Requirements analysis by Base-
functional areas specification
For each part of the system
Requirements specification
and documentation
Requirements
specification
Fig. 1 – Overview of the proposed methodology.
3.3. Specification of the WebGA system
GAUP is an information system designed to assist
administrative tasks of the educational process in the
University of Porto. WebGA is a new information
system aimed at replacing GAUP. The specification
of this new system was assigned to PSI. The system
meets the assumptions of the proposed methodology
thus allowing its use for requirements development.
Also, there were roles assigned to a group of people
forming a specification team. One of those people
took the role of requirements engineer with full
dedication to the task.
After six months since the beginning of the
requirements development process it was already
possible to perform, at least once, almost all activities
described in the methodology. The first phase was
completed, resulting in the preceding study, the
meetings plan and the identification of a large
quantity of requirements sources. The second phase
was held for five parts of the system, although with
different stages of completeness, obtaining a final
base-specification. The third phase was the least
exercised, with the production of incomplete versions
of the specification part referring to courses and the
requirements specification document.
4. Conclusions and future work
With its implementation, it is possible to draw some
conclusions on the effectiveness of the proposed
methodology, such as:
• The system partitioning allows the analysis of
each part to be done in isolation, which reduces
its complexity and enables certain activities to be
performed in parallel, reducing the time needed
to requirement analysis;
• The proposal of a collaborative environment in
the requirement analysis helps to obtain a more
representative view of the business area through a
systematic observation carried out by a
specification team;
• The definition of intermediate artifacts (preceding
study and base-specification) helps separating
system requirements from supporting
information.
• The use of business modeling as a tool for
requirements analysis shows how the system
supports the business and points out potential
new forms of integration.
• The inclusion of requirements in the context of
use cases, taking advantage of the flow of events
to describe the system dynamics, eases their use
in the subsequent stages of the software
development cycle.
• The proposed model for the requirements
specification document incorporates elements
from other models such as IEEE 830-1998 and
the Rational Unified Process.
The application of the proposed methodology to the
requirements specification of the WebGA system
revealed that, although all assumptions were met,
some activities didn’t need to be implemented. This
shows that, despite being very specific, this approach
can be further improved by identifying the more
relevant activities and eventually include new tasks.
It may also include a test-driven specification
approach in which all test cases are designed within
the requirements specification itself.