Submitted by Isaac Francisco de Souza Dias (isaac.souzadias@ufpe.br) on 2015-05-15T18:23:09Z No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) MASTER THESIS VERSAO BIBLIOTECA.pdf: 2607756 bytes, checksum: f3fc68e302dd5e0adcd2e9c5c95d61fe (MD5) / Made available in DSpace on 2015-05-15T18:23:09Z (GMT). No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) MASTER THESIS VERSAO BIBLIOTECA.pdf: 2607756 bytes, checksum: f3fc68e302dd5e0adcd2e9c5c95d61fe (MD5) Previous issue date: 2009-09-02 / A Engenharia de requisitos tem sido amplamente reconhecida como um fator crítico de sucesso de projetos de Software. Se não forem devidamente elicitados, os requisitos podem levar o projeto ao fracasso. A elicitação equivocada dos requisitos pode estar relacionada com a falta de compreensão do negócio pelo analista de sistemas, a falta entendimento dos objetivos do sistema, bem como a falta de comunicação entre analistas de negócio e analistas de sistema. A existência de uma lacuna entre os domínios do negócio e da computação podem causar desequilíbrios entre o que os usuários finais precisam e o que os analistas de sistema desenvolvem. Uma das razões para o problema de comunicação é que os modelos de requisitos utilizados para interagir com os usuários finais podem ser difíceis de serem compreendidos e validados em função da alta complexidade das notações. Além disso, os erros provocados por não lidar com requisitos, especialmente os não-funcionais, convenientemente são apontados como os mais caros e difíceis de corrigir. O problema tratado nesta dissertação é a integração dos requisitos não-funcionais aos modelos de processos de negócio, através de notações intuitivas para todos os usuários envolvidos no processo. Para isso, uma pesquisa baseada em análise de requisitos não-funcionais e modelagem de processos de negócio é apresentada. Portanto, propomos uma abordagem para inserir os requisitos não-funcionais na notação Business Process Modeling Notation (BPMN). A abordagem utiliza catálogos para requisitos não-funcionais, descritos na notação Non-Functional Requirement (NFR), que orientam a descoberta das suas operacionalizações. Esta abordagem é validada com um estudo de caso real.

Esta tese tem o objetivo de definir um processo para análise de requisitos não-funcionais orientado a aspectos denominado PARNAFOA. Este processo utiliza, de maneira integrada, métodos de tratamento de requisitos não-funcionais, baseados no NFR Framework, e métodos orientados a aspectos. Como resultado principal obtém-se um modelo de casos de uso que incorpora novas funções relacionadas aos requisitos não-funcionais. A aplicação do PARNAFOA foi realizada em cinco sistemas de software, com domínios, características e complexidades diversos. A avaliação da aplicação deste processo mostrou que o tratamento dos requisitos não-funcionais, desde as fases iniciais do desenvolvimento dos sistemas de software, complementa o modelo de casos de uso com funções adicionais ou gera restrições de projeto. Se estes requisitos não forem considerados desde o início, a introdução posterior dessas funções pode causar alterações nos modelos consolidados ou as atividades de projeto podem ser realizadas sem considerar as restrições. As aplicações do PARNAFOA e sua conseqüente melhoria, incorporada após sua avaliação, permitiu torná-lo mais flexível do que sua versal inicial. Aplicações futuras, com outros tipos de requisitos não-funcionais, irão permitir o amadurecimento deste processo. / The aim of this thesis is to define an aspect-oriented non-functional requirements analysis process named PARNAFOA. This process applies nonfunctional requirements methods in an integrated manner, based on NFR Framework, and aspect-oriented methods. A use case model that embodies non-functional requirements as new functions is the main result obtained from this process. PARNAFOA application was performed in five software systems, with diverse features, domains and complexities. The evaluation of this process application showed that the treatment of these non-functional requirements, from the early phases of software systems development, complements the use case model with additional new functions or generates project restrictions. If these requirements are not considered from the very beginning, the introduction of these functions at a later phase can generate modifications in consolidated models or project activities, that do not consider these restrictions, can be performed. The PARNAFOA applications and consequent improvement, incorporated after the assessment, allowed it to become more flexible than the initial version. Future applications, with other non-functional requirements types, will provide this process maturity.

