Zugl.: Dortmund, Techn. Univ., Diss., 2008

Aspect Oriented Programming has been proposed in order to handle crosscutting concerns in an ecient manner. Initial proposals in this area have been applied to the source code. Subsequently, aspects were considered to be implemented in other phases of software development such as Requirements Engineering and Software Architecture. There are several advantages in identifying aspects at the requirements level and architecture level such as detecting conicts of interest, improving the requirements modularity, reducing costs of software maintenance and preserving the notion of aspects in software development process ensuring traceability. Therefore, the purpose of this work is to develop a model to represent aspects at the requirements level and the architecture level. The requirements model denes the activities of identication of aspect requirements, both functional and non-functional, separation and composition of aspect requirements and identication of conict between aspect requirements. Since dierent stakeholders need to view the system from dierent perspectives, the architecture model allows to represent dierent views considering the representation with aspects. The proposed views are structural, use case + requirements and development. Compared to other analysed approaches, the proposed models in this work represent important characteristics that others models do not represent, such as maintaining traceability of aspects between requirements and the architecture level. In order to represent the models, extensions to the SysML modeling language were proposed. / A Programação Orientada a Aspectos foi proposta com o objetivo de manipular interesses transversais de uma maneira eciente. Propostas iniciais nesta área foram aplicadas no código fonte. Posteriormente, aspectos foram considerados para serem aplicados em outras fases do desenvolvimento de software tais como Engenharia de Requisitos e Arquitetura de Software. Há várias vantagens em identicar aspectos no nível de requisitos e no nível arquitetural, tais como detectar inicialmente conitos de interesses, melhorar a modularidade dos requisitos, reduzir custos de manutenção de software e preservar a noção de aspectos no processo de desenvolvimento de software garantindo rastreabilidade. Portanto, o propósito desse trabalho é desenvolver um modelo para representar aspectos no nível de requisitos e no nível arquitetural. O modelo de requisitos dene as atividades de identicação de requisitos aspectuais tanto de origem funcional quanto não-funcional, separação e composição de requisitos e requisitos aspectuais e identicação de conitos entre requisitos aspectuais. Uma vez que diferentes stakeholders necessitam visualizar o sistema a partir de diferentes perspectivas, o modelo de arquitetura permite representar diferentes visões considerando a representação com aspectos. As visões propostas são a estrutural, a de casos de uso + requisitos, e a de desenvolvimento. Em comparação com outras abordagens analisadas, os modelos propostos nesse trabalho cobrem importantes características que os outros modelos não cobrem, como por exemplo, manter a rastreabilidade de aspectos entre os níveis de requisitos e de arquitetura. Para representar os modelos, extensões da linguagem de modelagem SysML foram propostas. / Mestre em Ciência da Computação

Le but de ce rapport est de présenter une méthode globale de développement à partir de spécifications informelles, depuis la modélisation graphique des exigences temporelles d'un système ferroviaire critique jusqu'à une implantation systématique au moyen de méthodes formelles. Nous proposons d'utiliser ici les réseaux de Petri temporels pour décrire le comportement attendu du logiciel de contrôle-commande à construire.Tout d'abord nous construisons un modèle des exigences p-temporel prenant en compte toutes les contraintes que doit vérifier le système. Nous proposons des outils et des méthodes capables de valider et de vérifier ce modèle. Ensuite, il s'agit de construire un modèle de processus solution en réseau de Petri t-temporel. Ce modèle illustre des exigences techniques relatives à un choix technologique ou architectural. L'objectif est double : tout d'abord il est nécessaire de vérifier la traçabilité des exigences ; ensuite, il faut vérifier que l'ensemble des exigences sources sont bien implémentées dans la solution préconisée et dans sa mise en oeuvre. Enfin, nous proposons une approche visant à transformer de façon systématique le modèle de processus en machine abstraite $B$ afin de poursuivre une procédure formelle $B$ classique. Finalement, le cas d'étude du passage à niveau, composant critique dans le domaine de la sécurité ferroviaire est décrit / The introduction of new European standards for railway safety, coupled with an increasing use of software technology changes the method of development of critical railway systems. Indeed, new systems have to be at least as good as the previous ones. Therefore the appropriate safety level of critical systems has to be proved in order to obtain the necessary approval from the authorities. Accordingly a high level of reliability and correctness must be reached by the use of mathematical proofs and then formal methods. We focus on the treatment of the temporal requirements in the level crossing case study which is modelled with p-time Petri nets, and on the translation of this model in a more formal way by using the B method. This paper introduces a methodology to analyse the safety of timed discrete event systems. First, our goal is to take out the forbidden state highlighted by a p-time Petri net modelling. This model deals with the requirements of the considered system and has to contain all the constraints that have to be respected. Then we aim at describing a process identified as a solution of the system functioning. This method consists in exploring all the possible behaviours of the system by means of the construction of state classes. Finally, we check if the proposed process corresponds to the requirements model previously built.Our case-study is the level crossing, a critical component for the safety of railway systems

