![](bg2.png)
few consider software tools aiming for requirements
reuse.
Many authors refer to software system functional
requirements as goals. Sem and Hemachandram
(2012) present goals as a method to identify
requirements during the requirement engineering
phase. Rocco (2002) asserts that software goals
settle guidelines to organize what is being needed by
users.
Based on this perspective, Fook and
Abdelouahab (2001) proposed a goal reuse method
for requirements engineering, MROBJER. This
method focuses on improving requirements
elicitation, analysis and validation. Authors develop
FROBJER, a computational tool to apply
MROBJER. Differently from the proposed tools, the
reuse is the focus of FROBJER.
3 MROBJER
The goal reuse method for Requirement
Engineering, MROBJER, allows the goals and
scenarios reuse through complex applications
analogy. Authors consider that clients can easily list
goals to be reached in their tasks.
First, requirement engineers map a structure to
compare applications from the same or different
Domains, and then they identify the goals. In this
method reuse is not restricted to systems from the
same domain, but they also include systems from
different domains. There are different mapping
levels, such as software domain and the subdomain.
Following, the application is mapped as
functional aggregations set. Generic goals are also
identified with their respective scenarios.
Requirements engineers list goals considered
generic, the ones which may be common to other
applications. The approach proposes a generic goals
representation:
Gen
Goal
N = {Domain, “Description”, Main
Verb, Main Object, <Parameter> [0..n]}, where:
N: is the Goal identification number;
Description: is goal brief description;
n: number of goal parameters.
The verb and the main object of a generic goal
are identified. The generic goals contain variable
parts and are labeled parameters. They are identified
by determinants < >. Once the generic goals are
formatted, requirements engineer inserts all the
structure into a repository. Figure 1 shows the
structure mapping which allows goals reuse.
Figure 1: MROBJER Process (Castro and Fook, 2011).
The reuse happens whenever a new application uses
one or more generic goal from the repository.
Generic goals and scenarios can be partial or totally
reused by the new application. In case of partial use,
a parameterization process occurs. After reusing the
new application specific goals are included into
repository. The FROBJER produces a document
which can serve as a basis to the new application
Requirements Document. For more details on
MROBJER application, it is suggested to read Fook
and Abdelouahab (2001).
Although MROBJER may be applied in
manually
way, it becomes difficult to keep mapped
structures in simple text documents due to
information amount in these files. Thus there is a
tool to support MROBJER, FROBJER. This
program improves the method application through a
database repository instead of text document.
Besides, it supports best application of goals and
scenarios parameterization during partial reuse. Next
section presents FROBJER architecture.
4 FROBJER ARCHITECTURE
Once the new application is mapped, FROBJER
allows the requirements engineer to apply
MROBJER in a short time.
WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies
498