Esta tese tem o objetivo de definir um processo para análise de requisitos não-funcionais orientado a aspectos denominado PARNAFOA. Este processo utiliza, de maneira integrada, métodos de tratamento de requisitos não-funcionais, baseados no NFR Framework, e métodos orientados a aspectos. Como resultado principal obtém-se um modelo de casos de uso que incorpora novas funções relacionadas aos requisitos não-funcionais. A aplicação do PARNAFOA foi realizada em cinco sistemas de software, com domínios, características e complexidades diversos. A avaliação da aplicação deste processo mostrou que o tratamento dos requisitos não-funcionais, desde as fases iniciais do desenvolvimento dos sistemas de software, complementa o modelo de casos de uso com funções adicionais ou gera restrições de projeto. Se estes requisitos não forem considerados desde o início, a introdução posterior dessas funções pode causar alterações nos modelos consolidados ou as atividades de projeto podem ser realizadas sem considerar as restrições. As aplicações do PARNAFOA e sua conseqüente melhoria, incorporada após sua avaliação, permitiu torná-lo mais flexível do que sua versal inicial. Aplicações futuras, com outros tipos de requisitos não-funcionais, irão permitir o amadurecimento deste processo. / The aim of this thesis is to define an aspect-oriented non-functional requirements analysis process named PARNAFOA. This process applies nonfunctional requirements methods in an integrated manner, based on NFR Framework, and aspect-oriented methods. A use case model that embodies non-functional requirements as new functions is the main result obtained from this process. PARNAFOA application was performed in five software systems, with diverse features, domains and complexities. The evaluation of this process application showed that the treatment of these non-functional requirements, from the early phases of software systems development, complements the use case model with additional new functions or generates project restrictions. If these requirements are not considered from the very beginning, the introduction of these functions at a later phase can generate modifications in consolidated models or project activities, that do not consider these restrictions, can be performed. The PARNAFOA applications and consequent improvement, incorporated after the assessment, allowed it to become more flexible than the initial version. Future applications, with other non-functional requirements types, will provide this process maturity.

Made available in DSpace on 2014-12-17T15:48:08Z (GMT). No. of bitstreams: 1 FabioAGS_DISSERT.pdf: 1631308 bytes, checksum: cb5c8aa720129c7e7b32a24acd2a4b2c (MD5) Previous issue date: 2013-07-30 / The importance of non-functional requirements for computer systems is increasing. Satisfying these requirements requires special attention to the software architecture, since an unsuitable architecture introduces greater complexity in addition to the intrinsic complexity of the system. Some studies have shown that, despite requirements engineering and software architecture activities act on different aspects of development, they must be performed iteratively and intertwined to produce satisfactory software systems. The STREAM process presents a systematic approach to reduce the gap between requirements and architecture development, emphasizing the functional requirements, but using the non-functional requirements in an ad hoc way. However, non-functional requirements typically influence the system as a whole. Thus, the STREAM uses Architectural Patterns to refine the software architecture. These patterns are chosen by using non-functional requirements in an ad hoc way. This master thesis presents a process to improve STREAM in making the choice of architectural patterns systematic by using non-functional requirements, in order to guide the refinement of a software architecture / Cada vez mais os sistemas computacionais precisam satisfazer requisitos n?ofuncionais. No entanto a satisfa??o destes requisitos exige uma aten??o especial j? que s?o requisitos que devem ser levados em considera??o pelas arquiteturas de software que representam esses sistemas. Uma arquitetura de software inadequada introduz uma complexidade maior, al?m da complexidade intr?nseca do sistema. Al?m disso, estudos mostram que apesar das atividades de engenharia de requisitos e de arquitetura de software atuarem em diferentes aspectos do desenvolvimento, ? preciso execut?- las de forma iterativa e entrela?ada para produzir sistemas computacionais satisfat?rios. Com o objetivo de diminuir a lacuna existente entre requisitos de software e o desenvolvimento de uma arquitetura de software que reflita esses requisitos, foi proposto o processo STREAM (Strategy for Transition between REquirements models and Architectural Models). O STREAM consiste de uma abordagem sistem?tica que enfatiza os requisitos funcionais, sendo os n?o-funcionais usados de forma ad hoc. Entretanto, os requisitos n?o-funcionais normalmente impactam o sistema como um todo. Assim, a maneira proposta pelo STREAM para fazer com que a arquitetura de software desenvolvida reflita os Requisitos N?o-Funcionais elicitados no modelo de requisitos ? atrav?s do refinamento da arquitetura usando padr?es arquiteturais escolhidos com base nos requisitos n?o-funcionais. No STREAM a escolha desses padr?es ? realizada de forma ad hoc. Com o objetivo de sistematizar a forma de escolha dos padr?es arquiteturais, esta disserta??o prop?e um processo para sistematizar a escolha desses padr?es, a partir de requisitos n?o-funcionais racionalizados, que ser?o usados para refinar arquitetura de software