Les environnements confinés, tels que les blocs chirurgicaux ou les salles blanches, hébergent des processus complexes auxquels sont associés de nombreux risques. Leur conception, leur réalisation et leur exploitation sont complexes, de par les très nombreuses normes les encadrant.La qualification de ces « environnements normés », afin d’en garantir la qualité de conception, requiert une expertise fine du métier et souffre du manque d’outil en permettant l’automatisation. Partant de ce constat, nous proposons une approche unifiée visant à faciliter la qualification des environnements normés. Celle-ci s’appuie sur une représentation du contexte normatif sous la forme d’un graphe unique, ainsi que sur une modélisation de l’environnement et son objet final par étapes successives permettant une vérification incrémentale de même que la production d’informations nécessaires à la traçabilité lors de l’exploitation. Cette démarche, illustrée au travers du domaine des environnements confinés médicaux, est générique et peut s’appliquer à l’ensemble des environnements normés. / Industrial clean rooms or operating rooms are critical places often hosting dangerous or complex processes. Their design, building and use are thus difficult and constrained by a large amount of standards and rules. Qualifying these environments, in order to ensure their quality, consequently requires a high level of expertise and lacks assisting tools.This leads us to propose a unified approach aiming at easing the qualification process of standardized environments. It relies on a graph-based representation of the set of standards and rules that apply to a specific case, as well as on step-by-step modelling of the whole target environment. The verification process is then eased as it becomes incremental. During each stage, relevant information can also be gathered in order to ensure environment traceability during its use.This approach, applied to medical environments for validation purposes, remains generic and can be applied to any kind of standardized environment.

Uppsatsen undersöker inledningsvis om FOI:s principer för kravformulering kan anses behöva kompletteras mot bakgrund av Försvarsmaktens behov och undersöker därefter kvalitén i några av flygvapnets kravunderlag relativt principerna för kravformulering. Av resultatet framgår att principerna kan behöva kompletteras med principerna prioritering och kontextuell beskrivning. Av fallstudiernas resultat framgår att kvalitén i flygvapnets kravunderlag relativt principerna för kravformulering generellt är låg, att den varierar mellan underlagen och att den i vissa fall är mycket låg i fråga om uppfyllnad av principerna. Uppsatsen rekommenderar att FOI:s principer för kravformulering utökas med principerna prioritering och kontextuell beskrivning. Vidare rekommenderas flygvapnet att öka kvalitén i framtida kravformuleringarna så att den militära nyttan av arbete med kravformulering även kan öka. Slutligen och som biprodukt visas hur ett bör-krav kan användas i ett kravunderlag på ett annat sätt än det som har varit Försvarsmaktens tradition. / The paper firstly examines if the FOI principles for formulating requirements need to be complemented as a result of the Armed Forces needs and then examines the quality of some of the Air Force requirements documents relative to the principles of requirements formulation. The results show that the principles can be complemented by the principles of priority and contextual description. The case studies results show that the quality of the air force's requirements documentation relative to the principles is generally low, that it varies between the documents and that they in some cases are very low in terms of fulfilling the principles. The paper recommends that the FOI principles for formulating requirements are complemented with the principles of priority and contextual description. It recommends the Air Force to improve the quality of future requirement formulations so that the military utility of such work also may increase. Finally, as a spin-off product, it shows how a should-requirement can be used in a different way than what has been the Armed Forces tradition.

