Aus Punkt 1.: "We state a growing importance in of implicit factors in user's decision making. The products they choose to use are no longer sufficient only addressing the basic functional requirements. Due to higher living standards, the users now ask for more than just the consideration of accessibility terms. "[…] People have gradually enhanced their survival mentality from the materialistic fulfilment into the emotional one. This phenomenon has transcended producers’ role in the market. They do not only manufacture products and provide goods, but they should also create a kind of product that can create atmosphere and stories, so that consumers can experience deeper satisfaction and emotions in their purchase behaviour." (Huang & Guan 2014) There is a stronger focus on emotional aspects affecting users' product selection as ever before. Physiological UCD, however, already is a challenging task itself, regarding all parties and factors influencing its decision making process, so the concentration on other, more subjective factors still remain widely unconsidered. Recent User Centred Design (UCD) approaches already take up this fact, but still this is at the very beginning regarding UCD implementation (Law et al. 2010). ..."

[pt] Em geral, os Requisitos Não-funcionais (RNFs) só são tratados nas atividades relacionadas à arquitetura do software, e, muitas vezes, apenas durante a implementação. Essa situação resulta em custos mais altos e menor qualidade do software. Este trabalho estuda mecanismos para ressaltar os RNFs durante as atividades de construção de requisitos. A escolha dos requisitos pelos diversos interessados, dentro do processo de elicitação de requisitos do software através do consenso, é um problema complexo. Representar e estruturar dinâmicas de grupos, que são compostas por ações humanas, é um desafio. Durante o processo de decisão em grupo ocorre o debate de um conjunto de idéias, nem sempre expostas de maneira clara e nem sempre entendidas por todos da mesma forma. O debate envolve vários perfis de participantes, com pontos de vista distintos, e por vezes conflitantes. Sendo tais diferenças, em contra partida, fundamentais para a qualidade da decisão em grupo, pois as ideias são analisadas sob vários ângulos. Um processo colaborativo de construção de RNFs e seu suporte computacional são propostos. A abordagem de Negociação - Colaboração é reutilizada para trabalhar especificamente RNFs. Leva em consideração não apenas a construção dos RNFs em si, mas também a construção de suas interdependências. Tais interdependências entre os requisitos impactam a própria decisão sobre os RNFs a serem construídos. A avaliação do processo foi apoiada por um software desenvolvido para suporte, ao mesmo tempo, de mecanismos de Negociação-Colaboração e de atividades de especificação de RNFs. O software é assíncrono e distribuído geograficamente, facilitando a comunicação em grupo, mesmo que com membros distantes fisicamente. Foram realizadas três atividades avaliativas e os resultados produzidos demonstraram indícios positivos ao uso do processo na construção de RNFs. Para cada um dos projetos usados nas avaliações, foi produzida uma lista de RNFs cujo a consistência foi julgada pelos participantes envolvidos como suficientemente satisfatória. O número de RNFs foi dobrado nas três atividades de construção, revelando uma maior cobertura relativa aos atributos de qualidade inicialmente elencados para os softwares. / [en] Non-Functional Requirements (NFRs) are often managed late, either during design or, more often, just at implementation. This trend results in higher costs and low-quality software. Our work studies mechanisms to support RNFs, based on the collaborative dynamics of a negotiation process, during the requirements construction activities As such, we created a collaborative strategy for the construction of NFRs. An evaluation was conducted using a tailored tool built to implement the proposed Negotiation-Collaboration mechanisms. The choice of requirements by various stakeholders, within the process of eliciting software requirements through consensus, is a complex problem. Representing and structuring group dynamics, which are composed of human actions, is a challenge. During the group decision-making process, a set of ideas is debated, not always clearly expressed and not always understood by everyone in the same way. The debate involves several profilesq of participants, with different and sometimes conflicting points of view. Such differences, however, are fundamental to the quality of the group decision, as the ideas are analyzed from various perspectives. A collaborative strategy for building RNFs and their computational support is proposed. The Negotiation-Collaboration approach is reused to work specifically with RNFs. It takes into account not only the construction of the RNFs themselves, but also the construction of their interdependencies. Such interdependencies between the requirements impact the decision on the RNFs to be built. The strategy evaluation was supported by software developed to support, at the same time, Negotiation-Collaboration mechanisms and RNFs specification activities. The software is asynchronous and geographically distributed, facilitating group communication, even with physically distant members. Three evaluative activities were carried out, and the results showed positive indications for the use of the strategy in the construction of RNFs. For each of the projects used in the evaluations, a list of RNFs was produced, whose consistency was judged by the participants involved to be sufficiently satisfactory. The number of RNFs was duplicated in the three construction activities, revealing greater coverage regarding the quality attributes initially listed for the software.

