$3URFHVV)UDPHZRUNIRU5HTXLUHPHQWV$QDO\VLVDQG6SHFLILFDWLRQ
Category: Experience Paper
Enrique García Alcázar (egarcia@tcpsi.es), Antonio Monzón (amonzon@tcpsi.es)
TCP Sistemas e Ingeniería
López de Hoyos, 327, 28043 Madrid, Spain
Tel.: +34 917489920, Fax: +34 917489876
$EVWUDFW
7KLV SDSHU SUHVHQWV D QHZ DSSURDFK IRU OLQNLQJ
5HTXLUHPHQWV (QJLQHHULQJ DFWLYLWLHV LQWR D 3URFHVV
)UDPHZRUN WKDW FDQ EH XVHG DV D UHIHUHQFH IRU GULYLQJ
FRQFUHWH5HTXLUHPHQWV(QJLQHHULQJSURFHVVHV
6SHFLDO HPSKDVLV LV SODFHG RQ FRQVWUXFWLQJ 3UREOHP
'RPDLQ PRGHOV LQ RUGHU WR EXLOG D FRPPRQ
XQGHUVWDQGLQJ RI WKH SUREOHP FRQWH[W WR VLWXDWH XVHU
UHTXLUHPHQWVZLWKUHIHUHQFHWRLWDQGDVDWHFKQLTXHIRU
XVHUUHTXLUHPHQWVUHILQHPHQW
$QRWKHUDVSHFWKLJKOLJKWHGE\WKH3URFHVV)UDPHZRUNLV
WKHVHSDUDWLRQ RI WKH HOLFLWDWLRQ DQDO\VLV DQG UHILQHPHQW
RIXVHUUHTXLUHPHQWVIURPWKHFRQVWUXFWLRQRIDV\VWHPRU
VRIWZDUHVSHFLILFDWLRQ
$OWKRXJK WKH HPSKDVLV LV SODFHG RQ WKH SURFHVV DQG WKH
DFWLYLWLHV WR EH SHUIRUPHG WKH SDSHU GHVFULEHV VSHFLILF
WHFKQLTXHVWKDWKDYHEHHQXVHGVXFFHVVIXOO\
7KH 3URFHVV )UDPHZRUN LV VXSSRUWHG E\ D WRRO DQG KDV
EHHQ WHVWHG LQ VHYHUDO SURMHFWV IURP GLIIHUHQW
RUJDQL]DWLRQV
7KLV SDSHU GHVFULEHV WKHVH H[SHULHQFHV GUDZV
FRQFOXVLRQVDQGKLJKOLJKWVIXWXUHLVVXHV
.H\ZRUGV 5HTXLUHPHQWV (QJLQHHULQJ 3URFHVV
)UDPHZRUN3UREOHP'RPDLQ
,QWURGXFWLRQ
The Requirements Engineering (RE) framework has
been developed within the Software Engineering1
Division of TCP. It started as an effort to solve recurring
problems encountered during the requirements analysis
1 2
TCP Sistemas e Ingeniería is a Madrid (Spain) -based software house.
The Software Engineering Division of TCP provides consulting support
both in-house and to external clients in software engineering methods
and tools.
phase of many projects and has evolved into a reasonably
comprehensive RE Process Framework (PF) that is being
implanted in most divisions of the company and tested in
several client organizations.
The techniques initially selected by the division to
perform the process were based on commercial tools,
mainly Relational Database (RDB) and design-oriented
Computer Aided Software Engineering (CASE) tools.
But, although the information suited the RDB structure
well, the kind of presentation required was not adequately
supported, requiring substantial handwork. The
continuous evolution of requirements-related information
and its difficult integration with CASE tools aggravated
these problems still further. Only a part of the problem
could be solved using the requirements management tools
available.
For these reasons, a tool2 was developed, and is being
used to support the Process Framework. Again, the
information is stored on a commercial RDB that acts as a
repository but provides sufficient support for the activities
considered in the PF as well as adequate presentation,
reporting, navigation and management. It required a
substantial effort to define the Process Framework clearly
and consistently, but this had the beneficial effect of
bringing many of its concepts and activities under the
microscope.
The techniques were initially applied in a project with
an especially complex requirements analysis phase. The
project [Project1] intended to build the technical platform
and to prototype systems for the remote operation of
scientific laboratories or premises. It constituted a good
test bench, because there was a significant number of
stakeholders with different origins, affiliations and
interests, all providing user requirements and validating
Initially a prototype tool was developed to support the PF. This
prototype has finally derived in a commercial tool named Integral
Requisite Analyzer - IRqA [9].
the proposed solutions. The experience gained in this and
two other projects is described below.
The team that started this job tried to use, when
possible, already existing, reasonably proven techniques.
Due to this background, mainly Object Oriented (OO) and
Domain Analysis techniques have been used, as can be
seen in the process description. But, over time, the
emphasis has shifted from what technique is used to what
are the activities that have to be performed, what are the
results we are looking for, and how they fit into the
overall process. Although the techniques themselves are
not new, the way to integrate them and to perform the
complete process constitutes a new approach in RE. This
paper describes the process and the experience obtained in
applying it to several real projects in different
organizations.
7KHSURFHVV
7KHVFHQDULR
The Process Framework was developed as an answer
from TCP’s Software Engineering division to the
problems encountered during the requirements
specification phase by many software projects from other
company divisions.
Those problems were the typical ones related to
requirements phases (problems related to the difficulty of
eliciting user requirements and managing them in the
course of their evolution). But a problem that appeared
recurrently, especially in projects collecting requirements
from different stakeholders, was the large dispersion in
the style, aim and vocabulary used. Some way of
analyzing and organizing them not based on their
structure, but rather on their meaning appeared to be a
desirable objective.
This was the problem appointed to the SW.
Engineering Div. that ultimately gave rise to the
development of the Process Framework.
)RXQGDWLRQV
The first approach to the complete process and the tool
were ready by mid ’98. During the evolution of the RE
process definition, many problems appeared, both
theoretical and practical. During its evolution, some of
these problems became clear to the team, highlighting key
aspects of the process. These key foundation concepts are
presented below.
The first point is key for structuring the process: the
basic problem that always underlies Requirements
Engineering activities is a communications problem, and
can be stated in a simple way:
a) Users have a problem and a need to solve it. Analysts
have to understand the problem, the context in which
it arises, and the user’s expectations.
b) Analysts “create” a solution they think suitable for the
user problem. Users have to understand what the
analysts propose –the specification- and accept,
modify, or discard it, preferably before starting the
application development.
And this is not a linear but a cyclic and iterative
process. The RE Process Framework is therefore
articulated around this loop.
Another key aspect came to the fore when trying to
reconcile requirements from different stakeholders. It
soon became clear that, very often, they had substantially
differing mental models of the problem: whenever users
are providing requirements, they think in terms of a set of
concepts, characteristics, meanings and relationships that
are often called the Problem Domain (PD). It is no
surprise then that it becomes very hard to understand –and
therefore to analyze- user requirements unless you
understand their context [1].
User requirements have a meaning and a structure only
when referred to their primary context, the Problem
Domain: the concepts that populate the area in which the
users carry out their activity, and in which they have a
problem and expect a solution. Other artificial structures
can be built upon the requirements, but the natural one is
given by its context.
Building a Problem Domain model, and situating the
user requirements in that context has therefore become
one of the key techniques in our RE framework for
analyzing and building a common understanding of users’
problems. The importance of identifying the Problem
Domain and clearly separating it from the solution domain
has already been discussed extensively by Jackson [2]
(who terms them as “application domain” and “machine
domain” respectively). We have verified the relevance,
and the difficulty, of doing this in practice.
One last point is worth mentioning. There is no unique
process in RE. This statement, quite obvious on the other
hand, has become clear when trying to standardize a
process. This is why we have tried to formalize our
experience in a “Process Framework” that is intended to
serve as a reference and as a guide, but not to cast any and
all RE process into a fixed process pattern. We have
found substantial differences in the processes required,
depending on many factors. Among these, we can mention
the level of formality required (having formal
requirements lists or not); the application novelty for
client and developer; the type of product (if it is an ad-hoc
or free-standing product or a member of a product
family).
7KH3URFHVV)UDPHZRUN
We present below the main activities comprising the
RE Process Framework (Fig. 1). With each activity, we
suggest the techniques that we have found most useful to
obtain good results, and the way to use them. Other
techniques could be used instead, in many cases: the key
points are the objectives and the activities, not the specific
techniques used (although we discuss the ones we have
found most appropriate).
Capture User Analyze
Requirements Requirements
Verify Build Solution
Specification Specification
Figure 1. Process framework activities
A simple example, shown in boxed paragraphs, is used
to illustrate each activity.
([DPSOH 
In a public organization a new system of documentation
access management is going to be built. This system
organizes the documents within the institution and
manages the access to them by authorized people.
 &DSWXUH ZHOO LGHQWLILHG XVHU UHTXLUHPHQWV All
information items should be collected and identified
(stakeholder, date). Requirements lists are very useful but
other formats should also be captured (graphs, free texts,
references to external data, applicable standards,...).
Business process and organizational descriptions can
give additional information to understand the
requirements. They are also part of the context.
$QDO\]HUHTXLUHPHQWVE\PRGHOLQJWKH3UREOHP
'RPDLQThe key activity in the framework for analyzing
requirements is to build a Problem Domain Model
(conceptual model). This is done, first, to capture all
information relevant to the Problem Domain, concepts,
characteristics, relationships. Clarifying vocabulary and
definitions is also an important part.
The objective is to build a common understanding of
the Problem Domain concepts, vocabulary … among all
participants in the process and to have a reference concept
model/dictionary.
We have basically used the techniques provided by
static Object Oriented models (Unified Modeling
Language - UML [8]) to capture that information. It
appears to be a powerful way of representing and
characterizing concepts and their relationships within the
problem context. Entity-Relationship models are also a
suitable alternative.
([DPSOH 
In the example, one of the user requirements could be
described as “A document can be modified or
suppressed by the persons authorized by the department
manager”. The concepts related with this requirement
are “Document” and “Person” (see Fig. 2). The
particular approach used to model it (OO) involves the
use of attributes and operations3 to characterize
internally the PD concepts. In this case, the concept
“Document” was associated with the requirement
through its operations “Modify” and “Suppress”.

([DPSOH 
Three user requirements identified during the
development of this activity are:
ID Name Description
R1 Document Department manager should decide
distribution the type of distribution for each
Figure 2. Problem Domain
document generated in his dept.
R2 External External documents should be
document classified by the librarian. We have complemented this technique with facet
treatment models, [5][6] coming from the field of Domain Analysis
R3 Internal Internal document registration is (and from library sciences before that), that are very
registration allowed only during the morning.
of documents 3
In this context, an operation should be understood as something that
happens to those concept objects in the Problem Domain, and therefore
serves to further characterize the concept.
useful to classify information with simple, flat,
independent criteria (hierarchical models can be described
with the classical OO techniques). The facets are used in
two ways, first as domain facets (classificatory aspects
coming from the specific Problem Domain), and as
domain-independent facets, that are very useful for
managing the requirements and the project.
([DPSOH 
In our example, six domain-dependent facets were used
to classify the requirements:
)DFHW 7HUP
Type of Access Confidential
Free
Type of Person Department manager
Librarian
Secretary
Hour of the day Morning
Afternoon
Document Origin Internal
External
Document Format Paper
Electronic
Document Type Technical document
Memorandum
Notification
Minutes of meetings
A second but equally important activity is to situate the
requirements in their context: identify relations among
requirements and model elements.
The concrete mechanism is to establish a link between
the requirement and its related context elements. As well
as easing navigation and searching, the activity of
analyzing the links of each requirement often sheds light
on the requirement itself, producing the clarification and
refinement of the requirements and their implications.
Anyway, building the models and linking them with
requirements is not necessarily an independent activity.
Very often, identifying model elements and linking them
to the requirements are done simultaneously.
 &DSWXUH ZHOO GHILQHG VROXWLRQ VSHFLILFDWLRQ The
objective is to express what the application has to do –its
specification- in such a way that analysts and stakeholders
get a clear picture, and the latter accept it. It should
express it in the terms stated by the Problem Domain
models but should not enter into how the application will
solve it, so Problem Domain elements should appear
referenced as such, but not as part of the solution. The
specification should describe how the application is
expected to behave in its interaction with the external
world.
([DPSOH 
Four services (Use Cases) were identified to describe
the external behavior of the system: “To register
documents in the system”, “To access documents to
consult them”, “To access documents to modify or
suppress them” and “To manage personnel”. Within the
first service some internal activities were identified to
describe in detail the processing of a document (see
Fig. 3).
Use Cases [3] are becoming one of the key techniques
for specifying application requirements. They are intuitive
and fit well both with OO styles and with functional
styles. Building a Use Case specification model is
therefore used as key technique for specifying. The Use
Cases have also been enriched with additional techniques
(state-charts in the activity-event style, UML notation [8];
and responsibility-oriented descriptions, in the sense used
by Wirfs-Brock [7]) to strengthen its formality and level
of detail, as suggested by UML/UMP [3] and others [4].
Figure 3. "Register file" Use Case
description
Two additional techniques complement Use Cases:
Actors and Scenarios identification and definition. Actors,
whose description also adds to the context knowledge,
enforced in the sense “all external entities (roles) that
interact with the application”. On the other hand,
scenarios act as good examples of Use Case execution
sequences.
 9HULI\ VSHFLILFDWLRQ Linking each user
requirement to the Use Case or Cases that solve it closes
the process. This activity is to be performed by the
analysts, and allows them to confirm that all user
requirements have been adequately taken into account,
and gives a path to trace them.
([DPSOH  can reach a certain point, plus a set of techniques and
One of the conclusions to be obtained during the suggestions to arrive there easily.
specification verification is how the Use Cases are In the PF, the sequence described above is called
related to the requirements. ‘direct path’ because it is the natural way in traditional
The particular service represented in Figure 3 (“Register Requirements Engineering. But we have found that in
File”) 'solves' the requirements: “Document many other cases the ‘inverse path’ could be more useful.
distribution”, “External documents treatment” and In our example, a direct approach was used ( Fig. 4). An
“Internal registration of documents”. initial requirements list was prepared (requirements
elicitation). From these requirements an analysis was
 *XLGHOLQHV WR JR WKURXJK WKH 3)  The PF made to extract the main problem concepts and their
involves a number of activities to be developed during the internal characteristics and the PD facets to classify the
requirements analysis phase. But the process also includes requirements. The second task during this phase was the
some advice on the sequence of activities to follow during association of the concepts and facets to their related
this analysis work. requirements, and based on this relationship a primary
Some paths are recommended to address the final revision was performed. Once the problem was
objective of obtaining a good definition of the problem. sufficiently clear, the next step was the proposition
These paths show the logical order in which each activity (creation) of functional specifications. The identification
has to occur. of Use Cases, and then their internal description and their
The activities presented above constitute the Process association with the requirements they solve, was the last
Framework. Although there is a logical order (Capture activity in this direct process. Once we have all the
user requirements ⇒ Analyze them ⇒ Build a software elements, we can perform a first global revision of the
specification ⇒ Verify it), it should be seen rather as a specification.
loop (Fig. 1), that always requires some iteration, and An alternative approach is recommended for those
having several entry points (Figs. 4 and 5). projects in which more accurate information of the overall
functionalities is available. In this case the entry point is
the specification. The inverse approach (Fig. 5) is
Functional Requirements interesting in product families or well-known project
Requirements Análisis Problem specifications.
Domain
Capture User Analyze Models
Requirements Requirements Functional Requirements
Requirements Analysis

Solution Capture User Analyze

Specification Requirements Requirements
Problem
Verify Domain
Build Solution Models
Specification Specification
Services
Specification Verify Build Solution
Specification Specification

Process Activity Result or Document Services Solution

Specification Specification

Figure 4. Direct process (entry point in

requirements)
Depending on the way requirements are handled in the
organization, on the level of formality of the process, on
the application type –free-standing or product family-, and
many other factors, the stress may be placed on any of
these activities and some may even be dropped. But the
framework will in any case be there to orient us on where
we are, what it is we are doing, and what not, and how we
Figure 5. Inverse process (entry point in
specificacion)
Both approaches, direct and inverse, are valid and
useful, but one of them has to be selected for each
particular project, according to the previous experience or
knowledge of the problem definition.
2WKHU5(DFWLYLWLHV
Two additional activities are an integral part of the RE
process. We show below how they are supported in the
framework.
 7UDFH UHTXLUHPHQWV Tracing requirements is a
usual concern in RE. The Process Framework described
above gives multiple paths and facilities to perform it.
First of all, user requirements are directly traced to the
Use Cases that solve them. Once the specified Use Cases
are solved (in the design phase) through a specific
software module or process, there is a clear path to trace
the user requirement down to the design and later to the
code.
An alternative and complementary trace path can be
established through the Problem Domain model elements.
Whether they are object classes or entities, they will in
most cases evolve into design elements (without confusing
the representation of the real world –the Problem Domain-
with a design artifact –the elements of the solution
domain-). Through the link between user requirements
and Problem Domain elements, the former can be traced
down to the program classes that handle those concepts in
the application, or to the table structure and processes that
do so.
 5HTXLUHPHQWV PDQDJHPHQW The proposed
solution to the requirement management problem is the
use of certain requirement attributes, concerned directly
with this matter. In the PF these requirements
characteristics are called 'management facets'. They are
considered internally in the same way as domain facets,
but with the particularity that they are domain-
independent (they can be applied to requirements in
different Problem Domains). The main objective of these
requirement characteristics is to facilitate the evolution
and management of requirements. Some examples of
attributes are the state of a requirement, the type of
requirement or the acceptance criterion.
([SHULHQFHXVLQJWKH3URFHVV)UDPHZRUN
We will discuss the experience gained during the
development of three different projects. They were
selected in order to provide a wide point of view on the
application of the Process Framework but it is important
to emphasize that they were not designed specifically to
test the efficiency of the proposed methodological
framework. They are real-life working projects, with the
common point that they have adapted the RE Process
Framework to their needs.
The particular projects are:
- REMOT-DYNACORE [Project1]: This international
project deals with the remote operation of large
scientific devices like telescopes or plasma physics
facilities (plasma fusion). The main idea of this
project is to provide the application and
communication infrastructure to operate complex and
very expensive experimental devices.
- Sales Promotion System (SPS) in banking
environment [Project2]: The objective was to develop
a system to support the acquisition of non-financial
products, using the existing commercial
infrastructure, within one of the most important
financial institutions in Spain (Caja Madrid).
- SIGA [Project3]: This project deals with the
automatization of telecoms connections with ADSL
(Asymmetric Digital Subscriber Line) technology.
The target system should support ADSL service
provision, monitoring and operation. It was
developed by the first telecommunications operator in
Spain (Telefónica) in the R&D division.
The application of the activities involved within this
framework was not manual, but supported by the tool that
helped the analysts take advantage of the electronic
manipulation of requirements information.
$JUHHPHQWEHWZHHQSDUWLHV
One of the points most often mentioned in the
application of this Process Framework is the benefit of
compromise. All of the people involved in the
requirements process were aware that they had to propose,
discuss and accept the elements needed to conform a
consistent requirement specification. They were expected
to agree with some kind of ‘contract’ between all of the
parties, mainly the final users and the development team.
This formalization procedure is the first step towards
reaching the desired problem specification.
The framework provides a standard way to solve the
differences in the conception of the problem and the
solution by the various parties. The DYNACORE project
can be seen as the most complex from the organizational
viewpoint. Various international partners participated with
different roles. In this context, the participation of a
coordinator was needed, not only to organize the
administrative work, but also to ensure the correct
comprehension of the user needs. Within this project,
when a partner wanted to introduce a change in the
specification, the PF provided him with the necessary
information and mechanisms to verify if the desired
modification would fit with the current development
situation. Through the use of this PF, the stakeholder can
take the decision to carry out the modification or to
postpone it to another version. Therefore a first benefit
that could be addressed by the use of the Process
Framework was better project management.
Our previous experience in managing and coordinating
international projects allowed us to draw comparisons
with the experience gained in this project. Instead of just
throwing away a new or changed requirement, it is
strongly recommended to analyze its impact on the overall
requirements and system specification, and then decide to
push it or delay it, or even discard it.
3UREOHPFRPSUHKHQVLRQ
One of the most important differences of this PF with
regard to other methodological approaches in the
requirements environment is the use of Problem Domain
models in order to understand the context in which the
requirements are stated.
It was especially useful in the analysis of the
DYNACORE and SIGA projects. Both projects have a
common characteristic: they involve complex concepts.
The Problem Domain was intrinsically difficult to
understand because of the particularities of the scientific
environment, in the first case, and the telecommunication
concepts, in the second one. The analysts of the SIGA
project initially used a classical E-R diagram to represent
the domain concepts. They translated this into a proposed
object diagram, with an enhancement of these concepts
supported on its internal behavior. Although this
representation is alternative, they found it very useful to
understand better the problem concepts.
An additional benefit derived from the use of a model
is the unification in the notation. One of the most
important problems during the elaboration of a consistent
requirement specification is the existence of synonyms. A
domain model defines each concept clearly and in a
unique way. The requirements must initially use the same
word while referring to the same concept to be created
within the problem model. Synonyms could be used with
adequate tool support.
6ROXWLRQVSHFLILFDWLRQ
Given a set of user requirements, the solution is not
automatic. At least in novel applications (novel to the
participants), the solution concept has to be “created” by
the analysts, and communicated to the client, to be
discussed, modified and eventually approved. This is the
purpose of the specification and it is quite distinct from
the user requirements. User requirements convey the
stakeholders' problems, needs and expectations. The
specification conveys a solution concept. This is basically
equivalent to the distinction made in standards between
“user” requirements and “system” or “software”
requirements.
This is the point on which the SIGA project focuses. In
this case, the analysts employed the Use Cases [3]
technique to represent user needs. The proposed PF
supports this representation through the relationship with
the user requirements: a requirement is solved by a Use
Case. This association between Use Cases and
requirements is quite useful to detect inconsistencies in
the course of the requirement specification.
In the SPS project, the final users were initially
unspecified. Within the analysis team, some analysts were
also domain experts. For this reason a reasonable
functional specification could be initially provided.
Therefore, during the initial solution specification, Use
Cases modeling [4] was the basic technique for functional
requirement description. The requirement elicitation
process was defined internally and could be modified on
the basis of future experience.
The relationships between the requirements and the
rest of the elements are the keys to ensure a correct and
useful specification and to trace them through the
remaining life cycle activities.
Our experience in the usage of Use Cases as a
description of the external behavior of a system is very
positive. We have found that this representation is easily
understood by end users with scant knowledge of
Software Engineering but is also sufficiently useful for the
development team for it to be used in the early stages of
the design phase.
5HTXLUHPHQWVDQDO\VLV
DYNACORE involved more than 300 requirements
and around 40 problem concepts. When we tried to
analyze this volume of information, we found that a
traditional RDB structure was insufficient to organize it
adequately. One of the facilities needed was the flexible
selection of particular requirements according to various
criteria. The implementation of this facility on a standard
RDB Management System implies the creation of
particular queries for each restriction or organization of
the requirement list. A more efficient mechanism was
needed to organize and display the information. Finally
the tool developed implemented a multi-criteria
classification option with a tree-representation control to
organize the requirements list. This technique has
demonstrated good results from the viewpoint of the
analysis. Based on different classifications, the analyst can
make decisions about the requirements specification on-
line.
The concept of domain facet was successfully used in
the DYNACORE project to allow the classification by
different context aspects. The benefit obtained by the use
of domain-dependent facets is the possibility to classify
the requirements from very different problem viewpoints.
3DWKVHOHFWLRQ
Based on our experience, we have found two different
sequences of activities through the PF. The first one took
place during the first phase of the project DYNACORE
(named REMOT). At the beginning, the involved
stakeholders (astronomers and plasma physicists) had a
general idea of what they wanted from such a remote-
operated system. The problem to be solved was diffuse,
unclear. The scientific particularities made
communication with the system analysts especially
difficult. In such a context, a first non-structured user
requirements capture was needed to establish a baseline to
construct the problem specification. The subsequent
activity of analyzing the information obtained was the
natural second step in the process. Once the Problem
Domain was sufficiently clear and the user requirements
structured and associated with the problem concepts, the
third activity was to obtain the functional specification of
the system. In this matter the Use Cases technique was
particularly useful. Of course, in the first iteration many
mistakes were found after verification.
In the case of the SIGA project, the analysts had prior
experience of specifying and building similar systems.
They had a clear idea of the problem (the system was
developed ‘in house’, with no other participant), and the
emphasis had to be put on the functional aspects of the
system. The first step was the construction of the software
specification. They just had to focus on what the system
had to provide. Once the functional aspects were covered,
next came the selection of known requirements, applied to
this project, and the establishment of known problem
concepts. They managed an existing E-R model used in
other projects with an RDB representation. The pure
requirement elicitation did not occur because the
requirements existed prior to the definition of the
particular problem. Of course, the verification activity was
needed to detect and correct the definition mistakes. In
this case the stakeholders were not end users but project
engineers and the engineers responsible for other systems.
5HTXLUHPHQWVPDQDJHPHQW
The problem of managing requirements depends on
their evolution and their relationship with the design.
Good requirement management is needed to achieve the
success of the global development process.
In the SPS project, the PF support tool was used for
requirements structuring and labeling. Domain
independent facets were applied to classify requirements
for project management purposes. The project analysts
found that the tool was beneficial considering its
capabilities for: grouping requirements into domains,
classifying requirements with domain independent facets
(attributes) and maintaining a centralized database of
requirements.
This last point reinforces the PF idea of “knowledge
management” in a corporate environment. The
information contained in the specification of a system can
be shared throughout the rest of the organization to be
used by other development groups in other similar
projects.
This experience showed that some aspects of the PF
could be improved, such as the traceability of
requirements, the impact analysis of requirement changes
or the communication with other tools (project
management tools, CASE design tools, etc.)
Another interesting experience in this field was
obtained during the development of the DYNACORE
project. As mentioned above, this project included many
requirements and problem concepts. This complexity
caused management difficulties (see 3.1).
&RQFOXVLRQV
The framework seems to have good acceptance in
organizations. Several of them are evaluating it for
possible adoption, while some others have started to use it
in pilot projects. The framework provides a
comprehensive set of concepts, activities and techniques
that constitute a good reference for organizations.
It requires further work to integrate it with different
activities (estimation, testing and validation, project
management, requirements tracing…) and different
development methods.
A problem that has appeared repeatedly is the effort
required to build the Problem Domain models and to link
the user requirements to them. Still worse, when
requirements –and models- evolve, there is a substantial
effort required to keep them consistent and synchronized.
We are now working with a University department on
automating as far as possible the model extraction and
linkage identification, and especially the revision of the
whole info set after each change is introduced. Although
complete automation seams neither feasible nor desirable,
this will substantially alleviate the analysts’ job, leaving
them with the task of checking what the automatic tool
may propose and completing the analysis, an activity that
has to be maintained because it is crucial for gaining a
shared understanding of the problem.
In RE, there is always some tendency to become
formal. We have intentionally tried to avoid formal
techniques, because they preclude the participation of
many analysts and of almost all stakeholders. We tried to
use semi-formal but expressive techniques that facilitate
the participation of all stakeholders. The process is
therefore not designed for safety-critical applications that
require a formal demonstration. But it can be used in such
cases provided formal techniques are incorporated into the
framework.
The framework does not explicitly differentiate
between functional and non-functional requirements. For
the requirements collection and analysis activities,
sufficient techniques are given to handle these differences.
However, the Use Case-driven specification is clearly
oriented towards the functional part of the specification.
This may need to be complemented with specific
techniques for the non-functional aspects.
We suspect that, although requirement evolution is
unavoidable, a significant part of that “evolution” is just
the process of stakeholders becoming aware of the
meaning of the requirements and of their implications. So
it should pay off to dedicate some effort to analyze and
clarify the requirements, and to build a common
understanding among all participants in the process. This
has still to be proven.
The methods and techniques require exposure to the
international university and industry communities. This is
the main reason for this paper. Therefore, all comments,
suggestions and criticisms can be addressed to the authors
and will be welcomed.
$FNQRZOHGJHPHQWV
We want to express our gratitude to Dr. José L.
Fernández from Caja Madrid, Mr. José R. Yeste and
Mr. Antonio Hedo from Telefónica I+D, and Mr. Julio
Rejas, Telematic Applications Div. Manager from TCP,
for their experience in the mentioned projects.
3URMHFWV
[Project1]: REMOT (Remote Experiment MOnitoring &
ConTrol), DYNACORE (DYNAmically COnfigurable
REMOT)
The objective of the DYNACORE project is to provide
scientists and astronomers with a tool for remote
operation of experiments and facilities that require real-
time control and multimedia information feedback, using
communications infrastructures available to European
researchers.
Contact person: Julio Rejas. TCP Sistemas e Ingeniería.
López de Hoyos, 327, 28043 Madrid, Spain. (e-mail:
jrejas@tcpsi.es).
Project web page: http://www.tcpsi.es/dynacore
[Project2]: Sales Promotion System (SPS)
Caja Madrid Requirements Engineering Group used
the PF support tool for requirements management of the
Sales Promotion System developed in-house. The Sales
Promotion System supports the acquisition of products
sold by third parties to the bank’s customers, ensuring best
price policies, and arranged payment conditions.
Contact person: José L. Fernández. Caja Madrid, Las
Rozas, 28230 Madrid, Spain.
Web page: http://www.cajamadrid.es
[Project3]: SIGA ‘Sistema Integrado de Gestión ADSL’
(ADSL Integrated Management System)
The system developed facilitates the automatic
provision of connection between end users and GIGADSL
service clients. These clients are usually Internet
providers. The system also provides service monitoring
and management.
Contact person: José R. Yeste. Division Manager.
Telefónica I+D. Emilio Vargas, 6 28043 Madrid, Spain.
(e-mail: jramon@tid.es)
Web page: http://www.tid.es
5HIHUHQFHV
[1] J. Siddiqui and M. Chandra Shekaran, “Requirements
Engineering: The Emerging Wisdom”, IEEE Software,
Mar. 1996
[2] M. Jackson, Software Requirements and
Specifications, Addison-Wesley, 1995
[3] I. Jacobson, Object-Oriented Software Engineering,
Addison-Wesley / ACM Press, 1992
[4] I. Jacobson et. al., The Unified Software Development
Process, Addison-Wesley / ACM Press, 1999
[5] Cohen, S., et. al. “Feature Oriented Domain Analysis
(FODA) Feasibility Study”, CMU, 1990
[6] Prieto-Diaz, R., “Domain Analysis for Reuse: A
Practical Approach”, ESEC'95
[7] R. Wirfs-Brock et al., Designing Object Oriented
Software, Prentice Hall
[8] Unified Modeling Language Specification (UML),
Object Management Group, Inc., http://www.omg.com
[9] IRqA - Integral Requisite Analyzer , TCP Sistemas e
Ingenieria, http://www.tcpsi.es/irqa
$FURQ\PV
ADSL: Asymmetric Digital Subscriber Line
CASE: Computer Aided Software Engineering
IRqA: Integral Requisite Analyzer
OO: Object Oriented
PD: Problem Domain
PF: Process Framework
RDB: Relational Data Base
RE: Requirements Engineering
UML: Unified Modeling Language