1 |
Integração de Requisitos não Funcionais a Processos de Negócios: Integrando BPMN e NFRXAVIER, Laís 02 September 2009 (has links)
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.
|
2 |
PARNAFOA: um processo de análise de requisitos não-funcionais orientado a aspectos. / PARNAFOA: an aspect-oriented non-functional requirements analysis process.Bombonatti, Denise Lazzeri Gastaldo 19 August 2010 (has links)
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.
|
3 |
PARNAFOA: um processo de análise de requisitos não-funcionais orientado a aspectos. / PARNAFOA: an aspect-oriented non-functional requirements analysis process.Denise Lazzeri Gastaldo Bombonatti 19 August 2010 (has links)
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.
|
4 |
STREAM-AP: um processo para sistematizar a escolha de padr?es arquiteturais baseado em requisitos n?o-funcionaisSilva, Fabio Alexandre Gon?alves 30 July 2013 (has links)
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
|
Page generated in 0.054 seconds