Requirements Engineering (RE) approaches are widely used in several domains such as telecommunications systems, information systems, and even regulatory compliance. However, they are rarely applied in healthcare beyond requirements elicitation. Healthcare is a multidisciplinary environment in which clinical processes are often performed across multiple units. Introducing a new Information Technology (IT) system or a new process in such an environment is a very challenging task, especially in the absence of recognized RE practices. Currently, many IT systems are not welcomed by caregivers and are considered to be failures because they change what caregivers are familiar with and bring new tasks that often consume additional time. This thesis introduces a new RE-based approach aiming to evaluate and estimate the potential impact of new system integrations on current practices, organizational goals,and user satisfaction using goal modelling and process modelling techniques. This approach is validated with two case studies conducted in real hospitals and a usability study involving healthcare practitioners. The contributions of the thesis are: • Major: a novel Activity-based Process Integration (AbPI) framework that enables the integration of a new process into existing practices incrementally, in a way that permits continuous analysis and evaluation. AbPI also provides several alternatives to a given integration to ensure effective flowing and minimal disturbance to current practices. AbPI has a Goal Integration Method to integrate new goals, an Integration Method to integrate new processes, and an Alternative Evaluation Method exploiting multi-criteria decision-making algorithms to select among strategies. The modelling concepts of AbPI are supported by a profile of the User Requirements Notation augmented with a new distance-based goal-oriented approach to alternative selection and a new data-quality-driven algorithm for the propagation of confidence levels in goal models. • Minor: a usability study of AbPI to investigate the usefulness of the framework in a healthcare context. This usability study is part of the validation and is also a minor contribution due to: 1) the lack of usability studies when proposing requirements engineering frameworks, and 2) an intent to discover the potential usefulness of the framework in a context where recognized RE practices are seldom used.