[pt] O projeto de software resulta das decisões ao longo do seu desenvolvimento. Algumas dessas decisões podem levar a problemas de projeto, afetando negativamente os requisitos não funcionais (RNFs). Embora seja crucial identificar esses problemas, essa é uma tarefa complexa, especialmente quando o código-fonte é o único artefato disponível. Nessa tarefa, os desenvolvedores podem ter que considerar vários sintomas (por exemplo, anomalias de código) para identificar até mesmo um único problema de projeto. Estudos anteriores sugerem que usar um único sintoma pode ser inadequado para identificar tais problemas. Portanto, nesta tese, investigamos como múltiplos sintomas podem ser usados nessa identificação. Em nosso primeiro estudo, nos concentramos em investigar o uso de anomalias de código bem conhecidos (anomalias de manutenabilidade). Nós identificamos que os desenvolvedores podem se beneficiar desse tipo de sintoma quando as ocorrências das anomalias afetam a mesma localização do programa e formam um padrão, podendo indicar melhor a presença de um problema de projeto. No entanto, também revelamos as limitações ao depender exclusivamente desse tipo de sintoma, destacando a necessidade de contexto adicional. Isso nos levou ao segundo estudo, onde investigamos um tipo adicional de sintoma, anomalias de robustez, e seu uso combinado com anumalias de manutenabilidade. Nós identificamos que ambos os tipos de anomalia de código podem ajudar os desenvolvedores na identificação de problemas de projeto principalmente relacionados à má modularização do sistema. Através desses dois estudos, observamos a necessidade de compreender as perspectivas e estratégias dos desenvolvedores em relação aos RNFs do sistema. Ao fazê-lo, podemos potencialmente entender quem são os desenvolvedores mais capazes de prevenir, discutir e identificar problemas de projeto. Isso nos levou ao terceiro estudo, onde investigamos como os desenvolvedores discutem e abordam RNFs em seus sistemas, revelando estratégias comuns em relação a esses requisitos. Esses resultados nos proporcionaram uma compreensão mais abrangente de como os desenvolvedores podem combinar diferentes sintomas e como percebem sua importância dentro de seus sistemas. / [en] Software design results from stakeholder decisions made through software development. Some of these decisions may lead to design problems, negatively impacting non-functional requirements (NFRs). Even though identifying design problems is crucial, this is a complex task, especially when the source code is the only artifact available. Along this task, developers may have to reason about multiple symptoms (e.g., code smells and nonconformities with NFRs) to identify even a single design problem. In fact, previous studies suggest that relying on a single symptom may be inadequate for the design problem identification. Thus, in this thesis, we investigate the role that the use of multiple symptoms may have on the identification of design problems. In our first study, we focused on investigating the use of well-known code smells (called here maintainability smells) to support this task. Our results indicated that developers could benefit from this type of symptom when smell occurrences affect the same program location and form a pattern; i.e., a set of co-occurring maintainability smells may better indicate the presence of a design problem. Nevertheless, we also reveal the limitations of relying solely on this type of symptom, highlighting the need for additional context. This leads us to the second study, where we investigate an additional type of symptom, robustness smells, and its combined use with maintainability smells. Our results indicated that the use of both types of smells can help developers in the identification of design problems mainly related to bad modularization of the system (e.g. excess of responsibilities assigned to the same component). Through these two studies, we observed the need to understand the perspectives and strategies of developers toward the NFRs of the system. In doing so, we can potentially understand who are the developers better able to prevent, discuss and identify design problems. That led us to our third study, where we investigated how developers discuss and address NFRs in their systems, uncovering common strategies toward these requirements. These results led us to a more comprehensive understanding of how developers can combine different symptoms and how they perceive their significance within their systems.

