Beruflich Dokumente
Kultur Dokumente
1 2
TCP Sistemas e Ingeniería is a Madrid (Spain) -based software house. Initially a prototype tool was developed to support the PF. This
The Software Engineering Division of TCP provides consulting support prototype has finally derived in a commercial tool named Integral
both in-house and to external clients in software engineering methods Requisite Analyzer - IRqA [9].
and tools.
the proposed solutions. The experience gained in this and a) Users have a problem and a need to solve it. Analysts
two other projects is described below. have to understand the problem, the context in which
The team that started this job tried to use, when it arises, and the user’s expectations.
possible, already existing, reasonably proven techniques. b) Analysts “create” a solution they think suitable for the
Due to this background, mainly Object Oriented (OO) and user problem. Users have to understand what the
Domain Analysis techniques have been used, as can be analysts propose –the specification- and accept,
seen in the process description. But, over time, the modify, or discard it, preferably before starting the
emphasis has shifted from what technique is used to what application development.
are the activities that have to be performed, what are the And this is not a linear but a cyclic and iterative
results we are looking for, and how they fit into the process. The RE Process Framework is therefore
overall process. Although the techniques themselves are articulated around this loop.
not new, the way to integrate them and to perform the Another key aspect came to the fore when trying to
complete process constitutes a new approach in RE. This reconcile requirements from different stakeholders. It
paper describes the process and the experience obtained in soon became clear that, very often, they had substantially
applying it to several real projects in different differing mental models of the problem: whenever users
organizations. 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
7KHSURFHVV surprise then that it becomes very hard to understand –and
therefore to analyze- user requirements unless you
7KHVFHQDULR understand their context [1].
User requirements have a meaning and a structure only
The Process Framework was developed as an answer when referred to their primary context, the Problem
from TCP’s Software Engineering division to the Domain: the concepts that populate the area in which the
problems encountered during the requirements users carry out their activity, and in which they have a
specification phase by many software projects from other problem and expect a solution. Other artificial structures
company divisions. can be built upon the requirements, but the natural one is
Those problems were the typical ones related to given by its context.
requirements phases (problems related to the difficulty of Building a Problem Domain model, and situating the
eliciting user requirements and managing them in the user requirements in that context has therefore become
course of their evolution). But a problem that appeared one of the key techniques in our RE framework for
recurrently, especially in projects collecting requirements analyzing and building a common understanding of users’
from different stakeholders, was the large dispersion in problems. The importance of identifying the Problem
the style, aim and vocabulary used. Some way of Domain and clearly separating it from the solution domain
analyzing and organizing them not based on their has already been discussed extensively by Jackson [2]
structure, but rather on their meaning appeared to be a (who terms them as “application domain” and “machine
desirable objective. domain” respectively). We have verified the relevance,
This was the problem appointed to the SW. and the difficulty, of doing this in practice.
Engineering Div. that ultimately gave rise to the One last point is worth mentioning. There is no unique
development of the Process Framework. process in RE. This statement, quite obvious on the other
hand, has become clear when trying to standardize a
)RXQGDWLRQV process. This is why we have tried to formalize our
experience in a “Process Framework” that is intended to
The first approach to the complete process and the tool serve as a reference and as a guide, but not to cast any and
were ready by mid ’98. During the evolution of the RE all RE process into a fixed process pattern. We have
process definition, many problems appeared, both found substantial differences in the processes required,
theoretical and practical. During its evolution, some of depending on many factors. Among these, we can mention
these problems became clear to the team, highlighting key the level of formality required (having formal
aspects of the process. These key foundation concepts are requirements lists or not); the application novelty for
presented below. client and developer; the type of product (if it is an ad-hoc
The first point is key for structuring the process: the or free-standing product or a member of a product
basic problem that always underlies Requirements family).
Engineering activities is a communications problem, and
can be stated in a simple way:
7KH3URFHVV)UDPHZRUN Business process and organizational descriptions can
give additional information to understand the
We present below the main activities comprising the requirements. They are also part of the context.
RE Process Framework (Fig. 1). With each activity, we
suggest the techniques that we have found most useful to $QDO\]HUHTXLUHPHQWVE\PRGHOLQJWKH3UREOHP
obtain good results, and the way to use them. Other 'RPDLQThe key activity in the framework for analyzing
techniques could be used instead, in many cases: the key requirements is to build a Problem Domain Model
points are the objectives and the activities, not the specific (conceptual model). This is done, first, to capture all
techniques used (although we discuss the ones we have information relevant to the Problem Domain, concepts,
found most appropriate). characteristics, relationships. Clarifying vocabulary and
definitions is also an important part.
The objective is to build a common understanding of
Capture User Analyze
the Problem Domain concepts, vocabulary … among all
Requirements Requirements
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
Verify Build Solution appears to be a powerful way of representing and
Specification Specification characterizing concepts and their relationships within the
problem context. Entity-Relationship models are also a
suitable alternative.
Figure 1. Process framework activities
([DPSOH
A simple example, shown in boxed paragraphs, is used In the example, one of the user requirements could be
to illustrate each activity. described as “A document can be modified or
suppressed by the persons authorized by the department
([DPSOH manager”. The concepts related with this requirement
In a public organization a new system of documentation are “Document” and “Person” (see Fig. 2). The
access management is going to be built. This system particular approach used to model it (OO) involves the
organizes the documents within the institution and use of attributes and operations3 to characterize
manages the access to them by authorized people. internally the PD concepts. In this case, the concept
“Document” was associated with the requirement
&DSWXUH ZHOO LGHQWLILHG XVHU UHTXLUHPHQWV All through its operations “Modify” and “Suppress”.
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,...).
([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, expected to behave in its interaction with the external
independent criteria (hierarchical models can be described world.
with the classical OO techniques). The facets are used in
two ways, first as domain facets (classificatory aspects ([DPSOH
coming from the specific Problem Domain), and as Four services (Use Cases) were identified to describe
domain-independent facets, that are very useful for the external behavior of the system: “To register
managing the requirements and the project. documents in the system”, “To access documents to
consult them”, “To access documents to modify or
([DPSOH suppress them” and “To manage personnel”. Within the
In our example, six domain-dependent facets were used first service some internal activities were identified to
to classify the requirements: describe in detail the processing of a document (see
Fig. 3).
)DFHW 7HUP
Type of Access Confidential Use Cases [3] are becoming one of the key techniques
Free for specifying application requirements. They are intuitive
Type of Person Department manager and fit well both with OO styles and with functional
Librarian styles. Building a Use Case specification model is
Secretary therefore used as key technique for specifying. The Use
Hour of the day Morning Cases have also been enriched with additional techniques
Afternoon (state-charts in the activity-event style, UML notation [8];
Document Origin Internal and responsibility-oriented descriptions, in the sense used
External by Wirfs-Brock [7]) to strengthen its formality and level
Document Format Paper of detail, as suggested by UML/UMP [3] and others [4].
Electronic
Document Type Technical document
Memorandum
Notification
Minutes of meetings