Une entreprise, et particulièrement une PME ou une PMI, doit être apte à évoluer sur des secteurs d’activités souvent très concurrentiels qui évoluent rapidement, par exemple, en fonction d’une clientèle volatile et soucieuse de trouver des produits et des services moins chers et plus adaptés à ses besoins. La PME se trouve alors confrontée à des problèmes de réactivité et de flexibilité face à cette clientèle. Par effet direct, elle recherche à réduire les délais et les coûts de réalisation tout en privilégiant aussi la qualité et le degré d’innovation des biens et des services qu’elle propose. Le système d’information de cette PME est un enjeu essentiel pour mettre en œuvre cette stratégie et maximiser donc la réactivité et la flexibilité mais aussi la rentabilité et la qualité recherchées. Ce sont des qualités incontournables, garantes d’une autonomie et d’une reconnaissance dont la PME a grand besoin. Le système d’information est en effet la courroie de transmission entre le système de décision et le système productif qui génère la valeur ajoutée de la PME. Il fait le lien entre les différents acteurs de l’organisation mais aussi avec les partenaires externes de l’entreprise. Une partie de ce système d’information est de fait informatisée. Celui-ci supporte, mémorise et traite les informations nécessaires aux différents processus de décision, métier et support qui tapissent l’organisation pour servir la stratégie de l’entreprise. Les fonctionnalités, les interfaces et les données qui forment ce système informatisé sont donc cruciales à comprendre, à développer en accord avec les besoins de la PME, à améliorer au fur et à mesure de l’évolution de ces besoins. La PME est donc tentée de se lancer, seule ou accompagnée, dans des projets dits d’informatisation i.e. des projets visant le développement ou l’amélioration de son système informatisé. Nous nous intéressons ici à des projets visant à développer des applicatifs de gestion et de pilotage de la PME. La PME – prenant alors le rôle de la maîtrise d’ouvrage (MOA) – tout comme la société de services qui l’accompagne – prenant alors en charge le rôle de maîtrise d’œuvre (MOE) – doivent partager une vision commune des besoins d’informatisation. Elles sont alors appelées à mener en commun des activités d’ingénierie des besoins et des exigences (IBE). L’IBE guide et accompagne la PME pour arriver à décrire et formaliser ses besoins. Elle permet ensuite à la société de service de spécifier de manière plus formelle ces besoins sous forme d’exigences qui définissent alors les travaux de développement souhaités. L’IBE est souvent réalisée avec une assistance à maitrise d’ouvrage. Cette étape cruciale reste cependant difficile pour une PME. Elle est de plus souvent réalisée par la MOE elle-même pour faire face au manque de moyens, de temps et de compétences de la PME. Or, l’implication des collaborateurs de la PME est primordiale pour la réussite de tout projet d’informatisation, surtout si celui-ci impacte durablement le fonctionnement de la PME.Ces travaux, développés dans le cadre d’une collaboration Industrie/recherche avec la SSII RESULIS, ont consisté à développer une méthode d’IBE qui offre aux PME des concepts, des langages et des moyens de modélisation et de vérification simples mais suffisants tout en tant aisément manipulables de manière intuitive et donnant lieu à une formalisation pertinente pour la MOE. Cette méthode est basée sur le croisement et la complémentarité de principes issus de la Modélisation d’Entreprise et de l’Ingénierie Système pour l’élicitation de besoins. Des moyens de vérification et de validation semi-formels sont appliqués pour garantir certaines qualités attendues des exigences résultantes. La méthode s’intègre également au cycle de développement basé sur les modèles pour permettre a posteriori d’accélérer la production de prototypes et de rendre interopérables les langages et outils de la MOA et de la MOE. / Most enterprises, and especially SMEs, must develop their business in very competitive and rapidly changing fields. Where they have to adapt to volatile customers who want to find cheaper products and services and that are more corresponding to their needs. The SME is then confronted with problems of responsiveness and flexibility in responding to these customers. As an effect, it seeks to reduce the costs and time to market and to provide high quality and innovative goods and services. The SME’s information system is an asset on which it can rely to implement this strategy and so to maximize its responsiveness and flexibility but also to reach the sought profitability and quality. These are key qualities that guarantee autonomy and recognition, qualities that are highly needed by any SME. The Information system is indeed the drive belt of information not only inside the enterprise, between decision and operational systems proving added value of the enterprise, but also within its environment that includes its external partners. Part of this information system is computerized. It stores and processes the information needed by the different decision-making, business and support processes that serve the enterprise’s strategy. It is crucial to understand the features, interfaces and data that make up this computerized system and develop them according to the needs of SME. The SME is therefore tempted to embark, alone or accompanied, in so-called computerization projects i.e. projects for the development or improvement of its computerized system. We are interested in projects aimed at developing management applications of SMEs. The SME – then assuming the role of project owner – along with the development team – supporting the role of project management – have to share a common vision of the computerization needs. They are then called upon to carry out jointly requirements engineering (RE) activities. RE guides the SMEs to be able to describe and formalize its needs. It then allows the development team to specify more formally these needs as requirements which then define the required development work. RE is often carried out with the assistance of project owner support. This crucial step remains difficult for SMEs. It is most often performed by the development team itself to address the lack of resources, time and skills of SMEs. However, the involvement of the SME’s members is vital to the success of any computerization project, especially if it permanently affects the functioning of the enterprise.This work, developed through a collaborative with the company RESULIS, consisted in developing a requirements engineering method which offers SMEs concepts, simple languages, modeling and verification means that are easily and intuitively manipulated and provide sufficient and relevant formalization of the SME’s requirements. This method is based on principles derived from both enterprise modeling and systems engineering fields for requirements elicitation. Semi-formal verification and validation means are applied to guarantee some expected qualities of the resulting requirements. The method is also integrated in the model driven development cycle to enable a posteriori the production of prototypes and make interoperable the languages and tools used by both the SME and the development team.

