Show simple item record

dc.contributor.authorHadad, Graciela D. S.
dc.contributor.authorLitvak, Claudia S.
dc.contributor.authorDoorn, Jorge H.
dc.contributor.authorRidao, Marcela
dc.date.accessioned2015-04-15T20:41:57Z
dc.date.available2015-04-15T20:41:57Z
dc.date.issued2014
dc.identifier.urihttp://repositorio.ub.edu.ar/handle/123456789/4860
dc.description.abstractThe 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)es_ES
dc.language.isoenes_ES
dc.publisher.EditorUniversidad de Belgrano - Facultad de Ingeniería y Tecnología Informática - Proyectos de Investigación
dc.relation.ispartofseriesEncyclopedia of Information Science and Technology, Third Edition. Editorial: IGI Global.;2014
dc.subjectCompletenesses_ES
dc.subjectRequirements Engineeringes_ES
dc.subjectRequisitos de Ingenieríaes_ES
dc.subjectlo completoes_ES
dc.subjectIngenieríaes_ES
dc.subjectengineeringes_ES
dc.titleDealing with Completeness in Requirements Engineeringes_ES
dc.typeArticlees_ES


Files in this item

Thumbnail

This item appears in the following Collection(s)

Show simple item record