| dc.description.abstract | The Requirements Engineering (RE) goal is to sys-tematize the process of requirements construction and
management (Maculay, 1993; Reubenstein & Waters,
1991; Maté & Silva, 2005) along with the creation of
a compromise among clients and users with develop-ers, since both human groups must participate and
collaborate together. To accomplish such tasks, the
requirements engineers should understand and par-ticipate in the definition of the context of use for the
software system to be developed. The requirements
engineers usually ignore totally or partially both, the
current and the foreseen future context of use. The
latter must be conceived having as a resource the new
tool: the system software itself. Frequently, nobody
knows in detail such future context of use. To be able
to participate in the definition of the future business
process, the requirements engineers must understand
the current business process in advance. Therefore, the
Requirements Engineering process involves, as the first
step, elicitation and modeling of the current business
process and later, definition and modeling of the future
business process. Both models have different purposes.
The first one is used as a help for understanding the
current business process and as a tool to validate with
clients and users such understanding. The second one
is used as a help for the planning of the future busi-ness process, to validate such plans with the clients
and users, to specify the software requirements and to
give an environment reference for software designers.
The Requirements Engineering process consists
of three main activities: elicitation, modeling, and
analysis of the application domain (Kotonya & Som-merville, 1998; Sommerville & Sawyer, 1997). Analysis
includes the sub-activities of verification, validation
and negotiation. The difficulties that requirements
engineers must face to understand and elicit the clients
and users’ necessities are widely known. The more
complex the application domain, the more difficult
the definition or construction of software requirements
becomes. Many times, requirements engineers must
become themselves problem domain experts during
the acquisition of knowledge about the application
domain. Concurrently, Requirements Management
deals with the changes in the existent requirements and
the irruption of new ones (Kotonya & Sommerville,
1998; Sawyer & Kotonya, 2004) | |