Made available in DSpace on 2016-06-02T19:06:05Z (GMT). No. of bitstreams: 1 5226.pdf: 3993089 bytes, checksum: a0750877fc955b7274271f1326ade7b3 (MD5) Previous issue date: 2011-08-24 / One of the benefits of Service-Oriented Architecture is to make business processes adaptable when this architecture is adopted during software development. For reaching this purpose, it is essential to have a support for services identification in order to meet the business goals. However, many available services found on web environment are too specific and can hardly be reused in different applications. This happens because there is a lack of systematic approaches for supporting generic services identification in a systematic way. Objective: Presenting a strategy for identifying generic services that support business processes. The identification is supported by Goal Diagrams and Business Process Models and is composed by a set of guidelines which assist the domain engineer in extracting the services. The identified services are generic enough to be reused in similar applications of a specific domain. Methodology: To elaborate our strategy, some domain-specific business process were analyzed, aiming at extracting key tasks and turn them into generic web services. This analysis was supported by an extended version of goal diagrams (GTR) and conventional BPM models. Results: As a proof-of-concept we applied our strategy for identifying services in the planning processes domain and we developed a real e-gov web portal based on the identified services. The web portal was used successfully by two different schools for elaborating their planning processes. Conclusion: We claim that our strategy is generic and can be applied to other business processes providing software suitability to the organization dynamics, besides the potential reuse of services in different instances of the same business process. / Um dos benefícios da Arquitetura Orientada a Serviços é tornar os processos de negócios adaptáveis quando esta arquitetura é adotada durante o desenvolvimento de software. Para atingir este propósito, é essencial ter um suporte para a identificação de serviços a fim de atender os objetivos de negócio. No entanto, muitos serviços disponíveis encontrados no ambiente web dificilmente podem ser reutilizados em diferentes aplicações. Isso acontece porque faltam abordagens sistemáticas de apoio à identificação de serviços genéricos de uma forma sistemática. Objetivo: Apresentar uma estratégia para identificar serviços genéricos que dêem suporte aos processos de negócios. A identificação é apoiada por diagramas de objetivos e modelos de processos de negócios, e é composto por um conjunto de diretrizes que auxiliam o engenheiro de domínio na extração dos serviços. Os serviços identificados são genérico o suficiente para serem reutilizados em aplicações semelhantes de um domínio específico. Metodologia: Para elaborar a nossa estratégia, um processo de negócio específico de domínio foi analisado, com o objetivo de extrair tarefas chaves deste processo e transformá-las em serviços web genéricos. Esta análise foi apoiada por uma versão estendida de diagramas de objetivos (GTR) e modelos BPM convencionais. Resultados: Como prova de conceito, aplicamos a nossa estratégia para a identificação de serviços no domínio do processo de planejamento e desenvolvemos um portal web real com base nos serviços identificados. O portal foi utilizado com sucesso por duas escolas diferentes para a elaboração de seus processos de planejamento. Conclusão: Afirmamos que nossa estratégia é genérica e pode ser aplicada a outros processos de negócios provendo a adequação do software à dinâmica organização, além do potencial de reúso de serviços em diferentes instâncias do mesmo processo de negócio.