Agile software engineering has been a popular methodology to develop software rapidly and efficiently. However, the Agile methodology often favors Functional Requirements (FRs) due to the nature of agile software development, and strongly neglects Non-Functional Requirements (NFRs). Neglecting NFRs has negative impacts on software products that have resulted in poor quality and higher cost to fix problems in later stages of software development. This research developed the CEP “Capture Elicit Prioritize” methodology to effectively gather NFRs metadata from software requirement artifacts such as documents and images. Artifact included the Optical Character Recognition (OCR) artifact which gathered metadata from images. The other artifacts included: Database Artifact, NFR Locator Plus, NFR Priority Artifact, and Visualization Artifact. The NFRs metadata gathered reduced false positives to include NFRs in the early stages of software requirements gathering along with FRs. Furthermore, NFRs were prioritized using existing FRs methodologies which are important to stakeholders as well as software engineers in delivering quality software. This research built on prior studies by specifically focusing on NFRs during the early stages of agile software development. Validation of the CEP methodology was accomplished by using the 26 requirements of the European Union (EU) eProcurement System. The NORMAP methodology was used as a baseline. In addition, the NERV methodology baseline results were used for comparison. The research results show that the CEP methodology successfully identified NFRs in 56 out of 57 requirement sentences that contained NFRs compared to 50 of the baseline and 55 of the NERV methodology. The results showed that the CEP methodology was successful in eliciting 98.24% of the baseline compared to the NORMAP methodology of 87.71%. This represents an improvement of 10.53% compared to the baseline results. of The NERV methodology result was 96.49% which represents an improvement of 1.75% for CEP. The CEP methodology successfully elicited 86 out of 88 NFR compared to the baseline NORMAP methodology of 75 and NERV methodology of 82. The NFR count elicitation success for the CEP methodology was 97.73 % compared to NORMAP methodology of 85.24 %which is an improvement of 12.49%. Comparison to the NERV methodology of 93.18%, CEP has an improvement of 4.55%. CEP methodology utilized the associated NFR Metadata (NFRM)/Figures/images and linked them to the related requirements to improve over the NORMAP and NERV methodologies. There were 29 baseline NFRs that were found in the associated Figures/images (NFRM) and 129 NFRs were both in the requirement sentence and the associated Figure/images (NFRM). Another goal of this study was to improve the prioritization of NFRs compared to prior studies. This research provided effective techniques to prioritize NFRs during the early stages of agile software development and the impacts that NFRs have on the software development process. The CEP methodology effectively prioritized NFRs by utilizing the αβγ-framework in a similarly way to FRs. The sub-process of the αβγ-framework was modified in a way that provided a very attractive feature to agile team members. Modification allowed the replacement of parts of the αβγ-framework to suit the team’s specific needs in prioritizing NFRs. The top five requirements based on NFR prioritization were the following: 12.3, 24.5, 15.3, 7.5, and 7.1. The prioritization of NFRs fit the agile software development cycle and allows agile developers and members to plan accordingly to accommodate time and budget constraints.

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.

A utilização da Internet como um meio de automação de serviços de e-business tem sido adotada como estratégia por empresas em vários ramos da economia, diminuindo custos e propiciando uma melhoria no relacionamento com o cliente. Um requisito não-funcional importante a ser considerado no desenvolvimento de sistemas de software que possibilita esta automação é a disponibilidade. O nível de disponibilidade de um sistema pode ser influenciado pela arquitetura do sistema, e, em particular, pela arquitetura de software, pois as decisões arquitetônicas devem considerar aspectos relacionados à disponibilidade. No método de avaliação de arquitetura ATAM (Architecture Tradeoff Analysis Method Método de Análise de Compromissos de Arquitetura), esse requisito é analisado através da utilização de cenários de disponibilidade. Como a avaliação da disponibilidade é normalmente uma tarefa complexa, requerendo dos analistas a identificação de numerosos itens interdependentes, a geração e, conseqüentemente, a análise de cenários de disponibilidade na maioria das vezes não é uma tarefa trivial. O presente trabalho tem como objetivo elaborar uma técnica de análise de disponibilidade em sistemas de software para a Web, que auxilie a geração sistemática de cenários de disponibilidade requeridos no método ATAM. Para a elaboração da proposta, o trabalho aborda métodos para a elicitação, representação e análise de requisitos não-funcionais em uma determinada arquitetura de software, bem como conceitos e taxonomias relacionadas à dependabilidade. Ao final, a técnica é exercitada em um exemplo simplificado de sistema de software bancário na Web. / The use of Internet for e-business service automation has been adopted as a strategy by organizations in several sectors of the economy, reducing costs and providing a better relationship with the customer. Availability is an important nonfunctional requirement to be considered in the development of software systems offering this type of automation. The level of system availability may be affected by the system architecture, and, especially, by the software architecture, as architectural decisions must take availability-related aspects into account. In the ATAM (Architecture Tradeoff Analysis Method) architecture evaluation method, this requirement is analyzed by means of availability scenarios. As availability evaluation is normally a complex task, requiring analysts to identify several interdependent items, the generation and, consequently, the analysis of availability scenarios is often not a trivial task. This work aims to elaborate an availability technique analysis for web-based software systems, to aid in the systematic generation of availability scenarios required in the ATAM method. To elaborate the proposal, the work covers methods for elicitation, representation and analysis of non-functional requirements in a specific software architecture, as well as concepts and taxonomies related to dependability. In the end, the technique is applied on a simplified example of web banking software system.

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.

