Requisitos de software: a vagueza e ambiguidade em um requisito de software

• Autor(a) principal: Bigonha, Renato Dias
• Data de Publicação: 2015
• Tipo de documento: Dissertação
• Idioma: por
• Título da fonte: Biblioteca Digital de Teses e Dissertações da PUC_SP
• Texto Completo: https://tede2.pucsp.br/handle/handle/18190
• topic: Requisitos; Vagueza; Ambiguidade; Linguagens; Requirements; Vagueness; Ambiguity; Languages; CNPQ::ENGENHARIAS

The development of a software system is a complex task. For development to occur, it is necessary communication between software developers and those interested in the use of such software (client). Through the interpretation of the client's intentions, is the specification of requirements that describe the features of the software and give rise to the application model. The use of natural language for such communication can bring ambiguities and vagueness communication and requirements specification. For any communication to take place a code or common language is needed for a sender and recipient and the software context, customer and developer. When the terms of the language used in communication does not mean exactly the same thing to both sides, communication can be impaired, giving way to the assumption, which may prove to generate specifications for software that does not meet customer needs. The fix for this software system can lead to rework that can be costly and increase development time. This research starts from the assumption that with the elimination or reduction of ambiguity and vagueness in communication and specification of the list of requirements, the resulting software development can be more likely to come to meet the client's goals. During the research it was noted that with the use of ubiquitous language during development can bring about improvements in development for proposing the setting of arbitrary terms according to the viewpoint and client context thus causing ambiguity and are reduced vagueness communication and requirements specification. But the requirements specification can never generate an absolute model, since the model is always abstracted from a different viewpoint