Submitted by Clebson Anjos (clebson.leandro54@gmail.com) on 2016-02-11T19:32:02Z No. of bitstreams: 1 arquivototal.pdf: 4976069 bytes, checksum: f6823a093e9be9d6a14113d2ff7e56f3 (MD5) / Made available in DSpace on 2016-02-11T19:32:02Z (GMT). No. of bitstreams: 1 arquivototal.pdf: 4976069 bytes, checksum: f6823a093e9be9d6a14113d2ff7e56f3 (MD5) Previous issue date: 2014-07-24 / Coordenação de Aperfeiçoamento de Pessoal de Nível Superior - CAPES / In software development process, Requirements Engineering is responsible for identifying what are the objectives of the desired product, its features, activities and constraints, based on the understanding of the scenario where this product is used and/or expected behaviors by users. To interact directly or indirectly with the people, the products and the processes impacted by them, are required to comply with the legal regulations related and found in the legal rules or laws. At the organizational level, these regulations determine how business practices should be, which will be reproduced for their products/processes. The Legal Compliance is a requirement imposed on organizations by government departments and their non-compliance may result in legal and financial problems for these organizations. It is the role of Requirements Engineering dealing with legal compliance in these scenarios. In this context, the Nòmos framework extends the i* framework to achieve legal compliance requirements of information systems and business processes. Nòmos proposes a systematic and cohesive method to achieve this goal, from the execution of activities of elicitation, modeling and negotiation of requirements and laws. However, Nòmos was designed to be used in requirements models represented in i*. Since i* is not widely used in industry, dependence on i* can hurt the adoption of Nòmos as a process to achieve legal compliance in Requirements Engineering. In this sense, this work proposes to adapt the process of Nòmos, making it less dependent on i* and more flexible to be used with other modeling languages requirements. So, was created the GenNormas, in order to guide the acquisition of legal compliance of software requirements or business processes specified in other modeling languages, in addition to i *. Finally, to illustrate the use of our approach, it has been applied in the specification of a hypothetical system, connected to the e-commerce domain, applying GenNormas in requirements specification models, such as the Business Process Modeling Notation (BPMN), in Use Case Diagram and the User Stories. / No processo de desenvolvimento de software, a Engenharia de Requisitos é responsável por identificar quais são os objetivos do produto pretendido, suas funcionalidades, atividades e restrições, a partir do entendimento do cenário onde este produto será utilizado e/ou dos comportamentos esperados por seus usuários. Por interagirem direta ou indiretamente com as pessoas, estes produtos, e os processos impactados por eles, estão obrigados a cumprirem com as regulamentações jurídicas relacionadas e encontradas nas normas jurídicas ou leis. No âmbito organizacional, estas regulamentações determinam como devem ser as práticas de negócio, que serão reproduzidas por seus produtos/processos. A conformidade legal é uma exigência imposta às organizações pelos departamentos governamentais e o seu não-cumprimento pode acarretar transtornos judiciais e financeiros às organizações. É papel da Engenharia de Requisitos lidar com a conformidade legal nestes cenários. Nesse contexto, o Framework Nòmos estende o Framework i* para alcançar a conformidade legal dos requisitos de sistemas de informação e de processos de negócio. Nòmos propõe um método sistemático e coeso para atingir este objetivo, a partir da execução de atividades de elicitação, modelagem e negociação de requisitos e leis. Porém, Nòmos foi concebido para ser usado em modelos de requisitos representados em i*. Visto que o i* não é usada amplamente na indústria, a dependência do i* pode prejudicar a adoção do Nòmos como processo para alcançar a conformidade legal na engenharia de requisitos. Neste sentido, esta dissertação propõe adaptar o processo do Nòmos, tornando-o menos dependente do i* e mais flexível para ser utilizado com outras linguagens de modelagem de requisitos. Assim, foi criado o GenNormas no intuito de guiar a obtenção da conformidade legal de requisitos de software ou de processos de negócio especificados em outras linguagens de modelagem, além do i*. Finalmente, para exemplificar a utilização da nossa abordagem, ela foi aplicada na especificação de um sistema hipotético, ligado ao domínio do comércio eletrônico, aplicando o GenNormas em modelos de especificação de requisitos, como a Notação de Modelagem para Processos de Negócio (BPMN), no Diagrama de Caso de Uso e nas Estórias de Usuário.