A utilização da Internet como um meio de automação de serviços de e-business tem sido adotada como estratégia por empresas em vários ramos da economia, diminuindo custos e propiciando uma melhoria no relacionamento com o cliente. Um requisito não-funcional importante a ser considerado no desenvolvimento de sistemas de software que possibilita esta automação é a disponibilidade. O nível de disponibilidade de um sistema pode ser influenciado pela arquitetura do sistema, e, em particular, pela arquitetura de software, pois as decisões arquitetônicas devem considerar aspectos relacionados à disponibilidade. No método de avaliação de arquitetura ATAM (Architecture Tradeoff Analysis Method Método de Análise de Compromissos de Arquitetura), esse requisito é analisado através da utilização de cenários de disponibilidade. Como a avaliação da disponibilidade é normalmente uma tarefa complexa, requerendo dos analistas a identificação de numerosos itens interdependentes, a geração e, conseqüentemente, a análise de cenários de disponibilidade na maioria das vezes não é uma tarefa trivial. O presente trabalho tem como objetivo elaborar uma técnica de análise de disponibilidade em sistemas de software para a Web, que auxilie a geração sistemática de cenários de disponibilidade requeridos no método ATAM. Para a elaboração da proposta, o trabalho aborda métodos para a elicitação, representação e análise de requisitos não-funcionais em uma determinada arquitetura de software, bem como conceitos e taxonomias relacionadas à dependabilidade. Ao final, a técnica é exercitada em um exemplo simplificado de sistema de software bancário na Web. / The use of Internet for e-business service automation has been adopted as a strategy by organizations in several sectors of the economy, reducing costs and providing a better relationship with the customer. Availability is an important nonfunctional requirement to be considered in the development of software systems offering this type of automation. The level of system availability may be affected by the system architecture, and, especially, by the software architecture, as architectural decisions must take availability-related aspects into account. In the ATAM (Architecture Tradeoff Analysis Method) architecture evaluation method, this requirement is analyzed by means of availability scenarios. As availability evaluation is normally a complex task, requiring analysts to identify several interdependent items, the generation and, consequently, the analysis of availability scenarios is often not a trivial task. This work aims to elaborate an availability technique analysis for web-based software systems, to aid in the systematic generation of availability scenarios required in the ATAM method. To elaborate the proposal, the work covers methods for elicitation, representation and analysis of non-functional requirements in a specific software architecture, as well as concepts and taxonomies related to dependability. In the end, the technique is applied on a simplified example of web banking software system.

Web accessibility guidelines have textual representation and provide little support in systematic analysis and usage. The study hypothesizes that the guidelines can be reorganized and represented using the goal oriented technique and design patterns which will allow their usage in a more systematic manner and accommodate detailed analysis of the guidelines with other competing goals. For this study, knowledge from web designers’ experiences in using the guidelines, researchers’ findings, and the actual guidelines have been amalgamated. Six web designers have been consulted on a one-on-one basis and difficulties in using the guidelines for (1) specific scenarios, (2) systematic application, and (3) detailed systems analysis have been reported. Goal oriented modeling and design patterns have been introduced for (1) graphical representation of the guidelines using goal graphs, and (2) keeping the technical details separate from the goal graphs. The proposed representation allows for the accessibility guidelines to be systematically applied into interface design, and systems design using the goal oriented modeling technique.

Web accessibility guidelines have textual representation and provide little support in systematic analysis and usage. The study hypothesizes that the guidelines can be reorganized and represented using the goal oriented technique and design patterns which will allow their usage in a more systematic manner and accommodate detailed analysis of the guidelines with other competing goals. For this study, knowledge from web designers’ experiences in using the guidelines, researchers’ findings, and the actual guidelines have been amalgamated. Six web designers have been consulted on a one-on-one basis and difficulties in using the guidelines for (1) specific scenarios, (2) systematic application, and (3) detailed systems analysis have been reported. Goal oriented modeling and design patterns have been introduced for (1) graphical representation of the guidelines using goal graphs, and (2) keeping the technical details separate from the goal graphs. The proposed representation allows for the accessibility guidelines to be systematically applied into interface design, and systems design using the goal oriented modeling technique.