Submitted by Viviane Lima da Cunha (viviane@biblioteca.ufpb.br) on 2016-02-17T10:53:15Z No. of bitstreams: 1 arquivototal.pdf: 20428901 bytes, checksum: b66dc5cc2c10c67d4c70f46436440ab4 (MD5) / Made available in DSpace on 2016-02-17T10:53:15Z (GMT). No. of bitstreams: 1 arquivototal.pdf: 20428901 bytes, checksum: b66dc5cc2c10c67d4c70f46436440ab4 (MD5) Previous issue date: 2015-06-23 / Goal Oriented Requirements Engineering approaches capture both the stakeholders’ goals and the requirements of the system-to-be, so that the latter corresponds to the stakeholders desires. Goal models can capture similarities and the variability of a Software Product Line (SPL), but they cannot describe the detailed behavior of its functionality. Due to this limitation, a process called GS2SPL (Goals and Scenarios to Software Product Lines) was defined to systematically obtain, from goal models, feature models and the specification of use case scenarios with variability described in PLUSS (Product Line Use case modeling for Systems and Software engineering). However, the variability of the SPL and the configuration knowledge are tangled an the scenarios described in PLUSS, jeopardizing the maintenance and reuse of artifacts. In order to solve this problem, it was proposed techniques to specific use case scenarios with separation of crosscutting concerns (or just, aspectual scenarios). One of these techniques is called MSVCM (Modeling Scenario Variability as Crosscutting Mechanisms), which specifies the variability and configuration knowledge of a SPL separately, as well as it defines a process to configure the specifications of a product. Thus, this work proposes an extension of the GS2SPL to obtain, systematically, a feature model and a specification of aspectual scenarios in MSVCM, from goal models. This approach is called GAS2SPL (Goals and Aspectual Scenarios to Software Product Lines) and their activities were described using the TaRGeT (Test and Requirements Generation Tool) example. GAS2SPL approach was evaluated through a comparative study between TaRGeT and MyCourses artifacts generated by GS2SPL and GAS2SPL approaches, taking into account modularity (features scattering and tangling scenarios) and expressiveness (how detailed are the configuration knowledge). After evaluating our approach, we realize that GAS2SPL approach reduced in the features scattering and tangling in the scenarios to zero, addition to own a knowledge configuration more specific because uses less symbols for it elaborate. / Abordagens de Engenharia de Requisitos Orientadas a Objetivos capturam tanto os objetivos dos interessados ( stakeholders) como os requisitos do software a ser desenvolvido, de modo que este último corresponda ao que realmente os interessados desejam. Modelos de objetivos são capazes de capturar as similaridades e variabilidades de uma Linha de Produto de Software (LPS), mas não conseguem descrever o comportamento detalhado de suas funcionalidades. Diante dessa limitação, o processo GS2SPL (Goals and Scenarios to Software Product Lines) foi definido para obter sistematicamente, a partir de modelos de objetivos, modelos de features e especificações de cenários de casos de uso com variabilidade, descritos em PLUSS (Product Line Use case modeling for Systems and Software engineering). Entretanto, a variabilidade da LPS e o conhecimento de configuração ficam entrelaçados nos cenários descritos em PLUSS, o que prejudica a manutenção e reuso dos artefatos. A fim de solucionar esse problema, foram propostas técnicas de especificação de cenários de caso de uso com separação de interesses transversais (ou, simplesmente, cenários aspectuais). Uma destas técnicas é o MSVCM (Modeling Scenario Variability as Crosscutting Mechanisms), que especifica a variabilidade da LPS separadamente do conhecimento de configuração e define um processo para configurar as especificações de produto. Assim, este trabalho propõe uma extensão do GS2SPL visando obter, sistematicamente, modelos de features e especificações de cenários aspectuais em MSVCM, a partir de modelos de objetivos. Esta abordagem chama-se GAS2SPL (Goals and Aspectual Scenarios to Software Product Lines) e suas atividades foram descritas utilizando o TaRGeT (Test and Requirements Generation Tool) como exemplo. A abordagem GAS2SPL foi avaliada através de um estudo comparativo entre os artefatos do TaRGeT e do MyCourses- A Course Scheduling System gerados pelas abordagens GS2SPL e GAS2SPL, levando-se em consideração a modularidade (espalhamento de features e entrelaçamento de cenários) e, a expressividade (quão detalhado é o conhecimento de configuração). Depois de realizar a avaliação, percebemos que a abordagem GAS2SPL conseguiu reduzir o espalhamento de features e o entrelaçamento de cenários para zero, além de possuir um conhecimento de configuração mais expressivo, pois utiliza menos símbolos para elaborá-lo.